中台是企业业务发展中非常重要的存在。


本文作者从三个方面讲述了自己的亲身经历，希望对大家有所帮助。


自19年中以来，中台概念的普及突然上升，我的企业（一家电子商务企业）去年年底提出了全面建设中台的战略，所以我在中台大坑里翻了半年多。


在此期间，我将的起伏总结将在后面与您分享，我真诚地希望帮助即将到来的中台建设和正在进行中台建设的朋友们少走弯路。


一、中台的起源 明确中台建设的目的很重要！很重要！很重要！ 至于中国平台的起源，我们一定听到了阿里巴巴的例子：为了快速支持业务扩张，降低开发成本，阿里巴巴以中国平台的形式提供共享服务。


那么，在这句大家都熟悉的中台定义中，中台的核心目标是什么？ 避免重复开发？ 抽离一般服务？ 不，这些只是手段。


中台的核心目标之一是快速响应业务需求。


以终为始，方得善终。


根据我们中间项目团队的个人经验，在整个项目开始时，领导为项目团队设定的目标是减少系统之间的重复开发，并在最短的时间内完成抽象的公共服务。


整个项目团队，二三十号人，几个月后，终于交付了第一阶段的公共服务。


但是极其残酷的现实摆在我们面前:业务团队根本不买单，毫不避讳地说这个东西不起作用。


在这堆公共服务建设的这几个月里，几乎所有的业务需求都停滞不前。


换句话说，在近几个月的中台建设项目中，我们只是重新整合或重构了现有的系统，或者实现了一些业务学生认为不是很重要的功能模块的通用建设，但对于业务学生来说，最紧迫、最痛苦的事情并没有得到很好的满足。


综上所述，我不想要你给的，你不给我想要的。


为什么会得到这个荒诞的结果？ 一个非常重要的原因是，目的和手段被逆转了：为了成为中间平台，为了通用化和通用化。


但是我们不妨再想想，为什么要做中台？为什么要做通用化？这不都是为了更快地响应业务需求吗？ 因此，中台建设的目的一直是为了快速有效地响应业务需求，通用化只是一种手段。


二、中台的定义 关于中台的定义，我非常同意王健先生的观点：中台是企业能力的再利用。


以熟悉的阿里巴巴为例。


他们提取电子商务业务的核心模块，并以共享的形式为前台提供服务。


这些核心业务模块包括：用户中心、商品中心、交易中心、支付中心、库存中心和物流中心。


这些中心本质上是电子商务帝国阿里的核心企业能力。


通过对这些核心能力的分散，阿里的电子商务领域可以在业务扩张过程中快速重用这些核心能力，最终达到快速响应业务的目的。


让我们逐一计算中台定义的关键词。


企业级： 企业水平，也就是说，在设计中，我们应该站在整体考虑中，定位是企业层的一定能力，而不仅仅是业务线或项目组的内部使用。


从整体的角度进行业务抽象和再利用，从整体的角度考虑数据服务的整合和一般性，以支持业务的快速和低成本的扩张。


基于以上描述：中间平台的定位是企业层面的一种通用能力。


中间平台的建设可能涉及业务线和组织的调整。


例如，在建设中间平台的交易中心时，原两个团队中的系统模块的整合和人员的调整；在这种调整下，必须由公司高推广，即自上而下推广，促进业务线的整合，促进利益再分配。


能力： 这里使用的是能力这个词，或服务这个词，而不是系统、功能、模块这些词——就像产品定位一样，所有的产品，用户消费，本质上是为了获得一定的能力或服务。


中间平台的建设也是如此。


中间平台的建设不是为了整合企业层面的原始系统和功能，中间平台应该做的是能力的抽象和共享。


这种能力每个企业都有自己的实际情况，如数据能力、技术能力、算法能力、业务能力等，具体从哪些能力开始，哪些能力，这需要每个企业结合自己的实际情况、企业战略、企业市场定位、综合决策。


判断标准既简单又复杂：业务在后续发展中需要解决哪些场景问题。


复用： 说到重用这个词，或者共享这个词，想必很多朋友对中台的认知都是一样的。


事实上，这个概念在整个行业已经被重复使用多年了。


