后台案例实操：如何通过状态机图梳理业务流程

一、UML之状态机图

后台产品经理在梳理业务过程中，比较常用的方式之一为UML（统一建模语言，以图片的形式展示），其中以行为型的图——活动图、状态机图、顺序图用的比较多。

活动图是对时间的活动过程、作业顺序的一种表达方式，也比较符合我们对于事情按照时间或者流程顺序思考的思维模式，活动图中经常也会掺杂一些分支机构。

而本文要讲解的状态机图与活动图最大的区别在于，状态机图通常是一某一事物为主线，描述状态的变化发展，无需通过泳道图划分角色的。

二、状态机图在项目中的运用

后台产品经理可以回忆一下，在产品设计和文档编写的过程中，是否经常需要定义业务变化的关键节点以及状态值，我们称之为枚举值或者数据字典的设定。

简单一些的业务，数据字典值可能也就2-3个，而复杂一些的数据字典值，可能多达10个，甚至更多。

数据字典的设定，需要覆盖全业务流程、业务状态无重叠、有明确起止节点。

想象一下，一个事件，有10来个关键节点，每个节点的切换都有前置和后置条件的说明。如果仅靠文字描述，研发小哥哥小姐姐多半会看的一个头两个大，还会不停的跑来问产品经理，要求讲解业务状态变化的过程。

如果我们通过状态机图表示，则会一目了然，毕竟大脑对图片的处理效率要远高于文字。状态机图的制作过程，也有利于产品经理全盘考虑是否有业务环节的遗漏、梳理业务流程是否合理。

接下来我们用实例来说明，状态机图是如何协助我们梳理业务以及简化PRD文档的。

三、案例实操之项目背景介绍

某车辆管理系统订单的作业流程为：司机靠台装货 → 出发运输 →按时到站 → 上传回单凭证 → 回单审核通过 → 订单完结。

为了提高月台装卸货的效率，系统需要对司机的靠台时间进行调控；为了对司机的运输时效进行监控，需要获取司机的出发时间和到站时间；为了核对货物是否安全达到，需要获取收货方的回单凭证。

以上节点均完成之后，订单算是顺利完结，接下来进入到财务报销的流程。

四、状态机图制作

按照上述的流程描述，我们得知关键节点在于：

• 获取订单信息；
• 靠台；
• 出发；
• 到站；
• 上传回单；
• 审核回单。

而结合业务流程和关键节点，我们可以定义数据字典为：

• 待装货：司机获取到订单信息后，系统识别到司机已经按时靠台；
• 装货中：司机在等待装货；
• 订单在途：装货已经完成，司机出发开始运输；
• 已到站：司机已经到达目的地；
• 回单已上传：货物核验通过，上传回单到系统供财务审核；
• 回单审核通过：回单通过审核，订单完结，财务给司机打款报销。

以上，正向业务流程的订单运输过程，状态已经定义好了。

接下来需要分析，每个节点之前的操作是怎么样的，这些是我们需要在状态机图中标注出来的内容，便于研发人员的理解。

• 待装货：线路基本是固定的，可以通过后台系统按照一定的规则，自动派发订单给司机，并告知时间靠台的时间点和地址。所以系统给司机派送订单的时候，默认就是待装货的初始状态；
• 装货中：司机靠台装货的时候，在移动端操作靠台打卡；或者通过GPS电子围栏识别司机的靠台地点，从【待装货】状态切换到【装货中】的状态；
• 订单在途：同样通过电子围栏或者司机移动端的发车打卡，订单从【装货中】切换到【订单在途】状态，此时对于订单的时效监控开始计时；
• 已到站：通过电子围栏或者司机移动端到站打卡，订单状态从【订单在途】切换到【已到站】状态，订单时效监控结束；
• 回单已上传：司机到站之后，默认已到站状态下是【已到站未上传回单】，司机上传回单之后，【已到站】状态切换为【回单已上传】。此时回单信息会回传到系统，供财务审核打款；
• 回单审核通过：财务审核回单，确认通过后，订单状态切换为【回单审核通过】，订单正式完结，只有此状态下才允许财务对司机的报销项目打款。因为订单完结状态和回单审核通过状态是重叠的，所以无需加入订单已完结的状态。

上文的文字描述就看起来很多，而我们用一张状态机图表达即可，如下图：

（正向业务流程，状态机图）

当然我们还需要考虑一些其他的意外情况，如：

1. 回单没有通过审核

如图，司机重新上传回单，再次进入审核，需要加入数据字典值：回单审核不通过。

2. 意外情况

可能是车坏了或者司机无法正常出车或者中途需要切换订单，财务结算模式会发生变化，需要加入状态值：异常订单。异常结束的订单会在数据中被单独标记出来，订单会根据换车、司机的前后里程，拆单进行结算。

3. 可能会有临时订单产生

例如司机已经靠台装货，订单调度中心才知道有这样的订单产生，毕竟有很多物流订单都是在半夜装货，清晨出发的。

此时调度中心再去创建订单，很多数据就会缺失，不利于财务对账。所以需要靠司机自己创建订单的模式来解决问题，那么此类订单的初始状态就不是待装货，而是【装货中】。

4. 更复杂一点的情况

会在司机出发后，订单调度中心上班后，对订单进行审核，补充司机自己创建订单的部分数据。

5. 还可能会有其他的逆向业务流程

比如司机忘记了靠台、发车、到站打卡；司机自己创建订单的时候选错了线路；比如GPS电子围栏失效导致打卡范围测算不准；比如司机还未出发就需要更换运输车辆或者切换订单给其他司机替跑等等。

以上案例只是对主线业务的梳理，对应的还有其他逆向的状态就不一一说明了，聪明的你应该知道这部分的PRD文档要怎么简化了吧~

本文作者 @RaRa 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！