在B端系統中,流程并發駁回具體如何處理?
本文作者以個人在工程項目管理系統設計過程中的實際經歷,為大家分享了以下設計文檔,幫助大家解決“B段系統設計中流程并發駁回”具體該如何處理的問題。
公司用一款敏捷開發平臺做企業辦公系統,近日給客戶做一款工程項目管理系統。因為客戶行業特殊性,一個項目的概算在百億以上,所以對流程審批比較重視,同時審批效率也有一定要求,部分流程需要幾個相關部門并行一起審批;但又因平臺缺少并行審批功能,在參考了網上不多的文檔后加上客戶實際需要與自己的思考形成以下設計文檔,同時包括了開發的疑問與我的回復,供大家學習交流。
一、概念定義
1. 概念示例圖
2. 流程模版
指使用流程設計器設計的,某一應用對應的所有高級表單都應執行的流程
3. 并行流程分區
并行流程由兩個或者多個分支流程同時執行,分支上可以有多個節點,所有分支上的所有節點都執行完畢后,整個并行流程才被認為是執行完成,流程一旦進入并行流程,我們可以把整個并行流程步驟看做一個整體,稱之為并行流程分區。本文只討論并行流程“與”,“或(多條分支但根據條件實際只執行一個分支)”不在本文研究范圍內。
并行分區應被定義為一個整體,其在整個流程中可以被看做一個節點。
在示例中共有2個并行流程,分別是4、5、6、7、8與10、11、12 。
出現并行流程的原因有:
- 為了提高企業效率。并行審批是多人同時審批,能夠提高審批的速度;
- 解決同時審批,但絕大多數審批的內容不一樣的用戶場景。
4. 并行分支
在并行流程分區內并行執行的實例稱之為并行分支
在示例中共有5個并行分支,分別是4、7與5、8與6與10、12與11
并行分支審批狀態
并行分支應有同意與不同意兩種審批狀態,分支的狀態取決于分支上節點的審批狀態
- 當分支上所有節點都為同意時,認為分支為同意
- 當分支上一個節點為不同意時,認為分支為不同意
開發:
節點同意不同意,是后臺程序去判斷,不是頁面操作?
產品:
節點不同意是指:節點的審核人員點擊系統“駁回”按鈕填寫駁回表單并點擊提交按鈕的一系列操作。
5. 節點
可以簡單的理解為:在現有流程中,一個“方塊”等于一個“節點”。
并行開始節點
分支開始的作用是實現流程的并行流轉,并行開始節點需要將表單同時轉交給一個或多個節點。
在示例中,共有2個并行開始節點,分別是3與9。
聚合節點
聚合節點用于將分支或動態分支節點上產生的若干條并行流程實例聚合起來。
在示例中共有2個聚合節點,分別是9與13。
6. 提交
直接提交給我
流程哪里在來的就回哪里去。
重走流程
即按流程圖定義,返回指定節點重新執行。
二、流程執行原則
非并行流程執行區外,在任意時間點只允許一個節點處于辦理中。
兩種狀態:
1.并行流程分支可選
2.分支可不選:并行分支可以根某次實際業務中的需求,跳過某一分支,如下圖:
在特定業務所需流程步驟中,不需要包含5、6節點的這一分支。那么在3選擇轉交下一步時,不對5進行勾選,則在本次流程業務中將不執行節點5、8 ;本次并行流程分區只需4、7、6同意后流程即可轉交至9。
例:并行流程分區內的三個分支分別為財務、監察審計、工程管理,在某次合同審核中不需要“監察審計”分支進行審核,那么項目主管部門經辦人可以只對財務與工程管理部分支進行勾選,跳過檢查審計部。
未被選定的分支不被記錄
如本次流程業務執行程中,4、7、6有人選擇退回(重走流程),流程被駁回至3,3再次提交時可以再次選擇分支。
1. 并行流程分區內流程等待
重申分支狀態概念:
并行分支應有同意與不同意兩種審批狀態,分支的狀態取決于分支上節點的審批狀態
- 當分支上所有節點都為同意時,認為分支為同意
- 當分支上一個節點為不同意時,認為分支為不同意
2. 同意等待狀態
聚合節點9應等待所有分支狀態都為同意時再對聚合節點9發送一條待辦信息。(不包括3在“本次”提交流程時未勾選的分支)
開發:
添加同意與不同意的節點信息,分支所有的節點都完成,有不同意的,就駁回?當人員不同意,是操作駁回,還是直接填寫不同意?流程判斷所有節點,有不同意的就駁回?每一個節點去判斷不同意,只要分支上有一個不同意,就駁回?也就是說出發駁回的操作是什么?
產品:
此處有兩個概念:節點不同意、分支不同意。
節點不同意是指:節點的審核人員點擊系統“駁回”按鈕填寫駁回表單并點擊提交按鈕的一系列操作。
分支不同意參見文檔上提及的概念:
分支狀態概念
并行分支應有同意與不同意兩種審批狀態,分支的狀態取決于分支上節點的審批狀態
- 當分支上所有節點都為同意時,認為分支為同意
- 當分支上一個節點為不同意時,認為分支為不同意
根據概念,有多個節點的分支按照流程圖順序執行,如分支上先執行的節點獲得了同意那么就按照流程圖依次轉交給分支上其他節點;如果先執行的節點就獲得了不同意的節點狀態,那么此時分支狀態就獲得“不同意”狀態,分支上后執行的節點不在進行,此時等待其他分支獲得分支狀態后再按照其他規則進行駁回操作。
圖例2個:
例1駁回:
分支1有多個節點(4、7、9)當4節點不同意,進行了節點的駁回操作(直接提交給我或重走流程都可),基于分支狀態第二條,分支1無需再獲得節點7與9的節點狀態,此時獲得分支1獲得分支狀態為:不同意。在獲得2,3分支的分支狀態獲取后,綜合并行流程分區的意見,按照其他規則執行駁回操作。
例2同意:
節點同意概念:點擊轉交下一步,填寫轉交下一步表單,點擊提交按鈕等一系列操作。
根據分支狀態概念,
分支1:4、7、9三個節點都為同意后分支1才獲得分支狀態:同意
分支2:5、8兩個節點都為同意分支2才獲得分支狀態:同意
分支3:6節點為同意后分支3獲得分支狀態:同意
此時整個并行流程分區上所有分支都同意則按照流程圖轉交至節點10,對節點10發送一條待辦消息。
3. 駁回等待
與同意等待相似,并行流程分區內所有分支狀態都獲得之后才執行駁回操作,在此之前被駁回人不會收到駁回通知,以免出現各分支意見不一重復修改,一個業務辦理多次等問題。
開發:
現在是有駁回就插入記錄,記錄每個人的駁回信息,當等待完成時,推送那一條代辦?其他的代辦如何處理?當有代辦消息時,會如何提示?
產品:
“現在是有駁回就插入記錄,記錄每個人的駁回信息”不是記錄每個人的,如果先執行的節點就獲得了不同意的節點狀態,那么此時分支狀態就獲得“不同意”狀態,無需再獲得分支上后執行的節點記錄。當所有分支都獲得分支狀態后再按照其他規則對相應的節點推送一條待辦。
三、駁回策略
1. “有人有異議就會被駁回”
如果一個并行流程分區內有100個分支,有99條分支狀態都是同意,有1條分支狀態是不同意,也將執行駁回操作。
開發:
這里的駁回是頁面操作,還是程序操作?頁面操作,這一條不同意,是直接提交給我,還是重走流程?
產品:
程序操作
2. 重走流程大于直接提交給我。
在并行流程分區內,如有退回類型選擇不一致的情況,則執行重走流程。
3. 大于一個直接提交給我則執行重走流程。
在并行流程分區內,如有兩個及兩個以上節點選擇直接提交給我,則執行重走流程
4. 退回節點不一致。
在并行流程分區內,如兩個分支選擇的退回節點不一致,則按照流程模板的節點序號(也可以說是順序執行中相對先執行的節點)對應的節點處執行重走流程(基于以上兩條)
5. “直接提交給我”有且只能傳遞一次。
“直接提交給我”模式有且只能轉遞一次,比如節點9“直接提交給我”模式駁回到節點4,這時候節點4不允許再有“直接提交給我”駁回到節點2。因為如果有再次“直接提交給我”駁回到節點2會造成混亂,因為節點2處理完后直接返回節點4,當節點4再次處理時是按正常提交給節點7,并不會直接返回節點9,那么此時流程實例將無法正常流轉到結束,因為節點9是一個聚合節點。
節點4此時也不支持再次使用按流程圖執行的駁回,因為是會破壞節點9的設置期望,節點9是期望駁回后直接處理返回回來,所以“直接提交給我”駁回后,統一規則為不允許再次駁回。只能是按節點9的期望處理完后再次返回給節點9.
6. 有駁回權限的節點
流程中所有節點都應有駁回權限
7. 可被駁回節點
本節圖示:
并行流程分區內部可被駁回
并行流程分區內可駁回,兩種駁回模式都應支持,但不可夸分支選擇
- 例1:8駁回至5,可行
- 例2:9駁回至4,選擇重走流程,可行
- 例3:9駁回至4,選擇直接提交給我,可行
- 例4:9駁回至6,不可行
主線流程駁回至并行流程分區內
當審批人在駁回窗口選擇駁回節點時,主線節點不可駁回至并行流程分區內任意節點,執行重走流程,只支持直接提交給我
例:10駁回到任務7的情況,由于節點7處于并行分支上,我們約定這種情況的駁回模式只支持“直接提交給我”模式,若不是這樣那么節點7可能永遠不法繼續流轉,因為節點10是一個聚合節點,需要等候節點9、8、6三個節點同時到達。
并行流程分區 駁回至主線節點
并行流程分區可駁回至主線節點,兩種駁回模式都支持
- 例1:4駁回至2,選擇重走流程
- 例2:8駁回至3,選擇直接提交給我
本文由 @白開水 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自Unsplash,基于 CC0 協議
能給我一個聯系方式嗎?我有比較復雜的項目需求,聯系方式18911392572
關于駁回,你給他太多限制了。
1、關于第5點可以這樣改動:
9→4→2,都可以“直接提交給我”。“直接提交”的是獨立的優先服務,可以記錄多條,即記錄 “當2提交時直接給4”、“當4提交時直接給9”
2、如果與前面“整個分支區域作為一個意見”一致,那么分支內駁回到分支前是可行的,重新流入分支即可。個支路駁回人可選擇是否直接提交給我,若不是,則廢棄其他支路的決策。
最近在考慮企業系統方向PM轉型,想和作者交流下,可否聯系下呀~~
邏輯牛皮~~贊
硬核干貨