2.4 中台解决方案的威力

通过前面篇幅的讲解，相信大家对中台的概念已经有了一定程度的理解。接下来我们就要聊一聊另一个话题：中台能为企业带来的价值。

从根本意义上来看，中台的核心价值之一就是可以大幅降低软件开发的边际成本。

要理解这句话，首先我们要弄懂边际成本是什么。

在这里我先为大家解释一下何为边际成本，边际成本（MC（Q））是一个标准的经济学术语。从概念性角度解释，边际成本指的是每一单位新增的产品所带来的总成本增加量部分。

还是有点难理解是吧？让我们看一个通俗的案例，这样大家就会明白了。比如说，今天我们要制造一部当今地球上技术含量最高的手机，该手机比如拥有透明机身、待机一年、支持全息投影通话等。在明确需求后我们便开始制造第一部手机，此时我们发现以地球上现有的技术是不被支持的，所以我们需要先组织技术人员进行技术攻关，在完成研发后开始进行产品生产线搭建、产品开模、工厂建设、生产流程设计、工人培训、试产。在这一切进行完毕之后，我们终于有了第一部手机。

统计一下，在第一部手机制作上我们一共花费了：设计费1亿元、研发费2亿元、生产线搭建费5000万元、生产流程磨合费1000万元、第一部手机成本（包含物料成本与工人成本）5000元。

但是在我们完成了第一部手机制作后，当我们开始生产第二部手机的时候，突然发现成本一下低很多了，因为此时我们不需要再进行研发与生产线搭建了，这些东西都已经是现成的了，所以我们只需要付出第二部手机的成本（5000元）就拿到了第二部手机，成本对比如图2-8所示。

当然，现在我们计算的是每部手机的独立成本，也就是从单个手机来看。此时让我们再站在企业视角上去计算整个项目的总成本，这两部手机的总成本：

100000000+200000000+50000000+10000000+5000×2=360010000元

我们发现，多生产一部手机，企业的总成本只增加了5000元，也就是边际成本只增加了5000元。此时每部手机的平均成本：

总成本/2=360010000/2=180005000元

如果我们要生产1000部手机，总成本就变为：

100000000+200000000+50000000+10000000+5000000=365000000元

每部手机的平均成本降为：

365000000/1000=365000元

而此时如果我们不断增加手机的产量，我们会发现手机平均成本会随着手机产量的增加而不断下降，而这种变化关系使我们发现两者可以构成一个如图2-9所示的标准函数曲线。

这就是产量规模化带来的效应，也是我们经常听到的一个词“薄利多销”。那么这类重复性生产有没有可能让边际成本变为负数呢？答案是有的，这就是所谓的边际成本递减事件。

事实上，我们介绍的中台模式就是标准的边际成本递减事件。就拿电商企业搭建中台的订单中心来看，有了中台后，公司新增项目时只需要接入中台的统一订单模块就完成了订单服务。从公司层面来看，本公司新增的业务线（如自营、第三方入驻平台等）的不同客户、提供的订单服务的基础设施都可以看作凭空出现的，不需要成本。也就是说，中台让我们在建设上实现了一次建设、不断复用，同时随着这一模块的接入方增多，边际成本会出现不断下降的局面。

所以通过这个案例，我们就可以得出两个结论：

基础设施的建设成本在后期可以通过大量的产品生成而逐渐摊平，让前期的投入成本无限趋近于零。

中台其实也就是我们企业的基础设施，同样符合上述边际成本递减的经济规律。

那么中台带来的边际成本递减究竟体现在企业业务中的哪些地方？具体说来，可以分为如下4类：

（1）提升内部服务的复用能力

通过梳理战略目标我们可以将公司现在和未来的核心能力抽取出来，而通过这个步骤我们能将每个能力从原有复杂业务体系中剥离出来，并集中核心力量将其变为一个个独立的标准化中间件，任何业务方需要使用时都进行统一的标准调用。（在本书的“实战：中台体系设计精髓”篇中，我们会来谈谈如何进行核心能力抽象）

这样做的好处是能让公司核心力量所发挥的作用覆盖全公司，举一个不太恰当的例子来说，一家公司内几乎所有的后端开发同学都能独立编写访问数据库并完成增删改查的功能，但是如果我们要求每次编写的数据库访问操作都是对数据库资源占用最小的，此时又有几个人能以这样的要求完成数据查询的功能实现呢？

而正确的做法应该是将这种进阶开发交由公司内的技术带头人，由他们做出最优解并形成可复用的工具以在中台中同步给全公司的基础员工使用，这样在后期开发中就可以实现公司的每个项目在数据库访问的部分都是以本公司内的最优解去完成的，这样带来的性能提升是不可估量的。

