對于中台，很多小夥伴都有一些困惑和誤解，對于中台的理解還不是很深入。本文作者結合自己的實際工作案例，以産品經理的角度，與大家談談關于中台的價值及其建設規劃，希望對你有所啟發。

最近跟一些朋友聊起中台的相關話題，大家都很感興趣、各抒己見。

不過，我發現其中有不少困惑甚至是誤解。

今天，結合自己過去幾年在螞蟻規劃和建設“螞蟻AI中台、風控中台”的實踐，以産品經理的角度來對“中台究竟是什麼？有什麼價值？如何規劃和建設？如何支持好業務”等問題，跟大家做一個深入的探讨。

一、中台的本質和價值

如今一提到中台，很多人可能就警惕了。

不是都說“中台已死”、“都在拆中台”嗎？怎麼還聊這個？

首先，大家不要被一些聳人聽聞的标題和觀點所迷惑。

自己要有正确的立場和判斷，要先搞清楚事實和本質。

那就是，中台到底是什麼？

在百科詞條中，中台是這樣定義的：

中台，互聯網術語，一般應用于大型企業。一般是指搭建一個靈活快速應對變化的架構，快速實現前端提的需求，避免重複建設，達到提高工作效率目的。

盡管這個定義表述得不夠凝煉，也肯定不是100%準确——當然也不存在标準定義，但這個描述至少指出了一些要點。

一個要點是“大型企業、複雜業務”，一個是“模塊複用、提升效率”。

前者指出了中台适合的場景，就是公司有足夠的規模、有很多的業務。

如果每一個業務都從前到後搞一套系統的話，效率肯定比較低。

所以，就需要把各個不同業務中的共性抽取出來，做深做強，打通産品、數據和技術。

這樣，就形成了“大中台、小前台”的模式。即，前端做薄、靈活多變，船小好掉頭。

而且，當有新業務時，能夠迅速地用後台模塊拼接、搭建出來，不用全部重新開發。

字節跳動前幾年接連地發布很多應用，被譽為“App工廠”，也是受益于這樣的架構。

第二個要點是“模塊複用”，指出了中台模塊的本質，就是要高效複用。

這也是平台與中台的區别——很多人一直沒有搞清楚二者的區别。

平台可以隻有一個業務方，那是沒問題的，可以稱為專用平台。但中台一定是要服務于多個業務的，隻有這樣才能稱之為中台。

了解了中台的本質之後，我相信大家就能有獨立的判斷了。

可見，哪些盲目叫喊“中台已死”的人，顯然是沒有深入思考的。

的确，在前幾年中台概念大行其道的時候，很多小公司也頭腦發熱，自己搞中台，或者被忽悠采購中台。

最後發現勞神費力，絲毫沒有提升效率。

那是當然，你就一兩個業務，而且創業過程中充滿各種不确定性，三天兩頭調整方向，在這種情況下，你搞什麼中台。

在大廠裡面，也确實出現了中台過度的情況。

什麼事情，過度了都不好。中台過多、顆粒度太細，中台之間的銜接做得不好，肯定會大大影響效率。

可見，中台是否有價值，取決于企業的業務特性和所處的階段。盲目地“大幹快上”和“追漲殺跌”都是不明智的。

二、欲建中台，先建組織

談完中台的概念和價值，再來說說如何建設中台。

在這之前，先說說“人性”。

坦白地說，中台其實是“反人性”的。

中台就是要“合并同類項”、“拉通融合”，往往會把原來相似的模塊合并掉，這個自然會動了一些人的奶酪，影響了他們的利益。

戰略決定組織，屁股決定腦袋。

如果不從人性和組織的角度來思考，中台是做不成的。

如果你真的要做中台，隻有“一腔熱血”和“一張藍圖是”不夠的，你得先有适應中台戰略的組織。

