殊途同歸，各有千秋：兩種審批流解決方案

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

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

2.層級審批方法：更本土化的抽象邏輯，形象描述為：一層一層逐級審批。層級審批的特點是，沒有步驟的去向概念，而是抽象定義為是和否兩個分支。是：則繼續下一級別審批；否：則直接結束審批。

BPM方法的資料很多，開源資源也非常豐富，這里不再贅述。我們來談談更加貼近本土用戶使用習慣的：層級審批實現方案。首先，我們回歸到基礎場景，以非常典型的單據：訂單審批為例，剖析層級審批的設計邏輯。

1.審批的基礎業務數據：訂單+訂單明細+（應收計劃）。這里的應收計劃很容易在業務角度忽略，實際上，審批訂單的核心指標是三個：1）價格2）交期3）應收（計劃回款）。如忽略應收數據，則可能會造成大量賬期拖延的應收，甚至于帶來壞賬風險。在我們開發人員看來，應收數據只不過是基礎審批中多了一部分數據而已，關系也不復雜，并不需要花這么多篇幅來闡述。實際不然，多數業務管理系統的技術后臺并不弱，UI也很現代，但是一旦融入業務運行，就會發現缺胳膊少腿，業務邏輯支離破碎。我們在用戶這里學到這樣一句話：UI漂亮有什么用？我要跑通業務！當業務管理系統融入了企業的生產運營環境，就會發現：業務順暢高于一切！

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

那么我們總結為：1）一組數據參與審批2）鎖定參與審批的數據不允許在過程中隨意修改3）沒有經過審批的數據不得繼續執行，且不得納入統計。（這是很多用戶在用了BPM審批流之后，再用超兔的審批流，忽然發現輕松很多的原因之一。在數據層，直接用業務表本表發起審批，并通過審批狀態實現業務執行約束和統計約束）

2.審批的層級：層級，審批人。和BMP相比，這里抽象簡化了很多內容，因為簡化所以在配置審批流時非常簡單，只需要兩個參數：層級和審批人。因為其弱化了步驟去向的概念，用審批的要義：否決即中止，避免了設置步驟去向。（并不是說步驟去向沒有價值，而是由步驟組成流程時，步驟去向必須是完整的閉環，雖然有校驗邏輯，但是步驟去向仍然是一個看似簡單，實際容易出錯的參數）

【超兔CRM設置審批人】

【超兔CRM審批路徑條件設置】

【超兔CRM金額自動路徑+動態角色】

否決后怎么辦？既然層級審批是否決自動中止；申請人希望根據否決意見修改原始數據后繼續審批可以嗎？可以，被抽象為重新發起審批。在這個過程中，原始業務數據被允許修改的同時，會保留上次參與審批的數據快照，比對是否意見做了合理修改。這里有幾個要點1）步驟只有層級和審批人2）任何一步否決即中止，不再繼續3）允許申請人在否決后修改業務數據重審，并自動做好數據快照比對。

3.擴展。1）審批人角色擴展，支持上下級關系類的動態角色2）金額分支的擴展（最高頻分支，覆蓋中小企業審批流分支95%的場景）3）自定義動作（在審批步驟中，可以通過代碼插件實現特殊的業務動作）

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