流程设计建模方法：流程的需求梳理之流程级别梳理

一般而言，对于一个业务系统的开发过程，可以划分成：需求、设计、开发、测试、集成、部署等阶段。在需求阶段形成《需求规格说明书》之后，设计阶段需要对需求进行设计建模。业务流程需求是业务人员从业务化视角对企业业务活动的现状和规划方案的一种全面概况描述，其隐藏了技术细节。流程设计建模主要是对流程需求进行梳理，要使用可操作的技术来描述业务流程场景。

业务需求建模是否合理，直接影响到流程的技术实现，在流程设计过程中首先需要对业务需求从技术实现的角度重新进行梳理。下图是业务流程需求梳理过程的示意图：

在业务流程需求梳理的过程中，流程的需求梳理主要包括：流程级别梳理、活动级别梳理、活动属性梳理、活动间规则梳理等环节。梳理的过程按照“从大处着手，需求逐步细化”的原则。

业务流程需求梳理是一个循环的过程，在流程设计阶段需要反复与需求分析人员、业务人员沟通和确认。只有经过反复沟通和确认，流程设计建模才更加贴近业务需求。

下面介绍流程需求梳理之“流程级别梳理”
流程级别需求梳理是对整个业务系统的业务域进行梳理的过程。一般需要如下沟通和确定以下内容。

1、是否需要子流程

是否需要子流程：在业务流程定义中，一组相关的活动组，可以设计成一个子流程；引入子流程的概念用于表示按照递归方式对流程在级别上做更深入的优化，直至到达合适的组成部分。是否使用子流程主要从下面几个指标衡量：

企业管理的模式是否需要精细：如财务部门多级审批环节，可以是一个审批环节，也可以是在财务部门经过一组相关活动组成的活动组审批。当然，业务流程管理优化有很多工作要做，但是不是本文重点，这里就不深入讨论。
使用子流程是否可以使流程图表达简洁清晰：在某些业务流程中环节较多，如果所有的活动放在同一个层次，会使得流程图拓扑结构复杂而不容易识别。对业务功能相近或者相关的活动组适当的使用子流程，可以使整个业务流程表达清晰简单。这种情况下推荐使用子流程。
一组活动被多处重用：在整个业务系统中，如果某些相近或者相关的活动组在多个流程中可以重用，推荐使用子流程。
是否有子流程嵌套：在业务系统中如果有子流程递归调用的情况，建议使用子流程。

【应用场景：活动组复用举例】：在下图所示中的应用场景中，客服部门会受理不同产品的申办请求，不同的产品在IT支撑部门处理过程都是一样的：首先由“IT支撑部审核”，如果是非标准业务转由“IT支撑部经理审核”，最后由IT支撑人员做相应的操作。其他部门则根据产品的不同走不同的审批流程。

使用子流程的设计方案是可以将“IT支撑部处理”相关的3个人工活动设计成下图所示的子流程。

原始的需求就可以设计成下图的方案。这样“IT支撑部处理”子流程就可以在多个流程中使用，将来IT支撑部处理过程发生变化时，仅仅修改子流程即可。

2、业务流程的个数

业务流程的个数：本环节需要确认在待建的业务系统中有多少个业务流程，每个业务流程是否可以描述一个完整的业务过程。
- 检查每个流程是否完成相对独立的业务功能，如果不完整则需要将相关流程合并；
- 检查使用的子流程是否必须。

【说明】：在相同的业务场景下，业务流程的个数不是固定的，具体的流程个数需要根据业务人员工作习惯来设计。