中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

…….

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

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

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

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

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

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

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

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

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

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

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

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

這里面要注意幾個點：

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

……

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

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

事實上如果你透徹的理解了產品功能實現的真實效果，是經常可以說服客戶的。（關于需求優先級管理這塊，大家可以參考之前的一篇文章：如果定義B端產品的MVP）

通過需求梳理以及確認之后，我們發現需求變成下面的樣子：

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

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

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

然后我們來設計一下整個實現需要的數據庫結果，需要包含如下的幾個表格：

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

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

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

作者：李東林（微信公眾號：SaaS產品說；微信號：jianguzhuxin），原ADP大中華區產品負責人，14年To B研發與產品設計，團隊管理經驗，主導過多款大型企業管理軟件的設計、研發、上線，也有過2年移動互聯網TO C的創業經驗。

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

題圖來自Unsplash， 基于CC0協議。