中臺的崛起代表了一部分中國領(lǐng)先企業(yè)的“去 ERP 化”趨勢,從以資源集約化為中心走向以用戶價值為中心,從閉源單體架構(gòu)的商業(yè) ERP 套件走向分布式微服務(wù)架構(gòu)的業(yè)務(wù)開放平臺。本文將從微觀宏觀雙視角展開闡述,微觀層面以一個典型的訂單服務(wù)的演進,展示數(shù)據(jù)中臺業(yè)務(wù)中臺的價值和聯(lián)系;宏觀層面,縱覽企業(yè)后 ERP 時代的問題,分析中臺崛起背后的企業(yè)訴求。2019 年的中臺概念著實火了一把,繼去年購買了“數(shù)據(jù)中臺”的百度搜索指數(shù)后,昨天我又購買了“業(yè)務(wù)中臺”的百度指數(shù),可能是由于剛剛購買,全量數(shù)據(jù)還沒有統(tǒng)計匯總出來,所以當(dāng)我們在百度指數(shù)中,搜索業(yè)務(wù)中臺的時候,目前只有 4 月 6 日的數(shù)據(jù)。

即便如此,我們依舊能從這張圖能清晰地看出,中臺、數(shù)據(jù)中臺的熱度在 2019 年 5 月份開始崛起,在年底達到頂峰,已經(jīng)持續(xù)超越了數(shù)字化轉(zhuǎn)型的關(guān)注度。
在本篇文章,我不去重復(fù)中臺的各種概念和定義。這一點,我的同事王健給出了清晰的定義,“中臺是企業(yè)級能力復(fù)用平臺”。
從另外一個角度,歷經(jīng)了企業(yè) BPR,ERP 實施,EAI、SOA、J2EE、Web2.0、ITSM、ITIL、TOGAF、MDM、PLM 等傳統(tǒng)項目,再到現(xiàn)在的云計算、大數(shù)據(jù)、移動互聯(lián)網(wǎng)、區(qū)塊鏈、CDP 等數(shù)字化項目,在一個從業(yè)二十年的 IT 老兵的眼中,中臺的崛起可能不僅是“能力復(fù)用”,它所代表的意義是更豐富和巨大的。
在我的認知中,“中臺”這個概念的火爆不是曇花一現(xiàn),更不是機緣巧合,它是中國企業(yè)信息化發(fā)展的必由之路,是本土企業(yè)信息化歷史上的一個里程碑,它有以下兩個代表性:
“中臺”是國人自主提出并孵化成一個市場的原創(chuàng)概念 從 1999 年靠寫程序掙了人生第一筆工資開始,我所接觸到的所有的 IT 領(lǐng)域的概念,基本上全都是“舶來品”,中國的企業(yè)信息化市場的關(guān)鍵概念,包括大數(shù)據(jù)、云計算、移動互聯(lián)網(wǎng)、Web、J2EE、EAI、SOA、ESB、ERP、商務(wù)智能、數(shù)據(jù)倉庫等無一例外,都是從海外由咨詢公司或者大型廠商引入的,而中國的企業(yè)信息化歷程就是由這一個個關(guān)鍵概念牽引著前進的。
理論指導(dǎo)實踐,好的理論能夠統(tǒng)一愿景,領(lǐng)導(dǎo)行業(yè)的方向。好的概念能夠讓行業(yè)統(tǒng)一認知,形成共識,從而更快的規(guī)模化發(fā)展,比如云計算、大數(shù)據(jù)、ERP 這些概念,教育了眾多企業(yè)的高管,構(gòu)建起了中國數(shù)字化的基石。
在我的記憶里,中臺是第一個由國人自己提出,持續(xù)被關(guān)注,不斷走高成為現(xiàn)象級企業(yè)信息化領(lǐng)域的概念。
同時,通過行業(yè)的不斷討論和迭代,“中臺”這個概念,已經(jīng)像云計算、大數(shù)據(jù)一樣,逐漸成為了一個獨特的市場領(lǐng)域,眾多的中臺創(chuàng)業(yè)公司不斷涌現(xiàn),國內(nèi)企業(yè)都在思考并且實踐如何建設(shè)中臺,巨大的市場需求正在形成。
就在我寫這篇文章的時候,一個大家耳熟能詳?shù)目鐕髽I(yè)也開始思考數(shù)據(jù)中臺的建設(shè),希望做中臺相關(guān)的溝通,這說明,中臺的市場在不斷擴大,不僅在國內(nèi)本土企業(yè)受關(guān)注,在跨國企業(yè)中也有了一定的影響力。
雖然到目前為止,中臺的概念在中國以外的市場落地的案例還不多,但是作為國人自主提出,并且已經(jīng)孵化成一個市場的原創(chuàng)概念,中臺這兩個字,已經(jīng)創(chuàng)建了太多的第一,這兩個字足以在中國的信息化歷史上畫上閃亮的一筆。
“中臺”代表著本土企業(yè)數(shù)字化轉(zhuǎn)型理論的一個豐碑 在中臺以前,中國的企業(yè)信息化領(lǐng)域出的書大部分都是偏實操和工具類的書籍,比如 Office/Java/Python 等,什么《七天學(xué)會 Excel》、《Java 開發(fā)寶典》之類的,而介紹企業(yè)級架構(gòu)、方法論的原創(chuàng)書籍不多。對比美國的 IT 界,很多軟件大拿非常擅長總結(jié)抽象理論體系,比如敏捷、演進式架構(gòu)、微服務(wù)這些體系就是 Martin Fowler 和 Neal Ford 這樣的軟件巨匠提出并升華到企業(yè)架構(gòu)級別的。
而自從中臺興起,圍繞中臺架構(gòu)進行概念澄清、實踐剖析、案例分享的文章和書籍越來越多。從阿里巴巴鐘華先生的《企業(yè) IT 架構(gòu)轉(zhuǎn)型之道 阿里巴巴中臺戰(zhàn)略思想與架構(gòu)實戰(zhàn)》,到云徙科技的《中臺戰(zhàn)略:中臺建設(shè)與數(shù)字商業(yè)》,再到數(shù)瀾科技《數(shù)據(jù)中臺:讓數(shù)據(jù)用起來》,每一本書的邏輯自成體系,都從不同的維度闡述了中臺的建設(shè)方法論和案例實踐。從這個角度講,相對而言,在本土數(shù)字化轉(zhuǎn)型市場,中臺的理論體系化程度是比較高的,可以說是中國企業(yè)信息化領(lǐng)域理論總結(jié)的一個豐碑。
所以,中臺概念的崛起,絕對是中國企業(yè)信息化領(lǐng)域的一個里程碑式的事件,它對于企業(yè)信息化已經(jīng)帶來并且還在持續(xù)帶來巨大的推動作用。
當(dāng)我回顧這個里程碑事件的時候,我隱約感覺到了一個模糊的關(guān)聯(lián),這些關(guān)聯(lián)隨著思考不斷的深入,隨著與同行們不斷的碰撞越來越清晰,中臺的本質(zhì)是什么,它的發(fā)展將何去何從?
中臺的崛起是從“服務(wù)化”到“去 ERP 化”10 年前,阿里掀起了一場聲勢浩大的“去 IOE”活動,其本意是,在阿里巴巴的 IT 架構(gòu)中,去掉 IBM 的小型機、Oracle 數(shù)據(jù)庫、EMC 存儲設(shè)備,代之以自研或在開源軟件基礎(chǔ)上開發(fā)的系統(tǒng)。
站在技術(shù)的視角看“去 IOE 化”的過程,就是將原來的中心化的、封閉的 Oracle 商業(yè)數(shù)據(jù)庫軟件替換為去中心化的、開放的開源數(shù)據(jù)庫軟件,將原來封閉的 IBM 的主機、EMC 的高端存儲設(shè)備替換為以 X86 為代表的云化硬件設(shè)備。

