中台实践分享

「来自犬校同学simon在犬校talk频道的分享」

最近一年半在做中台相关的工作（虽然名称上没有直接命名为中台），碰巧最近中台的概念火起来了，业内有很多讨论，我整理了一部分主流的观点，配合我自己的经验，分享给大家，欢迎一起讨论、相互补充。

因为中台业务往往涉及较多公司信息，从职业规范角度不便多说，以下内容均经过脱敏调整，存在部分关键信息缺失，实操使用前建议补充多方信源、谨慎思考。

提纲

• 中台的定义

• 为什么需要中台

• 中台能解决什么问题

• 中台业务建设的方法

• 某公司中台化实践的案例

• 中台化过程中遇到的难点

一、中台的定义

因为中台是近期才逐渐火起来的概念，关于中台究竟是什么，业内众说纷纭，根据一些主流的讨论，常说的中台有好几种，比如组织中台、数据中台、技术中台或业务中台（个人比较赞同的是三节课邹老师对于中台的定义）。

中台更多是因为公司业务在发展到某一阶段时（在主干上同时长出很多分支，或者多个新领域同时布局），遇到瓶颈与障碍后，为解决实际问题而提出的解决方案。

各类中台的定义，综合业内的各种材料，结合我自己的理解，按照实现难度排列如下：

• 技术中台：技术中台指的是将业务通用的技术能力（技术中间件、基础设施、算法等）收敛到同一个团队负责，提供简单、易用和可靠的应用技术设施，防止其他团队重复造轮子，常见的有账号服务、日志服务、发布平台、存储服务等，是最容易实现的中台，核心价值是降成本（早期很多大公司就有类似的团队在做各种技术平台，这些技术平台跟技术中台是一脉相承的关系）

• 数据中台：沉淀数据存储、加工、分析/挖掘和数据服务，从共性需求里提炼数据产品，支持业务数字化运营（基本的数据采集、数据仓库建立和数据加工能力的共享，是偏数据的技术中台的范畴，业务的数据打通、数据共享和数据产品属于数据中台的范畴，在国内比较少见，现在大部分公司的数据分析是在不同的前台业务线自己实现）

• 业务中台：以电商为例，抽象沉淀的是支付、订单、营销、供应链、配送等业务能力，为前台业务（比如生鲜、医药、跨境等垂直电商业务）创新提供支持，因为业务复杂度高，所以对平台类PM的需求比之前2个中台要旺盛，现在业内讨论比较多的基本是业务中台

• 组织中台：最难的部分，在组织架构上实现中台化，需要公司有很强的顶层设计能力，典型的例子是字节跳动的商业化、UG等是由独立团队负责，同时支持了不同的业务团队

二、为什么需要中台

互联网的人口红利和流量红利使得许多公司在过去几年进行了大规模业务扩张，随之而来，公司内出现了重复建设和复用难的现象。

重复造轮子：业务快速发展过程中，许多需求是高度重复的（比如营销类的能力，优惠券、满减、抽奖），因为没有专门的团队负责规划和开发，各业务线自行开发建设--->资源浪费、用户体验不统一。

复用难：业务在演进过程中，产品技术团队为了快速实现当下的业务需求，本着能用就行的原则，将业务功能与基础系统耦合在一起，没有平台性质的规划，每个业务系统像烟囱一样高高耸立，并且系统间的交互错综复杂--->开拓新业务、新市场时，系统没法直接复用，甚至没法快速迭代。

为了能体系化地解决这些历史债务，复用已有的资源与系统，支持新业务的快速试错和迭代，提高企业运作的效率，中台战略应运而生。

对于什么样的系统/业务可以中台化，我一般从3个角度考虑问题：

• 行业内的其他公司怎么做？

• 现有公司的场景是否需要中台化？

• 当前业务是否适合中台化？

  
  

拿比较容易通用化的支付系统为例，先看看业内的主要公司的做法：

