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

簡介：多年SOA規(guī)劃建設(shè)，私有云PaaS平臺架構(gòu)設(shè)計經(jīng)驗，長期從事一線項目實踐

今天準(zhǔn)備談下BPM業(yè)務(wù)流程管理系統(tǒng)的建設(shè)和實施方面的內(nèi)容。首先還是從BPM的基礎(chǔ)概念入手進(jìn)行介紹，然后重點(diǎn)解釋下BPM和工作流引擎的區(qū)別，最好談下BPM軟件的應(yīng)用和實施場景。

BPM業(yè)務(wù)流程管理概述

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

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

而如今，公司再次把業(yè)務(wù)流程管理——這種通過分析、建模和監(jiān)控持續(xù)優(yōu)化業(yè)務(wù)流程的實踐，當(dāng)作一種解決業(yè)務(wù)難題和幫助公司實現(xiàn)自己財務(wù)目標(biāo)的系統(tǒng)方法。

業(yè)務(wù)流程管理（Business Process Management, BPM）不是一個新概念，甚至不是一個新名詞。它是從相關(guān)的業(yè)務(wù)流程變革領(lǐng)域，如業(yè)務(wù)流程改進(jìn)（BPI）、業(yè)務(wù)流程重組（BPR）、業(yè)務(wù)流程革新中發(fā)展起來的。流程管理技術(shù)也是從早期的工作流管理、EAI、流程自動化、流程集成、流程建模、流程優(yōu)化等技術(shù)中發(fā)展起來的。

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

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

業(yè)務(wù)流程管理是跨業(yè)務(wù)組織結(jié)構(gòu)，跨業(yè)務(wù)系統(tǒng)，跨應(yīng)用的軟件和方法論,從而實現(xiàn)自動化管理,優(yōu)化動態(tài)業(yè)務(wù),產(chǎn)生真正的業(yè)務(wù)價值。更多體現(xiàn)的是跨業(yè)務(wù)域，端到端業(yè)務(wù)流程的管理和整合。

BPM和HWF人工工作流引擎

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

端到端流程整合出現(xiàn)斷點(diǎn)或流程不暢通，一方面是業(yè)務(wù)系統(tǒng)本身的分解有問題，一方面則是業(yè)務(wù)系統(tǒng)之間集成有問題，業(yè)務(wù)部門各自為陣導(dǎo)致了系統(tǒng)集成這種中間地點(diǎn)沒有一個主導(dǎo)部門去管理和負(fù)責(zé)。業(yè)務(wù)系統(tǒng)本身分解問題主要體現(xiàn)在沒有一開始就從企業(yè)架構(gòu)和應(yīng)用架構(gòu)出發(fā)來考慮業(yè)務(wù)系統(tǒng)建設(shè)，業(yè)務(wù)系統(tǒng)建設(shè)不是從上向下的，而是完全根據(jù)業(yè)務(wù)部門需求各自建立。系統(tǒng)間集成問題則主要體現(xiàn)在了完全不考慮集成的標(biāo)準(zhǔn)規(guī)范，集成的方式，集成本身的可復(fù)用性，導(dǎo)致大量重復(fù)建設(shè)。

流程建模遵循高端建模逐層分解的思路，高端流程往往正是我們關(guān)注的業(yè)務(wù)流程，高端流程跨越了多個業(yè)務(wù)域，多個業(yè)務(wù)活動，多個業(yè)務(wù)對象和單據(jù)實體，最終完成了一個端到端業(yè)務(wù)。如供應(yīng)鏈端到端，涉及到采購需求，采購計劃，采購策略和實施，采購訂單，采購執(zhí)行諸多環(huán)節(jié)和業(yè)務(wù)對象。高端業(yè)務(wù)流程中采購訂單生成只是一個業(yè)務(wù)活動或子流程，而采購訂單制作和生成本身又需要根據(jù)訂單類型或金額設(shè)計不同的審批流程，而采購訂單擬制后的審批流程才是我們經(jīng)常所說的工作流，人工工作流或?qū)徟鳌?/p>

那么從這個意義上很容易看到業(yè)務(wù)流和工作流的區(qū)別如下:

