图2 登录业务流程

那么通过这几点的分析，我们就可以将系统中用户身份认证与用户配置这两个使用频率比较高的部分进行统一抽象，使其成为中台的一个能力模块。

此外在第8章我们也提到了中台建设中会遇到这样的现象，就是公司内部若干条业务线对于同一个功能有完全不同的使用场景存在，这个时候我们的中台模块提取是以哪个场景作为核心对象的？

此时在本章最开头我们分析出的业务线在整个公司商业模式中的地位就派上用场了，那些能为公司变现的业务模块应该是中台优先归纳和剥离的，随后其他不同的业务线都应该向此类模块集中。至此针对某一个具体场景的抽象方法我们就介绍完了，接下来我们需要做的就是针对全公司的业务进行逐个分析。

为了更好地理解产品画像与流程抽象，在这儿我们以一款真实的地图类应用为例。

产品背景：

• 产品终端：App。
• 一级功能：地点查询、路线导航、公共交通乘坐指南、地理位置周边发现、在线打车。
• 用户数据：选取9天内无任何投放活动的自然流量下的用户数据，如图9-6所示。

图3 自然流量下的用户数据

步骤1：产品画像分析

画像一分析：产品线中各功能的地位分析，如表9-4所示。

步骤2：节点拆分

在这儿我们以在线打车功能进行流程通用性抽象，按照动作拆分理论，我们可以拆分出如图9-7所示的结果。

图4 打车需求拆分示例

步骤3：节点信息流分析

让我们对在线打车里的各事件节点信息流进行一下梳理：

• 登录系统（2个主要信息项）：个人密码校验、个人账户信息（昵称、ID、联系方式、头像）。
• 选择终点（2个主要信息项）：终点地理信息、路线信息查询。
• 选择车型（1个主要信息项）：车型偏好信息（在应用中选择了打车模块）。
• 呼叫车辆（3个主要信息项）：乘客信息（账户信息）、司机信息、司机地理信息。
• 到点付费（4个主要信息项）：路程地理信息、账单信息、个人账户评价信息、司机评价信息。

此时如果我们将上面的12个信息项进行归类，并统计下各节点的信息项重叠次数，可以得到如表9-5所示的结果，也就是我们前台业务所需要的能力。