业务会采用 BPMN2.0 吗？

许多刊物已明确指出，保证业务流程管理（BPM）成功的主要前提之一是业务和 IT 的紧密协作。业务流程管理标注（BPMN）的发展是保证这种合作的途径之一，其最初目标是——成为 IT 和业务共用的业务流程定义语言。BPMN2.0 引入了许多新结构，它们可用于直接定义流程的执行方式，因此，许多供应商采用它作为 BPM 的运行时语言。但是很多分析师认为，从业务的角度看，执行方面的增强使它更加复杂。Jim Sinur坚称，BPMN 对业务的要求太高：

BPMN 对于业务的复杂程度并不取决于业务需求。有些人认为，因为 BPMN 对 IT 已足够好，所以对业务也应该足够好。我认为，前半句没有问题，后半句与事实之间存在差距。IT 无法期望业务真正理解那些加密的 / 标准的格式，因为业务希望看到的业务流程的真实描述，用他们期待的那些图标，而非工程图标。好比某人说“让他们吃蛋糕啊”（译注：参考 let them eat cake ，最初可能源自法国的某位公主，当她听到农民没有面包吃时说，“让他们吃蛋糕啊”，而蛋糕是用高级面包和鸡蛋做成的，此处表示 IT 不了解业务对 BPMN 图标的理解水平），正是这种 IT 的傲慢让 BPM 技术沉没……BPMN 其实是“业务人员无法理解”（译注：“Business People May Not…understand”，前面四个单词的首字母缩写也是 BPMN）。

Sinur 的博文引起了洪水般的回复。其中，Scott Frances认为，我们可以要求业务掌握一些新技能，正如他们要求 IT 提高他们的技能一样：

尊敬地说，我理解 Jim 的愿望是让业务摆脱困境。业务不需要学习任何新技能，只在餐纸巾上画点东西就期待它能像流程一样运行？随意画点陈旧的图形，如果不要求别人理解还不成问题（诚然，标准的价值在于不单单是某个人或某个团队才能够理解它所产出的东西）……如今，在我们要求 IT 学习新技能、变得更加面向业务的同时，让业务学习一些新技能以支持流程的改进，这点要求过分吗？……问题不在于标注语言 BPMN 本身有多难，而是太多人认为 BPM 开始于 BPMN，结束于 BPMN。较之 BPMN，人们更需要业务流程的管理并改进。

Keth Swenson提到，BPMN 新版本的大多数增强都是针对开发人员而非业务人员的，它将图形化编程语言转换成流程。针对侧重于建模而非执行的厂商是否会从 BPMN1.2 升级到 2.0，他表示怀疑。在他看来：

对服务器整合型 BPM，或者 EAI 或 Web 服务编排而言，它们的确能从 BPMN2.0 的新增特性中获得不少益处。而对于用图形描述人工活动的工作流而非服务器整合，BPMN2.0 中增加的那些特性也许只能给我们带来更多复杂性，却不能带来充分的好处。

Sandy Kemsley 在回答 Swenson 的评论是说，他强烈反对他的意见：

我认为 Keth 的说法是“将婴儿与洗澡水一起倒掉”（译注：这是一则习语，意指丢弃无用物时将珍贵的东西也一并丢弃了），尽管许多新增的特性使得 BMPN 对于开发人员更加有价值，但这不能否认那些原有的基础结构集对于业务的价值，因为业务已经使用这些基础结构将业务流程映射成流图。在没有任何引导的情况下，我经常看到业务（和业务分析员）用流图表示他们的业务流程；将他们引导向这些最简单的 BPMN 结构集合至少能让那些流图变得标准化，从而减少对流图中各种的图标的误解，减少流图事件出现混乱局面的可能性。

Neil Ward-Dutton 持中庸立场：

……BPMN 的应用性取决于众多因素；简单地说 BPMN（特别是 BPMN2.0）适用于业务或不适用于业务太过轻率和绝对，这就像说云计算将是（或否）IT 的未来一样。这其中的第一个假设是，必须要对 BPMN 作出个非此即彼的定位；第二个假设是，“业务是某种单一组织，只有单一的技能、经验和偏好”……很多事实表明，一个有高层分析和设计经验的业务分析员绝对能使用 BPMN 的核心图标集描述业务流程，从而在交叉团队间形成便于交流的共通语言。

是的，BPMN2.0 中大部分新特性的目标都使它成为一门可执行语言，而且，完整的标准的确相当复杂。但是，正如 Bruce Silver 的书中的解释，BPMN2.0 可用在三个层级上——描述、分析和执行。如果我们假定业务从只包含10 个主要图标的第一层开始，这样就不会太复杂。但是，形式化的标准语言能使业务和IT 在理解和解释上达成一致，这一优势是巨大的。

查看英文原文： Will Business Adopt BPMN 2.0?