本文我先為大家介紹業(yè)務中臺的設計方案。

1.1 企業(yè)架構

當我們分析完了業(yè)務線間的需求而開始進入業(yè)務中臺設計階段時，出現(xiàn)的首要問題便是要如 何設置業(yè)務中臺這一新生系統(tǒng)在企業(yè)整個信息化體系中的位置。我們都知道當下絕大多數(shù)要建設 中臺的企業(yè)都不是“一無所有”的傳統(tǒng)企業(yè)，在這些企業(yè)中除業(yè)務線的系統(tǒng)外，至少存在多套IT系 統(tǒng)，可能是辦公自動化 (OA) 系統(tǒng)，也可能是訂單管理系統(tǒng) (OMS) ，那么此時中臺要如何融入 這些系統(tǒng)？需要調用哪些系統(tǒng)的接口？又需要給哪些系統(tǒng)提供數(shù)據(jù)接口？多個系統(tǒng)之間如何建立 起新的聯(lián)動關系？這些都是中臺加入后我們必須考慮的。

面對這些問題，我們就不能再像之前的單一產品線的產品經理一樣來看待問題了，而需要將 視角轉向企業(yè)頂端——企業(yè)是怎么通盤考慮自己的業(yè)務規(guī)劃的，又是如何確定什么階段需要什么 IT系統(tǒng)的。而這其實就是我們的企業(yè)架構所思考的范疇了。

1.1.1 企業(yè)架構的定義

為了回答業(yè)務中臺設計這里遇到的問題，我們來看一看企業(yè)架構是什么東西。先讓我們回顧 以下前幾章介紹過的內容，在前面我們已經談過了企業(yè)標準化、商業(yè)模式、 目標行業(yè)分析，如果 我們把這些分散的“零件”全部組裝起來，從某種意義上我們就能得到一個標準的企業(yè)架構。

對于一個企業(yè)來說，企業(yè)架構就是一種管理業(yè)務生產各個要素之間關系的集合。通過這樣的 組合，我們能在保證利潤的前提下去生產產品以滿足特定行業(yè)細分市場的需要 (包括現(xiàn)在的需要 與未來的需要) 。為了這樣的目標，我們雇用了不同類型的人員去完成生產、研發(fā)、銷售等企業(yè) 不同環(huán)節(jié)的工作，又通過一些管理制度和信息化軟件去實現(xiàn)企業(yè)內部的管理。

所以企業(yè)架構的定義就是對一家企業(yè)的生產、銷售、市場流程、管理方式的建模。一般來

說，企業(yè)架構主要分為兩大部分：業(yè)務架構和IT架構，如圖1- 1所示。

圖1-1 企業(yè)架構總覽

(1) 業(yè)務架構

業(yè)務架構就是指我們公司的整個業(yè)務運轉模式是什么，比如我們是一家飲料生產公司，我們 是如何將水、糖等配料最終制作成一個帶有包裝并印有公司標識的飲料，并實現(xiàn)從工廠交付到用 戶手中的整個流程的。

具體來說，業(yè)務架構包含運營模式、組織結構、生產流程等內容，而在這里就是在前面幾章 所介紹的企業(yè)標準化與企業(yè)商業(yè)模式的內容。

(2) IT架構

在開頭我已經說過當下任何一個企業(yè)都已經無法和信息化脫離，企業(yè)內部或多或少都有若干 套信息化系統(tǒng)去幫助企業(yè)管理運營和生產流程。所以IT架構就是指面對企業(yè)的業(yè)務架構，我們要 如何聯(lián)合這些信息化系統(tǒng)建立起一套標準的系統(tǒng)群去幫助企業(yè)實現(xiàn)更高效的內部管理運營，幫助 企業(yè)更好地進行生產、銷售、運營等活動。

所以對IT架構，我們可以理解為企業(yè)用于建立企業(yè)信息系統(tǒng)的施工圖紙。這里IT架構由數(shù)據(jù) 架構、應用架構和技術架構3部分組成，通俗理解就是對應公司中的業(yè)務數(shù)據(jù)、前臺產品與代碼。

1.1.2 企業(yè)架構的作用

在企業(yè)剛剛誕生的時候整個組織規(guī)模還很小，但由于企業(yè)經營范圍也很窄，所以此時我們不 需要設計系統(tǒng)與系統(tǒng)間的協(xié)同配合就能梳理整個企業(yè)的戰(zhàn)略與市場經營方式，這其中最關鍵的就 是因為整個企業(yè)可能就只有一到兩個業(yè)務系統(tǒng)。因此所有的企業(yè)決策與管理只需要由老板在自己 頭腦中思考便可以輕易決定。

但是隨著企業(yè)的不斷發(fā)展，公司內慢慢地出現(xiàn)了數(shù)十個部門、若干個事業(yè)部，任何一個工作 都變成了若干個部門相互配合才能完成，此時我們就需要一個架構來統(tǒng)一協(xié)調與管理各個部門之 間的配合，從而在我們進行決策的時候能有依據(jù)，這就是企業(yè)架構的核心作用。

讓我們再拆分得細一點來看：

作用1：創(chuàng)新。企業(yè)架構幫助我們梳理了企業(yè)內部的業(yè)務流程與目前整體業(yè)務的信息 化程度，從而使我們可以輕松掌握公司內全局資源的分布，來幫助快速實現(xiàn)業(yè)務推 進。

作用2：提效。經過設計的企業(yè)架構能打通各業(yè)務單元邊界，使得部門間的流程可以充 分融合。

作用3：降本。在系統(tǒng)增減決策中，參照企業(yè)架構可以避免系統(tǒng)的重復性開發(fā)，從而充 分利用現(xiàn)有系統(tǒng)資源。

1.1.3 企業(yè)架構與中臺

講明白了企業(yè)架構的定義與作用后再看我們一直所談的中臺，本質上我們新建的中臺屬于企 業(yè)架構中IT架構層面的產物，之前劃分出的數(shù)據(jù)中臺、業(yè)務中臺與技術中臺對應企業(yè)架構里IT架 構部分的數(shù)據(jù)架構、應用架構與技術架構，如圖1-2所示。

圖1-2 中臺加入后的IT架構

因此，我們可以說中臺系統(tǒng)在企業(yè)信息化中是承接前臺應用與底層系統(tǒng)的重要橋梁，它的定 位就是幫助前臺業(yè)務封裝底層系統(tǒng)接口并形成一個中間層。

