现在再讨论中台问题不知道算不算炒冷饭，但是我确实最近一段时间才开始从事相关的工作，查阅了一些资料结合一些自己的思考最终决定写一些只言片语。
要不要做中台？
我一直觉得军事上的规则和策略因为具有敏感的意义和价值所以从合理的角度来讲可以适用于很多领域，比如:让能听见炮火的人指挥战斗、只有具备敢使用核武器的胆量，才能不战而屈人之兵等等。
人口的国家，找几个人组成一个巡逻队基本就可以满足日常的国防需求，所以同理业务规模小的企业是不需要中台的，那是不是大国就需要建设“炮火群”呢？也不尽然，比如智利，狭长的国土地形，一面临海，一面对着多国的边境线，很难建设一个功能统一、强大的“炮火群”满足截然不同的个性化防卫需求，所以我的结论是如果一个公司的业务规模达到一定规模，业务模式在不同的产品线上大致雷同，日常的管理维护、升级迭代成本对公司的盈利造成了比较大的影响，那么中台化势在必行。
这样的公司多不多呢？以我目前的视力所及是多的。举个栗子？这里开个小差，提出一个观点如果不能找到合适的栗子，要么你对这个观点理解还不够深刻、要么这个观点就是有待商榷的，至少目前这个时间点还不适合拿出来讨论。
拉回来看看这颗栗子，一个水果店，经营状况良好，但由于老板动手能力强、又迫切的想扩大业务规模，就自己动手建设了一个小程序，把生意做到线上，结果效果良好，隔壁的蔬菜店得知之后，也请店主建设了一个线上的销售工具，水果店主调研了一番后发现，把自己的小程序复制一份，修修改改就可以了交付了，并且赚取了可观的酬劳，肉店、服装店都来了，水果店主发现自己精力不够覆盖复制后的修修改改了，结合拿到的酬劳考虑，可以为每一个客户专门招一个技术人员来建设，前期走的也非常顺，因为有源源不断的客源进来，支付了技术人员的工资之后还有足够的利润，但是好景不长，随着线上业务的普及和技术的成熟，市场上竟然出现了竞争者，分流到自己这里的新增系统建设需求也没有多少了，前期积累的利润很快就被几个技术人员的薪水消耗的所剩无几，可是已经交付的诸多系统还有一些升级迭代需求，也是一笔不错的收入，显得比较鸡肋，继续运营耗时耗力，利润微薄，放弃又实在舍不得，这个时候中台就要应运而生了。水果店主把各个业务线上的技术人员集中在一起，把系统重复的部分抽象出来，重新建设，建设完成之后原来90%的工作量都不需要专人维护了，1个技术人员可以满足多个店铺的升级需求，多余的人力可以开辟一些新业务，增加一些其他收入，水果店主的软件生意又回到了正轨。单就这个例子而言，技术人员可能会说，你设计系统的时候为什么不考虑兼容性，为什么不能提前抽象化一些，这样就可以避免后边的尴尬了，确实，这个小栗子是可以靠一些专业的设计能力去覆盖，但是谁也没有预测未来的能力，如果第一个蔬菜店主没有找上门，你前期设计的过于复杂，实施成本提升、交付时间拉长，可能第一版水果店的线上工具都胎死腹中了，何谈未来。在商业逻辑上，先低成本试错、随着业务发展逐渐调整的模式是更常见的。所以我看需要中台化的公司不在少数。
目前中台的建设有两种声音，一种是中台无限好，一种说中台完全就是妖魔鬼怪，我鸡贼的发现说中台好的基本是建成了、受益了，说中台是妖魔鬼怪的大多是没做成、没做好，又付出了比较多的成本，气急败坏、歇斯底里。所以在我看这个问题不是在讨论中台要不要建设的问题，而是在讨论怎么才能建成、建好？
参考了一些中台建设成功和失败的案例，总结了几点注意事项，下面请听我一一道来：
第一步要判断我们自己的企业目前是不是到了上述例子中的历史进程、我们的产品线是不是冗余程度比较高，这个判断由谁来做？当然是企业的老板、至少是高层管理，只有站到了足够的高度，才能看清企业的发展阶段和各环节的支出收益比，才能决定中台项目要不要提上日程？什么时候推进？但是这个过程基本上是迅速的、坚决的，因为老板们是先有切肤之痛，才有济世良方，这也是中台概念能大行其道的主要原因，另外发散一下，互联网进入下半场，跑马圈地、价格战换取用户的时期在大多数业务领域已经是过去式了，下半场更多的是深耕存量用户、业务，精准运营、降低成本、提升利润率，中台概念提供了这样的可能，所以成为风口。
第二步就是怎么做了，这里边各企业个性化的部分很多，没有制式的标准和方案，那就意味着失败的可能性也多，再分开说一下：
1、业务和中台边界的划分
看过一个文章中说这个边界的划分直接影响中台建设的成败和建成之后的意义，我深以为然。但是各个企业业务千姿百态，组织结构也错综复杂，没有通用的解决方案，但是有一个框架可以遵守，那就是取最大公约数、不要取最小公倍数，中台建成之后和业务的交互模式是：业务端保留自己的定制化需求和开发、通过轻量的对接可以实现快速的推广、试错。与之相反的两种情况是业务什么都不需要做，也什么都做不了，中台支持定制化开发，这个是最小公倍数的方案，那么无非是把各业务线的代码挪到中台来写而已，很难大幅降低工作量，还有就是中台只管技术抽象，完全不考虑业务，最后业务串联开发量仍然很大，完全跑不快。简单一句话：做全部业务和完全不做业务的中台都是耍流氓。
2、中台建设团队的成员组成
这里说两个极端，一种是完全启用新人，或找有经验的外包团队做，请原谅我很难相信他们可以精准快速的找到各个业务线的最大公约数，另一种是完全由业务线的成员抽调组成，由于先入为主的思维方式，具体负责业务的成员会习惯的想我需要这样的功能、需要那样的功能才能实现目前的业务，这也是不利于对共有部分进行抽象的，所以各兵种联合作战的组织结构是我比较认可的，其次，在人员组成相对合理后，让项目组成员充分的了解项目背景、未来愿景和困难程度显得尤为关键，当然只要有人的地方就有江湖，为了提升沟通效率、落实项目意图、增强执行力，做不到完全理想化或者采取一些强制化手段也未尝不可。营造一个众人拾柴火焰高的氛围可以事半功倍，这在所有工作中几乎都是适用的，只不过中台项目总体沟通量大、涉及沟通链路长，团队协作才显得尤为重要。
总而言之、言而总之，中台建设是一个有指导思想但是没有标准工作步骤的工作，是需要公司领导层、中台建设者、各个业务线在各个时期分工合作，群策群力的，它足够复杂也足够有威力，需要智慧和胆识，如果各方面时机成熟的的确确是可以做的，也是能做得成的。
