01 卓越的CIO更關注戰略與IT相結合的方法論
提到CIO，你能想到什麼？ 對於公司內部信息技術做項目的管理與執行 ？ 不！這是過去式了。 現在的CIO，眼裡有戰略，手裡有技術，肩能扛業務，甚至主導整個公司發展與變革也不在話下。 過往可能我們對CIO的期待，可能是對於公司內部技術或者是對於IT做一些執行的項目與管理，但是現在大家對於CIO的期待越來越高，甚至希望CIO能夠主導整個公司的發展跟變革。 我對CIO做了三個不同的層面的解讀： 我們傳統的CIO更多的是關注在技術層面，但很多優秀的CIO，他已經從技術層面開始擴展到業務層面的；而卓越的CEO更能夠關注戰略跟IT互相結合的方法論。
如果IT跟戰略脫離，CIO可能會面臨到問題是，公司決策層會覺得所花的錢不是在刀上，且所做的事情跟戰略沒有直接相關。反之，這個CIO是非常有成就的。 四十多年前，BCG布魯斯·亨德森提出了增長份額矩陣，從市場的佔有率、高增長率這兩個維度去區分公司的業務產品。而這一管理工具時至今日，仍非常適用於當下的商業環境。 舉個例子來講，如果產品佔有率和增長率都很高，那麼我們定義這個產品為“明星產品”；而如果一個產品市場佔有率相對較高，但是增長率已經趨緩，表示這是一個成熟產品，也是一個厚利產品；對於一些可能增長率很高，但市場佔有率不是特別高的的產品，可能面臨著成功或者失敗，我們稱之為“潛力產品”；最後是增長率低，市場佔率也低的產品，我們稱之為“衰退產品”，是需要淘汰的產品。 增長份額現在需要更快速的應用，並且要更加註重戰略實驗(strategic experimentation),以適應越來越難以預測的商業環境。由於市場份額不再是業績預測的有力指標，所以矩陣需要一種新的競爭力衡量標準。 成功的公司需要更頻繁地探索新的產品、市場和商業模式，通過有紀律性的實驗不斷更新他們的優勢，並更加系統地完成這些工作，以避免資源浪費。現在要求公司以一種比競爭對手更快、更經濟的方式投資更多的“問題產品”，並系統地將有潛力的“問題產品”發展成為“明星產品”。與此同時，公司需要準備好應對市場的變化，更快地將“明星產品”變現，讓“現金牛產品”退出市場，並最大化"瘦狗產品"的信息價值。 從這個角度來看，IT就是CIO的“產品”，為了提升產品的市場佔有率和增長率，CIO就需要從企業戰略、人員、技術等方面考慮，從整體性出發，適應企業發展需求，以更高的價值獲取“佔有率”——也就是我們說談論的“數字化戰略”。
中台建設，就是CIO支撐企業內部戰略和產品落地的重要手段。
02 中台是什麼？
在數字化浪潮幾乎席捲了所有行業的時代大環境下，中台成為數字化轉型的重要抓手之一，有人就會盲目將數字化等同於中台。事實上，中台其實不等於數字化。 另外要提醒的一點，中台建設並不適用於初創企業，應該是高速發展的企業階段，例如擴展期、突破期、成熟期階段的企業。 以及，如果不從戰略切入數字化，極有可能犯錯。再次提醒這點。
所謂中台，從業務的角度來說，就是從若干垂直業務流程當中，把相同的或者相似的地方，拿出來抽象提煉，變成一個共享的獨立的業務單元對外提供服務。中台的出現，解決了企業隨著公司業務高速發展，組織不斷膨脹的過程中，暴露出的種種問題。
比如阿里巴巴的數字中台：
阿里巴巴的中台前身其實就是阿里巴巴共享事業部。 為什麼會衍生出中台？阿里巴巴中台又是怎麼誕生的？ 主要還是基於阿里巴巴龐大且複雜的業務。 舉個例子來說，阿里巴巴有電商業務，電商業務下面又有一手電商、二手電商，比如天貓、鹹魚，如果每個業務單元都獨立運作，就會出現業務部門和it部門重複相似的交易工作業務。那麼這個時候企業就要考慮：怎麼樣可以把交易中心，變成一個共享中心，支持不同的交易場景——這就是中台的初步概念。訂單拆分、創建訂單付款、修改價格、關閉訂單、刪除訂單、確認收貨、自動發貨，訂單查詢，等等這些業務也是同樣的道理。 再繼續深挖下去，就會發現，這些業務底層的運維邏輯、數據邏輯、安全邏輯都是相通的，我們把這些單獨拉出來做一個交易中心。 這就是中台。
03 什麼時候做中台？
那麼什麼時候做中台呢？ 我的建議是：導入中台之前，除了考慮自己的企業，在現階段是否適合做中台，企業要先對自己做靈魂拷問，問自己如下的問題： 是否效率不彰了？ 是否能夠復用？ 企業是否是在成熟階段？ 是否理解中檯面臨的就是“組織”問題，也就是“人”的問題？ 阿里巴巴的董事長兼CEO張勇就曾提到一個概念：如果一個企業是奔著中台去做中台，那就是死。
盲目做中台，之所以大概率會失敗，是因為中台不是一個單純的IT問題，它面臨更多的是組織的問題，組織的問題就是人的問題。盲目導入中台，最終將會面臨發展難、借鑒難、兼容難三大難題，如果沒有解決這三個難點，整個業務變化耗時很長，業務中台會越做越重，最後導致這業務狀態沒有人用就被拋棄了。
01 借鑒難：對未來業務發展的預見。 企業新的變化，變化本身也沒有太多規律可循，沒有太多歷史可鑒。 可能今天想著不會發生的場景，第二天就發生了，造成業務流程和系統建設的缺失，還是快不起來； 曾經想著大概率會發生，且為之耗時耗力的業務場景從未發生，造成建設的浪費，結果是付出發展的機會成本。
02 相容難：對已有業務的相容。 要針對某業務需求寫出一堆程式碼來實現並不難，難的是做出通用的模式，來相容已有的，和已知將要有的業務場景； 從零開始做一個系統其實要比改一個已有的系統要容易，新增一段程式碼還能保證原有的邏輯不出問題比較難。
03 發展難：業務快速發展的壓力。 中台的好處是實現快、成本低，有利於業務快速發展。 這是有前提條件的，新業務和已有業務要足够相似，甚至相同。 如果新業務和已有業務有較大的差异，那改造的時間更長，成本更高。
這三個難點凑到一起，導致三種可能的不良後果： 1.變化耗時長，越做越重 2.中台被拋弃，越做越小 3.“偽”中台，越做越笨
所以，做中台，應該要先思考兩個問題：
1、業務是否趨於穩定？
穩定不是指業務不變化，而是指業務在既定的範圍內發生變化，業務的變化是否有規律可循。 比如前面說的銷售管理中台，經常針對某個通路開放或關閉一個保險產品的銷售資格，這就是穩定的。 但是如果在銷售資格上經常出現不可預知的限制條件，就是不穩定。 穩定不穩定，其實要看設計的人和設計的目標，不同抽象層次和歸納方法，對於穩定還是不穩定也會出現判斷上的差异。
2、業務是否快速發展？
快速擴張新的同類業務條線，或者經常發生多業務條線變更，都視為快速發展。 比如，經常新增新的協力廠商平臺銷售保險產品，銷售流程和已有的銷售管道一致，就符合業務快速發展的特徵。 如果銷售管道就是一兩個，比如有些公司主要是線下代理人通路，發展再快，有沒有銷售管理中台意義不大。 如果要拆出一個子系統，也不是中台，其目的是為了系統解耦、瘦身，並不是為了共亯、通用。
正如我們前面所說，中台更多面臨的是組織問題、人的問題，所以，做中台應該首先考慮在業務流程固化之後，再依據業務流程去設立相應的組織，最後才去做中台，即從整個業務模型導入到人，再到組織，最後才是業務狀態。 另外一提，中台並不適用於每家公司的每個階段。 在獨立業務拓展期、突破期，“一定用獨立團、獨立師、獨立旅建制來做”，否則就會變成瓶頸； 但發展到一定階段，出現太多山頭，就要“關停並轉、要合併同類項。問管理要效率，取消重複性建設。” 比如蘇寧科技的組織架構模式：在蘇寧科技的組織架構中，每一個BU或是研發中心就是一個獨立業務，同時它又是一個研發中心，整個業務跟研發部門有非常高度的重合：
另一個實踐案例是蘇寧零售的“智慧零售大腦”概念，叫做“Retail as a Service”。 這麼多人在談數位化，有沒有一個零售公司是有科技能力、可以賦能整個零售產業的？ 囙此我們提出RaaS。 大家可能不太瞭解蘇寧現在的研發實力，比較强大，這在零售行業中也是很少見的，我們把他們聚集起來，不僅僅是工程師，更是零售專家。 單獨把人工智慧、大數據這些基礎設施拉出來，做成一個服務； 在平臺在PaaS層面，我們將一些共同業務，比如會員、交易、供應鏈等內容單獨拉出來做成一個平臺。 以AI來說，有三個基礎算灋平臺，可以讓我們的算灋工程師在上面開發很多應用，也讓我們有80個以上的AI零售場景、150個AI技能可以調用 同時會基於業務中台基礎創建一個大數據中台，可以承載非常多SaaS應用，比如金融、物流、供應鏈、行銷，以及基於用戶的種種SaaS服務：
所以，業務中台定義應該是一個充滿生命力的個體，它能够承載你整個公司的所有的業務流、邏輯，也能够把業務的數據沉澱下來以後，當你需要數據的時候，有業務數據可以用，而且這個中台應該要對企業產生業務價值。 基本上，一家企業能够做中台，都表明這家企業度過了萌芽期和初創期，處於較為成熟的階段或高速發展的階段。
04 業務中台怎麼做？
我們說，業務中台要基於業務戰畧來做。 那麼我們怎麼樣從一個戰畧的方向出發，再到信息化，把這整個點線，面都關聯起來？ 應該去思考如下的問題：
- 如何判斷當前已有數據的價值，規劃並繼續深入思考數位化轉型如何為企業創造價值
- 如何製定數據中台落地的策略和路線
- 如何精確評估數據中台的ROI
- 如何設計相應的組織架構及劃分權利義務
- 如何進行合適的科技選型，以及把握購買產品和自主研發之間的平衡
企業在遇到一些商業機會時，如果從數位化的角度，應該從兩個層面來考慮，第一個是企業的戰畧商業機會，另外一個是科技的實用性，這兩個要完整結合。 首先基於企業的商業機會和戰畧方向去進行企業架構設計、業務活動製定，最後才匯出業務中台的建設方向。 另外，業務中台是個充滿生命力的個體，它承載業務邏輯、沉澱業務數據、產生業務價值，並隨著業務不斷發展進化。 設計者也應該考慮一些原則，並且在一開始就定好這些原則，避免以後做無用功：
- 服務松耦合原則
- 面向介面實現
- 非同步事件解耦
- 服務提供者位置解耦
- 版本松耦合
- 服務依賴原則
- 有價值的領域模型
- 服務間最小依賴
- 能力實體具有層次性
- 延遲對科技組件的依賴
- 服務設計原則
- 優化遠程調用
- 去掉冗餘數據
- 設計粗細微性的服務介面
- 識別並設計通用的服務介面
- 隔離服務內部的變化
- 服務介面先行
- 服務介面向下相容
- 服務命名原則
- 服務顆粒度原則
- 服務的無狀態性原則
- 服務操作設計原則
- 服務約束原則
坊間有很多專家寫類似的原則，我這裡不多說。
企業在做商業機會跟戰畧時，應該要把業務戰畧跟資訊技術戰畧結合在一起。 簡而言之，建立戰略目標與信息化支撐的關聯，為戰略目標的實現提供有力保證。 而業務架跟IT
這裡還是以蘇寧為案例：蘇寧有個叫做零售雲的產品，主要聚焦在縣鎮為主的“下沉市場”，以3C為主的消費品類，在各種惠民措施的帶動下，啟動了縣鎮消費的新勢能。 蘇寧零售雲就是通過數位化把零售能力賦能輸出，讓鄉鎮的傳統實體店店長在加盟的時候，從系統中獲取成功經驗和能力，以降低加盟運營的風險。 這裡面的做法就是結合業務中台、數據中台以及人工智慧做成通用的狀態，賦能對外輸出：
此外，我們在談論中台的時候可能指的是業務狀態，也有可能指的是數據狀態。 以阿裡雲為例子，阿裡雲現在主要推的是數據中台，而不是業務狀態，原因是阿裡雲現時沒有辦法滿足所有的業務場景，每個產業的業務場景是不一樣的。 而數據能够通用，所以數據中台成了企業裡面更容易推動的計畫。
- 數據重複開發
- 數據使用成本高
- 浪費存儲與計算資源
- 業務數據孤島問題嚴重
- 數據標準不統一
- 數據利用效率
然而，在實際運作過程中，還是有很多企業面臨推動數據中台沒有成功。 那這裡面的主要原因有什麼？
- 數據標準建立和協調困難
- 數據需求多變
- 資料安全管理複雜
- 科技選型困難
- 數據正確性難以確定
- 數據許可權管理
- 數據需求多樣
- 資料管理複雜
- 數據成本高，難以量化
如果把數據中台一言說完，其實其本質就是“資料倉庫+資料服務中介軟體。
05 去中心化
基於上述，我個人更推崇大家思考的概念，即去中心化的數據狀態。
Twitter、Facebook、Airbnb等矽谷公司的做法是，大數據部門提供足够好用的工具，賦能業務部門共亯數據能力。 而有些公司的情况又不一樣，它們將某項能力抽取出來由專門的組來負責。 這個概念，其實在很多優秀的頭部互聯網公司都能看到了，比如國內像阿裡、京東、蘇寧等等。
去中心化的數據狀態，跟集中式的數據狀態有什麼不一樣？ 從業務上來講，集中式的數據狀態，通常數據中台業務團隊還要肩負起去梳理整個公司的業務邏輯，這對於數據團隊的挑戰性是非常高的。 而去中心化則不一樣，數據中台業務團隊主要是工具提供者，具體的開發能力會由業務部門的數據研發工程師來負責，這樣的優勢在於數據中台業務團隊要保證整個中台的功能跟穩定性，而業務部門不僅是數據中台的使用者，同時也是貢獻者。 在數據中台建設，除了傳統大數據團隊以外，還需要業務部門的積極參與。 因為共亯的數據能力是與業務相關，且開發反覆運算的流程需要與各個業務部門、IT部門協調溝通，所以在建設數據中台時，需要對參與人員進行統籌安排。 這也是我們在數據中台規劃過程中經常碰到的問題。 下麵列出了數據中台建設過程中一般會涉及的人員及其主要職責：
- 業務部門首長：深入瞭解業務流程和優先順序，能够將業務場景與數據對應，指導建模的流程。
- 業務系統架構師：瞭解企業的系統架構、科技框架。 l業務流程工程師：對業務流程非常熟悉，通常是科技部門與業務部門的紐帶。
- 數據平臺工程師：通常有系統工程師背景，負責建設和運維數據平臺，安裝和運維各種大數據組件，以及保證數據平臺的效能和穩定性。
- 數據開發工程師：以資料倉庫技能為背景，懂業務，負責建模、數據清洗和編寫ETL程式。
- 數據應用開發工程師：以應用開發為背景，開發服務於業務部門的數據應用。
- 數據中台架構師：全面掌握數據平臺的功能，對公司的產品提出數據的支持和要求，負責公司產品與數據平臺的集成、與業務系統進行銜接的架構規劃以及公司的數據標準推動和把控。
- 數據分析師：以統計學背景為主，能够從數據中產生合理、準確的商業智慧報表。
- 數據科學家：以機器學習為背景，提供基於機器學習和人工智慧的資料分析產品和結果。
- 數據產品經理：負責公司內部數據能力的規劃和開發流程的協調，有時這個角色由數據架構師承擔。
數據中台業務團隊主導科技製定、業務部門共同研發應用層，這個優勢在很多頭部企業的核心能力上都已經得到了體現。
總而言之，我們做業務中台，需要從設計開始就思考業務狀態，一個成功的業務狀態，應該第一天開始就設計一些原則，這個原則有助於業務中台在後面發展的時候不至於走偏，有一個基準的方向可以遵守。 如果要評估中台需要花多錢，這是很多人都會問我的問題，我一般有三個維度可以介紹給大家，大家可以從這三個維度來回答這個問題：
1、依照實際需求進行估算，以大潤發為例，可導入嚴謹的研發流程。
簡單來說，企業一定要界定完自己的需求是什麼，才好進入到研發，否則可能導致的是項目需求變更，預算新增等等風險 這個維度就是讓大家好好思考中台的真正需求在哪裡。 而嚴謹且高效的研發流程，可以透過人天來評估成本。
優點：依據企業發展具體需求而定，能充分說明做一個中台實際上需要多少成本。
2、依照年度IT預算來測算，以年收入百億的公司來估算。
我們來算一筆帳，假設一個年收入百億的公司，企業的淨利潤為一個億，年度IT預算一般落在2-7%，假設這個企業是一個重視數位化建設的企業，其IT預算高達7%。 等於是把百億收入的7%，也就是700萬投入在年度的數位化項目中，而中台又是當年的重點專案，占了30%的預算，那中台預算的30%，即是210萬。 但問題來了，若以210萬來說，中台只能外包，且由於預算問題，失敗率較高。 畢竟這是一個百億收入的成長型企業，所以估計要做些適度的調整，不能全盤按照這個維度來製定計畫，但這個維度的評估方法有一定的參攷價值。
優點：依據企業發展具體需求而定，能充分說明作一個中台實際上需要多少成本。
3、依照過往經驗，並結合企業現況，預估一個自研的數據中台所需成本。
在數據中台的建設中，除了傳統的大數據團隊以外，還需要業務部門的積極參與。 這張圖，就是依據實際的情况，去算出成本應該要多少。 結果算出來，可能預估每年8000萬支出，假設以平均工資40萬計算，一年約需要4200萬的人工支出，加上硬體與運維費用，約莫8000萬。
最後提醒一點，數據中台建起來困難，維護起來更困難。
最後，回歸到CIO對於建設數位中台的需求方面，我的 建議是：
- 更合理的估算，將數位化納入戰略規劃溝通
- 依據數位化的投入產出及可能的帶來的價值進行充分的研究與分析
- 取得董事會成員及高層的共識
- 最終依據實際需求評估投入實施
- 召開會議對項目進行總結
為什麼會做這個分享，是因為太多朋友問我中台的建設問題，因此系統性的做一次分享。 最後，不論是數字化，還是中台的問題，都歡迎各位與我交流，王俊傑個人微信號jawinjawin。
