Keith Swenson在其发布于BPM.com的新文章的开头这样写道：

　　BPM社区中的大多混淆和困难都是由于某些人认为BPM是软件工程的一种而造成的。的确，从外表看它非常象软件工程：由需求开始，然后确定需要在变量中保存和检索的信息，接着可能要画出它们之间的关系，最后就是把成品在联网的计算机上安装和执行。但是，它们之间存在区别，而这个区别就是BPM之所以存在的原因。

　　根据Keith的说法，软件工程在其50多年的历史中已经取得了极大的进步，包括结构化和面向对象编程、复杂的建模语言（UML）和大量在开发过程每个阶段发挥作用的工具。结果，软件工程师会将“业务流程管理”视为另一项将图转换为可执行程序的简单活动：

　　当我们手握锤子的时候，我们会开始把所有围绕在我们周围的问题都看作是钉子……业务流程步骤被解释成和程序步骤完全类似。软件工程师几乎靠条件反射就能将高级别功能翻译成低级别的函数序列，然后借助控制流等将其翻译成某种最终可转换成机器语言、执行就绪的东西。我猜想很多人都有这样的感觉：BPM纯粹是大量的市场炒作，其核心不过是软件工程世界中很平常的东西。这到底有什么了不起？

　　Keith试图通过区分业务流程和典型的程序来定义软件工程和BPM的区别：

　　“业务流程”不是程序。支撑它的虽然可能是程序，但是业务流程是组织想要完成的事情。你可以说业务流程是程序的目标，而不是程序本身。业务流程由业务人员管理：这个人他理解“业务”，决定完成业务的策略，评估业务的健康状况，决定如何变更业务以满足不断变化的条件。软件工程师管理软件，而业务人员则管理业务流程。

　　他接着概述了BPM解决方案和一般程序的主要区别：

　　业务人员所画的图就是被执行的那张图。它不会为了软件工程师的方便而转换成其他形式。它不会为了执行而转换成其他形式……这种转换是出于优化执行的目的，尤其是在处理能力有限的机器上。某些业务流程仍将需要这种转换，但是绝大多数的业务流程将不会受限于CPU的性能。

　　历史和分析报表需要匹配原始图表，以支持业务用户能评估组织的执行状况，它不是为了让程序员能分辨程序的运行状况。

　　在软件系统中，用户很少需要知道程序的内部结构，但是从这个角度来说，业务流程不是程序。流程本身必须是可见的，即便有程序支撑它执行也是如此。参与流程的人必须能了解当前步骤、后续步骤和最终步骤。这是BPM和软件工程的最大区别。

　　根据Keith的说法，混淆和误解的一个最大来源是由于BPM设计和开发大都是由软件工程师完成的：

　　遗憾的是，很多研究BPM系统的人大都具有软件工程的背景，并下意识地认为BPM应该具有某种标准软件的特性。软件工程师将系统视为一种发送、接收和转变信息的手段，他们受训将业务问题归纳为可以按这些方法来执行的某种事物。业务人员不会把焦点放在字节的发送和接收上，相反他们更看重职责和承诺。这是看待业务流程的不同方法。这种区别的效果是巨大的。试图把所有软件工程的特性都装入到BPM（业务人员）的特性中，其结果必然是两面不讨好。时至今日，你仍会碰到一些人认为BPEL是实现业务流程的终极方式。BPEL仅仅提供了一种发送、接收和转换的手段……这些是软件工程的需求，而不是业务流程的需求。软件工程师会告诉你，利用这些原语（primitive）你可以实现任何东西，可能包括电子表格，但是这忽视了一个要点，一个我们一开始为什么需要电子表格和BPM的要点：因为它们不是软件工程。

　　Keith在其文章的结尾对目前OMG BPMN 2.0活动进行了评估：

　　在OMG邮件列表中，关于“BPMN怎么会只是统一建模语言（UML，软件工程师钟爱的作图标准）的另一个方言”激起了广泛的讨论。软件工程师的确可能会从BPMN中看到对软件工程有用的东西。记住，OMG组织主要是由软件工程师构成并为软件工程师服务的，大多数OMG成员会得出以上结论完全不足以为奇。他们大多数甚至可能认为UML对所有学科都有用。把BPMN看成是UML的一个方言对于将把一张图归纳成一个可执行程序的软件工程实践非常有用。

　　BPMN的存在是为了让业务人员可以表达业务单元内部人员之间的交互。在OMG内部也有不少的人明白这一点，我希望这些人不要被那些认为所有问题都是软件工程问题的人所压倒，这样对我们大家都有好处。BPMN的存在不是为了软件工程师的方便，因为BPM不是软件工程。

　　在业内，对于软件工程和BPM之间的关系的确存在大量混淆。它们是完全不同，但又相互关联的学科。一方面，完全有可能设计和实现没有任何自动化的业务流程；另一方面，业务流程自动化确实需要涉及大量的软件工程。