在写完30万字的中台100讲后，再来谈谈中台
各位关于中台读者，大家好！好久没和大家再聊聊中台相关的内容了。
最近在我写完中台100讲（《中台产品经理宝典》一书+中台实战30讲）的内容后，我终于有空在我的公众号上去回答和接受邀请去往很多企业参与中台方案的评审。
在这将近一个多月的沉淀与走访中，让我对中台这个概念在一线战场使用的人群中有了新的了解，也正是如此我决定再写一篇中台本质探索的文章，来对近期我遇到的中台高频疑问进行一个梳理。
一、中台的争议
最近关于中台争议最大的一个消息，莫过于张勇近期在阿里内网发布的一段话，大概意思如下：“张勇对目前阿里的中台建设并不满意，他直言道现在阿里的业务发展太慢，要把中台变薄，变得敏捷和快速。”
而这段话在流出后，被自媒体一番加工后变为了阿里开始要拆中台，于是乎很多人阅读完这些文章后，也开始说中台已经成为被阿里抛弃的产物。
那事实真的是这样吗？这里我想说其实这些自媒体其实已经从中台的概念源头出现了理解偏差。
也就是说如果有人认为中台是一个具体的产物或一个系统，那么此人对中台概念已经产生了相当大的误区。
如果仔细拆解这里的误区，可以发现他们的思考链条是这样的：
中台的错误认知：中台 = 一套神奇系统 = 降本提效的软件工具。
基于这个错误的认知，加上市场一些SaaS企业的恶意炒作，在市场中很多IT企业主就产生了这样的认知：
企业主的决策认知：我要降低成本 = 所以要上中台系统 = 我不清楚中台是什么，我也没有能力自研 = 我要去买一个中台系统。
大家试想下，无论是之前的某酒厂的中台失败案例，还是某电商的3千万的中台流产项目，这背后其实都是这样的企业主在把中台与一套神奇系统画等号后，进行的一系列错误决策。
二、中台究竟是什么？
那么中台究竟是什么呢？
这里我想说：中台概念其实只是一种设计思路，本质来说就是当企业发展到一定规模后，一次企业内部改建。
众所周知在互联网公司内部的产品其实都是为企业业务所服务的，在很多时候产品的建设都需要优先满足于业务的需求。
因此在很多公司中，会出现为了追风口赶业务新产品会在现有产品基础上进行临时搭建，快速拼凑出一个临时产品。
这种场景，举个形象的例子就很像现实生活中的违章建筑。
违建虽然在一定程度上临时满足了我们的需求，但是他给整座大楼带来了安全隐患，会影响到楼层的稳定性，同时也将原有的楼层主体进行了破坏。
而且更重要的是这种临时建筑由于没有进行全局的设计，只是在现有的结构基础上临时拼凑出来的，就会导致其自身的使用性能与使用体验远低于正常水平。
所以很多时候，在新业务发展到一定时间后，我们都会选择重构来为新业务重新设计产品。因此中台这个概念，本质上就是一种企业内部全产品线的一次改建方案，具体来说分为两点：
- 对企业内部的这些违章建筑进行一次改建，拆除原有的违章建筑，并将这些违章建筑的原有诉求进行合并；
- 为了避免在企业后期再次出现违章建筑，我们需要将时下已经跑通并且验证了业务功能变成可复用的原子组件，让其他业务方可以在出现诉求时，直接用现有的组件去拼装出自己的解决方案。
第二点这里我再举个不怎么正确但是很好理解的例子，就是当我们需要再开发一个新的商城时，在公司内部我们可以选择把做的最完整那条业务线的PRD与代码拿过来，此时我们就有了个现成的商城。
当然为了让一份PRD与代码可以全公司复用，我们在设计时就需要尽可能的抽象，比如在某业务线中设计的入库模块，他们根据业务需要在入库类型中定义了海淘商品入库单、残次品退货入库单两种类型。
但是大家试想，如果在新的业务中，商城中不涉及海淘的业务，那么在拿到这个业务线的代码时，就会觉得这里的入库单还需要二次开发。所以我们在将自己的代码交给别人复用时，我们应该先将自己业务的逻辑剥离掉。
比如这里，我们就应该将海淘商品入库单、残次品退货入库单进行业务剥离，得出抽象后的入库单与退货入库单两种原子组件。
当然这里的例子不是很正确，只是为了帮助大家理解。在实际的中台抽象中我们需要大量的建模，原子组件定义等等，这里我就不展开详述了，感兴趣的可以去看看我的《中台产品经理宝典》一书。
三、中台落地产物
涉及到中台的另一个问题就是，中台的落地产物到底是什么？
当我以外部专家身份，参与了多家企业的中台方案评审后，再来看这个问题，我的答案就是：中台产物其实就是六个字，“下定义、给标准”。
1. 下定义
当有多个业务线都存在同一事物时，我们要通过中台的改建将这些不同的事物进行统一化。例如在电商中，一提起指标，在不同业务线中就变得五花八门。
例如毛利、核心用户群，每个业务线都有自己的定义，而我们要做的就是要给这些不同业务线都有而又定义不同的事物一个标准的定义。
这样定义的好处是，以后在任何场景大家都能以“同一国语言”来进行沟通了。
当然这里的定义我们不能一味地为了大而全就把所有的业务概念进行统一，就像上文提到的核心用户群，在不同的业务线中确实是存在不同的定义：
- A业务线：对下单频次高，客单价高的用户称之为核心用户群；
- B业务线：对单位周期内订单总金额为前20%的用户称之为核心用户群。
此时这样的定义可以看出存在明显的业务诉求，因此我们应该保留而不需要中台进行统一定义。
2. 给标准
除了要对企业内部同一事物进行下定义外，在很多时候我们还会遇到，很多业务线确实对同一事物有个性化的需求。
例如订单中心，由于各个业务线的业务模式不同，我们最终落地的订单就会有对应的业务场景所需的功能嵌入。
例如：
- 海淘订单：有复杂的关税相关逻辑；
- 大客户订单：有账期逻辑，履约配送仓库逻辑等。
此时进行中台化，我们要做的内容就是对这些订单定一个标准，告诉各个业务线你的订单生成逻辑需要有什么样的标准、什么样的数据格式、业务线的个性化需求插入方式。这样当我们去统计各个业务线的订单时，我们就有了一套标准的订单格式。
这样在中台看到的订单，就不会存在有的订单是10个字段，有的是15个字段；存储的信息范畴也不同，有的存储商户ID，有的存储商户CODE等等。
本质上中台让各个业务线的订单创建流程、字段数、存储格式上都有了一套标准。
四、最后
最后，中台并不是一个具象化的系统，而是企业内部进行信息化自我升级的一次改建工程。
因此中台要能够顺利的完成企业内部的建设与实施，所必经之路就是要对企业内部的业务与信息化有充分的调研，在此基础上以强定制化的方式给出适合本企业的中台解决方案。
最后的最后，说一句会触动现在市面上很多软件服务公司利益的大实话：任何企业都绝不可能凭空给出一招鲜吃遍天的通用中台解决方案或软件。
#作者#
三爷，微信公众号：三爷茶馆，2019年年度作者。《中台产品经理宝典》作者，原万达高级产品、MBA特约讲师、独立创业者，现叮咚买菜B端产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
