新管理
作者：譚雲傑
判斷一個產品是不是真正的BPM，應該從源頭往下看，看它的設計目的是不是為了解決業務流程管理，看它的架構是不是從業務流程管理方法論當中推導出來的，是不是符合業務流程管理方法規範，其針對的用戶是不是業務用戶。
BPM（Business Process Management）方興未艾，然而市場上BPM產品你方唱罷我上場，各色產品、各種概念粉墨登場。雖然百花齊放，但真正有誌於實施BPM的客戶卻被這亂花迷了眼，實在搞不清楚BPM該怎麼去做，最終失去對BPM的信心。這於BPM的發展並無益處。筆者由是撰寫此文，從BPM的基本概念出發，給出一些辨別和選擇BPM產品的建議。希望能為BPM市場的進一步發展帶來一點幫助。
現在一種普遍的理解，即把BPM理解為一個IT術語或一類IT產品，這是不全麵的。在BPM中，業務應當占據主導地位，軟件或說技術占輔助地位。從業務角度說，完整的BPM應該覆蓋企業戰略管理、戰略流程定義、業務構建、業務流程定義、業務服務定義和編排、業務執行和監控、業務流程優化改進以及戰略調整等幾乎企業管理的方方麵麵。從IT角度說，BPM所集成的一係列軟件和專業技術要能夠支持上述的業務生命周期落地。最重要的是，這些軟件和專業技術必須是麵向業務人員的，即要由業務來驅動BPM的建設，由業務人員來主導整個業務流程管理體係的建立，而不是由IT來驅動。
BPM市場和產品的混亂
與其他革命性的IT變革一樣，我們需要從方法、架構和實現技術三個方麵去理解和掌握BPM產品。
方法對應產品的設計目標——企業的管理理論和相應的實施方法論，架構意味著對軟件產品的設計如何匹配設計目標，實現技術則意味著采用何種IT技術去實現相應的設計目標。三者缺一不可，然而長久以來，人們習慣於用實現技術去分辨和解釋BPM，以至於到現在為止，人們仍然無法正確理解BPM。由此也造成了BPM市場和產品的混亂。
其實這個問題並不是BPM獨有的。舉例來說，筆者在培訓麵向對象的分析和設計方法時發現，相當大比例的程序員，即使他已經工作了很多年，即使他擁有豐富的項目經驗，同時也精通一門或多門麵向對象的語言，但實際上他們卻沒有真正地掌握麵向對象的方法。掌握麵向對象方法的關鍵不在於是否采用了麵向對象的語言和工具（如UML），也不在於是否掌握了麵向對象的編程技巧（如設計模式），而是從需求到分析設計，再到編碼實現，你是否真的在用麵向對象的思維去思考。
SOA也麵臨同樣的問題。是否掌握了SOA，其關鍵不在於是否采用了支持SOA的應用架構（如WebSphere Application Server），也不在於是否把某些代碼邏輯封裝成了符合SOA規範的服務（如Webservice），而是，你是否真的采用麵向服務的方法去分析需求、設計架構、抽取服務，把業務服務化。從項目開始到結束的整個過程都應該是麵向服務的，而不僅僅是針對產出物的。
回到BPM產品上來，如果僅從實現技術去理解，人們就會陷入這樣的混亂： BPM與工作流有什麼差別？都有流程引擎，都可以自動化運行，都有流程編排器，也都能對流程進行監控。憑什麼工作流就不是BPM？如果辯解說BPM比工作流能做更多的事，比如服務編排和集成，那麼也可以辯解說隻要是開放的通信標準，不論是WebService還是JMS，工作流同樣可以集成第三方服務，BPM可以做的，工作流同樣可以做到，無非隻是技術實現的方式不一樣而已，並沒有本質的差別。你還可以爭辯說BPM是麵向業務的，而工作流不是，但你如何解釋什麼是業務？難道BPM裏一個審批申請的活動是業務，工作流裏一個審批申請活動就不是業務？什麼道理？
看，一旦陷入這樣的技術細節比較，就是比上個三天三夜，吵個天翻地覆也不會有結果。
從方法和架構入手
要辨別一個產品是否是BPM產品，我們還是得回到方法和架構上來。我們得承認這樣一個事實：業務驅動架構，架構驅動技術，而不是相反。判斷一個產品是不是真正的BPM，應該從源頭往下看，看它的設計目的是不是為了解決業務流程管理，看它的架構是不是從業務流程管理方法論當中推導出來的，是不是符合業務流程管理方法規範，其針對的用戶是不是業務用戶。而不是看它是否包含了BPM的某些技術特征，也不是看它是不是能做到一些BPM聲稱應該做到的事情。
一方麵，技術的堆砌無法形成架構（技術架構必須指向特定的業務領域，解決特定的業務問題），拚湊出來的所謂架構也無法完整的解決業務問題。能夠做到某些事情並不表示它就是解決這類問題的恰當的工具，比如，扳手和錘子都可以用來砸釘子，但扳手本身不是錘子，二者被設計服務於不同的業務領域。另一方麵，同樣的方法和架構允許不同的實現技術。例如，如果你的架構就是要解決砸釘子的業務問題，由於某種原因無法使用錘子，必要時，你可以把扳手集成進來，作為一種可能的實現技術。