如何通过执行流程分解来提高重用率和降低复杂性

本文提供一种多维方法来开发有机的业务流程架构。文中涉及建模计划的范围划定，以及业务分解和流程定义技术。本文不仅介绍了分层流程分解的基本概念，还展示了如何通过在一组关键业务维度（包括所有权、价值和信息）上分析流程，改善流程标准化，降低业务操作的复杂度水平。本文适用于参与 BPMS 计划的业务领导、架构师和分析师。

简介

我接触过的一些组织信奉 BPM 原则，他们选择了使用一种业务流程管理系统 (BPMS) 平台，结果发现部署第一个流程自动化解决方案很容易，但将 BPM 扩展到整个组织来实现他们最初计划的流程统一化和标准化水平却很难。

我将会解释，如果在开发一个合理的业务流程架构之前就投资执行流程自动化，通常会出现这种情况。谈到 “业务流程”，我指的是对一个活动序列的逻辑描述，组织执行这些活动来生成有价值的结果，无论它们的自动化水平如何。通过定义易于管理的、可在更大的价值链中重用和合成的流程，合理的架构可以最大程度地实现业务操作所实现的价值。在本文中，我将展示如何实现此架构，设计具有定义明确的职责、清晰的所有权和彼此松散耦合的流程。

developerWorks 上发表的一些文章已讨论了如何基于技术维度来分类和分解流程。但是，我的目的是向业务领域应用架构思维。在考虑技术之前，您如何确定一个流程何时开始和结束？它的核心职责是什么，它与组织的其他流程有何关系？

将高级流程步骤分解为不同粒度级别的子流程的基本技术，本身无法用于开发成熟的架构。在我的经验中，这仅适用于一些受限的场景，其中的业务可简单地描述为一个线性的活动序列，而且每个功能区域都与组织的其余区域隔离。本文从更加整体性的视角来审视一个流程架构的设计和它的组件定义。

定义上下文和范围

企业级业务建模规划的复杂程度可能让人望而却步。试图好高骛远的风险始终很高，定义一个明确的范围可能是成败的关键。为此，您需要有一个在整个组织内共享的参考依据。这个参考依据都可以由一个 能力模型 提供：组织职能的一种高级图表，其中每个组件表示一个逻辑功能，这些功能具有内在的高凝聚力，但彼此松散耦合。IBM 为每个行业开发了一组能力图表，称为组件业务模型 (Component Business Model, CBM)。这些图表使用行对可靠性水平进行了分类（从战略到控制和执行），而列是围绕企业价值链的不同区域来设计的。

因为能力模型的元素具有内在的高凝聚力，并且彼此松散耦合，所以它们的界线为制定一个没有太多外部依赖性的流程建模工作的范围提供了有效的准则。您不应低估在整个组织上下文中通过突出显示要解决的组件来一致地沟通工作范围的价值，如图 1 所示。

图 1. 零售银行的组件业务模型

业务流程分解

定义一个清晰的范围之后，如何得出一个条理清楚的架构？上面已经提到过，在这点上，大多数传统的流程分解技术都无法胜任。将粗粒度的活动分解为子流程时，您仅分析了组织的行为。遗漏了至少两个重要的维度：结构和信息。然后，整体方法应该利用 3 种补充性技术：流程分析、结构分析和信息分析。

流程和结构分析

您可以将流程想作是一个组织对企业内外的某个人的产品或服务需求的响应行为。流程分析专注于组织的工作原理，将每个高级流程分解为不同级别的更细粒度的活动。

例如，我们想象一家租车公司的情形。图 2 给出了组织支持客户租车需求的行为的分解图。

图 2. 租车行为分解

另一方面，结构分析考虑的是组织的组成部分，将每个高级功能分解为更小、更具体的区域。因为会分析和描述每个功能区域的责任，所以这些区域被放置在它们与其他功能区域的关系的更大上下文中。

功能区域之间的协作与企业流程具有直接的对应关系。确实，经过一定级别的分解后，当一个细粒度功能可与流程中单个活动匹配时，两种分析方法将大致相同。

在我们的示例中，如图 3 所示，Rentals and Reservations 支持租赁体验的大部分客户可见的方面，而 Promotion Management 和 Price Management 控制租赁价格，Fleet Management 是提供车辆可用性和交付能力的关键。在车辆返回之前，客户面临的任何问题都会经过 Customer Service 来解决。