1.2業(yè)務中臺建設的啟動

1.2.1建設模式選擇

在現(xiàn)有的公司啟動中臺建設就像建造航母一樣，第一步是選擇中臺的項目組裝模式，也就是 選擇是要在某一家造船廠讓一群工人一 口氣建造完一艘航母，還是將航母分割為多個模塊交由不 同的造船廠分開建造，而在這里只進行最后的拼接。也就是說，在中臺建設時，我們是選擇完整 式建設，還是選擇分布替換式建設。

分布替換式建設：是指我們對業(yè)務系統(tǒng)內的模塊一次一個地進行改造重建，最終將所 有綜合架構實現(xiàn)中臺化。這種建設模式的好處是可以不斷根據(jù)業(yè)務需要進行抽象， 而壞處也是顯而易見的，就是整個業(yè)務中臺完成建設的周期將比較長。而現(xiàn)在很多 啟動中臺建設的公司一般都選擇了這種模式。

完整式建設：就是指從企業(yè)中單獨開始建設業(yè)務中臺。我們先保留原有的業(yè)務系統(tǒng)并 使其正常運行，再單獨啟動一個新的項目，逐步沉淀原業(yè)務系統(tǒng)中的代碼與成熟業(yè) 務，在完成中臺建設以后，保持業(yè)務前臺不變，將中臺作為一個新系統(tǒng)嵌入原有的 IT架構，并讓原來前臺業(yè)務與后臺的接口調用關系逐步由中臺接替，來實現(xiàn)整個IT 系統(tǒng)的改造。這種模式的好處是一切從零開始建設，對于中臺研發(fā)人員來說可以快 速完成代碼實現(xiàn)而不需要去梳理其他業(yè)務代碼。不過缺點是我們需要單獨用一套系 統(tǒng)從零翻新公司的所有項目，建設成本比較高。

這兩種建設模式可以說各有利弊，大家可以根據(jù)自己的實際需要來選擇中臺建設模式，但是 要注意的是我們在開始中臺建設前就必須將其確定下來，并在建設過程中不要輕易更改。

1.2.2中臺用戶優(yōu)先級

確定了建設模式后，還需要對中臺所服務的用戶進行劃分，從而確定響應優(yōu)先級，以保證中 臺團隊可以有的放矢地進行研發(fā)。此處的“用戶”指的就是我們在用戶調研中選定的各條業(yè)務線。我 們常用的中臺用戶劃分方法是三層劃分法，也就是將各條業(yè)務線分為如圖1-3所示的層級。

圖1-3 中臺用戶劃分

通過對用戶分層，我們就可以將中臺建設過程中的需求優(yōu)先級確定下來，同時為不同類型的 用戶提供不同級別的服務與支持。

大家可能疑惑：為什么要這么做呢？要知道，在一個企業(yè)內部，不可能所有的業(yè)務線都處在 盈利的狀態(tài)，因此業(yè)務線在經過一段時間的發(fā)展后會自動衍生出不同盈利狀況的業(yè)務線。第一層 級業(yè)務線能為公司帶來大量的利潤，這也是一個公司的主力業(yè)務線，而且這里我們也稱其業(yè)務流 程是真正跑通的；而第三層級業(yè)務線則是還處于向盈虧平衡點探索的業(yè)務線，我們稱之為業(yè)務流 程還未跑通的業(yè)務線。

將業(yè)務線劃分完畢后，中臺建設團隊在面對多方同時提出的需求時，可以優(yōu)先響應與支持第 一層級業(yè)務線，在這基礎之上再去對其他業(yè)務線進行拓展，這樣就能應對在中臺建設過程中的先

后緩急。

在這兒我們可以總結一些判斷中臺需求優(yōu)先級的基本規(guī)則：

規(guī)則1：業(yè)務線優(yōu)先 。也就是根據(jù)業(yè)務線所在層級來定義優(yōu)先級，顯然來自第一層級 業(yè)務線的需求在優(yōu)先級上是高于其他兩級業(yè)務線的需求的。

規(guī)則2： 需求共性程度 。這里面包括多個細分的評估層次，如需求是不是核心流程需 求，提出需求的是否具有可擴展性，其提出的需求有多少其他業(yè)務線也需要。

1.3 業(yè)務中臺建設路徑

下面我們以一家電商公司為例來介紹如何進行業(yè)務中臺的建設。

假設你是一位電商平臺的產品經理，在按照前面幾章中的方法完成了中臺的行業(yè)分析、用戶 分析后，你向老板提出了當下本公司的中臺建設方案，老板看過后對你的中臺知識非常贊賞，便 將建設一個面向全公司的業(yè)務中臺的任務交付給你。

此時我們先來看一下整個公司的現(xiàn)狀，公司內電商業(yè)務分為多條業(yè)務線——海淘業(yè)務線、 自 營業(yè)務線與第三方商家業(yè)務線，此外有一家獨立的線下體驗中心。了解完現(xiàn)狀，我們需要將中臺 建設的目標進行細化。要想讓這3條不同的業(yè)務線都能接入中臺，那么必須在以下兩個層面完成統(tǒng) 一性的整合：

功能流程層面整合：定義三者業(yè)務的統(tǒng)一的業(yè)務模型。

業(yè)務數(shù)據(jù)層面整合：找出可以對通用模型進行業(yè)務描述的基本數(shù)據(jù)。

也就是說，我們要提出企業(yè)中經過多次優(yōu)化并由大量用戶跑通的業(yè)務流程，從而為新孵化的 業(yè)務提供復用。

也就是說，我們的目標就是將這3條電商業(yè)務線中處在第一層級業(yè)務線的模塊 (如供應鏈采 購、訂單分揀等) 提取出來。除了做上述業(yè)務，我們還可以去做直播電商，而背后用的都是已經 被資本驗證過的流程。明確了目標后，我們就可以進入中臺設計的執(zhí)行階段了。

1.3.1公司全景功能地圖

既然要整合業(yè)務線模塊，我們首要做的就是按照第9章的分析方法去繪制各條業(yè)務線內的功能 矩陣，梳理出公司內現(xiàn)有的各條業(yè)務線有哪些功能模塊。此外，在這一步，我們需要在原來的結 果上繼續(xù)匯總，得出一個由業(yè)務中臺部門來統(tǒng)一維護的公司級“產品模塊全景地圖”。

