中小企業的業務中臺構想、規劃與設計

本文從四個方面給大家總結了中小企業的業務中臺構想、規劃與設計，希望文章內容能夠給大家帶來幫助，enjoy~

目前行業關於中臺建設的文章隨著熱度已經非常多了，尤其是阿里、Thoughtworks、雲徒等都拿出自己的理論體系和實踐方法。這些理論給行業帶了明燈，使得中臺建設有一個清晰方法論。

筆者總結目前這些方法論，主要集中在大企業的實踐，很多也是基於EA架構建設方法論的進一步延展和創新。比如王健老師的D4模型，融入設計思維，融入DDD領域驅動設計。

D4模型將中臺規劃方法論分為4個步驟：

1. 企業戰略分析和調研（Discovery）；
2. 企業數位化全景規劃（Define）；
3. 中臺的規劃與設計（Design）；
4. 中臺的建設與接入（Delivery）。

圖  王建老師的4D模型

筆者所處的企業是一家從0-1的中小型網際網路汽車企業。對於中小企業，尤其0-1的企業，並不適合完整的進行企業戰略分解、自上而下調研和分析、然後進行企業架構設計、然後再進行詳細的規劃和計劃。 因為中小企業面臨市場變化很快，資源有限，必須快速調整戰略和業務，如果經過複雜而又冗長的系列至上而下的討論和規劃，得出來後的方案，已經不適應新的市場了。

經過筆者實踐總結，有以下幾步：

第一步：模式識別

首先，作為企業的負責人需要清晰認識自己商業模式，清楚自己的用戶，不能一上來想到的就是如何數位化轉型、如何構築中臺。

中臺適用的場景是什麼？

根據王健老師的定義企業級能力復用平臺，也就是說企業的模式是前提。最近筆者也接到很多大型裝備製造業數位化轉型以及建設中臺的諮詢，但筆者認為對於大型裝備製造業的數位化轉型應該有自己的側重點，比如智能製造，而不一定非要加上一個中臺的概念。中臺本身來自阿里的電商，面向的是激烈競爭下的流量時代，所以「以用戶為中心」的企業更加適合。

第二步：問題診斷

筆者實踐中認為，從問題出發，快速解決業務問題，然後再逐步連接起來和歸納出來，更適合小企業的中臺建設。

首先，可以通過魚骨圖等問題分析工具，分析目前存在的業務難點；

圖  問題診斷示例

比如圖中筆者的團隊在建設中就發現，前端有各種結算和支付場景，在自有APP、電商 、線下體驗店系統及第三方電商渠道，都有自己的結算和支付需求。

由於各系統都對應開發了結算和支付功能：

1. 各系統重複開發，尤其是結算邏輯複雜情況下，開發成本就會增加；
2. 一旦計算的邏輯和支付功能修改，就需要同步給各系統，並逐個驗證；
3. 業務方由於不同系統都要操作一遍，造成他們非常的抱怨，且很容易由於人工配置的疏忽導致結算結果不一致的情況。

這就是一個很典型的業務問題，基於這樣一個業務問題，我們規劃了結算和支付中心，為前端各場景系統提供API。這樣各系統結算和支付時，通過調用結算和支付中心，將總價、折扣、積分、支付渠道等輸入給結算和支付中心，結算和支付中心完成結算和支付並返回結果。這樣則只需要維護一個結算和支付中心即可，不僅開發量大大減少，同時業務也僅需要在一個地方配置結算和支付邏輯，且能夠保證一致性。

根據不同業務問題，逐步完善中臺建設；如果一開始就有一個宏大規劃，不僅僅難以落地，而且由於見效慢，很難得到業務和領導的支持。

圖  系統架構對比

第三步：組織建設

那有了中臺的建設目標，要不要建立一個中臺組織呢。很多企業一開始就規劃了一個業務中臺，然後成立了對應的中臺組織，用於完成中臺產品的設計、開發和運維。中臺團隊很容易就陷入一個備胎定位， 前臺系統有什麼髒活累活都會成為中臺的鍋，成了一個備用資源中心。但是我前面提到，對於小企業或者創業型企業來說，資源是有限的。所以筆者認為，以服務中心為基礎，形成跨組織的項目團隊，才是更好的方式。

原因有二：

• 一是，由於中臺團隊解決的是實際問題，所以能夠得到業務和前端團隊的有力支持；
• 二是，隨著對應服務中心建設，能力會沉澱到相應的人員，這些人員也就成為服務中心OWNER，隨著服務中心的逐步建設，中臺組織就慢慢自我形成和連接。

圖   中臺組織建設

第四步：服務梳理

一旦我們明確目標，以及有對應團隊，就可以進入業務中心梳理，很多中臺負責人遇到第一個問題就是：什麼樣的原則來劃分服務中心？ 這裡基於筆者的實踐，我給出三條建議：

統一標準：這裡說的統一標準，包括三個層面：

• 第一是業務標準，即通常我們說的業務流程的標準化，這需要抽象業務的時候進行分析，並對部分業務進行標準化處理，比如：整車的訂單和備件訂單，他們的物流狀態本身是不同，這個時候就需要做一些標準化。
• 第二是技術標準，即不同的服務中心不管建設方是誰，必須是一套技術框架來進行，同時接口也必須統一；
• 第三是數據標準：包括元數據、維度等等。這三個標準越往後，難度越大，這也是為什麼要基於業務問題出發，這樣能夠減少統一這三個標準的難度。

基於以上三個原則能夠滿足，則可以進一步通過MVP來驗證。

MVP（最小化可行產品）：創業團隊永遠是基於MVP出發的，所以中臺建設也不例外。儘管我們的中臺建設是基於業務問題的，但程序猿都很容易陷入到追求全面和完美。 中臺關鍵是復用兩個字，但是哪些能夠復用呢，這需要基於業務問題出發去抽象。

整車訂單和備件訂單例子，如果要強硬去整合就會存在很多問題，因為整車訂單的下訂流程和備件訂單差異很大，所以抽象成一個完整的訂單中心把訂單的下訂、選配、拆單、物流、狀態等以及正、逆向流程抽象化是非常困難。但是我們可以基於MVP，想把訂單狀態標準化，作為訂單狀態中臺，可以讓其他系統訂閱這個服務，從而解決訂單狀態統一維護問題。

價值優先：很多中臺建設花費很多精力和成本，最終的卻沒有產生有價值的成果，甚至反而成為拖累。所以，建設中臺必須要考慮結果。基於業務問題出發，梳理出來的中臺建設方案，能不能解決業務問題。這裡的結果，筆者強調必須是能夠量化的，這個量化目標維度，既可以是業務維度，也可以是技術維度。以下就是筆者在進行支付中心建設時的目標：

圖   目標看板

總結

（1）一般行業內的做法是在EA框架的基礎上進一步優化和創新。

（2）中小企業應該通過模式識別、問題診斷、組織建設、服務梳理4步完成業務中臺構想、規劃與設計。

 

作者： 大橙子；深耕汽車行業信息化、數位化10多年

本文由 @大橙子 原創發布於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

收藏已收藏 | {{ postmeta.bookmark }} 點讚已贊 | {{ postmeta.postlike }}