甜腻的嘴角|头部电商的中台实践血泪总结( 二 ) 在企业业务发展中

能力：
这里用的是能力这个词，或者服务这个词，而不是用系统、功能、模块这些词——就像产品的定位一样，所有产品的，用户消费的时候，本质上都是为了得到某个能力或者服务。中台的打造也是一样的，中台的打造不是为了把原来的某个系统，某个功能在企业层面做整合打通，中台要做的是能力的抽象和共享。
这个能力每个企业都有自己的现实情况，如数据能力，技术能力，算法能力，业务能力等，具体要从哪些能力方面入手，要把哪些能力中台化，这个都需要每个企业结合自己的实际情况，结合企业的战略，结合企业的市场定位，综合再做决定。而判断的标准说来既简单也复杂：业务在后续的发展中，最高频、最迫切需要解决的是哪些场景问题。
复用：
提到“复用“这个词，或者“共享“这个词的话，想必很多朋友对中台的认知都是如此吧。
其实复用这个概念在整个行业提了很多年了，例如编写代码的时候，封装函数，各方调用，就有点这个味道。只是说，中台这个概念把「复用」这个概念的重要程度提升到了一个新的高度，而且从单单一个函数的复用，上升到了业务能力、数据能力、AI能力的高度。
读到这里的时候，其实不少的朋友一定会在心里默默地念叨：阿里的中台战略之所以这么成功，很大一部分原因就是因为阿里绝大部分的业务都是属于电商类业务，所业务上面存在很多的共性，所以才可以复用，所以做中台对于像阿里这样的电商帝国来说，才是一个很好的选择。
但这是不是就意味着说做中台的企业，必须都是业务模式比较集中的呢？
这个我觉得倒是未必。
三、中台的本质经历过了这大半年的实践之后，我对中台的本质最深的认知就是：中台的本质是一种企业级能力复用的设计思维。
在企业业务发展的过程中，在满足业务发展的系统建设过程中，每一个系统，每一个模块的设计和打造，我们都要去思考：是否有做通用化的必要？或者在未来的业务场景里是否有通用性的诉求？
至于说是否需要都像阿里那样，弄一个中台部门出来，把各大核心模块全部打造成一个中台系统——我倒是觉得未必。
例如我们在做电商卖场货品结构分析的时候，在一开始的时候，我们只做了一个卖场，但是这个模块在设计之初就有一个很重要的考量点：这个模块后续能否为其他的卖场继续提供货品结构分析服务？以及这个服务直接复用之后是否能够直接满足其他业务线的需求？
又例如创业公司在打造自己的用户中心的时候，在业务的前期，可能只有一两条业务线，而为了业务的快速扩展，在打造新产品线的时候，可能会为了求快而采取新的用户系统，但是这些用户系统设计的时候，都面临同一个问题的挑战：后续多个系统间的用户体系如何才能更加高效低成本的融合？
所以说，中台本质上就是一种企业级能力复用的设计思维。
也正因为这是一种思维方式，故而真没必要给自己加那么多的条条框框，没必要拘泥于市面上各种中台的系统现状和中台应该长什么样的定义：以快速支持业务扩张为目的，以企业级能力复用为设计思维——就可以了。
这就好比编程中的函数思维一样，把一些通用的逻辑，封装在一起，然后各方直接调用即可。就像现在很多的算法，你要是刨根问底的解释起来或者从零开始写的话，那叫一个复杂，但是当前很多的算法调用对应到python的语句中，就是一行函数而已，各方调用同一个算法的时候都十分的方便——本质上，这也是一种复用的思维。
所以说，中台落地后到底长什么样？这个真没有定论，这个要看你希望中台化的业务形态：是业务线？还是技术实现？还是算法？又或者是AI能力？除却要看你的业务形态之外，也需要和你们企业当前的系统现状做结合，进而再决定是中台是通过底层技术模块封装，还是通过中间层，又或者是通过微服务，还是说通过Sass来对外提供服务。