文章主要阐述在系统开发过程中业务的梳理方式和订单功能的设计流程，不涉及具体设计方法或案例，也不涉及复杂的订单设计方案。希望帮助未接触过订单模块的产品经理对于设计流程有大致的了解。

订单的概念

订单这个概念想必大家都不陌生，但是需要注意的是，不一定是付款购买的才算是订单。企业中大多数的业务流都是以订单的形式来承载的，而这篇文章将会用几个模块来解释一下订单设计流程中的重要组成部分。

文中描述的设计流程和阶段产出物都是按照最详细的步骤来实施，在现实工作过程中如果因为时间限制没办法完全满足的话，也可以在输出文档过程中不时回顾一下。但是在经验不足的情况下，还是建议尽量把前期准备工作做好。

一、设计之前

无论是toC还是toB，在任何功能开始之前，调研和了解都不可或缺。

1. 明确对象

在开始设计订单之前，首先要明确订单的涉及对象。

以设计常见的电商订单为例，涉及的最基础外部对象有消费者、卖家、物流服务商，企业内部有运营、客服、仓库等多个部门，根据各个平台的不同情况还会涉及财务、风控等等。

明确对象的好处和必要性体现在，后续进行设计时可以保证：

1. 减少遗漏订单节点的发生
2. 保证能迅速找到节点的负责人
3. 确保对各个环节的把控

2. 了解业务流程

在你明确了对象之后，就可以开始与业务部门进行沟通，了解他们对于这个业务的定位和需求。

这里的业务部门可以是互联网的运营、市场，也可以是企业内部的相关业务人员。

有人的地方就有江湖，在梳理业务流程的过程中，各个业务部门之间不可避免会有各种冲突和意见。作为对整体流程负责的产品经理，需要把控好业务与系统流程的结合点，不能让业务的需求无限膨胀，但是也不能忽略这些专业人士的需求，否则会发现最终做出来的东西根本没办法用。

3. 阶段产出物——业务对象分析图、业务流程图

在完成了初步的沟通之后，需要一张业务对象分析图、多张业务流程图承载你们的沟通过程和结果。同时这些流程图也可以作为记录，避免后续的扯皮。

（1）业务对象分析图

有利于后续接触项目的成员可以迅速掌握项目情况，也可以帮助你拆分相应的业务流程图，减少遗留的情况出现。对业务对象分析图的要求有：

1. 包含所有业务对象及对应的关键动作；
2. 标记三流——订单流（信息流）、资金流、物流，如果没有资金流物流的话可以忽略不计。

（2）业务流程图

可以帮助你进行后续的系统设计工作，一张合格的业务流程图需要做到以下几点：

1. 业务闭环——业务需要完成闭环，就需要考虑到上游和下游的业务衔接，不要出现突然出现的信息或环节；
2. 把控好颗粒度，不出现过多的判断——业务流程图的主要作用是展现业务，一般不需要出现大量的系统判断，影响阅读性；
3. 确保阅读顺序——常见的是从左至右，从上至下，考虑到阅读性，尽量保持在一个方向滚动，减少又要左右滚又要上下滚的情况。

二、系统设计

在于业务同事完成了沟通，对业务流程有了一致的共识之后，就可以开始进行系统设计了。

首先，我们需要对订单流程进行下一步的细化。

1. 订单流设计

在这个阶段，还不能直接动手画原型写文档，因为业务流程≠系统流程。

所以，为了避免后续画原型时出现遗漏或者冲突而影响文档的交付时间，需要对订单状态进行设计。

展现订单流程的关键元素就是订单状态，为了让真正的使用对象可以迅速明确订单所处的流程，我们需要把操作和状态进行结合。

这个时候就要对订单状态进行规划，原型永远是最后才做的。

（1）确认合理并且必要的状态

1）一个订单可以有多个状态

还是以电商订单为例，因为在实际业务过程中可能会存在多个分支，只用一个订单状态显然不合适。所以设计人员一般会为订单规划多个订单状态，例如一个总的订单状态、发货状态、付款状态、退款状态等等。

2）状态映射表

如果订单状态非常的多，外部用户看起来难免会头晕眼花，这个时候就需要设计一个状态映射表，用符合外部使用者心智模型的设计方式来巧妙地显示状态

（2）考虑触发状态变更的动作

从状态A到状态B，是通过什么动作来触发的，自动还是手动，这些都要提前思考清楚

（3）考虑状态变更触发的动作

订单状态变更时，是否会触发其他环节？

（4）考虑逆向流程

订单是否可以取消？什么时候可以取消？谁能发起取消？取消之后怎么处理？（涉及物流和资金流时尤其需要慎重考虑）

（5）考虑上下游

如果你目前所设计的订单流程中还有上游流程和下游流程，或者涉及多个系统的交互，那么就要考虑清楚与上下游、其他系统的信息交互问题。

2. 阶段产出物——状态机图、系统流程图、状态映射表

（1）状态机图

用于展示订单状态的变化流程，主要便于项目人员快速了解订单在系统中的流向和关键操作

（2）系统流程图

展示业务对象及其在系统中的操作，以及系统中自动执行的判断和处理，主要便于项目人员快速了解订单的详细逻辑

（3）状态映射表（非必要）

展示订单状态在多个端口的映射关系。

小结

可以看到，在现阶段工作的重点在于将业务与系统结合，同时主要输出物也是便于后续开发工作的进行，这些产出物都是需求文档中重要的部分。越是复杂的系统，越需要这些资料进行辅助了解，不能指望后面加入的项目人员能根据你的文字来了解复杂的业务。

本文由 @PM林盐 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议