編輯導讀：本篇文章以第三人稱描述產品實際工作中，“業(yè)務中臺”部分從0-1的搭建，介紹了作者對中臺的一些理解心得。如果你對中臺感興趣，或者工作中也需要涉及到中臺的搭建，那么本篇文章應該對你有幫助。

01 背景

這2年來產品被議論最多的應該就屬“中臺”了，火到連面試官都要問一下面試者“有沒有中臺的產品設計經驗？”。

國內的中臺最早提出者是阿里，阿里在2015提出了“大中臺、小前臺”戰(zhàn)略部署。作者經過一段時間的學習與實踐，梳理后輸出此文，跟大家一起討論下中臺的存在意義以及戰(zhàn)略規(guī)劃。

隨著企業(yè)的快速發(fā)展，很多企業(yè)都開始步入多元化領域，以事業(yè)部的形式向其他領域進發(fā)，而為了快速滿足前臺需求變化，大多企業(yè)內都具備了多套操作系統(tǒng)，一個稍微大規(guī)模的甚至去到十幾二十套系統(tǒng)。

以作者的企業(yè)為例：ERP、CRM、直播、資訊等業(yè)務系統(tǒng)，還有HR、財務等支持系統(tǒng)。即便如此，各條業(yè)務線還是覺得不能滿足，希望自己的操作系統(tǒng)能夠更加的強大。

由于這些系統(tǒng)是分部實施，并且還是不同供應商提供的，造成這些系統(tǒng)有一個顯著特點——那就是每一個都是自成一體的封閉的系統(tǒng)。

前期不會有太大的影響，每個部門各玩各的就完事了，但是隨著后續(xù)系統(tǒng)的不斷成熟，很多的問題開始浮出水面。

這里舉一個例子，企業(yè)中下達了一個“敏感詞管理“需求，需求目的在于對用戶終端進行敏感詞的顯示管理，需求下發(fā)后由各事業(yè)部的業(yè)務部門分別執(zhí)行，如果當前有3個事業(yè)部門，那么該功能單元則需要被搭建3次，這無疑加大了企業(yè)的人力成本。

那么諸如此類問題，是否可以將其中一些基礎的東西，比如說：商品信息、授信信息、敏感詞信息等等，集中起來，同時對外提供服務或整套的企業(yè)解決方案呢？

——這就是SaaS和微服務的概念。

中臺戰(zhàn)略，就是基于這樣的一個規(guī)劃應運而生的一種信息化架構。

所以說，為什么要規(guī)劃中臺戰(zhàn)略？

02 中臺建設

行業(yè)內的中臺，往往分為組織中臺、業(yè)務中臺、數(shù)據(jù)中臺、技術中臺這四個主題切入并探討建設目的與建設方案。此文主講“業(yè)務中臺”，其他類型的，如果之后有時間，作者會在后續(xù)的文中進行補充（主要是作者不懂…）

這里摘抄前VIPKID 的產品總監(jiān)楊堃的一段話：

業(yè)務中臺：業(yè)務中臺研究的是企業(yè)內部的軟件系統(tǒng)如何進行抽象和設計，從而讓企業(yè)的軟件系統(tǒng)就像搭建積木一樣靈活，可以重復高效利用現(xiàn)成的軟件組件，快速組裝開發(fā)出新的軟件系統(tǒng)，從而節(jié)約軟件開發(fā)成本，并能夠快速支持新業(yè)務開展。很多文章也把這類中臺產品稱作業(yè)務中臺，或業(yè)務中臺產品。

目前被廣泛討論的產品中臺包括電商交易中臺、賬號中心中臺等，其中電商交易線又被更加廣泛的探討，包括了訂單中臺、支付中臺、商品中臺、促銷中臺等。

產品中臺還有另一層含義，即能夠給全公司全企業(yè)提供一致服務的管理軟件產品，也可以納入產品中臺的范疇，例如呼叫中心、項目管理軟件。從某種程度上來講，這些標準化軟件產品也是中臺產品。

