審批流是我們經(jīng)常遇到的問題，在進行審批流產(chǎn)品設(shè)計的時候，需要注意哪些問題？本篇文章筆者對此進行了分析說明，一起來看看吧。

無論是OA, HR,CRM,ERP 系統(tǒng)，審批流的是我們經(jīng)常碰到的問題，比如說組織架構(gòu)變動，請假，出差，報銷，采購申請等等。那在面對一個審批流的時候，我們怎樣來進行產(chǎn)品的設(shè)計呢？

我們拿一個大家在公司里面經(jīng)常會碰到的休假申請審批來舉例說明吧。比如說我們拿到了一些客戶的需求：

1. 公司A, 需要管理一下年假的申請，3天以內(nèi)的年假只需要直接上司來進行審批，如果超過3天的年假需要二級審批，另外所有休假單子還需要管轄范圍的HR的審批；
2. 公司B,需要管理一下年假的申請，2天以內(nèi)的年假只需要直接上司來進行審批，如果超過2天需要二級審批，超過5天需要三級審批；
3. 公司C的需求比較簡單，就是所有年假都只需要支持一級審批。所有超過5天的申請都需要通知一下HR人員。

…….

這種類似的需求非常正常吧，面對這樣需求的時候我們怎樣做出一個標準產(chǎn)品來滿足所有的需求呢？還是說我們需要滿足所有的需求嗎？

這個基于不同的情況實際上最后判斷的結(jié)果可能不同。

這篇文章就一般情況來進行分析說明一下,首先我們先來看看需求的內(nèi)容，整體上面來說需求主要包括下面幾個部分：

1. 所有的需求來說，前面的審批基本上都是直接匯報對象來進行審批，只是基于天數(shù)可能審批的層級不一樣；
2. 針對A公司來說，需求有些不一樣，一個是超過3天最后一級需要HR進行審批；
3. 對于C公司來說，超過5天的申請需要通知HR人員。

對于需求1，筆者覺得問題不大，邏輯合理通用。對于第二，三個需求來說，我們需要支持嗎？我們可以從下面的維度來進行判斷：

1. 需求的邏輯是否合理；
2. 需求的價值有多大。

對于第二個需求來說，需要詢問HR，現(xiàn)在三天以上的單子的頻率是怎樣的？在這個頻率基礎(chǔ)上面，如果業(yè)務(wù)部門審批通過，你們拒絕的概率有多大？

對于第三個需求來說，需要繼續(xù)詢問為什么要通知HR人員相關(guān)的幾個問題，

通知到你們了有什么后續(xù)動作嗎？是可能進行干涉嗎？如果進行干涉，什么樣的情況下才會進行干涉，怎么樣進行干涉？基于公司現(xiàn)在的情況，干涉的概率和量為多少？

你們發(fā)現(xiàn)如果深究下去，對于第二三個需求來說，事實上通知HR以及讓HR參與審批意義可能沒有那么大，根本沒有多大的可能性在業(yè)務(wù)部門同意休假的情況下，HR再來拒絕的情況，這樣處理反而讓休假申請審批的流程變得低效，而且單子多了HR自己也會覺得很煩（HR因為在業(yè)務(wù)部門之外，審批休假的動力還有實時性都會很差）。

HR需要的只是一個能夠方便找到多少天以上休假申請的記錄而已，如果有太離譜的情況，進行一下干涉。這樣的話，可能在原來就需要的HR查詢休假紀錄功能的記錄上面支持超過一定休假天數(shù)的檢索就夠了。

如果不問青紅皂白，就來支持這幾個小功能會有什么后果呢？你會發(fā)現(xiàn)這個功能并不是很小的功能，一個小的功能要成為邏輯完整的產(chǎn)品功能都不是很容易的事情。

這里面要注意幾個點：

