作者：人月神話，新浪博客同名

簡介：多年SOA規劃建設，私有云PaaS平臺架構設計經驗，長期從事一線項目實踐

今天準備談下BPM業務流程管理系統的建設和實施方面的內容。首先還是從BPM的基礎概念入手進行介紹，然后重點解釋下BPM和工作流引擎的區別，最好談下BPM軟件的應用和實施場景。

BPM業務流程管理概述

業務流程管理是將生產流程、業務流程、各類行政申請流程、財務審批流程、人事處理流程、質量控制及客服流程等70%以上需要兩人以上協作實施的任務全部或部分由計算機處理，并使其簡單化、自動化的業務過程。

20世紀90年代，Michael Hammer和James Champy的成名之作《公司再造》（Reengineering the Corporation）一書在全美公司領域引發了一股有關業務流程改進的洶涌浪潮。這兩位管理學宗師在書中展示了這樣一個觀點——重新設計公司的流程、結構和文化能夠帶來績效上的顯著提高。但是由于缺少對變革管理以及員工變革主動性的關注，在很多致力于把他們的理論付諸實踐的公司身上產生了反作用的結果。

而如今，公司再次把業務流程管理——這種通過分析、建模和監控持續優化業務流程的實踐，當作一種解決業務難題和幫助公司實現自己財務目標的系統方法。

業務流程管理（Business Process Management, BPM）不是一個新概念，甚至不是一個新名詞。它是從相關的業務流程變革領域，如業務流程改進（BPI）、業務流程重組（BPR）、業務流程革新中發展起來的。流程管理技術也是從早期的工作流管理、EAI、流程自動化、流程集成、流程建模、流程優化等技術中發展起來的。

從管理理論或戰略的層面看，業務流程管理（BPM）就是在一個存在內部事件和外部事件的環境中，由一組相互依賴的業務流程出發，對業務進行描述、理解、表示、組織和維護。從具體實施的層面看，BPM 還可分為流程分析、流程定義與重定義、資源分配、時間安排、流程管理、流程質量與效率測評、流程優化等。

Gartner Inc．給出的BPM的定義是：BPM是一個描述一組服務和工具的一般名詞，這些服務和工具為顯式的流程管理(如流程的分析、定義、執行、監視和管理)提供支持。

業務流程管理是跨業務組織結構，跨業務系統，跨應用的軟件和方法論,從而實現自動化管理,優化動態業務,產生真正的業務價值。更多體現的是跨業務域，端到端業務流程的管理和整合。

BPM和HWF人工工作流引擎

企業信息系統構建本身就應該遵循流程分析，業務建模，子系統劃分，系統功能建模的逐步分解過程。由于企業內職能部門的劃分，而業務系統往往又需要一個歸宿的主導部門，在企業發展大后一個業務系統也很難完全支撐到企業所有業務流程和業務活動。因此不可避免的導致了企業在各個業務域衍生了多個業務系統，業務系統主要實現價值鏈的一個核心業務域，但是業務系統必須要整合和集成才能夠滿足端到端流程的整合。

端到端流程整合出現斷點或流程不暢通，一方面是業務系統本身的分解有問題，一方面則是業務系統之間集成有問題，業務部門各自為陣導致了系統集成這種中間地點沒有一個主導部門去管理和負責。業務系統本身分解問題主要體現在沒有一開始就從企業架構和應用架構出發來考慮業務系統建設，業務系統建設不是從上向下的，而是完全根據業務部門需求各自建立。系統間集成問題則主要體現在了完全不考慮集成的標準規范，集成的方式，集成本身的可復用性，導致大量重復建設。

流程建模遵循高端建模逐層分解的思路，高端流程往往正是我們關注的業務流程，高端流程跨越了多個業務域，多個業務活動，多個業務對象和單據實體，最終完成了一個端到端業務。如供應鏈端到端，涉及到采購需求，采購計劃，采購策略和實施，采購訂單，采購執行諸多環節和業務對象。高端業務流程中采購訂單生成只是一個業務活動或子流程，而采購訂單制作和生成本身又需要根據訂單類型或金額設計不同的審批流程，而采購訂單擬制后的審批流程才是我們經常所說的工作流，人工工作流或審批流。

