信息技术发展至今，企业的IT部门面临的一大挑战是如何才能迅速调整应用软件，以便紧跟企业业务的变化，即使是在一个高度不确定性的环境中。为了应对这种日益重要的挑战，程序工程师们开发了新的程序设计模式，例如极限编程（Extreme Programming，是一套能快速开发高质量软件所需的价值观、原则和活动的集合，使软件能以尽可能快的速度开发出来并向客户提供最高的效益），迭代开发模式（iterative development是往复进行的、增量的，“极限编程”的一种形式）。所有的新技术应用目的都是一样的：尽可能的缩短软件开发的周期，同时满足更多的限制条件，并且能够在同一个模式下面不断的升级。与此同时，一些新的架构技术也开始进入我们的视野，这些技术都是以服务或者企业的流程为导向的。而且，面向服务的架构技术——SOA和面向流程管理架构的技术——BPM逐渐开始成为主要的引导技术，而实践证明这两种技术是满足企业“随需应变”的最好的两种武器。

　　很不幸的是，在许多的软件开发和系统设计中，企业 “随需应变” 的要求并没有得到很好的满足。这也不能完全怪企业的CIO目光短浅，因为很多企业不断减少自己的IT预算，而要求却是大幅增加，企业的IT系统能够维持目前的现状已经是很不错了，哪里还有什么精力和资源去满足“随需应变”的要求呢。问题也不是程序开发人员的技术不能达到企业项目的要求，而是在于现在通行的软件开发（或者升级）模式根本就没有办法满足现代商业环境所提出的要求。

　　具体的情况我们接下来详细的说明。传统的软件开发都是建立在这样的模式上面的：从用户那里把需求都收集在一起，制定满足这些需求的计划，并且在软件开发的过程中得以实施，然后通过结构化的设计模式和软件程序变更的方式来进行调整，以满足新的需求。但是这种传统的软件开发模式已经不能满足新环境下企业的需求：

　　传统的开发模式不能全面地、正确地定义这些企业的需求，因为企业的需求是在不断变化的（一般来说，并不是企业自己要不断更改自己的需求，而是他们所面临的商业环境的变化迫使他们不得不做出相应的变化）；

　　在高度不确定的环境中，企业甚至有可能在软件设计还没有结束的时候就要改变整个系统；

　　出于紧急需要，变化的要求会不按平常规定的时间提出；

　　面对激烈的竞争和不断变化的环境，企业几乎不会提供什么额外的设计时间或者计划来创建更多的参数选择，本来这些参数选择可以让业务部门能够有效的对系统进行调整而不需要IT部门的协助。

　　事实上，企业及其IT系统面临的最大的挑战来自于企业的业务流程。所有的人都希望自己的系统能够自动的调整并且不断优化自己的流程，但是不考虑自己的流程是否内置于传统的应用里，还是为企业某功能（例如客户管理）定制开发的单一流程。

　　对于企业的流程来说，高度的不确定性是其最本质的一个特点之一。现在，大多数企业的流程已经成为业务环境中的一个组成部分，这并不是企业经过周密的计划得到的，而仅仅是对做好事情的一个自然的反应。企业的流程一般都是贯穿于企业的系统之中的，通过流程加强系统与企业中的个体员工之间的联系。并且流程通常都是按照一定的规律来进行调整以便满足新的客户和新的业务环境的要求。对于开发人员来说，流程的这种改变并不像他们改变数据库查询条件那么简单。相反的，这些改变可能是关于工作的顺序以及由谁来负责完成的变化。事实上，企业对流程的关注可以从市场上流程平台——BPM产品热度的上升可以看出。

　　BPM是业务（business）、流程 （process） 、管理 （management） 三个英文字母的首写字母的组合，但是对于不同的人来说却是意味着不同的内容。有些人认为BPM是一种纯粹的业务模式，是指企业把自己的业务围绕关键流程组织在一起。也有一些人则认为BPM是一种技术，一种可以为流程建模、自动化、管理和优化的软件技术。我们认为，BPM是这两种概念的集合体，而不是仅仅代表其中的一种意义。另外，BPM还代表了一种新的、可以产生满足企业“随需应变”的流程应用的方式，它让IT部门与企业的业务团队更加紧密的协作。而这一点正是众多的BPM成功的一个关键因素。同时，这也是我们很多人忽略的一个关键。

