從合同審批流程出發,說說工作流引擎的設計原理

18 評論 21868 瀏覽 154 收藏 11 分鐘

本文作者從一個合同審批流程角度對工作流的設計原理進行了介紹,供大家一同參考和學習。

寫這篇文章的意圖并不是為成熟工作流引擎知識徒增一篇文章,也不是深入介紹JPBM、Aactivity等工作流引擎技術和數據庫結構。而是因為當前轉ToB的產品經理多了,但提及這塊兒就很難深入。雖然有不少介紹工作流的文章,但大多是直接介紹BPM的體系,很少有文章從業務角度出發介紹為什么這樣設計,下面我就試著從一個合同審批流程角度介紹工作流的設計原理,希望對大家有幫助。

工作流簡介

工作流(Workflow),指“業務過程的部分或整體在計算機應用環境下的自動化”。是對工作流程及其各操作步驟之間業務規則的抽象、概括描述。在計算機中,工作流屬于計算機支持的協同工作(CSCW)的一部分。其主要解決的主要問題是:為了實現某個業務目標,利用計算機在多個參與者之間按某種預定規則自動傳遞文檔、信息或者任務。說白了就是按照怎樣順序、做什么、由誰來做。

1993年工作流管理聯盟(Workflow Management Coalition,WfMC)作為工作流管理的標準化組織而成立,標志著工作流技術逐步走向成熟。WfMC對工作流給出定義為:工作流是指一類能夠完全自動執行的經營過程,根據一系列過程規則,將文檔、信息或任務在不同的執行者之間進行傳遞與執行。工作流無論是減少人為操作,提供工作效率,還是優化線下業務流程,提高管理水平均有很大的幫助。

工作流經歷了第一個階段的“無紙化、重復工作、流程孤島、系統孤島、數據孤島”過程,目前正在實現“智能化、效率質量提升、外部數據整合、消除信息孤島、內部數據整合”的第二階段。

1. 合同審批流程

所有的信息化都是為了解決業務上需求,首先我們了解企業合同管理制度中審批流程是如何完成的。下面是一個比較通用合同審批流程圖。

  1. 首先所有可以起草合同并發起合同申請流程的人,即使合同承辦人;
  2. 合同承辦人將合同提交其部分負責人(實際情況可能部長或副部長均要審批、或順序審批、或任一審批即可)來審批,大部分還有內部審核人把關再提交其部門負責人;他們都有權退回(不合格需要修改)或駁回(徹底不簽了);如果承辦部分負責人同意,可以選擇相應的會簽部分同步開始會簽,如財務部、技術部等等。有些事必須選擇,如涉及金額合同必須選擇財務部。
  3. 會簽部門就更熱鬧了,三五個部分并行審批,部門內部有各自審批流程,而且均可以同意、退回,有的需要退回合同承辦人,有的需要退回承辦部門負責人。而且有的情況是全部同意才能算通過,有的是三分之二同意才能算通過。
  4. 必須經過合同歸口部門審核。一般是法律部或風險部,他們也需要退回,可能是審批過的任何一個節點,返回來的方式可能是從來一遍,也可以直接返回退回人。這里還有“是否重大合同”和“是否使用合同范本”的業務屬性判斷。
  5. 根據業務業務類型和管轄范圍,自動選擇分管領導。根據授權情況判斷合同流程是否到此終止,當然分管領導可以退回、駁回等。
  6. 總經理可能會簡單些,同意、退回、駁回。審批通過后自動觸發用印或上報上級公司的審批流程。

這算是一個常規的大企業合同審批流程,如何利用信息化實現一份具體合同審批流程?簡單,將每一步及其規則固化帶代碼中。如果換一份合同?如果換一種業務?如果規則變動?如果需要每個節點觸發不同業務,顯現不同信息?如果人員變動了?如何組織機構變動了?這個時候就需要我們抽取其中的共性,將其引擎化,能夠通過配置實現系統的靈活性。

2. 工作流引擎設計

下面我們從業務的角度逐步抽象出工作流引擎的設計。遇到復雜問題一方面我需要按照第一性原理尋找最本質的需求,另一個更常規的思路就是分解,對問題進行分類分級處理,各個擊破。其實,還有一種完全交個用戶自己選擇,如釘釘審批流程。但大型企業流程的作用除了提高效率,還需要減少人為操作、控制合規風險,完全交個用戶選擇的自由流程使用較少。

從上文的流程圖中,可以簡單抽取出流程、環節、連線、角色、組織等主要對象,還有一個就是與外部(業務)發生關系的接口。它們之間簡單的關系就是流程由環節和聯系組織,環節上有角色和組織屬性,接口可以在連線上,也可以在環節上,下面一步步解釋。

(1)流程分類(流程太多)

如果設計一個通用的工作流引擎,面對的各種業務流程、審批流程可以說成千上萬,怎么辦?首先想到的就是對流程進行分類,對相同類型的流程進行統一處理,降低流程需求復雜度和耦合度。目前業務操作不同進行分類的,如請假流程、報銷流程、合同審批流程等等。

(2)自定義具體流程(一種流程還是太復雜)