也就是將公司的各條業(yè)務線中的模塊進行統(tǒng)一匯總，查看到底每條業(yè)務線有哪些模塊，其業(yè) 務線之間的重疊情況又是怎么樣的。這也是業(yè)務中臺建設中不可或缺的一個步驟，就像大家設計 一般性垂直業(yè)務系統(tǒng)一樣，大家需要先對市場上的同類型產品做功能分析，再進行設計。而這里 對各條業(yè)務線的調研就類似于我們的產品分析。

我們根據(jù)現(xiàn)有的業(yè)務線梳理出了如表1- 1所示的電商產品模塊全景地圖，在地圖中我們以“業(yè) 務線+產品+功能”的形式完整記錄一個模塊。

表1-1電商產品模塊全景地圖

怎么樣？看到這樣的統(tǒng)計結果，大家是不是感覺有很多看著很相似的功能？沒錯，這些就是 我們要進行整合的。

除此之外，在建設中臺過程中，我們經常會遇見的一個問題就是很多時候由于各條業(yè)務線之 間的封閉，很有可能出現(xiàn)我們剛將某一業(yè)務線的業(yè)務模塊進行剝離并合并到中臺架構中后，業(yè)務 線新建的模塊又變成了重復建設。所以這個全景地圖除了具有摸清楚當前各條業(yè)務線的作用，另 一個作用就是保證在未來各條業(yè)務線中不會再出現(xiàn)重復建設。我們通過統(tǒng)計各條業(yè)務線每周新增 的模塊開發(fā)內容來不斷更新這個地圖，就可以第一時間發(fā)現(xiàn)重復的內容。

但是我們要如何應對通過這個地圖監(jiān)測到的各條業(yè)務線中正在建設的部分？又要如何決策這 些新增模塊是否要歸類到業(yè)務中臺里？ 比如說我們在某條業(yè)務線中新推出了付費會員體系，那么 我們如何判斷是否要把這一模塊進行業(yè)務中臺化呢？

此時除了判斷該模塊是否已經被跑通 (是否被市場用戶接受) ，我們還要做的就是每次當各 條業(yè)務線進行新的主模塊研發(fā)時，可以與該業(yè)務線的業(yè)務研發(fā)人員一起來看新開發(fā)的模塊與之前 的模塊之間的相似度是否超過閾值，如果超過一次閾值我們就將其記為一次預復用，也就說明這 個模塊是公司當前業(yè)務中已經監(jiān)測到重復的一個模塊。

那么問題又來了：我們要如何進行相似度對比呢？這里就需要用到一個業(yè)務模塊的相似度計 算公式，也就是通過對比兩個模塊中的通道數(shù)來計算相似度。這里的通道就是指模塊的輸入輸出 信息。

相似度=(相同輸出通道數(shù)+相同輸入通道數(shù)) /總通道數(shù)

這個公式的意思就是如果不同業(yè)務線之間的兩個模塊所需要的輸入與輸出信息都相同或大體 相似，就意味著這兩個模塊是有相似度的。

例如，我們以輸入通道統(tǒng)計，在海淘業(yè)務線與自營業(yè)務線中，訂單模塊都接收用戶所輸入的 商品SKU (庫存單位) 、商品數(shù)量、商品規(guī)格、寄貨地址、支付方式，輸出訂單狀態(tài)、支付狀態(tài)， 唯一不同的是海淘業(yè)務線在訂單輸入時會存在用戶關稅處理的相關信息。也就是說， 自營業(yè)務線 的訂單模塊共有7個通道，海淘業(yè)務線的訂單模塊共有8個通道，根據(jù)相似度公式我們可以計算 出：

相似度=(7+7) /(7+8) ≈93.3%

那么雖然這兩個模塊是分屬不同業(yè)務線的，但是我們計算出它們卻是高度相似的，可以計入 一次預復用。

所以根據(jù)這個公式，如果預復用超過兩次就有一定的必要去考慮是否可以中臺化，需要業(yè)務 中臺建設團隊將其抽取出來進行統(tǒng)一維護。

以我本人維護的業(yè)務中臺需求為例，經過一段時間的維護就得出了一份統(tǒng)計表，如表1-2所 示。

表1-2業(yè)務中臺需求統(tǒng)計表

有了這張表，我們就可以按照預復用次數(shù)的多少進行排序，次數(shù)越多就代表著其優(yōu)先級與重 要程度越高，就可以讓我們的業(yè)務中臺部門進行優(yōu)先開發(fā)。通過這個方法，我們也可以規(guī)范業(yè)務 線的自主開發(fā)內容，避免出現(xiàn)中臺建設中業(yè)務線內部另起爐灶的現(xiàn)象。

1.3.2 核心業(yè)務流程抽象

接下來擺在我們面前的問題就是如何根據(jù)現(xiàn)有業(yè)務建設一個通用模型，以便可以支持不同的

前臺。像我們這里一共有3條不同的業(yè)務線，那么到底哪些功能才是這三者通用的呢？

建設通用模型之前，我們要先將第9章中遺留的一個問題解答了。大家還記得在第9章的打車 業(yè)務線案例中我們利用動作分析法確定了每條業(yè)務線具體的標準流程，找到了該業(yè)務線內的公共 需求模塊。那么對于這么多的公共模塊能力，我們是否都需要放入業(yè)務中臺呢？

答案是否定的，通用模型的建設在本質上是建設起全公司業(yè)務的一個通用流程，而不是簡單 地將業(yè)務線中的公共需求模塊進行堆砌，也只有這樣才能讓中臺的能力邊界可控。

所以通用模型的建設方法就是從企業(yè)的業(yè)務出發(fā)去設計一個大體的模塊框架，其承載的是我 們的核心業(yè)務流程。就像面對一棵大樹一樣，業(yè)務中臺負責的只是整個軀干的維護，而具體的枝 葉由各條業(yè)務線完成。

例如，在資訊平臺中，業(yè)務中臺定義出了一個完整的從內容中心編輯內容再分發(fā)給不同業(yè)務 線的不同業(yè)務模塊的基本流程，而具體的內容展示時到底采用如圖1-4所示的哪種形式就不需要業(yè) 務中臺去管理了，而是由前臺業(yè)務線去自己定義維護，業(yè)務中臺只負責提供數(shù)據(jù)。

