中台産品設計的“大中台+小前端”

二十年前，CRM叫九七。

那時，辦業務必須去營業廳。營業員在九七系統裡錄入使用者資訊、業務辦理資訊。然而，随着業務和客戶的增多，幾個人能開發搞定的九七系統，逐漸膨脹、臃腫。

這時，系統開始分成前端、後端。面向客戶的前端叫BS系統，面向網絡、運維的後端叫OS系統。

然而，随着時代的變化，系統平台化逐漸成為标配，基礎設施、人工智能各種領域不斷出現各類平台。同時，平台化對于軟體開發人員、企業都産生了很大的影響。

企業平台化源于以使用者為中心的産品出現，網際網路時代使用者是商業戰場的中心，為了快速響應使用者需求，系統必須走向平台化。通過不斷快速響應、探索、挖掘、引領使用者的需求，使得企業得以生存和持續發展。

• 海爾早在十年前開始推進平台化組織的轉型，提出了“平台自營體支撐一線自營體”的戰略規劃和轉型目标。建構了“人單合一”、“使用者付薪”的創客文化，将平台化提升到了組織的高度。
• 華為在幾年前提出了“大平台炮火支撐精兵作戰”的企業戰略，“讓聽得到炮聲的人能呼喚到炮火”形象诠釋了大平台支撐下小前台的作戰政策。
• 阿裡通過多年不懈的努力，在業務的不斷催化下，将自己的技術和業務能力沉澱出一套綜合能力平台，具備了對于前台業務變化及創新的快速響應能力。

然而，随着網際網路程序的推進，新業務模式不斷湧現：O2O線上線下協同、全管道無縫購物體驗、異業合作能力支撐。大多數企業的背景開始出現問題，要麼前台無法用，要麼不好用，或者變更速度跟不上前台節奏。

大部分企業背景系統，建立之初的目标不是服務于前台系統創新，是為了實作企業業務資源的電子化管理，解決企業效率問題。

這類系統有些花大價錢外購，每年支付大量服務費，但版本舊，定制困難；還有些花大價錢自建，漏洞多變更困難。

最終背景問題集中在慢、貴，響應業務慢，改小功能又花費高。

于是，“數字化平台戰略”出現，也就是我們常說的“中台”。

初了解“中台”，不清楚與“前台”、“背景”外是什麼樣的差別。随着參與的企業中台項目順利步上了正軌，試回再次回顧中台并梳理成文，與大家交流。

首先我們先明确前台、背景的概念：

• 前台：企業的最終使用者使用的産品，是企業與使用者的互動的産品。如使用者使用的網站，手機App，微信公衆号等都是前台。
• 背景：背景通常管理企業的核心資源，如财務系統，産品系統，客戶管理系統，倉庫物流管理系統等，這些系統構成企業背景。

而中台，從企業内部來看，本質上是企業組織架構、技術架構的優化，核心思路是“能力共享”，是企業級的各個業務線和各個管道可以複用的能力。就企業與企業間看，也存在泛複用能力。

如對于電商系統來說，不論是什麼類型的電商，其基本子產品都應包括：商品、訂單、支付等，是以，做為伺服器“中台”可以成為行業解決方案。

中台支撐前端需求，并且快速響應。同時，中台的搭建和疊代依賴于前端，包括：

1.中台需求來自前台

這裡也能看出中台、平台的差別：平台側重提供現有能力，而中台要響應前台需求，前台需要什麼我就做什麼

2. 中台的疊代源于新業務、新服務接入

接入前端越多，中台越完善，越豐富和立體，是以中台要積極地引入更豐富的新業務。

中台的核心任務是制定标準、機制，把不确定的業務規則、流程确定下來，減少溝通成本，最大程度地提升協作效率。是以：

• 中台的目标：減少溝通成本，提升協作效率。
• 中台的實作手段：制定标準和規範。
• 原則：集中管控，分布式執行。

中台類型繁多，常見的有：

• 業務中台

• 資料中台

• 營銷中台

• 技術中台

• 運維中台

不但如此，聽說滴滴還做了ux中台。從理論上來說，前台業務重複部分都可以做成中台。

例如：登陸頁面

大部分産品的登陸流程差不多，如果某個企業具有整合開發的能力，可以輸出一個技術中台，在新産品做登陸頁時，直接複用做個性化開發。

由此，不難發現中台的優勢在于：

減少重複

阿裡開始做中台是發現淘寶、天貓兩個電商系統完全獨立，但都有商品、交易、支付、物流和評價等相同的功能。

嘗試複用的構想下，建構了“共享業務事業部”。之後，融入1688、聚劃算、閑魚等更多獨立系統，沉澱形成了統一的使用者中心、商品中心、交易中心、評價中心等。

打通多管道

傳統平台通常會拓展多個管道，如：線上app、小程式、公衆号、線下門店，但尤于獨立的技術架構，各系統管道資料獨立，無法多管道共享，影響使用者體驗。

另外，對于使用者資料來說，每個使用者在各個管道産生的行為資料都不同，獨立系統下，建構完整使用者畫像并精準營銷基本屬于空想。

中台不但可以存儲原始資料，也能建構事實資料标簽，甚至預測标簽，前端資料都可以調用。而且，系統資料表結構需求發生變化，出現新資料需求時中台也可以快速修改。

加快需求上線

中台對前台需求的快速響應，實質是開發思路到營運思路的轉變。去除所有系統從0到1的開發套路，而是從營運角度思考，從己有的1中拿出可以共用的部分做模式化優化開發。