對應(yīng)到典型 IT 架構(gòu)的層次,去 IOE 化都是在企業(yè)的基礎(chǔ)架構(gòu)層面,包括應(yīng)用基礎(chǔ)架構(gòu)的工作,也就是從 IaaS 到 PaaS,而應(yīng)用層并沒有太大變化。
但是,當(dāng)我們看中臺的概念的時候,我們發(fā)現(xiàn),中臺要解決是兩個方面的問題:業(yè)務(wù)中臺和數(shù)據(jù)中臺。業(yè)務(wù)中臺通過抽象,封裝可復(fù)用的邏輯,提升企業(yè)的響應(yīng)力,而數(shù)據(jù)中臺通過打通企業(yè)的數(shù)據(jù),構(gòu)建自學(xué)習(xí)服務(wù)的數(shù)據(jù)能力,讓企業(yè)更智慧,一個是應(yīng)用層, 一個是數(shù)據(jù)層,也就對應(yīng)到 Application 和 Data。
行業(yè)里普遍比較認同中臺的構(gòu)建就是業(yè)務(wù)數(shù)據(jù)化,數(shù)據(jù)業(yè)務(wù)化,也就是圍繞微服務(wù)架構(gòu)的過程。但是如果我們把業(yè)務(wù)中臺和數(shù)據(jù)中臺與過去二十年的信息化歷程關(guān)聯(lián)到一起,我們會發(fā)現(xiàn)中臺的建設(shè)可以分為兩個階段,第一個階段是“服務(wù)化”,第二個階段是“去 ERP 化”,而最終對于企業(yè)來講追求的是用新的數(shù)字化技術(shù)去替換遺留的 ERP 系統(tǒng)的過程。
目前很多企業(yè)所實施的中臺,主要的工作是將遺留的后臺系統(tǒng),比如 ERP/MES/CRM 的公共部分進行拆解復(fù)用,形成類似于交易中心、用戶中心,訂單中心這樣的微服務(wù)集合供前臺調(diào)用,從而保證邏輯的一致性同時更快的響應(yīng)前臺的變化。
這個階段,中臺以“通用能力服務(wù)化”為核心。如下圖所示,左邊是業(yè)務(wù)中臺,業(yè)務(wù)中臺將后臺的通用業(yè)務(wù)能力,比如用戶接口、訂單接口、支付接口等統(tǒng)一抽象成微服務(wù)提供給多個業(yè)務(wù)前臺使用,從而保證前臺業(yè)務(wù)數(shù)據(jù)化的過程的標(biāo)準(zhǔn)化、統(tǒng)一化,提升了業(yè)務(wù)數(shù)據(jù)化的一致性和準(zhǔn)確性,同時也加快了前臺的響應(yīng)速度。右邊是數(shù)據(jù)中臺,數(shù)據(jù)中臺從后臺獲取全域數(shù)據(jù),并且通過結(jié)合人工智能的算法技術(shù)挖掘產(chǎn)生業(yè)務(wù)洞察,并提供唯一的數(shù)據(jù)查詢和統(tǒng)計服務(wù)給到業(yè)務(wù)前臺和業(yè)務(wù)中臺,從而驅(qū)動業(yè)務(wù)朝智能化轉(zhuǎn)型,優(yōu)化現(xiàn)有業(yè)務(wù)同時轉(zhuǎn)型和創(chuàng)新業(yè)務(wù)。