那么從這個意義上很容易看到業務流和工作流的區別如下:

• 業務流往往會跨多個業務系統，而審批流往往主要涉及到一個系統。
• 業務流會涉及到多個業務功能，多個業務對象，而審批流往往只涉及到一個業務對象。
• 業務流涉及到的是不同業務單據之間的流轉，而審批流往往是同一業務單據狀態的變化。
• 業務流中既包括了人工活動也包括了自動的業務活動，而審批流一般為人工審批活動。

而對于BPM業務流程管理系統和工作流管理系統，可以再進行下分析。我們看到現在很多BPM軟件也從工作流管理軟件發展而來。不論是哪種，基本都包括了流程建模，流程執行，流程監控，流程分析等基本功能，也包括了表單建模和數據建模，權限管理等擴展功能。

可以講一個完整的系統基本上可以實現簡單的以審批流為主的簡單業務功能模塊的配置化開發。通過表單設計工具制定一個表單界面，綁定數據對象，掛接上自定義的流程模板，一個功能即開發完成，只要沒有太多復雜的業務規則，基本上完全可以通過配置實現，這也是這類工具可以在類OA應用中大規模使用的原因。

對于流程建模，BPM關注的是業務流程建模，基于BPMN或BPEL進行，而工作流軟件關注的是審批流建模。BPM建模需要考慮業務人員對建模需求和可用性，但是不可避免又導致建模的內容無法很好的落地。而工作流建模本身已經細化到一個功能模塊中的審批流，相對來說簡單很多而容易實施執行。

BPM業務流程往往跨越了業務系統，跨越了多個業務單據，需要處理不同的業務規則和邏輯。而工作流軟件活動節點往往僅僅處理審批和會簽任務，和外界交互相對較少。而BPM業務流程中由于存在業務活動和業務規則，而這些又需要外界提供數據支持，因此不可避免的在BPM流程建模中需要通過SOA服務方式調用各種可復用的服務來處理和轉換數據。

工作流軟件發展到今天，我們看到也可以在表單建模，工作流設計過程中調用外部的SOA服務，這是一個很好的進步，使工作流軟件不僅僅能夠簡單進行審批處理還能夠增加較為復雜的業務規則判斷。

業務流程建模中會出現業務規則，常規的工作流軟件處理方式一般支持腳本代碼進行簡單業務規則的處理，而發展到BPM后為了保證規則本身的復用性和獨立維護性，引入了規則引擎，規則引擎形成統一的規則創建和維護庫，BPM本身不再負責規則的創建和維護，而僅僅是按需消費。這個分離本身意義也很重大，要知道業務規則又明確的業務系統開發商和業務主管部門，放到BPM系統中通過定制方式管理規則顯然是很困難的。

傳統的軟件工程方法從業務流程分析到形成子系統和功能模塊，有一系列的分析和設計過程，最終形成各個功能模塊和協同應用。而BPM系統試圖通過簡單的業務流程建模和BPMN就能完成一個復雜業務流程到功能模塊的轉化，這是一個相當困難的事情。雖然BPMN2.0使這種轉化成為了可能，但是要看到對于跨系統，跨多個業務對象實體的長流程，BPM系統可以進行流程建模和設計，但是很難直接轉化為可實現的模型。這是到現在BPM系統也很難去解決的問題，如果該問題沒有解決，BPM系統又淪落為一個業務人員建模的工具而已，BPM和實際的業務系統仍然是脫節的。

BPM重點是流程整合，而流程整合是多個業務系統中多個業務功能模塊之間的協同，如果一開始想用BPM去實現這些業務功能，那么往往是適得其反，BPM切入的第一步仍然是在于跨業務系統的流程集成，而流程集成重點又在于流程間的數據傳遞。知道這個重點后BPM的關注點應該放到流程協同和監控上，而子流程或某個獨立的業務模塊實現仍然在原有的業務系統中，通過端到端流程整合實現了業務模塊之間的系統，這個一方面最大限度的利用了已有的IT資產，又實現了流程整合的需求。

