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