整個這個過程,都是業(yè)務(wù)響應(yīng)需求的發(fā)展,進行微服務(wù)改造的過程。下面我們以一個最典型的訂單服務(wù)為例來仔細剖析這個過程,從而闡述業(yè)務(wù)中臺和數(shù)據(jù)中臺的關(guān)系以及他們的業(yè)務(wù)價值。
下圖是一個典型的電商訂單服務(wù)的流程,用戶在某電商自營 APP 下一個產(chǎn)品訂單,這個應(yīng)用負責(zé)把訂單數(shù)據(jù)保存到數(shù)據(jù)庫里。

隨著這個企業(yè)的發(fā)展,該電商企業(yè)拓展了多個渠道,構(gòu)建了其他的 APP,提供給用戶使用。于是,用戶下訂單就有了兩個方法,分別在不同的應(yīng)用里,比如自營 APP 和微信小程序,這樣最典型的兩個渠道。而真實的情況可能是一個電商企業(yè)會有非常多的渠道,有自營的,還有代運營的,還有線下的 POS 系統(tǒng),還有合作伙伴通過 API 接入的,多個應(yīng)用會同時創(chuàng)建訂單。這樣的情況下就會出現(xiàn)多個應(yīng)用都會創(chuàng)建訂單。

這樣帶來的問題很明顯:
- 數(shù)據(jù)一致性差,訂單數(shù)據(jù)分散在不同的應(yīng)用系統(tǒng)中,數(shù)據(jù)不一致,同步復(fù)雜。
- 維護困難,當(dāng)一個訂單邏輯發(fā)生了變化,所有的應(yīng)用邏輯都要重寫,帶來的很大的維護工作量,響應(yīng)慢。
在這種情況下,如何解決這些問題呢?
為了解決訂單數(shù)據(jù)一致性的問題,一般會在 OrderDB_1 和 OrderDB_2 之間做同步更新,從而保證用戶能看到自己的全部訂單。
為了能夠掌握全局的銷量情況,企業(yè)會構(gòu)建數(shù)據(jù)倉庫系統(tǒng),將不同系統(tǒng)的數(shù)據(jù)都通過 ETL 的方式抽取到數(shù)據(jù)倉庫中進行分析,這就是 OLAP 的過程。但是由于數(shù)據(jù)量比較大,處理過程復(fù)雜,往往 OLAP 都是 T+1 以上的響應(yīng)速度,也就意味著,比如企業(yè)要想看所有渠道的銷量分析報表,只能看到一天以前的,而不能看實時的數(shù)據(jù),如下圖所示。

