首先解釋兩個概念:
工作流,將工作分解成幾段不同的任務，然後通過一定的規則和過程來執行這些任務並對它們進行監控,達到提高工作效率，降低生產成本，提高企業競爭力等目的.它大多應用於辦公自動化領域.
業務流:它是企業內部資源之間的數據流動，一般通過企業資源計劃系統(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,理應包含工作流子系統和業務流子系統，而這兩個子系統既是毫無關聯的又可以相互協作，不關聯指的是少了其中的一個，另外一個都可以正常工作。相互協作指的是它們可以互相利用，更好的為企業發展服務