審批流是企業中高頻業務場景。實現審批流的方法很多,最常見的有兩種抽象:
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更實用,更便捷。