圖1-4 兩種數(shù)據(jù)展示交互形式

所以接下來我們需要做的是以用戶視角找到公司不同業(yè)務的使用流程，這里和第6章中我們找 尋一般業(yè)務流程不同的是，我們要聚焦于企業(yè)內部，了解用戶是怎么使用我們的產品的。此時就 要對現(xiàn)有的3條業(yè)務線依次進行任務程序化、業(yè)務線子流程定義，接著在這些分析結果的基礎上整 合出一個通用業(yè)務流程。

具體來看，在案例里，因為我們是一家電商公司，所以我們根本的用戶流程就是：用戶如何 找到自己想要的商品并完成下單 。進一步細化下，我們就可以得出這里的兩個任務步驟：

根據(jù)第9章我們學習的動作分析法來梳理各條業(yè)務線的功能流程：梳理自營業(yè)務線的下 單購物流程；梳理第三方商家業(yè)務線的下單購物流程；梳理海淘業(yè)務線的下單購物 流程。并將各個模塊拆分為動作，比如將購物車、商品查找拆分為對應的動作。

將3條業(yè)務線的分析結果進行合并，得到最終的業(yè)務通用模型。

根據(jù)上一任務步驟的產出，經過整理我們可以將一般的電商平臺內購物流程定義出7個關鍵節(jié)

點，如圖1-5所示。

圖1-5 核心流程

對這個核心流程中的環(huán)節(jié)進行歸類時我們可以發(fā)現(xiàn)，這7個節(jié)點可以聚合為3件事，分別是商 品查找 (售前) 、購買決策 (售中) 和售后管理 (售后) ，此時我們再將從上一任務步驟中拆分 出的各個動作填充到這一核心流程，就得到一份完整的公司級核心流程地圖，如圖1-6所示。

接下來根據(jù)上面分析的業(yè)務流程，我們可以把商品查找、購買決策和售后管理這3個流程中的 功能細分下來，得到標準業(yè)務框架，如圖1-7所示。

圖1-6 公司級核心流程地圖

圖1-7 標準業(yè)務框架

這樣我們就成功將3條業(yè)務線的通用模型建立起來了，我們可以看到雖然3條業(yè)務線各自業(yè)務 不同，但是在剝去那些枝葉后整個業(yè)務框架都是圖中的這一套。

依據(jù)這個模型，我們可以梳理出4個我們公司中的核心能力，分別為用戶中心、商品中心、交 易中心、客服中心，具體功能說明如下：

用戶中心：需要承接前臺不同業(yè)務線中應用的用戶注冊信息，同時對于公司中存在面 向B端商家的開放平臺業(yè)務特點，我們還需要在用戶中心加入商家信息管理的子模 塊，提供商家注冊和信息完善服務；為整個公司提供統(tǒng)一的認證服務，提供多種方 式的驗證，也為各條業(yè)務線中的用戶提供在公司層面的通用唯一標識符 (UUID) ， 從而使整個公司都可以識別出該用戶。

商品中心：接收來自倉庫、供應商、采購系統(tǒng)的商品信息；提供商品基本介紹信息錄 入，此外提供品牌創(chuàng)建、SKU編輯等商品標識維度添加管理功能；為訂單發(fā)貨、商品 庫存管理提供數(shù)據(jù)回傳。

交易中心：實時處理來自倉儲管理系統(tǒng) (WMS) 的庫存信息，以便完成商品訂單的生 成等業(yè)務活動；在訂單生成后根據(jù)訂單中的商品需求數(shù)量向WMS發(fā)出發(fā)貨指令。

客服中心：通過對平臺中的用戶進行電話回訪等方式實現(xiàn)運營推廣；管理用戶售后需 求，監(jiān)控用戶反饋進度；處理部分自營業(yè)務的售前服務，承接用戶商品咨詢服務。

其中我們可以進一步將這些核心能力拆分為公共模塊與功能點，得到1.0能力開發(fā)大綱，如表 1-3所示。

表1-3 1.0能力開發(fā)大綱

續(xù)表

1.3.3 企業(yè)級數(shù)據(jù)模型搭建

完成了功能流程級的整合，業(yè)務中臺終于有了個雛形了。但是當我們信心滿滿地將這個1.0能 力開發(fā)大綱拿給各條業(yè)務線的產品主管評估完后，得到了一致的反饋：我們的業(yè)務要怎么和你的 中臺掛鉤呢？

海淘產品線負責人說：“用戶的海淘訂單信息與現(xiàn)有的訂單格式不符。”

開放平臺線負責人說：“第三方商家入駐要涉及新的商家信息管理?！?面對這些聲音，下一步我們要做的就是在數(shù)據(jù)層面上讓各條業(yè)務線能接入中臺。

實際上這里就是要開始進行企業(yè)級數(shù)據(jù)模型 (Enterprise Data Modeling) 的搭建了。所謂企業(yè) 級數(shù)據(jù)模型，是一個企業(yè)中的業(yè)務規(guī)則以及信息管理，也就是說我們的一個完整業(yè)務 (如下單流 程、配送流程) 可以被描述成需要用戶輸入哪些信息、確認哪些信息，并在什么樣的信息篩選情 況下，可以讓用戶完成一次業(yè)務活動。值得注意的是，這里和之前的不同，是不再以模塊來看， 而是看整個流程中用戶的所有輸入、輸出信息。

就以我們的自營電商產品線來說，當用戶需要購買一個商品時，此時需要獲取商品名稱、規(guī) 格、數(shù)量、收貨信息，確認用戶付款，并在有庫存的情況下完成。

那么提起數(shù)據(jù)模型的設計，有過一定計算機學科背景的同學可能就想起要去繪制實體-聯(lián)系圖 (E-R圖) ，并試圖在中臺這里通過對業(yè)務對象的劃分梳理出實體間的關系，從而去設計業(yè)務中臺 的數(shù)據(jù)模型。

但是實際上在中臺設計里，繪制E-R圖就顯得有點力不從心了，因為E-R圖這個工具只是面向 單個系統(tǒng)構建的，它只能去描述一個不重復的領域內的實體關系，而隨著業(yè)務線的增多，我們的 實體間肯定會發(fā)生沖突，例如出現(xiàn)多個重復的商品實體。

所以我們在設計企業(yè)級的數(shù)據(jù)模型時，就要橫向去分析公司內所有的業(yè)務發(fā)展情況，這里我 們要先依據(jù)第7章的方法去梳理出標準業(yè)務。

