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