上圖的橘黃色箭頭表示在線交易處理流程,是生成數(shù)據(jù)的過程,而綠色箭頭表示在線分析處理流程,是抽取處理分析的過程。
這是典型的數(shù)據(jù)倉庫和商業(yè)智能的場景,而這樣的數(shù)據(jù)利用的問題也是很明顯的:
- 數(shù)據(jù)分析不實時,不能夠?qū)崟r出報表。
- 數(shù)據(jù)倉庫往往都是單體架構(gòu),受限于數(shù)據(jù)的處理計算能力,擴展能力不強,往往只能分析一個階段的數(shù)據(jù)。
- 響應(yīng)慢,ETL 的過程依賴于預(yù)設(shè)的分析主題設(shè)計,當(dāng)要分析的數(shù)據(jù)結(jié)構(gòu)發(fā)生變化時需要重新設(shè)計抽取邏輯,導(dǎo)致響應(yīng)慢。
以上是現(xiàn)在很多企業(yè)現(xiàn)存的典型的應(yīng)用和數(shù)據(jù)利用場景,在這個基礎(chǔ)之上,業(yè)務(wù)部門提出了更高的需求,比如如何能夠?qū)崿F(xiàn)精準(zhǔn)營銷,如何能夠?qū)崿F(xiàn)動態(tài)的價格?
這就是數(shù)據(jù)中臺和雙中臺的典型用例和業(yè)務(wù)價值所在,下面我們用三個典型場景用例來闡述中臺服務(wù)化的價值。
數(shù)據(jù)中臺的典型場景用例:精準(zhǔn)營銷 下圖是典型的數(shù)據(jù)中臺的業(yè)務(wù)場景:精準(zhǔn)營銷。
利用分布式的數(shù)據(jù)架構(gòu)替換傳統(tǒng)的數(shù)據(jù)倉庫,將 ETL 的過程更換成 ELT 的過程,結(jié)合批流一體的架構(gòu),保證數(shù)據(jù)的全面覆蓋,源數(shù)據(jù)抽取,實時數(shù)據(jù)和歷史數(shù)據(jù)并存。
在這個基礎(chǔ)上,數(shù)據(jù)中臺借助機器學(xué)習(xí)等算法能力,構(gòu)建精準(zhǔn)營銷模型,能夠供前臺業(yè)務(wù)應(yīng)用直接調(diào)用,而不需要做成報表以可視化的形式提供給業(yè)務(wù)人員,業(yè)務(wù)人員根據(jù)自己的經(jīng)驗在去做手工的用戶運營。當(dāng)用戶在訪問商品清單的時候,根據(jù)用戶畫像、產(chǎn)品銷量等全域數(shù)據(jù),實時生成最新的產(chǎn)品推薦,通過數(shù)據(jù)中臺的 API 推薦給用戶。

這是一個典型的數(shù)據(jù)智能化的過程,通過數(shù)據(jù)中臺整合了企業(yè)相關(guān)應(yīng)用系統(tǒng)的全域數(shù)據(jù),通過分布式存儲和計算能力,結(jié)合人工智能技術(shù)和算法,為業(yè)務(wù)系統(tǒng)提供直接可調(diào)用的實時數(shù)據(jù)和智能服務(wù)。
實現(xiàn)智能化,是所有的企業(yè)希望達到的目標(biāo),但是智能化對于數(shù)據(jù)的質(zhì)量要求很高,而多個分別創(chuàng)建訂單服務(wù),導(dǎo)致的問題很明顯,而且隨著前臺應(yīng)用系統(tǒng)的不斷增多,業(yè)務(wù)數(shù)據(jù)化的過程越來越復(fù)雜,導(dǎo)致數(shù)據(jù)與真實的業(yè)務(wù)出現(xiàn)了很多的不一致和偏差。同時,隨著業(yè)務(wù)變化的速度越來越快,同時維護多個訂單服務(wù)的工作量很大,響應(yīng)速度越來越慢,這就要求對于所有的訂單服務(wù)進行抽象、復(fù)用和包裝,這就是業(yè)務(wù)中臺出現(xiàn)的原因。
如下圖是最簡單的業(yè)務(wù)中臺的服務(wù),也就是訂單中心的服務(wù),所有的前臺應(yīng)用當(dāng)需要創(chuàng)建訂單的時候,統(tǒng)一調(diào)用業(yè)務(wù)中臺的訂單服務(wù),由這個服務(wù)統(tǒng)一生成產(chǎn)品訂單,從而保證了訂單邏輯的一致性和維護的高響應(yīng)性。

