Robert Perkins曾经使用过BPM工具，他解释了自己不喜欢BPM套件的原因：
去让你的工程师使用如visio这样的流程图工具来编写你产品的下一个版本。他们将被限制使用javascript。他们将没有自动回归测试系统。他们将没有一向所依靠的eclipse或Intellij Idea的任何特色功能。这里也不会有任何构建部署脚本，部署工作将陷入手工拷贝文件。噢，他们将不会有版本管理。
你含沙射影地说那些想使用这些工具而不用能为业务创造最大价值的工具或产品的开发者是为了一己之需。
这确实有些道理。我认为有很多非技术的企业都会相信这一点，它正在制造开发者和企业之间的不信任。我知道我现在的公司就有这个问题，我想很多厂商和销售团队都在利用这一点。
而且就成功的案例而言，我不知道应该信多少。我的公司被列为一个“成功案例”。而现实情况是该项目是一个灾难，最终用户还在抗议中，并且截至今年3月整个开发团队还在继续开发中。
问题不仅仅在于BPM，而是更为普遍。在很多地方，企业是个性化一些业务或表达逻辑的非常好的位置。最近Mark Proctor就统一规则和过程引擎是否有益提出疑问，他认为许多过程定义需要更有表达力的规则引擎，而且规则能受益于过程引擎的状态管理能力。Mark补充说：
统一建模环境的一个美景在于你可以选择想要的方式对事物进行建模。
Dave Wright认为这一切都有千丝万缕的联系：
你可以说，在给定的相似的数据模型和条件及事实模型下，规则和数据相比规则和过程而言要更加紧密地联系在一起。我知道你不想分离过程和规则平台，你也想去掉分离的数据平台吗？
Pierre Bonnet关于敏捷链管理系统（ACMS）的分析证实了这一点，他认为MDM, BRMS和BPMS之间有着非常强的联系：
主数据管理（MDM）。 引用数据和参数的简化管理，允许服务配置模式的实现将执行置于上下文中。
业务规则管理系统（BRMS）。 规则依赖于引用数据和参数。组织服务的前置、后置条件位于规则管理系统中。
业务过程管理（BPM）。 过程使用规则来驱动不同阶段的活动。编制服务被MDM和BRMS置于上下文中。
Peter Evans-Greenwood赞成使用一种新途径来定义应用语义:
规则和过程之间的分离只是技术所带来的一种人为结果，并不是我们希望它们如此。分离规则和过程引擎带来了庞大的花费（这是我们可以免除的）。
更富有成效的做法可能来自这个问题的反方向。让我们由上而下来调查人们是如何认识和处理业务逻辑的，然后创造出能够模仿我们的做法的工具和技术。
