对于中台，很多小伙伴都有一些困惑和误解，对于中台的理解还不是很深入。本文作者结合自己的实际工作案例，以产品经理的角度，与大家谈谈关于中台的价值及其建设规划，希望对你有所启发。

最近跟一些朋友聊起中台的相关话题，大家都很感兴趣、各抒己见。

不过，我发现其中有不少困惑甚至是误解。

今天，结合自己过去几年在蚂蚁规划和建设“蚂蚁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”的生意。

这些有技术含量的中台模块，往往也受到行业和客户的关注，从而经过“技术→产品→商品”的孵化和打磨，最终成为一门生意，为公司创收。

结语

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

对于一个事物，盲目跟风、走极端都是有问题的。

中台能带来什么价值，中台要不要搞、怎么搞，都得结合实际来做决策。

中台是一个复合型的课题，涉及到前线业务、底层模块，还涉及到业务、产品、技术等众多团队。

中台不仅是业务问题、产品问题和技术问题，更涉及到价值、利益和组织的方方面面有关人的问题。

因此，要做好中台，就要全局观、未来观，还得要有耐力和定力。

只有这样，才能做成。