　　一些企业因为具有很有远见的领导或者是因为幸运，成功地实施了很多具有高价值同时又具有高度适应性的流程。而其它的一些企业在传统的IT模式下面进行BPM实施，只得到有限的成功或甚至失败。为了更好的理解这些挑战，我们需要进一步来探讨BPM技术。

　　BPM技术的核心是通过软件来管理企业的业务流程生命周期。它要求建立一个流程模式，通过这流程模式的实施，产生流程应用，使工作得以在系统和员工之间流转，并且通过这模式来管理运转中的流程应用，和在使用时对流程应用进行优化——无论是改善企业的核心流程或者是因业务条件变化做出调整。在流程生命周期的不同阶段，大部分的BPM解决方案都支持业务部门的参与，最普遍的就是它可以让业务部门开发出一个最初的流程模式，然后通过企业的IT部门来进行实施。

　　一些BPM系统能够把企业流程生命周期管理的能力从IT开发部门转移到业务部门的用户手上，使得业务部门变得更加敏捷。一个很好的例子就是规则，在企业的业务流程中，规则是最常用的手段，企业可以用它来管理任务的分配以及执行的顺序。有一些规则，企业会常常使用，也有一些规则只会在一些特别的环境中应用。但是，它们通常也会不断的变更。一般来说，这种改变可能会是很简单的，例如“为某一个特殊的客户省略这检查的步骤”。在变化的过程中有一个原则是不会改变的，导致规则变更的原因都是来自于业务的特殊需求，所以，让业务部门的员工在管理流程的变更上承担更多的职责，这对于企业的IT和业务来说都是非常有利的。

　　事实上，一个能支持对运营中的流程做职责分配的BPM系统， 为企业加强IT部门与业务部门的合作关系提供了很好的机会，可以加速流程实施、部署的速度，并且可以减少大量的开发要求，这些要求所导致的工作对于软件开发人员来说既不是一个挑战也不是一件激动人心的事情。但是要想很好地利用这种机会，关键在于理解企业业务流程的关键组成部分，企业需要确认适当的资源来管理那些关键组成部分，同时还需要组建一个由业务流程人员和IT专家们组成的BPM团队来贯彻执行。这些工作对于软件开发人员来说，他们可能不怎么感兴趣，但是如果分配给业务流程人员则可以大大增加业务的敏捷性。

　　另一方面，Web Services（面向网络服务）以及SOA（服务导向架构）的发展可以让企业的业务“随需应变”，但是如果IT开发人员仍必须不断地以改写代码的方式来处理流程的规则、角色以及基本步骤的定义等等，“随需应变”的目标是不可能达到的。如果真的是那样的话，企业的业务敏捷性就取决于系统开发人员“to-do ”的单子的长度了，清单越短，业务才会有越高的敏捷性。业务人员有能力对流程的一些部分进行控制，企业的业务流程才能获得更高的敏捷性，同时IT开发人员的“to-do”单子才能更创新和有趣。 总之，现在企业的IT部门面临着为业务的持续性变化提供支持的压力，而且这个压力越来越大。BPM技术可以给IT部门满足上述目标的能力，同时还可以改善IT部门与企业业务的关系。当我们评估BPM技术的时候，一个非常关键的考虑是BPM 系统对职责分配的支持能力，满足企业组建一个BPM团队，一个其成员具备各种各样的能力，包括IT开发人员、业务分析员和业务管理人员的BPM团队。而且一旦人员到位，到底确认谁对流程的哪些方面的贯彻实施和变革负责就应该成为一个纯粹的商业决策，取决于资源和目标，而不应该受到技术的限制（例如，业务部门应该管理规则，但是在现有的系统对规则做改变对业务部门人员来说是太困难了，所以还是由IT来管理规则吧）。那些在这样的共享模式下运营的企业已经看到了巨大的利益，包括提供高商业价值，减少定制开发；更快的响应业务的需求，降低流程部署的风险；并且在企业内部提升了IT部门的地位。