产品经理互联网大厂的中台战略剖析进击的中台组织的砺炼.docx
《产品经理互联网大厂的中台战略剖析进击的中台组织的砺炼.docx》由会员分享，可在线阅读，更多相关《产品经理互联网大厂的中台战略剖析进击的中台组织的砺炼.docx（19页珍藏版）》请在冰豆网上搜索。
产品经理互联网大厂的中台战略剖析进击的中台组织的砺炼
中台战略作为近期大厂和品牌商竞相追逐的方向，背后反映出企业对于业绩增长进入相对瓶颈期的焦虑。
我们的观点：
（1）中台从来不单是技术的游戏，是企业战略、组织、方法论与技术的结合产物。
“中台是组织的外化，最终服务于商业模式”，脱离战略与组织维度的企业数字化转型往往事倍功半。
中台概念之所以被争相传播，与企业所面临的成长瓶颈期以及企业技术架构的发展阶段强相关。
我们通过阿里中台转型的故事看到：
自顶向下、切入正确的场景、产品化思维是中台战略不可或缺的要素。
（2）各互联网大厂的中台战略尽管围绕主营业务各有侧重，但无一例外希望：
然而目前看除阿里中台相对成熟外，其余大厂中台布局道阻且长；长期视角下的互联网大厂更希望自家中台的逐步社会化，这也侧面推动了云服务市场的繁荣。
而具备危机意识的品牌商也已拉开中台化的进程，但在组织变革层面的进展相较于互联网大厂要更难。
（3）我们对中台的前景坚信不疑。
ERP在早期实施阶段与中台当前面临的问题如出一辙，但毫无疑问ERP的实施强力推动了企业信息化进程。
特别是在全渠道零售/服务领域，中台将在线上线下的数据、业务与供应链融合过程中大展拳脚。
对于企业，找到当前发展阶段最适合自己的组织与技术架构乃当务之急，克服盲目对中台追随的心态有助企业保持理性与健康发展，毕竟在高速行驶中更换发动机谈何容易。
开篇说：
我们认为中台之所以不能被正确和理性看待的原因尽管复杂，但并不难理解：
脱离企业组织文化单独看中台，将把中台归类为技术系统的优化、归纳与升级，这将会对中台的功能定义以及落地实施的期望值造成较大的偏差。
我们认为中台≈战略与组织的外化形式，企业组织的健壮性与柔性、业务的成熟度、数据沉淀的规模以及看待中台的视角将很大程度决定企业中台建设的必要性及推进难度。
中台战略作为近期大厂和品牌商竞相追逐的方向，背后反映出企业对于业绩增长进入相对瓶颈期的焦虑。
我们认为，中台不仅仅是技术架构的变革，而是一套“战略、组织、方法论、技术架构”多者协同的结果。
中台思想在早期更多以技术层面展现和解读，往往是因为技术层面是企业战略、组织、文化外化的最终结果，从中台实施的最终结果看毫无疑问要以技术架构作为落地手段。
因此，本文通过不同主线反映企业中台的成长与进化历程，以中台为切入口探讨中台与战略和组织之间的关联，并尝试归纳与总结中台未来的发展方向。
我们看到，中台的诞生并未偶然或无迹象，我们认为这与企业业务发展与人员规模的扩大密切相关，中台的诞生也或多或少反映管理层的意志（当然也承载了他们对企业的美好愿景）。
基于对中台的历史研究我们初步认为，阿里中台的发展轨迹已在业内具备代表性：
阿里最初的业务以1688和淘宝为主，各自为政，面向客户以及业务对象均有较大差异。
淘宝初期主要面向C2C电商领域，全套系统围绕淘宝垂直的技术框架落地。
随着业务的不断扩张，阿里成立天猫事业部主抓B2C电商，又形成了一套并列垂直的技术框架。
这种垂直式的、相互不连通的架构体系类似烟囱林立带来了诸多不足，如成本的重复投入和维护、数据之间打通复用的难度、几年之后推倒重建的风险等。
为了解决这些问题，阿里于2009年就已成立了共享业务事业部（SharedServiceCenter）与数据平台部，通过构建共享服务来沉淀和复用业务能力。
但由于成立初期业务话语权不强，共享服务体系的建设并不顺利。
随着“聚划算”团购项目的启动，公司统一要求各系统的流量都需要通过聚划算，共享服务中心依托聚划算业务才得以大展手脚，逐步将集团核心的业务能力沉淀成为用户中心、商品中心、交易中心、评价中心、店铺中心等数十个共享服务。
共享业务事业部：
地位曾尴尬到聚划算救场
资料来源：
《企业IT架构的转型之道》
阿里共享业务事业部逐步成为有效的中台角色
料来源：
《企业IT架构的转型之道》，阿里云官网
同时，阿里借鉴Supercell组织管理方式，强化中台战略转型也进一步放大了巨头在中台组织建设方面的前瞻性：
在Supercell内部以小团队（cell）形式作战，小团队最多不超过7人，小团队对整个项目周期负责，从项目策划到研发再到向市场推广。
如果产品没有受到市场欢迎则迅速放弃产品，从中吸取经验后再进行新的尝试。
这样的快速试错、不断创新的模式使得Supercell成为了一家年税前15亿美元的游戏公司，人均贡献收入达到4亿元/年。
阿里在参访Supercell后，于2015年提出“大中台，小前台”的组织和业务体制。
因此，阿里中台革命也即共享服务中心发展壮大后的产物，共享服务中心作为阿里中台核心，聚焦各业务单元能力的构建，协助目前集团上百个前台业务的快速创新——中台登上阿里组织架构发展的历史舞台，连接了前台的变化与后台的不变。
Supercell的类中台管理方式示意（注：
“中台”的概念并非来自Supercell）
资料来源：
程序员小灰公众号
阿里“大中台，小前台”战略落地逐渐成型
资料来源：
阿里云论坛
从上述阿里中台的历史演化以及中台源起可以看出，中台发挥的核心价值在于“共享复用，敏捷创新”。
我们认为中台目前正处于一个探索中的“定义混乱期”，按照ThoughtWorks给出的参考定义，中台是企业级的能力复用平台。
之所以是“企业级”，是因为中台的规划牵扯企业战略与组织，需要企业自顶向下做顶层设计。
而“能力复用”体现在通过敏捷响应机制的建立，通过将企业的共性能力（对应共性需求）进行抽象重组，打造为公共的系统能力，以接口、组件等形式共享给各业务使用，使得企业前台各业务线无需重新开发即能快速实现业务迭代创新。
企业公共能力复用价值被逐步开发（但请注意中台不承担管理职能：
人/事/钱，那是前台和后台的事情），满足快速变化的市场需求。
中台也开始成为进入成熟期企业不可回避的思考维度之一。
中台的视角迁移：
从惯常的管理维度到业务能力创新视角
我们看到，近年来中台的曝光频率走高也反映头部企业迈向稳定期过程中的成长焦虑。
我们之所以关注中台发展，本质上就是在高速变化的社会环境下关注企业在组织与文化层面的转型创新。
根据伊查克·爱迪思《企业生命周期》，我们认为中台即为企业生命周期从“稳定期”继续降本提效的立足点，也可以理解为中台是帮助官僚化企业减轻“官僚期症状”的有效组织形式（请注意：
只是减轻，不是避免）。
伊查克·爱迪思提出的企业生命周期，中台在企业‘成长阶段’后期发挥作用。
资料来源：
hrmarket
阿里从原有传统应用架构转变为共享服务体系架构，经历了多个组织架构的变迁与调整，可以说阿里中台的成长就是阿里对其战略组织架构不断思考与升级的过程，公司战略与组织结构发生了复杂却必不可少的的变化。
钟华在《企业IT架构转型之道：
阿里巴巴中台战略思想与架构实战》一书开篇提到：
“与任何公司一样，阿里巴巴组织架构的战略调整势必对公司现有组织架构、部门间的协作等各方面都将带来深远影响…假若没能很好地控制战略执行过程中带来的风险，对组织架构的动荡过大，都会给现有业务带来不小的损伤。
”
我们认为阿里的中台战略之所以能够成功落地，得益于其以往对组织架构调整的能力与决心，对阿里价值观的高度一致，以及内部逐渐形成的“适应变化”的文化。
组织架构调整的难点在于让每个员工都快速了解并且认同其背后的战略意图，并快速适应新的组织架构，理解接纳接下来在新的组织架构下自己的角色，从而使得战略能够平滑迁移并最终落地，这需要一套机制和文化基础来保证。
基于阿里中台的建设案例我们认为，企业中台的成长路径就是在企业战略与组织博弈的同时开辟的：
通过战略与组织的相互博弈与妥协（战略也需要在组织调整的反馈中动态调整），最终达成一致，使得中台的形态随之逐渐迭代，形成承接战略与组织的成熟形态，进而推动业务在未来商业模式的不断（小幅）迭代。
也即：
战略通过组织体现，组织效能通过中台反映，业务逐渐通过中台（而不是原有体系）进行商业模式的更新。
资料来源：
阿里2017、2018云栖大会
“康威定律”（Conway’sLaw：
一个产品或系统的设计（架构）受到其生产组织自身交流沟通结构的制约，MelvenConway，1967）也被援引成为表达中台成长原则与核心价值的重要评估方式。
康威定律表达的核心在于承认：
企业的技术架构与组织架构紧密联系，组织架构就是对于责任和利益的分配结构和分配方式，责任和利益划分清晰了，中台被承认了，也就有更明确的存在感。
因此，中台建设真正困难的部分是战略指导下组织重构的深刻动刀，而这往往是大家有意无意避而不谈（或未意识到）的。
具体细化而言：
（1）技术架构是一家公司核心业务和组织的抽象和沉淀，架构师其实是一种解读管理复杂性的角色——不断将复杂性抽象化、简单化、清晰化的职业。
在架构师的脑海（中台蓝图）里，一家公司应当就是各种积木（业务单元）的抽象、拼装和组合。
（2）组织顺畅下的高效充分沟通就是抽象复杂业务、拼装与组合业务公共部分的前提。
对于一个系统模块（如支付、交易等），它的被调用次数和调用后评价就是衡量它好坏的标准。
那么开发它的工程师与其他部门、业务方的沟通次数，就近似于这个技术模块的调用次数与调用时长。
这也就意味着：
在高速发展、不断迭代的科技时代，公司竞争的不是技术，而是组织和文化的优越性与建壮性。
这种优越性与健壮性使得中台架构师在沟通，抽象与沉淀的动作当中能够实现相对平稳顺畅的对接流程，最终实现中台建设与充分发挥效能的目的。
因此不得不提的是，阿里价值观强绑定与考核的铁腕文化+平台型多元业务组合，正面促成了中台战略的实施落地。
通过阿里巴巴的中台建设，我们看到：
我们尝试总结中台的成长路径中需要具备的核心要素：
1）自顶向下的一把手工程：
组织文化重构的魄力需企业管理者的大力推进
尽管中台的初步试水未必由高层首先提出，但我们认为中台建设路径当中涉及战略确立，组织变动与利益协调分配，仍然要通过自顶向下的驱动方式。
没有高层强有力的长期推动，很难切动组织架构中的固有利益网，因而会导致中台的内部推广难度都大幅上升，很有可能最后因组织划分与职能分管等不可调和原因“中道崩殂。
同时大部分一线员工是很难站在一定的高度去做“看N年、做一年”的中台战略规划，特别是当中台与业务眼前的KPI难以达成平衡时，中台的工作开展会受业务的强力狙击。
2015年12月起，阿里正式从集团层面启动中台战略建设
来源：
阿里云官网，阿里2015年12月内部信
2）在平台化的基础上，寻找到有效的业务组合与有效的业务推动场景
建设中台的前提在于公司的成型业务存在大量协同效应，以至于中台能够很好的提升业务抽象能力，从成型业务的共性切入作为突破口是中台切入的理想选择。
中台是能力复用平台，协同效应的业务越多，中台的抽象和复用能力越强，越能够为前台业务提供价值。
阿里做中台起源于淘宝和天猫，本质都是电商平台；滴滴做中台，是因为快车、专车、出租车、顺风车等业务围绕出行展开；头条做中台是因为所有APP的使命都围绕用户展开，用户增长是所有APP无法绕开的话题，因此锁定增长指标成为所有业务部门的重点……
我们认为当公司存在如下三种问题的至少一种时可能并不适合搭建中台：
烟囱（业务）林立的时候未必一定是搭建中台的成熟条件，要看业务之间的协同效应
3）PlatformasaProduct（PaaP）：
用产品思维建设中台
中台产品化、产品思维在中台建设当中的重要性也被逐步体现出来。
每家企业建设中台的目的均存在差异，包括不限于内部研发效能提升、资源与数据复用、零售全渠道打通、开放银行、多品牌、构建商业生态等。
因此，中台所面临的前台业务随着企业业务组成的不同大相径庭，这容易诞生诸多问题——
a.内部矛盾
因中台建设的复杂性和长期性，导致无法满足前台团队的短期业务需求，中台压力大。
业务方不满，认为没有得到（与原有support相比）相应的服务；中台团队背负着业务的持续施压，无法按照自己的节奏推进中台建设，导致中台内部矛盾频发。
b.外部矛盾
中台团队迫于压力极力满足前台的需求。
因为中台的性质，中台团队需要同时面对多个不同的前台业务、前台团队。
每一个前台团队都是甲方，在中台团队眼中地位近似，需要极力满足需求。
而因前台团队为能获取更多的中台资源使用权，提需求争取更多中台资源成为前台团队习惯，导致中台团队的需求短时间剧增，但因为中台资源毕竟有限，自然而然会出现之前反复提到的需求爆炸、排期、冲突等问题，矛盾产生。
因此，中台的成长过程需要按照产品化（PaaP）的思路进行设计，将前台业务需求前置，提升需求响应和处理能力，形成中台模块的核心落地思路。
我们认为，中台产品化可以借鉴思考如下几点：
中台通过角色转换变为产品团队，形成（中台）产品对（前台）产品的服务形式
资料来源：
健荐公众号
中台产品化过程中可能需要去思考的问题：
围绕产品需求展开
资料来源：
健荐公众号
基于上述分析，中台需要考虑组织、方法论与技术三个维度的事项。
从技术架构的演变，可以看出除了组织外，技术成熟度的提升也侧面催生了中台方法论（以及背后思想）的诞生。
从SOA到ESB理念转型为微服务架构，最早可以追溯到从亚马逊早期提出的核心管理原则的转变——我们能够从贝佐斯铁腕管理方式对中台诞生的萌芽初窥门径。
2002年，Bezos突然向全公司发布了指令，核心内容表达为：
全公司数据不得成为孤岛，IT项目组之间必须以接口（API）的形式进行合作。
这使得从2002年开始直到2006年API工程迁移完成之后，亚马逊内部技术体系逐渐调整为SOA（service-orientedarchitecture，面向服务）架构，每个技术组和产品组之间都是service形式，都可进行互相调用。
之后Amazon不仅在技术架构上逐渐变成业内俗称的“微服务架构”，并且使得整个组织都变得API化，不断强化对外接口的能力，AWS也间接受益于此：
亚马逊早期的系统能力是按照高峰期的需求配置的，美国人购物集中在圣诞节前，圣诞节后系统的利用率仅有30%左右，其余算力都进入闲置状态，内部建议将闲置的系统计算能力和存储空间出租。
这也是最早的云的概念，亚马逊通过早期管理思想的积淀与电商业务的不断打磨，也一步步摸到了云的入口。
众多国内企业早期的发展的技术架构更多采用ESB架构完成——ESB（EnterpriseServiceBus）讲究企业技术架构的联通，其基于SOA，应用场景是在对已有应用的打通，比如企业ERP+CRM软件以及定制开发的软件，这些软件价格不菲，需要长期使用，轻易无法改动。
所以要尽量保留，通过SOA进行架构串联，是一种企业集中式服务治理的架构；久而久之，企业形成了“烟囱式”的技术服务基础设施，“烟囱式”的技术服务设施尽管对单一业务的逻辑闭环与系统支撑形成了良好的支持。
但对于企业整体系统而言并不利于延展和内部业务相互协同，原因有如下几个：
（1）功能重复开发和维护成本带来的浪费：
原有业务的系统支撑模块无法复用到新的业务系统架构中，只能重新开发极其类似的系统支撑模块；
（2）打通企业“烟囱”间交互花费企业更大成本：
ESB架构的大部分/彻底推翻，新的企业架构的建立所需花费的时间；
（3）ESB模式下数据流典型系统特征：
仅支持数据的单向流动和单场景使用，业务与系统单线联动，业务优化仅限于局部改善，无法做彻底性改动（如果彻底改动，可能对企业业务整体带来重大影响如业务停摆等）；
ESB架构下不同环节系统林立，使得业务链无法模块化拆分
资料来源：
《钟华：
中台战略推动企业生产力&生产关系再变革》
因此随着企业规模逐渐庞大的过程，ESB架构的系统负载将会愈发提升，随着前台业务面向用户快速变化需求的力不从心，前台需要更加灵活和健壮的系统和组织架构的支撑以便完成后续的快速改进乃至业务迭代。
中台的微服务技术架构效率要高于ESB，ESB更多体现中心化思想，将企业所有细分业务链接到ESB总线以便更加适用于技术部门管理。
相反，微服务架构强调的是“业务的彻底组件化及服务化”，原单个业务的支撑系统会被拆分为多个可以独立开发、设计、部署运行的（小型）应用。
这些应用之间通过服务完成交互和集成。
组件表示的就是一个可以独立更换和升级的单元，例如PC中的CPU、内存、显卡、硬盘，独立且可以更换升级而对其他单元并不产生显著影响。
我们把PC中的各硬件以服务的方式理解，则PC只需要维护主板（可以理解为微服务架构中的ESB总线）和一些必要的外部设备就可以。
CPU、内存、硬盘等都是以组件方式提供服务，例如PC需要调用CPU作为计算组件，只需知道CPU这个组件的访问接口（地址）即可。
从ESB到微服务架构：
总线形式的中心化思想到服务模块化下的去中心化思想
资料来源：
知乎@李运华、CSDN
从ESB到微服务的架构转型，本质是企业组织管理方式的转型。
企业技术架构从早期的传统IOE架构（每个应用彼此按烟囱式独立排列，唯一的共通点在于都与底层的数据库相连；每个应用都比较庞大，同时需要连接多个数据库；架构中的应用数量较少，应用与应用之间的关系简单），到传统中心化ESB架构（ESB总线瓶颈凸显），再到去中心化微服务形式的敏捷架构（业务扩展随叫随到）。
实际是业务不断延展和深化过程当中路径：
从传统经济到数字经济，从关注产品功能到关注用户体验，?
户逐渐成为商业战场的必争之地，为了快速响应用户的需求，平台化组织的对业务相应的需求迫在眉睫。
不断快速响应、探索、挖掘、引导?
户需求，才是企业得以?
存和持续发展的关键因素。
ESB到微服务，架构的演变为中台提供了一种灵活的技术选型方案
资料来源：
《腾讯云中台建设实践》
由于电商行业一直是我们关注的重点，我们可以藉由电商平台系统架构的变迁看到中台能力在电商领域的不断释放。
我们发现近年来，由中心化向去中心化的电商演进正在发生：
中心化模式的价值主张就是平台方汇聚流量，提供并掌握用户购物的第一入口，商户通过这个入口获得流量销售商品，平台以此分成。
在行业快速发展期，商户可通过平台提供的入口获得有效且具规模的流量和运营能力，商户受益且依赖平台赋能；但随行业整体增速放缓，互联网巨头用户量趋稳，获客成本高企，中台能力接近稳定。
另一方面平台入驻商户不断增加，竞争白热化，僧多肉少的结果导致流量价格加剧，订单转化率接近瓶颈，倒逼各大平台开始注重深耕存量用户的价值，并利用中台能力稳定商户军心。
2016年阿里首次提出私域的概念，伴随淘系的内容化战略落地方向，倡导淘宝商家从“产品为王”到“内容为王”的转变。
但淘系生态本质是流量获取和留存方，商家和品牌在淘内更多属于流量贡献者，虽然微淘界面鼓励商家与用户之间建立直接联系，淘宝内部私域流量仍没有得到很好的发展。
因此在私域流量在电商领域应用逐步大行其道的今天：
（1）品牌主建立自有电商的需求，品牌主努力构建自有电商渠道，不断脱离“古典电商”的磁场，加强数据跟踪与应用能力；
（2）用户要求电商体验的多样化：
购物现很多新场景触点——语音、社群、酒旅、穿戴设备、AR/VR，前端更加丰富，在稳定底层商品和交易框架基础上，API化可有助于保障各场景的购物体验稳定；
（3）品牌直接面对消费者（DTC）的诉求：
品牌通过自有电商直接面对消费者（私域流量也为DTC创造了很多机会）。
在这三点的推动下，电商平台的技术框架的演化与思想也随着电商形态的进化而不断更替：
从一体电商方案（从搜索到交易往往是一家供应商提供，如Oracle,SAP，WordPress等）到内容和交易能力的定制分离方案（用户交互端依托主站、电商交易端依托三方服务商）再发展到通过以API为基础的无头电商（HeadlessE-commerce，三方服务商提供全部定制化/灵活化的电商服务）架构。
无头电商（注：
国外流行概念，国内接纳时间并不长；其实中台是国内提出的概念，国外更愿意采用AWS对标所谓中台）通过前后端分离，允许开发人员在任何类型的框架中为产品和服务创建各种接触点。
由此，后端开发人员就可以灵活地创建和使用API以交付给任何类型的终端设备（屏幕）。
无头电商的去中心化系统理念为私域电商和品牌电商的发展提供了技术和系统层面的方案：
将品牌电商的前台展现和后台服务进行解耦的结果。
后台以API的方式提供服务，前端展现层与后端分离。
电商去中心化伴随系统架构去中心化，中小玩家拥有了和BAT比肩的中台架构利用机会
无头电商模式更加有效的适应多样化零售场景
资料来源：
互联居公众号，CSDN
无头电商的优势：
设计灵活，前后端分离，API服务导向
资料来源：
互联居公众号，CSDN
在技术层面上，无头电商模式属于SaaS与PaaS之间的抽象层次，这与中台的抽象层次类似（最终会殊途同归）。
从国内角度看，有赞云提供的服务与这种抽象层次类似，通过大量API的封装与开放，开发者或者商家可以自己定制交易流程，比如增加适用于社交工具的促销环节与特定交易流程、线下门店与电商的库存、促销、交易、会员服务匹配。
同时在流程中的各个业务关键点输出扩展能力，让开发者可以去实现扩展能力，如价格计算，现在开发者可以改写价格计算逻辑，实现新的商品实际成交价格，选择赠品逻辑，可以通过调整不同的赠品实现买赠挑选的功能等等。
通过前端页面组件化，开发者可以定制自己的组件，修改原有组件的行为，以及其它复杂的定制。
资料来源：
《有赞云白皮书》
有赞云将核心业务模块封装，并开放接口供开发者调用
资料来源：
有赞Coder公众号
阿里是互联网大厂中台战略的坚定推行者之一。
我们基于上述分析认为，阿里中台的前身是2009年成立的“共享业务事业部”和“数据平台部”。
具体到《企业IT架构转型之道》中，作者钟华的表述采用“共享服务中心”（sharedservicecenter），并且“从原有传统应用架构转变为今天共享服务体系的架构，本质上是微服务架构建设的过程”——中台架构大概率会选型微服务架构，微服务架构既是一种有形架构，也是一套管理复杂系统的服务治理思路。
阿里自2015年提出“大中台小前台”战略（提出此战略的目的是在共享服务基础上进一步之后，组织架构和业务机制两个层面进一步将关系梳理清晰，拆掉部门之间隔墙）经过3年多的改造，中台已经实现公共业务和技术组件横向打穿，为阿里前台业务提供高效运转和迭代的支撑。
阿里大中台示意：
业务数据化+数据业务化，前台灵活+双中台支撑
资料来源：
阿里云论坛
2007年9月的阿里战略会至今看来，仍被视为一次阿里内部思想提炼的重要媒介。
在阿里未来方向不清晰、内部组织割裂严重的形态下，这次战略会确立了“建设一个开放、协同、繁荣的电子商务生态系统”的战略方向并始终延续至今，下图也诠释了阿里生态系统的远景，这也为阿里打开了生态化的格局。
也确定了“客户&数据为重要价值，信息流+资金流+物流为关键数据资产”的生态系统贯穿核心；阿里的“奔月计划”（数据贯穿所有子公司的业务打通，后由王坚博士改名为“登月计划”，属于阿里云飞天计划前身）“五彩石项目”（淘宝与淘宝商城（现天猫）的数据打通）也基于此次战略会的结论，开始围绕公司数据体系的变革展开。
07年阿里战略会提出的阿里生态系统雏形
资料来源：
曾鸣书院公众号
从战略、组织、前台、
升级会员 