业务订单的设计流程详解

人人都是产品经理 05-02 2455

前言：

眼前朋友们对“映射模块”都比较关心，看官们都想要了解一些“映射模块”的相关内容。那么小编也在网上收集了一些有关“映射模块””的相关文章，希望姐妹们能喜欢，看官们一起来了解一下吧！

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

订单的概念

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

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

一、设计之前

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

1. 明确对象

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

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

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

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

2. 了解业务流程

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

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

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

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

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

（1）业务对象分析图

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

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

（2）业务流程图

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

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

二、系统设计

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

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

1. 订单流设计

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

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

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

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

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

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

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

2）状态映射表