阿里：最早实施中台战略的公司，集团内的支付服务接入主要是收敛到业务平台事业部-支付平台（业务平台事业部包括：会员平台、商品平台、店铺平台、交易平台、营销平台、支付平台、资金平台、结算平台、财务平台，以及围绕商品的商品知识图谱数据产品，围绕用户位置信息的地动仪数据产品）。

美团点评：收敛到金融服务平台-支付平台部，包括线上支付业务（提供收银台给外卖、团购、酒旅等业务）和线下收单业务（提供智能POS给美团点评的线下商户）。

京东：收敛到京东数科（金融）-支付团队。

携程：收敛到携程金融-支付团队。

腾讯：腾讯内部有微信支付、QQ钱包2个支付品牌，有米大师这样的计费平台（2003年筹建，为了满足腾讯内部的各个产品线进行话费、点卡充值的记账与集团对账需求，2005年腾讯组建财付通支付平台，米大师主要做聚合支付通道并给腾讯内部产品使用，腾讯内部游戏业务是最主要的接入方），内部山头多。

综上，大型互联网公司多有专门团队提供标准化的服务。

再看看公司内部的情况，是否存在重复造轮子和复用困难的问题：

已有的多个业务团队自行重复实现类似的功能，维护成本高，且支付、提现、对账等涉及较为专业的知识，部分产品研发无相关背景，容易出现资损事故；支付与业务系统耦合，复用性较差，新业务接入支付时需要从头开始，时间成本高。

最后看看业务本身，是否适合中台化：

公司内部业务对支付的功能需求比较类似，主要是聚合支付类需求，功能的通用化程度高，可以抽象作为通用服务；支付、提现、红包等资金相关业务有一定的专业性门槛，由专业的团队来做，整体成本低、沉淀能力提高效率（比如，提升收银台的转化率、降低系统故障概率、提升渠道侧成功率）。

三、中台能解决什么问题

对于很多公司来讲，进入到高速发展、业务扩张阶段时，容易遇到的问题是：以往的产品模型、商业模型、组织架构，无法应对新增的大规模用户增长/业务增长/复杂度上升到来的压力。

以连锁饭店的扩张为例子说明：

初期夫妻店，一开始老板做菜，老板娘招待收银，因为饭菜味道好、物美价廉，生意越来越好，小店里逐渐坐不下了，夫妻俩扩张店面，雇人做菜跑腿；

小店升级到大店，老板和老板娘都去招待客人，请了几个厨师专门做菜，后来生意越来越好，一家大店有了招待、收银、厨师、帮佣、保洁等员工；

随着店越来越大，老板开了第二家店、第三家店、第四家店，新店的模式复制上一家店；

夫妻店做成连锁店的过程中，老板的身份也在不断发生着变化，从杂工变成厨师，从厨师变成职业经理人，从职业经理人变成股东，从股东变成老板。

这时候，问题逐渐来了，因为连锁店开了很多，每家新店的招聘、培训、维护的成本都很高，合适的厨师难招；因为客户太多，招待和厨师都满负荷工作，也没时间钻研新菜，店里没有新菜品推出；店与店之间各自为战，连锁品牌的口味和稳定性不统一，老顾客意见很大。

从以上的例子可以看出，快速扩张过程中遇到的问题主要是：

• 资源不足，人力有限--->新业务/新区域/新市场的扩张能力受到制约

• 业务需求太多，占用太多资源--->竞争优势被追上，关键能力积累不足

• 各业务自行发展、没有配合--->用户体验不一致，业务协同能力差

参考连锁饭店行业的中央厨房模式，连锁店老板做了改革，将大厨集中在中央厨房，专心研究做菜、研发新菜品，各店面的厨师主要负责后期加工制作、个性搭配，前台的招待集中精力去获客并服务客人。

从中央厨房模式中看出，中央厨房解决了连锁行业内店面扩张的几个问题，主要价值体现在2点：