例如，在编写代码、包装函数和各方调用代码时，它有点像这种味道。


只是说，中国和台湾的概念「复用」这一概念的重要性提高到了一个新的高度，从单个函数的重用到业务能力、数据能力、AI能力的高度。


读到这里，事实上，很多朋友会默默地说：阿里中台战略如此成功，很大程度上是因为阿里绝大多数业务属于电力业务，业务有很多共同点，所以可以重用，所以像阿里这样的电力帝国，是一个不错的选择。


但这是否意味着中台企业必须集中商业模式？ 我不这么认为。


三、中台的本质 经过半年多的实践，我对中台的本质最深刻的理解是，中台的本质是企业能力重用的设计思维。


在企业业务发展过程中，在满足业务发展的系统建设过程中，我们应该考虑每个系统、每个模块的设计和建设：是否有必要进行通用化？或者在未来的业务场景中是否有通用的需求？ 至于是否需要像阿里一样建立一个中台部门，并将所有主要的核心模块建设成一个中台系统——我认为这可能不是真的。


例如，当我们分析电子商务商店的商品结构时，一开始我们只做了一家商店，但该模块在设计开始时有一个非常重要的考虑点：该模块能否继续为其他商店提供商品结构分析服务？该服务直接重用后能否直接满足其他业务线的需求？ 例如，初创公司在建立自己的用户中心时，在业务的早期阶段，可能只有一两条业务线，为了业务的快速扩张，在建立新产品线时，可以快速采用新的用户系统，但这些用户系统设计，面临同样的问题：多个系统之间的用户系统如何更高效、更低成本的集成？ 因此，中台本质上是企业能力复用的设计思维。


因为这是一种思维方式，真的没有必要给自己增加那么多的规章制度，也没有必要坚持市场上各种中间平台的系统现状和中间平台应该有什么定义：为了快速支持业务扩张，以企业能力重用为设计思维。


就像编程中的函数思维一样，包装一些通用逻辑，然后直接调用各方。


就像现在很多算法一样，如果你从头开始解释或写作，那就叫复杂，但目前很多算法都是相应的python句子只是一行函数，各方调用同一算法非常方便——本质上，这也是一种复用思维。


所以中台落地后长什么样？这真的没有结论，这取决于你想要中台化的商业形式:是商业线吗？还是技术实现？还是算法？又或者是AI能力？除了看你的业务形式，还需要结合你企业目前的系统现状，然后决定是通过底层技术模块包装，还是通过中间层，还是通过微服务，还是通过Sass为外部提供服务。


如果真的需要给中台做一个形象类比，我觉得各种云服务都是很好的类比对象。


例如，阿里巴巴云中的各种能力，如机器视觉、智能推荐和智能语音交互，实际上可以理解为中间平台的能力。


阿里巴巴将这些通用能力包装成云服务，每个企业都可以按需呼叫。


使用相同的接口，相同的服务，每条业务线不再需要重新开发，直接使用——我们做中间，不是为了这个目的：当业务线需要扩大时，直接使用，大大降低时间成本，提高市场响应速度。


回应上一节留下的问题：作为中台企业，业务模式是否需要集中-不一定。


当然，集中是好的。


有更多的内容可以抽象和共享。


当业务扩张时，有很多场景可以重用。


就像suppercell在游戏领域，在制作新游戏时，可以直接调用游戏引擎中间平台；就像阿里巴巴在开发性价比高的业务线时，可以直接组装原交易中心、商品中心等一系列中间平台元件。


然而，腾讯等业务并不集中，其业务领域跨越游戏、社交网络、视频、内容等，你认为他真的不能成为中间平台吗？肯定不是，否则人们就不需要成立技术委员会来做这件事，比如用户方面总能收拢吧？可以抽象分享游戏引擎吗？还是底层的一些新闻推送服务可以抽离？等等…还是那句话，中台是一种思维:企业能力复用的设计思维。


可指导产品设计、技术设计、AI能力设计。


万事结合自己的实际情况，不必拘泥于各种规则。


在文章的最后，我们做了最后的总结： 中台不是必须的，也不是万能的——支持业务发展是永恒的王道。


特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。