中台最近又成了比较热的话题，结合我对中台的认知，试图跟你回答下这样一些问题：1.网络公司的中台到底是什么？2.

  中台化据说是马云参观 Supercell 后在阿里巴巴提出的，要求“大中台、小前台”的模式。目标也很明确：小前台距离一线更近，便于快速决策、敏捷行动；剩下的交给支撑部门做。

  首先，Supercell 一直倡导“Less is more”的组织文化，整体公司员工数量保持在极度精简的水平，在去年底也没有超过 400 人，而 2018 年盈利大约是 5.1 亿欧元（39 亿人民币）。在这样精英文化的氛围下，CEO Ilkka Paananen 力求员工不要被流程和管理机制束缚，给每个小团队足够的决策权。而且由于资源稀缺，每个小团队能更加聚焦手中的资源，选择做最重要的事情。（Supercell 中的 cell 也是表达这个意思。）

  组织中台化对游戏的价值显而易见。游戏本来是创意行业，把决策权给业务前台、中台结构放权、CEO 主要来完成大家资源的支撑和整合，是合理的。

  其次，据说 Supercell 是某些特定的程度上实现了技术中台化，即前台业务团队可通过现有的各种技术模块，快速敏捷地试错。（这点待求证，毕竟游戏的复杂度很高，不知能中台化到什么程度。）

  技术中台化的核心目的是成本。成本可以从两个维度看，一个是资源浪费方面的成本，即公司有三四个业务线都在做同样的事情了，那技术上实现能不能融合可复用的部分？另一个则是时间成本，即新业务能够足够敏捷地去使用既有的技术模块去做探索。

  实际上，实现中台化的环境是相当苛刻的。连 Paananen 自己都说，他认为Supercell 的经验不是对所有公司都有效，有它自己的特殊性。他觉得 Supercell 的每个员工，都是能在外面成立公司自己当老板的，因此这种精英文化和中台化在公司得以保持。

  反观国内的网络公司，这几年都陆续提到了、或者在践行中台化。我了解到的许多中小企业，也在追随大公司的脚步，搭建中台能力。

  不过中台化显然不是万能的提效方案，也不是适用于各种公司各种领域的。夸张点说，很多人口中所说的中台化，每个字儿看起来都一样，但压根都不是一件事情。

  除了刚刚提到了组织中台和技术中台，还存在数据中台和业务中台。我们按照难易程度倒序逐一论述。

  技术中台指的是将大家都通用的技术能力聚合到一起，由同一个团队负责，防止重复造轮子，是最容易实现的中台化。核心价值是降成本，刚刚提到了。

  各公司的基础服务，以账号体系为代表，都已经是中台化的了。淘宝、天猫、飞猪等业务之间，快车、专车、顺风车等业务之间，美团外卖、酒旅、团购之间，必然要做打通。

  顾名思义，表面上数据中台是各业务的数据能够打通。不过在实际运用中，又分为多种。

  基本的数据采集、数据仓库建立和数据分析能力的共享，其实是数据技术中台的范畴，是将做数据相关工作的技术团队整合，来支持各业务。核心价值是降成本。

  各业务线的数据打通、数据共享和协同运用，则属于业务中台的范畴，是以业务目标牵头的（比如阿里的88VIP会员的前提就是用户数据打通）。

  有时这两者是耦合在一起的，既有技术能力的共享，又有业务支撑。不过在国内数据分析的认知还比较浅（认为数据都是拉报表的），后者往往效果不佳。前者在不少网络公司倒是确实落地了。

  在有些公司，数据中台只是很粗浅地把数据整合到一起，并没解决任意的毛病，或者让整合产生什么价值。阿里云中间件架构总监谢纯良曾经说过，许多公司的数据中台就是把数据加工成“大屏”，搞一个展示用的“大屏”就以为实现了中台。意思就是，数据中台如果不为业务服务，或者说为业务中台服务，那就没有价值。

  既然技术模块可以抽象出来复用，那业务模块是否也可以？在淘宝时用过的经营销售的策略，能不能直接挪到飞猪用？专车的策略能不能直接给快车用？这就是业务中台的概念。

  业务中台是各大公司追求的最终效果：前台业务敏捷推进，后台业务稳固支持。不过真实情况往往事与愿违，难尽人意，实际做到业务中台运转良好的，很少见。

  组织中台刚刚讲 Supercell 时提到了，是嫁接在前三种中台基础上，再加入“放权机制”的中台结构。

  阿里的中台业务支撑能力能支持新的电商相关业务快速创新；字节跳动把增长能力中台化，头条的增长部队能够迅速投入到抖音中去，还可以投入到海外各个国家各个产品；美团有试错小团队，会利用既有的技术能力、用户流量等资源快速试错，找到新的方向，包括外卖在内都是这样来的。

  这些都是组织中台的体现。组织中台与其说是中台能力，倒不如说是内部创业的空间。它的核心价值应该在于“旧业务能否帮到新业务”，很考验组织能力。有的企业内部创业，封闭隔离，跟这个公司自己投资了个新团队，没啥区别。

  为什么中台化的难度是：技术-数据-业务-组织？因为越往后，越需要业务团队的介入，越要有业务认知才能做到中台。而中台团队，天然就是离业务远的。

  各公司跟中台团队的协作，都存在很大的低效问题，一线的前台业务团队，要反复与中台沟通，才能讲清楚业务需求的背景，在大公司，跨部门协作都会徒增成本。另外对于中台业务团队来说，长期离业务很远，没有成长性，在判断需求时也不准确，很难获得前台业务团队的信任。

  久而久之，就变成了中台团队纯支撑、被动接需求的状态，成为“鸡肋中台”。更大的问题就在于，中台团队的价值就是整合需求、抽象能力的，在对用户和业务不够了解的前提下，这块就会做得特别吃力。如果是多个前台业务的需求有了冲突，中台团队未必能做好协调，多方要反复沟通扯皮。

  像贝壳的中台模块，就是由二手房先行推进的；而大多数通用的乘客司机产品流程，在滴滴也都是快车先发起的。最大的业务方离业务足够近，能自己决策判断大多数需求，更加高效。

  这样以来，就从“硬找一个中台团队来收集大家需求”变成了“老大哥发挥余热，把自己的能力共享出来”，具体要怎么用，仍然是各自团队来决策和执行。

  这只适用于少部分情况，即中台业务本身能自闭环。常见的比如各公司的账号体系（包括注册登录）、阿里的支付和订单流程、滴滴的地图和导航。这些业务与其它业务的关联度不大，可以解耦，能自己完成从用户到业务的认知和决策，那就可以独立出来自己做，其它业务希望使用的时候，对接通用接口就可以了。

  而大多数中台团队负责的业务不太容易自闭环。比如滴滴不同业务线的接单流程，就很难抽象出来让中台团队直接闭环自己做；或者像阿里不同业务线的商品部分、订单流程部分和支付部分可以抽象，但用户体验方面，不同前台业务差异太大，则很难抽象。

  很现实的问题是，中台团队会面临无数的需求，要处理优先级问题。如何来处理，很难有标准。

  你可以说，用业务指标即可，比如哪个前台业务方的需求能创造更大业务价值。这当然可以，但这有悖于前面提到的“中台化是为了前台业务更高效，尤其辅助创新业务”的作用。因为很简单，你的创新业务没几个用户的时候，就永远得不到中台支持，那还做个毛线。

  结果往往就是，若严格按照量化收益来排序，小业务和创新业务的个性化需求永远排不上，最后就只能自己完成，又是在“去中台化”了。

  这个问题暂时没什么太好的解法。跟每个公司的人聊，几乎都会碰到，小业务或者边缘业务对中台业务部门的诟病，认为不够支持，需求都被堵死。除了自己做，只能寄希望于，个人需要的，中台部门恰好已经提供了。

  腾讯从大半年前提出中台化之后，已经由 TEG 牵头陆续实现底层技术的一些整合，以账户体系为主。数据的整合也在做了，不过应该更多类似数据仓库的建设这种底层整合。从业务中台来说，搜索、广告、信息流都在陆续整合，基本是钦定某家的方式，分别是浏览器、广点通、FCC（信息流与内容社区业务线） 牵头做。微信仍然是飞地，不受任何中台化影响，自给自足。

  腾讯的难度应该是最大的，因为众所周知，山头林立，遍地赛马。一些新业务，无数团队都在做，而且是完全“去中台化”的方式在做。我有个朋友所在的团队，对内部严格保密地做新项目，怕被发现成了靶子，对外反倒是没那么保密，很是魔幻。

  阿里的业务中台化应当是做得最好的。网传的这张示意图较好地描述了阿里中台架构的情况。

  中间的“业务平台”中，各中心（Center）承担自闭环的业务，是我前文中提到的对“离业务远”的第二个解决方案。由于电商环境下各环节的客户的真实需求和体验都有较高相似度，且阿里的组织文化建设得足够高效，在阿里的中台部门不会存在太多“中台鸡肋”的情况，能够深入参与业务。

  比如，阿里的用户中心（ User Center ）就是统一账户管理部门，负责用户画像、用户标签等一系列基础能力建设，同时也会负责前端体验（比如“我的淘宝”）。商品中心（Item Center）会负责商品详情页，既有后端的信息逻辑，也有前端的体验。不管是“我的淘宝”还是“商品详情”，中台部门都是提供一套完整的基础能力，由淘宝、天猫以及各种前台业务部门自己去个性化使用（可以简单理解成换皮）。

  贝壳的中台刚刚提到了，是由二手部门牵头做，把二手和别的业务都面临的业务模块（房源管理、CRM系统、经纪人带看/跟进能力、合同签约等）抽象出来，提供给大家使用。中台部门没有单独拿出来，而是跟业务部门强耦合。

  滴滴除了基础服务会有平台产品部和一些支持部门（基础信息、风控等），快车的不少业务模块就是实际上的中台（例如提供接单流程、营销工具）。网约车虽是核心业务，但与其它业务相对解耦（单车、代驾、顺风车、国际化、车服），对外中台化的模块不多，主要还是一些基础服务。

  字节跳动的中台以用户增长（投放拉新为主）、技术（算法为主）和商业化（广告为主）三个部门为主，近期新增了直播中台。很明显的，这几块业务在各个方向业务上复用性比较强，业务独立性也足够。这样就能与阿里的中台类似，可以深入业务的同时保持中台的独立。头条的组织化极其看中效率，因此统一支持，效果俱佳。举个例子，用户增长团队是手握预算、以bp身份介入许多业务、有许多产品功能上的决策权的，这跟有的公司的用户增长其实就是市场投放而已，截然不同。

  美团很少提到自己的中台战略或者能力。内部在搭建的主要也是基础服务中台和数据中台。对于业务中台来说，美团业务模式之间的差异性导致不太容易抽象（团购-外卖-酒旅-物流-新零售-单车-网约车）。不过美团的组织建设对新业务很友好，每个新业务都是得到了老业务支持（当然前提是数据本身做得足够好）后生长出来的，无论是底层技术业务的支持，还是人力资源的支持，又或者是流量的支持。因此能说美团具备一定的组织中台文化。

  京东提出中台化后，也搭建了技术中台、数据中台，以及部分业务中台（比如搜索中台、营销中台）。从结构上跟阿里比较类似，不过相对低效一些，业务方与中台的协作不够顺畅，会出现前文提到的各种问题。

  基础服务（账号、支付、安全、风控等）能力的中台，相对都很完备。技术中台基本多多少少都在搭建了，渗透业务的程度各有不同。

  数据中台也大都在搭建中，不过还是侧重提供“采集、存储、取数”的能力，虽说降低了研发成本，但跨部门协作通常会增加协作成本；这样的中台，距离能提供业务决策洞察的数据中台，恐怕还比较远。真正一般数据分析的工作都是各业务内自己闭环，自己完成。

  业务中台视情况而定，有的公司业务之间天然不适合做中台化。对于适合的公司，最常见的方式，一种是难以解耦闭环的情况，就采用“老大哥”式的方法，由核心业务来提供支持，比如贝壳、滴滴；另一种是中台有机会掌握自己的业务，比如阿里的电商中台、字节跳动的增长中台。

  中台化还是要遵循“具体问题，具体分析”的道理。没有放之四海而皆准的中台化策略，有的业务就不需要中台化，有的中台化反而会适得其反。有的公司压根就只有一个业务，或者有几个业务都没有重复造轮子的现象，那硬去学习阿里的中台，一定是东施效颦了。看阿里谢纯良的采访，包括我跟阿里的朋友了解到的，阿里的中台也是“痛极思变”的过程，在跌跌撞撞中成长的，不是老板一声令下就全部到位的。

  中台化的目标都是减少相关成本，分两种：第一，现存业务之间重复造的轮子合并，减少相关成本；第二，为某些业务尤其新业务提供能力，可以低成本快速试错。

  对于有的大公司，中台化不是个技术问题，反而变成了组织问题，就是各业务线要不要接受别人提供的东西，还是我就要自己做；以及对于新业务来说，能否得到老业务既有能力的支持。

  对产品经理和运营来说，一定要加入可以业务自闭环的团队，不要加入纯支撑的中台团队。离业务远或非常容易成为“鸡肋中台”。比如在许多公司，基础服务的中台，压根是没有产品和运营这样的业务岗的，都是技术。

  在即将到来的10月26、27日，郭红保老师将在北京举办为期两天的线下集训营——【任职资格体系设计与应用】，席位有限，有需要的小伙伴要抓紧了。