如果中台涉及到的“業務、産品、技術”團隊還是一個個小閉環、小山頭，那麼中台是很難推動的。因為他們可以找出一百個理由說，我這個很特殊，不能中台化。

因此，為了推進中台，就要打破組織壁壘。把“業務、産品、技術”的團隊獨立出來，隻有這樣，才能實現“業務通、産品通、技術通、數據通”，才能真正從全局的角度去考慮問題、做頂層規劃，才能不僅僅考慮一個業務、一個團隊的利益。

及時把組織陣型調整好了，也隻能說是萬裡長征走了第一步。

三、千萬不能閉門造車

接下來，就是中台如何規劃的問題。

一個常見的錯誤是，中台隻是“産品、研發”的事情。

中台團隊閉關研發了幾個月，突然跳出來給業務說，“兄弟，我們搞出了中台核武器，你來用用”。

首先，這樣做也是反人性的。

憑什麼是你們産品、研發搞高科技、搞核武器，我們業務整天扛指标，幹髒活累活？然後扔過來一個武器給我們用，再讓我們證明武器很先進？比我們之前“人拉肩扛”高級？

所以，不要把中台和業務隔離，更不能對立起來。

相反，要讓業務廣泛參與到中台的規劃、建設、落地的全過程中。

要讓中台成為大家共同的事業。

如果哪天你發現業務團隊在讨論中台、在他們的彙報PPT以及月報中，大張旗鼓地提到中台産品模塊，那麼不要有什麼不滿的，也不要覺得人家在搶功。

你要理解，對業務團隊的考核，不光是要有業務指标、不出事，更要有“系統化、有機制、有沉澱”。大家一起搞出來的中台，就恰恰符合這個要求。

中台産品不屬于産品團隊、也不屬于技術團隊，而是大家共有的。

所以說，中台不斷露臉，你應該高興。

要大度一點，軍功章上有你的一半，也有我的一半。

而且，中台現在都是業務的孩子了，那麼他們還會整天無端地罵孩子、打孩子嗎？

中台“反人性”的另外一方面，還體現在人們普遍是不願意改變現狀、不願意學習新東西的。

中台肯定是會研發出新的産品，盡管可能“降本增效”，但畢竟要讓大家去學習和适應。

所以，如果人家從始至終沒有參與進去，隻是被動地被告知來使用，那麼積極性肯定是有限的。遇到一些bug和問題，怨氣也會很大的。

但如果他也是中台的一分子，那肯定會包容很多。

四、中台首先得“做抽象”

當然，中台服務業務，不能隻停留在意識、組織形态層面，更要落到實處。

中台要“從業務中來、到業務中去”。

中台的頂層設計是基于對業務、技術的深刻理解，而架構出來的。就是把共性抽出來，形成一個個模塊。

以螞蟻AI中台和風控中台來舉例。

一眼看過去，可能發現AI領域的算法、技術、應用很多，問題很複雜。

但從橫向鍊路來說，無非是“數據打标、算法開發、模型訓練、模型部署、模型管理和叠代”等等。

從縱向來看，有“文本（NLP）、圖像（CV）、視頻、機器人（智能會話）、知識圖譜”等不同的領域。

因此，你可以從這些抽象出來的鍊路和模塊來設計AI中台的産品架構。

對于風控來說，業務、技術種類也很多。

風控有不同的風險域，比如“盜用、欺詐、作弊、洗錢、賭博、内容風險、IoT”以及“國内、國際、生态風險”等。

顯然，風控中台不能直接按照這些風險域來規劃，而是要對林林總總的風險類型進行抽象。

仔細分析下就能明白，無論何種風險，首先要盡早地感知到風險的發生，然後再對風險進行精準的識别和決策，再進行處置（放過還是攔截、處罰等），機器判别不了的還要人工審核。

此外，風險運營人員經常要研究新風險、新案件，所以還要進行風險的分析、策略的加工。