• 降低成本：通过避免重复建设，降低了运营成本

• 提高效率：通过系统抽象，实现快速复用、能力不断沉淀

以上，也是业务中台在公司内的价值点。

参考业界常见的中台案例，要不要在公司内建设中台，核心判断依据是看 ROI，中台的成本是相对好衡量的，中台的收益可以参考预估：

• 公司业务是否在快速扩张期（特别是多线开战或者多地开店这两类场景）

• 中台能力是否可以共用（新业务、垂直业务是否需要这个能力，能力本身是否足够通用化）

比如，公司内产品矩阵里的同类型产品比较多、存多个垂直领域的产品同时发力的场景，在资源有限的情况下，如果通用服务（比如UG、直播、审核、商业化等）可以通过一个中台来提供，就能使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度避免重复造轮子。

四、中台业务建设的方法

以上讲的是中台的定义、价值等部分，这些内容相对简单，业内的讨论虽然众说纷纭，但思路基本类似，大部分观点上可以达成一致结论。

至于中台怎么搞的部分，就非常复杂了，不同的公司面临的问题和背景条件不一样，没有很通用的方法论，只能“具体问题、具体分析”。

我在实践过程中整理了一个中台建设的7(A-G)步法，这个方法可能不适用于每个公司，实际落地时需要灵活变通：

1. 调研业务现状

2. 确定中台目标

3. 抽象业务核心流程并提炼功能点
   

4. 设计中台架构，梳理前中后台关系，给出核心路线图
   

5. 争取资源支持
   

6. 搭建中台团队机制（协作、接入、运营、问题处理、质量控制）
   

7. 详细功能设计与落地

   
   

拿一个虚构的例子来说明一下不同步骤的作用，以下案例均为虚构，与业内真实的任何公司无关。

背景：

某旅行电商公司，以前主要做机票比价和预订业务，随着业务不断扩展，发展出火车票、景点门票、船票、跟团游、酒店、保险等多条业务线，各个新业务部门相对独立，每个部门都有自己的一套产品、研发、运营、商务、财务等团队。

该公司在发展新业务过程中遇到的问题：新业务获得的支持比较少，迭代不够快，多个新业务间资源重叠浪费，成本较高。公司的CTO想缓解这个问题，所以安排了手下的资深PM小A来调研一下。

A.调研公司业务现状，主要是为了摸清楚公司业务的现状、业务流程、核心相关方。

这一步，主要是为了解决以下2个问题：

除非特别幸运，中台需求的提出者一般不是业务的需求方，小A需要给出双方都满意的解决方案，比如这里，需求的提出者是CTO，但新业务线的leader们会有不同的想法，需要提前摸清楚业务线的想法和目标。

中台是最近业内才兴起的概念，大家都是摸着石头过河，提出人可能都很难明确需求和最终的效果，公司是否需要中台、业务本身是否值得中台化，这些都是小A在一开始规划时就需要回答的问题。

所以，调研的过程中，就需要小A能回答几个问题：公司内部业务有哪些（全面无遗漏）、业务线的相关方有哪些（比如产品、运营、技术负责人是谁，部分业务如支付还涉及财务等）、业务线相关方的诉求和目标是什么（KPI、关注的点、担忧的点、业务目标、精力分配）、用户分析（用户是谁、如何使用、用户场景）、业务功能（业务有哪些功能、性能有什么要求、是否适合中台化）。关于业务功能是否适合中台化，评估的方法可以参考第二章的3点原则。

因为中台关联很多业务方，这个环节是中台建设流程中最重要的环节，如果做得不好或有遗漏，往往后续需要花十倍、百倍的精力来弥补。

考虑到业务部门的业务成熟度不同，不同团队的配合意愿差别很大：

• 成熟期业务，配合意愿相对一般（因为一旦采用中台，反而需要调整已经成熟的原有业务）；

