工作流引擎你所不知道的事--開源軟體誕生16
淵遠流長的工作流--第16篇
用紀錄檔記錄「開源軟體」的誕生
【點亮星標】----祈盼著一個鼓勵
博主開源地址：
工作流定義
工作流誕生於企業管理和辦公自動化的需要，它是針對日常工作中的業務流程管控而產生的一個概念。目的是將工作步驟分解成的任務，根據一定的原則和邏輯來完成這些任務並加以監控，從而實現更加有效的業務流程管理、更加規範的業務制度執行。
工作流不是審批流
看了工作流的定義，可能你認為已經懂了或者你認為還很抽象，沒關係，我們先來探討一個常見的理解誤區：工作流就是審批流。既然說了是誤區，那這個理解肯定就是錯誤的。只是很多人在接觸工作流時往往都是通過OA裡面的審批流，所以才有了這個誤區。當然審批流肯定是屬於工作流，但它只是工作流的一個應用。
下面我們再次回到工作流上，其實這是兩個詞的組合，一個是工作、一個是流程，所以從特點上已經表露無遺。首先它得是要完成的一個工作，一定是企業對人的一個管理要求，喝水它不是工作。其次這個工作必須要經歷一個流程才能做完，並且在過程中要發生資料的變化，也就是說流程中必須要做點什麼影響它。比如說上班打卡，它就不是流程，不需使用工作流。
到此，我想大家應該已經比較清晰為什麼工作流不是審批流，因為審批只是我們日常工作中的一項工作而已，其他的工作只要涉及流程，它也是工作流，可以使用工作流系統實現管控。
工作流的應用
（1）主業務流程：訂單、採購、合同稽核、供應鏈管理、倉儲管理等
（2）行政管理類：出差申請、加班申請、請假申請、用車申請、各種辦公用品申請、日報週報等
（3）人事管理類：員工培訓、績效考核、工資發放流程、職員招聘等
（4）財務相關類：收付款、發票管理、費用報銷、計劃預算等
（5）客戶服務類：客戶資訊管理、客戶投訴、售後服務等
（6）特殊服務類：ISO管理流程、品質管理流程、進出口報關流程、物流跟蹤處理流程等
舉個栗子
上面說了很多工作流可應用的場景，下面我們就來找一個典型的案例來分析一下整個處理過程。以計劃預算的制定為例來講解。正常每個公司都會在年底制定一套計劃預算來管控第二年的收入和支出，以保證按計劃完成一年的目標。一般流程如下：
（1）公司一般會制定一個頂層的規則，包括預算上限、預算事項和科目、預算制定的顆粒度等，然後下發。
（2）公司的所有部門會根據公司制定的規則以及部門內部自己的規劃制定一個部門預算，包括：人力、行政、財務、資訊、業務等各個部門。
（3）制定完成後，上報上級領導審批，並通過幾輪商議並敲定。
（4）各部門的預算確定後，會有專人彙總預算並核對公司的規則，接著交給董事會審批。
（5）稽核後，會有專人負責重新下發給各部門以及內部發文通知。
計劃預算這個例子，比較典型，因為它包含了審批、包含了業務處理、甚至包含了不同系統的共同作業。由此可見，涉及到使用工作流的場景往往是業務或邏輯複雜場景，工作流適合幫助企業把複雜的事情變得簡單，把邏輯梳理的清晰有序。
工作流系統如何實現
由於篇幅原因，下一篇文章我會具體介紹工作流的框架，以及如何整合部署。本篇我就先用自己的語言總結一下，要實現一個工作流引擎都需要哪些功能。
（1）流程圖，不管是使用通用的工作流引擎還是自己開發，我們一定首先需要指定流程，指定流程的方式多種多樣，可以採用設定的形式，也可以直接通過畫流程圖的方式（最終也會形成一個可資料化的流程xml）。不管用什麼方式這一步是核心，告訴系統你的流轉過程。
（2）資料庫，所有的流程資訊、節點資訊、任務資訊、歷史資訊、使用者資訊都必須儲存於資料表中，每一個操作也會直接反饋給表中的資料。
（3）任務的使用，任務是一個重要的概念，流程流轉的是任務，我們無需記錄任務的具體內容，這是業務系統需要考慮的事情，我們只需要記錄任務的流轉過程即可。可以給任務做個分類，分為人工執行的和系統自動執行的。
（4）流程變數，這個概念也同樣的重要，因為沒有一個流程是絕對固定的，它的流轉分支以及邏輯判定必須是動態的才有意義。而動態也就意味著必須在流程啟動時才能確定某些資料的值，這個值的傳入就必須要通過流程變數實現。
（5）歷史記錄，每一個已經流轉完成的流程都需要詳細的歷史記錄，這是必須的，可以排除風險並確定責任。
（6）可呼叫的工具類或介面，流程中執行的每一個操作：啟動、終止、通過、退回，都需要使用者手工或系統自動觸發，所以要提供所有可執行的API。
在很多開源的流程引擎框架裡，並沒有考慮太多的國內的使用需要，所以我們在設計或客戶化我們的工作流系統時，要考慮到各種特殊情況。比如：撤回、終止、回撥等。
後記
如果您對我們正在做的開源軟體感興趣，歡迎各種形式的合作，作為貢獻者或直接加入我們！讓我們一起打造一套開源的企業級資訊化解決方案。
【碼雲】或【GitHub】搜尋「赤龍ERP」點選星標，亦可加入我們！ 讓我們從小開始做點偉大的事！與開發者交流 kzca2000