編輯導語：實現審批流最常見的兩種方法是“BPM方法”和“層級審批方法”，後者更加貼近本土用户使用習慣。本文作者以訂單審批為例，剖析層級審批的設計邏輯，一起來看一下吧。
審批流是企業中高頻業務場景。實現審批流的方法很多，最常見的有兩種抽象：
1）BPM方法
工作流引擎。雖然BPM的完整概念是商業業務流程，但是多數開發者把BPM結合國內情況，收斂了BPM的範圍，核心約束在：表單+流程的範圍，或更縮小到自定義表單+自定義審批流程的範圍。BPM的核心是：基礎表單，步驟執行人，去向或者去向邏輯。
2）層級審批方法
更本土化的抽象邏輯，形象描述為：一層一層逐級審批。層級審批的特點是，沒有步驟的去向概念，而是抽象定義為是和否兩個分支：
BPM方法的資料很多，開源資源也非常豐富，這裏不再贅述。我們來談談更加貼近本土用户使用習慣的——層級審批實現方案。
首先，我們迴歸到基礎場景，以非常典型的單據——訂單審批為例，剖析層級審批的設計邏輯。
審批的基礎業務數據：訂單+訂單明細+（應收計劃）。這裏的應收計劃很容易在業務角度忽略，實際上，審批訂單的核心指標是三個：
如忽略應收數據，則可能會造成大量賬期拖延的應收，甚至於帶來壞賬風險。在我們開發人員看來，應收數據只不過是基礎審批中多了一部分數據而已，關係也不復雜，並不需要花這麼多篇幅來闡述。
實際不然，多數業務管理系統的技術後台並不弱，UI也很現代，但是一旦融入業務運行，就會發現缺胳膊少腿，業務邏輯支離破碎。我們在用户這裏學到這樣一句話：UI漂亮有什麼用？我要跑通業務！當業務管理系統融入了企業的生產運營環境，就會發現：業務順暢高於一切！
説了半天，迴歸業務。用户希望是一組以訂單為中心的業務數據參與審批，並在審批過程中不要被步驟審批人修改原始數據，且沒有經過審批的訂單，不允許被執行，不應該納入銷售類統計。
那麼我們總結為：
- 一組數據參與審批
- 鎖定參與審批的數據不允許在過程中隨意修改
- 沒有經過審批的數據不得繼續執行，且不得納入統計（這是很多用户在用了BPM審批流之後，再用超兔的審批流，忽然發現輕鬆很多的原因之一。在數據層，直接用業務表本表發起審批，並通過審批狀態實現業務執行約束和統計約束）
審批的層級：層級，審批人。和BMP相比，這裏抽象簡化了很多內容，因為簡化所以在配置審批流時非常簡單，只需要兩個參數——層級和審批人。
因為其弱化了步驟去向的概念，用審批的要義：否決即中止，避免了設置步驟去向（並不是説步驟去向沒有價值，而是由步驟組成流程時，步驟去向必須是完整的閉環，雖然有校驗邏輯，但是步驟去向仍然是一個看似簡單，實際容易出錯的參數）。
否決後怎麼辦？既然層級審批是否決自動中止，申請人希望根據否決意見修改原始數據後繼續審批可以嗎？可以，被抽象為重新發起審批。
在這個過程中，原始業務數據被允許修改的同時，會保留上次參與審批的數據快照，比對是否意見做了合理修改。這裏有幾個要點：
- 步驟只有層級和審批人
- 任何一步否決即中止，不再繼續
- 允許申請人在否決後修改業務數據重審，並自動做好數據快照比對
擴展：
- 審批人角色擴展，支持上下級關係類的動態角色
- 金額分支的擴展（最高頻分支，覆蓋中小企業審批流分支95%的場景）
- 自定義動作（在審批步驟中，可以通過代碼插件實現特殊的業務動作）
綜上，我們完整分析了層級審批流的解決方案。從第一視覺上，它沒有BPM看起來更花俏，但是在業務層卻遠比BPM更實用，更便捷。
本文由 @糨醬紫 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議