編輯導讀：區別於普通業務，中臺能讓系統更好地滿足業務需求，提升系統效率，建設業務中臺最直接的目的一般是為了幫助產品快速且低成本的提效。本文作者從自身工作實踐出發，總結分享瞭如何建設業務中臺，希望能夠給你帶來一定的啟發。
本文主要記錄為公司搭建業務中臺的前期過程，由於摸著石頭過河，如有不足之處，懇請指出。
一、發現問題，分析猜想領導：“最近公司同事都反饋內部的多個系統很難用，操作效率低，你看怎麼解決下呢？”
作者：“好的，我研究下，明天上午給您一個回覆。”
和領導溝通後發現，隨著公司業務線開拓，輸出各種產品，後臺需要不停的新增對前臺的功能支撐，而功能需求有些大同小異，有些大相徑庭，同事們需要登陸不同的後臺處理不同的業務流程，甚至會碰到系統無法滿足業務需求的情況。
因此，可以初步判斷，這不僅是內部系統效率低下，更涉及對公司資源的浪費問題。而追本溯源，是業務線開拓，後臺系統需要支撐各類服務導致的。於是，作者對公司的業務體系進行梳理。
1. 業務梳理首先梳理公司當前的服務模式。
公司作為綜合服務提供商，為各類客戶提供資料、評價、諮詢、科技以及培訓服務，以下業務線為例：
“資料服務”、“評價體系”、“研究諮詢”作為成熟度較高的業務線，涉及的部門及業務流程已經具有完整的閉環，而“資管科技”和“培訓服務”有以下特徵：
- 近年核心業務，產品推陳出新，迭代快、定製化需求極多；
- 多方領導重點照顧，後臺部門必須積極響應這兩條線的各種要求；
- 業務方向大相徑庭，但都需要其他業務線的大量支撐；
- 產品形式多樣，涉及PC、移動端、嵌入外部系統等方式；
於是，“罪魁禍首”找到了。接下來需要對業務線進行內部調研。
2. 業務調研調研物件：兩條業務線裡涉及的部門業務人員，由於分身乏力而且只是初步瞭解，因此根據領導提供的反饋截圖找對應同事溝通；
調研目的：瞭解業務流程上的問題、瞭解操作流程上的問題、瞭解運營流程上的問題；
可事先準備部分調研問題例如：
- “你們在操作過程中遇到了什麼問題”
- “你在做什麼事的時候感覺系統不能滿足你們的業務流程”
- “你們當前運營重點是什麼呢？”
- “系統是不是沒有足夠的資料支撐，哪些內容沒有得到有效的處理”
- ······
這部分由於時間關係，只是想初步瞭解同事們對當天業務流程的看法，順便試圖找出他們的真實訴求，如果想更調研具體，可靈活參考《產品汪的“野蠻生長”覆盤（2）》（右鍵-新標籤頁開啟）第二節“需求”裡的“使用者調研”。
同事們的反饋如下：
進而整理得到同事們的真實訴求：
- 定製化需求裡複用率高的業務模組避免重複設計與開發，消耗人力；
- 報告的上傳、稽核、上線、分發進行統一，保證在一個系統上實現對所有內容的管理；
- 對各類產品統一管理客戶資訊（CRM系統）；
- 內部資訊跨部門管理，實現文件的及時更新和傳閱；
- 資料統計維度統一，避免不同系統出來的資料結果不一致；
- ······
結論：公司需要一個小型的業務中臺
二、設計規劃，小心論證作者：“經過分析我發現這兩條業務線產生了這些問題······，經過和大家的友好溝通，同事們的真實訴求是······，因此，我認為公司需要一個小型的業務中臺，以提高同事工作效率，響應前臺高頻變化需求、降低後臺人力成本、進而提升業務整體效率，應對兩條業務線不斷變化的發展需求。”
領導：“不錯，可以寫一份關於中臺的規劃方案，下週一可以嗎？”
作者：“可以的”
為了規劃中臺，借用5W2H方法對兩條業務線進行分析，得到中臺的業務目標、業務流程以及業務迭代。
1. 業務目標Who：梳理每條業務線的參與角色（從使用者到運營，最後到技術支撐），這些角色將會是受到中臺影響最直接的角色，後續的功能邏輯梳理也要圍繞ta們進行；
When：業務線裡產品的生命週期，中臺的搭建需要即時應用到實際生產中，因此需要考慮產品的實際生命週期，以“逐步迭代、每個版本都能產生價值”作為中颱建設節奏；
What：業務線裡，前、中、後臺涉及到哪些功能，主要找出具有共性的功能，這些功能往往就是複用率高的，優先加入中臺搭建的功能；
Where：梳理出業務共通的功能，體現在複用性、業務邏輯一致性等；
Why：自問自答，為什麼選擇它納入中臺；
How：如果納入中臺，大概會以什麼樣的邏輯實現。可以結合流程參與角色畫出業務流程圖；
How Much：該功能的優先順序評估；（圖中是定性，也可以用定量的方法，即透過和以往的實現方式對比，人力成本節約了多少百分比）
透過業務解析，最終得到中臺的功能框架，樣例如下：
關於版本規劃，一方面除了“How Much”裡的分析外，另一方面可以從以下4點考慮：
- 保證“每次迭代都能為業務線創造價值”，即每個版本都能提供一個核心功能滿足某個需求；
- 避免過度設計，不想被蚊子叮，蚊帳即可；不想聽蚊子聲，蚊香/驅蚊液不香嗎，別去練用筷子夾蚊子的功夫；
- 暫時不去改動目前成熟且運轉無誤的業務流程，先解決問題，再考慮最佳化；
- 同等優先順序時，可考慮“使用者高頻使用的功能＞使用者強烈要求的功能＞支援業務生產的功能＞內部同事期望解決的功能”
作者：“領導，這是業務中臺的初步規劃，一共涉及了2條業務線，涉及的部門和角色分別是······，對應的中臺功能架構是······，之所以這麼設計是因為······，目前規劃的優先順序是······” 領導：“我找時間協調下部門相關業務負責人，你給他們講講”
與各個業務線涉及的部門溝通中臺方案，需要解決戰略講解、認知統一、業務邊界等細節問題，以便快速無誤地進入專案啟動階段。
1. 戰略講解主要講解中臺和公司戰略的緊密程度和對業務線的有利，讓各個領導達成共識。
其次確定中臺目標，不是做阿里那種以電商為核心的共性業務中臺，也不是做滴滴那種圍繞打車業務延展的複用業務中臺，而是做契合公司本身業務發展的中臺。
最後闡述中臺主要涉及的業務線，需要對應部門提供人力支援。
2. 認知統一- 大家對當前業務線和對應產品的目標認知統一；
- 業務概念、指標定義、系統規則、資料規則的認知統一；
- 業務標準執行流程上的認知統一；
主要基於中臺功能架構，把每個功能的流程與參與角色的實際操作進行對比，確定中臺業務邊界，避免過度開發、錯誤開發和無用開發。
總結和其他業務線的團隊溝通並細化需求後，基本上就進入正常的專案階段，後續流程可參考《產品汪的“野蠻生長”覆盤（2）》。
期間其實也碰到不少問題，例如：
- 專案開發團隊是從其他開發中的專案抽調的人員，導致中臺搭建時，開發人員的理解更傾向原本業務，無法一碗水端平；
- 花了很多時間在給專案團隊講解各個業務流程，需要持續的把控進度，避免開發跑偏；
- 由於有部分產品已經開發完成投入使用，中臺搭建的同事，需要同步調整往期產品的部分內容，開發成本遠超預期；
- 需要持續的投入維護和迭代，以便跟上整體業務線進度，讓本就禿頭的開發同事雪上加霜；
而最終效果很明顯，定製化產品的開發週期普遍縮短了、內部運營效率提升了，技術同事拍頭叫好，運營同事喜極而泣，市場同事老來欣慰，而我也激動地記錄下這次搭建流程，拋磚引玉，希望對大家有所幫助。
本文由 @汐_ 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。