數(shù)據(jù)中臺不僅為前臺應(yīng)用直接提供調(diào)用服務(wù),并且也能夠為業(yè)務(wù)中臺提供數(shù)據(jù)和智能的服務(wù)。
下圖是典型的雙中臺協(xié)作的場景用例:動態(tài)價格。

這個場景在很多需要實時計算動態(tài)價格的業(yè)務(wù)中存在,比如機票預(yù)訂和滴滴打車的下單服務(wù)中,每一個訂單的價格都是實時根據(jù)當(dāng)前的數(shù)據(jù)計算生成的。
如上圖所示,業(yè)務(wù)中臺統(tǒng)一為不同的應(yīng)用提供訂單生成服務(wù),而在生成訂單的過程中,需要根據(jù)不同用戶的情況,動態(tài)計算一個價格。這種情況下,業(yè)務(wù)中臺就需要調(diào)用數(shù)據(jù)中臺中的動態(tài)價格計算模型。這個模型從分布式數(shù)據(jù)網(wǎng)格(Data Mesh)中獲取產(chǎn)品、用戶等歷史數(shù)據(jù),同時獲取實時的訂單數(shù)據(jù),最終計算出最優(yōu)的價格,返回給業(yè)務(wù)中臺的訂單服務(wù)。
而這個動態(tài)價格的智能服務(wù)可以同時被業(yè)務(wù)中臺和其他業(yè)務(wù)前臺所調(diào)用,所以,數(shù)據(jù)中臺是同時為業(yè)務(wù)中臺和業(yè)務(wù)前臺提供數(shù)據(jù)和智能服務(wù)的。
部分企業(yè)目前所實施的中臺,都是和以上三個業(yè)務(wù)用例類似的場景,就是將一些共有業(yè)務(wù)流程做服務(wù)化改造,從而變成可以被前臺快速調(diào)用的業(yè)務(wù)服務(wù),提升業(yè)務(wù)的響應(yīng)力,讓業(yè)務(wù)更智慧。
當(dāng)我們看雙中臺服務(wù)化的過程時,不可避免地要面對很多已經(jīng)有了后臺系統(tǒng),特別是已經(jīng)有了套裝 ERP 軟件的情況。這個時候,我們要解決的就不僅僅是服務(wù)化幾個核心能力的問題,而是以 ERP 為代表的遺留企業(yè)架構(gòu)和以中臺為代表的新興企業(yè)架構(gòu)的博弈問題了,這時候,中臺的實施就進入了第二個階段。
企業(yè)中臺實施的第二個階段:“去 ERP 化”十幾年前,我作為早期做 BPR(業(yè)務(wù)流程再造)和 ERP(企業(yè)資源管理系統(tǒng))的顧問,經(jīng)歷了原來以進銷存為核心、系統(tǒng)分散數(shù)據(jù)不拉通的蠻荒階段。那時候的企業(yè)對于 ERP 的追捧,就和現(xiàn)在追捧中臺一樣。當(dāng)時要解決的問題是將企業(yè)的流程梳理清晰,做到資源的集約化管理,從本質(zhì)上講也是解決流程復(fù)用、業(yè)務(wù)能力化的問題,只不過那時的技術(shù)實踐方法是套裝軟件,通過 Oracle EBS 或者 SAP ECC 這樣的商業(yè)閉源軟件,開箱配置后使用,用國外成熟標(biāo)準(zhǔn)化的流程來驅(qū)動企業(yè)的業(yè)務(wù)。
曾幾何時,ERP 是企業(yè)現(xiàn)代化管理制度的代表,上了 ERP 表示企業(yè)流程優(yōu)化、資源集約化的成功,但是經(jīng)過了十幾年的發(fā)展,原來的 ERP 系統(tǒng)已經(jīng)不足以滿足當(dāng)今企業(yè)的訴求,主要原因如下:
- 商業(yè)軟件,響應(yīng)慢大部分的 ERP 系統(tǒng)是商業(yè)軟件,是按照 License 來授權(quán)的,企業(yè)只有使用權(quán),這就導(dǎo)致當(dāng)企業(yè)的業(yè)務(wù)發(fā)生變化的時候,需要找到原廠進行重新配置或者新開發(fā),響應(yīng)比較慢。
- 封閉架構(gòu),不開放套裝 ERP 軟件是封閉架構(gòu),技術(shù)不開放,導(dǎo)致企業(yè)無法對它進行大的功能上的擴展,只能像打補丁一樣,構(gòu)建一些外掛,而且效果往往都很不好。
- 單體架構(gòu),彈性不夠過去的套裝 ERP 軟件一般都是巨型單體架構(gòu),天生的彈性不夠,不能夠滿足持續(xù)增長的性能需求。
- 昂貴的升級和維護成本套裝 ERP 軟件的升級和維護成本一般來說都很貴,導(dǎo)致有的的企業(yè)抱怨,不上 ERP 會死,但是上了 ERP,費用太高,負擔(dān)很重。
過去,企業(yè)使用套裝 ERP 的核心原因是需要復(fù)制和遵循 ERP 軟件里內(nèi)置的那些業(yè)務(wù)流程,在某種角度上講,過去 ERP 系統(tǒng)的實施其實是“買流程送軟件”。
但是,中國的企業(yè)已經(jīng)建立了適應(yīng)中國市場特色的組織結(jié)構(gòu)和業(yè)務(wù)流程體系,而且互聯(lián)網(wǎng)的快速普及,導(dǎo)致原來靜態(tài),標(biāo)準(zhǔn)化的業(yè)務(wù)流程已經(jīng)不足以支撐企業(yè)的快速響應(yīng)。
這種情況下,一些領(lǐng)先的企業(yè)對于 ERP 這樣的核心業(yè)務(wù)系統(tǒng)的價值訴求從原來的固化流程到了快速響應(yīng)前臺市場變化的新階段。
而與此同時,ERP 這樣的以流程為核心的組織形式也轉(zhuǎn)向平臺化的組織形式,而這也是中臺的核心理念。
企業(yè)組織結(jié)構(gòu)從流程式協(xié)作走向平臺式協(xié)作 ERP 的實施過程中,會制定很多的流程、崗位、職責(zé),從而讓多個部門能夠在統(tǒng)一的流程下有機的協(xié)作起來,我把這種組織形式叫流程式協(xié)作,如下圖所示:

