原文链接：
中台这个概念，由于阿里前些年的大中台小前台的建设。
一、中台是什么
关于中台是什么，有很多文章都有提过。这里不多赘述，我自己简单的总结：为不同的业务线提供可以重复使用的能力，形成一次建设多次使用。
（快速理解法：组件库、控件库、sketch library facebook最早提出设计中台、设计中心，国内阿里的UED，腾讯的ISUX、CDC，滴滴CDX。他们很多都没有单独的业务线，他们负责多个业务线，他们承载的地方就是中台。可以抽调人去不同的业务线服务）
类似于仓库的概念，做集中中转。中转中心，一个素材库、资料库、整理库这样的东西。
所以中台本身是一个很大的概念，在建设的时候，需要考虑不同业务线，有什么是共用的，才可抽象出来进行中台化建设。
比如阿里是电商业务，不同的业务线如天猫、淘宝、菜鸟、飞猪等等，其实都是在不同的平台去售卖不同定位、类型的商品。所以对于阿里的中台建设来说，一开始核心要建设的就是商品中心、交易中心、营销中心等等。再比如有的公司内容是公司的核心，所以会做内容中台的建设。
二、什么样的公司适合建中台
通过上面中台的定义，其实已经可以看出，究竟什么样的公司适合建中台，或者我们通过回答这几个问题来看你们公司适不适合进行中台建设。
1. 你们公司是否有多业务线？
中台的出现，本身就是为了通过一次建设，满足不同业务线的需求，减少公司内不同业务线的重复建设。
所以如果公司只有一个核心业务线，中台的建设就是不需要的。只是在开发过程中，可以相对考虑到未来的发展可能，把整体做的比较有扩展性一些。这样万一后续公司出现了多业务线，则可以在原先的核心业务基础上，将其发展为中台。
不过注意一点，为什么说是相对扩展性，因为互联网整体业务变化和技术变化都比较快，如果一开始为了后续可能出现的中台情况，考虑太过完善，有可能会拖慢一开始核心业务的发展。所以这其中的度需要把控。
2. 不同业务线是否有共通点？如果做中台，应该做哪些部分？
直播口述版：一般一个公司有不同业务线时，我们是可以做中台的。但是不同的业务线也不能完全的不着调。例如：阿里是做销售的，他往前面走是做支付，往后面走做物流，他们交汇点都是销售，这样就可以做一个中台。很多销售内容可以同时出现在支付和物流方面。
有赞也有很多产品线，有赞微商城、有赞教育、有赞零售。就拿有赞教育来说，有赞教育这个产品，他本质上也是同一种产品线，虽然他不是像阿里那种上下游的关系，但他在总的设计师眼中思考模式是一样的，你可以把有赞教育的每个校区理解成一个店铺，有赞教育的每个老师就是一个销售员，谋一节课就是一个商品，某个顾客可能就是一个买家。他的这种思路可以用在不同的产品线中，这个也是可以做中台的。
这就是2种不同情况下做中台的必要性。第一种叫做线性的中台方式，上下游业务可以做中台。第二个就是变型类比做中台，他们的模式基本是一种模式。
假如你们公司有多个业务线，接下来需考虑。不同业务线有没有共通性。
互联网有时候常常会说，一个公司可以做好一个事情，是因为有这方面的基因。不过我觉得基因讲的好像过于玄学了，其实底层逻辑是因为一个公司在一个业务下发展好后，会占据某一方面的核心竞争力，所以再利用这个核心竞争力去扩展自己的生态，做生态上下游的事情，就会借势更容易成功。
比如阿里一开始做电商，围绕电商需要去解决信任问题，所以做了支付，然后要想要货品更快的到达顾客手中，所以做了菜鸟。同时由于有大量的商家，对B端的企业需求更加了解，所以钉钉这样的社交软件可以成功。
刚讲的这些题外话，是想说，一般来说对于一个公司的多个业务线（或产品），（利用公司的核心优势），其产品只是面向用户或者场景的不同，这种公司是比较适合做中台的。
比如有赞的多个业务线（解决方案），有赞微商城、有赞零售、有赞教育等。其实只是按照了不同的场景、人群在前台包装了不同的解决方案，其共通性都会有商品、店铺、订单等等。
（有赞也做了好几种业务线，这些业务线，都有商品店铺，订单等等。所以我们可以整中台了）
比如有赞教育每个校区就是一个店铺，每节课就是商品。所以其实像商品中心，不能理解为狭义的商品。
需要通过一些抽象，进行共通性的抽取（找他们产品的相似点），这样企业再做自己不同产品或者解决方案时，可以面向不同 人群/场景 更加灵活。而中台就可以越做越厚。
3. 做了中台后，真的可以提高我们公司的效率吗？
每一个事情，必须在做之前就要考虑到目标以及结果。回到做中台的初衷，是为了减少重复建设的能力，所以建设初期，我定的中台建设的目标是：业务接入的速度以及效率。所以在做之前，自己可以预想评估下，一些中台中心化建设所花费的成本，以及建设好后业务接入的成本。
有可能业务变化十分快，中台一边建设，业务一边变化，而且接入时候双方也很痛苦。所以一方面要问自己这个问题，同时要结合公司情况，来看某些东西的建设到什么程度对于效率的提升更加有帮助。
什么地方比较容易做中台？第一个中台是怎么建立的？拿什么建立的中台？为什么选这个模块建立中台？
第一点：我们最早是在交易中心开始做的，因为订单、吸引报名、招生答疑、顾客咨询这些东西很多平台都是大同小异的。获客的话术、获客的方式、获客的模块基本差不多。最后能促使用户下单的点也是差不多的。
第二点：这个模块需要非常强的稳定性，需要在一个可控标准下的重复，对我们后面的产出、供货、物流都有好。所以这个模块我们需要做标注化。这种东西天生对中台的需求就很大。
转化到我们设计领域中去，我们的产品中台在一开始搭建的时候，我们需要考虑两件事情：
第一件事情，这个部分应该在多个产品线或者在产品线的不同上下游之中都是大同小异的。
第二个，这个部分需要用户的使用稳定性较高，或者我们产品的更新频次较低，这种东西是值得的建中台的。
像登入、注册、下单、最后的支付这些模块是适合建中台的。包括我们的招牌动作、客户打理。我们虽然在不同产品线都有同一种模式，也不怎么改动，但我们后面不断融入新的产品线、新的员工时这个部分是可以复用的。
比如一般对于交易中心来说，如订单的很多字段其实对于很多平台都是大同小异的，那这部分相对标准化，而且交易这部分比较重对稳定性要求很高，需要不断维护增强稳定性，每个业务线自己开发，也比较不现实，所以这个部分的投入产出比衡量一下，还是比较有意义的。
但是对于如营销相关，可能需要判断，哪些是通用的营销能力，比如券、折扣。这种可以沉淀相关基础的。再丰富的玩法，每个业务不同，就不适合在中台做了。（H5、推广、banner等等不要做中台，或者中台只以素材为主，不做整体活动的布局）
4. 组织情况：有强力的政策让其余业务线必须接入你们的中台吗？
前面三个问题比较属于产品问题，产品问题都考虑清楚了。需要问最后一个客观因素，就是组织情况，你们公司是不是自上而下的要求其余业务线必须接入中台。
因为在中台建设的初期，比如我们公司是按照滚轮子的方式建设的，就是边满足业务需求，边建设中台。那对于业务来说，肯定有一个等待的时间。如果没有强力要求进行中台接入，很多业务可能都会觉得很麻烦，然后自己做了。长期下去，中台就会变成一个空壳。然后就会陷入恶性循环，别人总觉得你很弱，接入很慢，不愿意接入。
比如在我们公司首先从组织结构上，划分了中台以及各个前台，每个前台产品、中台分别作为一个项目，当一个新业务发展时候，由于本身后端开发资源进展，所以必须寻求中台的帮助，让一个新业务可以快速发展起来。
所以组织结构的划分也很大决定了中台是否可以建好，用一张图对上面一个部分进行简单描述，类似下面这种情况的公司，是比较适合进行中台建设的。
KA用户：key account 商家或者大客户。
什么模块做进了中台
三、建设方式：边发展边建设？OR 一步建设到位？
中台的建设方式市面上主要有两种：
- 一步建设到位：一步到位，用一段时间建设中台（比如1年、2年），建设好后再提供给多业务使用。
- 边发展边建设：发展核心业务的同时，考虑多方需求及需求的通用性，边发展边建设中台，形成一次建设，多次使用。
在许多真实的案例中，采用一步建设到位的公司大部分中台化都失败了。为什么呢，其实可以想到，中台的建设主要是为了减少业务重复开发的成本，如果一定要等中台做好了，再进行接入，有可能业务在这个过程中有的已经自己先开发了，重新接入反而是增加了其成本，变得为了建设中台而中台化。
一般采取一步建设到位的大部分是一些传统企业，将中台外包出去，因为必须明确项目范围，所以会按照项目制的方式进行建设。这种会比较难以成功。
而边发展边建设这个方式，一般适合于公司有一个核心业务，核心业务发展还不错，在核心业务的发展过程中也沉淀了比较多的能力（很多闲人，闲的没事干）。此时想要进行新业务发展时候，可以在原先核心业务的基础上，将其中台化，然后由其余产品接入。
同时需要对优先级进行判断，比如电商相关的产品，商品、订单均是必须的，则这部分必须要一起上线才可以接入。营销相关可以先有商业化后，再进行建设，一开始不用着急做营销相关产品。
四、中台的衡量指标是什么
中台建设的目标：减少重复开发，降低业务侧的开发成本。衡量的结果需要按照不同阶段进行区分：
若有收获，就点个赞吧
0 人点赞
