文/明道云創(chuàng)始人任向暉
本文來自即將出版的《零代碼企業(yè)應用搭建指南》中的關鍵章節(jié)，指導用戶進行相對復雜應用的前期信息架構工作。
零代碼平臺賦能了業(yè)務開發(fā)者，讓他們可以不寫代碼就能完成應用實現。但是企業(yè)應用設計和開發(fā)畢竟是一個復雜過程，對于大多數用戶來說，即興創(chuàng)作是很難的。對于比較復雜的應用搭建需求，它依然需要一個完善的分析和計劃的過程。
在企業(yè)信息系統(tǒng)建設過程中，開發(fā)和實施前都離不開架構設計工作，對于復雜的系統(tǒng)，信息架構所花的工作時間比例更高。而且，信息架構是一個長期過程，它不僅服務于具體業(yè)務系統(tǒng)開發(fā)和實施的需求，還包括中長期規(guī)劃和服務于應用的迭代與遷移需求。
本章重點介紹企業(yè)信息架構（Enterprise Architect）的一般方法，以及如何簡化它們來服務零代碼應用搭建的過程。
從上世紀七八十年代開始，企業(yè)信息架構就開始成為一個專業(yè)領域，形成了一整套方法論。這些方法論圍繞復雜組織的信息系統(tǒng)建設提供了抽象的思維框架和計劃工具，它們雖然大多來自軍工、航天和政府需求，但經過整合以后，同樣適用于企業(yè)領域。
在這些方法中，來自 IBM 的 Zachman 框架和源自美國國防部的 TOGAF 框架是比較典型的信息架構方法論。我們對這兩個方法論做一個簡單介紹。
Zachman 框架起源于 John Zachman 先生在 1987 年完成的信息系統(tǒng)架構論文“A framework for information systems architecture”，他把信息系統(tǒng)架構設計相關的各種元素歸納到如下表格之中：
TOGAF 模型全稱 The Open Group Architect Framework，目前由 The Open Group 負責維護，已經發(fā)展到 9.x 版本。
TOGAF 框架定義了企業(yè)架構內容和實施步驟及交付物，將企業(yè)架構劃分為業(yè)務架構、應用架構、數據架構和技術架構，形成了涵蓋企業(yè)各方面的架構體系，是一個面向各種不同組織、具有很強通用性的企業(yè)架構。對于實際的架構工作，其指導意義高于實踐操作的意義。其中，業(yè)務架構：定義企業(yè)戰(zhàn)略、企業(yè)治理、組織結構以及關鍵的業(yè)務流程。數據架構：描述組織的邏輯與物理數據資產的結構和組織的數據管理資源。應用架構：提供描述應用系統(tǒng)的部署、交互以及系統(tǒng)與組織核心業(yè)務流程之間關系的藍圖。技術架構：描述用于支持業(yè)務、數據、應用服務的軟件、硬件的能力。這些軟、硬件以及邏輯技術部件包括 IT 基礎設施、中間件、網絡、通信、處理機制、標準等。
TOGAF 的一大特色在于其獨特的架構開發(fā)方法 AMD (Architecture Development Method)，它是一個以需求為中心的循環(huán)過程。在總體框架和規(guī)劃原則的前提下，ADM 方法從架構愿景出發(fā)，經過業(yè)務架構規(guī)劃，確定信息系統(tǒng)架構和技術架構，然后結合現有的信息化基礎，給出企業(yè)信息化建設，適應性改造的解決方案。遷移計劃針對實施方案中不同項目的優(yōu)先權，評估各個項目的依賴程度、遷移費用、收益等，并形成具體的實施規(guī)劃；實施治理制定了各個實施項目的建議，建立架構規(guī)約來管理所有實施和部署的過程，以確保實施項目架構與相關項目架構的一致性。架構變更管理關注業(yè)務目標、環(huán)境和技術等方面的演變和發(fā)展，為是否啟動和規(guī)劃新的架構進化周期提供。
TOGAF 目前是企業(yè)架構專業(yè)領域最知名的框架，它也有完善的培訓、認證體系。但它和 Zachman 框架一樣，都過于龐雜，缺乏實際項目落地的可用性，更多地演化成為一個職業(yè)，而難以被一般企業(yè)實踐直接所用。
接下來的小節(jié)會專門介紹一個簡化的信息架構方法。它保留了經典企業(yè)信息架構的戰(zhàn)略視角，但更多著眼于 IT 項目的落地需求，簡化了參與角色和架構實現中的環(huán)節(jié)，讓非專業(yè)人員也能夠從事信息架構的實質性工作。
方法論的介紹很容易陷入晦澀的程序說明，它最好能夠結合實例來表達。為此我們專門準備了一個大多數企業(yè)用戶能夠有代入感的案例。但在解析案例之前，還是有必要先簡單概述一下這個方法論的核心思想。
RPIC 是 Role，Process，Information 和 Content 的縮寫，意思是角色、流程、信息和內容。它是一個循序漸進的分析計劃過程，從企業(yè)管理和運營角色的分解出發(fā)，為每個涉及到的角色（可能包括外部角色）分析他們在業(yè)務活動中需要完成的流程和接觸的信息（數據），當枚舉出所有的流程和信息后，就能夠取得它們的不重復并集；通過這個并集內容分項規(guī)劃數據架構、角色權限、統(tǒng)計報表和工作流程四項核心架構內容。
整個過程簡潔明快，著眼于具體規(guī)劃產出。稍有 IT 經驗的職場人員經過簡單訓練就能夠掌握。尤其是結合零代碼平臺，規(guī)劃人員甚至可以直接上手完成具體的應用搭建。當然，使用者要了解這是一個簡化的框架。它不可避免地會忽略一些內容，比如企業(yè)戰(zhàn)略視角、復雜企業(yè)組織的干系人網絡、規(guī)劃的長期視角、應用的迭代和遷移計劃。這些被裁剪的內容并非不重要，只是它們不一定出現在每個應用的需求時刻。而且我們也會有其他辦法來針對性補充。
接下來的案例，我們會按照這個方法論，一步一步引導大家理解和掌握企業(yè)信息架構技巧。
案例中的企業(yè)叫“普渡餐飲”，是一家成長中的企業(yè)餐飲服務企業(yè)。它為周邊企業(yè)提供員工送餐和宴會送餐服務，面對的客戶對象是企業(yè)。因為普渡餐飲重視菜品質量和口味，它的服務獲得了一些高福利企業(yè)的歡迎。一般企業(yè)會為員工常年訂購早餐和午餐，遇到有會議用餐需求的時候，也非常樂意繼續(xù)使用普渡餐飲的服務，因此普渡餐飲的這兩種業(yè)務有明顯的客戶交叉現象。
普渡餐飲的產品目錄是有獨立菜品和套餐組成的綜合菜單。員工早午餐可以從數十種套餐中進行選擇，宴會則可以選擇套餐或者自選的菜品組合。大多數客戶會傾向于選擇訂購套餐。
因為在發(fā)展的早期階段，普渡餐飲目前只有一個生產加工中心。出于成本控制的目的，普渡餐飲除了包裝材料以外，幾乎不保留任何生鮮原料庫存，采購完全根據前一天的訂單，在當晚完成采購，次日根據訂單加工和派送。菜品加工完全在自營的生產加工中心完成。因為營業(yè)規(guī)模有限，普渡同一時期只在數家固定的生鮮配送商那里采購，每月結算費用。
普渡餐飲的物流服務是外包的，通過固定合作的物流公司將制作好的菜品和包裝快遞給本地客戶。物流公司每月根據實際的物流費用與普渡餐飲結算。
結合以上的案例背景，我們的目標是為普渡餐飲設計核心業(yè)務系統(tǒng)的信息架構，并通過零代碼平臺來實現整套應用。為了控制篇幅，我們把核心業(yè)務系統(tǒng)定義為從普渡餐飲接單開始到餐品交付，并完成收款的全部過程，舍去行政、人事、營銷等環(huán)節(jié)。
我們要獲得的產出物具體包括：
信息架構中的數據結構定義
工作流程定義
可用的應用系統(tǒng)
配套的使用文檔
（1）價值創(chuàng)造過程總覽
為了梳理清楚一家企業(yè)的信息架構需求，我們一般可以先繪制一張流程圖。這張流程圖可以從宏觀的層面將這家企業(yè)的價值創(chuàng)造過程表達出來。在流程圖中，節(jié)點表達的是參與主體，既可能是內部部門，也可能是外部角色。價值創(chuàng)造按照從左往右的方向進行，這樣既容易繪制（減少交叉），又能夠有條理地遍歷所有的參與角色。而角色是 RPIC 方法中的出發(fā)點，我們不能遺漏任何參與業(yè)務流程的重要角色。
在本例中，客戶向普渡餐飲的銷售部下訂單，銷售部據此向內部的加工中心下加工單，加工中心再據加工單向生鮮配送商下采購單。以上是整個業(yè)務活動的信息流部分。然后生鮮配送商向加工中心配送食材原料，再被加工成最終產品，并通過物流服務商配送給客戶。在這個流程圖中，信息流用虛線表達，實物流用實線表達。在后面的信息架構工作中，我們重點要關注的是信息流，以及和信息流相關的角色主體。
銷售部
加工生產中心
客戶（外部）
生鮮配送商（外部）
物流服務商（外部）
在角色定義中，內部用戶一般要精確到特定的職能，而外部角色一般不需要細化，因為上下游協作主體一般都有固定的角色來和本企業(yè)進行交互。比如在本例中，無論是物流服務商，還是生鮮配送商，都是由客戶服務部門來對接的。
所以接下來，我們按照這個分析結果逐項厘清所有的流程參與角色
（2）參與角色盤點
從總覽流程圖，我們挖掘出了和業(yè)務活動有關的角色。在列舉具體角色的時候可以分別從管理角色和運營角色這兩種類型出發(fā)。因為必然存在的科層分工，每個企業(yè)組織中都會有不同的崗位層級，他們在業(yè)務活動中需要接觸不同的數據對象和完成不同的工作內容，因此，分開列舉運營用戶和管理用戶能夠幫我們把信息架構設計得更完善。
下表是我們根據主體對象繼續(xù)開發(fā)出來的角色清單。為簡化案例，我們只細分了和案例目標有關的兩個職能部門和總經理角色。這樣我們就有了 RPIC 方法的出發(fā)點——角色（Role），后續(xù)的架構設計工作將圍繞這些角色的工作視角進行。如果你需要通過用戶訪談來幫助架構設計，也可以明確地將這些角色用戶當作訪問對象，觀察他們的業(yè)務活動，搜集來自他們的工作材料。
我們以其中三個角色為例，來說明如何梳理不同角色的信息和流程觸點。這三個角色是銷售專員，廚師長助理和總經理。
銷售專員和廚師長助理都是運營用戶角色，他們的數據和流程觸點往往比較具體，涉及到原始行數據的搜集和錄入，也包括發(fā)起具體的業(yè)務活動。通過分析，我們可以總結銷售專員的最重要業(yè)務活動就是接受客戶的訂單和向加工中心發(fā)出加工單；進一步分析，如果要處理客戶訂單，就不可避免地要建立和維護客戶檔案，以及產品價目表這兩個關聯數據對象，否則這個訂單是無法有效建立的。（不可能在一個客戶的多訂單中重復錄入客戶信息，也不應該在訂單中不斷重復產品具體信息）。這個進一步分析表達在下圖的擴展箭頭上。這種擴展分析是我們通過角色業(yè)務活動整理數據架構的基本方法。在這個分析圖中，加粗和紅色的字體表達的就是整理出來的業(yè)務數據對象，也就是 RPIC 方法中的 I（Information）。
訂單
客戶
產品價目表
加工單
供應商
物料
采購訂單
運單
除了這兩個運營用戶角色，我們再分析一個管理角色——總經理。
管理角色對于企業(yè)信息和流程的運用一般都會基于運營用戶已經處理的數據內容，所以如下圖所示，總經理希望分析訂單和客戶變化趨勢，分析利潤情況，這兩者的基礎數據支持都已經在以上運營用戶管理的數據基礎之上，我們已經無需再擴展更多的數據對象。
但是，管理視角可能會提示我們既有數據架構的不足。比如，如果總經理希望考察加工中心的人效數據，則最好能夠增加加工中心的出勤信息數據。
額外說明一下，在本例中，之所以訂單的成本核算可以根據采購單直接獲取，是因為這家餐飲企業(yè)在財務會計上使用批次成本法，也就是銷貨成本可以直接對應到某些批次的進貨成本。
（4）用 ER 圖細化數據模型
第 3 步已經列出信息系統(tǒng)所需要的數據對象。在此基礎上，我們繼續(xù)細化數據的屬性，也就是描述每個數據對象的字段。
描述數據的屬性可以基于現有工作流程中的材料，比如現有的 IT 系統(tǒng)界面，Excel 文件，紙質表單等。如果設計者本人不直接從事相關業(yè)務活動，還可以訪談相關的職能用戶。
下面給出本案例需求所涉及到的數據對象列表和他們的屬性。在架構設計上，我們一般用實體關系圖（ER 圖）來表達。ER 圖的繪制雖然有一些專業(yè)約定，但是它并不難理解，所以建議零代碼應用深度使用者學習掌握。概括來說，ER 圖繪制的規(guī)則包括：
（1）用表格框來表達一個獨立的業(yè)務對象，對應著關系數據庫中的數據表。同一性質的主體必須放到同一個數據表中。比如我們不能有客戶表和大客戶表，也不能有年度客戶表這樣的概念，客戶就是客戶，所有屬性的客戶都應該在一個獨立的客戶表中。
（2）在表格框的主體部分羅列描述主體的屬性，對應著關系數據庫中數據表的字段。在正式的應用開發(fā)設計中，還需要定義字段類型、主鍵和外鍵，對于應用平臺搭建用戶來說，這些技術化的環(huán)節(jié)全部可以省略。
（3）用連接線建立不同數據表之間的關聯。關聯主要包括一對一、一對多和多對多的類型。比如本例中，客戶和訂單就是一對多的關系，用表示。而訂單明細和產品價目表就是一對一的關系，用表示。有關關聯數據庫的基礎知識可以參考第 3 章中關于工作表關聯的類型。
（4）整個 ER 圖的布局要注意位置關系，讓具有關聯關系的對象排列在附近位置，讓關聯關系更容易被理解。
產品分類表的建立則是為了讓顧客訂購產品的時候能夠方便地按照類別進行查找，比如冷菜、熱菜、早餐和套餐等。
設計數據結構也并非一定要使用 ER 圖。對于簡單的數據關聯關系，用一般表格加標注來做計劃也是可以的。無論用何種方法做計劃，分析出來的數據對象列表就會完整對應零代碼應用搭建時的工作表對象。
企業(yè)軟件行業(yè)發(fā)展數十年，在常規(guī)的企業(yè)運營活動中已經積累和完善了成熟的數據模型。比如管理銷售漏斗的 CRM 數據架構，管理貿易活動的 ERP 數據架構，管理項目績效的 PSA 數據架構。這些數據架構都反映在成熟的軟件產品中。所以，企業(yè)自建數字化系統(tǒng)既不能閉門造車，也無需自己重新發(fā)明輪子。有時候直接參考成熟軟件的數據架構是一個明智的做法。明道云零代碼平臺在提供銷售管理應用模版時，就直接復刻了 Salesforce 和微軟 Dynamics CRM 的數據結構。
（5）用流程圖繪制業(yè)務流程
第 3 步列出各個角色的流程和數據觸點，接下來我們詳解每一個流程，為具體的應用設計作準備。我們以列出的 5 個流程中的“按加工單采購流程“為例進行具體拆解。
按加工單采購是廚師長助理的業(yè)務活動。他接受來自銷售部門的加工單，根據加工單內容向生鮮配送商下采購訂單。以下是通過標準流程圖對這項業(yè)務活動的流程解析。廚師長助理根據生產工單內容生成了原料采購單，并根據當前輔料庫存的情況決定是否增補輔料。每一項采購流程均已供應商確認而結束。
在流程圖的右側，我們可以在對應的位置上起草一些具體的架構內容。比如，根據多工單生成采購單的節(jié)點就對應了加工單的自定義動作（工作流的一類）的創(chuàng)建，它的實質是要根據加工單明細來獲取物料明細，并將物料明細組合成計劃狀態(tài)下的采購單。而同樣，創(chuàng)建輔料采購單則比較簡單，它應該直接依附在物料表記錄上，針對特定輔料來創(chuàng)建采購單。
通過以上步驟，我們從角色出發(fā)，遍歷每個角色的流程和信息觸點，完成了多項架構內容的產出。這些產出可以直接服務于零代碼應用搭建。我們可以小結如下：
（1）數據結構作為工作表來源。在本例中，我們已經羅列出了 13 個數據對象，其中有 4 個明細子表。在應用搭建時，依次創(chuàng)建這些工作表，并建立關聯。
（2）根據單據狀態(tài)，可以創(chuàng)建工作表下的多個視圖，例如“草案訂單”、“待執(zhí)行訂單”等。
（3）系統(tǒng)所涉及到的所有內外部角色清單，作為應用中的自定義角色依次創(chuàng)建和賦權。
（4）運營角色和管理角色所需要的報表內容，作為自定義頁面及其統(tǒng)計組件搭建的藍圖。
（5）每個角色的業(yè)務活動及其分析出來的流程作為工作流配置的藍圖。其中有一部分工作流將通過用戶的手工觸發(fā)（自定義動作）執(zhí)行。
以上這五個部分就是應用平臺搭建所需要的基本架構內容。我們從需求命題的參與角色出發(fā)，一步一步梳理，得到具體的工作清單。這個過程所需要花的時間取決于項目的規(guī)模。一般而言，單個職能部門的小型應用并不需要這么完善的分析過程，但像這家餐飲公司的核心業(yè)務系統(tǒng)還是有必要進行這樣的架構分析工作的。雖然零代碼應用平臺的使用不像代碼開發(fā)工作那么技術化，但我們依然鼓勵用戶加強文檔工作，提高應用系統(tǒng)的質量，至少可以提高一次做對系統(tǒng)的概率。
應用搭建的基本技能我們已經在本書的其他章節(jié)詳細介紹，本案例章節(jié)呈現一個根據藍圖而搭建的應用實現面貌。
在這個明道云實施專家搭建的應用中，將不同業(yè)務環(huán)節(jié)分組（頂部菜單），在每個業(yè)務分組下建立對應的工作表。比如，如圖產品管理分組下就建立了系列（分類），產品，產品明細和產品配方這四個對象。
架構分析的第一步就是角色列表，可以將這些角色通過應用平臺配置為自定義角色，并根據數據接觸需要分別給他們賦權。
在明道云應用平臺中，工作流是由觸發(fā)器和一系列動作節(jié)點構成的。只要觸發(fā)器滿足條件，就會自動執(zhí)行所有的動作節(jié)點。在本案例中，有諸多環(huán)節(jié)均需要由特定角色觸發(fā)工作流程，例如生成加工單。這個工作流可以通過一個按鈕觸發(fā)，然后通過數據操作相關的節(jié)點，將訂單中的數據轉移到加工單上。下圖是整個系統(tǒng)所配置的工作流。
圍繞管理角色所需要的統(tǒng)計數據，應用平臺可以通過自定義頁面上插入統(tǒng)計組件，再將頁面分發(fā)給不同的角色。例如本例中就創(chuàng)建多個“駕駛艙頁面”，不同職能角色看到的頁面組合可以是不一樣的。
命題作業(yè)已經基本完成，我們可以借助架構工作的價值，進一步探索數字化運營的機會。反過來來說，如果我們拋去架構設計過程，直接根據需求搭建應用，就失去了看清全局的機會。創(chuàng)新不是空中樓閣，只有看到，才有更大的機會想到。架構藍圖的價值就是提供給企業(yè)主一個發(fā)想和驗證的工具。
案例只覆蓋了普渡餐飲的接單、采購、生產加工和配送環(huán)節(jié)。對于完整的企業(yè)運營來說，還有很多其他環(huán)節(jié)具備數字化升級價值，比如此例中，普渡餐飲可以把營銷拓客，銷售轉化，客服，人事考核等都加入進來。利用零代碼應用平臺的一大好處就是各個業(yè)務系統(tǒng)實際上是緊密相連的，減少了采用不同技術解決方案帶來的數據孤島問題。比如延伸客服應用時，顯然可以直接共享既有的客戶和訂單數據。明道云的工作表關聯可以跨應用實現，所以無論怎樣規(guī)劃應用組合，都是可以實現企業(yè)內的數據統(tǒng)一治理。這對企業(yè)數字化建設是一個重要價值。
在延伸業(yè)務環(huán)節(jié)的時候，一般可以從核心業(yè)務流程，或者說是企業(yè)的關鍵價值創(chuàng)造過程開始。比如本例中，普渡餐飲的價值創(chuàng)造就是為客戶加工餐飲訂單并配送的過程。在核心業(yè)務流程完善后，再向支持性職能擴展。這是我們在企業(yè)數字化建設里程碑設計中的常規(guī)考量。
在這兩種性質的業(yè)務環(huán)節(jié)中，一般只有核心價值創(chuàng)造流程才值得建立差異化競爭優(yōu)勢。比如普渡餐飲有機會利用數字化能力建立零庫存且全自動的原材料采購和配送體系，從而建立在企業(yè)餐飲服務市場的成本優(yōu)勢。而在支持性業(yè)務環(huán)節(jié)，只需要對標一般競爭者即可。數字化建設的主要精力始終應該聚焦在核心業(yè)務流上。
案例中還沒有涉及到客戶體驗相關的環(huán)節(jié)設計。這個環(huán)節(jié)對于任何企業(yè)來說都應該是有發(fā)揮和創(chuàng)造的空間。譬如普渡餐飲可以建立在線菜單，允許顧客直接自助下單，可以為客戶建立菜單收藏，提高客戶下單體驗?？蛻粝聠我院?，還可以實時跟蹤訂單處理狀態(tài)，甚至可以直接跟蹤到加工單。需要的時候給廚師長帶個話都可以。
數字化建設在顧客體驗方面的創(chuàng)新空間是無窮盡的。設計什么樣的信息系統(tǒng)，提供什么功能，一切都可以以是否能夠給客戶帶來價值和高體驗為標準。相反，我們也可以根據客戶現實的痛點逆向思維，想一想我們如何通過數字化能力來解決客戶的這些問題。比如客戶在宴會用餐的時候，不想花時間來盯著物流，那么我們就可以在進入加工步驟和交付給物流公司的時候主動推送短信通知客戶。這些就是我們常說的有溫度的 IT。
所謂自動化，就是將過去需要人員處理的工作交給程序處理，理論上，只要有可在線的業(yè)務數據，通過原生開發(fā)，總能夠實現想要的自動化場景。只是這個過程比較昂貴。它涉及到業(yè)務需求部門和軟件研發(fā)團隊的高密度溝通，需要做很多的調試和驗證工作。
零代碼應用平臺給了業(yè)務用戶一個機會自助完成這些復雜的自動化特性開發(fā)工作。準確得說，這個過程是通過可視化配置完成的，并不需要寫代碼。在本例中，普渡餐飲通過客戶的訂單內容，查詢訂單產品明細所對應的原料數量，即可自動計算出每天所需要進行的原料采購單。通過實驗和調優(yōu)，可以將原料預定數量控制得非常精確，而且不需要花費人工計算。而過去，批量餐飲生產企業(yè)都必須依賴主廚的個人經驗判斷來做決策，既不準確，也不易于內控。這個自動化設計可以成為普渡餐飲運營過程中的亮點，不僅運營效率高，而且節(jié)省了很多不必要的人力投入。
像這樣自動化的機會還很多。它們一般貫穿在各項業(yè)務活動之間，傳統(tǒng)上靠人員協作來解決。再比如，生產加工中心給物流公司下配送單也可以是全自動的，它可以根據加工單的狀態(tài)變化來自動觸發(fā)，也可以每天定時按照加工單內容批量生成配送單。
當業(yè)務運營起來以后，我們就會不斷積累出商業(yè)數據。這些數據會給企業(yè)更多的洞察機會。比如普渡餐飲可以通過客戶訂單結構分析來優(yōu)選菜品組合，通過價格敏感度測試優(yōu)化定價，通過訂單配送時間需求來優(yōu)化運營班次，幾乎任何商業(yè)數據的集合都會帶來更好的決策。
只要數據在一起，進行報表分析就不復雜，你甚至不用再投資昂貴的 BI 軟件，零代碼平臺本身就能夠制作各種基于數據表的統(tǒng)計組件，這個過程如同制作 Excel 圖表一樣簡單。
企業(yè)投資數字化建設，有一個很重要的動因就是滿足未來的規(guī)?；砷L。當業(yè)務規(guī)模不大的時候，用簡單的工具也許還能對付，例如銷售部如果只有幾名員工，那么靠 Excel 記錄和日常溝通就能夠解決銷售管理問題。但是當人員擴充到數十后，很難逃避真正意義上的數字化建設。
人員擴充只是業(yè)務擴展的一種形式。更復雜的擴展包括引入多個運營實體。例如普渡餐飲很可能需要在一個城市建立多個生產加工中心，以降低配送成本和加快配送速度；它也有可能未來走出一個城市，建立全國性運作。這時候，集中服務的數字化系統(tǒng)就發(fā)揮出了更大的效力，單位成本也會得到攤薄。建立多運營實體在 IT 上并不一定很昂貴?；谏衔奈覀兎治龅钠斩刹惋嫎I(yè)務數據架構，我們只要增加運營城市、加工中心對象，就能夠將現有的應用快速擴展為一個多站點使用的系統(tǒng)。這一切都離不開科學和有前瞻性的架構工作，它就是本章主要介紹的內容。
