在这篇文章中，我们要从根本上讨论流程的不同方面的问题：一旦流程部署，在这种情况下对于流程管理者而言BPM是如何应对变化的。

　　管理者完全是从完成任务的角度来考虑它。技术既能让管理者尽力去做成某事又能阻止做成某事。对成功而言它或是业务引擎或者障碍。不幸的是，至少迄今为止，它还经常作为障碍，这一点确实已经在BPM界被证实。

　　BPM对管理者来说一直是个障碍

　　观察BPM的历史，它给我们展示了一些清晰的模式，但这些模式严重地限制了BPM对管理者的价值。这种说法并不足为奇。BPM从历史上说产生了流程设计，这些设计没有反映出现实世界中流程的真实本质，但却导致过度工程化和我们以为我们了解的笨拙的截图，或一个原本想结束静态的灵活设计（按需改变）。

　　这个过度工程化的透视是由本来不成立的假设驱动的，这个假设是我们能够向模型中定义所有替换路线、流和流程的行为。这个结果是复杂而且又不灵活的，并且管理者不断地同“围绕系统的工作”而斗争，因为向这个“模型”中设计工作是如何完成（和如何改变）是不可能的。这已经使我们从无效支持技术的版本向另一个仅仅收效甚微的版本迁移。

　　相反地，弹性流程模型的想法采用的就是我们目前的做法--原则上被各个负责给定流程的管理者更改--已经惨败了。这个概念很棒，不幸的是不管我们给他们什么工具，管理者都只对定期更新的、以流程设计环境的某种方式的流程不情愿（不感兴趣）。他们不是传统意义上的构建者，不论我们让流程多简单，构建者的工具都不合适。

　　更进一步而言，BPM过去一直没能给管理者真正需要的信息和透明的流程。现在，我们需要多留意这，因为这个声明在功能上成立的情况下，在技术上却不成立。问题在于并不缺乏从BPM软件中获得可用信息，相反问题是正确的信息以正确的格式，在正确的时间，以一种让管理者完成她/他的工作却而又和他们所得到的结果不一致的方式呈现。换一个说法，150个预先包装好的报告中很可能有管理者需要的信息，但谁去混乱中搜集找出现在发生的情况？他们想要（需要）的是，当他们需要时，管理者在不需要大动干戈的情况下，能够完成他们工作的可用信息。