業務流程整合一定是涉及到自動化的業務流和人工工作流，原有的BPEL很難融入HWF導致BPEL只能應用到流程整合的一些點上而無法真正實現理想狀態下的流程編排，最多算上服務編排。而引入人工工作流使BPM有了做端到端流程整合的能力，但是已有業務系統已經有工作流引擎或審批流實現，要完全拋棄已有的流程引擎又是一個很麻煩的事情。

那是BPM來整合已有的流程引擎，還是流程引擎引入BPM的關鍵要素又成為一個需要考慮的問題。BPM之所以困難，不在于思路上，而在于實踐和落地上，如果是全新構建業務系統還好辦，特別是已有業務系統的IT環境改造。即使實現了流程整合，那么流程整合后的認責部門是誰？流程整合后對已有業務系統有哪些影響都需要考慮，而不是簡單的想流程整合后放到門戶系統了事。

HWF人工工作流引擎

在這里先談下我們常說的人工工作流引擎，這個其實是現在大多數應用系統都必須具備的基本業務管理功能。正是由于每個系統都需要該功能，那么每個系統如果都單獨建設必然帶來重復的成本投入，同時帶來了各個業務系統間的工作流交互標準語言不統一。

在談企業私有云PaaS平臺建設的時候我們談到了，基于平臺 應用的構建思路，企業流程平臺作為底層技術平臺統一建設。

企業內部的統一流程平臺建設，不僅僅是功能的遷移，更加重要的是數據的遷移，對于流程來講我們所說的數據即是流程建模數據和流程執行數據的遷移。在統一流程建模和統一流程執行的基礎上，提供統一的流程監控和流程績效管理。

很早我們就在談流程不能脫離組織，崗位角色，權限等基礎而存在。進行組織，人員，崗位權限等基礎主數據的管理和整合又是建立內部統一流程平臺的基礎。因此我們可以看到內部的主數據管理，組織引擎和權限引擎等內容。這些都是為流程平臺做準備。

流程建模全統一在統一流程平臺進行，因此BPM需要有統一的組織，人員和權限數據，這是各個系統能夠完全互通的基礎。在流程建模的時候，不僅僅涉及到常用工作流模型中的串行，并行，條件分支，聚合，子流程，回退等基本流程功能。更加重要的我認為還是流程活動節點和組織權限內容的結合，否則流程很難適應組織權限調整帶來的影響和變化。

粗一點的流程建模可以只控制到表單級權限，而細化點的流程建模則可以控制到表單輸入的每一個數據項的權限。流程活動節點往往很多時候都具有條件判斷，條件判斷往往又涉及到外部調用，因此流程活動節點支持腳本代碼的編寫，支持對外部接口和服務的調用又是最基本的功能。

工作流產品本身的設計包括了靜態數據建模和動態數據建模兩方面的內容。涉及到流程模板，活動節點，連接弧，分支判斷，流程圖形化展示元數據等多個方面的內容。動態數據建模又涉及到流程執行實例數據的記錄，這方面的內容后續單獨描述。

統一流程平臺需要實現的就是統一流程建模，統一執行和統一監控，只要是涉及到流程建模和執行的數據都不在原有的各個業務系統中，而是全部集中到統一流程管理平臺進行管理。按這個思路自然帶來新問題即BPM系統如何與原有的業務系統集成。

業務系統和BPM的集成最佳的效果就是對于用戶感受不到BPM系統的存在，不能因為系統內的集中化和云化帶來用戶使用上面的差異。簡單點的描述，使用具體包括如下幾個方面的內容：

1.各業務系統單獨的多租戶賬號登錄BPM系統，進行系統流程建模，BPM系統已有在各個業務系統完全統一的組織，用戶和權限數據。這個不統一BPM系統無法真正落地。

2.在流程建模完成后，對于每次流程建模系統會建立單獨的流程模板ID供業務系統使用。

3.業務系統各業務表單使用統一的流程啟動接口調用BPM系統提供的服務啟動工作流。

