企業級業務系統（BPMS）特色分析與應對思路

摘要

一、文中分享了對於企業級管理軟件的理解。

二、文中整理和分析的業務流程管理系統的特徵。

三、文中針對討論的風險和挑戰，也提出了應對的方法，領域內業務系統的產品研發難度歷來不在使用的技術上，而在於對領域內業務的理解程度和架構師的設計功力。

四、分享了Merge開發平臺信息，做爲架構設計思路的一個案例，可用於交流和參考。

如有不合適內容，歡迎溝通指正。

參考資料： 

1. 可變性設計
   

2. Merge開發平臺（http://merge.wang/wiki/）
   

分析內容

業務系統的核心功能

數據化和邏輯化兩點構成了業務系統中的核心功能，信息化仍然是業務系統的主題，爲用戶提供溫馨便捷的操做體驗，經過系統的使用提高業務執行效率，下降企業運行成本也還是企業對業務系統需求最痛的點。

1. 業務數據化

將企業運做過程以結構化數據在系統中進行存儲，一方面做爲信息化檔案長期備查，另外一方面提供給系統用戶做爲業務執行的支持信息。

通常分爲字典類數據、基礎類數據、業務類數據、日誌類數據

下圖是MES（製造執行系統）系統的業務場景，MES系統的主要痛點就在於支持生產相關業務活動的執行，創建信息化標識（一維碼、二維碼、RFID等），並採集生產活動過程當中產生的各類信息（包括並不限於人機料等方面），併爲客戶提供執行狀況分析報告。

2. 業務邏輯化

在複雜的業務場景中，基於客戶提供的需求，對各個業務環節的工做內容進行支持和約束，將以人治爲核心的工做方法進一步升級爲系統化、規範化、流程化的工做流程。

以系統做爲媒介，將業務流程中的參與者連接在一塊兒，分工協做完成總體業務流程工做。

下圖是將MES系統進行的數據流圖分析，真實項目中的業務場景會更加複雜和細緻。

業務系統的風險與挑戰

3. 業務邏輯的不穩定性

企業內的組織結構、業務部門、運做模式是一個實時都在變更的，隨着人員流動、生產設備的購置、新系統的啓動、管理理念的升級、運做模式的變化等等，都會在具體業務執行層面被體現。這些變化是客觀存在的、不可避免的在某一時間被識別、被需求、被處理的。

需求規格說明書獲得用戶的確認，僅表明在確認的時刻，系統的設計能夠勉強的知足業務運行中客戶提供的不完整的業務需求。而業務的變化卻不會所以而中止，仍然會進行不間歇的量變，直至產生質變，突破了原定需求範圍和內容。

對於研發團隊而言，這是個漫長而痛苦的過程，100天的需求變動可能會被拆分爲20個（或更多）5日內的小型需求變動，以間斷的方式被提交——有一種溫水煮青蛙的感受。研發成本會所以而難以控制，甚至研發團隊被拖垮。應對這個問題，主要依賴研發團隊的項目經理對於需求變動內容的把控，系統設計師對於業務的理解成熟度，以及前期過分設計的程度，高級設計師會在設計過程當中增量設計25%，以應對基於業務經驗識別的潛在業務變化。

4. 業務的不完整性

通常狀況下，新實施的業務系統都會和企業內的遺留系統有業務聯動，創建不一樣形式的業務接口。新系統所負責的業務多是閉環業務，也多是非閉環業務，可能缺失業務起點或業務終點。在跨系統業務過程協做過程當中，大機率會出現業務反覆、信息反覆、業務逆流程等需求場景。

5. 業務權限化需求

業務系統隨着業務複雜度提高和參與協做人羣或角色的增長，對權限的控制需求也逐步的提高。通常來說一個業務單據的處理過程包括建立環節、審批過程和生效處理三個階段。

建立過程是單據的發起環節，這個階段系統主要進行數據有效性驗證、格式驗證、數據存儲等處理。

審批過程相對來講較爲複雜，通常會分爲若干級審批，或理解爲若干個工做流環節，單據信息可能在建立階段填寫完成，也可能在審批過程當中獲得補充和修正，審批過程當中各個環節經過審批結果「贊成」或「駁回」，控制單據流程的後續走向，在工做流程設置中存在分支的狀況下，單據的某個業務屬性或業務邏輯也會影響工做流的走向。

