白话中台战略-4：Platform as a Product(组织篇)

原创王健健荐

以下这个简短的对话出现在刚刚过去不久的2019年深圳技术雷达峰会后主会场外的某个阴暗的角落……

“你觉得我对中台的「企业级能力复用平台」这个定义咋样？” 我沾沾自喜，满怀期待地问到。

“没有说到点子上，不解决实际问题。” 徐昊此时就斜靠在我旁边的桌子上，磕绊儿都没打一下，一上来就给我浇了一盆凉水，还是零下的那种。

“嗯……” 我假装沉思，其实是需要稳定一下此时复杂的情绪。

“那要是让你给中台下个定义，你会怎么整？” 我守住了阵脚，开始反击。

“Platform as a Product” 徐昊答到，又是磕绊儿都不打一下，一点情面都不留。

……

这段对话最终持续了将近两个小时，直到会务把我们靠着的桌子拆了，才被迫结束。

对了，介绍一下，徐昊就是ThoughtWorks中国区的CTO，也是两年前第一个跟我提起“中台”概念的人，同样是他引导我开始用Pace-Layered Application Strategy和Business Operating Model去思考中台，给了我很大的启发。

这次，也一样。

这段对话过去后的一段时间，我一直在思考和回味这次对话的内容。本篇就尝试将这段时间的思考落笔成文，从中台实施过程中经常遇到的各种实际问题出发，将视角提升到组织层面，看看为什么说以“Platform as a Product”的思路来开展中台建设是有价值的。

中台建设过程中的问题

之前的文章我一直围绕在“为什么建中台”、以及“中台到底是什么” 这些偏抽象的问题上。

但是接触的中台场景越多，就越发现其实每家企业建设中台的目的可能都是不一样的，大面上就能分成：内部研发效能提升、资源整合、新零售、全周期、全渠道、开放银行、多品牌战略、全球化战略、产业互联、构建商业生态等等等等。

中台这个概念，随着市场的炒作，越来越像一个个“许愿池”，承载了每家企业对于自己未来发展的美好愿景。但理想总是很丰满，而现实总是很骨感。

当我们真正下定决心，捋起袖子加油干，尝试真正去推动中台落地的时候，才发现原来通往美好远方的是条布满荆棘之路：

中台的建设经费从哪里来？中台团队的人从哪里来？谁应该为中台的建设买单？
中台的建设效果如何来体现？谁来验收谁来评价？
我们说中台是企业级，要支撑多个前台团队，那四面八方的需求涌进来，会不会出现拥堵和排期？如何处理排序需求？
如果不同的前台团队的需求出现矛盾和冲突，中台如何处理？都是金主，以谁为主？
前台与中台的职责怎么划分？
前台不配合中台团队怎么办？
前台提的需求不合理怎么办？
……

问题还有很多，但仔细观察就不难发现，这些常见的问题大多与技术无关，而多是出现在组织的边界上。中台的建设既然是“企业级”，必然会涉及到组织的调整，甚至是组织的重新划分以及利益的重新分配，而这些都早已超出了技术能解决的范畴。

说实话，近两三年我也算参与了不少大大小小的中台建设。大多时候，作为一名外部顾问和咨询师，一直是想方设法绕过组织这座大山，回归到我熟悉的技术领域，尝试用技术的方式去解决碰到的所有问题，但神奇的是组织的大山总会在中台建设的某个关键阶段，像海市蜃楼一样突然出现在面前，阻挡在前进的路上，绕也绕不开。

甚至，我都有种越来越强烈的感觉：组织可能不是中台建设的阻碍，而恰恰是中台建设的本质。

既然绕不过去，那就跨过它！

为什么中台建设需要关注组织架构

回答这个问题可以从两个方向推演：一个是自上而下，一个是自下而上。

自上而下：组织重构是战略落地的必经之路

我在上一篇文章（白话中台战略-3：中台的定义）中就提到过，中台就是「企业级能力复用平台」，“企业级”就意味着中台规划是属于公司战略的一部分，是需要自上而下做顶层设计的。

而战略的落地，往往就是靠组织的调整来实现的。

