BPM方興未艾，然而眼見市場上BPM產品一片混亂，你方唱罷我上場，各色產品、各種概念粉墨登場。雖然百花齊放，但真正有志於實施BPM的客戶卻被這亂花迷了眼，實在搞不清楚BPM該怎麼去做，最終失去對BPM的信心和關注。這於BPM的發展並無益處。由是撰寫此文，從BPM的基本概念出發，講解了一些如何辨別和選擇BPM產品的建議。希望能爲BPM市場的進一步發展帶來一點幫助。
什麼是BPM
BPM（Business Process Management）其實並不是近期出現的新概念，從本質上說，BPM並不是一個IT術語，更不是因技術的發展而起源的，相反，BPM至始至終都是管理學術語和概念。BPM的核心是通過對企業運營的業務流程的梳理、改造、監控、優化來獲得利益的最大化。要達到這一目的，必須把企業資源和管理方法從縱向的戰略到業務的執行打通，使得企業業務流程當中每一個活動都能夠明確的指向特定的戰略目標並且可以測量和評估，從而獲得改進的方向；同時必須把企業資源和管理方法從橫向的各部門、職能甚至第三方職能整合爲一個有機的整體，使得企業業務流程可以以端到端的方式，即從業務目標的提出（業務流程建立）到業務執行結果（業務活動的測量），來管理企業的運營以獲得最大的利益。
而BPM軟件產品則是針對這種管理方式的一種構造工具——一種令人異常興奮的工具，可提供更快更好更便宜的解決方案。它致力於將IT 與業務之間的對話變成一種用於構建解決方案的交互式連續迭代方法。 BPM將IT會話轉變成業務語言——解決IT長期存在的一個問題：業務-IT之間的溝通障礙，幫助企業改進效率、使流程可視化、使流程敏捷化並幫助企業進行業務變革。
可見，BPM不是因爲IT技術而出現的，正相反，是因爲有了BPM這樣的管理理論，而企業又希望通過IT工具來幫助他們實施BPM管理，才相應的出現了BPM軟件。現在普遍的把BPM理解爲一個IT術語，更多的理解爲一類IT產品，這樣的理解是不全面的。在BPM裏，業務應當佔據主導地位，軟件或說技術是輔助地位。從業務上說，完整的BPM應該覆蓋企業戰略管理、戰略流程定義、業務構建、業務流程定義、業務服務定義和編排、業務執行和監控、業務流程優化改進以及戰略調整等等幾乎企業管理的方方面面。從IT角度說，BPM所集成的一系列軟件和專業技術要能夠支持上述的業務生命週期使之落地。最重要的是，這些軟件和專業技術必須是面向業務人員的。即，BPM的實施將由業務來驅動BPM的建設，由業務人員來主導整個業務流程管理體系的建立而不是由IT來驅動。
當前BPM市場和產品的混亂
與其它革命性的IT變革一樣，我們需要從方法、架構和實現技術三個方面去理解和掌握BPM產品。方法對應產品的設計目標——企業的管理理論和相應的實施方法論；架構表示軟件產品的設計如何匹配該設計目標；實現技術則表示採用何種IT技術去實現相應的架構設計。三者缺一不可，然而長久以來，人們習慣於用實現技術去分辨和解釋BPM，以至於到現在爲止，人們仍然無法正確的理解BPM。由此也造成了BPM市場和產品的混亂。
其實這個問題並不是BPM獨有的。舉例來說，作者在培訓面向對象的分析和設計方法時發現，相當大比例的程序員，哪怕他已經工作了很多年，哪怕他擁有豐富的項目經驗，也精通一門或多門面向對象的語言，但他們並沒有真正的掌握面向對象的方法。掌握面向對象方法的關鍵不在於是否採用了面向對象的語言和工具（如UML或java），也不在於是否掌握了面向對象的編程技巧（如設計模式），而是，你是否真的在用面向對象的思維去思考，從需求，到分析設計，到編碼實現。它體現在項目的整個過程而不是僅僅是結果的表象。
SOA也面臨同樣的問題。是否掌握了SOA，其關鍵不在於是否採用了支持SOA的應用架構（如WebSphereApplication Server），也不在於是否把某些代碼邏輯封裝成了符合SOA規範的服務（如Webservice）。而是，你是否真的採用面向服務的方法去分析需求、設計架構、抽取服務、把業務服務化，從項目開始到結束的整個過程都應該面向服務的，而不僅僅是產出物。
回到BPM產品上來，如果僅從實現技術去理解，人們就會陷入這樣的混亂： BPM與工作流有什麼差別？都有流程引擎，都可以自動化運行，都有流程編排器，也都能對流程進行監控。憑什麼工作流就不是BPM？如果辯解說BPM能比工作流能做更多的事，比如服務編排和集成，工作流會說只要是開放的通訊標準，不論是WebService還是JMS，工作流同樣可以集成第三方服務，BPM可以做的，工作流同樣可以做到，無非只是技術實現的方式不一樣而已，並不是本質的差別。你還可以爭辯說BPM是面向業務的，而工作流不是，但你如何解釋什麼是業務？難道BPM裏一個審批申請的活動是業務，工作流裏一個審批申請活動就不是業務？什麼道理？
同樣的混亂還有很多，例如ERP會爭辯說ERP也有其內部的工作流，也可以把客戶的業務流轉起來，ERP也是BPM；辦公協同類軟件也會爭辯說BPM不就是資源共享和工作協作麼？從這個角度說，我也是BPM，有何不可？
而客戶就更加混亂了。從通過流程來實現一項業務的實際需求出發，上述的任何一門技術似乎都可以實現他們的需求，怎麼選擇？何況凡是帶個流的，都說自己是BPM，似乎誰誰也差不到哪裏去。至於那些花了大價錢進行了流程梳理的企業，費了牛大的勁梳理出來的流程卻停留在Visio裏，寫在word文檔裏，有什麼用？以至於許多客戶最終消極起來：我只知道我得審批信用卡，我得處理投訴，只要管用好用就行，只要能解決我現在的問題，是不是BPM又有何妨，who care？
看，一旦陷入這樣的技術細節比較，就是比上個三天三夜，吵個天翻地覆也不會有結果，市場繼續混亂，產品繼續混亂，客戶繼續混亂……
甄別BPM產品應從方法和架構入手
要辨別一個產品是否是BPM產品，我們還是得回到方法和架構上來。正本清源，我們得承認這樣一個事實：業務驅動架構，架構驅動技術，而不是相反。判斷一個產品是不是真正的BPM，應該從源頭往下看，看它的設計目的是不是爲了解決業務流程管理，看它的架構是不是從業務流程管理方法論當中推導出來的，是不是符合業務流程管理方法規範，其針對的用戶是不是業務用戶。而不是看它是否包含了BPM的某些技術特徵，也不是看它是不是能做到一些BPM聲稱應該做到的事情。
一方面，技術的堆砌無法形成架構（技術架構必須指向特定的業務領域，解決特定的業務問題），拼湊出來的所謂架構也無法完整的解決業務問題。能夠做到某些事情並不表示它就是解決這類問題的恰當的工具！比如，扳手和錘子都可以用來砸釘子，但扳手本身不是錘子，它們被設計爲服務於不同的業務領域。另一方面，同樣的方法和架構允許不同的實現技術。例如，如果你的架構就是要解決砸釘子的業務問題，由於某種原因無法使用錘子，必要時，你可以把扳手集成進來，作爲一種可能的實現技術。
這表示了兩層含義。其一，某種技術手段的加入不能決定或改變產品所針對的業務領域，更不能改變產品的本質。上述例子中的架構是爲砸釘子設計的，其設計目標並不會因爲產品具備了板手的某些特徵就變成了修水管的工具。因爲扳手在這裏明確的指向砸釘子的業務問題，產品會忽略掉其它與砸釘子無關的扳手的其它特徵。其二，不能因爲某項技術最終解決了某個業務問題，就認爲該項技術就是針對該業務問題的正確工具。上述例子中，在解決砸釘子業務問題的工具裏，扳手是一種可能的實現辦法，但它仍然是扳手，不能夠說因爲扳手也可以砸釘子了，所以它根本就是錘子。
回到BPM上來，上述的例子想要表達的意思是：如果一個產品的設計理念和相應的架構不是針對BPM的（例如工作流、OA），即使其加入了符合BPM的某些技術實現特徵（例如流程監控、流程生命週期管理），它仍然不是一個BPM產品，它只是能夠額外做一些BPM所需的功能（上述例子中的扳手）而已；另一方面，如果一個產品的設計理念和相應的架構是針對BPM的，即使其加入了其它一些技術使得它能夠支持諸如工作流或OA的應用，它也不會因此就變成工作流或OA產品。它只是擴展了更多的支持而已。
有人要問，我爲何要如此糾結和矯情一個產品到底是不是真正的BPM呢？管它什麼產品，只要技術上能解決實際問題不就行了嗎？我要如此較真的原因在於，業務驅動架構，架構驅動技術，這是一套符合科學方法的體系：首先提出問題，然後分析問題，最後解決問題。從方法到架構到實現，它是一套自洽的、因果的、能自我發展完善的體系。隨着問題的深入和變化，整個體系也會隨之修改或者進化，但始終是一套完整的處於相應理論指導下的體系，直到該問題不再有價值時被拋棄或者被另一套更好的體系或理論所替代。在整個產品生命週期中，其目標始終清晰、體系始終完整、進化始終有序。所以，如果一個產品是真正的BPM，意味着該產品會隨着整個BPM理論和體系進化，獲得穩定的、可靠的升級和改進；而如果它只是披着BPM的馬甲，通過勉強的定製或拼湊某些技術手段去解決BPM的問題，則意味着該產品無法針對業務流程解決方案提供有效和持久的改進。因爲對一個軟件來說，如果一個軟件設計最初的目標與應用目標不符，而硬逼迫它往應用目標去變更和定製，該軟件必然變成打滿補丁的袍子和胡亂嫁接的內衣，總有一天它不但再也無法解決這些業務問題，恐怕連它的本職工作都無法再勝任了。
是，還是不是BPM，真的是問題的關鍵！自底向上的堆砌技術，隨波逐流的往架構上隨意嫁接技術，見風使舵的把產品改頭換面去製造與業務需求的匹配，終究不是長遠之計。
如何辨別一個產品是否BPM產品
由BPM的設計目標——業務流程管理決定，BPM不僅僅是一個IT工具，它必然要和企業運營緊密結合在一起，是企業管理運營的直接映射，而不需要等待把業務需求翻譯爲IT需求再用技術定製實現的週期。企業需要的是可以直接將業務變成可執行流程的技術，需要由業務人員直接建立、管理、優化流程，希望流程管理系統建設後可以直接在執行過程中監控企業績效，更希望企業的戰略意圖可以直接與具體的執行層聯繫起來。
要滿足這樣的需求，BPM工具必須徹頭徹尾的面向業務人員而不是IT人員，用業務語言去建模而不是IT語言，由業務人員驅動BPM的建設而不是IT驅動。換句話說，如果有一個所謂的BPM產品，但它被設計爲面向IT人員，靠IT人員定製開發而不是業務人員建模、其設計無法對接戰略層和執行層（最明顯的判斷是：是否能夠說明和測量流程中的某一個活動針對哪個戰略目標，某個實例貢獻值如何）；或者它被設計爲針對業務執行問題（需求從基層來）而不是業務管理本身問題（需求必須自頂向下）的，即可懷疑爲僞BPM或說是不完整的BPM。
最容易混淆的便是工作流與BPM，OA與BPM，ERP與BPM。首先，不論是OA還是工作流，其設計目標並不是管理業務而是通過IT手段協調和分配工作任務和資源，提升工作效率、優化資源利用率和工作規範化。其次，ERP是面向工作流的，它實現了信息的最小冗餘和最大共享，將企業內部所有資源整合在一起，對採購、生產、成本、庫存、分銷、運輸、財務、人力資源進行規劃，從而達到最佳資源組合，取得最佳效益。換言之，不論是OA也好，工作流也好，ERP也罷，它們都關注在執行層面。
一方面，其活動或操作的粒度是針對業務人員執行的具體工作任務，並不追究該工作任務與企業整體業務之間的橫向關聯和企業戰略目標之間的縱向關聯。其突出的特點是直接面對最爲具體的業務操作，但無法說明和測量該業務操作指向哪一個企業戰略目標，更無法衡量該業務操作向特定的企業價值貢獻了多少指標。其項目特點是不需要端到端的流程梳理（自頂向下定義，縱、橫向貫通）作爲必要的需求輸入，只需要某個局部的需求便可完成項目。
另一方面，其技術基礎針對的是IT人員，必須將流程的業務含義轉化爲IT含義，由IT人員進行建模和實施。其突出的特點是，在項目中，業務人員只能夠承擔需求提供者和軟件使用者這兩個角色，而無法承擔流程建模者、流程監控者、流程改進者、流程管理者等角色。
這些非針對BPM的設計帶來兩個明顯的侷限，其一，系統的建立儘管使得工作效率有所提高，但對於衡量企業的整體績效來說，每個這些系統內容是一個黑盒子，無法在執行過程中監控並得到企業整體績效乃至戰略的反饋；其二，由於架構和設計的方向不同，業務人員被排除在流程的建立、管理、監控、調整之外，必須通過IT人員來進行。這使得業務敏捷成了一句空話。
總結下來，辨別一個產品是否是真正的BPM產品，可以從以下幾個關鍵特徵出發：
1. 該產品是否有着極強的導向性à面向價值增值（戰略目標）而非僅僅實現當前業務。
此特徵意味着每個業務流程和每個活動都可以明確的指出其針對的戰略目標，並可以用指標衡量其價值貢獻（相對於戰略目標）。BPM的建設成功與否可以用企業最爲熟悉的商業價值評估體系來評判並優化調整。
如果一個所謂BPM產品不能夠直接實時的提供業務執行時對戰略目標的貢獻值，僅能夠提供IT級別的運行測量結果，或者只能通過滯後的報表統計，再通過諸如BI工具等來估算業務效益。它將無法支持BPM的面向價值。
2. 該產品是否以端到端的業務流程爲中心而非僅僅用於實現局部業務。
此特徵意味着流程梳理是BPM建設的前提條件。BPM實施的同時必然帶有流程梳理、測量、優化或改造等活動，基於片斷化的，侷限於部門內部的所謂BPM建設難以獲得BPM帶來的價值。
如果一個所謂的BPM產品從建模到實施到管理，僅需要或僅支持局部的業務需求，在必要時，只能通過其它技術手段（如WebService、JMS、Rest）來與其它部門或系統做散列的點狀集成，而不是像真正的BPM那樣需要端到端的流程梳理結果作爲必要條件，在業務流程建模過程中沒有所謂的“與其它集成”的明顯概念，所有活動都是端到端流程中一個自然的節點。那麼，它將無法支持BPM中的戰略落地。
3. 該產品是否由業務人員驅動而非IT驅動。
此特徵這意味着業務人員將從單一被動的需求提供者和業務流程執行者的角色增加爲更積極主動的業務流程構建者、業務流程監控者、業務優化者和業務流程管理者角色。業務人員和IT人員將密切配合起來。
如果一個所謂的BPM產品僅面向IT人員，業務人員不能深度參與業務流程建設，只能將業務需求翻譯爲IT語言再實現，那麼很難做到IT資產與真實業務流程的高度同步。該產品將無法支持BPM的業務監控、改進、優化等管理需求。
4. 該產品的流程實現是否支持粗粒度的服務編排而非從頭定製開發
此特徵意味着BPM產品必須支持通過編排粗粒度的服務集成並整合利用企業資產（包括IT和非IT），以快速、敏捷的建設和變更業務流程，從而有效支持業務敏捷和業務改造。
如果一個所謂的BPM產品在項目中需要大量的定製開發，其架構不支持服務編排或者只能通過外掛的標準協議調用服務而不是在架構內形成一個有機的整體，那麼它將無法支持業務敏捷和快速的業務改進。就目前的IT界的技術來看，產品是否全面支持SOA甚至直接架構在SOA上，是判斷是否符合此特徵的重要依據。
如何選擇BPM產品
真正的BPM需要提供面向業務人員的業務流程的建模語言、建模工具、管理工具和監控工具；需要屏蔽掉業務人員弄不懂的IT語言與實現；需要強大的集成能力可以貫通分散於各個業務部門各個平臺上的異構系統以實現企業整體業務流程管理和績效監控；還需要業務流程當中的活動可以與企業戰略掛鉤，使得業務流程的運行直接反饋戰略執行狀態。
因此，一個真正的BPM軟件要解決的是以下一些核心問題：
1. BPM與其他IT產品要麼支持業務用戶、要麼支持IT建設的不同之處在於，它必須橫跨業務和IT兩個部分，它必須很好的支持業務用戶採用業務語言來建設業務流程；同時它又必須能夠支持IT人員使用IT語言來整合IT資產以實現業務流程。這要求一個BPM產品必須同時具備業務設計能力與IT設計能力，並且能夠將兩種模型統一爲一個完整的模型；
2. 與以前純IT產品不同，企業的運營流程與BPM產品裏的資產應該是高度同步的，這些資產映射了真實的業務流程而不是需要翻譯的IT資產。當企業的業務變更發生時，這些變更不需要等待從業務翻譯爲IT資產的週期，而是由業務人員直接將其轉化成BPM資產，這些BPM資產則應快速響應業務變更。這要求一個BPM產品要能夠管理一個業務流程（BPM資產）從創建到測試、模擬、部署、運行、監控、改進、變更、升級、歸檔的整個生命週期；
3. 與單純的某一類專業IT產品（如生產、財務、客戶關係管理等）不同，BPM更注重於跨部門、跨IT系統、跨業務甚至跨組織的綜合業務需求。儘管它在解決企業應用架構中較低層次的執行問題方面也是利器，但BPM的更大的價值在於它能夠在整個企業應用架構中更高的層次上整合業務，能夠與企業戰略相結合。這要求一個BPM產品要能夠使用粗粒度的服務來快速構建應用程序而不是從頭開發。
4. BPM整合業務的需求使得BPM必須具備更強的擴展能力，能夠容納、擴展、整合各種各樣的企業應用，以BPM爲核心形成應用生態圈而不是僅僅是孤立的業務問題和流程問題。這要求一個BPM產品必須基於開放的標準和平臺，要能夠具備跨平臺、跨應用的整合能力，可以擴展和被擴展，以滿足企業各種各樣的業務需求和應用環境。
以上4個核心問題，同時也是對一個BPM產品對企業業務流程管理支持度的評判，企業可以從以上四個方面來評估一個BPM產品是否符合自身的需要。
但同時需要說明的是， 選擇BPM產品並不是一味的越大越全就越好。因爲BPM的實施是一個循序漸進的過程，它必須與企業當前的BPM成熟度、業務規模、人員素質等相匹配，同時也與BPM產品的本身的複雜度息息相關。顯然，一個剛剛接觸並開始採用BPM的企業，不可能完全掌握從戰略到執行的建模方法，不可能建立完善的從戰略目標到活動的指標體系，也無法在短時間內在管理上疏通各個業務職能部門。直接實施一個龐大的BPM計劃，引入一個全面但複雜的BPM產品，將會使企業充滿挫敗感：每走一步都極爲艱難，週期長，難見成效。許多邀請諮詢公司做了業務流程梳理但卻難以落地的企業對此應深有體會。
因此，在比較各BPM產品如何解決上述的核心問題之外，還需要看該BPM產品的複雜度和針對不同背景和需求的客戶的支持程度。其關鍵是兩個方面：
其一，一個BPM產品是否能夠支持並幫助企業循序漸進的小步快走，步步爲營，步步爲贏，在短時間內見成效。每建立一個業務流程都體現出應有的價值，幫助企業建立信心，找到適合自己的方法，鍛鍊業務流程管理能力，從而最終全面採用BPM。這要求一個BPM產品具備快速實施的能力，並且產品的複雜程度能夠針對不同客戶量身定製。一個實施過程複雜、無法按需求規模定製複雜度的產品，將會給BPM的實施帶來許多額外的困難。
其二，一個BPM產品是否能夠支持企業長期的、不斷深入的、擴展的業務需求。隨着企業使用BPM的成熟度提高，其需求也必將從簡單走向複雜、從表面走入深層、從一個業務領域擴展到另一個業務領域。這要求一個BPM產品具備完整的產品體系以及各產品模塊的靈活配置、擴展甚至即插即用的能力，以保證不斷擴展產品功能的同時維持BPM建設進程的穩定並且保護已有資產。不具備靈活的架構，只能通過定製開發來擴展功能的產品，將無法有效支持此需求。
BPM的實施能力也很重要
BPM的實施與傳統管理信息化項目不同，與ERP倒是有幾分相似：項目實施過程必然要依據對業務的深刻理解並伴隨着業務的改造、優化和調整等活動，而不僅僅是簡單的實現當前的業務。這要求實施團隊不僅僅要懂IT技術，更重要的是懂業務，要能夠跟業務人員在業務層面上進入深入的交流。最理想的BPM實施團隊要有業務流程梳理的知識與技能，有實施企業業務管理的經驗，能夠幫助客戶量身定製的尋找和定位業務價值、定義業務能力、端到端的建模業務流程並且能夠找出流程中的瓶頸並且與客戶一起尋找到適合該企業的優化的辦法。
再好的BPM產品交到只懂技術，持有技術至上觀點或者只會用IT思維去思考業務問題的團隊去實施，其結果必然會失敗。因爲BPM是業務驅動而非IT驅動的，成功的BPM絕不僅僅是幾個流程跑起來，解決了當前問題就完事。而是通過BPM的建設，從縱向打通企業自頂向下的價值實現過程（從戰略目標或業務價值到業務執行），從橫向建立價值實現能力（跨部門、跨業務的業務能力），從環向上建立業務績效評估（業務活動針對某業務價值的指標監控）體系，最後通過BPM產品的業務流程治理來不斷的優化上述的各個管理要點，從而不斷的提升企業的價值創造能力。這些實施目標與技術相關不大或說技術只是支持，與BPM實施團隊的業務理解能力、行業領域知識和行業管理諮詢經驗則是息息相關。
因此對有志於實施BPM的企業來說，除了關注BPM產品本身，還需要關注BPM實施團隊的業務能力和業務經驗，畢竟BPM絕不僅僅是一個IT級別的產品。從這一點來說，大、中型企業的業務往往錯綜複雜，規模也要大得多。要想成功實施BPM，與具有豐富業務經驗和行業管理諮詢能力的BPM產商合作是更好的選擇。不能夠在業務管理諮詢方面向客戶輸出行業成功經驗、業務領域模型和量身定製的優化建議的BPM實施，最終很可能成爲只是實現了局部的、片斷化的、僅僅實現了當前業務的所謂的BPM。這一結果距離真正的BPM成功尚有相當的差距。
譚雲傑， 《大象-Thinkingin UML》一書作者，BPM及面向對象分析設計方面的專家。經驗豐富的IT從業者，曾經擔任過項目經理、產品經理、系統分析師、架構師等職，擁有10多個項目分析、設計、管理經驗，對軟件領域有着全面和深刻的理解。精通UML及建模方法，在需求管理、分析方法、軟件架構以及面向對象的分析和設計方面具有擁有10年的實踐經歷，有着深刻的理解和獨到的認識。精通軟件工程和各種軟件方法，如RUP、敏捷方法等。精通項目管理，PMP證書獲得者。
現就職於IBM從事BPM相關產品的研發工作，精通IBM業務流程管理（BPM）產品及其解決方案。