這樣的好處是,在預(yù)設(shè)好的業(yè)務(wù)流程、分工職責(zé)下,不同的部門做各自的事情。比如研發(fā)部門就關(guān)注產(chǎn)品的先進性,采購部門就關(guān)注采購的低成本,生產(chǎn)部門就關(guān)注產(chǎn)品的高質(zhì)量,我們默認為只要各個部門按照制定的流程和 KPI 協(xié)作,就可以實現(xiàn)企業(yè)的業(yè)務(wù)戰(zhàn)略。
但是,我們會發(fā)現(xiàn),這個圖是從企業(yè)內(nèi)部視角來看的,并不是從客戶價值視角來看的,天然把企業(yè)分成了外部和內(nèi)部。
而隨著互聯(lián)網(wǎng)的出現(xiàn),外部競爭格局越來越復(fù)雜,企業(yè)需要圍繞客戶價值來組織經(jīng)營,一些領(lǐng)先的企業(yè)倡導(dǎo),所有組織單元和業(yè)務(wù)部門都要產(chǎn)生客戶價值。
但是 ERP 時代的流程式協(xié)作就在客戶價值之間構(gòu)建了一堵無法逾越的墻,因為研發(fā)部門只關(guān)注技術(shù)的先進性,不關(guān)注客戶是否買單,而采購部門只關(guān)注低成本,不關(guān)注技術(shù)的先進性。每一個流程節(jié)點和業(yè)務(wù)部門重點關(guān)注的是給自己設(shè)定的 KPI,而不是客戶價值,導(dǎo)致局部利益大于全局利益。
如何打破這堵墻?
這不是一個簡單的事情,從原有的遺留系統(tǒng),特別是 ERP 這樣的套裝軟件中區(qū)解耦業(yè)務(wù)流程,做服務(wù)化改造本身是一個很復(fù)雜的工作,并且在改造的過程中,牽一發(fā)而動全身,很多企業(yè)會發(fā)現(xiàn),最終的結(jié)果就是會將原來的單體 ERP 系統(tǒng)拆解成為分布式的,去中心化的 ERP 微服務(wù)集合,我稱這個階段為“去 ERP 化”階段。
中臺建設(shè)對于一些已經(jīng)有 ERP 系統(tǒng)的企業(yè)來說,就是“去 ERP 化”,將中心化的單體 ERP 系統(tǒng)拆解成分布式、微服務(wù)架構(gòu)的開放平臺,而不僅僅是“能力復(fù)用平臺”。
在這樣的業(yè)務(wù)開放平臺的基礎(chǔ)上,能夠打破企業(yè)內(nèi)外部的邊界,讓所有的業(yè)務(wù)部門從后端走向前端,通過中臺支撐敏捷前臺,創(chuàng)造客戶價值,我們把這樣的協(xié)作形式稱為“中臺時代的平臺式協(xié)作”。

