BPM 是與非 -- 什麼是BPM，如何辨別是否BPM產品，以及如何選擇BPM產品

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的應用架構（如WebSphere Application 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的（例如工做流、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 成功尚有至關的差距！！可能只是披了流程外殼的傳統信息化，或者新瓶裝舊酒的又一個OA、工做流系統而已。

做者簡介：

譚雲傑， 《大象-Thinking in UML》一書做者，BPM及面向對象分析設計方面的專家。經驗豐富的IT從業者，曾經擔任過項目經理、產品經理、系統分析師、架構師等職，擁有10多個項目分析、設計、管理經驗，對軟件領域有着全面和深入的理解。精通UML及建模方法，在需求管理、分析方法、軟件架構以及面向對象的分析和設計方面具備擁有10年的實踐經歷，有着深入的理解和獨到的認識。精通軟件工程和各類軟件方法，如RUP、敏捷方法等。精通項目管理，PMP證書得到者。

現就任於IBM從事BPM相關產品的研發工做，精通IBM業務流程管理（BPM）產品及其解決方案。