在過去這兩、三年推廣BPM的過程中，我們感受到不論是客戶或者是友商都極力在推廣企業流程管理(Business Process Manager；BPM)以取代傳統的工作流程(Workflow)，但到底什麼是BPM與傳統的Workflow有什麼不同則是我們常常被客戶提出的質疑，也常收到一些客戶或者是一些專業媒體的BPM功能調查表(Survey Form)，但是觀察其內容多半是傳統Workflow的功能，如能不能動態加簽、能不能跳關……等等的功能描述，加上有沒有支援Web Service、有多少的系統整合配接器(Adaptor)，這些功能當然是BPM應該要有的功能，可是難道Workflow 或傳統程式就作不到嗎?
市場對Workflow的迷思
- BPMS 只不過是Workflow 廠商的舊瓶裝新酒
- WorkFlow加上系統整合的Adaptors就變成BPMS
- EAI廠商加上Activity Modeling的工具或者是Routing Engine重新包裝一下，也可以稱作BPMS
- BPM 是不是等於 Workflow+EAI
正因為這樣的迷思，某些產品宣稱，傳統的Workflow 是一張表單的流程，而只要可以整合流程中的多張表單，例如請購、採構、驗收、付款，這些表單的流程能夠串連起來，就是一個BPM的系統。
有些使用者會說程式沒有作不到的，基本上這句話是對的，因此我們可以說就功能面來看BPM 可以有的功能，Workflow 也都可以作到，但是重點在於要達成這樣的功能，需要花多少的成本、多少的時間，更何況BPM對一個企業在價值面的功能是傳統應用程式或Workflow所無法作到的。
我們也常接觸一些曾經用過Workflow 的客戶，想要找一套BPM但又怕買到一套Workflow，因此我們也試圖建立一個BPM應該具備的功能的功能查檢表，協助資訊單位的同仁，找到適合自己的解決方案，在查檢表中並非每個項目都是必備的，端看企業本身是否有此種需求。
在BPM的導入精神中，希望讓流程設計的工作讓Business User 也能參與流程的規劃，因此常常會有Business User 質疑是否可以達成，在現階段也許還無法實現，但是至少以目前BPM的開發模式可以讓IT主管人員系統析人員掌握流程的主導權，程式開發人員開發流程元件，系統分析師組合流程元件，變成一個可以執行的流程，在這理我要強調的是所謂的流程元件並不是一個程式碼或執行檔，而是一個以經將其轉化為視覺上的可看的到的圖形，可以用拖放的方式組合。
由Business User 來設計流程這樣的概念，我們相信在不遠的未來應該可以逐步達成，以軟體架構的發展趨勢來看，由早期的集中式的架構，到後來個人電腦的興起，因此有了Client-Server的架構，但是由於前端的個人電腦必需逐一安裝，最後演進到Web 化的架構，我們深信流程的開發也會循這種模式演進，早期的流程設計都是由企業內部的IT部門執行，但因為電腦化的程度越來越高，應用系統維護的責任也越重，IT部門已無餘力開發新的應用系統，因此在很多大企業中，事業單位或部門也開始召募IT的人員，開發自己所需要的功能，以滿足內部的需求，卻也造成企業內部資訊系統的混亂，因此我們認為唯有BPM的開發模式可以解決這個困擾，也就是企業的IT部門提供應用系統的服務，或作成所謂的流程元件，事業單位的IT人員不再負責元件的開發，而是運用IT部門提供的元件，組合流程，如此可達成權責的分工，又能達成業務上多變的需求。
最重要的我們也試圖導入一個在國外已經逐建成形，國內尚未有很多的討論的新一代軟體開發的概念 BPM-Enable 的應用系統，BPM-Enable 的應用系統是利用BPM的概念或平台來開發傳統的應用系統，此項概念有助於釐清BPM與Workflow間的差異，取而代之的是BPM-Enable 的應用系統與Workflow 間的差異，相信一定更有助於讀者的理解，進而將BPM的開發模式導入企業中。
IT的投資是長遠的，花錢導入一個解決方案很容易，但一旦導入要再退出是很困難的，因此在評估解決方案的同時不應只看到眼前的功能，而更應該考慮未來的擴充性與延展性。
IT 技術發展的演進
流程管理技術演進
自1990年開始，應用系統內部針對系統內部的需求漸漸導入工作流程的概念，但此時的工作流程通常是應用於單一系統內部，因為沒有一致性的標準，因此各應用系統都是使用各自特有的流程描述方式，多半是以程式碼的方式表示，處理的對像亦以應用系統內部為主，無法跨應用系統。
1990年末期Internet 興起後，各系統間的整合需求日益迫切，因此系統與系統間因為無法直接整合，因此大多數的整合是透過資料檔案的方式整合,但因各系統間資料格式的不一致，因此也導致EAI (Enterprise Application Integration)的盛行， 各系統間的資料交換採用格式定義的方式，但因為各系統間並無一致規劃的規範，因此系統間的轉換還是需要一對一的資料源格式對應(Mapping)，如果整合的系統很多時會造成系統的複雜度提高，因為各系統間是以矩陣的方式銜接。
因為各系統間以API或資料交換的整合，造成系統間連結的複雜度很高，因此2001年開始導入BPM企業流程管理的概念，利用BPM的觀念可以讓應用系統間以Process 的方式整合，各應用系統以介面的元件的方式整合，其優點為兩個應用系統間不會直接連結，而是透過流程管理平台整合，可大幅降低整合的複雜度，當其中一個系統改變，只需修改其相關的介面元件即可。
流程管理架構演進
早期的工作流程通常是採用程式碼的方式表示，將使用著介面、處理的邏輯及系統整合的程式碼都包含在程式碼中。
在第二代的工作流程是以程式碼的方式來描述使用者的面，軟體開發的人員以程式碼的方式描述作業流程，因此每次的流程變更都需要透過IT的人員。
在第三代的流程管理系統(BPM)中，使用者的介面、處理的邏輯、系統整合的程式碼都是獨立的元件，流程的描述是以描述性的語言如XML的方式標示，因此透過一個視覺化的工具來描述作業的流程，因此流程的管理可以由Business User來管理。
企業流程演進未來驅勢
依據Gartner 在2005年間的未來IT 發展驅勢的報告，將企業流程的整合分為三個階段
- 1998 年以前，多是採用功能導向的應用系統，系統與系統間的整合，採用應用系統與人工作交互的模式。
- 2005-6 年作業驅勢逐漸改採系統間串連方式，以Web-Enabled及服務導向的方式整合作業流程，企業流程管理平台的導入讓系統與系統間的接口整合起來。
- 2008年開始，應用系統逐步趨向企業流程的完全整合，並因為各系統間逐步採用SOA的架構，因此對外提供的皆為各種服務的接口，因此各應用系統間的界限變的相對的模糊，因此企業的流程，各種活動(Activity)間可採用各種處理的彈性流程，以達到最佳的效率與彈性。
為了配合未來企業流程的改變，應用系統在開發時不應以單一系統來考量，而應以系統所提供的服務為設計的出發點，並且需逐步導入企業流程管理的平台，作為各服務間整合的架構。