• 業(yè)務(wù)流往往會跨多個業(yè)務(wù)系統(tǒng)，而審批流往往主要涉及到一個系統(tǒng)。
• 業(yè)務(wù)流會涉及到多個業(yè)務(wù)功能，多個業(yè)務(wù)對象，而審批流往往只涉及到一個業(yè)務(wù)對象。
• 業(yè)務(wù)流涉及到的是不同業(yè)務(wù)單據(jù)之間的流轉(zhuǎn)，而審批流往往是同一業(yè)務(wù)單據(jù)狀態(tài)的變化。
• 業(yè)務(wù)流中既包括了人工活動也包括了自動的業(yè)務(wù)活動，而審批流一般為人工審批活動。

而對于BPM業(yè)務(wù)流程管理系統(tǒng)和工作流管理系統(tǒng)，可以再進(jìn)行下分析。我們看到現(xiàn)在很多BPM軟件也從工作流管理軟件發(fā)展而來。不論是哪種，基本都包括了流程建模，流程執(zhí)行，流程監(jiān)控，流程分析等基本功能，也包括了表單建模和數(shù)據(jù)建模，權(quán)限管理等擴(kuò)展功能。

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

對于流程建模，BPM關(guān)注的是業(yè)務(wù)流程建模，基于BPMN或BPEL進(jìn)行，而工作流軟件關(guān)注的是審批流建模。BPM建模需要考慮業(yè)務(wù)人員對建模需求和可用性，但是不可避免又導(dǎo)致建模的內(nèi)容無法很好的落地。而工作流建模本身已經(jīng)細(xì)化到一個功能模塊中的審批流，相對來說簡單很多而容易實施執(zhí)行。

BPM業(yè)務(wù)流程往往跨越了業(yè)務(wù)系統(tǒng)，跨越了多個業(yè)務(wù)單據(jù)，需要處理不同的業(yè)務(wù)規(guī)則和邏輯。而工作流軟件活動節(jié)點(diǎn)往往僅僅處理審批和會簽任務(wù)，和外界交互相對較少。而BPM業(yè)務(wù)流程中由于存在業(yè)務(wù)活動和業(yè)務(wù)規(guī)則，而這些又需要外界提供數(shù)據(jù)支持，因此不可避免的在BPM流程建模中需要通過SOA服務(wù)方式調(diào)用各種可復(fù)用的服務(wù)來處理和轉(zhuǎn)換數(shù)據(jù)。

工作流軟件發(fā)展到今天，我們看到也可以在表單建模，工作流設(shè)計過程中調(diào)用外部的SOA服務(wù)，這是一個很好的進(jìn)步，使工作流軟件不僅僅能夠簡單進(jìn)行審批處理還能夠增加較為復(fù)雜的業(yè)務(wù)規(guī)則判斷。

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

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

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

業(yè)務(wù)流程整合一定是涉及到自動化的業(yè)務(wù)流和人工工作流，原有的BPEL很難融入HWF導(dǎo)致BPEL只能應(yīng)用到流程整合的一些點(diǎn)上而無法真正實現(xiàn)理想狀態(tài)下的流程編排，最多算上服務(wù)編排。而引入人工工作流使BPM有了做端到端流程整合的能力，但是已有業(yè)務(wù)系統(tǒng)已經(jīng)有工作流引擎或?qū)徟鲗崿F(xiàn)，要完全拋棄已有的流程引擎又是一個很麻煩的事情。

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

HWF人工工作流引擎

在這里先談下我們常說的人工工作流引擎，這個其實是現(xiàn)在大多數(shù)應(yīng)用系統(tǒng)都必須具備的基本業(yè)務(wù)管理功能。正是由于每個系統(tǒng)都需要該功能，那么每個系統(tǒng)如果都單獨(dú)建設(shè)必然帶來重復(fù)的成本投入，同時帶來了各個業(yè)務(wù)系統(tǒng)間的工作流交互標(biāo)準(zhǔn)語言不統(tǒng)一。

在談企業(yè)私有云PaaS平臺建設(shè)的時候我們談到了，基于平臺 應(yīng)用的構(gòu)建思路，企業(yè)流程平臺作為底層技術(shù)平臺統(tǒng)一建設(shè)。

企業(yè)內(nèi)部的統(tǒng)一流程平臺建設(shè)，不僅僅是功能的遷移，更加重要的是數(shù)據(jù)的遷移，對于流程來講我們所說的數(shù)據(jù)即是流程建模數(shù)據(jù)和流程執(zhí)行數(shù)據(jù)的遷移。在統(tǒng)一流程建模和統(tǒng)一流程執(zhí)行的基礎(chǔ)上，提供統(tǒng)一的流程監(jiān)控和流程績效管理。