• 发展期业务，正缺资源，为此提出若干个性化诉求，且往往并不稳定，容易调整；
  

• 起步期业务，可能暂无相关需求，规划的诉求比较模糊。
  

B.确定中台目标，确定中台化涉及的业务

基于第一步调研的信息，这一步主要是确定要哪些业务功能需要抽象为中台、这些中台的建设目标，为后续评估立项做准备。

比如，小A发现，旅行电商公司的各业务线都涉及了商品、库存、交易、订单、支付、财务、售后等环节，综合考虑了业务的需求紧迫程度、功能的通用化程度、业内其他公司的案例等因素，确定了最终需要中台化的系统包括：商品、交易、订单、支付（仅仅用于举例，不要纠结选择的原因）。

因为中台的建设是一个长期的过程，期间会遇到很多波折与困难，为了能将顺利地将愿景落地，需要为每个中台指定一个目标，由目标延伸出考核标准。

比如，小A经过调研后，发现业务对支付的痛点是1）接入耗时长，2）功能复杂，3）对账繁琐。CTO的愿景是，将业务从这个事情里释放出来，业务不需要关心支付的细节，将愿景细化后获得目标：

• 覆盖所有主流支付渠道（微信、支付宝、QQ钱包、银联等）--->支付渠道和支付方式的覆盖率

• 最简单、快捷的接入体验--->业务接入周期和工作量
  

• 简单易用的管理平台，方便财务管理对账--->财务等职能团队的满意度
  

• 安全稳定的系统架构--->安全事故率、服务稳定性
  

C.抽象业务核心流程并提炼功能点

基于第一步调研的信息，这一步主要是将需要中台化的业务功能抽象，详细梳理出业务流程（正常流程、异常流程、使用场景）、用户分析（用户是谁、用户使用场景）、业务功能（系统模块、功能点）。

根据不同公司的历史背景与现状，有2种中台化的路径：

(1).中台直接由最成熟的业务来孵化。

最成熟的业务方离业务足够近，积累的经验和案例足够丰富，场景复杂度和系统完善程度都高，基于已有业务抽象出中台系统，业务线同时会调配一些PM来做中台，难度会大大降低。比如脱胎于三淘（淘宝、天猫和一淘）时期的阿里业务平台（商品平台、交易平台、营销平台），后来顺利演进成为了业务中台；或者，有的公司会通过行政手段把职能重复的研发团队和的系统合并成立中台团队。

这种模式下，中台团队一般有人、有系统，跟各业务关系相对较熟悉。

(2).单独成立中台团队，重新构建中台系统。

公司单独成立一个团队/部门来做中台业务，人员可能是从其他团队抽调或者自行招聘补充，需要基于业务场景重新构建中台系统，并探索与业务系统间的边界。

这种模式下，中台团队陆续有人，系统需要重新建设，跟各业务的关系需要重新建立。

之前第一章提到过，中台化的难度是：技术、数据、业务、组织，因为越往后，越需要一线业务知识的介入，而中台团队往往远离一线炮火，对业务的认知和灵活程度有问题。对于自建中台团队和系统的路径来讲，这一步的难点，主要在于中台部门往往对前台业务不够了解，跨部门协作的成本又较高，容易因疏漏导致覆盖不全，白白损耗团队的人力和时间。

结合第一轮调研，这一阶段需要注意的点有：梳理所有的业务方（别遗漏）、寻找合适的相关方（找对人）、形成业务宏观认知（了解业务在做什么）、细化需求提出人的愿景（中台做什么、做到什么程度、与业务协作的边界）、绘制业务流程与功能模块。

比如，小A经过第一步的调研后，确认了火车票、景点门票、船票、跟团游、酒店、保险等业务线的业务负责人、产品负责人、运营负责人和财务负责人，并通过领导的介绍找到了各业务的对接人，通过2次的访谈，熟悉了业务线的主要业务、用户群体与使用场景，然后整理了一份简明扼要的报告，找机会在跟CTO汇报时确认了愿景细化后获得的目标（第二步）；然后小A再次找到各业务的对接人，通过2-3次访谈，全面了解业务流程、功能模块、业务规则，并产出了一份相近的业务需求文档。