同时我们还可以将这些模块归为一处、统一管理，从而在更新时实现一处更新则所有项目都可以更新，大大提升公司内部项目的易维护性。

（2）提供全局化视野和全量数据模式

对于互联网企业来说积累的核心财富就莫过于数据资源了，但是由于项目制的原因，各个项目的数据被限制在本项目中流动。而很多时候在本项目中并不算是很重要的数据在别的项目中却变得非常有用，这种项目间的沟壑就让企业获取的数据变为一潭死水。

像电商公司的用户交易订单，从支付角度来说，我们更为关心的是用户的使用场景，也就是用户平时喜欢买什么东西，而对用户的资金进出不是非常关心。

而这个数据如果放在金融借贷产品中就非常重要了，我们可以通过资金的进出来分析用户的净值与本人是否有多次借贷等金融行为。因此支付部门的数据在这里就发挥了重要的作用。

此外，公司的管理者所得到的数据只能是各个项目的结果性数据，比如总收入、总成本，但是他没有办法去获取各个项目的直接业务数据。而中台这一工具可以让各个业务的数据都沉淀在同一套中台服务中，让数据可以打破项目隔离变为一个企业中可以被复用的资源，并且通过各个项目的资源形成一个公共数据池，方便进行全局的决策。

例如，在某公司自营电商项目中，我们通过长时间的运营已经获得了当前用户的用户画像，如年龄层、偏好、职业、消费能力。而假设此时公司需要新开辟一条主打境外电商业务的业务线，在中台的帮助下我们就可以利用在自营电商项目中所积累的用户画像数据进行分析，筛选出那些单均价高、偏好国际品牌的用户，面向他们进行精准邀请以完成项目的冷启动。

当然，这里描述的主要是中台概念中的细分领域之一的数据中台的作用，在后面我们还会详细描述。

（3）提升应用的TTM

中台的另一个重要的可感知作用就是能缩短企业的TTM，所谓TTM（Time to Market）就是产品从研发到推向市场所用的时间，对于企业来说这个时间当然是越短越好。

而对以往分散在各个项目中的共有部分进行统一维护后，我们在3个方向实现了统一：

专用术语含义统一。例如，在项目A中定义了“会员”这一对象，用其指代在公司中购买了付费服务的用户群体，则在公司其他的所有项目中“会员”将都是这一含义。不会再出现在项目B中“会员”指代普通用户而付费用户被称为“VIP”，但在项目C中“会员”又指代本项目中的所有用户这样混乱的局面。

结构化表达统一。在实现过程中我们也将使用统一的数据库存储方式。例如，将会员信息存储在特定的User表中并使其与数据库字段名称统一，并统一定义“会员”这一对象。要存储的属性有会员名称、会员等级、会员性别、会员昵称、会员编号等。从而使不同项目在使用“会员”这一对象时，都能有标准的格式去使用，这样就方便同一对象数据在公司内部流转与功能复用。

业务身份统一。利用中台，我们可以将业务中一些承担相同业务的模块抽取出来进行整合。例如，我们在会员购物阶段要输入支付密码完成用户下单确认，在登录注册时需要输入用户口令完成用户身份校验。这两个场景中虽然业务功能看似不同，但实际上其中的用户身份确认是同一个业务功能。而我们完全可以将这两处的密码校验抽取出来，剥离掉原来的业务属性，统一成一个密码校验模块以进行统一维护。这样在以后的新功能开发过程中我们就可以直接调用、完成开发。

（4）统一用户感知

不同的部门由于业务发展的时间长短不同，因此在积累用户体验细节上也会有不同。而新孵化的项目却可能因为诞生时间短、对用户群体的了解不够细致而无法给用户带来良好的体验。

就拿某公司产品的注册登录功能来看，如图2-10所示，诞生时间较长的App （右图）由于经历过多次迭代，用户体验被优化得较为完善，当用户使用第三方登录后会在用户退出后提示用户上次登录所使用的方式（例如，这里提示上次登录方式为微信）；而反观相对年轻的App（左图），它没有此功能，当用户有不同授权登录时就变得很难回想起自己的上次操作了。

这经常会造成一个现象：同一家公司的产品体验会有天壤之别，让用户对公司的整体品牌认知无法加深。而通过中台，我们则可以将前台的交互流程进行统一管理，让任一公司项目在使用各种模块与组件（如登录组件）时，直接使用公司最新迭代的产物，站在巨人的肩膀上进行开发。

在竞争日趋激烈的互联网行业中，如何低成本又快速地完成业务创新去占领市场是每个企业所追求的方向，而中台解决方案的出现给我们当下的互联网企业带来了一个全新的发展思路。