通过在阿里的实践，谈一下中台建设的Why、When与How
我在文章 “想转型数据驱动，ETL是拦路虎？十年来的传统工作模式，该升升级了”中对企业内服务架构和现代化服务体系的特点做了简要的分析，可以看出，如果服务架构不能与日益发展、灵活多变的业务相适应，那么企业的发展一定会被拖慢脚步。
脱胎于名门阿里的"中台战略“，给现代化的服务治理能力带来一道曙光，一时间竟是洛阳纸贵，争相仿效。CIO、CTO、架构师们，阅尽千篇中台文，除了并没有茅塞顿开的感悟外，反倒被各种新概念、新方法论折腾的一头雾水，忙茫然失措。
那么，究竟什么是中台呢？我的答案是：我也下不了定义！但是我可以根据自己的亲身经历，来给大家说一下我遇到的场景和见解。
1. 一个例子看透中台价值
我曾在阿里旅行负责过营销系统，就从这里开说吧。举营销里一个最基础的业务场景，发优惠券。乍一看够简单吧：
发个优惠券，吸引用户来买东西，买完后，用券抵个价就行了。有什么可讨论的...
既然你都认为这么简单了，那么产品经理乐得其中：“这个需求，这周上线算了！”
等领完活儿，进去一看，发现事情比想象略微复杂一些：
优惠券根据出资方不同，分为平台券和商家券。平台券由平台（如阿里）自己出钱，吸引用户来买东西。商家券由平台内的商家自己出钱。
根据优惠玩法，又分为满减券、现金券、红包。平台发红包还涉及到纳税的问题....
再深入去看运营玩法，发现刚刚还是想少了，至少还有这些问题需要考虑：
券的类别：私有券 or 公共券。私有券需要绑定账号，公共券输入代码就可以使用
优惠券的名称：这里可以根据活动进行定制。
优惠券的面值：若是满减券的话需要达到条件的满减金额是多少？
发行数量：即这个批次的券一共要发放多少张？
优惠券的生效时间：就是券是从什么时候生效到什么时候失效。
用户限领次数：一个用户最多允许领取几次。细致点还会再分每天用户可以领取几次。
参与商品：这里就要确定下这个优惠券使用哪些商品。
需求分析到这里，你断定，这已经不是一个小项目了，等等，问题还没完：
用户领完券，在淘宝网浏览出行类商品的时候，需要显示出相关优惠券信息。即我们的优惠券信息要在淘宝网、而不是我们自己的某系统中显示出来...
用户拍下商品的时候，需要根据所有可用优惠券，计算商品实际价格。满减、随机减、现金减、红包的使用和价格规则都不相同，需要自己慢慢算，更不要说券的叠加使用。
用户支付的时候，系统还需要根据用户的支付方式，对优惠券做特殊处理，比如用支付宝付钱的红包，需要会支付宝红包做额外处理。
用户退款最麻烦，支付时用了红包，红包怎么退？即使能退，退的时候红包已经过期，怎么算？
好了，我们不往下分析了！
到这一步我们已经发现，这个系统功能之复杂、设计链路之长（从淘宝到支付宝）、运营策略之灵活，用见所未见来形容毫不过分，更不用说每年、每次运营玩法还不同。
如果从零开始，我相信我们是没法完成任务的，这不仅仅是工作量的问题，关键是涉及的业务太多，淘宝、支付宝、到双十一还牵扯到天猫，要做广告的话，还有阿里妈妈，在这几大巨头面前，我们还是个小弟弟，玩不起玩不起....
阿里中台的强大之处，在于它已经把营销系统服务化，通过统一营销中心发的优惠券，从用户浏览商品、到支付等各环节已经内置，用户体验与原生淘宝商品一模一样。
在此基础上，我们只需要封装自己的业务玩法就可以无缝对接。我们每个玩法的研发时间可以有效控制在1-2周。
这就是营销中台的力量，它提供的不仅仅是一次API调用，而是一整套完整的解决方案，业务线不想关心、也没有能力关心的问题，如资金税控、跨业务板块全链路打通、用户体验迭代升级、客服支持等。
中台有哪些特征？它面向业务、支持业务的快速创新，同时它又不与具体场景绑定、自己也有持续升级的能力。
请用相同的思路去解读其他中台模块，如支付中心、用户中心，你立刻就体会到它的内涵，它可不是一些功能的罗列和聚合：
2. 中台战略的Why and When
看到中台提供的强大能力后，那么，我也来一套！不要白不要。
我的建议是，且慢，中台是不是适合你，还需要进一步去考察，我们从两个角度来看：企业发展阶段、和创新驱动力。
开始之前，先问自己一个问题：我有创新焦虑吗？
什么是创新焦虑：一个企业的发展，取决于不间断、快速的创新时，它就会面临创新焦虑。当创新或试错的速度慢下来的时候，就意味着被超越和死亡。
创新与效率
企业发展越快，需探索的业务模式和场景就越多，但往往由于资源所限，一般只能选择少数几个进行尝试，这就产生了越来越高的机会成本。
机会成本：它是一种成本/付出，指在面临多方案择一决策时，被舍弃的选项中的最高价值者是本次决策的机会成本。
机会成本在一定程度上，考验了企业的决策力
在企业发展前期，产品的迭代速度，与研发的投入成正比，投入越多，研发效率越高。
然而，随着系统复杂度的日益增加，研发效率则无法再与投入成正比，会逐渐下降 -- 想想大公司病。
当一家公司的创新带来的价值，低于机会成本的时候，如上图的A点，就很危险了，因为选择失误，带来的损失是无法弥补的。这也是企业为何要保持活力和创新力的根本原因。
通过上图可见，要解决创新与效率的问题，有两个选择：
主动降低机会成本，在一个快速发展的公司内，这几乎是无法实现的。因为降低机会成本的过程也会产生新的机会成本
保持迭代效率的提升。这正是目前所有公司正在追求的
3. 我需要中台吗？
需要中台吗？
这取决于你现在面临的问题是什么，中台是妙药，但不包治百病。
中台要解决的问题，在上面两节通过示例和理论分析都已经描述了：它解决的是业务创新的效率问题。
你可能会说，从全局梳理资产也是中台的目标。我的答复是：构建公司数据资产中心只是中台发展过程中留下的痕迹，它的本质目标还是要赋能业务
根据创新效率与机会成本的关系，可以做如下的分析：
如果你的业务不需要快速创新：中台给你带来的价值有限，甚至系统的抽象、运维成本都比带来的价值要客观
如果你的业务以横向功能扩展为主：由于不同模块之间业务相似性太小，每次产品迭代基本上都是全新的投入，研发效率与人力投入基本上是正比关系。由于通过提高研发投入可以覆盖机会成本，因此眼下考虑的主要在某项业务中找到爆发点，中台并不是当务之急。
如果你的业务愿景很大，但还没开工仅处于规划阶段：通过上面曲线可见，在项目前期，研发效率一般是可以满足机会成本需要的，此时，由于并无技术积累，还无法精确预测业务真正运转起来后对系统的要求，空谈中台化还不如做好子模块划分和功能抽象来的实在。
如果你的业务已经在运转，事务总是block在研发上：中台化，可能能解决研发效率过低的问题，但是需要谨慎的评估，主要是评估目前业务的积累情况。
上面的分类也是不一而足，只是希望提供一个分析思路。
4. 中台战略实施路径
中台怎么建？
需要中台，和必须做中台，是两码事。我举个例子：
美国为了制造出原子弹，在曼哈顿计划中，同时列入了计算部门，他们的任务就是手动计算各种参数。他们也想到了用计算机来完成数以万计的机械算数，但是计算机EANIC在原子弹之后才制造出来。
当然，EANIC在后续氢弹的制造过程中发挥了重要作用
通过上面的例子，你已经现，有时候中台化本身的工作难度比业务还要大，在等中台到位的过程中，说不定，你的业务已经挺不过去了...
当然，如果中台能顺利实现，那么带来的收益将是指数级的，研发效率的上限将会非常高。
中台化的一般实施路径如下图所示：
在谨慎的评估和选择后，就要坚定变革的决心，因为中台不是一蹴而就，切忌朝令夕改
一个健康的发展过程是循序渐进的。在实施过程中，建议找某一项业务，或大或小，作为切入点，先把这项业务服务好。在服务的过程中，密切观察给业务方的反馈，在稳定性、易用性、研发效率、运维成本上一定要有质的提升，再考虑公司内全面推广。
自身的升级很重要。中台的好处，就是业务和基础设施可以各自独立演进和升级。比如某中间键可以在业务无感知的情况下，做到异地多活、增强业务创新空间，那么，业务团队还有什么理由排斥支持中台的建设呢？
总之，中台是一个循序渐进的过程，是一个服务化的过程，我们的落脚点始终是提升业务线创新的效率。
经过锤炼的服务，为新业务带来的创新效率，必定让人久久不忘。如阿里基于TMF协议的交易中台，为用户提供了可视、可管、可配的自定义服务：
汽车4S服务中，在老系统上做了一个月（未完成），新系统7天完成；
"五道口"（项目代号）业务中，在老系统中评估工作量两个月，新系统12个工作日完成；
饿了么业务中，老系统评估要两周，基于新系统2天完成。
支持业务如此快速的创新和试错，中台策略怎么会不成功呢？
5. 写在最后
中台建设的过程，是业务逻辑和执行逻辑解耦的过程，中台会升级为商业的操作系统，它向上提供面向业务、但又场景无关的模块化能力。
它产生的价值增益，就是操作系统和上层业务可以各自演进、互相成就！
然而，打造这个“操作系统”的过程，是一个费事费力、工程浩大的事情，需要三思而行，在谨慎的评估、并选择后，就要用坚定的信心去推进。
热门文章
*每次「在看」，都是鼓励* ????