很早我們就在談流程不能脫離組織，崗位角色，權(quán)限等基礎(chǔ)而存在。進(jìn)行組織，人員，崗位權(quán)限等基礎(chǔ)主數(shù)據(jù)的管理和整合又是建立內(nèi)部統(tǒng)一流程平臺的基礎(chǔ)。因此我們可以看到內(nèi)部的主數(shù)據(jù)管理，組織引擎和權(quán)限引擎等內(nèi)容。這些都是為流程平臺做準(zhǔn)備。

流程建模全統(tǒng)一在統(tǒng)一流程平臺進(jìn)行，因此BPM需要有統(tǒng)一的組織，人員和權(quán)限數(shù)據(jù)，這是各個系統(tǒng)能夠完全互通的基礎(chǔ)。在流程建模的時候，不僅僅涉及到常用工作流模型中的串行，并行，條件分支，聚合，子流程，回退等基本流程功能。更加重要的我認(rèn)為還是流程活動節(jié)點(diǎn)和組織權(quán)限內(nèi)容的結(jié)合，否則流程很難適應(yīng)組織權(quán)限調(diào)整帶來的影響和變化。

粗一點(diǎn)的流程建?？梢灾豢刂频奖韱渭墮?quán)限，而細(xì)化點(diǎn)的流程建模則可以控制到表單輸入的每一個數(shù)據(jù)項的權(quán)限。流程活動節(jié)點(diǎn)往往很多時候都具有條件判斷，條件判斷往往又涉及到外部調(diào)用，因此流程活動節(jié)點(diǎn)支持腳本代碼的編寫，支持對外部接口和服務(wù)的調(diào)用又是最基本的功能。

工作流產(chǎn)品本身的設(shè)計包括了靜態(tài)數(shù)據(jù)建模和動態(tài)數(shù)據(jù)建模兩方面的內(nèi)容。涉及到流程模板，活動節(jié)點(diǎn)，連接弧，分支判斷，流程圖形化展示元數(shù)據(jù)等多個方面的內(nèi)容。動態(tài)數(shù)據(jù)建模又涉及到流程執(zhí)行實例數(shù)據(jù)的記錄，這方面的內(nèi)容后續(xù)單獨(dú)描述。

統(tǒng)一流程平臺需要實現(xiàn)的就是統(tǒng)一流程建模，統(tǒng)一執(zhí)行和統(tǒng)一監(jiān)控，只要是涉及到流程建模和執(zhí)行的數(shù)據(jù)都不在原有的各個業(yè)務(wù)系統(tǒng)中，而是全部集中到統(tǒng)一流程管理平臺進(jìn)行管理。按這個思路自然帶來新問題即BPM系統(tǒng)如何與原有的業(yè)務(wù)系統(tǒng)集成。

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

1.各業(yè)務(wù)系統(tǒng)單獨(dú)的多租戶賬號登錄BPM系統(tǒng)，進(jìn)行系統(tǒng)流程建模，BPM系統(tǒng)已有在各個業(yè)務(wù)系統(tǒng)完全統(tǒng)一的組織，用戶和權(quán)限數(shù)據(jù)。這個不統(tǒng)一BPM系統(tǒng)無法真正落地。

2.在流程建模完成后，對于每次流程建模系統(tǒng)會建立單獨(dú)的流程模板ID供業(yè)務(wù)系統(tǒng)使用。

3.業(yè)務(wù)系統(tǒng)各業(yè)務(wù)表單使用統(tǒng)一的流程啟動接口調(diào)用BPM系統(tǒng)提供的服務(wù)啟動工作流。

4.BPM系統(tǒng)中的流程待辦，流程已辦，流程處理等各個關(guān)鍵業(yè)務(wù)功能用UI組件的方式形成UI組件后內(nèi)嵌到各個業(yè)務(wù)系統(tǒng)中使用。在這里又需要企業(yè)內(nèi)業(yè)務(wù)系統(tǒng)間實現(xiàn)統(tǒng)一認(rèn)證和SSO單獨(dú)登錄。

5.BPM系統(tǒng)提供流程執(zhí)行，流程監(jiān)控，流程查詢等多個服務(wù)接口供業(yè)務(wù)系統(tǒng)使用。

統(tǒng)一流程平臺首先要實現(xiàn)的是替代原有業(yè)務(wù)系統(tǒng)內(nèi)的人工工作流引擎，實現(xiàn)流程的統(tǒng)一管理，同時在組織，用戶和權(quán)限集中的基礎(chǔ)上，形成系統(tǒng)基礎(chǔ)管理，權(quán)限管理和流程管理的通用語言。

