中台建设落地浅谈

一、前言

近一段时间有篇文章在讲阿里在拆自己的中台，反正说的是中台扼杀创新云云。刀本没有善恶？关键在于使用的人。用在厨师身上可以整出人间美味，用在杀人犯手里那当然产生悲剧啦。曾经从 thoughtworks 上面看过关于中台的第一性原理的文章，觉得挺在理的，文中讲到根据 Cynefin 认知模型，通过演绎法可以推论出：

中台所代表的企业架构向平台型演进的过程，本质上就是企业在发展过程中，随着对于市场信息认知不断提升，在不确定性中寻找确定性，持续在跨业务线探索通用最佳实践（Best Practice），并以中台层承载，并最终用于支撑和实现企业对于业务发展的快速响应、复制与增强的过程。

二、中台的作用

世上本没有银弹，如果你认为上中台是就能解决企业一切问题，那你是瞎了眼。但是阿里所推崇的中台就真的没用吗？首先，中台突出的就是 1）最大化复用以便快速复制、2）沉淀企业核心能力支持业务创新、3）反向推动业务侧往跨业务方向演进。

1、最大化复用以便快速复制

作为一个地道的程序猿，我们写的代码没有复用吗？有，我们天天写工具类呢，或者我们把它封装打包成一个微服务独立部署呢，毕竟 DRY（Don't Repeat Yourself）理念还是程序猿基本要求来的。但是公共代码被抽离封装出来后究竟有谁在用？一般来说就是本团队在自弹自唱罢了。其他团队能用吗？一般比较少，为什么？我认为有以下三方面吧。

1.1. 针对业务需求中的可复用模块的需求方与服务提供方的响应速率不一致

对服务需求方来说，既然有需求那肯定是对响应速度有要求。但是反观服务提供方，它的 KPI 决定了它们的响应原则一定是优先完成自己份内工作。服务提供方本没有错，错就错在团队职责没有被正确设置好。这样一来二去，各团队也对慢慢这种复用不感冒，因为支持力度和响应度不够。

1.2. 权责问题，毕竟 KPI 不一样

对服务提供方来说，优先提供协助给需求方对提供方带来何种益处？如果他们的 KPI 指标是没有承上启下的，从责任层面来说对团队发展是不健康的，因为没有约束，没有约束则代表没有责任。

1.3. 团队间 SILO（筒仓）的存在

在《边界》一书中讲到（原名：The Silo Effect：The Peril of Expertise and the Promise of Breaking Down Barriers），筒仓思维（silo thinking）的破坏力是巨大的。书中提到，由于筒仓的存在，瑞银集体内部即使在风险监管人员的巡查下还是没有发现账本中的风险，因此银行家们也无法发现风险。由于索尼公司的内部分裂和不交流，在新品发布会居然出现了 2 款功能类似的随身听产品，然后打败它的苹果却是因为其打破产品边界（即捅破筒仓）而获得成功。

曾经简单跟一名曾经在某互联网企业工作过的前同事聊过，团队虽然是按业务功能分开不同团队（如支付、产品、广告等），但是在 KPI 层面是相辅相成的。什么意思？就是 A 团队受理并完成 B 团队的需求能够对 A 团队绩效有积极意义，所以 A 团队也乐见其成并且协力相助。也只有在这样的绩效基础上，最大化复用才不是一个伪命题，否则中台只是自嗨搭建出来的一个漂亮的空中城堡。

因为团队间会有 SILO，除非是该条线的主管强力推进，否则进展是可以被预见的。那就活学活用“康威定律”，建设独立团队做共性萃取并推广，这样起码从组织结构层面巧妙的绕过 SILO 的问题。

2、沉淀企业核心能力支持业务创新

首先讲讲沉淀。具体怎么沉淀？谁对业务流程最熟悉？非应用开发团队莫属。

让听得见炮声的人来做决策。同样道理，让面对业务需求的应用开发团队来做萃取是最适合不过。但是具体应该怎么通过组织结构达成这一目标？我觉得不外乎以下几种：

“引进来”模式。就是建立一个业务中台团队，先派驻到各自应用开发团队负责日常需求开发，然后再把业务共性等知识到中台团队，协助中台建设。

“走出去”模式。就是从各自团队中抽一些骨干组建业务中台团队。大家毕竟接触了业务系统那么久，可以马上形成战斗力，这种方案效率是更高的。

“联络人”模式。还是新组建团队，也从应用开发团队抽人兼职负责中台团队的知识传递及修正，帮助业务中台团队成长。

3、反向推动业务侧往跨业务方向演进

中台建设完后，所有人以为就是“毕其功于一役”的这个“战役”已经完成了。正是因为中台这个复用的存在，这就注定了其他业务需要经常跟中台产品部沟通协助，再配合适当的 KPI，慢慢则会形成你中有我，我中有你的局面，部门间才能更加有“结果导向式”的互相配合。

三、中台是有使用成本的

