我有一个非常大的高水平流程。我现在想了解细节，但不确定方法。我已将高级流程的步骤标记为 1.1、1.2、1.3…
虽然我已经标记为高级别，但我不确定说它是高级别是否准确，因为其中一个步骤是“通知客户”。尽管如此，这仍然是一个端到端的过程。
对于下一个级别，我计划扩展这些步骤，并将其视为具有以下步骤编号的单独流程，例如1.1.1、1.1.2、1.1.3.
我没有将详细的流程视为子流程，因为它们是自身内部相当大的流程。我的理解是子流程仅用于较低级别的细节？
我认为这是比将它们分组更好的方法，例如第 1 组将重点关注 1.1 - 1.11 的步骤。
请告知最佳方法。
非常感谢。
自罗马帝国以来处理复杂性的方法是Divide et Impera，这意味着将其切成更小的部分，直到达到您可以掌握的水平。
在 BP 建模中，如果您的端到端流程太大而无法处理，则可能意味着您的建模过于详细。这里的策略是深吸一口气，缩小范围，找到真正重要的大块，不要被实现细节分散注意力，让细节提升到另一个层次。
这样做，你可能会发现有些子流程不一定按顺序执行。过早呈现太多细节可能会掩盖这一事实，并给人留下一个庞大的整体流程的印象，而实际上它是一组相互关联的动态且灵活的流程。这就是为什么流程和流程组之间的界限可能有些模糊，并且通常更多的是一种约定而不是客观现实。
我以订单兑现为例。看到一个大型的端到端流程可能很诱人，从接收订单开始，在数据库中搜索客户或创建客户，挑选商品，交付商品，为商品开具发票，监控收款，以及如果延迟发送催款信。在这个层面上，它已经相当复杂了（我什至没有提到信用控制、需要预融资的变体以及仓库或运输的物流组织）。如果您
太早了解细节，例如“打印通知”、“发送通知”等...您将拥有一个混乱的模型，除了您之外的每个人都会迷失在细节中。也许该通知属于更深一层，例如到“交付物品”。现在，从端到端的角度来看，“提货”是订单到现金的一个子流程。但从组织的角度来看，它本身就是一个在仓库执行的流程。拣货可能与订单有关，也可能与将过时的物品送去销毁有关。它们同时对许多订单执行，等等。也许某些库存丢失，并且拣货被搁置，直到稍后才恢复。因此，这也是在仓库中单独执行的一个过程。为了良好的建模，您需要采用一种观点。角色可以提供帮助（例如，对于首席执行官来说，端到端的问题和从客户到银行的手段，但对于仓库经理来说，只有一组相关的较小流程很重要；更糟糕的是：端到端可以有不同的理解，例如对于进入仓库直至退出的产品）。
但是，避免分组（按组或按顺序）、子流程-步骤-任务-操作不属于同一抽象级别。只是一个极端的例子：分组开具发票（顶层）和发送电子邮件（底层）没有任何价值，您甚至可以进一步了解影响力或互联网订阅）。换句话说，你可以将 1.1, 1.2, 1.3 分组，但不能将 1.1, 1.1.1, 1.1.1.2, ..... 如果是这样，那么分解过程中可能又出现了问题。