一、业务中台化抽象对于中台系统建设,如果只是简单地按照业务进行划分,会导致中台建设过度“粗糙”。所以要对各业务线的功能进行拆解,拆解出一个个的能力。那么,如何进行高效又无遗漏的模块拆解呢?本文作者分享了动作分析法,一起来看一下吧。
完成了对产品定位与用户这两个产品外部因素的分析后,接下来的重头戏就是我们需要深入各业务线的内部去研究各个组成部分,也就是对每个产品的功能模块进行挨个拆解,从而得到我们公司的颗粒度最小的基础单元,为下一步中台业务数据模型提取做好准备。
之所以这样做,就是因为在现在的公司中一个产品的各个模块实际上是由不同的团队进行研发并最终合并成一个App的。举例来说,在电商内部,为了实现用户去搜索商品这一个功能,背后至少需要有商品中心、搜索中心、订单中心、库存4个团队交织参与才能完成。
所以在这种情况下,如果粗糙地按照业务进行划分会导致中台建设过度“粗糙”,此外难免会有一些团队在信息不对称的情况下进行了功能的重复性建设。例如,我们梳理一家电商平台的需求,如果按照业务划分,那么自营电商的订单模块与第三方电商的订单模块会被划分为两个模块,但是本质上这些在中台中完全可以合并为一个订单模块。
而我们去进行整个产品的全部功能拆解,就是为了找到各个模块的共同之处,从而将这些共性部分提炼出来,这样就能保证我们站在整个公司的视角去思考整体的解决方案。只有这样,我们才能避免在思考中台需求时漫无边际地将各个应用中的任意需求都加入中台规划。
所以说来,在中台建设里广泛存在这两个问题:
- 添加的需求为了能适配不同的前端业务线,所以不能是具体的功能而应是能力;
- 我们要将哪些功能添加到中台的需求池中,避免将中台建设为另一个“小后台”。
这里问题的解决方法就是对各业务线的功能进行拆解,拆解出一个个的能力。例如,对一个商品模块,我们可以拆解出商品品类管理能力、价格管理能力、商品标签管理能力这3个能力。
那么又要如何进行高效又无遗漏的模块拆解呢?这里我推荐大家使用动作分析法来进行拆解工作。
所谓动作分析法,就是将任意模块拆分为某个人为了完成某个事件而需要在应用中做哪些动作。进一步说,这个方法在本质上就是将任意一个业务需求拆分为3个步骤,如图9-4所示。
图1 动作分析法示意
每层级拆分原理解释如下。
例如,我们对登录模块进行分析:
第一步,将这个模块拆分为两个角色,分别是登录用户与业务系统;
第二步,继续拆分可得到两个事件——用户账户信息输入,账户与密码正确性校验;
第三步,再将如上事件拆分为账户信息输入、校验事件触发、账户信息异常判断、校验结果返回、下一事件联动(如进入首页)。
综上,我们便将一个登录模块拆分为两个角色、两个事件、五个动作,得到如图2所示的完整流程。
在成功将模块拆分为以用户为角色的动作之后,下一步通过将各个节点中不同角色的输入输出进行统一,我们就能很快找到整个系统中我们所需要提供的最密集的能力是什么。
还是用App中的登录模块举例,可以发现如下的现状:在登录注册中,我们需要向用户提供身份认证与用户首页配置查询功能(根据用户权限而显示首页模块,如给员工显示基本界面,给管理员显示带有统一看板的界面);而当用户点开某模块时我们又需要向用户提供身份认证并按角色配置查询功能,查询用户是否为VIP用户等。