因此，抽象出來的大概就是“感知模塊、識别決策引擎、處置模塊、審理模塊、分析模塊”以及一些諸如“數據、模型”等支撐模塊。

當然，中台模塊不是孤立的存在的，它們要形成鍊路，不同模塊之間要形成關聯。

也就是說，每個模塊首先要完成自己的本質工作，然後還能流暢地串聯、靈活地組裝。

中台模塊就像積木，不能隻是孤零零地擺在那裡，而要能方便地組裝成不同的形狀，滿足不同的需求。

這就需要中台模塊在設計時，能夠形成“組件化、模塊化”。

五、中台要“層次化”滿足需求

中台的模塊架構有了，如何更好地滿足業務需求呢？

首先，産品經理要謹記一點，用戶需求是不同的、有層次的。

因此，在用戶需求挖掘的時候，在中台産品設計的時候，一定要注意這一點。

以AI中台舉個例子。

每個業務團隊都想擁抱AI，實現“業務智能化”，但團隊的情況各不相同。有的有業務算法團隊、有的沒有，有連基本的技術人員都少的可憐。

所以，中台産品模塊要考慮到這些問題，讓産品能夠被靈活的接入、集成和使用。

于是，我們按照前面提到的模塊抽象，不僅形成了“NLP/CV/機器人/标注/知識圖譜”等模塊組成的AI中台産品矩陣，還抽象出了需求分級和業務賦能的“五級火箭”，從簡單到高階，依次包括“功能嵌入、API調用、數據訓練、模型定制、算法開發”等五級。

這樣一來，平台設計得足夠簡單易用、門檻很低，對方的産品、數據、運營同學都能用起來。

對于現成的模型，諸如NER、OCR、證照識别等，直接調用API即可，也可以把平台的頁面、模塊嵌入進去，不來平台也可以用平台。

業務方如果有深入的、個性化需求，可以來平台上訓練自己的模型，甚至定制開發算法。

業務需求得到了充分滿足，中台的場景就更多、用戶也更多，中台的價值就得到了充分的體現。

中台産品也得有品質

這裡，不得不強調下中台産品的設計問題。

有很多人誤以為中台、平台類産品不需要什麼設計，随随便便搭一個就行。

殊不知，任何人都會本能地抵觸醜陋、體驗糟糕的東西。

而且，你讓一幫同事天天面對一個爛産品，是多麼的殘忍。

其次，中台産品尤其是技術類中台産品，本身是包含很多技術原理和術語的。

好的設計能夠隐藏這些晦澀的技術點，能夠實現“把複雜留給自己、把簡單留給用戶”。從而極大地提升業務效率，也能夠擴展平台的客戶群。

最後一點，如果産品設計得不好，産品和研發團隊會反受其害——你會被用戶的咨詢、吐槽淹沒的。

所以，要做就做好點。

我當時對中台産品團隊的同學們說，能否讓你做的産品成為你的作品，甚至代表作。

六、不光要錦上添花，更要雪中送炭

除了做好規劃、做好設計，中台還得有更好的業務sense。

即，不能隻站在自己的角度，做“錦上添花”的事情，更要站在業務角度，為業務着想，多“雪中送炭”。

對于任何類型的業務來說，最重要的無非是增長：用戶/客戶增長、收入增長等。

對于這些問題，中台能否主動做些事情呢？

答案是可以的。

以AI中台舉例。

支付寶平台上每天有很多的營銷活動，有活動就要有文案，這讓運營同學很頭疼。

手寫文案肯定扛不住，而且也不容易實現“千人千面”。

那怎麼辦？

于是，基于業務的這個痛點，我們在常規的NLP平台之上，孵化出了“智能文案平台”。

在這個平台上，可以根據活動類型、文案風格等條件，智能地生成成百上千條有創意的、個性化的文案。

這不僅減少了運營的工作量，而且能顯著提升點擊轉化率，從而為投放活動的業務方帶來了很多新的流量和用戶，實現了業務增長。

