ERP系統中的工作流程和業務流

首先解釋兩個概念:

    工作流程,將工作分解成幾段不同的任務，然後通過一定的規則和過程來執行這些任務並對它們進行監控,達到提高工作效率，降低生產成本，提高企業競爭力等目的.它大多應用於辦公自動化領域.

    業務流:它是企業內部資源之間的資料流動，一般通過企業資源計劃系統(ERP)對企業中的物流、資金流和資訊流進行全面整合管理.

但是在實際的企業中，常常有些需求，需要在OA系統和ERP系統中來回切換,比如：採購用款申請，付款，做憑證則是ERP系統中的功能（如）。

    

此外,企業在利用oa系統進行工作流程審批後,會產生一些業務資料,而這些業務資料又可能是ERP系統中的外部資料源，比如的採購費用申請的資料。為了避免資料的重複且保證資料來源的唯一性,就產生了工作流程系統和業務流系統整合的需求.

目前常見的整合方法，歸納起來兩大類

1):基於介面的整合封裝模式，利用OA,ERP各自提供的的介面（這個介面的含義包括：資料庫表結構，web service介面，其它自訂介面）,實現兩資料之間的互訪.

2):基於中間表的互訪模式,以相同的資料模型儲存不同的系統之間的共用資料, 通過直接對兩系統的資料表進行操作的方式，實現不同系統間的資料訪問，以及資料的一致和即時傳遞.

由上分析可知，這種整合還是有難度的，至少需要不同程度的二次開發，如果是採用二次開發，我個人傾向於web service,web service就是我們常常聽到的soa架構,它是一種整合各種服務的架構平台,核心點就是實現服務和技術的完全分離,從而在最大限度上實現服務的整合和重組.(注，如果在erp開發中，我是強列反對用soa架構的，我一直覺的soa只用在一些特定的業務情境，最適合的莫過於對外提供服務介面),為什麼不採用表呢？因為
ERP的審批流還比較特殊，它流程的執行實際上就是控制權在兩個子系統之間的轉移,如果是基於表的互訪問模式，這是一種緊耦合的整合方式,它將影響系統的靈活性和擴充性,阻礙商務程序的調整和最佳化,不利於企業的發展.

最近在研究國內的一個開源系統FireWorkflow(http://www.fireflow.org),並對它的原始碼進行了分析(先做個廣告，接下來我會把源碼分析的過程寫成blog,供大家交流，指正).

Fireworkflow提到的一些理念，甚合我意,比如，一個普通的請假流程

    

 

該流程圖的執行流程說明如下：

首先，工作流程子系統啟動一個新的協調流程執行個體，然後建立一個新的任務執行個體——“申

請”，並將控制權交給業務子系統，業務子系統等待申請人填寫表單。申請人完成表單後，控制權再次被交給工作流程子系統，由它決定下一步的路由。這個工作是由稱為Synchronize r 的元素完成的(圖中標有"S"的圓圈)。在這個業務樣本中，它通過計算得出下一步操作是“部門經理審批”。於是建立一個名字叫做“部門經理審批”的任務執行個體，並將控制權交給業務子系統，業務子系統等待部門經理做審批操作。

圖中的工作流程邏輯和商務邏輯分得非常清晰，審批之後執行哪個業務操作是由工作流程邏輯子系統的一個“操作”決定的。商務邏輯子系統中的“審批”操作僅僅負責完成業務特定的邏輯，其他的與之無關,這正是我所想要的結果，一個好的erp,理應包含工作流程子系統和業務流子系統，而這兩個子系統既是毫無關聯的又可以相互協作，不關聯指的是少了其中的一個，另外一個都可以正常工作。相互協作指的是它們可以互相利用，更好的為企業發展服務.