D.设计中台架构，梳理前中后台关系，给出核心路线图

确定需要中台化的业务模块后，就可以开始设计中台化的系统架构，此时就涉及到中台系统与前台、后台系统间的协作关系、服务链路。

之前提到过，有2种中台化的路径，对于中台直接由最成熟的业务来孵化这种路径，因为已经有成熟的业务系统存在，前台、中台和后台间的关系相对容易梳理，主要的工作在于理清楚三方的边界，确定三方的服务与交互内容（中台是什么，能提供什么服务，如何给前台提供服务）。对于单独成立中台团队这种路径，因为之前各业务系统已经跑起来了，而中台是新生的产物，一旦采用中台，反而需要调整原有的业务系统，改造的代价比较大，主要的工作是梳理出增值的价值点（为何使用中台比维持现状要好）、三方合理的边界（不同的业务有不同的诉求，需要灵活处理）、确定三方的服务与交互内容（中台是什么，能提供什么服务，如何给前台提供服务，三方如何配合改造）。

前台如何定义、前台和中台如何划边界，取决于公司的业务现状与未来规划，是一个动态博弈的过程。

有了前中后台的架构图，大体梳理出需要做的事情了，就可以根据团队的规模、系统建设的工作量、前期沟通调研中各业务的态度等，估算出中台落地的核心路线图与里程碑，路线图可以将中台化的过程分为3个主要的时期：中台建设期、业务接入期、中台成熟期。这个路线图因公司不同、中台化业务的不同、高层的支持力度，会产生很大的区别，不同场景下的路线与时间没有很强的参考意义，“具体问题、具体分析”。

假定这里的小A比较幸运，CTO的思路是将机票业务中的核心系统抽象出来，发展为中台，所以前台和中台的边界可以参考现有系统的边界，在合理的设计范围内进行解耦。考虑到是通过已有系统整合新业务，团队也是从原机票业务抽调，中台建设期预估是3个月，业务接入期预计是3个月，然后进入中台成熟期，能力不断沉淀、系统不断组件化/通用化。

E.争取资源支持

中台业务最难的不是业务或产品设计本身，而是业务协作、组织架构和资源的重新分配，分配过程中自然可能会有冲突 ，况且大部分公司做中台时，前台和后台业务本身已经有一定的起色了，有没有公司高层的支持，对于中台业务团队的发展来讲很重要。做完了1-4步，业务现状、中台化架构、路线图掌握在手，接下来需要做的就是争取支持了。

支持分2部分：公司高层的推动，前台业务部门的认可。

1）第一个是高层支持，没有高层推动很多事情没法做。

中台化任务，一般都是公司高层有这个idea或想法后，安排手下的团队去尝试梳理和落地，所以之前1-4步的工作完成后，找机会跟领导做汇报，主要讲清楚业务现状（和痛点）、中台化架构（与价值）、路线图（与协作需求），先争取到自己汇报线条领导的支持，期间可能有多次汇报，逐级递增，直到获取到高层的支持和认可。

中台项目的立项与落地，依赖于高层的支持，但又不能全靠高层强推，因为中台面临的问题是需要从前台抽取部分业务，并让前台业务接入到中台里，有的前台业务本身已有专门的团队/人员在负责相关的事情，接入中台后相关产研就不得不转岗或换业务，所以高层强推是很容易引起前台业务的反感，一旦前台业务与中台产生冲突和不信任，对于中台项目的落地非常不利。

2）前台业务部门的认可

第二个是前台业务团队认可，中台需要为前台带来价值，前台才愿意将服务迁移到中台上，如果中台提供的服务不好，依赖老板强行推广，前台业务大量投诉，老大们就需要评估是保能赚钱、能服务用户的业务还是保刚刚起步没带来增量的中台了。