這樣就很容易過渡到跨系統(tǒng)間的流程整合，在這種情況下的跨系統(tǒng)流程整合只需要再考慮如何與標(biāo)準(zhǔn)的BPEL進(jìn)行集成，使流程整合即具備人工審批流節(jié)點(diǎn)，又具備根據(jù)業(yè)務(wù)規(guī)則自動進(jìn)行處理和流轉(zhuǎn)的自動化業(yè)務(wù)節(jié)點(diǎn)。

基于工作流引擎的接口服務(wù)集成

業(yè)務(wù)組件和工作流的集成包括了服務(wù)集成和界面集成兩部分的內(nèi)容。對于服務(wù)集成則是將工作流平臺組件提供的工作流管理能力服務(wù)統(tǒng)一接入到SOA服務(wù)總線，并供業(yè)務(wù)組件在使用時候調(diào)用；對于界面集成主要是對于工作流平臺實現(xiàn)的可復(fù)用界面直接通過單點(diǎn)登錄的方式進(jìn)行集成。

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

• 啟動進(jìn)程 startProcessInstanceByQueue
• 獲取實例信息 getProcessInstance
• 靜態(tài)啟動工作流 createProcessInstance
• 進(jìn)程查詢 listProcessInstance
• 刪除進(jìn)程實例 deleteProcessInstance

在與流程平臺的集成中，一方面是通過流程平臺暴露的服務(wù)接口進(jìn)行程序集成；一方面是通過流程平臺提供的標(biāo)準(zhǔn)UI組件進(jìn)行界面集成?？梢钥吹綄τ诖k，已辦，流程監(jiān)控等核心界面不適合下放到各個業(yè)務(wù)組件自行開發(fā)，而是應(yīng)該通過抽象后統(tǒng)一有流程平臺來實現(xiàn)，業(yè)務(wù)組件在使用過程中通過界面集成的方式進(jìn)行嵌入。

具體可以考慮的界面集成內(nèi)容主要包括：

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

BPM和HWF人工工作流引擎

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

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

在這種情況下出現(xiàn)了流程管理部門，專門負(fù)責(zé)公司流程改進(jìn)和優(yōu)化，流程管理部門獨(dú)立在業(yè)務(wù)部門之外，這種情況下雖然可以全局的思考流程問題，但是流程優(yōu)化結(jié)果如何落地，流程管理部門不存在具體的業(yè)務(wù)KPI，而各業(yè)務(wù)部門有各自利益，雖然有很好的流程優(yōu)化和改進(jìn)，但是沒有強(qiáng)有力的執(zhí)行力仍然難以解決落地問題。

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

BPM的推進(jìn)和建設(shè)任重道遠(yuǎn)，因為其本質(zhì)是一個業(yè)務(wù)問題，而非系統(tǒng)問題。

BPM系統(tǒng)實施的兩個層面

對于BPM軟件前面已經(jīng)談到過一定是包括了自動化的業(yè)務(wù)流和人工工作流引擎兩部分的內(nèi)容，同時為了更好的處理在業(yè)務(wù)流程建模中的業(yè)務(wù)規(guī)則往往還需要有單獨(dú)的規(guī)則引擎子系統(tǒng)或模塊。一個完整的BPM系統(tǒng)往往包括了流程建模和設(shè)計，數(shù)據(jù)建模，界面設(shè)計，基礎(chǔ)數(shù)據(jù)和權(quán)限設(shè)計，流程執(zhí)行和監(jiān)控，流程仿真，流程績效評估多個方面的內(nèi)容。

由于BPM主要完成的流程組合和編排是是整個SOA架構(gòu)的上層內(nèi)容，因此一個完整的BPM系統(tǒng)設(shè)計和構(gòu)建本身就是組件化和SOA服務(wù)化思想進(jìn)行的。

對于BPM軟件的實施，我們從通過BPM系統(tǒng)全新構(gòu)建業(yè)務(wù)應(yīng)用和基于BPM系統(tǒng)進(jìn)行流程整合兩個場景來討論BPM軟件實施過程中的異同。

01-全新構(gòu)建業(yè)務(wù)應(yīng)用

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

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

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

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

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

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

02-遺留系統(tǒng)通過BPM來整合場景

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

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