接下來我們就將看似不同類型的業(yè)務場景抽象出一個通用的數(shù)據(jù)描述。我們要去尋找海淘業(yè) 務線、 自營業(yè)務線、第三方商家業(yè)務線這三者中有沒有一個數(shù)據(jù)模型可以進行統(tǒng)一描述。

首先，我們需要將每一個業(yè)務中各自調用所涉及的實體找出來。我們以產品實體為例，將當 下這3條業(yè)務線中不同定義的不同類型的產品 (也就是數(shù)據(jù)庫中存儲的字段) 進行梳理，得到如表 1-4所示的結果。

表1-4 各業(yè)務線實體調用

收集完不同業(yè)務線的實體之后，我們便可以將其進行統(tǒng)一歸類以便形成統(tǒng)一的對象。

有關抽象的方法，我們可以采取向下兼容，也就是將每個實體所涉及的字段與調用操作去重 后全部放入抽象出的對象。

這里我們首先以自營產品存儲字段為基礎，再對比海外產品、第三方商家產品的存儲字段， 找出不同的字段，如這兩種中新增了稅費、備案價、第三方商家等字段，將這些字段全部放入新 對象，我們將這三者抽象成為新的統(tǒng)一對象——商品。

在很多時候我們還會遇到多個不同的事件對同一個數(shù)據(jù)實體在不同的場景下進行訪問的情 況。例如在自營業(yè)務線中，用戶第一次進入系統(tǒng)時我們會要求用戶進行注冊，并填寫手機號、用 戶昵稱、收貨地址等關鍵信息。此時我們會在數(shù)據(jù)庫中為該用戶創(chuàng)建一個對象的實例，如用戶 01 。注意：此時的業(yè)務場景是新用戶注冊。而當該用戶下單購物時可能用戶填寫的聯(lián)系方式與聯(lián) 系地址會發(fā)生改變，此時我們需要更新用戶的信息，雖然此時的場景是下單購物場景，但是在這 兩個場景中我們訪問的是同一個數(shù)據(jù)實體——用戶對象。

而由于這兩個操作在同一條業(yè)務線內，所以我們能保證對同一個對象實例 (用戶01) 進行數(shù) 據(jù)更新，但如果我們再對海淘業(yè)務線與第三方商家業(yè)務線進行分析，我們可以找到很多對同類用 戶的操作，如海淘中的用戶地址變更。在以往過程中，由于我們將海淘業(yè)務線的用戶與自營業(yè)務 線的用戶在對象數(shù)據(jù)上相分離，因此每個業(yè)務系統(tǒng)都會擁有一份用戶01的個人信息數(shù)據(jù)，結果不 僅是重復，最重要的是還會出現(xiàn)用戶數(shù)據(jù)不一致的情況。

所以在數(shù)據(jù)模型的搭建中我們就需要找到各條業(yè)務線中的重復操作與重復對象，并將不同業(yè) 務線中同一事件與實體之間的讀寫操作進行統(tǒng)一，例如為我們現(xiàn)有的3條業(yè)務線定義統(tǒng)一的用戶注 冊事件、用戶地址修改事件等。

而對于相同的數(shù)據(jù)集，如這里用戶01的個人信息，我們在企業(yè)數(shù)據(jù)建模過程中可以將此類對 象聚集到同一個主題領域下，比如與訂單相關的數(shù)據(jù)歸類為訂單主題域，與用戶相關的數(shù)據(jù)歸類 到用戶主題域。那么從企業(yè)的角度來說，這些領域中的數(shù)據(jù)就成為我們的公共數(shù)據(jù)。

通過這個辦法我們就可以將企業(yè)的數(shù)據(jù)模型涉及的數(shù)據(jù)對象定義出來了，此時也就可以解決 我們在第2章中提出的數(shù)據(jù)庫中可能有不同的字段名稱的問題了。

了解了這里的方法論后，我們將目光轉向自己的公司，看看要怎么實踐。我們發(fā)現(xiàn)，無論從 自營平臺還是從其他的兩個平臺，我們都可以將這三者中的數(shù)據(jù)對象抽離出來，其集合如圖1-8所 示。

圖1-8 數(shù)據(jù)對象集合

再下一步我們要做的就是搞清楚在日常業(yè)務中這些對象都是怎么聯(lián)系身邊的其他對象的，例 如訂單的數(shù)據(jù)會流過商品 (商品SKU、規(guī)格、商品數(shù)量、商品圖片、所屬商家) 、交易 (價格、優(yōu) 惠) 兩個對象，在經過這些對象加工后，這些數(shù)據(jù)的次級流向會經過物流 (商品派送情況) 與財 務 (收款信息) 兩個對象。

我們把這些對象之間的數(shù)據(jù)通路整理出來后，就可以穿越不同前臺業(yè)務線的迷霧找到藏在功 能真正核心的數(shù)據(jù)變化，在這兒我們將分析結果用網(wǎng)狀圖 (見圖1-9) 來表示。

圖1-9 數(shù)據(jù)對象通信圖

我們從圖中可以發(fā)現(xiàn)，雖然現(xiàn)在3條業(yè)務線的功能流程各不同，但是它們在數(shù)據(jù)流向上是統(tǒng)一的，例如海淘業(yè)務線與自營業(yè)務線都可以將用戶訂單產生的數(shù)據(jù)交互定義到商品、交易、事件 中。

繼續(xù)在這個數(shù)據(jù)對象通信圖上進行整理，我們將各個對象主體之間在訪問時需要傳遞的數(shù)據(jù) 匯總一下，就得出了一個完整的企業(yè)級數(shù)據(jù)模型，如圖1- 1所示。

圖1-1 完整的企業(yè)級數(shù)據(jù)模型

進一步將這里的數(shù)據(jù)模型與之前標準業(yè)務模型拆解結果合并，就可以得出業(yè)務活動的本質就是：在什么樣的場景下開始執(zhí)行任務 (事件) ，模塊需要哪些數(shù)據(jù) (實體) ，依據(jù)什么樣的順 序、規(guī)則進行處理，處理之后與哪些對象 (實體) 產生聯(lián)系并產生了哪些數(shù)據(jù)。