美国的管理大师钱德勒就表达过组织结构从属于战略的观点，即“企业的发展取决于两个变量，一个变量是企业正确的战略，另一个变量，就是企业的组织结构。这两个变量之间，前者决定后者，后者保证前者的落地实现。”

马云也曾在湖畔大学的分享《使命、愿景、价值观、组织、人才、KPI》中提到过：“战略最后的本事不是你设计了多好一个Plan，而是你落实到了什么样的组织，谁来干，考核指标是什么？”

http://www.hupan.com/hupan.web.webapp/pages/m/video.html

可见中台战略之所以是企业级的数字化战略转型的一部分，从战略落地的角度来看，组织调整是其中重要的一环，也是战略真正落地的重要体现。

自下而上：组织是中台建设荆棘道路上的一道坎

我的同事王威在《你真地需要一个中台……吗？》文中提出了中台建设的三条原则：

但是，如果实际去观察，目前很多企业的中台建设，仍然主要是以技术驱动为主，以IT治理为目标，天天谈论的还大多是微服务怎么拆、技术架构如何选型此类的问题。

不是说这些问题不重要，而是技术驱动的一个主要问题在于：很难讲清楚中台建设对于业务的价值。而讲不清楚中台建设对于业务的价值，就得不到相应的资源，这里的资源主要就是钱和人。

没有资源的支持，技术团队就只能自己委屈点儿，吃苦耐劳，加班加点，用有限的资源既要满足业务上的需求，又要借着这个机会做中台的改造，甚至是闷着头偷着做的，卧薪尝胆。

但结果却往往并不好，好不容易硬着头皮加班加点赶完了一个版本，上线了，需要前台应用接入了，这时问题才暴露出来，例如经常出现这样的声音：

我们（其他团队）为什么要用你的中台，我们也建了一个，要不你用我的吧……
我们（其他团队）为什么要把数据给你？我这儿也有一个数据中台，你能不能把你的数据先给我一份儿……

此时大家抬起头来才发现，原来隔壁部门、兄弟团队也在搞中台，原来大家嗤之以鼻的“系统孤岛、数据孤岛”，现在则变成了“中台孤岛”……

中台建设从技术视角看来，看似清晰，无非是搭建一个平台，将可复用的能力沉到平台里来，对前台进行复用，感觉上就可以实现“大中台小前台”。

但现实远比这要困难得多，根据康威正反定律我们可知，企业的IT架构与组织架构紧密联系，而组织架构说白了就是对于责任和利益的分配方式。

而我反复强调的中台建设既然是“企业级”，就必然会影响到企业内责任和利益的重新分配，最终也是体现在组织架构上。

这就能解释开头说的，为什么中台建设必然会在某个阶段遇到组织这个无法逾越的坎，所以如果不在一开始考虑清楚，必然会让自己在中台建设的某个阶段处于一个进退两难的境地，非常被动。

从两种典型的组织架构中台演进看中台困境

组织是个很大的问题，典型的组织架构就包括：直线职能型（U）、事业部型（M）、矩阵型、网络型、平台型，还不算各种组合和变体；如果结合经营模式，还需要了解大家常常提到的阿米巴经营模式以及海尔的自主经营体……

所以，肯定不是一篇文章就可以讲清楚的。

本文定位白话，我就还试着收敛回到中台的上下文上，聚焦到数字化团队组织的形态上，以中台化场景中最典型的两种数字化团队组织结构的中台建设演进推导为案例，试图从组织演进的视角来看看到底为什么中台的建设会碰到这么多问题？以及寻求破解之法。

直线职能型组织结构的中台推演

直线职能型组织有时候又被简称为职能型组织，是从直线型组织发展而来，也是大中型企业最常见的组织形式，大多数企业都采用这种组织结构形式。

在这种企业组织架构下，数字化团队最常见的形式就是业务团队（BT）与技术团队（IT）分离体系。

在这种组织架构下业务团队因为更多的承载了用户与业务的需求，往往更具话语权和主动权，也掌握着预算分配的主动权，技术团队更多情况下是从业务团队申请预算，负责IT系统设施的建设与运维，完成业务团队的需求。