如果基于BPM是來實現(xiàn)一個完整的端到端流程，這個端到端流程在構(gòu)建過程中確實可以調(diào)用遺留系統(tǒng)的服務(wù)能力，但是這個端到端流程是否涉及到單據(jù)和數(shù)據(jù)的產(chǎn)生，是否涉及到人工流程的處理？如果流程會產(chǎn)生單據(jù)和數(shù)據(jù)信息，那么根據(jù)原有IT架構(gòu)這些業(yè)務(wù)單據(jù)仍然應(yīng)該產(chǎn)生和存儲在IT系統(tǒng)而不是BPM系統(tǒng)，對于人工流程的處理同樣的道理，仍然應(yīng)該是在原有業(yè)務(wù)系統(tǒng)中統(tǒng)一處理而不是在BPM系統(tǒng)。

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

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

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

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

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

第一個方面是通過BPM來實現(xiàn)端到端流程執(zhí)行的監(jiān)控和流程績效評估，注意這本身在完整的應(yīng)用架構(gòu)里面就是在執(zhí)行層上面的事情，這樣可以減少和已有的業(yè)務(wù)系統(tǒng)之間的功能性沖突。

第二是對于企業(yè)內(nèi)部的很多職能管理部門，如審計部門，風(fēng)控部門，流程管理部門等，這些部門本身不承載核心業(yè)務(wù)價值鏈上的單據(jù)產(chǎn)生和業(yè)務(wù)，而重點(diǎn)是基于已有業(yè)務(wù)系統(tǒng)能力進(jìn)行的IT管控和治理，因此對于這些部門新建設(shè)的業(yè)務(wù)系統(tǒng)是最適合通過BPM工具來完成的。

對于BPM本身在進(jìn)行流程建模設(shè)計的時候，也要注意到最好采用子流程的模式進(jìn)行分層建模和設(shè)計，即對于BPM流程的頂層重點(diǎn)是自動化的端到端業(yè)務(wù)流，而對于下層才是人工審批流流程，否則一個完整的端到端BPM流程將很難進(jìn)行后續(xù)的執(zhí)行監(jiān)控。

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

BPM系統(tǒng)實施演進(jìn)思路

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

那現(xiàn)在的問題還是，對于一個完整的業(yè)務(wù)能否全部依賴BPM產(chǎn)品提供的能力來實現(xiàn)，各個大型廠家的BPM產(chǎn)品基本都覆蓋了流程建模設(shè)計，流程執(zhí)行監(jiān)控，UI和權(quán)限建模等各個方面的內(nèi)容，基本已經(jīng)是一個完整的基于流程驅(qū)動的快速開發(fā)平臺。

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

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

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

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

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

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

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

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

01-流程建模

流程建模還是最重要的一個步驟，即基于企業(yè)架構(gòu)包括ARIS流程建模的思路對業(yè)務(wù)流程進(jìn)行建模，在業(yè)務(wù)流程建模過程中通過流程逐層分解，對業(yè)務(wù)對象，業(yè)務(wù)活動，人工審批，自動處理等各種業(yè)務(wù)節(jié)點(diǎn)進(jìn)行識別。對于BPM提供的流程建模平臺，不管是否基于BPMN2.0標(biāo)準(zhǔn)，最終的建模文件都是很好的銜接真實業(yè)務(wù)流程和最終的系統(tǒng)實現(xiàn)之間的一個關(guān)鍵點(diǎn)。

02-服務(wù)識別

其中包括了組件識別，要明白最終的業(yè)務(wù)活動和交互集成最終都需要調(diào)用底層業(yè)務(wù)系統(tǒng)和組件提供出來的服務(wù)能力。基于跨系統(tǒng)交互流程分析的思路才能夠分析和識別出能夠用來做上層BPM功能的核心服務(wù)能力。這些服務(wù)能力最終還是由底層的業(yè)務(wù)系統(tǒng)或組件提供?；蛘吆唵蝸碇v，這種方式帶來的是以后業(yè)務(wù)系統(tǒng)重點(diǎn)是提供服務(wù)能力開放，而是不管最終展現(xiàn)和集成。那么原有業(yè)務(wù)系統(tǒng)逐步下沉為業(yè)務(wù)組件，但是其核心業(yè)務(wù)能力還是在各個業(yè)務(wù)組件里面。

03-數(shù)據(jù)建模

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

04-界面建模

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

05-集成整合

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

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

BPM端到端流程整合案例