各條業(yè)務線的負責人看完了你的設計方案，又提出了一個尖銳的問題：海淘商品信息在存儲 方面與自營商品信息不一樣，就算數(shù)據(jù)通路相同了，流過的數(shù)據(jù)內容不同，這里不是沒辦法統(tǒng)一 存儲嗎？面對這個難題，就輪到下面我們要介紹的業(yè)務中臺中間件發(fā)揮作用了。

1.3.4 業(yè)務中臺中間件研發(fā)

定義完企業(yè)級數(shù)據(jù)模型后，我們就應該進行業(yè)務中臺中間件的研發(fā)了。從概念上說，中間件 就是一個公用模塊，能供不同的前臺調用，例如公用會員管理，它在功能上和業(yè)務線中的會員管 理沒有什么區(qū)別，只是中臺研發(fā)可以讓不同業(yè)務線接入，業(yè)務線中不需要再單獨開發(fā)，同時也為 后面的數(shù)據(jù)中臺建設提前將各業(yè)務數(shù)據(jù)匯聚到一起。

而為了使不同的業(yè)務線都能使用這個模塊，我們要做的中間件研發(fā)的核心就是進行字段的剝 離。我們將原來前端業(yè)務線中的數(shù)據(jù)存儲拆分為兩部分：

數(shù)據(jù)存儲=通用數(shù)據(jù) (中臺) +業(yè)務數(shù)據(jù) (前臺)

所謂通用數(shù)據(jù)，就是指能客觀描述對象的一個字段，也就是現(xiàn)實世界中能唯一確定這個個體 的數(shù)據(jù)，例如會員模塊的通用數(shù)據(jù)為用戶姓名、身份證號、手機號、用戶性別、ID 、年齡等。

而業(yè)務數(shù)據(jù)是指在各個前臺里根據(jù)具體場景里的特殊化需求所定義的字段，如用戶昵稱、用 戶在本業(yè)務中的會員等級等。

在完成這樣的數(shù)據(jù)分割之后，我們就可以將每次訪問系統(tǒng)產生的數(shù)據(jù)分為兩部分，將通用數(shù) 據(jù)存儲在中臺，而將個性化的業(yè)務數(shù)據(jù)依舊存儲在前臺，形成數(shù)據(jù)分離存儲的模式。

像這里，我們開放平臺中的商戶可以為自己的會員用戶定義會員等級，這一業(yè)務場景在業(yè)務 中臺最終落地的方案如圖1- 11所示。

圖1-11 數(shù)據(jù)分離式存儲結構

這個時候對于前臺業(yè)務來說，當我們需要開發(fā)會員模塊時，只需要接入中臺的會員模塊，并 在中臺的會員模塊數(shù)據(jù)基礎上去根據(jù)自己的業(yè)務擴充數(shù)據(jù)字段。這樣既可以享受中臺會員模塊所 現(xiàn)有的功能，如會員新增、刪除、修改，又可以通過存儲在前臺業(yè)務線中的會員業(yè)務數(shù)據(jù)實現(xiàn)在 當前場景下的會員特殊功能，這就是中間件的設計核心。

接下來我們就需要批量對原業(yè)務中的模塊調用關系進行梳理，來規(guī)劃出前臺業(yè)務線與原后臺 的調用關系業(yè)務流，例如在自營業(yè)務線中我們是在什么場景中調用會員中心數(shù)據(jù)的，將原業(yè)務線 中內部自研的會員中心服務切換到業(yè)務中臺的會員中心。

我們對現(xiàn)有的3條業(yè)務線進行分析便能得出如圖1- 12所示的分析結果。

圖1-12 基于中臺的業(yè)務數(shù)據(jù)流

在有了調用業(yè)務流后，我們進行前臺模塊重構。此時按照如下兩個原則：

將公共字段統(tǒng)一匯總至中臺。

前臺業(yè)務只留存?zhèn)€性化部分。

此時完成前臺模塊的輸入、輸出重新分離后，我們就得到了一個中臺中間件，就可以開始讓 前臺業(yè)務線通過這個中間件接入業(yè)務中臺了。

1.3.5 對接后臺業(yè)務系統(tǒng)

到目前為止我們已經將中臺的服務體系設計完畢了，我們要處理的最后一大項任務就是如何 讓中臺與原有的后臺系統(tǒng)進行對接。

先看一下我們現(xiàn)有公司中所有后臺系統(tǒng)，在這里一共存在兩款后臺系統(tǒng)：

企業(yè)資源計劃 (Enterprise Resource Planning ，ERP) 系統(tǒng)：負責采購計劃的生成、對應 財務信息錄入等采購計劃管理。

倉儲管理系統(tǒng) (Warehouse Management System ，WMS) ：負責采購后的產品出入庫管 理，以及分揀、打包、發(fā)貨等一系列發(fā)貨流程管理。

此時我們第一步需要挨個梳理這些后臺系統(tǒng)與原先業(yè)務系統(tǒng)的調用關系是什么。在這兒我們 看一下沒有中臺前的原系統(tǒng)業(yè)務流程：

在ERP系統(tǒng)中，創(chuàng)建采購計劃，根據(jù)填寫的采購商品名稱、規(guī)格、數(shù)量等生成采購 單。

在WMS中，商品入庫并生成入庫單 (并分為3類商品：海淘、 自營、第三方商家) ， 關聯(lián)采購單，進行逐一入庫項驗證。

在海淘電商中，讀取庫存上架產品，接受用戶訂單，訂單狀態(tài)流轉。

在自營電商中，讀取庫存上架產品，接受用戶訂單，訂單狀態(tài)流轉。

在第三方商城中，讀取庫存上架產品，接受用戶訂單，訂單狀態(tài)流轉。

在WMS中，接到出庫指令，關聯(lián)業(yè)務方記錄對應類別商品的庫存出庫動作，包裝與出 庫，并交付第三方快遞公司。

可以看出這里的3個業(yè)務前臺都直接與后臺系統(tǒng)關聯(lián)，結果就是典型的底層系統(tǒng)既要處理繁雜 的業(yè)務流程又要去管理與前臺業(yè)務的對接 (如庫存還需要由庫存系統(tǒng)按業(yè)務方進行分類) ，導致 后臺系統(tǒng)更顯得笨重。

因此我們的第二步就是將原來參與前臺調用的數(shù)據(jù)通路轉接至業(yè)務中臺上，由業(yè)務中臺實現(xiàn) 前后臺對接。我們來看中臺接入后的新調用關系，如圖1- 13所示。