所谓的成本意思是你得付出一些代价。很多人认为只要找个厂商或者组建个研发团队，匆匆上个什么中台就包治百病。殊不知，中台即使建设好后要想使用好还是有一些成本的。当然啦，这个是认知的问题，看你认为它是一个简单还是复杂的问题而已。但是实际上，很多时候在中台建设过程中，技术不是唯一的因素，还会有一系列的问题需要考量。

1、组织结构

中台建设往往带着明显的组织转型色彩。但是应该怎么转？

首先，总台是有业务属性的。如果缺乏专职的中台产品部，中台就无法进行建设规划，所有来的需求都是“打一枪干一炮”。好吧，我们首先建设中台产品部，但是建立后他们的 KPI 是什么？那些业务愿意接入？

接着，我们回顾一下阿里是怎么做的。首先，当时共享业务事业部是拥有聚划算这个巨流量入口，阿里高层要求所有其他电商平台如何要想接入聚划算必须得通过共享业务事业部。就是这样的一个点睛之笔给共享业务事业部一个抓手和窗口开展了真正的组织架构转型。从这里可以看出来，实际上一切就是利益驱动（首先这里讲清楚利益是一个中性词，不褒不贬），其他电商平台需要这个巨流量入口，共享业务事业部需要抓手转型，双方还是有一定的利益基础的。所以我们今天讲，中台转型除了设置个中台产品部还不够，还要让中台产品部与其他业务条线在利益方面是相同的或者一定程度是趋同的，这样才能慢慢转型成功。

2、需求管理

我认为中台也是一种战略，也是企业投资组合的一部分。中台系统只是“器”，倘若缺乏有效的需求管理这个“法”，实际上也是事倍功半。笔者所负责的其中一个团队前期虽然也是奔着建设可复用的服务中心，但因缺乏统一的产品经理，也没有整体产品规划，最终的 1.0 版本更多是把各种为了应对业务需求而硬拼凑起来的一堆功能；但是后面明确了由统一的产品经理专门跟进后，该服务中心的规划或定位才逐渐的清晰。由此看得出来，没有稳定的人员进行需求管理与规划，即使你有一个现成中台最后也会因为各种原因慢慢演变成“四不像”。

四、中台是一个演进的过程 

这里请抛弃“毕其功于一役”的想法，要拥抱打持久战的准备。我们要擅于用动态、发展的眼光看待问题。中台化建设本身就是一个持续迭代建设的过程。如果大家拿着 1.0 版本的中台需求原型进行建设，建成后就希望这个一成不变的支持这个不断变化的业务场景的话，那中台化建设一定在最后失败，就算不失败也会慢慢消亡。因为中台化建设本身也是一个持续的过程，任何过程是要基于 PDCA 的闭环进行管理的，这就好像我们做敏捷开发一样，没有最终的产品，只有不断优化的产品才具备强大的生命力。

从需求受理层面看，当我们一个需求来的时候，如果你只是准备用中台去套，然后你又说中台不支持但又不得不用（毕竟中台定位摆在这里），然后要求业务模式去适配中台现有功能，那肯定扼杀创新啦，因为那是形而上学的做法。

在我们受理需求的时候，应该是先去识别中台能承接的部分，其余的则通过其他系统支持。这就好像，例如公司本身是有一个现成的 B2C 商城系统、商品中心、支付中心。突然你接到另外一个业务部门的需求要做一个 B2B 的商城，那就要看具体的业务模式，但是如果考虑到 B2B 和 B2C 商城的共性（高内聚低耦合原则）还是需要做商品管理和供应商管理的话，可能就建议直接复用商品中心，但是前端的 B2B 商城则可能由于风格、购买流程的不一致而需要重新建设（支付中心也是一样的道路）。兴许有人会说商品管理和供应商管理模块也可能有改动，但是只要不违背高内聚低耦合原则的话直接在中台中进行适配改造也是合理的，毕竟架构本来就是一项追求平衡的艺术，它旨在技术、成本、资源、性能等方面进行平衡以便达到最高效的满足业务需求，所以具体每个业务功能究竟放在哪里确实要视具体情况而定。

从运营层面看，很多人认为业务中台建设好后就只需要一两个人运营维护即可。但实际上这个中台需要养分，如果没有持续性的对前端业务应用系统的“去粗取精”和“消化吸收”，这个中台迟早会因为失去活力和弹性也消亡。我们的前端业务实际上天天接触不同的运营情况，也有各种各样的业务想法，在前端运营过程中有失败的也有成功的。当有业务模式被证明是成功的时候，那就要迅速纳入到中台里面，以低成本高效率的复制到其他业务条线以便能够早于竞争对手投入市场，快速提升市场占有率而形成规模优势。

五、后语

中台有没有用，只是取决于你的目的。如果真的希望中台是一个解决企业一切问题的银弹，那确实因无法达到期望而被认为是无用；但是无论如何，这不妨碍它作为企业核心业务能力最佳实践的载体。