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，真的是問題的關鍵！自底向上的堆砌技術，隨波逐流的往架構上隨意嫁接技術，見風使舵的把產品改頭換面去製造與業務需求的匹配，終究不是長遠之計。
以下文章點擊率最高
Loading…