凱哥：企業數字化平臺戰略之實戰解析

問：數字化平臺規劃和IT架構規劃的異同點？

答：我認為，首先這是兩個不同緯度的東西。IT規劃是一個咨詢服務的類型，數字化平臺戰略，是企業運營管理組織的一種模式，從文章中我總結的數字化平臺戰略包括三部分：

企業組織的平臺化；

企業信息架構的平臺化；

商業模式的平臺化（生態）。

我們目前提供的數字化轉型Advisory服務中，囊括的是數字化平臺規劃內容。傳統的IT規劃，是過去10年市場上最火熱的服務。大多數體現在企業內部管理流程的提升，以及如何高效化，所以傳統的ITSP里面出現最多的詞是集約化、精細化。

那時候因為企業的信息化建設重點在于建設內部管理系統，比如ERP，MES等，都是構建企業的業務基礎架構，就是讓企業的業務能夠運轉，能夠開始賺錢的系統和應用。所以IT規劃那是更多關注在企業內部，先做BPR然后在做ERP實施，加速企業流程自動化，然后到了互聯網的出現，企業的供應鏈，傳統的封閉上下游的形勢被數字化打穿。

企業對于外部市場，外部客戶的敏捷度要求提高，僅僅關注內部的管理，績效，優化內部的流程完全不能滿足數字化時代的要求。原來傳統的IT規劃做的是業務基礎架構“是大后臺”，在互聯網的沖擊下，我們現在做的數字化平臺是“大中臺”，這兩個一起支撐快速敏捷的前臺業務，所以現在的數字化轉型咨詢規劃，更關注用戶，關注產品，關注市場。

問：平臺化的過程中是否會進行業務調研和業務流程梳理？梳理的目的、方法論、及相應的產出？對業務的梳理力度？

答：平臺化的過程會進行業務調研和業務流程梳理，更為準確地講，要因不同的客戶的情況而定。

傳統的IT規劃的弊端在于“太重了”，一個規劃做3-6個月，大型企業可以做一年。但當時“重”的原因是因為要構建標準化的業務流程，所以一個規劃中基本上要分析到3-4級業務流程。設計的很細致，這在當時是行的通的，因為業務變化慢，所以你可以深根細作。

如今，市場變化太快，我們講究業務敏捷，講究快速迭代，這種情況下業務調研和流程梳理是為了了解現狀和短期的線性變化，但是對于稍微遠一點的“明天”，其實，調研和梳理都用處不大，必須做出MVP，上線，拿用戶數據來驗證，來反饋，來迭代。

所以我建議現在數字化，互聯網化的產品，我們要重視的是如何快速獲得客戶的反饋，如何快速的推向市場，這恰恰是平臺化的目的，把很多可重用，可復用的技術、內容都抽象形成平臺，用服務的方式提供給前端，然后產品部門、數字化營銷部門，可以像搭積木那樣快速構建，快速發布，同時平臺本身提供公用的監控，運營等服務，所以平臺化的調研和梳理，更多的事關注所有業務條線的共性需求。

問：在平臺化規劃中是否會提前出業務能力模型？業務能力模型在平臺規劃中的地位及作用？如何推演能力能力模型？產出示例？

答：業務能力模型，這是銷售過程的手段。比如，對于我們做咨詢服務的而言，在售前的過程中，很多時候包裝一個Model，說這是我們的經驗總結，是案例的體系化結果，很有作用。

對于一個企業來講，我理解，業務能力模型就是這個企業的核心業務戰略，是在一個固定的時間節點內業務的高度提煉結果，用來指導企業發展和運營的理論體系。但是不意味著他是一成不變的，在數字化運營的時代，他是隨著數字化變化的。而當數字化足夠充分的時候，最后會進入智能企業時代，這個能力模型就交由大數據智能分析中心去幫助決策了。

問：是否做源系統調研？調研遵循的方法論是什么？從那幾個層面調研、調研的顆粒度是否有相應的分類？分類是依據什么樣的標準？

答：源系統調研會有，而且必須有，這是為了提煉大平臺的業務域，進行平臺結構化設計而必需輸入的。調研的顆粒度這個就因客戶的不同有不同的選擇了，我的建議是一層層像包洋蔥一樣，但是每一層要保證有它獨立的價值。

問：oltp那個圖不清楚。

答：重新插入一張：

問：對外接口易用性和通用性的沖突，很多專有的東西，開發和業務平衡如何做？

