編輯導語：實現審批流最常見的兩種方法是“BPM方法”和“層級審批方法”，後者更加貼近本土使用者使用習慣。本文作者以訂單審批為例，剖析層級審批的設計邏輯，一起來看一下吧。

審批流是企業中高頻業務場景。實現審批流的方法很多，最常見的有兩種抽象：

1）BPM方法

工作流引擎。雖然BPM的完整概念是商業業務流程，但是多數開發者把BPM結合國內情況，收斂了BPM的範圍，核心約束在：表單+流程的範圍，或更縮小到自定義表單+自定義審批流程的範圍。BPM的核心是：基礎表單，步驟執行人，去向或者去向邏輯。

2）層級審批方法

更本土化的抽象邏輯，形象描述為：一層一層逐級審批。層級審批的特點是，沒有步驟的去向概念，而是抽象定義為是和否兩個分支：

BPM方法的資料很多，開源資源也非常豐富，這裡不再贅述。我們來談談更加貼近本土使用者使用習慣的——層級審批實現方案。

首先，我們迴歸到基礎場景，以非常典型的單據——訂單審批為例，剖析層級審批的設計邏輯。

審批的基礎業務資料：訂單+訂單明細+（應收計劃）。這裡的應收計劃很容易在業務角度忽略，實際上，審批訂單的核心指標是三個：

如忽略應收資料，則可能會造成大量賬期拖延的應收，甚至於帶來壞賬風險。在我們開發人員看來，應收資料只不過是基礎審批中多了一部分資料而已，關係也不復雜，並不需要花這麼多篇幅來闡述。

實際不然，多數業務管理系統的技術後臺並不弱，UI也很現代，但是一旦融入業務執行，就會發現缺胳膊少腿，業務邏輯支離破碎。我們在使用者這裡學到這樣一句話：UI漂亮有什麼用？我要跑通業務！當業務管理系統融入了企業的生產運營環境，就會發現：業務順暢高於一切！

說了半天，迴歸業務。使用者希望是一組以訂單為中心的業務資料參與審批，並在審批過程中不要被步驟審批人修改原始資料，且沒有經過審批的訂單，不允許被執行，不應該納入銷售類統計。

那麼我們總結為：

一組資料參與審批

鎖定參與審批的資料不允許在過程中隨意修改

沒有經過審批的資料不得繼續執行，且不得納入統計（這是很多使用者在用了BPM審批流之後，再用超兔的審批流，忽然發現輕鬆很多的原因之一。在資料層，直接用業務表本表發起審批，並透過審批狀態實現業務執行約束和統計約束）

審批的層級：層級，審批人。和BMP相比，這裡抽象簡化了很多內容，因為簡化所以在配置審批流時非常簡單，只需要兩個引數——層級和審批人。

因為其弱化了步驟去向的概念，用審批的要義：否決即中止，避免了設定步驟去向（並不是說步驟去向沒有價值，而是由步驟組成流程時，步驟去向必須是完整的閉環，雖然有校驗邏輯，但是步驟去向仍然是一個看似簡單，實際容易出錯的引數）。

否決後怎麼辦？既然層級審批是否決自動中止，申請人希望根據否決意見修改原始資料後繼續審批可以嗎？可以，被抽象為重新發起審批。

在這個過程中，原始業務資料被允許修改的同時，會保留上次參與審批的資料快照，比對是否意見做了合理修改。這裡有幾個要點：

步驟只有層級和審批人

任何一步否決即中止，不再繼續

允許申請人在否決後修改業務資料重審，並自動做好資料快照比對

擴充套件：

審批人角色擴充套件，支援上下級關係類的動態角色

金額分支的擴充套件（最高頻分支，覆蓋中小企業審批流分支95%的場景）

自定義動作（在審批步驟中，可以透過程式碼外掛實現特殊的業務動作）

綜上，我們完整分析了層級審批流的解決方案。從第一視覺上，它沒有BPM看起來更花俏，但是在業務層卻遠比BPM更實用，更便捷。

本文由 @糨醬紫 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議