審批流設計(OA 系統(tǒng))
編輯導語:對具備一定規(guī)模的公司來說,OA是非常常見且致力于提高效率的一套系統(tǒng)。本文對OA系統(tǒng)中審批流模塊設計展開分析,筆者拆解了詳細的流程步驟,并對設計過程中的一些問題進行了思考總結,希望能夠給你帶來些啟發(fā)。
審批流,是OA 系統(tǒng)的最核心模塊,大部分的功能模塊都會和審批流關聯(lián),一個好的審批流管理方案,能極大減少產(chǎn)品和研發(fā)的工作量。
審批流管理,包括以下 3 個模塊:角色管理、審批關系管理、審批方案管理。通過審批方案聚合了角色、審批關系、以及審批規(guī)則,形成一套符合業(yè)務流程的審批流,基于具體的場景,走不同的人員審批。
01 員工角色管理
員工角色是審批流中的基礎,能很大程度上減輕審批流維護成本。從結構上分為 3 個部分:員工基本信息、角色管理和審批等級。
員工基本信息是不變的(一般由 EHR 系統(tǒng)維護),可以讀取 EHR 系統(tǒng)中的數(shù)據(jù),確保員工信息的準確。
角色管理分為角色名稱和員工管理的團隊范圍,舉例:張三是市場部和銷售部的 HRBP,那張三的角色是HRBP,管理的部門「市場部」、「銷售部」,當這兩個部門有屬于 HRBP 的審批信息,就都會通知到張三。
一個員工可以有多個角色和多個管理部門,一個角色也可以包括多個員工,這樣的好處,是如果有員工入離職或調(diào)崗,不需要修改審批流,只需要在角色中增加或減少員工即可。
02 審批關系管理
審批關系管理,是即默認審批流,分為「匯報關系管理」、「匯報類型管理」和「審批等級」。
1. 匯報關系
是一個標準的樹狀結構,每個員工都會有唯一的主匯報人,但會有虛線匯報和特殊匯報關系,比如 HRBP 除了向 HR 部門 VP 匯報之后,還會向負責的業(yè)務部門 VP 虛線匯報。
2. 審批等級
審批是根據(jù)審批內(nèi)容,來判斷需要到那個層級的管理者審批的。
舉例:請假 1 天直屬 leader(1 級審批人) 和團隊負責人(2 級審批人)就可以結束審批,休假 3 天以上,就需要通過部門負責人(3 級審批)審核。
審批等級的好處,是在配置審批流的時候,可以根據(jù)審批條件,精準的判斷可截止的審批層級。
一圖勝千言,可以看下這個結構圖。
03 審批方案管理
前兩個模塊,都是為了審批方案做的基礎工作。真正使用到業(yè)務中的,就是審批方案。
以財務用款審批方案為例,看如何設計審批方案。
舉例
- 用款需要員工發(fā)起,最終是審批人是財務
- 如果是金額小于等于 1000 元(部門 A 金額小于等于 2000 元),需要直屬 leader 審批,或者至少是 2 級審批人審批通過;
- 金額大于 1000 元(部門 A 金額大于2000 元),小于 1w 元,需要財務 BP 和部門 VP 審批通過
- 金額大于等于 1w,需要 CFO 審批
- 以上都審批完成后,最后通知財務打款
從上面的例子可以看出,審批方案分為審批規(guī)則和審批流。
1. 審批規(guī)則
業(yè)務規(guī)則:不同的業(yè)務審批流,都會有特殊的規(guī)則判斷,比如財務、考勤、行政采購、人事轉正等,我大致列了一些常用的規(guī)則字段。
- 財務:金額(參考上面例子);
- 考勤:休假類型和天數(shù),如事假、年假、產(chǎn)假等;
- 行政類:有采購數(shù)量和采購價格等,如超過 5000 元采購申請,需要主管審批
- 人事類:如轉正流程,有職級判斷,比如說 P7 以上轉正要 VP 審批等
特殊情況還會根據(jù)部門,走不同的審批流程,這里要基于業(yè)務場景來考慮
但也要留意一下特殊場景,比如說審批人缺失,可以跳過這個環(huán)節(jié)繼續(xù)審批,直接終止審批,或者跳轉到某個具體的人來處理這個事情。
2. 審批方式
包括依次審批、協(xié)同審批,以及僅通知。
- 協(xié)同審批:適合某個角色中,有多個成員,只需要一個人同意或拒絕就可以完成審批。
- 依次審批:當存在多個步驟,每個步驟中有多個審批人的時候,需要所有人都審批通過,才能進入下一步。
當某一個人或角色,僅僅告知審批結果的,可以選擇僅通知方式。
如下圖,某一個沒有分支條件的參考示例。
3. 可結束審批節(jié)點規(guī)則
做這個的目的是避免很小的流程,就走很長的審批,比如說金額小于 1000 的,到 2 級審批人就可以結束審批,但較大金額的比如超過 10w的用款,則只能 CFO 審批結束。
4. 審批流設置
這個對產(chǎn)品經(jīng)理來說,就是一個流程圖,相對簡單,只要審批規(guī)則、審批方式等提前定義好,這就是最簡單的配置。
04 總結
審批流是 OA 的核心模塊,一個靈活的審批流管理方案,不僅僅能滿足 OA 系統(tǒng),還能對外輸出給其他系統(tǒng),作為系統(tǒng)內(nèi)部審批流來實現(xiàn),比如 EHR 的績效審批等。
#相關閱讀#
從 0 到 1 搭建薪酬系統(tǒng)(OA 系統(tǒng)篇)
#專欄作家#
司馬特小隊,公眾號:司馬特小分隊,人人都是產(chǎn)品經(jīng)理專欄作家。8年+互聯(lián)網(wǎng)資深產(chǎn)品經(jīng)驗,多年B端產(chǎn)品管理經(jīng)驗。具有多個從0到1的大型B端產(chǎn)品的孵化、重構、迭代經(jīng)驗;主要教授產(chǎn)業(yè)互聯(lián)網(wǎng)產(chǎn)品相關的硬核知識點。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉載
題圖來自Unsplash,基于CC0協(xié)議。
太淺了 真正要做一個系統(tǒng) 這點知識是不夠的
同意。不說業(yè)務上的會簽、或簽的抽象概念,就是排他、并行網(wǎng)關設計,或者連 BPMN 等背后的一些基本引擎概念都沒提到,一直在表層做文章。后續(xù)需求改動時,研發(fā)改動成本會很大。
想請問下大佬
為什么需要做默認審批流呢?
您好,能向您請教個問題嗎
如果員工角色不固定,是處于流轉狀態(tài),那么,怎么設計請假審核的審批流呢?
比如住院醫(yī)師,在醫(yī)院住培期間,每個科室可能待1-3個月不同的時間,每次在不同科室請假時,會涉及到不同科室管理者審批!
我覺得可參考釘釘?shù)恼埣?由員工自動選擇審批人 抄送人
受教
你好能請教你一個問題么?
一個審批流,開始狀態(tài)是 “草稿” 發(fā)起人可編輯刪除 , 如果審批人審批駁回后狀態(tài)是定義一個“駁回”狀態(tài)還是直接打回“草稿”狀態(tài),如果定義一個”駁回“ 狀態(tài) 又讓發(fā)起可以編輯刪除?
考慮下,什么情況下需要刪除?是不是刪除本身就是個偽需求呢?
不太懂審批流背后的業(yè)務背景,作者能介紹下這個審批流相關的業(yè)務背景嗎?
感覺這個是有兩種情況:
1、填寫的申請內(nèi)容有問題,審批人駁回,要求修改申請信息。當通過駁回的動作線回到申請人環(huán)節(jié),申請人應該是有權限修改申請表單的信息。
2、審批人不同意此次申請,當駁回后,申請人可通過”取消申請“動作線,結束掉本次申請。申請人能不能修改申請信息,并沒有什么影響,因為在實際正常操作下,當審批人不同意駁回后,申請人即使修改也無意義。
是否可以在審批人審批的時候增加操作,根據(jù)實際情況判斷,是【退回修改】或者【拒絕】,如果是退回修改的話,可以支持申請人重新編輯再次提交審批;如果是拒絕的話,則顯示拒絕狀態(tài),發(fā)起人這邊僅可查看,不可以有其他操作。
很好的總結,謝謝大佬分享
感謝
感謝,非常有用