中台项目在已经向公司高层汇报，并获取高层支持后，就可以借由高层的关系，约各个前台业务部门的负责人做项目汇报，争取前台部门的认可。

因为前台业务跟公司高层关注的点不同（公司高层关注的是公司层面各业务的发展和组织架构的治理，而前台业务关注的是自己业务的发展与增长），沟通前要注意做好准备。

需要注意的点包括：

争取相关人员的支持（梳理自己或领导的人脉，看看是否有跟前台业务部门熟悉的同事，是否认识前台业务部的关键人物，可以侧面协助私下沟通；争取利益相关第三方的支持，比如一个营销中台的项目，会涉及运营、市场、研发、产品、财务等职能，在说法前台部门时，尝试先争取到财务、市场和运营等部门的支持，组团说服前台团队）

说明收益（因为建立中台的最终目标是为了业务发展更好，所以中台需要为前台带来价值，不管是降低前台的成本，还是增强前台的效率或能力，这个未来的收益一定要说清楚；收益可以从两个角度来陈述：接入中台有什么好处，不接入中台有什么潜在的损失）

数据论证（通过第三方的数据或者案例来论证项目的价值和必要性，比如行业内其他公司的实践经验）

不要直接批评前台业务部门（讲收益时避免直接指出前台业务的问题，避免反感）

在这个案例里，小A和其leader先向CTO进行了汇报，获得CTO的支持与认可，然后由CTO在高管会上向CEO汇报，争取到CEO的支持。然后小A跟leader一起约主要的业务部门领导，与前台业务做详细的沟通，不过效果不是很好，因为近期机票业务的增长压力较大，机票的leader本来就很烦，再加上需要从机票业务线抽调人员去做中台，担心以后中台的支持力度会下降，影响业务发展，机票的leader在会上批评了小A，导致第一次沟通尴尬终止。小A回来后，跟leader一起反思复盘，痛定思痛，做出如下改进：

1）私下沟通，确定机票leader的担忧、近期的目标，

2）列出所有利益相关方，分析立场，尝试逐个攻破，

3）找新业务线的leader先沟通，获取认可支持（新业务的人力紧张，相对欢迎中台来支持，后续需求提给中台来实现），

4）针对机票leader的问题，梳理中台拆分方案，人力需求与对业务的支持方式（保障后续对业务的支持及时），向CTO汇报，

5）请求CTO从中协调，再次与机票业务沟通，获取业务认可。

F.搭建中台团队机制（协作、接入、运营、问题处理、质量控制）

争取到高层与前台业务部门的支持后，中台业务就进入了项目的落地实施阶段，除去中台化架构、路线图等偏向于产品与技术方案的事情，中台团队还需要解决一系列的机制问题，这些问题主要包括：

中台如何与前台协作？（中前台的边界与关系是怎么样的，各接口人和负责人都是谁，前台如何提需求/报问题给中台）

前台如何接入中台的服务？（中台提供哪些标准化、组件化的服务，前台如何低成本接入）

中台的运营团队如何给前台业务提供支持？（有的中台可能没有运营团队，有的中台业务需要运营支持，比如支付的中台，有专门的岗位负责商户入驻接入、渠道路由配置以及异常订单排查等工作）

中台的问题处理机制？（如何及时发现问题，如何确定处理流程，如何知会前台业务）

中台的服务如何做质量控制？（需要定义什么样的服务是好的服务质量，关注的核心指标是哪些）

中台的团队绩效如何考评？

以上问题，很多不是产品负责的问题，需要整个团队一起来完善和制定（涉及产品、技术、运营、测试等团队），制度建设的周期一般比较长，在中台化的过程中会不断磨合调整，直到达到一个稳定的状态。

G.详细功能设计与落地

从这时候开始，中台项目的立项等工作终于接近尾声，这一部分主要做：