4.BPM系統中的流程待辦，流程已辦，流程處理等各個關鍵業務功能用UI組件的方式形成UI組件后內嵌到各個業務系統中使用。在這里又需要企業內業務系統間實現統一認證和SSO單獨登錄。

5.BPM系統提供流程執行，流程監控，流程查詢等多個服務接口供業務系統使用。

統一流程平臺首先要實現的是替代原有業務系統內的人工工作流引擎，實現流程的統一管理，同時在組織，用戶和權限集中的基礎上，形成系統基礎管理，權限管理和流程管理的通用語言。

這樣就很容易過渡到跨系統間的流程整合，在這種情況下的跨系統流程整合只需要再考慮如何與標準的BPEL進行集成，使流程整合即具備人工審批流節點，又具備根據業務規則自動進行處理和流轉的自動化業務節點。

基于工作流引擎的接口服務集成

業務組件和工作流的集成包括了服務集成和界面集成兩部分的內容。對于服務集成則是將工作流平臺組件提供的工作流管理能力服務統一接入到SOA服務總線，并供業務組件在使用時候調用；對于界面集成主要是對于工作流平臺實現的可復用界面直接通過單點登錄的方式進行集成。

對于服務集成，主要包括的接口服務有：

• 啟動進程 startProcessInstanceByQueue
• 獲取實例信息 getProcessInstance
• 靜態啟動工作流 createProcessInstance
• 進程查詢 listProcessInstance
• 刪除進程實例 deleteProcessInstance

在與流程平臺的集成中，一方面是通過流程平臺暴露的服務接口進行程序集成；一方面是通過流程平臺提供的標準UI組件進行界面集成。可以看到對于待辦，已辦，流程監控等核心界面不適合下放到各個業務組件自行開發，而是應該通過抽象后統一有流程平臺來實現，業務組件在使用過程中通過界面集成的方式進行嵌入。

具體可以考慮的界面集成內容主要包括：

• 我的待辦和我的已辦功能集成
• 圖形化流程查看界面集成
• 流程監控界面集成（暫停、重啟、終止、完成）
• 流程流轉和處理信息界面集成
• 任務處理信息界面集成

BPM和HWF人工工作流引擎

很早以前在談BPR業務流程重組的時候，其要點就在于打破職能部門界限，形成跨越業務職能邊界的端到端流程。而對于BPM同樣道理，即在業務職能部門各自為陣建設自己業務系統的情況下，需要跨越業務系統邊界進行端到端業務流程的整合。

BPM首先是一個公司管理問題，其次才是一個業務問題，其次才是一個系統問題。拋開了業務和管理，企業本身組織架構和戰略來談BPM基本都是無法落地，有時候期望通過BPR和BPM來改善公司管理和組織也是適得其反。根深蒂固的職能部門邊界，利益和績效KPI不可避免的會導致流程割裂，業務流程銜接點成為三不管地帶，沒有誰來關心端到端流程，更談不上來系統化思考全流程的優化和改進。

在這種情況下出現了流程管理部門，專門負責公司流程改進和優化，流程管理部門獨立在業務部門之外，這種情況下雖然可以全局的思考流程問題，但是流程優化結果如何落地，流程管理部門不存在具體的業務KPI，而各業務部門有各自利益，雖然有很好的流程優化和改進，但是沒有強有力的執行力仍然難以解決落地問題。

組織，戰略和業務目標來推動業務流程改進，業務流程改進推動IT的建設，流程和IT融合，IT建設和實施過程中又進一步固化流程，通過IT系統的建設和實施加快流程和標準規范的落地。先固化，再優化，持續改進。華為公司推行實施的ISC和IPD，中興推進的HPPD和項目化運作基本都是這種模式和思路。在面對市場競爭需要快速高質量交付的時候，必須有整合高效的端到端流程，在端到端流程下沒有割裂的部門，更沒有割裂的系統。

BPM的推進和建設任重道遠，因為其本質是一個業務問題，而非系統問題。

BPM系統實施的兩個層面

