实战思考（一）：如何搭建业务中台？

01 背景

这2年来产品被议论最多的应该就属“中台”了，火到连面试官都要问一下面试者“有没有中台的产品设计经验？”。

国内的中台最早提出者是阿里，阿里在2015提出了“大中台、小前台”战略部署。作者经过一段时间的学习与实践，梳理后输出此文，跟大家一起讨论下中台的存在意义以及战略规划。

随着企业的快速发展，很多企业都开始步入多元化领域，以事业部的形式向其他领域进发，而为了快速满足前台需求变化，大多企业内都具备了多套操作系统，一个稍微大规模的甚至去到十几二十套系统。

以作者的企业为例：ERP、CRM、直播、资讯等业务系统，还有HR、财务等支持系统。即便如此，各条业务线还是觉得不能满足，希望自己的操作系统能够更加的强大。

由于这些系统是分部实施，并且还是不同供应商提供的，造成这些系统有一个显著特点——那就是每一个都是自成一体的封闭的系统。

前期不会有太大的影响，每个部门各玩各的就完事了，但是随着后续系统的不断成熟，很多的问题开始浮出水面。

这里举一个例子，企业中下达了一个“敏感词管理“需求，需求目的在于对用户终端进行敏感词的显示管理，需求下发后由各事业部的业务部门分别执行，如果当前有3个事业部门，那么该功能单元则需要被搭建3次，这无疑加大了企业的人力成本。

那么诸如此类问题，是否可以将其中一些基础的东西，比如说：商品信息、授信信息、敏感词信息等等，集中起来，同时对外提供服务或整套的企业解决方案呢？

——这就是SaaS和微服务的概念。

中台战略，就是基于这样的一个规划应运而生的一种信息化架构。

所以说，为什么要规划中台战略？

02 中台建设

行业内的中台，往往分为组织中台、业务中台、数据中台、技术中台这四个主题切入并探讨建设目的与建设方案。此文主讲“业务中台”，其他类型的，如果之后有时间，作者会在后续的文中进行补充（主要是作者不懂…）

这里摘抄前VIPKID 的产品总监杨堃的一段话：

业务中台：业务中台研究的是企业内部的软件系统如何进行抽象和设计，从而让企业的软件系统就像搭建积木一样灵活，可以重复高效利用现成的软件组件，快速组装开发出新的软件系统，从而节约软件开发成本，并能够快速支持新业务开展。很多文章也把这类中台产品称作业务中台，或业务中台产品。

目前被广泛讨论的产品中台包括电商交易中台、账号中心中台等，其中电商交易线又被更加广泛的探讨，包括了订单中台、支付中台、商品中台、促销中台等。

产品中台还有另一层含义，即能够给全公司全企业提供一致服务的管理软件产品，也可以纳入产品中台的范畴，例如呼叫中心、项目管理软件。从某种程度上来讲，这些标准化软件产品也是中台产品。

我们经常听到，中台的建设目的主要是为前台服务的，对于业务中台，目前公认的关键要点包括如下关键词：企业级、抽象、下沉、复用，这些关键词代表了业务中台建设的特点，同时也是在企业应用架构设计中需要深层次思考的问题。（这里为什么企业级放在第一位，中台的建设一定要依托企业中的核心部门来进行推动，不然又会出现闭门造车的现象，所以也就可以明白，为什么阿里中台的战略的第一步，就是组建了一个“共享事业部”。）

03 实战案例：帮助中心

统一客户视图建设

作者企业中，目前有多条业务线，如旅游业务线，便民业务线，学习平台业务线等，业务团队包括市场推广团队，运营团队，以及客服团队。每条业务线都有各自的运营系统支持其运转，每个业务线系统既有个性化功能，如：课件信息、运营中心、讲师信息。也有高度重合类似的功能，如：订单列表、帮助中心，图片如下所示。

每条业务线都有一个帮助中心，虽然不同的业务线面向的用户群体不同，但目的是统一的，都是提供常见的问题解答方案供用户学习参考。

为了解决重复开发的问题，也为了能给业务人员提供统一的操作视图，作者将“帮助中心”模块从三个业务中抽象出来，建设统一 的“客服服务中心”模块，该模块提供统一的数据信息接口，供三个业务线分别调用，形成中间件标准，实现高度复用。

此时，“客服服务中心”将作为中台产品，为各个业务系统提供帮助信息数据查询的服务以及视图。图片如下所示。

而前台为了实现视图标准化，也进行了统一搭建，形成“客服中心服务”组件，通过对此页面进行灵活的权限配置，实现不同业务、不同角色进入时的数据查看、编辑。

图片如下所示：

类似的还有很多，这里就不再一一列举了。

总结

（1）中台的搭建需要根据企业战略而定，并且需要企业进行主导和推动，稍微大点的企业，业务线数不胜数，每个业务线都有对应产品经理人与业务团队，先别说对其他部门的业务线功能逻辑了解多少，可能连对方产品经理是谁都不知道，在此环境下，单一推动与搭建中台会显得极为困难。

（2）中台搭建的必要性有多高，如果说企业内为单一业务线，如在线教育、违章办理等，所有的业务团队都是围绕当前业务线开展工作，那么这种情况下不建议在前期进行中台的规划与建设，原因是未来的不确定因素太多，或掌握的信息不足，很可能做出错误的判断和设计，做出了错误的抽象决策，最后被抽象的系统模块，并不能被充分复用，只是制造了一个畸形的别扭的模块，生硬的把一堆毫无关联的功能强行捏在一起，给研发工作反而带来的更大的麻烦。

希望本篇文章能对你的工作上提供到帮助，如果对文中有不解或者建议之处，还请在评论区指出。

最后，感谢大家的阅读。

本文作者 @鱼店不卖鱼 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！