图 3. 租车操作的结构分解。以红色突出显示的组件在租赁相关活动中具有直接的作用

结构分析和流程分析是互补的：第一种分析在非常高的抽象级别上最有效，例如影响分析和节目范围定义，而第二种分析最适合在更低的细节级别上分解业务。因此，使用通过结构分析所识别的区域来对行为（流程）分析中建模的活动进行分类，这很重要。这将帮助识别跨多个不相关流程执行的公共活动。

信息分析

在 BPM 解决方案中，数据常常被视为一种事后要用的东西。活动和它们的流是业务和设计团体使用的主要抽象。之后在以后的某个阶段，您才会认识到 “帐户”、“客户” 或 “产品” 等关键词汇在不同的业务部分具有不同的含义。这会带来难以管理的业务实现变体。业务词汇表（有时称为数据字典）是一个基础工件，应包含与一个计划关联的词汇在整个组织中达成一致的准确的语义定义。数据模型也对指定信息对象之间的关系以及它们的关键属性至关重要。

信息分析还在流程分解过程中发挥着重要作用，有助于理清业务操作的描述。目的是将业务建模的关注点从 “行动” 转移到所处理的 “实体” 上。订单、请求、计划或发票等实体是企业用于跟踪其业务运营的信息；它们是在一个流程中创建、演化和（通常）归档的核心概念对象。例如，当银行客户从其帐户取款时，他们会填写一张取款单并交给出纳员。出纳员使用该取款单检查客户帐户的详细信息，并依据该金额来请求经理批准。经理的批准方式是在取款单上签字并将其返回给出纳员，出纳员将请求的现金提取给客户，然后提交该取款单用作银行记录。尽管本示例中提及了帐户和客户等名称，但 “取款单” 是关键的业务实体，它采集了与取款流程相关的所有重要数据：描述它的生命周期是一种描述该流程的工作原理的有效方式。

对 业务实体 生命周期的分析提供了一种额外的视角，在基础级别上将数据和流程结合在一起。业务活动始终应在业务实体的状态中生成一些有意义、能够带来增值的变化。如果一个业务活动没有带来这些变化，那么可以删除该活动或将它与其他活动组合在一起。然后可以将一个流程视为对核心实体的生命周期的管理，该周期的每个状态直观地与一个业务相关状态相对应。采用这种建模方法可得到更加模块化的、松散耦合的流程架构。

以一个客户分散在多个地点的 IT 服务提供商为例。它提供的服务可能包括 IT 置备、安装、维护和一般支持。图 4 中的活动流可用于描述该组织如何解决客户请求。

图 4. 被描述为活动流的 IT 服务提供商操作

这个简单的模型必须针对真实操作的复杂性进行测试。例如，一个取消订单的请求可在流程流的任意一步中收到，它对可能已执行的发票和计划活动有何影响？或者 Plan Schedule 活动如何考虑来自多个订单的请求，才能最大限度提高操作效率？

您可能会看到，一种仅以严格的活动流描述为基础的建模方法会快速演化为极其复杂的流程图。这通常会得到没有涵盖所有业务场景（尤其是异常）或在活动之间建立不必要的依赖关系的流程模型。

在一个以业务流程为中心的模型中，同样的流程可能被描述为 3 个业务实体的生命周期：Order、Invoice 和 Workforce Schedule。不同的事件驱动的流程将协调与每个实体的生命周期相关的业务活动，如图 5 所示。

图 5. 适用于 IT 服务提供商操作的核心实体

此方法会得到一种更好的业务架构。模型的更高模块化程度和松散耦合具有直接的业务价值，包括能够识别集中化业务操作的机会，以及高效地使用可用的资源。

举例而言，业务部门常常在不同的产品线上运行重复的、具有不必要变体的活动。另一方面，在图 5 中的示例中，从业务实体生命周期表示形式可以看出，发票处理已与任何可能特定于不同订单类型的处理的流程变体相分离。此模型还突出了优化多个订单的工作安排和执行的机会。

业务流程定义

上述技术可用于发现您的流程架构的候选构建块。这些 “砖块” 仍然很粗糙，只具有模糊的边界和身份。