一個工程項目或一個合同管理的端到端，往往在企業(yè)內(nèi)部跨越了多個業(yè)務(wù)系統(tǒng)，涉及到諸多的業(yè)務(wù)協(xié)同，業(yè)務(wù)單據(jù)對象和不同業(yè)務(wù)對象的狀態(tài)流轉(zhuǎn)。正是由于在這個業(yè)務(wù)流轉(zhuǎn)中出現(xiàn)了業(yè)務(wù)流，出現(xiàn)了多個不同的業(yè)務(wù)對象實體的轉(zhuǎn)換和映射，也就出現(xiàn)了1對多，多對多的業(yè)務(wù)對象關(guān)系。類似一個項目涉及到多個采購合同，一個合同往往涉及到多個訂單，一個訂單又可以分多次進(jìn)行接收。而端到端業(yè)務(wù)流程監(jiān)控的難點(diǎn)也正是在這個地方。

在梳理完成端到端業(yè)務(wù)流程后，我們可以進(jìn)一步梳理業(yè)務(wù)對象的關(guān)系圖，該梳理將有助于我們在BPM系統(tǒng)中進(jìn)行業(yè)務(wù)對象和數(shù)據(jù)建模。

分析完端到端流程，可以看到跨系統(tǒng)的端到端流程往往涉及到多個業(yè)務(wù)系統(tǒng)間的接口交付和集成，因此需要進(jìn)一步分析接口交付和集成關(guān)系，如下：

基于前面分析，我們可以開始使用BPM工具進(jìn)行詳細(xì)的業(yè)務(wù)流程建模，其中包括了主流程，也可以包括了子流程，既包括了業(yè)務(wù)自動化流程節(jié)點(diǎn)，也包括了人工工作流處理節(jié)點(diǎn)。如下。

監(jiān)控的可視化流程圖不同于BPM建模和設(shè)計中的復(fù)雜流程圖，因此該流程設(shè)計往往只需要支持最簡單的串行流程，并行流程即可。因此在監(jiān)控流程的狀態(tài)流轉(zhuǎn)設(shè)計往往并不復(fù)雜，而較為復(fù)雜的是對于流程中每一個狀態(tài)點(diǎn)我們需要查看到的業(yè)務(wù)對象信息的設(shè)計，界面的設(shè)計。

為了簡化這個系統(tǒng)的實現(xiàn)過程，對于服務(wù)提供部分我們采用在系統(tǒng)外單獨(dú)來實現(xiàn)，即監(jiān)控中需要查詢和查看的數(shù)據(jù)都單獨(dú)做成各種web service服務(wù)，可以在流程設(shè)計中進(jìn)行調(diào)用。而界面的可視化設(shè)計相當(dāng)簡單，即僅僅是需要將界面控件的數(shù)據(jù)源和各種web service數(shù)據(jù)服務(wù)提供端進(jìn)行簡單的綁定即可。

要注意流程監(jiān)控類系統(tǒng)的狀態(tài)流轉(zhuǎn)不同于工作流引擎系統(tǒng)，其狀態(tài)本身的定義就是大的業(yè)務(wù)流程階段和管控點(diǎn)，這些狀態(tài)點(diǎn)的觸發(fā)往往是事件觸發(fā)模式。因此對于該流程中的狀態(tài)流轉(zhuǎn)需要引入EDA事件驅(qū)動架構(gòu)和消費(fèi)發(fā)布訂閱機(jī)制，在業(yè)務(wù)系統(tǒng)中完成某些業(yè)務(wù)后需要發(fā)出相應(yīng)的業(yè)務(wù)事件，在流程監(jiān)控實例中接收事件，并根據(jù)事件響應(yīng)進(jìn)行狀態(tài)的流轉(zhuǎn)。

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

端到端流程監(jiān)控平臺還可以用來整合企業(yè)已有的工作流引擎，即端到端流程監(jiān)控平臺往往監(jiān)控的是企業(yè)內(nèi)跨多個業(yè)務(wù)系統(tǒng)的端到端流程，但是監(jiān)控到某一個活動的時候往往就下鉆到了單一的業(yè)務(wù)系統(tǒng)和單一的工作流引擎實例執(zhí)行，而對于這部分的內(nèi)容相當(dāng)也很簡單，即從業(yè)務(wù)流監(jiān)控-》單個工作流實例的監(jiān)控，能夠?qū)崿F(xiàn)逐層進(jìn)入的監(jiān)控和查看模型即可。

歡迎關(guān)注@人月聊IT 分享SOA，微服務(wù)，DevOps平臺規(guī)劃和建設(shè)。