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之间的联系的确存在许多混杂。它们是彻底不一样，但又彼此关联的学科。一方面，彻底有也许规划和完成没有任何自动化的事务流程；另一方面，事务流程自动化的确需求触及许多的软件工程。
以上文章由武汉网站建设公司整理发布。http://www.tuoruisi.com转发请注明出处。