在前面的过程中，我们在各种细节级别上搜集了流程信息。这些细节级别需要进行分类，并将信息分配给流程模型层次结构中的不同级别。该层次结构将从整个流程的高层次开始，然后分解为较低的细节层次，直到定义流程中的活动。在流程模型的这种分解中，流程分为子流程，然后再分解为功能（function）。功能与执行它们的业务操作相关，并与其他子流程结合在一起组成业务部门中的活动。这些流决定了该部门的工作表现。

建议在收集信息时将其分配给给定的详细级别。随着团队的进一步了解，可以修正此分配逻辑。层次结构中任何级别的信息都应与层次结构中较高级别的信息清晰地对齐，因此当层次结构中的级别越低时，表示的细节越多。这将使团队能够识别丢失的信息或需要查询的信息。

1、分几级

下图是流程层次结构的示例。您可以使用更少或更多的级别，并且可以对它们进行不同的标记。重要的是，如果希望控制信息及其质量，团队将需要一种统一的方法来组织收集的信息和构建的模型。

注意：级别的数目及其名称，因不同公司中使用的方法和命名约定而异。重要的是，该过程必须细分到足够低的层次，以了解正在发生的活动以及它们如何组合在一起以生产最终产品。因此，上图中的级别是公司如何看待流程建模标准中定义的详细级别的样本。

2、各层级含义

当前的“ASIS”和未来的“TOBE”模型中流程级别的编号、名称应遵循企业的业务建模标准。过去，这些标准可以独立于任何外部建模标准或工具，但是这种情况正在发生变化。现在必须注意使内部建模标准与所使用的工具及其功能和局限性保持一致。例如，虽然BPMN2.0不是唯一的建模标准，但是它正成为BPMS供应商的主要标准，因此，企业内部建模标准可能就需要符合BPMN。

但是，查看建模标准的一个好的经验法则是，它们至少以某种形式满足以下要求：

1.最高级别的模型是一种流程模型，可提供过程的完整的端到端高级视图。该模型可以显示子流程，以及可能显示高层级问题和应用程序系统。

2.子流程模型是下一个级别，它将工作划分为业务功能，然后按业务部门调整业务功能。

3.业务部门内的工作流是第三级，它标识了所执行的活动。此级别模型还可以用于显示活动、其他职能的活动、本业务单元执行的其他子流程之间的关系。

4.在第四个详细信息级别（场景）下，将很容易理解事件、时间或数据如何驱动业务部门执行工作。通过将任务向上汇总为活动，继而汇总为工作流，继而子流程，可以很容易地理解所有工作如何满足流程，以及它在流程的最终产品生产中发挥的作用。

但是，这第四级详细信息仅提供了对业务操作中的详细信息的基本理解，用来解决问题、降低成本或支持自动化通常还不够详细。对于这些操作，有必要将工作流程带到更高的详细程度，即任务级别。

在此级别（第五级），业务和BPMS设计人员通常具有足够的细节以将规则绑定到特定操作。但是数据的详细程度还不足以设计应用程序屏幕和报告、定义编辑和低级决策。该级别用于生成BPMS应用程序，该应用程序管理工作并自动执行手动“事务”级别的数据输入和使用。

在这个级别上，分析人员可以确定为交付单个活动的输出或结果而执行的任务。例如，当保险公司的保单持有人进入系统时，此级别的模型将定义输入新保单持有人必须执行的任务。在制造方面的示例是在客户向销售人员下订单后按订单生产。过程分析人员必须定义识别“定制的”产品所需的所有任务，并识别零件、定义选项、削减构建顺序、获取零件、然后进行构建（假设使用通用零件进行构建）。

3、可不可以再分

当然，我们仍然可能需要更低的详细程度。不过就像地图一样，关键是支持您正在做的事情，以及可能下一阶段将要做的事情。有可能是传统的应用程序、BPMS应用程序、构建与旧版应用程序的接口、构建与客户进行交互的Web应用程序等等。关键是必须考虑这些后续活动中的任何一项的要求，然后在模型中达到足以推动完成这些活动的细节。

感谢你读到最后，希望你能从中获得一些启发和收获。