如何合同審批流程,不同企業、不同種類,審批流程還是不一樣。繼續細分類別可以解決問題,但分到最后流程就需要多少個環節以及之間的關系是什么還是不確定,交個用戶和運維人員搭建流程,由他們自己定義。?定義流程的名稱、流程的環節、環節順序(連線)、環節參與人員等。

(3)自定義具體環節(環節定義最復雜)

環節需要具體到做什么工作、誰來做、怎么做等,但這三個主要因素都是變量,做什么工作(即查看什么表單,同意、退回、駁回等),誰來做(通過組織、角色、群組框定出參與的候選人),怎么做(并行、串行等),這些都需要通過配置實現。另外,需要配置出發的其他業務事件等,如何合同審批完畢后自動生成合同編號。

(4)環節間的連線

上文提到在實際業務審批中,涉及金額的合同必須經過財務審批,說明流程的走向與業務屬性發生了關系。因此,我需要設計在節點間連線上設置業務條件,或設計可以進行業務判斷的節點,滿足這種業務需求。

(5)流程實例(每個流程)

上面講到的都是配置一種流程,即將審批制度步驟和規則放到系統中,但具體的一份合同審批流程信息即流程實例必須記錄下來,一是為了留痕,再者就是流程審批中發生退回和返回需要用到這些數據,每個流程審批的業務唯一標識,每個環節實例需要記錄誰在什么時間、什么意見等。

(6)流程版本(流程變更)

業務上流程變更了怎么辦?這就需要對流程進行版本管理,可以實現流程變更前已經提交的流程,按照之前的版本繼續進行,而流程變更后提交的流程按照最新版本進行。

(7)流程關聯

本單位的流程審批完畢后,符合上報條件需要啟動上級工作流程;合同審批流程中,每個會簽部門內部的流程本身就比較負責,需要為會簽部門搭建單獨的審批流程,嵌入到合同審批流程中。以上兩種情況就涉及到流程關聯和子流程的問題,需要進行設計。

(8)流程設計器

以上的操作如果沒有圖形化支持,根本無法完成,因此,一個圖形化的流程設計器是必須的。

這里只是簡單介紹了一下工作的流程設計原理,還有很多復雜深入的需求和邏輯沒有提到,但是有了框架和整體認識后,完全可以根據需求進行改進和設計。

 

本文由 @Being4 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 好多錯別字,合同流程圖最后面是否也畫錯了

    來自北京 回復
  2. 請教下,關于工作流引擎公司會建設或采購符合所有業務的進行統一使用,這時候個性化需求應該會舍棄吧?個性化較強的業務會獨立建設嘛~

    來自福建 回復
    1. 個性化需求到什么程度?一般不建議獨立建設,之所以叫做引擎就是和具體業務關聯非常少,而且發展到今天應該可以支持大部分需求,太個性化的需求可以考慮投入產出比,是否真的有必要實現

      來自北京 回復
  3. 產品經營分析

    回復
  4. 想請教下,在公司沒有系統的情況下,我的合同登記表應該如何設計,才能更好的管理?
    現階段是每次走一份合同審批流,都記錄一次數據和費率,但是有些客戶可能重簽或者換簽合同之后,就有多份合同數據,我要如何做,才能在每次調取的時候只有一份最新的合同信息,還能保留原來審批流的明細?

    來自上海 回復
    1. 重簽、換簽合同與之前的合同進行關聯是否可以解決問題。履約主體、履行期限、合同金額等一直情況下提醒關聯原合同

      來自天津 回復
  5. 你好能請教你一個問題么?
    一個審批流,開始狀態是 “草稿” 可編輯刪除 , 如果審批人審批駁回后狀態是定義一個“駁回”狀態還是直接打回“草稿”狀態,如果定義一個”駁回“ 狀態 又讓發起可以編輯刪除?

    來自浙江 回復
    1. 有兩個詞一個是駁回,一個是退回。業務上駁回的意思是這事不用辦了,流程標記為駁回狀態進入歸檔模式,不可修改不可刪除;業務上退回的意思是有點小問題,修改完畢再提交過來,狀態仍是審批中,可以修改不可以刪除。原則上進入流程中不可以刪除要保留痕跡,唯一一種可以刪除的情況就是,起草人提交沒有任何人審批的時候,撤回了

      來自北京 回復
  6. 文章內錯別字和多余字還是有些多,建議可以再優化一下。

    回復
  7. 從原始需求到業務流程,再從中抽象出流程引擎(引擎內容的原由),且核心觀點很正“所有動作都是服務于實際需求”。引擎是為了服務當下、未來的需求,即產品拓展性。講的比較連貫,容易理解。

    來自浙江 回復
    1. 多謝

      來自天津 回復
  8. 能推薦一些開源項目嗎?

    來自福建 回復
    1. activity、flowable

      來自天津 回復
  9. 麻煩你用他人照片時先征求作者同意行嗎!!!!!!!! ??

    來自青海 回復
  10. 哪說的不明白,歡迎大家交流~~

    來自北京 回復
    1. 從原型圖角度出發的話,我怎么表達能讓研發落地這個決策流呢?

      來自北京 回復
    2. 這塊兒開源項目很成熟,不用重復造輪子。梳理清楚開源想的功能,哪里不合適優化升級即可,建議不用0-1的原型

      來自北京 回復
    3. 需要付費的吧?

      來自浙江 回復