對于BPM軟件前面已經談到過一定是包括了自動化的業務流和人工工作流引擎兩部分的內容，同時為了更好的處理在業務流程建模中的業務規則往往還需要有單獨的規則引擎子系統或模塊。一個完整的BPM系統往往包括了流程建模和設計，數據建模，界面設計，基礎數據和權限設計，流程執行和監控，流程仿真，流程績效評估多個方面的內容。

由于BPM主要完成的流程組合和編排是是整個SOA架構的上層內容，因此一個完整的BPM系統設計和構建本身就是組件化和SOA服務化思想進行的。

對于BPM軟件的實施，我們從通過BPM系統全新構建業務應用和基于BPM系統進行流程整合兩個場景來討論BPM軟件實施過程中的異同。

01-全新構建業務應用

一個完整的BPM系統本身就可以理解為一個既開放，又相當封閉的SOA架構平臺。開放主要是說該系統能夠很好的集成和復用已有的SOA共享服務能力，封閉則是說BPM軟件可以從設計建模，到測試，到部署上線端到端的完成一個業務應用的構建。

可以看到全新構建業務應用相當來說反而容易，這個時候沒有和企業內部遺留IT系統集成和協同的麻煩。在這種情況下4A基礎數據完全可以以BPM系統為最初的源頭，很多跨流程的業務單據信息也直接在BPM系統中進行建模和設計。對于界面和展現即完全利用BPM軟件本身提供的一整套快捷開發工具進行，本身也不存在單獨構建一個IT系統時候還需進行基礎技術框架構建的問題。

但是在這種場景下構建BPM，仍然存在一些問題無法解決，具體包括如下：

首先對于業務系統，我前面分過類，即以工單和流程驅動的系統，還有就是以核心共享數據為基礎驅動的系統。前者類似OA，ITIL類業務系統；后者類似資產，資源管理等系統。注意對于后者我們期望的一個完整的全局數據模型，這個數據模型往往會應用到多個業務流程中，而不是簡單的工單。在這種情況下采用BPM軟件是很實現完整的業務功能的。因此BPM更多的還是適用于流程驅動的業務應用。

其次，通過BPM軟件構建出來的系統往往是跨越了多個業務部門的一個端到端業務流程管理，在這種情況可能并不會再具備原有的項目系統，采購系統，物流系統等嚴格的業務系統劃分，而是這些業務都完整的實現在了一個短到短的業務流程上。那么這個BPM系統的業務管理和認責部門是誰？這個時候我們往往找不到一個主導的責任部門，那么這個BPM系統后續如何推廣實施？靠IT部門的力量往往是很難真正落地的。這也是我們常說的BPM系統的推廣難點已經不在技術上，而在于業務上。

最后即使是流程驅動的業務系統，如果期望通過BPM軟件提供的功能完全通過可配置和可視化設計的方式完全實現出來還是存在困難，即使有相關的規則引擎，但是仍然很難做到完全可配置的快速開發。這就自然涉及到了即使全新構建BPM系統，在BPM的底層仍然需要有實現核心能力和業務組件和技術組件，這些組件重點變成提供領域服務能力，而不是前臺界面展現和協同。這個點必須要意識到，否則容易理解為BPM是萬能的，啥流程都可以很簡單的建模和配置設計出來，那就大大的犯錯了。

02-遺留系統通過BPM來整合場景

這個相當于前者來說往往更加困難，困難點就在在于期望通過BPM來解決原有的端到端流程中的協同斷點，同時又需要最大化的保留歷史遺留系統的IT資產。

大家看SOA架構好像覺得這個問題已經很簡單的解決了，即歷史的遺留系統都會識別為組件，組件應該將遺留系統的業務和數據服務能力提供出來，然后通過BPM層對服務進行組合，服務進行編排，形成一個端到端的完整流程。但是這個本質問題還是BPM和遺留業務的關系問題。

如果基于BPM是來實現一個完整的端到端流程，這個端到端流程在構建過程中確實可以調用遺留系統的服務能力，但是這個端到端流程是否涉及到單據和數據的產生，是否涉及到人工流程的處理？如果流程會產生單據和數據信息，那么根據原有IT架構這些業務單據仍然應該產生和存儲在IT系統而不是BPM系統，對于人工流程的處理同樣的道理，仍然應該是在原有業務系統中統一處理而不是在BPM系統。