例如，考虑分解一个银行的 Sales 和 HR 流程的场景。在 Sales 流程中，当对新客户进行入职培训时，银行执行一个 Customer ID&V 流程来验证客户是否具有他们所声称的身份（ID&V 表示识别和验证）。另一方面，在 HR 领域，每当一位新人加入组织时，银行都会执行一次 Employee ID&V。这是两个不同的流程还是两个相同的流程（参见图 6）？

图 6. 分解不同业务领域可能发现类似的流程区域

流程分解本身无法回答问题，需要进一步分析。本节将介绍这种分析的多个维度（如图 7 所示），旨在清晰地定义一个流程的职责。请注意，本节特意命名为 “业务流程定义” 而不是 “规范”：主要是为了描述如何识别流程边界，而不是了解它的行为的完整规范。诚然，我们实际上常常可能陷入业务流程 “规范” 中，而没有特意定义所考虑流程的范围。

图 7. 业务流程定义维度

所有权

流程所有权定义了由谁最终负责流程执行的操作以及如何管理它。没有明确的所有权，就会使得任何流程在展开之后立即变得无法管理。这在以流程简化和统一为目的的 BPM 计划中尤为突出。可以考虑这样一个组织，其中的不同部门运行同一个流程的独立变体。在部署一个新的通用流程自动化解决方案时，如果流程所有权结构未发生变化，则会发生什么？在不同的业务因素推动下，多个所有者会立即发现 IT 和流程已经分道扬镳。

回到银行中的 ID&V 流程的示例：一个用于客户和员工 ID&V 的通用流程只需要一个所有者。他或她位于何处？在 HR 还是 Sales 中？无论在哪里，似乎都会实际上彼此比较独立的部门之间引入不必要的依赖关系。这一问题暗示有可能将两个流程当作独立的资产来建模和管理。实际上，对识别和验证的价值主张的分析（将在下一节中介绍）表明，银行的 Anti-Fraud 部门是所有 ID&V 活动的自然所有者。

价值主张

每个流程都应向组织内外的客户提供一种清晰的价值主张。这一价值需要针对提供它所需的活动和资源成本来权衡。计算一个流程的价值的困难性可能表明，它的范围太窄或太宽。

在我们的示例中，Sales 和 HR 中的 ID&V 流程的价值都是减少银行的欺诈风险，确保与银行交易的人具有他们所声称的身份。这明确表明这两个流程可统一到单一解决方案中，如图 8 所示。

图 8. Sales 和 HR 利用了归 Anti-Fraud 所有的单一 ID&V 流程

关键活动和资源

流程通过执行关键活动并利用宝贵资源来向客户提供价值。评估这些活动和资源是什么有助于定义流程范围，将关键流程需求与它的实现细节分开。

图 9 中的示例给出了一个 ID&V 流程的可能形式。该流程验证从第三方以及个人在 ID&V 下直接提供的文档中收集的个人信息，比如护照副本。

图 9. 一个示例 ID&V 流程

以紫色突出显示的区域描述了专注于文档处理的活动。这些活动需要具有不仅限于与 ID&V 相关的文档处理能力的人力和技术资源。因此，我们可将这些活动视为一个独立的 Receive Document 流程，它能够处理任何文档（不仅是与 ID&V 相关的文档），存储它，将它与一个参考文档相关联，并向任何可能对该信息感兴趣的流程进行广播。实际上，银行通常拥有具有这些职责的 Document Management 职能部门，如图 10 所示。

图 10. 可从 ID&V 中提取出来并在更大的上下文内重用的文档处理活动

客户和提供商

一个流程必须明确地确定其客户：收到来自该流程的价值的角色。客户既可以在组织内部，也可以在组织外部，它既可以是个人，也可以是另一个流程。客户数量和类型上的巨大变化会给流程设计带来重大影响。另一方面，对于具有单个客户的流程，最好将其建模为更大流程的一个私有组成部分。

流程可将它的一些活动的执行委托给外部提供商，提供商同样既可以在企业边界内，也可以在企业边界外。定义一个流程时，一定要评估它的任何活动本身能否形成一个完整的独立流程，向组织的不同部分提供价值。我们示例中的 Receive Document 流程就属于这种情况，如图 11 所示。

图 11. ID&V 流程的客户和提供商