審批過程常見如下的狀況：

• 靜態工做流，即工做流環節的數量和審批人的角色在系統內預置，單據可預知後續工做流程的信息。

• 動態工做流，即工做流環節數量不肯定，根據系統邏輯動態構建單據工做流，後續工做流程信息依賴系統邏輯設計而定。

6. 業務邏輯碎片化

處理複雜的業務流程時，設計師常採用分治法將一系列複雜的問題，分解爲許多細小的業務流程，再根據其業務相關性將業務流程分爲幾個業務模塊。

在複雜的業務場景中，業務模塊內也會有橫跨數個業務部門的業務流程，此時一個含義完成的業務流程會被進一步拆分爲各個含義更小，更不完整的小環節。

舉個例子，在一條設計有十幾到工序的流水做業的生產線上，通常只有下線工位的產出是完整的產品，可在前幾道工序感覺就會很模糊，其工序的內容可能僅是要將待加工的原材料或零件調整一下襬放的位置或方向。

7. 業務流程的複雜性

有人說作一個操做系統都要比作一套業務系統簡單，我十分贊同這句話，通過了一個個量身定製的項目研發工做後，切身的感覺就是——慾壑難填。

企業的業務流程體現了企業的管理目標和思想，其複雜性常有一下幾個方面：

• 多變分支，也能夠理解爲多場景切換邏輯。總體業務流程可模擬爲一系列相對獨立（聚焦內容、便於理解）的業務場景，而單據中的某項屬性和某個業務邏輯，會引導系統爲此單據由一個業務場景轉向另外一個業務場景。這期間的連接咱們理解爲業務流程，而業務流程隨着管理方法、業務部門的變化而變化。

• 業務依賴，即業務間的邏輯依賴，須要考慮爲主從依賴或業務依賴，前者指大業務流程的變化與其對應的子級業務流程的聯動邏輯或相反的約束邏輯。後者則通常指業務操做的一些涉及到其它業務、模塊依賴邏輯。能夠理解爲樹型的數據結構，父節點的某項業務操做與其對應的子級節點的聯動處理，或對同級別其它節點的邏輯依賴。

• 可逆/可反覆，即逆流程和以後的正向流程運行，出於成本考慮，通常狀況下設計師會更多考慮系統內的業務閉環，業務流程/場景的轉換和控制邏輯。逆流程常被視爲費力不討好的低價值工做。通常狀況下能夠考慮在25%的過分設計內體現一些逆向流程的設計，系統上線初期或中期，系統數據不穩定，業務人員使用不熟練，系統各類問題層出不窮，逆流程設計在其中爲實施團隊提供了更多回旋的餘地和可能，同時會必定程度上減小數據運維爲研發團隊帶來的成本損耗。

8. 應用工做流的機遇和挑戰

工做流模式是用戶相對於傳統的數據調度模式，有了新的體驗——系統會在制定好的邏輯化驅動各個業務單元的資源（人、機、料、系統）進行業務活動的處理和推動，這其中的關鍵點在於「驅動」兩個字，而現實每每是骨感的，系統更多的狀況下僅僅是在機械的執行編制好的代碼，僅此而已。

機遇，經過人工智能完成資源（人、機、料、系統）調度

在這方面人們作了不少的嘗試，但絕大多數狀況仍然是系統在機械的執行，我理解的人工智能在調度資源方面，要起到幾個方面的做用，分別是：決策、驅動和監督、分析和彙報。

決策：直到能決策的時候，人工智能才稱得上是智能。當決策的人和機器獲得了一樣多的信息的狀況下，機器是能夠得出正確的決策結果的，或者是次優解或可接受的解。

驅動和監督：調度角色將指令發送至各個執行單元，並監督其適時響應、彙報進度。

分析和彙報：基於任務運行信息，進行整理分析、生產進展狀況報表。

挑戰，工做流與業務環節的連通性設計。

隨着工做流模式的設計不斷完善，基本能夠應對常見的任務建立、調度、執行、監控、完成等控制。但做爲業務系統，工做流避不開的問題在於如何處理和業務單據的關係，或者反過來講，業務單據如何配合工做流的設置完成處理過程。

我的建議：操做體驗方面由工做流爲單據引導用戶進入，設計方面由單據向工做流靠攏，由其時業務單據的工做流模式應用比重較大的系統，能夠將工做流的模式做爲單據設計的預置模式——即單據（系統功能或模塊）從設計之初中就認爲是創建在工做流上運行的。