不过，随着企业业务的发展，IT系统也越来越多，自然就会出现越来越多“烟囱型”的系统，再加上整体架构的老化与腐化，技术团队的工作负担越来越重，对于业务团队的需求响应能力也逐渐降低，开始出现需求堵塞，需求排期问题日渐严重，业务团队不满情绪积累，技术团队则同样不堪重负，矛盾日益显现。

怎么办？

肯定会有人说，中台啊！中台不是就是解决烟囱问题的么，你想想，只要能将各个系统重复的能力抽取出来，沉淀成共享服务，大家一共享，一变都变。对于新需求前台直接拼拼凑凑，拖拖拽拽就能快速满足，简直不能更完美。

嗯，听起来也是这么个道理，说干就干，于是技术团队就开启了寄托着美好愿景的“中台改造”，因为是技术团队基于IT治理的需求驱动的，也就代表“中台改造”对于业务往往是透明的。

不过随后就发现，中台建着建着，之前提到的那些问题就开始一个接一个出现。

根本原因在于中台改造往往涉及到大量的工作量，难度也非常高，而由于其“业务透明性”，表面上并没有直接的业务价值。看不到业务价值就代表没有业务团队愿意为这些工作买单，甚至相反因为技术资源会被中台改造占用，对于业务的响应不升反降，业务团队怨声载道。

技术团队内也逐渐出现问题，随着架构复杂度急速上升，再加上中台改造出现了团队之间的服务交叉耦合，跨团队的沟通成本也急速增加。

看起来一切都在向着期望相反的方向加速进行，直到失控的边缘。

中台建设不是号称可以增加IT的响应力么，为什么会适得其反？是不是分离出一个独立的中台团队就会好些了呢？

中台技术团队应运而生，但不久我们就会发现，问题并没有被解决。

仍然是因为“业务透明性”，在没有新的资源支撑前提下，团队也自然无法扩张。只能将原来的团队进行重新切割，分为中台技术团队和前台技术团队（事实上，已经很少有企业有魄力能走到这一步）。

业务团队的压力和需求此时就会通过前台技术团队传导到中台技术团队。而中台团队则因为要同时支撑多条业务线多个APP，复杂度高，之前提到的需求拥堵、排期、冲突的问题仍然无法得到很好的解决，只是转移到了中台技术团队而已。

那是不是因为直线职能型组织天生就不适合做中台改造呢？

其实恰恰相反，从某种角度看，中台本质上就是一种Shared Service。Shared Service不是一个新概念，原本就是代表一种共享组织结构，由来已久，例如我们常常听到的共享财务中心。而直线职能型组织结构下的技术团队，本身就是一个IT Shared Service（IT共享中心），不但不是八字不合，反而非常的契合，那问题到底出在哪呢？

中台概念来自互联网，那我们就再来看看另一种在互联网企业更常见的组织结构，事业部（产品型）组织结构，是不是就可以在中台建设的过程中避免出现类似的问题？

事业部（产品型）组织结构的中台推演

事业部组织结构是分级管理、分级核算、自负盈亏的一种形式，即一个公司按地区或按产品类别分成若干个事业部，从产品的设计，成本核算，产品制造，一直到产品销售，均由事业部负责，实行单独核算，独立经营，集团总部只保留人事决策，预算控制和监督大权，并通过利润等指标对事业部进行控制。

由于互联网企业的产品基因，往往是由一款产品做起，随着业务的扩张，逐渐出现了多条并行的产品线。互联网因为竞争激烈，往往讲究的就是一个快字，谁先占领了市场和用户谁就占据了主动权。因为事业部组织架构相对于直线职能型组织架构，更强调“纵向”的执行力和灵活性，自然成为大多数互联网企业默认的组织演进方向。

同样，如果只聚焦于数字化团队的组织架构，事业部职能结构可以简单理解成产品型团队。从单一产品开始，多一个产品，多一个团队，团队之间就像产品之间一样，有很强的独立性，例如大家熟知的阿里巴巴淘宝团队和天猫团队，这样的例子有很多。

产品型团队的问题就在于产品之间的割裂和缺少横向协同。

相信不用多说，如上图所示，“烟囱产品”的问题已经非常明显：随着各产品线的独立快速发展，各个产品间的重复建设、技术栈混乱、设计混乱等问题日益突出。