实际上，依照 “精益” 最佳实践，识别流程客户应是定义流程价值的前提条件。这无疑很有用，而且是一种不错的做法；另一方面，在本文中，我不会试图提出分析 9 个流程维度的非常严格的顺序。在我的经验中，流程的定义是一个旅程，涉及到对这里提供的不同方面的一些迭代，对维度的阐述通常会带来对其他已评估流程的新的了解。例如，根据 ID&V 示例，您可以看到价值对所有权决策有何影响，而且后者已将 HR 和 Sales 从潜在流程提供商转移到客户。

信息模型

在对流程的信息模型的分析中，首先应验证会在整个流程中改变状态的核心业务实体已明确识别。在我们的示例中，这指出了一个事实：核心实体不是客户或员工，而是一个人。

信息模型还应定义输入和输出，还要为对流程的所有其他维度的分析中可能出现的实体定义一个来源。一种不错的做法是，在流程范围中仅包含提供核心价值的活动需要的最少信息，将其他所有上下文信息留给其客户掌控。

例如，在 Sales 上下文中执行 ID&V 的方式可能高度依赖于一个人申请的产品类型。如果申请贷款，银行可能希望执行比储蓄帐户所需的验证更强的验证类型。如果 “产品” 是流程输入，ID&V 将需要拥有所有银行产品和向不同产品分配不同验证级别的规则的知识。一种替代方法可能是将任何知识放在该流程外，让流程请求者仅输入需要的验证级别。单单这一项输入定义更改就会大大简化该流程，使它更适合在员工入职培训过程中重用。诚然，产品的概念在 HR 中没有任何意义，重要的是依据一个人向组织申请的职位来请求不同的验证级别。

事件

事件是流程行为的触发器。识别流程边界的最佳方式是查找开始和结束事件。开始事件通常与客户的操作相关，链接到经历的时间量或某个实体状态（例如，一个达到预设阈值的帐户余额）。另一方面，结束事件常常与达到最后的增值阶段的关键业务实体相关。

复杂流程交互可能涉及到具有上述类型的多个业务事件，它们发生在流程的不同阶段。

考虑所有可能的异常事件，可以很好地涵盖该流程将需要处理的所有场景，避免仅关注活动流的 “愉快路径” 的风险。

在我们的示例中，该流程处理的外部事件包括接收一个新 ID&V 请求（流程开始）和一个文档的到达通知。异常事件可能与取消一个 ID&V 请求或文档交付的长期拖延有关。

度量指标和 KPI

外部关键绩效指标 (KPI)，例如完成一个人的识别和验证所需的平均时间，对量化和监视流程向其客户提供的价值至关重要。另一方面，内部 KPI（包括流程参与者在特定任务上所花的时间）使管理层能够控制流程的效率。

描述客户收到的请求量的度量指标，也对建立该流程的任何实现将必须满足的一组基本的非功能性需求至关重要。

业务策略

业务流程的结果通常取决于一些复杂的业务决策，这些决策应根据公司的策略来制定。这些策略的所有权、生命周期和信息模型与流程的这些方面有很大的区别。制定它们并将它们作为与活动的流程流分开的业务规则来执行，这非常重要。

与 ID&V 相关的业务策略可能包括，确定身份验证需要哪些类型的文档的策略，以及控制与银行收集的个人信息相关的风险评估的策略。

流程可变性

针对一些关键维度来提前评估流程的可变性会很有用，这些维度包括位置、渠道、产品和最终客户细分（参见图 12）。这有助于决定是将需要的可变性吸收到流程中，还是为不同的变体创建不同的流程。

要考虑的另一个方面是可变性，流程必须应对其未来进化版本中的可变性。显然，我们不可能预测未来，但是，通过评估变化的可预测性、速度、规模和所有权，能够让服务提供商最大可能地在解决方案中设计适当的灵活性。

图 12. 以可变性为导向的流程分析

如上面所述，在我们示例的 ID&V 流程的设计中，可以让流程的行为不依赖于银行希望销售的产品类型的任何变化。要考虑的其他可变维度可能关系到一个事实，那就是银行可能希望在未来更换第三方提供商或向参与 ID&V 流程的人请求不同类型的文档。只要与第三方交换的信息保持不变，第一种变化的影响可能非常有限，而文档类型的变化可以通过业务规则来管理。

结束语

在本文中，我从一些互补的视角（基于行为、结构和信息）分析了业务流程的分解，还讨论了 9 个可用于定义流程的边界和责任的不同维度。这些技术降低了复杂性水平，有助于跨业务操作实现更广泛的标准化，使流程可作为宝贵的企业资产进行管理。