應對方案

針對上述種種困難和挑戰，要應對也不是沒有辦法。復仇者聯盟電影傳達出這樣一個觀點——不要試圖解決尚未出現的敵人，這個觀點應用在軟件行業也是合適的，但也不意味着不作任何的準備，咱們更喜歡未雨綢繆。

在這方面個人想法提及來很簡單也容易理解——以可變應萬變（這部分具體實現思路在後面 =^_^= ），不管多複雜的設計，一旦寫完就進入了「固化」狀態，除非進行再次的編輯，若設計過分的幅度比較大時可能達到觸類旁通的效果，但一樣付出了更多的成本（開發人月，以及複雜設計所帶來的一系列不穩定和風險因素），壓縮了原有的利潤空間，客戶也不情願爲了避免肯定會出現的場景投入更多的資金。

應對方法

1. 領域建模與業務流程設計

這部分時老聲常談，但這部分確實最重要的一部分，也是變數產生的起點。不管是作產品研發仍是項目實施，在需求分析階段的把控永遠是最重要的，這裏的蝴蝶扇一下翅膀，在後續就是一陣大風。而這部分工做十分依賴項目經理或負責人對於業務領域需求的掌控程度，不一樣的負責人的拆分方式可能差異會很大，甚至同一我的在不一樣時期的拆分結果都是不一樣的。

因此咱們要承認這一點，即指導後續工做進行的業務設計極可能是不完整甚至不正確的，但在問題出現以前，只能認爲其是正確的。

2. 可變性設計

設計的目標或宗旨是在性能和設計之間的權衡，有些設計從複用性方面考慮，有些設計從可用性方面考慮，有些設計從可維護性方面考慮，而面對客觀上必定會產生而主觀上又不可預知的需求變動，則能夠經過可變性設計方法，進行對變化進行預先設計和管理。

可變性設計方法，結合到某一個領域的項目研發和產品研發設計中，其有效性十分依賴設計團隊對目標業務領域需求和其變化規律的瞭解程度。

在對要進行設計的流程進行分析後，可識別出一部分可能會變化的流程或環節，可能包含如下幾種狀況：

• 可預見大機率會變化且可以預見後續分支的流程。

• 需求定位模糊大機率會產生業務變動的環節。

• 流程設計中已經涵蓋的流程分支斷定環節。

對於變化，咱們從將其視爲不可預知的、突發的狀況，改變爲視其爲客觀存在的，會不按期出現的存在，將其做爲設計工做的一部分處理，將其做爲一種常規性業務進行管理。

3. 業務流程能夠高效率開發

即使應用了一系列的方法以應對未知的需求變動，但實際工做中的需求變動仍然會在咱們計劃外的某一點出現，而業務架構如何可以高效的應對，並完成業務功能的重構開發，對設計架構的複雜度控制和可維護性提出了更高的要求。

4. 業務流程化整爲零，逐層精化

這個環節是整個應對方案的核心，從領域建模開始，全部的設計資源幾乎都處於不穩定的狀態，經過管理手段能夠進行必定程度的版本控制，但從架構設計的角度考慮，如何可以支持需求、設計等材料在版本更替過程當中，使開發的資源可以平滑的完成過渡，也是對架構設計的一方面挑戰。

逐層精化點在「層」，而每向上抽象一層，業務性越強，實現細節越少，每向下一層，業務性越弱，實現細節越多。層級過少，設計體現更加剛性，可變的程度較低；層級過多，會產生更多的「節點」，增長了治理的難度。

架構設計（以可變應萬變）

思路很簡單，實現有難度，應用很靈活，設計是重點。前期重注流程開發，後期注重流程使用。

1.設計思路

• 代碼直到執行的時候，才肯定執行的內容。

• 處理資源（代碼流）能夠熱插拔，在系統服務運行中識別、修改和調用。

2. 案例參考

在Merge開發平臺（http://merge.wang/wiki/）中，業務流程以活動圖的形式進行設計和使用，活動圖的節點涉及數據處理和流程調用相關操做，以數據處理爲設計核心，UML活動圖設計過程爲主要的操做體驗。

設計結果以json格式存儲，做爲運行資源被所部署的平臺識別和使用。