答：我理解易用性實際上有時包含專有性，平臺解決的是API層面的東西，最前端不同的渠道，不同的用戶體驗是可以百花齊放的。業務專有接口易用性就好，這就是微服務設計的顆粒度的問題。我在構建PAAS的時候，分成技術組件服務、平臺技術服務、業務公用服務和業務專業服務，就是為了解決通用和專業的問題。

而且我過去15年之前在做大平臺中心化的平臺，就是ESB、SOA，現在是走向去中心化，但前期業務領域沒有劃分清楚就比較難做，我是盡量劃分一個大的層，日后再分離清楚，獨立通用的劃分，幾個選擇，微服務是最小粒度的獨立價值單元。所以，專有通用是相對而言的，不需要太為了設計而設計。

問：數據應用團隊經常發現數據問題，然后走一個超級長的逆向過程來查找問題。用什么機制能夠改善這種情況，從數據源頭確保數據質量？

答：這是一個傳統的數據治理的問題，CRUD是傳統數據治理的一個方法，就是從源頭檢驗數據的全生命周期，創建、更新、利用和刪除。我覺得保障數據質量的事情其實是一個有意思的話題，數據質量的源頭是來自于應用系統，數據質量不好，說明是OLAP系統、業務系統設計有問題，才有了數據質量的問題。否則已有的數據都應該在業務系統中解決掉了。

在如何改善上，首先我們要判斷“數據質量”這個定義是什么，是有了不應該的數據還是數據出現了不一致性，還是不同緯度的數據有了誤差（丟失、損毀）等等。數據應用團隊發現數據問題，我的經驗是，是要從數據源頭，業務流，用戶歷程圖中找到問題。

還有一種補償機制，我們可以用其他維度的數據來倒推和修正局部數據的問題，因為數據之間是有關聯的，就像量化交易中，很難拿到全量的股票交易數據，丟數據很正常，行業里的做法就是利用趨勢，經驗，關聯自己吧數據修正或者補償了。

平臺化，是數字化的的必然結果，是構建商業生態的具體辦法，這方面希望和大家多多探討。

問：我理解了數字化平臺和IT規劃雖然在兩個維度上，但是都需要兩個前提，要了解業務（流程）現狀，系統現狀？

答：了解業務的TOBE和ASIS是很重要的，只有這樣，才能夠提煉和抽象平臺化的復用功能核心組件。了解系統現狀，是為了規劃和設計平臺的技術架構，這個回頭我可以分享給大家一些我的參考文檔，方法論在現在的時代，越來越精簡。原來埃森哲賴以生存的ADM，是IT工業化時代的產物，但是現在的方法論，更多的是來自于快速反饋和快速變化。

問：搭建一個數字化校園的平臺的話，雛形應該如何搭建呢？怎么可以保證，自己的第一步沒有錯？

答：首先我們來看一下數字化校園的平臺，你是為一個學校服務，還是為多個學校服務，做成一個校園行業云。如果是為一個學校服務且有一些遺留系統，我之前設計過K12的數字化校園的PaaS平臺。目前我們所推薦的構建生態的平臺的幾個核心點：開放、易接入。

第二，能夠為平臺之上的應用和業務提供可復用的資源，所以，那個平臺的主要作用是：

整合，管理資源池，是可插拔，彈性擴充的。

設計和構建服務框架，并且將業務API構成API Factory。

有快速構建業務應用的能力，從而能夠滿足最前端的業務需求。

比如，最底層可能是遺留系統。學生信息管理，教務系統等，這些系統之上是微服務層。抽象出一個個可服用的有獨立價值的微服務，同時，將各系統的數據抽到數據湖中，提供分析決策實時分析的功能。平臺要提供快速組裝構建，上線的應用集成構建能力，最前端是eas，企業應用商店，用戶可以用同樣的體驗，接受不同的渠道的服務，回頭后面的文章我會我畫一個數字化平臺的邏輯結構圖。

問：對于業務和市場都非常穩定的一些傳統企業（比如說一些特殊領域的國字頭企業）他們對于數字化轉型是否有足夠的動力呢？

答：他們當然有動力。前幾天我和一個500強的CIO還在聊，高層動力很足，但是恰恰是體制的約束，不過數字化技術會打破這一切的桎梏。比如，原來銀行的壟斷地位，現在被數字化支付技術打破，現在我出門不帶錢包也不會緊張，全球化的同時就是數字化帶來的全局沖擊，必須用數字化的方法來解決。現在各行業里，最有動力的是傳統制造業和零售行業。

（以上內容轉自GitChat，版權歸GitChat所有，轉載請聯系GitChat，微信號：GitChat，原文：《青云王煜：QingStor工作原理解析》）

本文轉載自異步社區。

5G教育 企業數字化

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。