BPM与软件工程：完全不同而相互关联

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

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

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

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

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

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

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

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

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