• 设计产品架构

• 模块拆解
  

• 详细功能设计
  

• 技术方案设计
  

这一部分因各中台对应的业务不一样，具体如何设计的方案差别也很大，在此不再详细描述。

五、中台化过程中遇到的难点

上面林林总总写了近一万字，现在回头看过来，上面已经涉及到中台化过程的几个难点和对应的应对方法，除此之外，再补充几个。

1.组织架构和顶层设计是否适合做中台？（团队的人和钱从哪里来）

中台战略最复杂的因素，其实是组织架构，即安排谁来做中台。组织架构的调整，就是对责任、权力和利益的再次分配。

之前已经提到过，有2种中台化的路径：

激进的路线：重复的业务与部门，合并为一个团队，或者中台直接由最成熟的业务来孵化，从业务抽调人。

温和的路线：单独成立中台团队，重新构建中台系统，另行招人。

如果是温和路线，难度在于：独立部门从0到1，要吃掉前台业务2-3年已有的业务和系统，这要求中台要做到对业务的熟悉程度很高、协调与沟通能力较高、平台级系统设计能力较强。

2.业务调研是否全面彻底？方案设计是否完善可扩展？

难度在于，作为中台业务部门的员工，接触到信息与层级是有限的，业务调研不彻底是很容易发生的（有的新业务在某个角落默默生长，或者没有传达到中台这边），而中台产品的需求调研务必完善，不然后期很容易返工。

所以，中台部门需要想办法建立公司内部的监听机制，以便尽快发现不在自己视野范围内的新业务（如果中台业务与某些职能岗位相关，可以借助职能部门，如财务、法务等团队协助监控）；中台立项前期调研时，需要想办法通过人脉或其他方法获取潜在前台业务，并深入调研业务场景。

3.别人为什么使用你的服务？你做的东西是否存在对别人利益的争夺？

回到之前提到的前台业务部门的认可问题，核心还是中台需要为前台带来价值，前台才愿意将服务迁移到中台上。难度在于，中台尽可能不要依赖高层行政命令强推，需要找到双方共同的目标（提升效率，降低成本），并把中台的服务与能力做好。

其实，就是把中台当独立的企业级产品去做，把前台当客户去获取，想办法为客户提供价值---如果中台能力做的好，中台能为业务提供增量的价值，前台业务为什么不用呢？

六、参考材料

上面几个部分，综合业内观点，简单介绍了中台的定义、价值、建设方法、难点等，整体偏向于PM的视角，其实中台化建设还有很多深层次的问题没有涉及，如有兴趣，可以参考如下文章进一步了解：

阿里研究员玄难：如何做电商业务中台https://yq.aliyun.com/articles/30340

三节课中台产品专场直播http://3jk.top/n/1ty

我看中台https://zhuanlan.zhihu.com/p/76606024

白话中台战略https://www.jianshu.com/nb/29862787

京东的中台实践https://tech.sina.com.cn/roll/2019-01-20/doc-ihqfskcn8748509.shtml

阿里的中台实践https://mp.weixin.qq.com/s/L6jvPtzz2M-sHTqPwsp32Q

数据中台演进四阶段https://mp.weixin.qq.com/s/8ociozq_Pc5zbL_EbQ1KcQ

数据智能深度报告，看清数据中台和业务中台的未来https://mp.weixin.qq.com/s/VTAKK0ff83cjefI3mp1mHA

深度解密阿里巴巴“中台战略”转型始末http://m.sohu.com/a/144689936_488677

p.s. 

以上内容来自犬校同学simon,他长期活跃于「黄埔犬校 / pmdogs」,如需加入,可点击「阅读原文」查看须知。

「黄埔犬校」是纯银在 2017 年发起的产品经理私密社区，需邀请加入的Slack群组，成员主要为中高阶的产品经理，覆盖所有互联网大公司，互联网行业专业的产品经理社区。