怎么办？

能不能成立一个单独的组织来处理协同的问题，让产品型团队专注于自己各自前台产品的差异部分，通过组织的分层来解决产品型组织的问题呢？

中台团队又一次应运而生。

但区别于前台产品团队，此时的中台团队与直线职能型团队中的中台团队一样，仍是以一个偏职能型的内部共享技术团队存在的。（我在图例中用红框来代表产品型团队，用篮筐来代表职能型团队）

乍一看，这种“分层组织结构”解决了产品团队组织结构下的协同问题。

前台产品团队继续负责产品差异部分的独立开发，承载着企业的纵向“灵活性”；中台职能团队负责产品间的协同和通用部分的开发，承载着企业的横向“经济性”。理想情况下，通过分层组织结构，就可以通过不断调整前台产品团队与中台职能团队的组织边界，来调节企业在“经济性”与“灵活性”之间的动态平衡，一切看似完美……

但是，同样随着中台建设的推进，我们就会发现，之前出现在直线职能型组织中的中台团队所面临的问题（需求堵塞、排期、冲突、资源竞争、边界定义、团队冲突……），同样也会出现在这种事业部（产品型）组织架构的中台团队里，问题并没有得到解决……

究其原因其实也是一样的，中台团队因为不是直接服务于终端最终用户，而是通过服务前台产品团队间接服务终端用户。所以并没有直接的收入来源，需要从各个产品线抽取一定的资源（人+钱），组建中台团队，为前台团队服务，前台团队与中台团队的关系与直线职能型组织一样，仍是一种被服务与服务的关系，区别无非在于前台是产品型还是职能型团队而已，并无本质区别。

复盘：问题的本质到底是什么？

基于上述，无论是以传统行业为代表的直线职能型组织，还是以互联网为代表的事业部（产品型）组织，亦或是各种组合变种（例如最常见的矩阵组织结构），我们发现在中台建设的演进过程中都会或多或少陷入到同样的问题。

所以，问题不在于企业原本是哪类的组织结构，问题在于中台团队本身的定位。

在两种组织结构的推演中，因为Shared Servie（共享服务中心）的组织概念历史悠久，深入人心。所以我们大多默认会将中台团队一开始就定位成一个内部的共享职能团队。

中台团队被定位成一个共享职能团队，中台团队与前台团队之间的关系是服务和被服务的关系，这才是问题的关键。

因为中台是一个共享服务团队，与前台是服务与被服务的关系。那自然前台出钱，中台团队为其提供服务就是天经地义的事情，正所谓“拿人钱财替人消灾”。

这时候就会出现两种情况：

一种情况是，因为中台建设的复杂性和长期性，导致短期无法满足前台团队的短期业务需求，业务方不满，觉得花了钱没有得到相应的服务；中台团队责因为背负着业务的持续施压，无法按照自己的节奏推进中台建设，痛苦不堪，矛盾产生。我管这种矛盾叫做：短期战术目标与长期战略目标的矛盾。
一种情况是，中台团队迫于压力极力满足前台的需求。但因为中台的企业级性质，中台团队需要同时面对多个不同的前台业务、前台团队。因为每一个前台团队都是“金主、客户、甲方”，在中台团队眼中地位是一样的，都是需要极力满足需求的。而因为前台团队“花了钱”，为了能获取更多的中台资源使用权，自然都会给中台团队提出各种各样的需求，来争取到更多的中台资源，导致中台团队的需求短时间剧增，但因为毕竟中台的资源有限，所以自然而然会出现之前反复提到的需求剧增、排期、冲突等问题，矛盾产生。我管这种矛盾叫做：多前台由于中台资源竞争所产生的矛盾。

破局：产品化中台建设

问：那，如何破？

答：给中台一个边界，产品的边界，将中台团队从共享职能团队转变为中台产品团队，将前台与中台的关系由被服务与服务的关系变为产品与产品的关系，既：

Platform as a Product！

呼……终于回到了主题，希望你还在：）