這個一分析清楚我們就容易理解，遺留系統場景下BPM進行整合，不能憑空的再找出一個BPM系統出來，BPM的重點是將原有業務系統中的單據和流程整合和集成起來，而不是替代原有系統的能力。最終集成的效果可以通過Portlet形式展示到門戶，而不是新增加一個業務系統。

把這個理解清楚了，就清楚在這種場景下BPM實施的重點應該是由業務系統提供完整的領域服務層能力出來，而BPM重點是來統一實現界面層和展現，實現各個業務系統中服務能力的組合。即使在這種情況下都還需要考慮如何解決門戶層應用功能和原有IT系統間功能的統一工作臺展現，這個問題沒有解決好就會變成業務部門人員需要兩處處理業務，現在在實施層面是很難推廣的。

還有就是我看到，實施BPM有個很重要的內容，就是4A系統或者叫模塊的實施，以及原有的工作流引擎是否已經成功實施。如果這些沒有實施，那么BPM將作為為4A和工作流的基礎支撐，如果已經實施那么就存在如何同步原有的4A數據，是棄用原有各個業務系統不統一的流程引擎還是保留資產進行整合的問題。

對原有的IT資產保留的越多，你會看到BPM本身在實施過程中能夠用到的能力越是減少和退化。那么對于一個已經相當成熟的內部IT來說，BPM還存在哪些價值和意義。

針對這個問題，我前面也有文章談到過，在這種場景下BPM的價值重點體現在兩個方面。

第一個方面是通過BPM來實現端到端流程執行的監控和流程績效評估，注意這本身在完整的應用架構里面就是在執行層上面的事情，這樣可以減少和已有的業務系統之間的功能性沖突。

第二是對于企業內部的很多職能管理部門，如審計部門，風控部門，流程管理部門等，這些部門本身不承載核心業務價值鏈上的單據產生和業務，而重點是基于已有業務系統能力進行的IT管控和治理，因此對于這些部門新建設的業務系統是最適合通過BPM工具來完成的。

對于BPM本身在進行流程建模設計的時候，也要注意到最好采用子流程的模式進行分層建模和設計，即對于BPM流程的頂層重點是自動化的端到端業務流，而對于下層才是人工審批流流程，否則一個完整的端到端BPM流程將很難進行后續的執行監控。

當前很多企業就IT成熟度來說都沒有到能夠理解和實施BPM的程度，這也是為何很多企業的BPM實施僅僅變成了一個企業內部的統一工作流引擎平臺實施的原因。

BPM系統實施演進思路

對于通過BPM工具并結合服務層來實現端到端流程監控這個話題，前面文章已經提到過了，這個相當來說比較容易實現，即這種最終編排出來的BPM流程視圖更多的都是通過服務讀數據而不會涉及到寫操作。同時原有的各個業務流程還是在各個遺留的業務系統里面，對業務系統本身的改動也相當較小。

那現在的問題還是，對于一個完整的業務能否全部依賴BPM產品提供的能力來實現，各個大型廠家的BPM產品基本都覆蓋了流程建模設計，流程執行監控，UI和權限建模等各個方面的內容，基本已經是一個完整的基于流程驅動的快速開發平臺。

但是實際的情況往往則是這種大而全的平臺在實際的實施應用中效果并不太理想。對于這點主要的原因包括了如下幾個方面的內容：

其一：企業在引入BPM的時候往往已經建設了大量的IT遺留系統，這些業務系統基本已經承載了企業核心業務流程和業務功能。而在BPM引入后如果要通過其來做完整的業務流程，往往都存在對遺留的業務系統改造相當大的問題。要明白對于傳統系統基本是煙囪式縱向建設模式，而SOA BPM的思想是橫向從組件-》服務-》流程-》界面展現的橫向分層建設模式。新的架構思想往往會導致遺留系統要完全下沉為獨立的業務組件并提供服務能力，而這個架構層面的改動和影響企業往往沒有魄力去做，當然其本身帶來的改造量也相當大。

