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

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

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

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

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

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

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

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

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

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

業(yè)務(wù)流程管理是跨業(yè)務(wù)組織結(jié)構(gòu)，跨業(yè)務(wù)系統(tǒng)，跨應(yīng)用的軟件和方法論,從而實(shí)現(xiàn)自動(dòng)化管理,優(yōu)化動(dòng)態(tài)業(yè)務(wù),產(chǎn)生真正的業(yè)務(wù)價(jià)值。更多體現(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)往往又需要一個(gè)歸宿的主導(dǎo)部門，在企業(yè)發(fā)展大后一個(gè)業(yè)務(wù)系統(tǒng)也很難完全支撐到企業(yè)所有業(yè)務(wù)流程和業(yè)務(wù)活動(dòng)。因此不可避免的導(dǎo)致了企業(yè)在各個(gè)業(yè)務(wù)域衍生了多個(gè)業(yè)務(wù)系統(tǒng)，業(yè)務(wù)系統(tǒng)主要實(shí)現(xiàn)價(jià)值鏈的一個(gè)核心業(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)沒有一個(gè)主導(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ù)流程，高端流程跨越了多個(gè)業(yè)務(wù)域，多個(gè)業(yè)務(wù)活動(dòng)，多個(gè)業(yè)務(wù)對象和單據(jù)實(shí)體，最終完成了一個(gè)端到端業(yè)務(wù)。如供應(yīng)鏈端到端，涉及到采購需求，采購計(jì)劃，采購策略和實(shí)施，采購訂單，采購執(zhí)行諸多環(huán)節(jié)和業(yè)務(wù)對象。高端業(yè)務(wù)流程中采購訂單生成只是一個(gè)業(yè)務(wù)活動(dòng)或子流程，而采購訂單制作和生成本身又需要根據(jù)訂單類型或金額設(shè)計(jì)不同的審批流程，而采購訂單擬制后的審批流程才是我們經(jīng)常所說的工作流，人工工作流或?qū)徟鳌?/p>

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

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

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

可以講一個(gè)完整的系統(tǒng)基本上可以實(shí)現(xiàn)簡單的以審批流為主的簡單業(yè)務(wù)功能模塊的配置化開發(fā)。通過表單設(shè)計(jì)工具制定一個(gè)表單界面，綁定數(shù)據(jù)對象，掛接上自定義的流程模板，一個(gè)功能即開發(fā)完成，只要沒有太多復(fù)雜的業(yè)務(wù)規(guī)則，基本上完全可以通過配置實(shí)現(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ì)化到一個(gè)功能模塊中的審批流，相對來說簡單很多而容易實(shí)施執(zhí)行。

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

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

業(yè)務(wù)流程建模中會(huì)出現(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)。這個(gè)分離本身意義也很重大，要知道業(yè)務(wù)規(guī)則又明確的業(yè)務(wù)系統(tǒng)開發(fā)商和業(yè)務(wù)主管部門，放到BPM系統(tǒng)中通過定制方式管理規(guī)則顯然是很困難的。

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

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

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

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

HWF人工工作流引擎

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

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

企業(yè)內(nèi)部的統(tǒng)一流程平臺(tái)建設(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)一流程平臺(tái)的基礎(chǔ)。因此我們可以看到內(nèi)部的主數(shù)據(jù)管理，組織引擎和權(quán)限引擎等內(nèi)容。這些都是為流程平臺(tái)做準(zhǔn)備。

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

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

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

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

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

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

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

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

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

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

統(tǒng)一流程平臺(tái)首先要實(shí)現(xiàn)的是替代原有業(yè)務(wù)系統(tǒng)內(nèi)的人工工作流引擎，實(shí)現(xiàn)流程的統(tǒng)一管理，同時(shí)在組織，用戶和權(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ī)則自動(dòng)進(jìn)行處理和流轉(zhuǎn)的自動(dòng)化業(yè)務(wù)節(jié)點(diǎn)。

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

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

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

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

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

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

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

BPM和HWF人工工作流引擎

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

