有些人認為BPM是一種純粹的業務模式，是指企業把自己的業務圍繞關鍵流程組織在一起。也有一些人則認為BPM是一種技術，一種可以為流程建模、自動化、管理和優化的軟件技術。我們認為，BPM是這兩種概念的集合體，而不是僅僅代表其中的一種意義。

信息技術發展至今，企業的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部門的地位。