简介
我很清楚你们想说什么 -- BPM 评审和魔方？ 接下来会讨论什么，PacMan 还是 Facebook？您肯定会问 “Scott，BPM 设计评审和魔方有什么关系？” 好吧，让我先来介绍一些背景知吧。我使用 BPM 技术大约有 15 年了，得出这样一个结论，评审 BPM 应用程序类似于破解魔方问题。BPM 解决方案通过大量模式和应用程序类型呈现自己。更重要的是，给定的 BPM 解决方案通常呈现多个维度，甚至在单个应用程序中也是如此。当您评审一个 BPM 解决方案时，必须考虑到所有维度，并确保它们彼此能适当地结合起来。类似地，破解魔方是为了使立方体的各个面上具有相同的颜色。所以说，BPM 设计评审和魔方之间有一定的关系，都需要采用一项技术，作为端到端流程的一部分评估多个维度。
去年，一个客户曾要求我开发一个 BPM 评审流程来支持他们的开发工作。最初，这似乎只是一个简单的运用，然而，当进一步深入这项工作时，我才意识到这比我最初想象的要困难得多，设计一个 BPM 评审流程的复杂性涉及到一个 BPM 应用程序包含或显示的多个方面，并且需要评估每个领域，以便开发优化改进解决方案的方法。
现在，让我来回答您关于 BPM 设计评审和魔方之间关系的问题：在 BPM 中（关于破解魔方），您拥有多个维度或颜色，需要对齐才能 “满足” 需求，需要以正确的次序处理这些维度问题才能评审一个 BPM 解决方案。
这些 BPM 应用程序的一个关键宗旨是，需要结合多个 BPM 模式和应用程序类型来制定一个完整的 BPM 战略。这些模式和应用程序类型范围涉及到直通式流程、专用流程、以规则为中心的模式和传统工作流。所有这些模式都会利用许多不同因素；结果是，当我们评审 BPM 应用程序以及这些变体中的因素时，需要有足够的灵活性，在本文中讨论 BPM 设计审查时，我将采用一个得到广泛应用的方法来介绍多个特性（魔方的不同颜色），以便提供一组指导方针，让读者可以根据自己的需要使用适当的评审技术。
在本专栏中，我将介绍一个根据一般法则进行 BPM 设计评审的方法，以及一个用于多个战略客户的方法。我需要声明的是，每个组织都各不相同，因此您可能需要为您的组织定制这些技术。
设计评审的目的和目标：不仅仅是排列颜色
查看图 1（通常称为 “婚礼蛋糕” 或 SOA 层次图），很明显地可以看出，流程应用程序并不是独立存在的。业务流程应用程序提供客户应用程序（比如，用户界面）和潜在业务以及技术服务之间的关键层。BPM 通常包含多个业务和技术组件的 “编制”，以便提供组合业务服务，这通常需要状态管理功能，尽管简单 BPM 应用程序可能只能反映传统工作流，比如自动化人工任务。除了编制服务之外，BPM 应用程序还需要与横切关注点交互，比如，集成、非功能性需求、数据基础架构和治理。这恰恰就是为什么进行 BPM 评审需要的不仅仅是 “排列颜色” 的原因，因为评审非常复杂，必须处理大量不同的甚至有时相互冲突的维度。此外，设计评审通常需要多个团体的参与，这些团队中有业务方面的团队，也有技术方面的团队，他们需要确保 BPM 应用程序设计和开发中业务和 IT 之间的一致性。
图 1. SOA 层
或许，最好先从定义 BPM 设计评审关键目标开始。根据我的经验，该目标是：
确认业务和 IT 之间的设计假设和需求。
确保业务和 IT 涉众与范围和需求同步。
促进协同开发方法。
加速开发
最重要的是，在部署之前减少异常等级。