对于中台系统建设，如果只是简单地按照业务进行划分，会导致中台建设过度“粗糙”。所以要对各业务线的功能进行拆解，拆解出一个个的能力。那么，如何进行高效又无遗漏的模块拆解呢？本文作者分享了动作分析法，一起来看一下吧。
一、业务中台化抽象
完成了对产品定位与用户这两个产品外部因素的分析后，接下来的重头戏就是我们需要深入各业务线的内部去研究各个组成部分，也就是对每个产品的功能模块进行挨个拆解，从而得到我们公司的颗粒度最小的基础单元，为下一步中台业务数据模型提取做好准备。
之所以这样做，就是因为在现在的公司中一个产品的各个模块实际上是由不同的团队进行研发并最终合并成一个App的。举例来说，在电商内部，为了实现用户去搜索商品这一个功能，背后至少需要有商品中心、搜索中心、订单中心、库存4个团队交织参与才能完成。
所以在这种情况下，如果粗糙地按照业务进行划分会导致中台建设过度“粗糙”，此外难免会有一些团队在信息不对称的情况下进行了功能的重复性建设。例如，我们梳理一家电商平台的需求，如果按照业务划分，那么自营电商的订单模块与第三方电商的订单模块会被划分为两个模块，但是本质上这些在中台中完全可以合并为一个订单模块。
而我们去进行整个产品的全部功能拆解，就是为了找到各个模块的共同之处，从而将这些共性部分提炼出来，这样就能保证我们站在整个公司的视角去思考整体的解决方案。只有这样，我们才能避免在思考中台需求时漫无边际地将各个应用中的任意需求都加入中台规划。
所以说来，在中台建设里广泛存在这两个问题：
添加的需求为了能适配不同的前端业务线，所以不能是具体的功能而应是能力；
我们要将哪些功能添加到中台的需求池中，避免将中台建设为另一个“小后台”。
这里问题的解决方法就是对各业务线的功能进行拆解，拆解出一个个的能力。例如，对一个商品模块，我们可以拆解出商品品类管理能力、价格管理能力、商品标签管理能力这3个能力。
那么又要如何进行高效又无遗漏的模块拆解呢？这里我推荐大家使用动作分析法来进行拆解工作。
所谓动作分析法，就是将任意模块拆分为某个人为了完成某个事件而需要在应用中做哪些动作。进一步说，这个方法在本质上就是将任意一个业务需求拆分为3个步骤，如图9-4所示。
图1 动作分析法示意
每层级拆分原理解释如下。
例如，我们对登录模块进行分析：
第一步，将这个模块拆分为两个角色，分别是登录用户与业务系统；
第二步，继续拆分可得到两个事件——用户账户信息输入，账户与密码正确性校验；
第三步，再将如上事件拆分为账户信息输入、校验事件触发、账户信息异常判断、校验结果返回、下一事件联动（如进入首页）。
综上，我们便将一个登录模块拆分为两个角色、两个事件、五个动作，得到如图2所示的完整流程。
在成功将模块拆分为以用户为角色的动作之后，下一步通过将各个节点中不同角色的输入输出进行统一，我们就能很快找到整个系统中我们所需要提供的最密集的能力是什么。
还是用App中的登录模块举例，可以发现如下的现状：在登录注册中，我们需要向用户提供身份认证与用户首页配置查询功能（根据用户权限而显示首页模块，如给员工显示基本界面，给管理员显示带有统一看板的界面）；而当用户点开某模块时我们又需要向用户提供身份认证并按角色配置查询功能，查询用户是否为VIP用户等。
图2 登录业务流程
那么通过这几点的分析，我们就可以将系统中用户身份认证与用户配置这两个使用频率比较高的部分进行统一抽象，使其成为中台的一个能力模块。
此外在第8章我们也提到了中台建设中会遇到这样的现象，就是公司内部若干条业务线对于同一个功能有完全不同的使用场景存在，这个时候我们的中台模块提取是以哪个场景作为核心对象的？
此时在本章最开头我们分析出的业务线在整个公司商业模式中的地位就派上用场了，那些能为公司变现的业务模块应该是中台优先归纳和剥离的，随后其他不同的业务线都应该向此类模块集中。至此针对某一个具体场景的抽象方法我们就介绍完了，接下来我们需要做的就是针对全公司的业务进行逐个分析。
二、案例：地图应用抽象
为了更好地理解产品画像与流程抽象，在这儿我们以一款真实的地图类应用为例。
产品背景：
产品终端：App。
一级功能：地点查询、路线导航、公共交通乘坐指南、地理位置周边发现、在线打车。
用户数据：选取9天内无任何投放活动的自然流量下的用户数据，如图9-6所示。
图3 自然流量下的用户数据
步骤1：产品画像分析
画像一分析：产品线中各功能的地位分析，如表9-4所示。
步骤2：节点拆分
在这儿我们以在线打车功能进行流程通用性抽象，按照动作拆分理论，我们可以拆分出如图9-7所示的结果。
图4 打车需求拆分示例
步骤3：节点信息流分析
让我们对在线打车里的各事件节点信息流进行一下梳理：
登录系统（2个主要信息项）：个人密码校验、个人账户信息（昵称、ID、联系方式、头像）。
选择终点（2个主要信息项）：终点地理信息、路线信息查询。
选择车型（1个主要信息项）：车型偏好信息（在应用中选择了打车模块）。
呼叫车辆（3个主要信息项）：乘客信息（账户信息）、司机信息、司机地理信息。
到点付费（4个主要信息项）：路程地理信息、账单信息、个人账户评价信息、司机评价信息。
此时如果我们将上面的12个信息项进行归类，并统计下各节点的信息项重叠次数，可以得到如表9-5所示的结果，也就是我们前台业务所需要的能力。
所以根据这份表格的结果，我们可以先将用户中心、位置管理中心这两个相对高频的模块进行剥离，使其成为公共模块。但是这里得到的结果还不能立即作为中台建设需求，还需要进行处理，具体我们将在下一章来看要如何建设。
专栏作家
三爷，微信公众号：三爷茶馆，人人都是产品经理专栏作家，2019年年度作者。《中台产品经理宝典》作者，原万达高级产品、MBA特约讲师、独立创业者，现叮咚买菜B端产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