在風控中台當中，也有類似的嘗試。

除了做好風控本質工作以外，我們還和商戶做聯防聯控，即輸出螞蟻的風控能力，讓商戶能更早地發現風險。

當然，作為價值回饋，商戶會在其支付渠道上首推支付寶。

這樣，就直接提升了支付寶的交易量和用戶量，為主航道業務帶來了額外的價值。

另外一個案例，是“圈用戶、圈商戶”的場景。

支付寶自己每做一個發紅包的活動，以及協助各地政府發放“消費券”的時候，需要首先圈出來優質的用戶和商戶，不能把錢發給壞人。

因為風控這邊積累了很多的優質用戶、商戶的數據，所以我們就将這個能力，主動輸出給業務，讓營銷活動快速、平穩地開展，保障了營銷資金的安全。

七、不光有“狠活”，還得有“科技”

中台不僅要解決好業務當下的問題，拼體力、幹“狠活”，而且要為未來業務的發展提前布局，搞出點“科技”。

要不然，中台還沒上台，就已倒台。

這裡面，還涉及到另外一個人性的問題，即技術團隊的利益和訴求。

他們的訴求是什麼呢？

就是你讓我做的需求，有沒有技術深度、技術先進性？

或者，更直白地，我寫的碼、發布的系統，能不能對自己發展和晉升有幫助？能不能“拿得出手”、能否讓他登上行業技術大會的舞台去“吹吹牛”？

誠然，包括中台和前台業務模塊在内的任何一個系統當中，都有很多工作是沒太多技術深度的。無非是涉及到業務流程、頁面交互以及增删改查之類。

我們絲毫不能否認這些工作的重要性，但如果隻開發這些東西，技術同學們肯定是不願意的。

買多少杯咖啡和奶茶，也不好使。

因此，在中台的設計當中，就要平衡好當下和未來。既要快速響應業務需求，也要基于業務本質以及行業技術發展的脈絡，來規劃出“有深度、有未來”的模塊。

以螞蟻風控中台舉例。

我們既按照業務鍊路設計了“風險感知、識别決策、處置、審理、分析”等中台模塊，來解決業務當前痛點。也基于風險以及技術發展趨勢，梳理、規劃了“智能反詐、圖風控、交互式風控、多方風控、終端安全”等平台和系統。

這些平台既解決了社會熱點問題，符合行業技術發展的趨勢，是熱門的技術領域，也有足夠的難度和挑戰，這樣技術同學們做起來就更有成就感。

當然，類似這樣有深度的事情往往需要更多的耐性和定力，需要多年的打磨。

一個月就能做完的事情肯定比較簡單，三五個月做完的估計也不會太難，難的是一兩年、三年五年甚至更久時間，才能做成的事情。

如此有深度的科技不光是生産力，也是商業。

這兩年，很多科技公司都在考慮“科技商業化”，将自己沉澱的技術輸出，做“To B”的生意。

這些有技術含量的中台模塊，往往也受到行業和客戶的關注，從而經過“技術→産品→商品”的孵化和打磨，最終成為一門生意，為公司創收。

結語

人在任何時候，都要保持獨立、理性的思考。

對于一個事物，盲目跟風、走極端都是有問題的。

中台能帶來什麼價值，中台要不要搞、怎麼搞，都得結合實際來做決策。

中台是一個複合型的課題，涉及到前線業務、底層模塊，還涉及到業務、産品、技術等衆多團隊。

中台不僅是業務問題、産品問題和技術問題，更涉及到價值、利益和組織的方方面面有關人的問題。

因此，要做好中台，就要全局觀、未來觀，還得要有耐力和定力。

隻有這樣，才能做成。

專欄作家

朱百甯，八點三十五，人人都是産品經理專欄作家。前百度品牌總監，著有《自傳播》一書，現在專注于人工智能以及産品設計等領域。

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,