從資源計劃為中心轉(zhuǎn)變?yōu)橐钥蛻魹橹行?ERP 系統(tǒng)的全稱是企業(yè)資源計劃系統(tǒng)(Enterprise Resource Planning),顧名思義,是以企業(yè)的人、財、物資源集約化管理為目標(biāo)的系統(tǒng)。
ERP 系統(tǒng)的典型場景是流程的復(fù)用,定義業(yè)務(wù)流程模板,然后把一套業(yè)務(wù)流程盡可能的復(fù)制到不同的業(yè)務(wù)領(lǐng)域和客戶需求上,從而實現(xiàn)資源調(diào)度的集約化,是典型的計劃型經(jīng)濟的思路,強調(diào)標(biāo)準(zhǔn)化和資源的復(fù)用節(jié)約。
而在 VUCA 的市場環(huán)境下,企業(yè)面臨的是客戶越來越多樣化,個性化的需求,越來越強調(diào)以客戶為中心去動態(tài)的組織資源為客戶提供服務(wù)。
這就要求后臺業(yè)務(wù)系統(tǒng)能夠更加靈活的支撐前臺不斷變化,個性化的客戶需求,這和 ERP 系統(tǒng)的核心理念及本質(zhì)是相違背的。
這種情況下,原來的 ERP 系統(tǒng)必須要將以流程為獨立單元的模塊拆解為以客戶價值為獨立單元的模塊。
同時,這樣的轉(zhuǎn)變也帶來一個巨大的挑戰(zhàn),就是如何給員工打績效。
原來 ERP 時代的員工績效比較直接清晰,就是將業(yè)務(wù)流程績效分解到每一個崗位,比如完成率、審批率等。
但是,當(dāng)轉(zhuǎn)變成以客戶為核心的時候,如何度量績效呢?
企業(yè)希望每一個業(yè)務(wù)節(jié)點,所有的參與方都可以對齊到客戶價值,用產(chǎn)生的客戶價值來度量貢獻,這樣能夠更直接的激勵員工。
這是一個很好的愿景,但是實現(xiàn)起來是困難的,那就是對于一些后端賦能型的業(yè)務(wù)單元,如何將它們關(guān)聯(lián)到直接的客戶價值上,這里就需要利用全域的數(shù)據(jù)分析、建模,通過敏感性分析等算法技術(shù)來實時計算,這也就是數(shù)據(jù)中臺所需要提供的能力。
總的來講,對于那些擁有 ERP 系統(tǒng)的企業(yè)來講,中臺實施的深水區(qū)必然涉及到要重構(gòu)原有 ERP 系統(tǒng),因為傳統(tǒng) ERP 和中臺的核心理念是沖突的,所以我用“去 ERP 化”作為企業(yè)中臺實施第二個階段的名稱,不意味著一定是要拋棄 ERP 軟件,而表示要將傳統(tǒng)的以資源計劃為核心,以集約化為目的的業(yè)務(wù)系統(tǒng)轉(zhuǎn)型為以客戶為中心的業(yè)務(wù)中臺。
“去 ERP 化”的過程一般會分為兩個步驟,由于篇幅原因,這里我們簡單介紹一下:
一、將相對比較獨立的真正的企業(yè)后臺,比如財務(wù),人力資源這些模塊保留在后臺 ERP 系統(tǒng),其他的業(yè)務(wù)模塊基本上都會從單體架構(gòu)變成分布式的微服務(wù)架構(gòu),如下圖所示:

