中台之路，从平台到中台的思考与实践（二）

关注
发布于: 2020 年 04 月 22 日
接上一篇 《中台之路，从平台到中台的思考与实践（一）》 中介绍了我们中台建设的前半段经历，随着中台建设的深入更多更棘手的问题也逐一显现。且我们接下来的填坑之路。
问题：服务边界不清、重复建设、缺乏规划有中台建设经验的朋友不知道是否有遇到如下问题：
中台化建设的目标之一就是避免各项目重复建设，但随着中台服务的增多，各中台服务边界定义不清晰，团队利益左右导致中台服务本身存在功能重叠。
如上图，这是个很意思的现象，中台建设搞着搞着就离初心越来越远，这不是中台方向的错误，人心使然。由不同团队建设不同的中台服务，每个服务的初始版本都可以是“泾渭分明”的，但是谁不想提升下影响力呢，于是版本越迭代重叠的功能越多。
这一问题的根源在于各中台服务源于一个个具体的需求，没有自顶向下做好顶层设计，服务规划不合理。所以才给了各服务建设方过多的自主权，导致要么重复建设，要么复用度不高。
填坑：自顶向下做顶层设计、自下而上做服务建设原因明确了，解决的方案自然是：自顶向下做顶层设计、自下而上做服务建设。
看起来很简单吧，但真的简单吗？很难，非常难。这需要业务、产品、研发三条线的通力协作，注意这三条线还是跨产品线、跨公司的，要对集团内所有的业务产品做统筹。这之中的投入、难度各位就可以想象了。
笔者在中台建设的后期也着手这方面的工作，虽然无法把所有业务都纳入顶层设计，但抓了几个重点业务，效果还是不错的，这里举一个示例。
如上图，以我们的电商与保险业务为例，当时电商已在规划设计电商中台，包含了商品中心、订单中心、供应链等多个服务，而彼时保险业务也在重构IT系统，包含了保险门户、经代展业等多个产品。如果我们没做顶层设计，那么这些业务会独立发展，没有交集，但好在这两个业务是中台顶层设计的试点，我们做了业务顶层设计，由业务推导到产品，在做产品顶层设计时我们就发现，保险门户、经代展业业务与电商有着比较多的重合，它们都是卖商品的，所以电商中台的很多能力进一步抽象后就可以很好地支撑到保险业务，于是我们做了多次的探讨，电商中台的定位也从原来只支撑电商业务拓展到对电商、保险在内的在线交易全业务支撑。
这就是我们做业务与产品统筹化的顶层设计带来的更高复用度代表，有了产品的顶层规划，在技术顶层设计上我们更能有的放矢地按产品域划分我们的产品服务域，抽象我们的共享服务能力。
问题：自顶向下做顶层设计如何执行监管自顶向下做顶层设计的重要性大家都懂，推进的难度大家也都理解，决策层也下定决心要往这方向走了，但我们要如何确保这一模式是可执行可落地的呢？
每个人、每个团队、每条业务线、每家公司都有自己的“小九九”，这是很正常的，不是说决策层一句“充分授权、坚决执行”就可以解决问题的。
填坑：架构委员会这之中涉及到太多的利益瓜葛了，笔者觉得主要要从两个方向化解：
明确利益分配，中台化建设一定会涉及利益的再分配，这需要协调好各关系方，要明确、摆正新格局下的利益关系，要放到台面上说清楚，对不予配合的坚决处理
要有强有力的抓手，上一条是大方向层面的，“防君子”，这一条是在执行层面的，“防小人”，一定程度上这个更重要
笔者的抓手是“架构委员会”，它由业务、产品、技术个领域的专家组成，在架构之初做对应的顶层设计，在执行阶段负责项目审核。
一个典型的流程如下：
业务负责人发起项目立项申请
PMO 核准立项
产品经理/业务架构师完成需求调研产出《需求说明书》
技术经理/技术架构师完成技术架构产出《高层设计》
架构委员会根据《业务顶层设计》及《产品顶层设计》判断需求是否合理，是否有共性，划分清楚业务域及前/中台边界，提出《需求说明书》及《高层设计》的修正要求，如有必要将此业务补充到《业务顶层设计》或《产品顶层设计》中
架构委员会根据《技术顶层设计》及《高层设计》明确前/中台的服务设计及各服务边界
项目经理着手需求排期并输出《研发计划》
按裁剪后的敏捷做日常管控及进度跟踪
阶段性交付验收
整体交付验收，验收方有架构委员会、业务提出方、研发团队等
PMO组织结项
可看到这个流程中将我们前面讲的PMO制度、敏捷流程都结合了起来，在项目立项、结项时架构委员会有绝对的权力，这样架构委员会就可以根据顶层设计统筹项目建设，在很大程度上保障了项目立项的合理性、项目建设的规范性。
问题：团队怎么考核这又是个“老大难的问题”，前面笔者提到6S标准时说是为了评定中台建设的好差，但如果没有相应的考核机制跟进仅有评定结果也就起不到促进的作用。
绝大部分公司的研发考核做得都很差，因为研发过程有很多的不确定性，思维往往需要发散，过多的考核设计可能会限制了人的能动性，但过于宽松的考核又可能圈养一批“小白兔”。
填坑：项目导向OKR考核？考核机制上笔者坦言我们做得很不到位，从最开始的公司统一考核到尝试中台项目导向的KPI考核，效果平平。后来笔者思考“项目导向OKR考核”，这个想法未有落地，但值得拿出来探讨。
OKR本不是为考核设计的，那什么叫OKR考核，为什么又是项目导向的？思考的点比较多，所以还是会另辟一文着重讨论。
小结回顾：One Team, One Platform为什么说自顶向下做顶层设计很难？为什么考核体系建设效果不好？本质上这涉及到了中台的组织治理，组织治理必定会带来利益格局的变化，至此中台建设进入了深水区。
可以说组织治理是大家都认为重要但却又最想回避的事，组织的中台化完全可以独立成专题讨论，后续笔者也会进一步阐述。
笔者可以说是用了一个比较“取巧”的做法，用架构委员会及流程优化代替了大规模的中台化组织，实现了相对平滑的组织治理。
如上图，至此我们的中台体系多了重要的一个环节：组织治理。
如上图，作为组织治理的抓手，架构委员会决定了公司中台建设的方向及各项目建设的指导与审计，是中台建设的事实权力机构。
现在的中台化建设看上去又比上一小结完善、丰满了很多。这样的中台建设已相对成熟，但是笔者感觉还是差了一个重要的内容……
问题：中台建设的本质目的是什么在中台建设的中后期，笔者时常在思考：中台建设的本质目的是什么？我们常说回归“初心”，这个本质目的就是我们做中台的初心。
也许大家会觉得这个很好回答，中台的目的不就是减少重复投入、提升交付质量、加快版本迭代、实现业务打通嘛。的确，这是本文一开始就提到的动机。但是笔者觉得这个目的还只是表现，算不上本质的诉求。
笔者思考的结果是：中台建设的本质目的是为 更高效地赋能业务，为其提供全面、稳定、快速的需求处理能力。 中台是业务发展过程中自然而然产生的，一切的目标都是为了使能业务。
有了这个定义后笔者不禁陷入迷思，业务建设的目标是创造利润，中台既然是为使能业务那么 中台应该为业务创造利润，这是它的价值，但目前它只是个成本中心！
填坑：中台服务产品化研发团队是企业的成本中心，而中台团队更是成本中心中的成本中心。在中台建设初期这不会是问题，但如果要让中台成果保值增值，那么势必要让其独立发展。
所以在中台建设后期我们着手将中台团队划到一家独立的公司，这是第一步，在财务上与各业务导向的公司划清界线。当然在相当长的一段时间内中台团队还需要各业务公司输血，但同期笔者也在规划“中台服务产品化”。
在上文笔者一直说我们中台输出的是各类“服务”，这是较为技术的描述，比较纯粹，但笔者想要中台由成本中心向利润中心过度，所以提出了服务的产品化，产品化是对服务的包装与组合，可设计定价策略，叠加上计费、套餐，使用方可以订阅付费。
如上图，这一方案最明显的变化是中台团队新增了产品部及运营部，产品部负责需求调研、产品功能设计、产品定价策略；运营部负责产品的推广、售前/中/后跟踪反馈、产品定价调整反馈（后期也可以考虑产品定价划给运营部）。
而这一变更的IT系统支撑又正好落到Galaxy这一业务信息化操作系统上，呼应了前面的建设思路。
中台建设总结经过了一次又一次的填坑，我们的中台建设一步步地完善，到最后可以说是完成了华丽的蜕变。
如上图，我们补了中台建设的最后一块拼图：运营管理，形成了技术、管理、运营的闭环。
整个过程错综复杂，本文也仅为概括性的描述，“魔鬼在细节中”，中台之路并不好走，实施之前也请各位三思。最后总结几点吧。
先问自己几个问题：
我们的业务到了非建设中台不可吗？有没有更简单的做法？
公司的决策层是否了解中台并理解其背后的风险、实施的难度吗？
中台建设的短、中、长期目标是什么？保障措施是什么？
公司内有没有人可以扛起中台建设的大旗？
如果这些问题都想清楚了，确定要建中台，那么有几个原则（底线）一定要把握：
中台建设是一把手工程，是企业战略，决策层要倾力支持，各条业务线、分子公司要积极配合
中台建设组织治理先行，中台化的组织、考核制度要明确、利益要摆平
自顶向下做顶层设计、自下而上做服务建设，两手抓，两手都要硬
中台要体系化，标准化，要有制度指导及保障
由成本中心向利润中心转变很重要，中台建设3分开发7分运营
希望本文可以为正在或是即将建设中台的同仁带来一些思考，笔者也会为文中提及的一些重点撰文进一步发散探讨，欢迎关注。
﻿
Important
本文描述的是互联网企业的中台建设，传统企业或是说产业互联网企业的中台建设有其特殊性，切不可对号入座，这块后期也会有专题讨论。
﻿
原文链接：http://www.idealworld.group/2020/04/16/thinking-and-practice-from-platform-to-middle-platform-2/
﻿
关注我的公众号
﻿