酷播亮新聞
本文作者主要總結後台設計的基石：RBAC和workflow。 enjoy~
後台產品同學在設計後台時，會發現一般後台的各個功能模塊總結起來有兩大類型：功能類、流程類。 在設計功能或流程前都需要預判不同的使用角色對應不同權限，設計流程前則還得思考最基本的工作流原理。
用戶權限是設計後台普適的基本管理功能，設計系統時幾乎都需要考慮權限問題。 後台系統在面對不同部門不同崗位的人員時，如何區分授權？ 在考慮前端不同身份的用戶訪問時（如普通用戶、普通會員、超級會員），如何自動判斷權限？ 工作流則是設計流程需要具備的基本理論，一個完整的流程會會包含哪些節點動作？ 節點是否可自主配置？
本文主要總結後台設計的基石：RBAC和workflow。
RBAC
1、什麼是RBAC
RBAC（Role-Based Access Control）基於角色的訪問控制。 這是從傳統的權限模型基礎上，改進而來並且相當成熟的權限模型。 這裡強調三個要素：用戶、角色、權限。 用戶與角色是多對多關係，角色與權限是多對多關係。
傳統模型中無角色概念，直接為用戶賦上權限，一是導致配置權限相當麻煩，二來無法快速為多個用戶批量刪除權限。 用戶—角色—權限多對多的關係，解決了這些問題。
關鍵元素：
- 用戶： 成功認證並登錄系統的操作員（主體：who）
- 權限： 訪問資源的許可（how）
- 角色： 權限的集合體
- 資源： 引入這第四個概念，包括系統菜單、頁面、按鈕等（what）
主體（who）如何通過權限（how）訪問資源(what resource)。
權限是用來訪問資源的，為用戶賦予權限，則可訪問資源；在權限基礎上，將權限打包為一個權限集合—角色，如財務經理角色，則為用戶賦上財務經理角色，用戶可訪問 財務經理角色下的資源集合。
2、RBAC模型解讀
根據RBAC的複雜度不同，可分為RBAC0，RBAC1，RBAC2，RBAC3.最常用的為RBAC0.
（1）RBAC0模型
將一個或多個權限掛到角色下，在將一個或多個角色賦予用戶，權限與角色的關係，角色與用戶的關係，均是多對多的關係。
場景。 為財務經理崗建立財務經理角色，將對賬、付款審批、回款確認等權限配置在財務經理角色下，則公司再更換財務經理人員，只需每次為新來的財務經理配置財務經理角色 。
為客戶經理建立客戶經理角色，客戶管理、客戶查詢、搶單等權限配置在客戶經理角色下，適應於公司流動性高且佔比龐大（多的甚至上千人）的客戶經理群體，若某 個權限不適宜配置給客戶經理，直接在角色中刪除即可，無需分別對每個人進行權限刪除。
（2）RBAC1模型
引入繼承概念，一個角色可以從另一個角色繼承許可權。 角色間的繼承關係可分為一般繼承關係和受限繼承關係。 一般繼承關係允許角色間的多繼承，受限繼承關係則進一步要求角色繼承關係是一個樹結構。
場景。 適用於角色之間的層次明確，如總經理與副總經理，業務部門如總經理–團隊經理–業務員。 也適用於用戶分級管理，初級用戶只能使用部分功能，中級用戶能夠使用更多功能。
（3）RBAC2模型
加入了角色的訪問控制。 規定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。
包括靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic DSD(Dynamic Separation of Duty)。
- 互斥角色 ： 同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。 案例：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。
- 基數約束 ： 一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；一個角色的權限數目受限。 案例：如VP類角色不可隨意分配給多個用戶。
- 先決條件角色 ： 指要想獲得較高的權限，要首先擁有低一級的權限。 案例：先有副總經理全下，才能有總經理權限。
- 運行時互斥 ：例如，允許一個用戶具有兩個角色，但不可同時激活這兩個角色。
（4）RBAC3模型
RBAC1+RBAC2的集合體。 即支持角色間的繼承關係，又支持角色間的責任分離關係。 一般無需如此全面負責的模型。
3、關於一般角色、數據角色、成員角色
角色一般可拆分為一般角色、數據角色、成員角色。
- 一般角色： 可見功能菜單頁、功能操作按鈕、數據字段，均可通過顆粒度較細的權限，去組合成一般角色。
- 數據角色： 指可查詢的數據范圍。 同一個一般角色，如查看客戶數據，大區總監能看到整個大區的數據，上海分公司經理只能看到上海客戶數據。 上級組織職能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等。
- 成員角色： 新建成員即自動賦予的角色，即普通用戶均有的常規權限，無需再手動配置。
4、常見的常規管理功能
（1）用戶管理
用戶按架構新建在對應的組織上。 一般掛到機構→部門（一級部門–二級部門）下。
對於公司內部管理系統，管理用戶的前提，是需要合理的組織架構，只有支持組織架構的靈活配置，才能進一步支持組織內人員的增刪調整。
（2）角色管理
所有角色的管理功能。 新建角色時，可將角色建立在某級機構或機構及以下，代表此角色只能適用此級別或此級別以下級別。
（3）菜單管理（有的後台叫欄目管理）
支持自主配置菜單一級二級，支持新增菜單、修改菜單、刪除菜單，更改菜單（修改菜單名、菜單順序等），每個菜單對應一個權限。
（4）組管理
用戶所屬組，用於配置統一組同一部門用戶。 有了用戶組，在新建角色時，可直接將角色賦予某個組，則進入此組的人員自動獲得對應角色。
workflow
一個業務流程包含多個環節的審批確認關係，按照業務流程，將各個節點串接起來，即時工作流。 系統實現各個節點的自動流轉，解決手工處理工作流程的低效和失誤，提高工作效率的同時，還可通過線上直接流程狀況進行實時跟踪，實現業務流程流轉的自動化。
1、工作流常見的路由方式
（1）串行路由
按順序一個步驟接著一個步驟走流程：
案例：入職流程，人力專員提交——HRBP審批——人力總監審批，順序走完流程。
（2）並行路由
同時可以執行多個不同的節點：
（3）條件路由
滿足條件後導向一個節點，不滿足條件的導向另外一個節點。
案例：流程提交滿足XX模式，則走A節點，不滿足則走B節點。
（4）分支路由
分支路由平行分支出多條線路，多條線路之間是並行的關係。
案例：付款申請，提交後判斷，對公付款走對公審批，對私付款走對私審批。
（5）合併路由
並行的多路分支集結到一個點的路由方式，前序分支節點全部都經過處理，最終才到匯合節點處理
案例：多個申請項目，同一天提交到終審崗審批。
（6）循環路由
下一步返回到原來的任意一個步驟，這之間形成的迴路就是一個循環路由。
案例：發起的流程，條到某崗位後，再流轉到自己確認，再提交。
（7）自由跳轉
這種是很特殊的路由方式，在流程實際運行時跳出原來定義的線路，自由跳轉到任意的步驟。
案例：滿足某個條件，則自動跳過某個崗位，無需此崗位再審批。
2、常見節點動作
- 提交： 每個節點的人將流程提交至下手崗位。
- 回退： 可退回到某個節點繼續流轉，退回到發起崗，或退回到前手崗。
- 撤回： 節點執行完後、下一節點執行前，可以收回進行修改然後再提交。
- 取消/撤銷： 流程發起人執行取消流程。
- 中止： 流程提前結束，當前節點之後的其它節點不再執行。
- 審批： 表單中的某個字段，用於填寫審批意見。
- 會簽： 通常用於審批後給相關的人簽字確認，需要簽字確認。
- 知會： 指定的人知道有這個流程這麼回事，並能查看流程，不需要簽字確認。
- 加簽： 審批時，可以徵求另一人或多人的意見，然後再回到原審批人。
- 跳簽： 跳過接下來的一個或連續的多個節點，直接到指定的節點執行。
- ……
3、上報關係
每個節點提交後，下一節點將有誰審批？ 一般會為對應崗位的人員配置對應的節點。 但若涉及到分公司或分地區審批，則需要設計上報關係。
上報關係支持靈活配置前一崗與後一崗的對應關係。 如北京分公司的審批，提交到財務審核時，只能提交到北京財務部。 合作公司的審批，只能提交到綜合財務部。 此時就需要提前配置上報關係，北京分公司——北京財務部；合作公司—-綜合財務部。 各個部門均可配置對應上報關係，包括財務，人力，業務等。
最後，為用戶配置某個財務部的權限，則其僅可接收特定對應的上報關係的審批申請。 如權限為綜合財務部用戶，僅可收到合作公司提交的申請單。
BRAC和流程節點，在設計過程中，還需考慮其靈活性。
如操作員入職流程完畢後，自動賦予其崗位對應角色權限，當然這可通過對用戶組分配角色實現。 當操作員調崗時，根據調崗的跨度大小，自主確定是否更改權限或刪除權限。 流程節點在系統中可根據對應業務，後台預備支撐性較強的節點變量，支持前台配置，由管理員自主根據對應業務流程，配置相應的流轉節點。
作者：柴小英，先後混跡於大數據及互金領域，負責過資金端理財平台及資產端信貸後台，現任銀客集團資產端產品經理
本文由 @柴小英 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自 Pixabay，基於 CC0 協議