圖1-13 新調用關系

通過這樣的方式我們就將業(yè)務中臺成功插入了前后臺之間，并在這兩者之間建立起了一個封 裝層，使得后臺無論有什么變動都不會影響到前臺業(yè)務；同時也讓后臺系統(tǒng)不再管理具體業(yè)務， 例如對于后臺WMS來說，不用再將商品區(qū)分業(yè)務方，它要做的就是忠實地記錄商品進出庫，無論 是海淘還是自營的商品，對WMS來說都只是一個SKU，而將商品歸屬業(yè)務方的需求交由中臺進 行。

這樣后臺只負責處理底層邏輯，砍掉了多余的業(yè)務關聯(lián)。假設我們下一步還要新開一條業(yè)務

線，就完全不需要再讓底層系統(tǒng)進行修改商品歸屬等一系列“傷筋動骨”的操作了。

1.3.6業(yè)務中臺的最終架構

在上一步我們就得出了建設完成后的業(yè)務中臺與前臺的交互模式，由業(yè)務中臺負責去提供核 心流程的處理，并將具體的業(yè)務數(shù)據(jù)與處理結果返回給前臺，由前臺業(yè)務線負責具體展示形式。

在案例中，我們將整體業(yè)務中臺系統(tǒng)定義為用戶中心、商品中心、交易中心、支付中心、客

服中心這幾個大的通用模塊，以此得出了如圖1- 14所示的最終版業(yè)務中臺架構。

圖1-14 最終版業(yè)務中臺架構

為了方便前臺業(yè)務線使用中臺的服務，我們將中臺提供能力的方式封裝為以下3種：

方式1：H5接入。我們將一些接口封裝為帶有具體頁面的形式，此時前臺只需要調用 H5就能完成接入，前臺App組成混合式開發(fā)。

方式2：應用程序編程接口 (API) 接入。我們提供接口將相應的數(shù)據(jù)直接傳輸給前臺 業(yè)務，讓前臺進行二次開發(fā)。

方式3：SDK接入。對于一些要求體驗高的場景，我們可以使用App的原生語言去開發(fā)

一些組件，方便前臺直接使用，不過唯一的缺點就是這種方式的迭代要求前臺業(yè)務 部門隨中臺同時升級，大家要注意一下。

這里為了幫助大家更好地去進行需求分析，我還總結了業(yè)務中臺建設中一些常見的通用模

塊，如表1-5所示，方便大家在規(guī)劃業(yè)務中臺時進行參考。

表1-5中臺通用模塊范圍表

1.3.7業(yè)務中臺需求管理

前面通過一番折騰我們整理出了很多業(yè)務中臺的需求，面對這些需求我們需要一個標準的需 求管理工具幫助我們進行分析管理，具體可以按圖1- 15所示的3個處理步驟進行。

圖1-15 業(yè)務中臺需求處理步驟

也就是說，一開始我們從各條業(yè)務線分析、采集到的需求都屬于原始的需求，我們需要先統(tǒng) 一將其放入候選需求池中管理，接下來我們需要經過一定的處理將其變?yōu)槲覀兣牌陂_發(fā)的需求。

大家先來想一個問題：當我們需要精準設計一個中臺需求的時候，需要指出這個需求的哪幾 個關鍵要素？

具體來說是這兩個要素：

1）對象。在中臺需求設計中切記我們不能脫離需求對象，因為很多時候中臺的需求都是 為從不同業(yè)務線提煉出的通用角色而設計的，如果我們無法精確定位需求對象，做 出來的功能就很難在不同業(yè)務線進行復用。

2）場景。明確該業(yè)務的使用范圍，從而在中臺建設時能清楚定義需求服務提供的能力邊 界。

這就是我們將需求轉換為可開發(fā)的需求的關鍵，我們要去找到這兩個關鍵點。

讓我們來看一個案例。表1-6中羅列的需求是我們在對倉儲物流業(yè)務線進行訪談后收到的原始

需求。

表1-6 需求收集表

像這樣的需求就是一個非常典型的業(yè)務中臺原始需求，這里先給大家簡單解釋一下“拆單”是什 么。拆單，顧名思義，就是在我們下單后，為了方便倉庫發(fā)貨與結算，后臺需要對訂單根據(jù)不同 的類型進行拆分。

雖然拆單功能在WMS中是非常常見的功能，但是這里的需求對于我們產品經理來說在表述上 是非常不明確的。例如，我們?yōu)槭裁匆饐?？在哪些場景進行拆單？拆單過程中訂單的所屬角色 有哪幾個類型？

對此我們可以將這個需求根據(jù)兩個關鍵要素的描述細分為表1-7中的這幾個詳細需求。

表1-7 需求拆分

到這兒可以看到，通過這幾個要素的提煉就可以將一個抽象的需求拆分為具體的、可讓開發(fā) 人員讀懂的標準需求了。

在通過上面的方法將用戶的原始需求轉換為可開發(fā)的標準需求之后，接下來我們要做的就和 正常需求價值評估一樣，評估該需求是否值得我們投入資源去開發(fā)，以及能帶來多少回報。

介紹完了需求分析的方法，在這兒我為大家補充幾個在業(yè)務中臺需求管理中經常用到的技 巧。

技巧1：業(yè)務中臺需求鑒別

這兒還有一個業(yè)務中臺需求收集的經驗之談：面對如下兩類需求，我們產品經理應該堅決地 砍掉，不應該進行受理。

影響業(yè)務中臺定位的需求。每個業(yè)務中臺的建設都是為了幫助企業(yè)適應市場的競爭， 并形成自己的差異性定位。對于業(yè)務線中一些非常個性化的流程需求，當其明顯與 業(yè)務中臺的核心定位相沖突 (服務整個公司) 時，我們要非常謹慎地進行思考，避 免需求影響到業(yè)務中臺的核心。我們可以將這些個性化需求放到具體的項目中去實 現(xiàn)，而非在通用的業(yè)務中臺版本去實現(xiàn)。

影響用戶體驗的需求。有時候我們設計的功能可能為整個系統(tǒng)的性能及效率帶來一定 的提升，但是如果這些需求依賴著非常高的用戶學習成本，也就是說假設我們將系 統(tǒng)的性能提高了5個百分點，而給用戶帶來的學習成本與操作體驗的難度提升了1個 百分點，此時我們應該放棄這樣的系統(tǒng)需求，因為我們的產品所服務的是真正的用 戶，而非系統(tǒng)人員。

