學了那麼多中台建設方案卻不知道中台需求如何管理？本文就來談談如何進行中台業務邊界劃定，開啟建設第一步。

一、中台業務邊界的劃定是乾什麼？

在前面的中台實戰章節中，我們先後談過了中台的概念、中台產品設計的核心思路模塊化設計、數據剝離思路，在學習了這些中台的“屠龍”技術之後，距離我們真正去進行中台建設還有一個很重要的問題，就是我們要如何識別各個業務線中的功能是否都為需要中台化的部分？

比如說我們在某個業務線中新推出了付費會員體系，那麼我們如何判斷是否要把這一模塊進行通用化，進行中台化呢？可能你會說付費會員體系屬於變現的基礎功能肯定要進行中台化啊，這是由於我舉的這個例子比較直觀，所以我們能快速地判斷出。

但是如果在看一些不是很直觀的模塊：地址標簽、會員個性化頭像，你覺得還要中台化嗎？是不是我們就需要分別進行論證了？

中台也是一個軟件產品，因此整個建設流程和我們的一般性產品設計一樣，可以很粗略分為如下4步：

用設計一般化產品的環節來說，前面我們一直在學如何進行需求分析，甚至提到了一部分的中台項目管理，而本章我們其實就是要去探討中台的需求範圍如何定義。而在中台的建設歷程里我們又稱之為中台業務邊界的劃定。

這個問題本質上有兩個核心難關：

• 需要我們中台的產品經理能判斷出該流程是否為整個公司的核心業務的標準環節，也就是80%的業務日常都會觸達這些個節點；
• 在企業下一步戰略中上一步的分析結果是否還為整個公司的核心業務的標準環節。

為什麼要這麼做呢？

我們知道中台也是一個軟件系統，而軟件系統的最大優勢就是低邊際成本。就拿一個OA軟件的單次開發成本來說，它的在研發階段的資本投入很大，為一個人開發出來需要交34萬元，但是一旦它投入大批量的生產，它的信息複製成本幾乎為零，10個人34萬元人均3.4萬元，100萬個人用呢？每人的成本可以低到不計了。我們也就可以近似看到邊際成本幾乎為零。

同樣的作為承載著企業效率提升的中台，如果設計出的模塊被各個業務線都沒有進行服用的話，那麼這個中台首先就是設計失敗的，其次這些模塊設計的成本也就變得非常高，所以我們必須要清楚的知道，劃歸到中台內部開發的模塊必須是企業中各個業務線高頻的業務服務，只有這樣我們將它沉澱到中臺中，才會為各個業務線的研髮帶來效率提升。

二、企業業務SOP梳理

因此我們在中台需求邊界的梳理過程中，第一步就是要進行業務流程標準化，這裡也有一個專用名詞，稱之為企業業務SOP，也就是我們要去梳理企業業務SOP。

梳理前，首先讓我們先搞懂SOP是什麼？

先來看下定義，所謂SOP就是 Standard Operating Procedure三個單詞中首字母的大寫 ，即標準作業程序，指將某一事件的標準操作步驟和要求以統一的格式描述出來，用於指導和規範日常的工作。

通俗來講SOP就是對某一程序中的關鍵控制點進行細化和量化。從管理學的角度,標準作業程序能夠縮短新進人員面對不熟練且複雜的事務所花的學習時間,只要按照步驟指示就能避免失誤與疏忽。

在正常每個公司中，每個固定環節我們都會有一些SOP，最經典的就是我們進行活動運營制定的那一套模板，而中台產品經理要做的就是將整個公司業務的SOP梳理出來。

那麼怎麼發現SOP呢？具體來說我們分為兩步得到整個公司級的SOP。

要梳理SOP就不得不先談兩個概念：

• 每個業務線中的現有日常流程，我們稱之為工作流；
• 服務/產品的作業流程中產生的信息流轉，我們稱之為信息流；

也就是說SOP在實際工作中我們可以這樣去理解：

SOP = 工作流 + 信息流

我們以電商商品中心為例子來看看怎麼去梳理出一個SOP：

（1）工作流：日常工作的節點獲取

這一步我們的得到了日常操作的每一個重要階段是什麼，也就是關鍵業務活動。接下來我們要去梳理每一個業務活動中有哪些信息流。

（2）信息流：信息流轉的節點獲取

如上我們得到的就是一個完整的信息流，這兩部合併起來我們就將抽象的業務活動定義為標準的信息流程，我們可以清楚看到業務線是如何實現商品管理的。

當我們將不同事業線中的信息流與工作流都梳理出來後，我們就可以統一來看哪些部分是各個業務線都重疊的，從而提取到中台來。

三、公司級戰略評估

在前面我帶大家完成了業務線內部的關鍵節點拆分與定義，總結出了各業務線的SOP，但是前面的方法主要是在模塊內部拆分還不夠全面，接下來我們要上升一個維度進入業務線間的抽象，去評估這些SOP哪些是符合當前公司戰略走向的。

具體來說我們的評估維度整體範圍如下表所示：

在這個層級的分析我們重點是要：

找到企業的問題域 ->再定義解決能力

每個軟件系統都有自身立項的原因，就拿我所經歷的中台業務來說，當時我們的數據中台推動原因：

在我們準備引入第三輪Pre A投資時，也就是Ts簽完（投資意向書），但是資本方給了個問題我們如何證明我們的商業模式是成立的，作為一家電商企業在規模增長融資階段，我們定義了以GMV與復購率作為商業模式驗證指標，最終就這個問題我們簽定了對賭協議並約定了這兩個核心指標的在2年內的增長目標。

所以這個時候我們整個公司對於數據需求就很明確了，也就是找到了我們的問題域：

• 如何定義下一步運營戰略；
• 如何精準獲客；
• 如何推動用戶復購；
• 現有用戶交易情況跟蹤。

我們也找到了現在與未來的企業發展方向，此時就可以對上一步得到的SOP進行一個再次評價，哪些是公司當前戰略所需要的，將其歸類到中台需求範圍中，至此我們整個中台業務需求邊界就可以說梳理完了。

四、拓展

這裡稍微拓展下，其實這裡的兩個分析我們已經悄悄的得出了業務流程架構，沒錯業務流程架構本質就是業務線流程+企業戰略兩個部分，我將上面的案例稍微的拓展下：

怎麼樣？不知不覺我們產品經理實際已經完成了一個企業架構的設計，所以大家看看產品經理是企業CEO學前班這句話還真不是騙人的。

PS：你的收藏、點贊就是對我最大的支持！

#相關閱讀#

中台實戰（0）：最近處處惹人愛的中台到底是什麼

中台實戰（1）：看懂企業業務演進路線

中台實戰（2）：中台的建設核心原則

中台實戰（3）：數據中心中台化案例

中台實戰（4）：業務的抽象建模

中台實戰（5）：數據指標體系創建思維

#專欄作家#

三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家。曾萬達高級產品、MBA特約講師、獨立創業者，現某支付公司產品線負責人，擁有多款集團項目從零到一經驗並帶領實現商業化佈局。

本文原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議