BPM業務情境分析（1）——內部交易合并開票

上篇的姊妹篇，上個系列是由工作流程模式推業務情境，而本系列是由業務情境推運行時實現，都是頭腦風暴的總結，不都是正確的，歡迎大家指正問題。

（1） 描述

內部交易流程，完成了整個業務過程之後是集中開票的過程。開票操作是批操作，至於哪些放到一批裡面，這個規則不確定，可能由人決定，可能是一個月開一次票。

單純的從業務發生髮展角度來看，內部交易完成以後就應該是開票，以上的商務程序圖很簡單，如下：

  

展開來看，想要達到的運行效果類似於：

 

（2） 解決方案

a、 將內部交易和集中開票分到不同的商務程序上，本來這者就沒有太緊密的聯絡，因此分到兩個商務程序上也很自然。實現方式上，內部交易流程執行個體正常結束，之後由人蔘與決定哪些資料集中到一張發票上，啟用開票流程。為了流程回溯，在資料匯合的時候應該記錄內部交易流程和開票流程之間的關係。這種方案適用於內部交易流程和開票之間沒有關聯規則，需要人蔘與的情境。

b、 用多執行個體模式中的在運行時都不確定執行次數的方式來實現這個流程，內部交易流程是一個可重複執行的活動塊，這個活動重複執行的次數是在運行時外來事件決定的，可能是時間，也可能是人蔘與產生的事件。如，在某些管理方法中是月結的，即是由時間作為外來事件，描述了這種情況。

 

的流程的啟動條件是每月月初，並使能重複執行Scope塊活動，每個內部交易開始啟用一個執行線程，此內部交易流程結束後，整個Scope塊活動仍然處於使能狀態，直到結束條件‘時間到月末’成立，整個Scope塊活動結束，然後進行集中開票。

（3） 含義引申

從上面的兩個解決方案引出了一個問題，什麼樣的流程環節應該畫在一個流程裡面，而什麼樣的應該分開，這個是不是有選擇的標準？是根據實施人員的經驗來進行判斷？那麼兩個不同水平的實施人員所定製的流程的可用性將有天壤之別。目前總結的標準或者說是策略包括：

a、 流程描述、展現的含義是不是清楚。在特定流程定製工具的約束下，是不是能表達出流程的本義。

b、 資料轉換存不存在問題。在一個流程中，這個肯定不是問題，而分開了可能就有問題。

c、 流程回溯、資料跟蹤的方便性，同上面一條的道理。

除了上述的選擇標準的問題，還有一個問題不得忽視。如何保持流程之間的串聯性，說白了就是如果是自動啟用了流程，如何通知這個流程啟動，而如果是由人啟用的流程，那麼如果去通知這個人。自然的聯想就是通過訊息中介軟體，其特徵必須具備傳達的可靠性、大輸送量和回饋的準確性。微軟的建議是使用Biztalk，那麼就在這種假設下構建了如下的商務程序圖。

 

表達了粗粒度的商務程序圖，圖中每個方塊代表的是一個模組內的流程，而模組間的流程的互通性由Biztalk的能力提供，主要依賴強大的Mapping做資料轉換、抓取資料的BAM用來做資料跟蹤、訊息中介軟體的能力。

另一個問題是商務程序劃分的力度不能過小，如果還是以一個功能點為一個商務程序的話，又回到了目前功能驅動的情況了。