電商後台設計：審核流

2020-07-03 由伯國平發佈於科技

文章結合具體業務場景對電商後台設計中的審核功能的設計邏輯展開了梳理説明，並對相關問題展開了分析，希望通過此文能夠加深你對電商後台設計的認識。

在工作中有許多的業務場景都涉及到審核功能，如請假條、加班申請、採購單等。既然有這麼多場景都在使用審核，那能不能將審核功能單獨設計成公共模塊進行復用呢？這個肯定是可以的，下面我就帶大家來分析一下審核功能。

01 審核單的組成

下圖是一張常見的請假單申請單，如果我們根據操作內容來劃分，可以分出兩個區域：業務表單區和審核表單區。

業務表單區：業務表單區主要填寫具體業務所涉及的內容信息。
審核表單區：審核表單區主要是審批人填寫審核意見的區域，根據我們常見的審核單模板，可以觀察到不同的審核單審批區域的可操作性內容基本一樣，主要包含審核人、審核意見、審核狀態。

02 參與角色

審核中主要有兩個角色參與其中：發起人和審核人：

03 審批操作

單就審核表單來説，它提供的功能相對簡單，主要有以下幾個：

04 審批模型1. 串行審批

串行審批主要是指當一個審核節點通過後，才能進入下一個審核節點。如果駁回，則駁回到上一個節點、或之前任意一個節點或者業務表單編輯節點。

2. 並行審批

並行審核是指一個審批節點同時存在多個對象可以同時審核的情況。當其中一個、多個或全部審核通過，才能進入下一個審核節點。如果駁回，通常其中一個對象駁回，就認為當前節點被駁回，其它的情況很少使用，如多個對象駁回、全部對象駁回。具體通過或駁回需要根據業務場景而定。

3. 混合審核

混合審核通常是指包含了串行審批和並行審批的方式。如下圖中，整個流程是一個串行審核方式，而其中一個節點則是並行審批方式。

對於上面的幾種方式分析後，可以看出，一個審核流通常是由多個審核節點組成，每個節點內最主要的任務是找到對應的審核人並作出相應的意見反饋。

05 使用場景場景一：指定審批人

發起人在發起申請時可以自己指定需要進行審核的人，這種場景比較常見。主要優點是功能簡單、靈活性比較高，缺點是無法形成標準審核流程。適用於那些對審核要求不高的業務，如請假單、遲到補卡、加班等。這樣的審核流因為是用户自己設置，所以通常不會太複雜。

場景二: 固定審核流

企業中還有許多審核內容因為其中涉及到了金額、以及保密信息，所以上面這種人為自定義的方式就不太適用，它們的審核流程通常都是固定的標準審核流，如採購單、合同等。針對這種情況需要設計一套標準審核流程，後期由技術人員或者產品經理進行維護。

除了審核人外，還需要根據業務加入更多的匹配規則，如:

1）審核金額：即當滿足一定的金額條件後，才會觸發對應審核人。如企業的採購單審核，當採購金額小於等於10000時，採購主管審核即可，當大於10000時，同時需要採購經理來審核。

2）動態確認審核人：上面我們總結了，審核其實就是找到對應的審核人，然後完成審核信息。審核人的設置有以下幾種方式：

指定具體的人：在審核節點上明確指定具體的審核人。
指定具體的職位: 將節點設置成對應部門下的職位，當審核流進入節點時，系統動態的根據職位信息獲取當前對應的人。這樣設計可以保障職員職位變更後，新的職員可以繼續審核，而不用重新修改審核設置。

3）消息通知：當審核進入對應節點的時候，給發起人和審核人發送消息通知，及時瞭解審核狀況，通常由代碼內部完成這個邏輯，功能不會體現在原型圖上。

4）抄送人：消息發送給審核人和發起人的同時，也需要給指定抄送人發送一份。

下面是優化後的固定審核流原型圖:

審核流列表頁：

審核流設置頁：

06 使用方法

上面我們將審核設計成獨立的功能模塊，使用時可以通過下面幾步完成調用：

以上就是審核功能所涉及的內容，歡迎小夥伴們在下方留言交流！

作者：JackLiu；個人微信公眾號: 揚帆去遠航（ID:Jackai_liu)

本文由 @Jack 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

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