文章結合具體業務場景對電商後臺設計中的稽核功能的設計邏輯展開了梳理說明，並對相關問題展開了分析，希望透過此文能夠加深你對電商後臺設計的認識。
在工作中有許多的業務場景都涉及到稽核功能，如請假條、加班申請、採購單等。既然有這麼多場景都在使用稽核，那能不能將稽核功能單獨設計成公共模組進行復用呢？這個肯定是可以的，下面我就帶大家來分析一下稽核功能。
下圖是一張常見的請假單申請單，如果我們根據操作內容來劃分，可以分出兩個區域：業務表單區和稽核表單區。
稽核中主要有兩個角色參與其中：發起人和稽核人：
單就稽核表單來說，它提供的功能相對簡單，主要有以下幾個：
序列審批主要是指當一個稽核節點通過後，才能進入下一個稽核節點。如果駁回，則駁回到上一個節點、或之前任意一個節點或者業務表單編輯節點。
並行稽核是指一個審批節點同時存在多個物件可以同時稽核的情況。當其中一個、多個或全部稽核透過，才能進入下一個稽核節點。如果駁回，通常其中一個物件駁回，就認為當前節點被駁回，其它的情況很少使用，如多個物件駁回、全部物件駁回。具體透過或駁回需要根據業務場景而定。
混合稽核通常是指包含了序列審批和並行審批的方式。如下圖中，整個流程是一個序列稽核方式，而其中一個節點則是並行審批方式。
對於上面的幾種方式分析後，可以看出，一個稽核流通常是由多個稽核節點組成， 每個節點內最主要的任務是找到對應的稽核人並作出相應的意見反饋。
發起人在發起申請時可以自己指定需要進行稽核的人，這種場景比較常見。主要優點是功能簡單、靈活性比較高，缺點是無法形成標準稽核流程。適用於那些對稽核要求不高的業務，如請假單、遲到補卡、加班等。這樣的稽核流因為是使用者自己設定，所以通常不會太複雜。
企業中還有許多稽核內容因為其中涉及到了金額、以及保密資訊，所以上面這種人為自定義的方式就不太適用，它們的稽核流程通常都是固定的標準稽核流，如採購單、合同等。針對這種情況需要設計一套標準稽核流程，後期由技術人員或者產品經理進行維護。
除了稽核人外，還需要根據業務加入更多的匹配規則，如:
1）稽核金額：即當滿足一定的金額條件後，才會觸發對應稽核人。如企業的採購單稽核，當採購金額小於等於10000時，採購主管稽核即可，當大於10000時，同時需要採購經理來稽核。
2）動態確認稽核人：上面我們總結了，稽核其實就是找到對應的稽核人，然後完成稽核資訊。稽核人的設定有以下幾種方式：
3）訊息通知：當稽核進入對應節點的時候，給發起人和稽核人傳送訊息通知，及時瞭解稽核狀況，通常由程式碼內部完成這個邏輯，功能不會體現在原型圖上。
4）抄送人：訊息傳送給稽核人和發起人的同時，也需要給指定抄送人傳送一份。
下面是最佳化後的固定稽核流原型圖:
稽核流列表頁：
稽核流設定頁：
上面我們將稽核設計成獨立的功能模組，使用時可以透過下面幾步完成呼叫：
以上就是稽核功能所涉及的內容，歡迎小夥伴們在下方留言交流！
作者：JackLiu；個人微信公眾號: 揚帆去遠航（ID:Jackai_liu)
本文由 @Jack 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。