这是“技术领导力”的第210期分享
编辑/Emma
阿里研究员--玄难，曾在《从应用到中台--业务平台的演进》的分享中提到，阿里中台化主要解决4个问题：
1、信息获取成本高
2、互联互通成本高
3、服务具有不确定性
4、低水平重复建设
如何来解决这些问题呢？可以去看一下传统的建筑行业和互联网本身的基础设施建设。基本上靠三个东西来共同解决一个复杂生态的协作问题：
1、协议标准、运行机制。
2、满足标准的分布式执行单元。
3、中心化的控制单元。
比如说移动互联网，我们现在之所以上网能用手机，它的根本是什么呢？网络的协议，就是我们整个对网络的理解，它是最基本的思考。
然后我们有很多设备，不管是什么品牌的手机，只要满足3G协议、4G协议，就可以插上卡上网。也就是通过这张sim卡确定了我们的身份，从运营商控制网络上获取了控制信息。知道我们是谁，能不能上网，网络速率等等信息。
01
阿里中台建设的基础协议
回头来看阿里的电商生态，就是要根据对商业的理解，把一些基础协议梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？领域服务和领域服务之间的流程链接标准是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。
电商业务中台由一系列：业务能力标准、运行机制、业务分析方法论，配置管理和执行系统以及运营服务团队构成的体系，提供各业务方能够快速，低成本创新的能力。
02
中台基础设施：中心化控制单元
中台建设需要一个中心化控制单元，就是我们的运营平台。它主要由协议标准、能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局，把控细节。
其中能力地图是一个最基础的设施，要能把电商生态里面的能力都呈现出来，并在过程中不断的优化完善。就象我们现在出行离不开XX地图一样，今后所有的业务方需要做业务规划，业务创新，都可以到这儿来寻找需要的基础能力。
为了能将业务逻辑本身与实现逻辑分离，可以将业务逻辑下发给不同实现的执行系统，引入竞争，方便业务平台的改造升级，我们要将控制信息从业务平台中抽离到业务中台，以业务身份为主线来进行组织管理和呈现。并以生态角色的视角来重构信息架构。这样的变革对我们原来的系统架构提出了更高的要求。
通过业务中台化，我们把所有业务的数据汇集沉淀。每个业务它是怎么出来的，出来之后做了哪些业务需求，业务活动，每个业务活动的效果是怎么样的，都可以沉淀下来。
当一个新业务来了之后，我们就可以让他看到前人成功和失败的经验。逐步可以做一些系统建议，建议他怎么去做营销活动，怎么做效果分析。这样我们能通过数据最终反过来支撑我们的业务创新。
业务平台是在最基础技术和前端大家能感受到交互技术中间的一层。这一层不是外部消费者和入门级技术人员能直接感知到的。但是这一层才是真正制约我们整个商业发展速度的核心地带。业务平台如何能支撑几千种业务，几万人在同一个时间里面进行变更，这个对业务业务的抽象能力和系统架构能力的要求都是极高的。
03
中台化的核心目的是降低成本
阿里中件间&业务中台 总监，谢良纯，在采访中提到，中台化的核心目的是降低成本。成本可以从两个维度看，一个是资源浪费方面的成本，即公司有三四个业务线都在做同样的事情了，那技术上实现能不能融合可复用的部分？另一个则是时间成本，即新业务能够足够敏捷地去使用既有的技术模块去做探索。
实际上，实现中台化的环境是相当苛刻的。连Supercell 的 Paananen 自己都说，他认为Supercell 的经验不是对所有公司都有效，有它自己的特殊性。他觉得 Supercell 的每个员工，都是能在外面成立公司自己当老板的，因此这种精英文化和中台化在公司得以保持。
国际知名咨询公司罗兰贝格高级合伙人王欣曾表示，当企业发展到一定规模，一定会开始思考两个问题：第一，组织是否存在重复建设和资源浪费；第二，如何沉淀企业核心竞争能力，以更好地支撑新业务的发展。这也是许多企业选择中台的原因，中台在本身定位上，具备了以上先天优势。
04
有了前台和后台，为什么还需要中台？
行业观察员王健，曾撰文分析企业为何需要中台，企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。
大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。
我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。
总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。
中台很像Pace-Layered中的SOD，提供了比前台（SOI）更强的稳定性，以及⽐后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。
中台作为变速齿轮，链接了用户与企业核心资源，并解决了配速问题。
有了“中台”这⼀新的Pace-Layered断层，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”⽀援。
所以，企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台，业务中台和组织中台等等）。
05
中台建设要避开哪些“坑”？
阿里专家谢良纯在采访中曾提到，现在在中台建设里面，常见的一些“坑”，有以下几个：
1、要真正树立一个认识：中台是企业 IT 变革的一个起点，而不是单纯认为，我就是做一个项目，我搞一个采购中台，就解决了所有的问题，非也。你要深刻意识到它是变革的关键，认真去做战略规划，应该采用什么样的技术、什么样的平台、什么样的人员的配套？需要有这样统一的规划。把一个项目当成一个中台去做，这是不合适的，但如果倒过来，我规划了一个中台，做一个项目的试点，这是对的，所以这就是一个认识的问题，不见得多投多少。把项目当成中台去做，这个“坑”是很多人容易踩上的，这是一个最大的坑。
2、第二个“坑”发生在选择中台的技术平台时，很多人想，我先选一个便宜的能用的平台，以后我再选一个复杂的、更全面的平台。事实上，他们不知道，这就跟“种菜”似的，一旦菜长起来了，你要把底下土壤换了，这几乎是不可能的事情，一般要推倒重来。你一定要相信一点，如果开源软件就能简单解决这么复杂的大问题，阿里还养那么多技术专家干什么？在选择技术平台这一块，这是一个大家踩的最多的一个“坑”。
3、第三个坑，我认为也是一个坑，我觉得大家对试点、试点项目这块不太重视，往往会抱有这样的想法“反正是试点、就试一试“。在中台建设里头，我觉得试点项目是非常重要的，你一定要抱着必胜的态度去做试点。因为中台的建设会涉及到技术升级、业务升级、组织升级等很多变化，你只有抱着必胜的这样一些态度去做试点，那这些相应的变化，你才能应对好，否则到最后你就凑合做个试点，大概率是失败的。
06
中台建设难题一：中台团队离业务远
公众号作者刘飞曾撰文指出，中台团队离业务远的问题。
为什么中台化的难度是：技术<数据<业务<组织？因为越往后，越需要业务团队的介入，越要有业务认知才能做到中台。而中台团队，天然就是离业务远的。
各公司跟中台团队的协作，都存在很大的低效问题，一线的前台业务团队，要反复与中台沟通，才能讲清楚业务需求的背景，在大公司，跨部门协作都会徒增成本。另外对于中台业务团队来说，长期离业务很远，没有成长性，在判断需求时也不准确，很难获得前台业务团队的信任。
久而久之，就变成了中台团队纯支撑、被动接需求的状态，成为“鸡肋中台”。更大的问题在于，中台团队的价值就是整合需求、抽象能力的，在对用户和业务不够了解的前提下，这块就会做得特别吃力。如果是多个前台业务的需求有了冲突，中台团队未必能做好协调，多方要反复沟通扯皮。
针对这个问题，通常有两个解决方案：
第一，中台职责直接由最大业务方来担任
像某找房App的中台模块，就是由二手房先行推进的；而大多数通用的乘客司机产品流程，在滴滴也都是快车先发起的。最大的业务方离业务足够近，能自己决策判断大多数需求，更加高效。
这样以来，就从“硬找一个中台团队来收集大家需求”变成了“老大哥发挥余热，把自己的能力共享出来”，具体要怎么用，仍然是各自团队来决策和执行。
第二，让中台团队做业务闭环
这只适用于少部分情况，即中台业务本身可以自闭环。常见的比如各公司的账号体系（包括注册登录）、阿里的支付和订单流程、滴滴的地图和导航。这些业务与其它业务的关联度不大，可以解耦，可以自己完成从用户到业务的认知和决策，那就可以独立出来自己做，其它业务希望使用的时候，对接通用接口就可以了。
而大多数中台团队负责的业务不太容易自闭环。比如滴滴不同业务线的接单流程，就很难抽象出来让中台团队直接闭环自己做；或者像阿里不同业务线的商品部分、订单流程部分和支付部分可以抽象，但用户体验方面，不同前台业务差异太大，则很难抽象。
07
中台建设难题二：中台需求优先级难排序
互联网技术和管理专家 黄哲铿，曾撰文阐述过这个问题主要的两个解决办法：
建立以价值为导向的需求治理机制
基于OKR的需求聚焦与创新
第一，建立以价值为导向的需求治理机制
以价值为导向的需求治理机制，其目的是把有限的开发资源，投入到更有价值的项目上，该机制分成几个部分：
建立需求管理闭环。以价值为导向的需求治理机制，是在需求提报环节，提出该需求的价值预估，即这个需求将给业务带来什么样的价值，这些价值要能够量化、能够追踪。比如，一个结算系统需求，价值是：提升客户对账效率20%，上线后会来验证效果，看看是否达到预期。
整个闭环，分成：提交需求、排期开发、上线运营、需求调整，4个环节。
在提交需求环节，需求提报方要给出可量化的价值预估。
在排期开发环节，开发团队将需求池里的需求按价值大小进行PK，价值高的需求会排在前面，优先安排开发资源 。
上线运营环节，对该需求的价值进行验证，验证的结果将影响需求提出方的信用等级，信用等级将用于需求PK阶段，作为加减分项。
需求调整环节，也将价值做相应的调整，形成新的需求，反复迭代，形成流程的闭环。
制定需求优先级的准则。从紧急程度、重要程度将公司的需求分成三个等级，P0为优先级最高，P2为优先级最低。如下图所示，横坐标按重要程度，分为三类：公司战略项目、各部门重要项目、非核心业务项目。
例如：公司战略项目和部门重要项目，同时又非常紧急的，这类项目是P0级项目。其它类型项目，你可以轻易的对号入座了。
开发资源冲突解决办法。在协商未果的情况下，自下而上层层升级，直到问题解决。此外，跟业务方的月度需求沟通会，季度需求复盘会，这类正式沟通会议要形成常态。
第二，基于OKR的需求聚焦与创新
什么是OKR？
OKR是一种战略目标任务体系，是一套明确目标并跟踪其完成情况的管理工具和方法，由英特尔公司发明。
OKR由一个需要极致聚焦的明确目标和量化该目标的数个关键结果这两大主要部分组成。
O是Objectives，KR是Key Results，OKR就是Objectives and Key Results，即目标与关键结果法。
OKR由英特尔公司发明，安迪 · 格鲁夫解释道：
这种目标管理的两个关键词是 “目标”和“关键成果”， 它们分别对应着两个目的： 目标是方向， 关键成果需要得到评估， 但是最终结果显而易见，根本不需要出现 “我做了这个吗，或者根本没做？” 那样的争论，是或否，就是这么简单。
英特尔按OKR方法，制定战略，并将其转化为可实施、可协作的项目。
简而言之，OKR让决策者和公司的其他成员总是能够把时间和精力聚焦在最重要的任务上，从而完成公司的使命。
在OKR的目标和关键结果制定过程中，有一个非常重要的环节，叫做“对齐”，指的是每一次制定完OKR之后，要看看你上级的OKR，跟你定的OKR，是不是方向一致的，这叫“向上对齐”。
一旦出现了开发资源冲突，就把大家拉到一起，把各自的OKR列出来，看看我们是否在同一个方向上聚焦，如果不能达成一致。就把上级领导的OKR拉出来，看看他的OKR聚焦哪个方向，甚至看公司CEO的OKR，通过聚焦目标、对齐的方法来解决开发资源冲突。
08
本文要点小结
中台建设的基础协议
就是要根据我们对商业的理解，把一些基础协议梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。
中台的基础设施：中心化控制单元
就是运营平台，它主要由协议标准、能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局，把控细节。
中台化的核心目的是降低成本
一个是资源浪费方面的成本，即公司有三四个业务线都在做同样的事情了，那技术上实现能不能融合可复用的部分。另一个则是时间成本，即新业务能够足够敏捷地去使用既有的技术模块去做探索。
有了前台和后台，为什么还需要中台
中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。
中台建设要避开哪些“坑”
1、中台是企业 IT 变革的一个起点，而不是单纯认为，我就是做一个项目，我搞一个采购中台，就解决了所有的问题
2、第二个“坑”发生在选择中台的技术平台时，很多人想，我先选一个便宜的能用的平台，以后我再选一个复杂的、更全面的平台。
3、第三个坑，就是大家对试点、试点项目这块不太重视，往往会抱有这样的想法“反正是试点、就试一试”。
中台建设难题一：中台团队离业务远
有两个解决方案：
第一，中台职责直接由最大业务方来担任。
第二，让中台团队做业务闭环。
中台建设难题二：中台需求优先级难排序
有两个办法：
第一，建立以价值为导向的需求治理机制。
第二，基于OKR的需求聚焦与创新。
以上对阿里中台建设的方法论进行归纳总结，希望对你有所帮助，关于中台建设还有什么想了解的？欢迎给我留言。
-End-
联系客服