1. HR可能是有管轄范圍的，產(chǎn)品上面需要支持可以配置每個HR人員的管轄數(shù)據(jù)權(quán)限范圍，如果要做成通用產(chǎn)品功能，可能要基于組織架構(gòu)。這里的產(chǎn)品化配置功能會相當(dāng)復(fù)雜；
2. 如果配置HR的數(shù)據(jù)管轄范圍是配在HR員工身上的，主要該HR離職或者調(diào)動的情況，要重新進行配置，有可能沒有人記得去修改配置；
3. 如果一些單子，該HR還沒有審批，就離職的情況，這些單子怎樣進行處理的問題；
4. 如果一些單子，HR人員自己休假了，沒有審批怎么辦？

……

我這里只是舉例說明了一些例子，你們就知道產(chǎn)品的減法有多重要，一點點的增加可能帶來很多的復(fù)雜度。

如果實現(xiàn)一些邏輯不合理，或者低價值的功能，用戶不會因為你實現(xiàn)了而感謝你，實際上他用的可能會相當(dāng)煩，天天罵娘，然后因為不好用，又提了一大堆改善的需求或者解決方案，日復(fù)一日，年復(fù)一年，這個產(chǎn)品會這么樣？

事實上如果你透徹的理解了產(chǎn)品功能實現(xiàn)的真實效果，是經(jīng)常可以說服客戶的。（關(guān)于需求優(yōu)先級管理這塊，大家可以參考之前的一篇文章：如果定義B端產(chǎn)品的MVP）

通過需求梳理以及確認之后，我們發(fā)現(xiàn)需求變成下面的樣子：

1. 公司A, 需要管理一下年假的申請，只需要支持一級審批，HR需要方便的查看3天以上的年假單子。
2. 公司B,需要管理一下年假的申請，2天以內(nèi)的年假只需要直接上司來進行審批，如果超過2天需要二級審批，超過5天需要三級審批。
3. 公司C, 所有年假都只需要支持一級審批。HR需要方便的查看5天以上的單子。

那我們看看主要需要哪幾個功能：

1. 休假申請，用戶可以方便的提交休假申請，填寫休假期間，休假類型，請假原因等；
2. 休假審批，上級可以收到休假申請的通知，可以方便進行審批通過或者拒絕，拒絕需要填寫拒絕原因；
3. 休假查詢，HR，經(jīng)理，個人可以進行休假紀錄的查詢；
4. 如果要做成標準產(chǎn)品，需要一個配置功能，可以配置對應(yīng)請假天數(shù)的審批層級?？梢曰诳蛻魜砼渲谜埣偬鞌?shù)范圍對應(yīng)的層級。

然后我們來設(shè)計一下整個實現(xiàn)需要的數(shù)據(jù)庫結(jié)果，需要包含如下的幾個表格：

• 員工表：員工編號，員工姓名，基本信息字段，匯報對象等；
• 休假申請表：員工編號，請假開始日期，結(jié)束日期，假期類型，請假原因等；
• 休假審批表：員工編號，請假開始日期，請假結(jié)束日期，審批層級，審批人，審批結(jié)果，審批日期，審批備注等等（多個審批層級存放多條記錄）；
• 配置表：休假類型，天數(shù)，審批層級數(shù)等。

我們再來看看大致的幾個功能頁面：

對于所有的需求，所有的設(shè)計都沒有標準答案，無論整體還是細節(jié)的設(shè)計都要基于各種因素綜合來尋求最佳答案，筆者更希望能夠基于一些基于簡單典型案例的梳理，幫助大家找到自己思考的方法論。

作者：李東林（微信公眾號：SaaS產(chǎn)品說；微信號：jianguzhuxin），原ADP大中華區(qū)產(chǎn)品負責(zé)人，14年To B研發(fā)與產(chǎn)品設(shè)計，團隊管理經(jīng)驗，主導(dǎo)過多款大型企業(yè)管理軟件的設(shè)計、研發(fā)、上線，也有過2年移動互聯(lián)網(wǎng)TO C的創(chuàng)業(yè)經(jīng)驗。

本文由@李東林 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash， 基于CC0協(xié)議。