本文作者從一個合同審批流程角度對工作流的設計原理進行了介紹，供大家一同參考和學習。
寫這篇文章的意圖並不是為成熟工作流引擎知識徒增一篇文章，也不是深入介紹JPBM、Aactivity等工作流引擎技術和數據庫結構。而是因為當前轉ToB的產品經理多了，但提及這塊兒就很難深入。雖然有不少介紹工作流的文章，但大多是直接介紹BPM的體系，很少有文章從業務角度出發介紹為什麼這樣設計，下麵我就試著從一個合同審批流程角度介紹工作流的設計原理，希望對大家有幫助。
工作流簡介
工作流（Workflow），指“業務過程的部分或整體在計算機應用環境下的自動化”。是對工作流程及其各操作步驟之間業務規則的抽象、概括描述。在計算機中，工作流屬於計算機支持的協同工作（CSCW）的一部分。其主要解決的主要問題是：為了實現某個業務目標，利用計算機在多個參與者之間按某種預定規則自動傳遞文檔、信息或者任務。說白了就是按照怎樣順序、做什麼、由誰來做。
1993年工作流管理聯盟(Workflow Management Coalition，WfMC)作為工作流管理的標準化組織而成立，標志著工作流技術逐步走向成熟。WfMC對工作流給出定義為：工作流是指一類能夠完全自動執行的經營過程，根據一系列過程規則，將文檔、信息或任務在不同的執行者之間進行傳遞與執行。工作流無論是減少人為操作，提供工作效率，還是優化線下業務流程，提高管理水平均有很大的幫助。
工作流經歷了第一個階段的“無紙化、重覆工作、流程孤島、系統孤島、數據孤島”過程，目前正在實現“智能化、效率質量提升、外部數據整合、消除信息孤島、內部數據整合”的第二階段。
1. 合同審批流程
所有的信息化都是為瞭解決業務上需求，首先我們瞭解企業合同管理制度中審批流程是如何完成的。下麵是一個比較通用合同審批流程圖。
- 首先所有可以起草合同併發起合同申請流程的人，即使合同承辦人；
- 合同承辦人將合同提交其部分負責人（實際情況可能部長或副部長均要審批、或順序審批、或任一審批即可）來審批，大部分還有內部審核人把關再提交其部門負責人；他們都有權退回（不合格需要修改）或駁回（徹底不簽了）；如果承辦部分負責人同意，可以選擇相應的會簽部分同步開始會簽，如財務部、技術部等等。有些事必須選擇，如涉及金額合同必須選擇財務部。
- 會簽部門就更熱鬧了，三五個部分並行審批，部門內部有各自審批流程，而且均可以同意、退回，有的需要退回合同承辦人，有的需要退回承辦部門負責人。而且有的情況是全部同意才能算通過，有的是三分之二同意才能算通過。
- 必須經過合同歸口部門審核。一般是法律部或風險部，他們也需要退回，可能是審批過的任何一個節點，返回來的方式可能是從來一遍，也可以直接返回退回人。這裡還有“是否重大合同”和“是否使用合同範本”的業務屬性判斷。
- 根據業務業務類型和管轄範圍，自動選擇分管領導。根據授權情況判斷合同流程是否到此終止，當然分管領導可以退回、駁回等。
- 總經理可能會簡單些，同意、退回、駁回。審批通過後自動觸發用印或上報上級公司的審批流程。
這算是一個常規的大企業合同審批流程，如何利用信息化實現一份具體合同審批流程？簡單，將每一步及其規則固化帶代碼中。如果換一份合同？如果換一種業務？如果規則變動？如果需要每個節點觸發不同業務，顯現不同信息？如果人員變動了？如何組織機構變動了？這個時候就需要我們抽取其中的共性，將其引擎化，能夠通過配置實現系統的靈活性。
2. 工作流引擎設計
下麵我們從業務的角度逐步抽象出工作流引擎的設計。遇到複雜問題一方面我需要按照第一性原理尋找最本質的需求，另一個更常規的思路就是分解，對問題進行分類分級處理，各個擊破。其實，還有一種完全交個用戶自己選擇，如釘釘審批流程。但大型企業流程的作用除了提高效率，還需要減少人為操作、控制合規風險，完全交個用戶選擇的自由流程使用較少。
從上文的流程圖中，可以簡單抽取出流程、環節、連線、角色、組織等主要對象，還有一個就是與外部（業務）發生關係的接口。它們之間簡單的關係就是流程由環節和聯繫組織，環節上有角色和組織屬性，接口可以在連線上，也可以在環節上，下麵一步步解釋。
（1）流程分類（流程太多）
如果設計一個通用的工作流引擎，面對的各種業務流程、審批流程可以說成千上萬，怎麼辦？首先想到的就是對流程進行分類，對相同類型的流程進行統一處理，降低流程需求複雜度和耦合度。目前業務操作不同進行分類的，如請假流程、報銷流程、合同審批流程等等。
（2）自定義具體流程（一種流程還是太複雜）
如何合同審批流程，不同企業、不同種類，審批流程還是不一樣。繼續細分類別可以解決問題，但分到最後流程就需要多少個環節以及之間的關係是什麼還是不確定，交個用戶和運維人員搭建流程，由他們自己定義。 定義流程的名稱、流程的環節、環節順序（連線）、環節參與人員等。
（3）自定義具體環節（環節定義最複雜）
環節需要具體到做什麼工作、誰來做、怎麼做等，但這三個主要因素都是變量，做什麼工作（即查看什麼表單，同意、退回、駁回等），誰來做（通過組織、角色、群組框定出參與的候選人），怎麼做（並行、串行等），這些都需要通過配置實現。另外，需要配置出發的其他業務事件等，如何合同審批完畢後自動生成合同編號。
（4）環節間的連線
上文提到在實際業務審批中，涉及金額的合同必須經過財務審批，說明流程的走向與業務屬性發生了關係。因此，我需要設計在節點間連線上設置業務條件，或設計可以進行業務判斷的節點，滿足這種業務需求。
（5）流程實例（每個流程）
上面講到的都是配置一種流程，即將審批制度步驟和規則放到系統中，但具體的一份合同審批流程信息即流程實例必須記錄下來，一是為了留痕，再者就是流程審批中發生退回和返回需要用到這些數據，每個流程審批的業務唯一標識，每個環節實例需要記錄誰在什麼時間、什麼意見等。
（6）流程版本（流程變更）
業務上流程變更了怎麼辦？這就需要對流程進行版本管理，可以實現流程變更前已經提交的流程，按照之前的版本繼續進行，而流程變更後提交的流程按照最新版本進行。
（7）流程關聯
本單位的流程審批完畢後，符合上報條件需要啟動上級工作流程；合同審批流程中，每個會簽部門內部的流程本身就比較負責，需要為會簽部門搭建單獨的審批流程，嵌入到合同審批流程中。以上兩種情況就涉及到流程關聯和子流程的問題，需要進行設計。
（8）流程設計器
以上的操作如果沒有圖形化支持，根本無法完成，因此，一個圖形化的流程設計器是必須的。
這裡只是簡單介紹了一下工作的流程設計原理，還有很多複雜深入的需求和邏輯沒有提到，但是有了框架和整體認識後，完全可以根據需求進行改進和設計。
本文由 @Being4 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議