首先，我只想说我真的很喜欢BPMN标准，尤其是2.0 Beta规范。我发现这种表示法是一种功能强大且具有表现力的语言，它不仅考虑了业务流程中的标准元素，而且还考虑了可能出现的各种有趣的可能性。我认为新的编排和对话图以及其他事件类型开辟了新的方式来描述各种个人和组织之间的复杂流程和协作。的确，BPMN允许您以图形方式对企业中可以找到的几乎所有情况进行建模。
但是我很少使用它。
根据BPMN 2.0 Beta规范，BPMN有两个目标。一个目标“是确保可以使用面向业务的符号来可视化为执行业务流程而设计的XML语言，例如WSBPEL（Web服务业务流程执行语言）。”
另一个目标是“提供一种易于理解的符号，从创建流程初稿的业务分析人员到负责实施将执行这些流程的技术的技术开发人员，最后是所有业务用户，都应易于理解。将负责管理和监视这些流程的业务人员。”
尽管BPMN在第一个目标方面做得非常好，但我认为它并没有达到其第二个目标。
商界人士无法马上获得BPMN
每当我在实际的商业客户面前使用非平凡的BPMN模型时，我总是至少会遇到一些问题。问题的数量取决于他们的复杂程度以及他们之前看过BPMN（或类似）图的次数。BPMN利用了几乎所有业务人员都熟悉的典型流程图，但是他们进行了几处更改，使他们的模型从任何地方都变得有些混乱，使外行人难以理解。
例如，我得到的最常见问题之一是关于每个池都有自己的开始和结束过程以及过程流线这一事实。如果池之间存在交互，则使用消息流。大多数业务人员对额外的流程线不知所措，并且在遵循整个流程路径时遇到了麻烦。
使用BPMN，这并不总是很容易看出来，因为所有池都沿其自身的流程流继续进行。
每个池定义为 “独立的业务实体或参与者”，而通道则用于“分隔与特定公司职能或角色相关的活动”。
BPMN是BPEL的伟大先驱
如果您准备利用业务流程执行语言（BPEL）并拥有适当的BPEL Process Manager解决方案来自动执行业务流程，我肯定会看到BPMN是一个很好的工具。BPMN规范指出，传统模型在“业务流程的初始设计格式和将执行这些业务流程的语言（如WSBPEL）之间形成了技术差距。” BPMN确实是为解决这一差距而设计的，但是它通过牺牲任何给定模型的开箱即用的可理解性而专注于技术实现方面。
从解决方案的角度来看，这是有道理的-如果目标是最终拥有自动化的业务流程，那么您需要确保模型可以翻译成可用于计算机的语言。BPEL已经存在了将近8年，并且已经获得了软件提供商和企业的认可。结合尽可能降低劳动力成本的需求，显然需要非程序员或技术精湛的人员能够利用过程的图形化描述。
像其他任何技术驱动的语言一样，BPMN是相对通用，健壮和灵活的。为了实现其灵活性，该语言必须固有地复杂，以处理可能属于该语言使用范围内的所有可能情况。从实现的角度来看，这虽然很棒，但它却使那些对表示法知识了解比较少的人则无法阅读图表。
何时坚持使用久经考验的真实符号
在大多数情况下（涉及当前状态分析，通过未来状态流程进行工作，验证需求等），涉及业务人员与图进行交互的BPMN有点过头了。当我不尝试创建可自动化的BPEL驱动的业务流程时，我发现业务人员几乎可以普遍理解流程图。这是大多数人在某些时候接触过的东西，即使他们没有那么多不同的图表对象，也很容易快速上手。
尽管流程图可能无法像BPMN那样优雅地对复杂的业务流程进行建模，但是您仍然可以通过将复杂的情况分解成几个较小的组件图，然后使用链接对象在组件之间移动来完成工作。我发现这不仅可以帮助我确保在构建模型时每个组件图都清晰可见，而且还可以帮助我在与客户一起查看详细信息时与客户一起处理特定的子流程或异常情况，因为这样更容易一次专注于一个相对简单的图表。
尽管BPMN是为自动化准备业务流程的好方法，但在与业务本身进行交互以记录，验证和设想业务流程时，它可能不是最佳选择。