本文适用于参与 BPMS 计划的业务领导、架构师和分析师。我接触过的一些组织信奉 BPM 原则，他们选择了使用一种">业务流程管理系统 (BPMS) 平台，结果发现部署第一个流程自动化解决方案很容易，但将 BPM 扩展到整个组织来实现他们最初计划的流程统一化和标准化水平却很难。
我将会解释，如果在开发一个合理的业务流程架构之前就投资执行流程自动化，通常会出现这种情况。谈到 “业务流程”，我指的是对一个活动序列的逻辑描述，组织执行这些活动来生成有价值的结果，无论它们的自动化水平如何。通过定义易于管理的、可在更大的价值链中重用和合成的流程，合理的架构可以最大程度地实现业务操作所实现的价值。在本文中，我将展示如何实现此架构，设计具有定义明确的职责、清晰的所有权和彼此松散耦合的流程。
developerWorks 上发表的一些文章已讨论了如何基于技术维度来分类和分解流程。但是，我的目的是向业务领域应用架构思维。在考虑技术之前，您如何确定一个流程何时开始和结束？它的核心职责是什么，它与组织的其他流程有何关系？
将高级流程步骤分解为不同粒度级别的子流程的基本技术，本身无法用于开发成熟的架构。在我的经验中，这仅适用于一些受限的场景，其中的业务可简单地描述为一个线性的活动序列，而且每个功能区域都与组织的其余区域隔离。本文从更加整体性的视角来审视一个流程架构的设计和它的组件定义。
定义上下文和范围
企业级业务建模规划的复杂程度可能让人望而却步。试图好高骛远的风险始终很高，定义一个明确的范围可能是成败的关键。为此，您需要有一个在整个组织内共享的参考依据。这个参考依据都可以由一个 能力模型 提供：组织职能的一种高级图表，其中每个组件表示一个逻辑功能，这些功能具有内在的高凝聚力，但彼此松散耦合。IBM 为每个行业开发了一组能力图表，称为组件业务模型 (Component Business Model, CBM)。这些图表使用行对可靠性水平进行了分类（从战略到控制和执行），而列是围绕企业价值链的不同区域来设计的。
因为能力模型的元素具有内在的高凝聚力，并且彼此松散耦合，所以它们的界线为制定一个没有太多外部依赖性的流程建模工作的范围提供了有效的准则。您不应低估在整个组织上下文中通过突出显示要解决的组件来一致地沟通工作范围的价值，如图 1 所示。
图 1. 零售银行的组件业务模型
（查看图 1 的大图。）
业务流程分解
定义一个清晰的范围之后，如何得出一个条理清楚的架构？上面已经提到过，在这点上，大多数传统的流程分解技术都无法胜任。将粗粒度的活动分解为子流程时，您仅分析了组织的行为。遗漏了至少两个重要的维度：结构和信息。然后，整体方法应该利用 3 种补充性技术：流程分析、结构分析和信息分析。
流程和结构分析
您可以将流程想作是一个组织对企业内外的某个人的产品或服务需求的响应行为。流程分析专注于组织的工作原理，将每个高级流程分解为不同级别的更细粒度的活动。
例如，我们想象一家租车公司的情形。图 2 给出了组织支持客户租车需求的行为的分解图。
图 2. 租车行为分解
另一方面，结构分析考虑的是组织的组成部分，将每个高级功能分解为更小、更具体的区域。因为会分析和描述每个功能区域的责任，所以这些区域被放置在它们与其他功能区域的关系的更大上下文中。