BPM方興未艾，然而市場上BPM產品你方唱罷我上場，各色產品、各種概念粉墨登場。雖然百花齊放，但真正有志于實施BPM的客戶卻被這亂花迷了眼，實在搞不清楚BPM該怎么去做，最終失去對BPM的信心。這于BPM的發展并無益處。筆者由是撰寫此文，從BPM的基本概念出發，給出一些辨別和選擇BPM產品的建議。希望能為BPM市場的進一步發展帶來一點幫助。
現在一種普遍的理解，即把BPM理解為一個IT術語或一類IT產品，這是不全面的。在BPM中，業務應當占據主導地位，軟件或說技術占輔助地位。從業務角度說，完整的BPM應該覆蓋企業戰略管理、戰略流程定義、業務構建、業務流程定義、業務服務定義和編排、業務執行和監控、業務流程優化改進以及戰略調整等幾乎企業管理的方方面面。從IT角度說，BPM所集成的一系列軟件和專業技術要能夠支持上述的業務生命周期落地。最重要的是，這些軟件和專業技術必須是面向業務人員的，即要由業務來驅動BPM的建設，由業務人員來主導整個業務流程管理體系的建立，而不是由IT來驅動。
與其他革命性的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聲稱應該做到的事情。
一方面，技術的堆砌無法形成架構(技術架構必須指向特定的業務領域，解決特定的業務問題)，拼湊出來的所謂架構也無法完整的解決業務問題。能夠做到某些事情并不表示它就是解決這類問題的恰當的工具，比如，扳手和錘子都可以用來砸釘子，但扳手本身不是錘子，二者被設計服務于不同的業務領域。另一方面，同樣的方法和架構允許不同的實現技術。例如，如果你的架構就是要解決砸釘子的業務問題，由于某種原因無法使用錘子，必要時，你可以把扳手集成進來，作為一種可能的實現技術。
這有兩層含義。其一，某種技術手段的加入不能決定或改變其所針對的業務領域，更不能改變其本質。上述例子中，扳手是為砸釘子設計的，其設計目標并不會因為產品具備了扳手的某些特征就變成了修水管的工具。因為扳手在這里明確地指向砸釘子的業務問題，產品會忽略掉其他與砸釘子無關的扳手的其他特征。其二，不能因為某項技術最終解決了某個業務問題，就認為該項技術就是針對該業務問題的正確工具。上述例子中，在解決砸釘子業務問題的工具里，扳手是一種可能的實現辦法，但它仍然是扳手，不能夠說因為扳手也可以砸釘子了，所以它就是錘子。
我為何要如此糾結于一個產品到底是不是真正的BPM呢？只要能解決實際問題不就行了嗎？我要如此較真的原因在于，業務驅動架構，架構驅動技術，這是一套符合科學方法的體系:首先提出問題，然后分析問題，最后解決問題。從方法到架構到實現，它是一套自洽的、能自我發展完善的體系。隨著問題的深入和變化，整個體系也會隨之修改或者進化，但始終是一套完整的處于相應理論指導下的體系，直到該問題不再有價值時被拋棄或者被另一套更好的體系或理論所替代。在整個產品生命周期中，其目標始終清晰、體系始終完整、進化始終有序。所以，如果它是真正的BPM，意味著該產品會隨著整個BPM理論和體系進化，獲得穩定的、可靠的升級和改進;如果它只是披著BPM的馬甲，通過勉強的改造或挪用某些技術手段去解決BPM的問題，則意味著該產品無法針對業務流程解決方案提供有效和持久的改進。因為對一個軟件來說，如果一個軟件設計的最初目標與應用目標不符，而硬逼迫它往應用目標變更和定制，該軟件必然變成打滿補丁的袍子，總有一天它不但再也無法解決這些業務問題，恐怕連它的本職工作都無法再勝任了。
是，還是不是BPM，真的是問題的關鍵！
BPM的設計目標決定，BPM是一個IT工具，必須要和企業運營緊密結合在一起，是企業管理運營的直接映射。企業需要的是可以直接將業務變成可執行流程的技術，需要由業務人員直接建立、管理、優化流程，希望流程管理系統建設后可以直接在執行過程中監控企業績效，更希望企業的戰略意圖可以直接與具體的執行層聯系起來。
要滿足這樣的需求，BPM工具必須徹頭徹尾地面向業務人員而不是IT人員，用業務語言去建模而不是IT語言，由業務人員驅動BPM的建設而不是IT驅動。換句話說，如果有一個所謂的BPM產品，它被設計為面向IT人員，靠IT人員定制開發而不是業務人員建模，它的設計無法對接企業戰略和執行層面(是否對接戰略和執行的簡單判斷標準是，是否能夠說明和測量流程中的某一個活動針對哪個戰略目標，某個實例貢獻值如何)，它的設計是針對業務執行問題(需求從基層來)而不是業務管理本身問題(需求必須自頂向下)的，即可懷疑為偽BPM或說是不完整的BPM。最容易混淆的便是工作流與BPM、OA與BPM、ERP與BPM。
非針對BPM的設計帶來兩個明顯的局限，其一，系統的建立盡管使得工作效率有所提高，但對于衡量企業的整體績效來說，這些系統內容是一個黑盒子，無法在執行過程中監控并得到企業整體績效乃至戰略的反饋;其二，由于架構和設計的方向不同，業務人員被排除在流程的建立、管理、監控、調整之外，必須通過IT人員來進行。這使得業務敏捷成了一句空話。
總結下來，辨別一個產品是否是真正的BPM產品，可以從以下幾個關鍵特征出發:
1.該產品是否具有極強的導向性，面向價值增值(戰略目標)而非僅僅實現當前業務。
此特征意味著每個業務流程和每個活動都可以明確地指出其針對的戰略目標，并可以用指標衡量其價值貢獻(相對于戰略目標)。BPM的建設成功與否可以用企業最為熟悉的商業價值評估體系來評判并優化調整。
如果一個所謂BPM產品不能夠直接實時地提供業務執行時對戰略目標的貢獻值，僅能夠提供IT級別的運行測量結果，或者只能通過滯后的報表統計，再通過諸如BI工具等來估算業務效益。它將無法支持BPM的價值。
2.該產品是否以端到端的業務流程為中心而非僅僅用于實現局部業務。
此特征意味著流程梳理是BPM建設的前提條件。BPM實施的同時必然帶有流程梳理、測量、優化或改造等活動，基于片斷化的、局限于部門內部的所謂BPM建設難以獲得BPM帶來的價值。
如果一個所謂的BPM產品從建模到實施到管理，僅需要或僅支持局部的業務需求，在必要時，只能通過其他技術手段(如WebService、JMS、Rest)來與其他部門或系統做散列的點狀集成，而不是像真正的BPM那樣需要端到端的流程梳理結果作為必要條件，在建模過程中沒有所謂的“與其他集成”的概念，所有活動都是端到端流程中一個自然的節點。那么，它將無法支持BPM中的戰略落地。
3.該產品是否由業務人員驅動而非IT驅動。
此特征意味著業務人員的角色將不只是單一被動的需求提供者和業務流程執行者，還將是更積極主動的業務流程構建者、業務流程監控者、業務優化者和業務流程管理者角色。
如果一個所謂的BPM產品僅面向IT人員，業務人員不能深度參與業務流程建設，只能將業務需求翻譯為IT語言再實現，那么很難做到IT資產與真實業務流程的高度同步。該產品將無法支持BPM的業務監控、改進、優化等管理需求。
此特征意味著BPM產品必須支持通過編排粗粒度的服務集成并整合利用企業資產(包括IT和非IT)，以快速、敏捷的建設和變更業務流程，從而有效支持業務敏捷和業務改造。
如果一個所謂的BPM產品在項目中需要大量的定制開發，其架構不支持服務編排或者只能通過外掛的標準協議調用服務而不是架構的一個有機整體，那么它將無法支持業務敏捷和快速的業務改進。就目前IT界的技術來看，產品是否全面支持SOA甚至直接架構在SOA上，是判斷是否符合此特征的重要依據。
真正的BPM需要提供面向業務人員的業務流程的建模語言、建模工具、管理工具和監控工具;需要屏蔽掉業務人員弄不懂的IT語言與實現;需要強大的集成能力可以貫通分散于各個業務部門各個平臺上的異構系統以實現企業整體業務流程管理和績效監控;還需要業務流程當中的活動可以與企業戰略掛鉤，使得業務流程的運行直接反饋戰略執行狀態。
因此，一個真正的BPM軟件要解決的是以下一些核心問題:
1.BPM必須橫跨業務和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產品是否符合自身的需要。
同時，BPM的實施是一個循序漸進的過程，它必須與企業當前的BPM成熟度、業務規模、人員素質等相匹配，同時也與BPM產品的復雜度息息相關。顯然，一個剛剛接觸并開始采用BPM的企業，不可能掌握從戰略到執行的方法，不可能建立完善的從戰略目標到活動的指標體系，也無法在短時間內在管理上疏通各個業務職能部門。直接實施一個龐大的BPM計劃，引入一個復雜的BPM產品，將會使企業充滿挫敗感:每走一步都極為艱難，周期長，難見成效。許多邀請咨詢公司做了業務流程梳理但卻難以落地的企業對此應深有體會。
AlphaFlow BPM流程管理平臺
電話：400-888-6861
//qdhaitiansuji.cn/