我們經常聽到，中臺的建設目的主要是為前臺服務的，對于業(yè)務中臺，目前公認的關鍵要點包括如下關鍵詞：企業(yè)級、抽象、下沉、復用，這些關鍵詞代表了業(yè)務中臺建設的特點，同時也是在企業(yè)應用架構設計中需要深層次思考的問題。（這里為什么企業(yè)級放在第一位，中臺的建設一定要依托企業(yè)中的核心部門來進行推動，不然又會出現(xiàn)閉門造車的現(xiàn)象，所以也就可以明白，為什么阿里中臺的戰(zhàn)略的第一步，就是組建了一個“共享事業(yè)部”。）

03 實戰(zhàn)案例：幫助中心

統(tǒng)一客戶視圖建設

作者企業(yè)中，目前有多條業(yè)務線，如旅游業(yè)務線，便民業(yè)務線，學習平臺業(yè)務線等，業(yè)務團隊包括市場推廣團隊，運營團隊，以及客服團隊。每條業(yè)務線都有各自的運營系統(tǒng)支持其運轉，每個業(yè)務線系統(tǒng)既有個性化功能，如：課件信息、運營中心、講師信息。也有高度重合類似的功能，如：訂單列表、幫助中心，圖片如下所示。

每條業(yè)務線都有一個幫助中心，雖然不同的業(yè)務線面向的用戶群體不同，但目的是統(tǒng)一的，都是提供常見的問題解答方案供用戶學習參考。

為了解決重復開發(fā)的問題，也為了能給業(yè)務人員提供統(tǒng)一的操作視圖，作者將“幫助中心”模塊從三個業(yè)務中抽象出來，建設統(tǒng)一 的“客服服務中心”模塊，該模塊提供統(tǒng)一的數(shù)據(jù)信息接口，供三個業(yè)務線分別調用，形成中間件標準，實現(xiàn)高度復用。

此時，“客服服務中心”將作為中臺產品，為各個業(yè)務系統(tǒng)提供幫助信息數(shù)據(jù)查詢的服務以及視圖。圖片如下所示。

而前臺為了實現(xiàn)視圖標準化，也進行了統(tǒng)一搭建，形成“客服中心服務”組件，通過對此頁面進行靈活的權限配置，實現(xiàn)不同業(yè)務、不同角色進入時的數(shù)據(jù)查看、編輯。

圖片如下所示：

類似的還有很多，這里就不再一一列舉了。

總結

（1）中臺的搭建需要根據(jù)企業(yè)戰(zhàn)略而定，并且需要企業(yè)進行主導和推動，稍微大點的企業(yè)，業(yè)務線數(shù)不勝數(shù)，每個業(yè)務線都有對應產品經理人與業(yè)務團隊，先別說對其他部門的業(yè)務線功能邏輯了解多少，可能連對方產品經理是誰都不知道，在此環(huán)境下，單一推動與搭建中臺會顯得極為困難。

（2）中臺搭建的必要性有多高，如果說企業(yè)內為單一業(yè)務線，如在線教育、違章辦理等，所有的業(yè)務團隊都是圍繞當前業(yè)務線開展工作，那么這種情況下不建議在前期進行中臺的規(guī)劃與建設，原因是未來的不確定因素太多，或掌握的信息不足，很可能做出錯誤的判斷和設計，做出了錯誤的抽象決策，最后被抽象的系統(tǒng)模塊，并不能被充分復用，只是制造了一個畸形的別扭的模塊，生硬的把一堆毫無關聯(lián)的功能強行捏在一起，給研發(fā)工作反而帶來的更大的麻煩。

希望本篇文章能對你的工作上提供到幫助，如果對文中有不解或者建議之處，還請在評論區(qū)指出。

最后，感謝大家的閱讀。

本文由 @魚店不賣魚 原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議。