其二：我們在和企業交流過程中可以看到，究竟有多少人真正需要端到端的業務流展示？要明白即使原有的端到端流程雖然分散在多個業務系統的業務功能單元中進行了功能支撐，但是本身端到端流程還是完整的，只是沒有一個端到端流程全貌而已。

而本身企業內的業務部門在進行職能劃分后，往往業務部門本身關心的也是自己業務部門的業務流程和功能，而不會太關心端到端流程，這是我們原來在理想化思考的時候沒有考慮到的問題。即一個企業在管理層都沒有啟動端到端流程優化和整合，或者沒有相應的流程管理類部門的時候，是不太會有明顯的對BPM業務訴求的。即我強調過的端到端流程即使存在斷點，也不是一定要上BPM，往往通過ESB服務集成就能很好的解決流程集成和業務協同的問題。

其三：即使到今天很多人對BPM還是有很大的誤解，將很多單純的工作流引擎產品錯誤理解為BPM，或者將統一的工作流引擎平臺產品理解為BPM，在上了這種產品或平臺后，雖然解決了審批流層面的問題，但是往往對于端到端流程整合和監控問題并沒有解決掉。當然這也不是單純的工作流引擎產品的重點。

其四：哪個部門需要BPM？要明白BPM產品最終做完的BPM業務流程和界面功能往往會橫跨了多個業務部門，那么這個產品最終的主導和認證部門往往很難決定是誰？如果僅僅是靠IT部門的能力去推一個BPM產品是存在相當大的難度的。因此前面也說過，如果企業有類似于流程管理部門，往往還相當容易找到一個認責的主體。

其五：各大廠商對BPM的宣傳有很多夸大，導致客戶認為BPM是一個無所不能的產品，什么東西都可以靈活的設計和配置出來。上了BPM產品后流程方面的問題就全部解決掉了。而實際上我們看到的情況上，即使BPM產品本身能力再強，由于企業本身核心價值鏈業務的復雜性，單純的靠BPM產品進行配置和開發當前來說還是不現實的，也很難做出讓客戶滿意的效果。

基于以上的分析，那么在一個企業的BPM實施里面究竟應該如何做是一種相當理想的方式？在這里我們主要談幾點關鍵性的實施步驟和內容。

01-流程建模

流程建模還是最重要的一個步驟，即基于企業架構包括ARIS流程建模的思路對業務流程進行建模，在業務流程建模過程中通過流程逐層分解，對業務對象，業務活動，人工審批，自動處理等各種業務節點進行識別。對于BPM提供的流程建模平臺，不管是否基于BPMN2.0標準，最終的建模文件都是很好的銜接真實業務流程和最終的系統實現之間的一個關鍵點。

02-服務識別

其中包括了組件識別，要明白最終的業務活動和交互集成最終都需要調用底層業務系統和組件提供出來的服務能力。基于跨系統交互流程分析的思路才能夠分析和識別出能夠用來做上層BPM功能的核心服務能力。這些服務能力最終還是由底層的業務系統或組件提供。或者簡單來講，這種方式帶來的是以后業務系統重點是提供服務能力開放，而是不管最終展現和集成。那么原有業務系統逐步下沉為業務組件，但是其核心業務能力還是在各個業務組件里面。

03-數據建模

這塊是要做，但是要注意不是在BPM里面進行核心業務對象的數據建模，數據建模還是要參考原有的方法進行，最終數據對象還是沉淀在業務組件里面。要明白核心業務對象是不可能存儲在BPM系統里面的，這個也不合適，BPM更多的還是服務組合和編排串聯，而不是承載核心數據對象能力。對于各大廠家給出的BPM產品中的數據建模能力要慎用。

04-界面建模