我发现一旦我开始尝试用产品化的视角和思路去思考中台时，脑子就像开了闸一样，持续不断地蹦出各种各样的问题，而思考和回答这些问题的过程，恰恰就是回答之前各种困扰和问题的过程。

不信？你也可以试试，像我一样，对照着自己的中台，问自己下面这些问题，看看是不是也有所启发？

而我自己，就在思考后认为，如果中台是一个产品，则意味着：

中台作为产品需要有自己的愿景定位，不一定需要满足所有前台客户的需求，这同样也意味着前台可以选择不使用中台的某些能力而选择自建。
中台作为产品需要有自己清晰的用户定位和用户划分，前台作为中台的用户不再是平等的，VIP前台用户的需求要优于免费前台用户的诉求，通过产品上常见的用户划分来解决需求膨胀、排期、优先级和冲突问题。
中台作为一个产品，需要想方设法体现自身的价值，真正为前台客户解决实际问题，并关注前台用户体验，通过营销和售前等手段获取前台客户，通过清晰的用户定位和产品力吸引前台客户，让其主动选择采购中台产品。
产品的建设初期，不一定启动资金直接从业务上切分，可能需要类似于天使投资的企业战略投资进行初始孵化，减少中台前期建设的业务交付压力，甚至作为企业的战略级产品，需要一些内部保护和孵化，但仍需要快速验证其价值，获取客户，实现自负盈亏。
产品的建设过程可以借鉴精益创业思路，需要尽快体现其商业价值，如果一定时期内无法获取相应的前台用户（前台不用），或是其他考核指标不达标，则需要进行中台建设止损，类似于创业失败。
甚至在特殊情况下，允许同一类型的中台产品存在合理的内部竞争，同时对两个相似的中台产品进行孵化，使用类似于内部赛马的机制解决内部服务差异性带来的内部产品垄断和定价困难问题。
中台产品为了用户留存，需要对于前台客户提供产品级SLA，提供客户运营，客户售后服务，保持产品平滑更新，关注用户满意度，实现客户留存与转化。
……

有意思的是，在思考这些问题的同时，回头再去看看这几年一直关注的阿里中台，才意识到答案其实一直就在那里。阿里巴巴早已将自身的中台能力，通过产品化包装整合到了阿里云上，对外输出，无论是承载了技术中台能力的Aliware，还是承载着数据中台能力的Dataphin，还是承载着研发效能能力的云效。

再去看各大互联网巨头，亦是如此，早已将眼光放到了更宽阔的企业外部，放到了整个社会，放到了各个行业，通过中台能力的产品化包装和输出，开始打造各自的生态系统了。

总结

基于企业的使命与愿景，结合当前的商业形势，制定匹配的公司战略，并基于战略迅速调整组织进行战略落地。再根据康威定律，通过组织的变化引导IT架构的演进，所以中台的诞生只是企业战略层面上，在企业发展某个阶段强调加强组织横向协同性的一个中间产物而已。
天下大事分久必合合久必分。战略在不断调整，组织就会不断调整，IT架构就会不断调整。凡事没有完美，没有完美的战略，没有完美的组织，也自然没有完美的IT架构，都是在持续地演进中。所以要将关注点从试图找到完美的解决方案转换到提升调整能力上来，这点无论是对于战略、组织还是IT架构都是适用的。
聚焦到中台建设的过程中，引入产品化的思路则可以让我们换个视角更好的思考中台的边界和责任，思考其核心的建设价值，更好的解决中台建设过程中出现的各种矛盾与问题。
同时可以将中台切成更小的产品单元，引入类似于组织中台这样的内部孵化投资管理组织，对于中台产品群进行产品化市场运作。这样的好处还在于可以通过投资方向的调整来引导内部IT架构的演进，加速企业的战略调整落地。
使用产品化的思路来建设中台，还有一个巨大的好处：因为中台作为一个产品，除了产品形式（可能就是API）和用户（内部前台团队）外，其他方面和其他产品没有什么不同。这就意味着在产品构建上我们过去已经积累了的大量成熟的方法和工具，都可以平移应用到中台的建设上来！

哦，对了，差点忘了，我还是觉得「企业级能力复用平台」这个定义还是Work的……只不过，再加上产品化的建设思路和方法就更完整了：）