aPaaS層自定義審批流產品設計
本文作者從工作項目實踐出發,總結了審批流程自定義結構化設計的相關經驗,供大家一同參考和學習。
審批流應用業務場景眾所周知,不多做贅述。
企業規模擴張,流程變革都會引起企業內部審批流程調整,很多傳統2B企業也都會因此具有流程再造,IT系統重構的需求,因此筆者主要談談平臺自定義審批流程產品設計。
面向用戶:企業IT系統管理員/系統實施人員/高級業務人員
基于以上場景可知,我們設計自定義審批流的初衷,是為了解決企業審批流程發生變更時,大規模、高成本的IT系統重構。因此設計審批流程自定義配置產品,方便企業IT運維/系統實施/高階業務人員,通過可視化界面快速、高效的配置或者修改審批流程。
產品結構化設計
1. 審批流基本信息管理
該部分主要用于審批流程基本信息管理,其中需要重點說明的是:
(1)關聯業務
這里主要是設置審批流程是基于哪個業務下發生的,如果是平臺已有業務,可以直接進行關聯。
如果這里審批流需要獨立自定義相關的業務描述,可以通過自定義表單的形勢實現,表單設計屬于另一個主題,不在這里贅述。
(2)生命周期
如前面所講,審批流隨時可能會發生變更,但是歷史審批流已產生歷史數據,因此不能直接刪除,這就需要對審批流進行生命周期管理,“禁用”的審批流程在前臺是不可見、且不可操作的,但是基于該審批流所發生的歷史數據是可查詢的。
2. 可視化審批流程配置
可視化流程配置,按照節點屬性分類設置,分為三部分:
(1)開始節點
(2)審批節點
其中重難點包括節點和節點之間的連接過程:
- 上個節點和下個節點是一對一節點,即為下個節點是單個節點;
- 上個節點和下個節點是一對多節點,即為下個節點是分支節點;
- 如果節點之間最終需要交匯合并,那么也可能在節點之間需要插入空節點,用于分支節點中某個節點可以跨節點到達下一個節點。
(3)結束節點
以上三部分主要用于審批流程屬性配置,每一個過程都必不可少,定義的屬性粒度足夠細致,前臺審批流程靈活性就會越高。
其中可抽象的重點能力模塊有:
- 觸發條件設置:定義觸發條件,基于某種條件可以觸發某種事件;
- 條件設置組件:選擇對象下的字段,設置字段條件;
- 觸發執行事件設置:定義觸發事件,當滿足觸發條件時,執行觸發事件。
觸發事件組件:
觸發器的應用場景比較多,此處可以封裝成獨立的觸發器功能。
其他細節此處不做一一贅述,如果有描述不清楚的地方,歡迎大家隨時討論。
3. 審批流權限
企業數據涉及很多企業機密信息,因此2B產品有一個很重大的課題,就是權限設計(此處后面可以專題討論),因此審批流也不例外。
其中需要重點關注的:
- 操作權限是只有當前節點的審批人,還是也要授權給管理員?
- 審批流查看權限,因為前面講到,審批流都是關聯業務進行的,因此是不是默認繼承業務的數據查看權限?還是可以更精細的進行權限控制?
此處需要根據業務場景進一步設計,當然也歡迎大家能有更多探討。
產品交互設計
大家應該都比較熟悉使用Visio等工具畫業務流程,為了減少用戶交互操作的培訓,筆者也希望能夠采用這種交互的方式來實現審批流程的配置過程。大致結構可參考下圖:
以上,是筆者根據自己的經驗總結的審批流程自定義結構化設計,僅代表個人觀點,歡迎大家深入探討,碰撞出更多火花。
本文由 @椰子 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
審批發起人為什么要分為那三種類型,這三種類型分別對應什么場景?
把釘釘的審批流程配置一遍就曉得了
干貨,不錯
棒,學習了
干貨