业务流程管理工具（BPM）随着时间已经逐渐发展，而且也受到各种观点的影响。早期流程编制工具区别于IT运行时的观点，而且规划这些工具是一项相当复杂命题。非IT人士对于业务建模工具的理解是一种更高层次的观点，随着时间推移，业务模型能够生成改进的运行时代码。

　　随着BPMN 2.0的出现，在业务流程建模工具方面会有一种显而易见的转移。但是，对于流程是什么没有一种共性的理解，包括IT端和业务端团队很可能在使用BPMN创建出众的BPM系统时会出现困难。

　　用Derek Miers的话说，转向这样的一种共识的时候可能要求对于流程的认可，这也意味着不同人不同事，他是Forrester Research的分析师。根据Miers所述，在探讨流程的时候，一些人会提及“规程（procedure）”，规程的序列或者是步骤都是BPM的一部分。别人讨论流程的是，实际上他们所说的是“实践（practice）”或者是工作方法。区别特别明显，通常现在的需求构建灵活的系统，而不是僵硬的系统。

　　着重强调现有规程会损害一些BPM的努力。当人们努力的改善他们所得到，而不是尽力去开发一些他们实际上需要的东西的时候，这种情况就会发生，Miers说。

　　实际上，他指出“流程”常常仅仅就是一个组织图的代理，以及“无论功能分解成什么，它就是一种问责机制。”

　　根据Miers所述，这种方法创造了“kebabs（烤肉串）”——组织图和流程图类似的膨胀。

　　“当我问大家，他们是否曾经看到过一个流程，他们说‘是’，而且开始描述一个流程图，”他说，“那实际上不是一个真正的流程。”

　　建模也遭受了同样的理解之痛，他说，换句话说，在处理整洁易理解的事物上省去了大量的努力。Miers说基本上应该包括活动顺序，谁来控制任务，此外，协作信息、同步以及其他的因素。

　　Miers认为模型被用于沟通，但是很多人认为，如果他们把所建模的流程都放在一起，就能够不可思议地重用它们。“那就是一堆垃圾，”他说。

　　通常会发生的是什么呢？就是人们试图过度设计一个流程，为了让其适用于数个用例中。“但是最终对于任何人都没有用，”他说。

　　解决方案是什么呢？抛弃牛顿的因果方法，开始接受混乱和持续的变化。换言之，考虑梅特凯夫定律，网络价值同网络用户数量的平方成正比。换言之，不要试图创建密封的、最终模型，要关注适应性和发展性。

　　“如果你关注模型以及对什么进行建模，你就会发现，系统和流程始终在变化，所以六个月后或者甚至是三个月后，模型就需要修订，”他说。

　　Miers对于工具也提供了一些建议。按照他的观点，更加的标准和更为广泛使用的的一种工具会是更佳的选择。“很多厂商在一中不稳固的业务模型上兜售工具，他们承担很多责任，而且客户也极少，”他说。这些工具大多围绕存储库构建，使用起来是很耗时。