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

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

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

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

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

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

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

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

破局：产品化中台建设

问：那，如何破？
答：给中台一个边界，产品的边界，将中台团队从共享职能团队转变为中台产品团队，将前台与中台的关系由被服务与服务的关系变为产品与产品的关系，既：
Platform as a Product！

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

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

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

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

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

……

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

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

总结

基于企业的使命与愿景，结合当前的商业形势，制定匹配的公司战略，并基于战略迅速调整组织进行战略落地。再根据康威定律，通过组织的变化引导IT架构的演进，所以中台的诞生只是企业战略层面上，在企业发展某个阶段强调加强组织横向协同性的一个中间产物而已。

天下大事分久必合合久必分。战略在不断调整，组织就会不断调整，IT架构就会不断调整。凡事没有完美，没有完美的战略，没有完美的组织，也自然没有完美的IT架构，都是在持续地演进中。所以要将关注点从试图找到完美的解决方案转换到提升调整能力上来，这点无论是对于战略、组织还是IT架构都是适用的。

聚焦到中台建设的过程中，引入产品化的思路则可以让我们换个视角更好的思考中台的边界和责任，思考其核心的建设价值，更好的解决中台建设过程中出现的各种矛盾与问题。

同时可以将中台切成更小的产品单元，引入类似于组织中台这样的内部孵化投资管理组织，对于中台产品群进行产品化市场运作。这样的好处还在于可以通过投资方向的调整来引导内部IT架构的演进，加速企业的战略调整落地。

使用产品化的思路来建设中台，还有一个巨大的好处：因为中台作为一个产品，除了产品形式（可能就是API）和用户（内部前台团队）外，其他方面和其他产品没有什么不同。这就意味着在产品构建上我们过去已经积累了的大量成熟的方法和工具，都可以平移应用到中台的建设上来！

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

本文转载自健荐公众号。

原文链接：https://mp.weixin.qq.com/s/DxjRze7GmtIpOrC1FxdWAQ

创作场景

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