aPaaS層自定義審批流產品設計

5 評論 13132 瀏覽 143 收藏 7 分鐘

本文作者從工作項目實踐出發,總結了審批流程自定義結構化設計的相關經驗,供大家一同參考和學習。

審批流應用業務場景眾所周知,不多做贅述。

企業規模擴張,流程變革都會引起企業內部審批流程調整,很多傳統2B企業也都會因此具有流程再造,IT系統重構的需求,因此筆者主要談談平臺自定義審批流程產品設計。

面向用戶:企業IT系統管理員/系統實施人員/高級業務人員

基于以上場景可知,我們設計自定義審批流的初衷,是為了解決企業審批流程發生變更時,大規模、高成本的IT系統重構。因此設計審批流程自定義配置產品,方便企業IT運維/系統實施/高階業務人員,通過可視化界面快速、高效的配置或者修改審批流程。

產品結構化設計

1. 審批流基本信息管理

該部分主要用于審批流程基本信息管理,其中需要重點說明的是:

(1)關聯業務

這里主要是設置審批流程是基于哪個業務下發生的,如果是平臺已有業務,可以直接進行關聯。

如果這里審批流需要獨立自定義相關的業務描述,可以通過自定義表單的形勢實現,表單設計屬于另一個主題,不在這里贅述。

(2)生命周期

如前面所講,審批流隨時可能會發生變更,但是歷史審批流已產生歷史數據,因此不能直接刪除,這就需要對審批流進行生命周期管理,“禁用”的審批流程在前臺是不可見、且不可操作的,但是基于該審批流所發生的歷史數據是可查詢的。

2. 可視化審批流程配置

可視化流程配置,按照節點屬性分類設置,分為三部分:

(1)開始節點

(2)審批節點

其中重難點包括節點和節點之間的連接過程:

  1. 上個節點和下個節點是一對一節點,即為下個節點是單個節點;
  2. 上個節點和下個節點是一對多節點,即為下個節點是分支節點;
  3. 如果節點之間最終需要交匯合并,那么也可能在節點之間需要插入空節點,用于分支節點中某個節點可以跨節點到達下一個節點。

(3)結束節點

以上三部分主要用于審批流程屬性配置,每一個過程都必不可少,定義的屬性粒度足夠細致,前臺審批流程靈活性就會越高。

其中可抽象的重點能力模塊有:

  1. 觸發條件設置:定義觸發條件,基于某種條件可以觸發某種事件;
  2. 條件設置組件:選擇對象下的字段,設置字段條件;
  3. 觸發執行事件設置:定義觸發事件,當滿足觸發條件時,執行觸發事件。

觸發事件組件:

觸發器的應用場景比較多,此處可以封裝成獨立的觸發器功能。

其他細節此處不做一一贅述,如果有描述不清楚的地方,歡迎大家隨時討論。

3. 審批流權限

企業數據涉及很多企業機密信息,因此2B產品有一個很重大的課題,就是權限設計(此處后面可以專題討論),因此審批流也不例外。

其中需要重點關注的:

  1. 操作權限是只有當前節點的審批人,還是也要授權給管理員?
  2. 審批流查看權限,因為前面講到,審批流都是關聯業務進行的,因此是不是默認繼承業務的數據查看權限?還是可以更精細的進行權限控制?

此處需要根據業務場景進一步設計,當然也歡迎大家能有更多探討。

產品交互設計

大家應該都比較熟悉使用Visio等工具畫業務流程,為了減少用戶交互操作的培訓,筆者也希望能夠采用這種交互的方式來實現審批流程的配置過程。大致結構可參考下圖:

以上,是筆者根據自己的經驗總結的審批流程自定義結構化設計,僅代表個人觀點,歡迎大家深入探討,碰撞出更多火花。

 

本文由 @椰子 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 審批發起人為什么要分為那三種類型,這三種類型分別對應什么場景?

    回復
  2. 把釘釘的審批流程配置一遍就曉得了

    來自四川 回復
  3. 干貨,不錯

    回復
  4. 棒,學習了

    來自四川 回復
  5. 干貨

    來自北京 回復