這塊也是導致BPM很難實施好的一個重要原因，即我們總是想理想化的通過BPM工具進行界面表單建模，但是對于服務的業務流程和業務功能這塊很難真正實現。那么真正好的做法還是展現層的開發需要通過實施重新做一套框架，里面可能會有一些界面配置但是不是全部。核心的界面展現和設計可能還是涉及到的自己定制開發，這塊沒必要借用BPM產品的能力。但是唯一要注意的就是在展現層開發的時候，最終的功能界面數據的查詢和存儲等都需要使用服務層提供出來的可重用的服務能力。這也是我們常說的應用層變輕和變靈活的一個原因，即應用層界面展現已經沒有太多的業務規則和邏輯提供，而更多的是使用開放的服務能力。

05-集成整合

上面幾點思考清楚后，剩下的關鍵事情就是自己開發定制的功能界面和BPM流程模型，和服務層服務之間的協同和整合，形成一個完整的整體。由于我們將界面和數據建模的抽離可以看到，我們需要自己來實現和流程層的集成和整合，包括和底層工作流引擎的整合，我們需要根據流程引擎本身的能力來考慮整個業務流程執行過程中流程模型中的狀態節點的同步流轉。

把以上幾點都想清楚了BPM實施落地才有了一個基礎。BPM產品本身不是萬能的，BPM產品的實施也不是去顛覆各個遺留IT系統，如何找到一種銜接和融合點才是真正的關鍵。

BPM端到端流程整合案例

一個工程項目或一個合同管理的端到端，往往在企業內部跨越了多個業務系統，涉及到諸多的業務協同，業務單據對象和不同業務對象的狀態流轉。正是由于在這個業務流轉中出現了業務流，出現了多個不同的業務對象實體的轉換和映射，也就出現了1對多，多對多的業務對象關系。類似一個項目涉及到多個采購合同，一個合同往往涉及到多個訂單，一個訂單又可以分多次進行接收。而端到端業務流程監控的難點也正是在這個地方。

在梳理完成端到端業務流程后，我們可以進一步梳理業務對象的關系圖，該梳理將有助于我們在BPM系統中進行業務對象和數據建模。

分析完端到端流程，可以看到跨系統的端到端流程往往涉及到多個業務系統間的接口交付和集成，因此需要進一步分析接口交付和集成關系，如下：

基于前面分析，我們可以開始使用BPM工具進行詳細的業務流程建模，其中包括了主流程，也可以包括了子流程，既包括了業務自動化流程節點，也包括了人工工作流處理節點。如下。

監控的可視化流程圖不同于BPM建模和設計中的復雜流程圖，因此該流程設計往往只需要支持最簡單的串行流程，并行流程即可。因此在監控流程的狀態流轉設計往往并不復雜，而較為復雜的是對于流程中每一個狀態點我們需要查看到的業務對象信息的設計，界面的設計。

為了簡化這個系統的實現過程，對于服務提供部分我們采用在系統外單獨來實現，即監控中需要查詢和查看的數據都單獨做成各種web service服務，可以在流程設計中進行調用。而界面的可視化設計相當簡單，即僅僅是需要將界面控件的數據源和各種web service數據服務提供端進行簡單的綁定即可。

要注意流程監控類系統的狀態流轉不同于工作流引擎系統，其狀態本身的定義就是大的業務流程階段和管控點，這些狀態點的觸發往往是事件觸發模式。因此對于該流程中的狀態流轉需要引入EDA事件驅動架構和消費發布訂閱機制，在業務系統中完成某些業務后需要發出相應的業務事件，在流程監控實例中接收事件，并根據事件響應進行狀態的流轉。

在整合完成后，我們可以將最終的內容作為一個獨立的portlet配置到統一門戶上面，用戶登錄門戶后即可以看到自己關注的項目的端到端流程和當前狀態信息。

端到端流程監控平臺還可以用來整合企業已有的工作流引擎，即端到端流程監控平臺往往監控的是企業內跨多個業務系統的端到端流程，但是監控到某一個活動的時候往往就下鉆到了單一的業務系統和單一的工作流引擎實例執行，而對于這部分的內容相當也很簡單，即從業務流監控-》單個工作流實例的監控，能夠實現逐層進入的監控和查看模型即可。

歡迎關注@人月聊IT 分享SOA，微服務，DevOps平臺規劃和建設。