這個拆解重構(gòu)的過程,最重要的一個標(biāo)準(zhǔn)就是將原來的 ERP 流程拆解出可獨立提供業(yè)務(wù)價值的微服務(wù)。
在這個階段,我們認為,偏后端的 ERP 模塊,比如財務(wù)、人力資源,還是會保留的,拆解的目的不是為了微服務(wù)而微服務(wù),是為了能夠?qū)R和提供客戶價值。
二、一切應(yīng)用云化,應(yīng)用與數(shù)據(jù)分離。
在第一步的基礎(chǔ)上,我們展望未來,會發(fā)現(xiàn)有一個趨勢:最終,一個個的單體架構(gòu)的后端系統(tǒng)都會隨著云計算、大數(shù)據(jù)處理技術(shù)的發(fā)展,變成一個個的可獨立運行的微服務(wù)。
企業(yè)的后臺系統(tǒng)會被分解成一個個的分布式的微服務(wù)架構(gòu),能夠被管理、被編排、被治理,每一個微服務(wù)有自己基于云的數(shù)據(jù)存儲,物理上是分布式的。

我用下面這張圖來概括中臺發(fā)展的三個階段,最終我們發(fā)現(xiàn),對于那些已經(jīng)有 ERP 系統(tǒng)的企業(yè)來講,中臺的建設(shè)本質(zhì)就是利用微服務(wù)架構(gòu)構(gòu)建開放業(yè)務(wù)平臺來替換閉源單體架構(gòu)的 ERP 系統(tǒng)的過程。

中臺的構(gòu)建過程是企業(yè)轉(zhuǎn)型的過程,是企業(yè)從流程為核心走向以客戶為核心的轉(zhuǎn)型,是企業(yè)從以人的經(jīng)驗驅(qū)動走向數(shù)據(jù)智能驅(qū)動的轉(zhuǎn)型。
中臺概念的崛起和落地代表了中國部分領(lǐng)先企業(yè)逐漸走入了企業(yè)管理體系的無人區(qū),已經(jīng)沒有以前的西方先進管理經(jīng)驗可以照搬,需要的是快速試錯和高速響應(yīng)的能力。
而這一切,也許要從“去 ERP 化”開始,讓我們和過去的 ERP 說一聲“珍重”。
作者介紹
史凱,花名凱哥, 20 年企業(yè)信息化、數(shù)字化轉(zhuǎn)型和咨詢實施經(jīng)驗,從早期的業(yè)務(wù)流程(BPR)、企業(yè)資源計劃系統(tǒng)(ERP)的實施到云計算、大數(shù)據(jù)、PaaS 平臺實施、IT 規(guī)劃,為眾多行業(yè)頭部企業(yè)提供數(shù)字化轉(zhuǎn)型咨詢和規(guī)劃實施服務(wù)。曾在 IBM、埃森哲、EMC 負責(zé)企業(yè)信息化咨詢,目前是 ThoughtWorks 數(shù)據(jù)和智能事業(yè)部總經(jīng)理,精益數(shù)據(jù)創(chuàng)新體系的提出者,深度思考者和作者,是數(shù)據(jù)中臺、數(shù)據(jù)驅(qū)動的數(shù)字化轉(zhuǎn)型的倡導(dǎo)者和實踐者,2019 年被評選為全球 DataIQ100 的數(shù)據(jù)賦能者,騰訊云最有價值專家 TVP。
Facebook 早期工程師覃超和極客大學(xué)聯(lián)合開設(shè)的「 算法訓(xùn)練營·第 8 期 」下周一開營,課程內(nèi)容是極客時間視頻課的超集,它不僅涵蓋常見的算法面試題精講,還包括數(shù)據(jù)結(jié)構(gòu)和算法的理論知識的講解、算法在實際工程上的應(yīng)用,加入了很多高級數(shù)據(jù)結(jié)構(gòu)(比如 紅黑樹、AVL、跳表),以及很多高階算法,一次性將數(shù)據(jù)結(jié)構(gòu)和算法的方方面面講透。
同時訓(xùn)練營設(shè)計了一套陪伴式學(xué)習(xí)機制,比起直接告訴你答案,更希望授人以漁,教給你思考方式,讓你在有限的時間內(nèi),實現(xiàn)算法學(xué)習(xí)的突破,無懼任何互聯(lián)網(wǎng)大廠的算法面試。通過覃超老師線上指導(dǎo)的學(xué)員,拿到硅谷公司以及國內(nèi)頂級互聯(lián)網(wǎng)公司 Offer 的概率保持在 95% 以上。 AI 前線粉絲專享 ¥100 優(yōu)惠口令:AIQIANXAN ,僅限 3 天??
今日薦文
點擊下方圖片即可閱讀

2020年軟件工程現(xiàn)狀: Python或?qū)⒊蔀榈谝淮缶幊陶Z言,中國開源漲勢最猛
你也「在看」嗎???