技巧2：版本迭代計劃安排

中臺作為一個公司級的基礎服務要注重穩(wěn)定性，不能發(fā)布過于頻繁。因此，對于早期功能重 構類的版本，為了能快速試錯，可以適當提高發(fā)布頻率；而在中臺功能穩(wěn)定后，我們需要考慮全 公司的業(yè)務穩(wěn)定性，此時需要盡可能在一個版本中上線多個功能，從而降低發(fā)布頻率。

我個人在處理中臺版本迭代時，在早期每兩周發(fā)布一個小版本，在中后期穩(wěn)定時每個月發(fā)布 一個大的版本。

1.3.8業(yè)務中臺路線圖

關于業(yè)務中臺的版本規(guī)劃，我們初步劃分出3個版本，劃分依據(jù)如下：

1.0版本以公司的主流程為主同時對無法人工代替的需求進行研發(fā)。

2.0版本對各條業(yè)務線的主流程外的系統(tǒng)對接類需求進行研發(fā)。

3.0版本對保障中臺運維與防止業(yè)務出現(xiàn)風險的安保類需求進行研發(fā)。 根據(jù)我們的現(xiàn)有建設大綱，可以得到業(yè)務中臺的完整路線圖，如圖1- 16所示。

圖1-16 業(yè)務中臺的完整路線圖

依據(jù)這份路線圖，我們將中臺的接入也分為3個階段：階段一為流程驗證期，階段二為全面接 入期，階段三為運行迭代期。各個階段的主要工作：

階段一 ：此時我們以跑通整個中臺流程為主，并尋找一到兩條業(yè)務線作為我們的試 點種子用戶，將中臺部分模塊與前臺業(yè)務進行嘗試性對接，在運行中檢驗我們的系 統(tǒng)所存在的問題并及時優(yōu)化。

階段二： 業(yè)務方批量接入，中臺開始正式接入公司內全部的存量系統(tǒng)，隨著接入業(yè)務 前臺的數(shù)量增加，中臺的能力復用設計目標正式被實現(xiàn)。

階段三： 此時的中臺已經是一個比較穩(wěn)定的系統(tǒng)了，我們要做的是對系統(tǒng)的各個組件 繼續(xù)進行迭代優(yōu)化，提高前臺業(yè)務接入的效率，同時為后期新業(yè)務增長進行能力準備

1.4 業(yè)務中臺建設KPI

既然要去建設業(yè)務中臺，我們就一定要有對應的指標去考核業(yè)務中臺建設的成功與否，為此 我專門幫大家總結了下面的幾類指標去考核業(yè)務中臺對企業(yè)所起到的作用，我們將這些指標稱之 為效果驗證性指標。具體來說，業(yè)務中臺的效果驗證性指標包含兩個指標：模塊復用率與業(yè)務開 發(fā)TTM。

1.4.1指標1：模塊復用率

模塊復用率的計算是用業(yè)務中臺的各個模塊被各條業(yè)務線所使用的次數(shù)除以業(yè)務中臺各模塊 總使用次數(shù)。舉例來看，這是我在2018年建設業(yè)務中臺時各條業(yè)務線的復用次數(shù)，如表1-8所示。

表1-8業(yè)務線復用次數(shù)統(tǒng)計

我們來統(tǒng)計下這3個模塊的復用率：57% 、7% 、36% 。在這兒可以很明顯地看到第二個模 塊“多賬戶綁定管理”的模塊復用率非常低，只有7% ，說明這個模塊復用價值不高，完全可以放到 對應的業(yè)務線中去單獨維護。最后，這個模塊被我們放回了對應的業(yè)務線，業(yè)務中臺團隊不再對 其進行維護。

1.4.2指標2：業(yè)務開發(fā)TTM

在第2章我們也提到了TTM (Time to Market) ，一般指產品上市周期。而在這里我們可以衍生 一下TTM的定義：一個軟件模塊從立項研發(fā)到最終上線所需要的時間。

大家也知道，我們建設中臺就是為了縮短前臺業(yè)務研發(fā)所用的時間，所以要衡量中臺的作

用，就可以看在企業(yè)業(yè)務中臺建設完成后，前臺業(yè)務線再開發(fā)對應模塊時TTM縮短了多少。

這里的核心計算公式：

原模塊研發(fā)所用人日-業(yè)務中臺化研發(fā)該模塊人日=節(jié)省的人日

前面我們不斷強調業(yè)務中臺的本質就是提供給各條業(yè)務線的共享服務，那么也就意味著任意 一個服務一旦進行業(yè)務中臺化后，被提供給至少一個前端使用時，節(jié)省成本的作用就發(fā)揮出來

了，而被越多的前臺業(yè)務接入則整體節(jié)省的成本越多。當然它為我們節(jié)省的就是各產品線為重復 建設所付出的成本。

所以我們將上面的TTM公式擴充，就可以得到中臺為我們帶來的價值變化公式：

總成本節(jié)省=(業(yè)務1節(jié)省開發(fā)成本+業(yè)務2節(jié)省開發(fā)成本+…) -業(yè)務中臺開發(fā)成本-業(yè)務方遷 移至中臺成本-中臺系統(tǒng)運維成本

到這里我們整個業(yè)務中臺的方案就設計完畢了，在第11章我們將聊聊如何設計能監(jiān)控整個業(yè)務 體系的數(shù)據(jù)中臺。

總結

知識點1：業(yè)務中臺建設步驟

在本章我們通過一個案例按照第9章提出的業(yè)務中臺建設框架進行了實踐，到這兒我們可以總 結一下完整的業(yè)務中臺建設步驟，分別是繪制全景功能地圖 (梳理業(yè)務線功能現(xiàn)狀) 、找到核心 業(yè)務流程 (不同業(yè)務線中的統(tǒng)一流程) 、搭建企業(yè)級數(shù)據(jù)模型 (業(yè)務數(shù)據(jù)化) 、研發(fā)業(yè)務中臺中 間件 (分布式存儲模式搭建) 、對接后臺業(yè)務系統(tǒng)。

知識點2：業(yè)務中臺建設KPI

我們主要通過兩個指標來考核中臺模塊建設的成功與否：模塊復用率、業(yè)務開發(fā)TTM。