BPM首先是一個(gè)公司管理問題，其次才是一個(gè)業(yè)務(wù)問題，其次才是一個(gè)系統(tǒng)問題。拋開了業(yè)務(wù)和管理，企業(yè)本身組織架構(gòu)和戰(zhàn)略來談BPM基本都是無法落地，有時(shí)候期望通過BPR和BPM來改善公司管理和組織也是適得其反。根深蒂固的職能部門邊界，利益和績效KPI不可避免的會(huì)導(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)來推動(dòng)業(yè)務(wù)流程改進(jìn)，業(yè)務(wù)流程改進(jìn)推動(dòng)IT的建設(shè)，流程和IT融合，IT建設(shè)和實(shí)施過程中又進(jìn)一步固化流程，通過IT系統(tǒng)的建設(shè)和實(shí)施加快流程和標(biāo)準(zhǔn)規(guī)范的落地。先固化，再優(yōu)化，持續(xù)改進(jìn)。華為公司推行實(shí)施的ISC和IPD，中興推進(jìn)的HPPD和項(xiàng)目化運(yùn)作基本都是這種模式和思路。在面對市場競爭需要快速高質(zhì)量交付的時(shí)候，必須有整合高效的端到端流程，在端到端流程下沒有割裂的部門，更沒有割裂的系統(tǒng)。

BPM的推進(jìn)和建設(shè)任重道遠(yuǎn)，因?yàn)槠浔举|(zhì)是一個(gè)業(yè)務(wù)問題，而非系統(tǒng)問題。

BPM系統(tǒng)實(shí)施的兩個(gè)層面

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二是對于企業(yè)內(nèi)部的很多職能管理部門，如審計(jì)部門，風(fēng)控部門，流程管理部門等，這些部門本身不承載核心業(yè)務(wù)價(jià)值鏈上的單據(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ì)的時(shí)候，也要注意到最好采用子流程的模式進(jìn)行分層建模和設(shè)計(jì)，即對于BPM流程的頂層重點(diǎn)是自動(dòng)化的端到端業(yè)務(wù)流，而對于下層才是人工審批流流程，否則一個(gè)完整的端到端BPM流程將很難進(jìn)行后續(xù)的執(zhí)行監(jiān)控。

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

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

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

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

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

其一：企業(yè)在引入BPM的時(shí)候往往已經(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)思想往往會(huì)導(dǎo)致遺留系統(tǒng)要完全下沉為獨(dú)立的業(yè)務(wù)組件并提供服務(wù)能力，而這個(gè)架構(gòu)層面的改動(dòng)和影響企業(yè)往往沒有魄力去做，當(dāng)然其本身帶來的改造量也相當(dāng)大。

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

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

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

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

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

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

01-流程建模

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

02-服務(wù)識(shí)別

其中包括了組件識(shí)別，要明白最終的業(yè)務(wù)活動(dòng)和交互集成最終都需要調(diào)用底層業(yè)務(wù)系統(tǒng)和組件提供出來的服務(wù)能力?；诳缦到y(tǒng)交互流程分析的思路才能夠分析和識(shí)別出能夠用來做上層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ù)能力還是在各個(gè)業(yè)務(wù)組件里面。

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

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

04-界面建模

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

05-集成整合

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

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

BPM端到端流程整合案例

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

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

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

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

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

為了簡化這個(gè)系統(tǒng)的實(shí)現(xiàn)過程，對于服務(wù)提供部分我們采用在系統(tǒng)外單獨(dú)來實(shí)現(xiàn)，即監(jiān)控中需要查詢和查看的數(shù)據(jù)都單獨(dú)做成各種web service服務(wù)，可以在流程設(shè)計(jì)中進(jìn)行調(diào)用。而界面的可視化設(shè)計(jì)相當(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ū)動(dòng)架構(gòu)和消費(fèi)發(fā)布訂閱機(jī)制，在業(yè)務(wù)系統(tǒng)中完成某些業(yè)務(wù)后需要發(fā)出相應(yīng)的業(yè)務(wù)事件，在流程監(jiān)控實(shí)例中接收事件，并根據(jù)事件響應(yīng)進(jìn)行狀態(tài)的流轉(zhuǎn)。

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

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

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