“范围蠕变（scope creep）”指在一个项目的范围控制的变化。这种现象出现时，就会发生一个项目的范围并错误定义、记录和控制。通常，我们认为范围蠕变是消极的，而且要极力避免。在《BPM最昂贵的错误是什么？》一文中，大多数人也认为范围蠕变是BPM项目最致命的一击。

　　BPM本身确实容易发生范围蠕变，因为我们很难界定一个流程的结束以及另一个流程的开始。此外，这个行业中市场也在兜售这样一种想法，流程可以跨越组织界限，它远远超越了简单的工作流。这一点也让确定从何停止、什么时候停止难上加难。那么，如何才能很好地处理“范围蠕变”？

　　避免范围蠕变

　　首先，我们要知道范围蠕变会发生，具有一定的不可避免性。然后通过目前的计划、优先权以及项目日程来最小化范围蠕变对于项目的影响。也要准备好记录下这些蠕变，文档化这些蠕变对于项目的影响。当然，我们也可以通过一些简单的操作避免范围蠕变的发生。

• 彻底理解和文档化项目。明确定义所有的可交付成果以及这些交付成果如何映射到业务优先级上去。
• 确保范围是合理化的。
• 确保我们要处理的问题或者要自动化的流程定义良好。
• 确保项目中所有相关者能够对流程的参与负责。
• 从小的单位开始执行，逐步确保所有人都理解这个流程。

　　敏捷方法

　　应用敏捷开发方法来实现BPM解决方案也是可循的路径之一。首先，我们要了解流程完整的幅度以及其中的优先级关系。接下来就要关注重点部分的细节。逐渐迭代，把相关部门也关联进来，改善已经完成的部分。这样一来范围就由数个流程装箱，可以在合适的时间内进行实现和测试。这一点也取决于实现过程中的复杂性，而不是设计阶段的凭空猜想。

　　此外，我们知道敏捷方法不是万能钥匙，并不适用于所有的环境，或者说可以解决所有的业务问题，但是确实是可以参考的方法，如果在可用预算范围内，这种方法可以提供高质量的解决方案出来。

　　从另一方面上来看，范围蠕变也并不是一成不变的都对BPM项目不利。如果能够预先接纳的话，实际上对项目也是有利的。敏捷方法促使我们从小的增量开始实施，让最初的范围保持的较小，让BPM项目参与者可以更快上手。这也为重新实施、重新设计提供了足够的空间。衡量流程运转状况，及时收集终端用户的反馈，周期性的进行改进。每一次的改进都是对企业现有的这些产出的评价。

　　正如当代著名哲人科学家普里戈金在《未来是定数吗？》中所说的“未来是不确定的……但是，这种不确定性正是人类最深层的创造力。”