對于BPM軟件的實施，我們首先可以從通過BPM系統(tǒng)全新構建業(yè)務應用基于BPM系統(tǒng)進行流程整合兩個場景來討論BPM軟件實施過程中的異同。
全新構建業(yè)務應用
一個完整的BPM系統(tǒng)本身就可以理解為一個既開放，又相當封閉的SOA架構平臺。開放主要是說該系統(tǒng)能夠很好的集成和復用已有的SOA共享服務能力，封閉則是說BPM軟件可以從設計建模、到測試、到部署上線端到端的完成一個業(yè)務應用的構建�？梢钥吹饺聵嫿I(yè)務應用相當來說反而容易，這個時候沒有和企業(yè)內(nèi)部遺留IT系統(tǒng)集成和協(xié)同的麻煩。在這種情況下應用基礎數(shù)據(jù)完全可以以BPM系統(tǒng)為最初的源頭，很多跨流程的業(yè)務單據(jù)信息也直接在BPM系統(tǒng)中進行建模和設計。對于界面和展現(xiàn)即完全利用BPM軟件本身提供的一整套快捷開發(fā)工具進行，本身也不存在單獨構建一個IT系統(tǒng)時候還需進行基礎技術框架構建的問題。但是在這種場景下構建BPM，仍然存在一些問題無法解決，具體包括如下：
首先對于業(yè)務系統(tǒng)，即以工單和流程驅動的系統(tǒng)，還有就是以核心共享數(shù)據(jù)為基礎驅動的系統(tǒng)。前者類似OA，ITIL類業(yè)務系統(tǒng)；后者類似資產(chǎn)，資源管理等系統(tǒng)。注意對于后者我們期望的一個完整的全局數(shù)據(jù)模型，這個數(shù)據(jù)模型往往會應用到多個業(yè)務流程中，而不是簡單的工單。在這種情況下采用BPM軟件是很難實現(xiàn)完整的業(yè)務功能的。因此BPM更多的還是適用于流程驅動的業(yè)務應用。
其次，通過BPM軟件構建出來的系統(tǒng)往往是跨越了多個業(yè)務部門的一個端到端的業(yè)務流程管理，在這種情況可能并不會再具備原有的項目系統(tǒng)，采購系統(tǒng)，物流系統(tǒng)等嚴格的業(yè)務系統(tǒng)劃分，而是這些業(yè)務都完整的實現(xiàn)在了一個端到端的業(yè)務流程上。那么這個BPM系統(tǒng)的業(yè)務管理和責任部門是誰？這個時候我們往往找不到一個主導的責任部門，那么這個BPM系統(tǒng)后續(xù)如何推廣實施？靠IT部門的力量往往是很難真正落地的。這也是我們常說的BPM系統(tǒng)的推廣難點已經(jīng)不在技術上，而在于業(yè)務上。
最后即使是流程驅動的業(yè)務系統(tǒng)，如果期望通過BPM軟件提供的功能完全通過可配置和可視化設計的方式完全實現(xiàn)出來還是存在困難，即使有相關的規(guī)則引擎，但是仍然很難做到完全可配置的快速開發(fā)。這就自然涉及到了即使全新構建BPM系統(tǒng)，在BPM的底層仍然需要有實現(xiàn)核心能力和業(yè)務組件和技術組件，這些組件重點變成提供領域服務能力，而不是前臺界面展現(xiàn)和協(xié)同。這個點必須要意識到，否則容易理解為BPM是萬能的，啥流程都可以很簡單的建模和配置設計出來，那就大大的犯錯了。
遺留系統(tǒng)通過BPM來整合場景
這個相當于前者來說往往更加困難，困難點就再在于期望通過BPM來解決原有的端到端流程中的協(xié)同斷點，同時又需要最大化地保留歷史遺留系統(tǒng)的IT資產(chǎn)。大家看SOA架構好像覺得這個問題已經(jīng)很簡單地解決了，即歷史的遺留系統(tǒng)都會識別為組件，組件應該將遺留系統(tǒng)的業(yè)務和數(shù)據(jù)服務能力提供出來，然后通過BPM層對服務進行組合，服務進行編排，形成一個端到端的完整流程。但是這個本質(zhì)問題還是BPM和遺留業(yè)務的關系問題。
如果基于BPM是來實現(xiàn)一個完整的端到端流程，這個端到端流程在構建過程中確實可以調(diào)用遺留系統(tǒng)的服務能力，但是這個端到端流程是否涉及到單據(jù)和數(shù)據(jù)的產(chǎn)生，是否涉及到人工流程的處理？如果流程會產(chǎn)生單據(jù)和數(shù)據(jù)信息，那么根據(jù)原有IT架構這些業(yè)務單據(jù)仍然應該產(chǎn)生和存儲在遺留IT系統(tǒng)而不是BPM系統(tǒng)，對于人工流程的處理同樣的道理，仍然應該是在原有業(yè)務系統(tǒng)中統(tǒng)一處理而不是在BPM系統(tǒng)。
這個一分析清楚我們就容易理解，遺留系統(tǒng)場景下BPM進行整合，不能憑空地再找出一個BPM系統(tǒng)出來，BPM的重點是將原有業(yè)務系統(tǒng)中的單據(jù)和流程整合和集成起來，而不是替代原有系統(tǒng)的能力。最終集成的效果可以通過Portlet形式展示到門戶，而不是新增加一個業(yè)務系統(tǒng)。把這個理解清楚了，就清楚在這種場景下BPM實施的重點應該是由業(yè)務系統(tǒng)提供完整的領域服務層能力出來，而BPM重點是來統(tǒng)一實現(xiàn)界面層和展現(xiàn)，實現(xiàn)各個業(yè)務系統(tǒng)中服務能力的組合。即使在這種情況下都還需要考慮如何解決門戶層應用功能和原有IT系統(tǒng)間功能的統(tǒng)一工作臺展現(xiàn)，這個問題沒有解決好就會變成業(yè)務部門人員需要兩處處理業(yè)務，在實施層面是很難推廣的。
實施BPM有個很重要的內(nèi)容，就是應用系統(tǒng)或者叫模塊的實施，以及原有的工作流引擎是否已經(jīng)成功實施。如果這些沒有實施，那么BPM將作為為應用和工作流的基礎支撐，如果已經(jīng)實施那么就存在如何同步原有的應用數(shù)據(jù)，是棄用原有各個業(yè)務系統(tǒng)不統(tǒng)一的流程引擎還是保留資產(chǎn)進行整合的問題。對原有的IT資產(chǎn)保留的越多，你會看到BPM本身在實施過程中能夠用到的能力越是減少和退化。
對于一個已經(jīng)相當成熟的內(nèi)部IT來說，BPM還存在哪些價值和意義。
第一個方面是通過BPM來實現(xiàn)端到端流程執(zhí)行的監(jiān)控和流程績效評估，注意這本身在完整的應用架構里面就是在執(zhí)行層上面的事情，這樣可以減少和已有的業(yè)務系統(tǒng)之間的功能性沖突。
第二是對于企業(yè)內(nèi)部的很多職能管理部門，如審計部門，風控部門，流程管理部門等，這些部門本身不承載核心業(yè)務價值鏈上的單據(jù)產(chǎn)生和業(yè)務，而重點是基于已有業(yè)務系統(tǒng)能力進行的IT管控和治理，因此對于這些部門新建設的業(yè)務系統(tǒng)是最適合通過BPM工具來完成的。對于BPM本身在進行流程建模設計的時候，也要注意到最好采用子流程的模式進行分層建模和設計，即對于BPM流程的頂層重點是自動化的端到端業(yè)務流程，而對于下層才是人工審批流流程，否則一個完整的端到端BPM流程將很難進行后續(xù)的執(zhí)行監(jiān)控。
當前很多企業(yè)就IT成熟度來說都沒有到能夠理解和實施BPM的程度，這也是為何很多企業(yè)的BPM實施僅僅變成了一個企業(yè)內(nèi)部的統(tǒng)一工作流引擎平臺實施的原因。
對于一個BPM項目的成功實施，最重要的就是分析和建模方法的轉變，如果仍然是按照傳統(tǒng)的方法已經(jīng)將業(yè)務分解到多個業(yè)務系統(tǒng)，那么面對的又將是遺留系統(tǒng)流程整合問題，而不是直接通過BPM+SOA方式來構建業(yè)務系統(tǒng)的問題。流程驅動IT是分析建模中的一個重要點，從流程開始自頂向下分析和分解，劃分組件和識別服務；再從組件開始自底向上進行服務組合和編排，形成應用或流程。這是一個完整的閉環(huán)路線，沒有前者我們就很難真正的保證我們最終劃分的組件，識別的服務能夠真正應用到后續(xù)的服務組合和編排上面。
不應該太早地進入到業(yè)務系統(tǒng)的概念，對于SOA整個咨詢和建模方法論里面的，我們是弱化業(yè)務系統(tǒng)的概念，而是進一步強化了業(yè)務組件和技術組件的概念。這樣做的目的主要是在SOA參考架構里面原有的業(yè)務系統(tǒng)已經(jīng)變成一個弱邊界，業(yè)務系統(tǒng)僅僅是多個組件的靈活組合或組裝；其次當我們以業(yè)務系統(tǒng)出發(fā)進行考慮的時候，我們思維里面仍然是縱向架構模式，但是當我們以組件，服務和流程角度來考慮的時候，思維里面是一種橫向分層架構模式。對于橫向架構模式本身重要的目的就是要打破傳統(tǒng)業(yè)務系統(tǒng)縱向的強劃分。
上面談的是BPM實施中相當關鍵的一點，把這點想清楚了就清楚了BPM流程建模的真正意義。在流程建模過程中我們是按照流程驅動的思路在分解流程，在規(guī)劃流程應該涉及到的流程環(huán)節(jié)和活動節(jié)點，在設計每個流程節(jié)點應該業(yè)務自動化和人工化處理的事情，在考慮相關的流程節(jié)點是否應該有前臺的展現(xiàn)和交互界面，表單所涉及到的數(shù)據(jù)對象結構；這塊想通了我們才會進一步考慮這些需要的數(shù)據(jù)或業(yè)務規(guī)則邏輯處理能力究竟應該由下層的哪些業(yè)務組件或技術組件來提供這些服務。
上面這句話如何理解？即就業(yè)務組件或技術組件本身來說還是按業(yè)務域，數(shù)據(jù)或技術域分開的，底層是組件化和服務化的，但是這些組件本身更偏服務能力提供，這些組件并不關系前端對應了什么流程，應該有什么樣的人機界面交互，這些組件的職責相當簡單，就是提供業(yè)務或技術服務能力而已。但是在組件或服務的上層，我們最終涉及完成的前端或業(yè)務流程流轉所需要的界面卻是不分業(yè)務組件或系統(tǒng)的，其本身就是流程化和一體化的，這些前端界面，交互和展現(xiàn)不屬于任何一個業(yè)務系統(tǒng)，而應該屬于BPM系統(tǒng)。
這就是一個理想化的BPM構建的方法和思路，把這個思路想明白后做過傳統(tǒng)IT系統(tǒng)開發(fā)的就比較容易理解為啥BPM系統(tǒng)實施如此困難，為何BPM系統(tǒng)實施看到的很多都是單純的HWF人工工作流引擎的實施。這個的本質(zhì)就是分析和建模思路沒有轉變，沒有從傳統(tǒng)圍繞業(yè)務系統(tǒng)為核心轉換為橫向的圍繞組件和服務為中心來思考。
BPM構建和實施層面
當前各個國際大廠商的BPM工具和產(chǎn)品套件已經(jīng)相當成熟，但是在這里要說明的是BPM軟件產(chǎn)品雖然可以靈活地通過配置、可視化建模設計方式來構建業(yè)務系統(tǒng)前端流程，但是其配置的繁瑣和復雜程度往往超過了直接寫代碼的模式。也就是說很多時候可配置的方法雖然看似很美好，能夠靈活地應對業(yè)務的變化，但是很多時候往往開發(fā)配置效率是降低的，同時對于BPM本身新設計完成的流程仍然涉及到需重新發(fā)布的過程，也遠遠無法達到我們期望的零部署模式。
一個BPM建模和執(zhí)行工具平臺，更多地是從服務層開始流程整合，而不是從遺留系統(tǒng)的界面層。如果已經(jīng)有成熟的業(yè)務系統(tǒng)和前端功能界面，那么實際問題僅僅是兩個系統(tǒng)的兩個功能間的業(yè)務或數(shù)據(jù)交互問題，這類問題是不需要用BPM工具來解決的，直接用到ESB服務總線這層就足夠了。對于BPM平臺一定要注意到其擅長的并不是單個業(yè)務系統(tǒng)內(nèi)部的功能構建，如果一個業(yè)務系統(tǒng)本身不涉及到外部交互，僅僅涉及到內(nèi)部功能或數(shù)據(jù)流轉，我們其實強烈不推薦采用BPM產(chǎn)品和建模方法，能夠有人工工作流引擎就足夠了。一個稍微復雜點的業(yè)務如果全部用BPM可視化建模和配置來實現(xiàn)出來，超過幾十個節(jié)點是常事。這種BPM建模維護的難度反而不如邏輯清晰的源代碼。不要把BPM產(chǎn)品理解為快速開發(fā)平臺，雖然很多BPM產(chǎn)品想朝這個方向走，但是確實不是BPM擅長的事情。
真正BPM產(chǎn)品最擅長的還是在跨系統(tǒng)的業(yè)務流程場景出現(xiàn)的時候，這種業(yè)務場景顯然放在任何一個已有的業(yè)務系統(tǒng)都不合適，但是這種端到端流程本身在業(yè)務上又需要統(tǒng)一管理和管控。在這種場景下是最需要BPM的能力，即前端交互和流程流轉統(tǒng)一規(guī)劃和設計，原有的業(yè)務系統(tǒng)僅僅為上層提供數(shù)據(jù)和業(yè)務服務能力。
大家可以考慮下，如何我們要構建一個企業(yè)電商的客戶自服務平臺，這個自服務平臺需要能夠方便客戶實現(xiàn)對從訂單到交互的全流程跟蹤和管理。這種平臺往往本身并不產(chǎn)生大量的基礎數(shù)據(jù)和存儲邏輯，而是需要大量的調(diào)用或系統(tǒng)企業(yè)內(nèi)部已有的CRM系統(tǒng)，ERP系統(tǒng)，PDM系統(tǒng)，MDM系統(tǒng)的能力。對于這些遺留系統(tǒng)能夠提供的能力根據(jù)客戶需求和流程的需要進行組合和編排。同時基于這些能力，重新設計端到端的前端界面交互和流程流轉，這就是一個BPM相當理想的實施環(huán)境。從這個層面來說企業(yè)內(nèi)部常見的風險管控系統(tǒng)，合同端到端跟蹤系統(tǒng)，財務共享服務平臺等都是比較適合BPM的應用場景。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文網(wǎng)址：http://www.oesoe.com/html/consultation/10820617821.html
相關文章
