编辑导读：本篇文章以第三人称描述产品实际工作中，“业务中台”部分从0-1的搭建，介绍了作者对中台的一些理解心得。如果你对中台感兴趣，或者工作中也需要涉及到中台的搭建，那么本篇文章应该对你有帮助。
01 背景
这2年来产品被议论最多的应该就属“中台”了，火到连面试官都要问一下面试者“有没有中台的产品设计经验”。
国内的中台最早提出者是阿里，阿里在2015提出了“大中台、小前台”战略部署。作者经过一段时间的学习与实践，梳理后输出此文，跟大家一起讨论下中台的存在意义以及战略规划。
随着企业的快速发展，很多企业都开始步入多元化领域，以事业部的形式向其他领域进发，而为了快递满足前台需求变化，大多企业内都具备了多套操作系统，一个稍微大规模的甚至去到十几二十套系统。
以作者的企业为例：ERP、CRM、直播、资讯等业务系统，还有HR、财务等支持系统。即便如此，各条业务线还是觉得不能满足，希望自己的操作系统能够更加的强大。
由于这些系统是分部实施，并且还是不同供应商提供的，造成这些系统有一个显著特点——那就是每一个都是自成一体的封闭的系统。
前期不会有太大的影响，每个部门各玩各的就完事了，但是随着后续系统的不断成熟，很多的问题开始浮出水面。
这里举一个例子，企业中下达了一个“敏感词管理“需求，需求目的在于对用户终端进行敏感词的显示管理，需求下发后由各事业部的业务部门分别执行，如果当前有3个事业部门，那么该功能单元被需要被搭建3次，这无疑加大了企业的人力成本。
那么诸如此类问题，是否可以将其中一些基础的东西，比如说：商品信息、授信信息、敏感词信息等等，集中起来，同时对外提供服务或整套的企业解决方案呢？
——这就是SaaS和微服务的概念。
中台战略，就是基于这样的一个规划应运而生的一种信息化架构。
所以说，为什么要规划中台战略？
02 中台建设
行业内的中台，往往分为组织中台、业务中台、数据中台、技术中台这四个主题切入并探讨建设目的与建设方案。此文主讲“业务中台”，其他类型的，如果之后有时间，作者会在后续的文中进行补充（主要是作者不懂…）
这里摘抄VIPKID 的产品总监杨堃的一段话：
业务中台：业务中台研究的是企业内部的软件系统如何进行抽象和设计，从而让企业的软件系统就像搭建积木一样灵活，可以重复高效利用现成的软件组件，快速组装开发出新的软件系统，从而节约软件开发成本，并能够快速支持新业务开展。很多文章也把这类中台产品称作业务中台，或业务中台产品。
目前被广泛讨论的产品中台包括电商交易中台、账号中心中台等，其中电商交易线又被更加广泛的探讨，包括了订单中台、支付中台、商品中台、促销中台等。
产品中台还有另一层含义，即能够给全公司全企业提供一致服务的管理软件产品，也可以纳入产品中台的范畴，例如呼叫中心、项目管理软件。从某种程度上来讲，这些标准化软件产品也是中台产品。
我们经常听到，中台的建设目的主要是为前台服务的，对于业务中台，目前公认的关键要点包括如下关键词：企业级、抽象、下沉、复用，这些关键词代表了业务中台建设的特点，同时也是在企业应用架构设计中需要深层次思考的问题。（这里为什么企业级放在第一位，中台的建设一定要依托企业中的核心部门来进行推动，不然又会出现闭门造车的现象，所以也就可以明白，为什么阿里中台的战略的第一步，就是组建了一个“共享事业部”。）
03 实战案例：帮助中心
统一客户视图建设
作者企业中，目前有多条业务线，如旅游业务线，便民业务线，学习平台业务线等，业务团队包括市场推广团队，运营团队，以及客服团队。每条业务线都有各自的运营系统支持其运转，每个业务线系统既有个性化功能，如：课件信息、运营中心、讲师信息。也有高度重合类似的功能，如：订单列表、帮助中心，图片如下所示。
每条业务线都有一个帮助中心，虽然不同的业务线面向的用户群体不同，但目的是统一的，都是提供常见的问题解答方案供用户学习参考。
为了解决重复开发的问题，也为了能给业务人员提供统一的操作视图，作者将“帮助中心”模块从三个业务中抽象出来，建设统一 的“客服服务中心”模块，该模块提供统一的数据信息接口，供三个业务线分别调用，形成中间件标准，实现高度复用。
此时，“客服服务中心”将作为中台产品，为各个业务系统提供帮助信息数据查询的服务以及视图。图片如下所示。
而前台为了实现视图标准化，也进行了统一搭建，形成“客服中心服务”组件，通过对此页面进行灵活的权限配置，实现不同业务、不同角色进入时的数据查看、编辑。
图片如下所示：
类似的还有很多，这里就不再一一列举了。
总结
（1）中台的搭建需要根据企业战略而定，并且需要企业进行主导和推动，稍微大点的企业，业务线数不胜数，每个业务线都有对应产品经理人与业务团队，先别说对其他部门的业务线功能逻辑了解多少，可能连对方产品经理是谁都不知道，再次环境下，单一推动与搭建中台会显得极为困难。
（2）中台搭建的必要性有多高，如果说企业内为单一业务线，如在线教育、违章办理等，所有的业务团队都是围绕当前业务线开展工作，那么这种情况下不建议在前期进行中台的规划与建设，原因是未来的不确定因素太多，或掌握的信息不足，很可能做出错误的判断和设计，做出了错误的抽象决策，最后被抽象的系统模块，并不能被充分复用，只是制造了一个畸形的别扭的模块，生硬的把一堆毫无关联的功能强行捏在一起，给研发工作反而带来的更大的麻烦。
希望本篇文章能对你的工作上提供到帮助，如果对文中有不解或者建议之处，还请在评论区指出。
最后，感谢大家的阅读。
本文由 @鱼店不卖鱼 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。