本文作者主要總結(jié)后臺設(shè)計的基石：RBAC和workflow。enjoy~

后臺產(chǎn)品同學(xué)在設(shè)計后臺時，會發(fā)現(xiàn)一般后臺的各個功能模塊總結(jié)起來有兩大類型：功能類、流程類。在設(shè)計功能或流程前都需要預(yù)判不同的使用角色對應(yīng)不同權(quán)限，設(shè)計流程前則還得思考最基本的工作流原理。

用戶權(quán)限是設(shè)計后臺普適的基本管理功能，設(shè)計系統(tǒng)時幾乎都需要考慮權(quán)限問題。后臺系統(tǒng)在面對不同部門不同崗位的人員時，如何區(qū)分授權(quán)？在考慮前端不同身份的用戶訪問時（如普通用戶、普通會員、超級會員），如何自動判斷權(quán)限？工作流則是設(shè)計流程需要具備的基本理論，一個完整的流程會會包含哪些節(jié)點動作？節(jié)點是否可自主配置？

本文主要總結(jié)后臺設(shè)計的基石：RBAC和workflow。

RBAC

1、什么是RBAC

RBAC（Role-Based Access Control）基于角色的訪問控制。這是從傳統(tǒng)的權(quán)限模型基礎(chǔ)上，改進而來并且相當成熟的權(quán)限模型。這里強調(diào)三個要素：用戶、角色、權(quán)限。用戶與角色是多對多關(guān)系，角色與權(quán)限是多對多關(guān)系。

傳統(tǒng)模型中無角色概念，直接為用戶賦上權(quán)限，一是導(dǎo)致配置權(quán)限相當麻煩，二來無法快速為多個用戶批量刪除權(quán)限。用戶—角色—權(quán)限多對多的關(guān)系，解決了這些問題。

關(guān)鍵元素：

• 用戶：成功認證并登錄系統(tǒng)的操作員（主體：who）
• 權(quán)限：訪問資源的許可（how）
• 角色：權(quán)限的集合體
• 資源：引入這第四個概念，包括系統(tǒng)菜單、頁面、按鈕等（what）

主體（who）如何通過權(quán)限（how）訪問資源(what resource)。

權(quán)限是用來訪問資源的，為用戶賦予權(quán)限，則可訪問資源；在權(quán)限基礎(chǔ)上，將權(quán)限打包為一個權(quán)限集合—角色，如財務(wù)經(jīng)理角色，則為用戶賦上財務(wù)經(jīng)理角色，用戶可訪問財務(wù)經(jīng)理角色下的資源集合。

2、RBAC模型解讀

根據(jù)RBAC的復(fù)雜度不同，可分為RBAC0，RBAC1，RBAC2，RBAC3.最常用的為RBAC0.

（1）RBAC0模型

將一個或多個權(quán)限掛到角色下，在將一個或多個角色賦予用戶，權(quán)限與角色的關(guān)系，角色與用戶的關(guān)系，均是多對多的關(guān)系。

場景。為財務(wù)經(jīng)理崗建立財務(wù)經(jīng)理角色，將對賬、付款審批、回款確認等權(quán)限配置在財務(wù)經(jīng)理角色下，則公司再更換財務(wù)經(jīng)理人員，只需每次為新來的財務(wù)經(jīng)理配置財務(wù)經(jīng)理角色。

為客戶經(jīng)理建立客戶經(jīng)理角色，客戶管理、客戶查詢、搶單等權(quán)限配置在客戶經(jīng)理角色下，適應(yīng)于公司流動性高且占比龐大（多的甚至上千人）的客戶經(jīng)理群體，若某個權(quán)限不適宜配置給客戶經(jīng)理，直接在角色中刪除即可，無需分別對每個人進行權(quán)限刪除。

（2）RBAC1模型

引入繼承概念，一個角色可以從另一個角色繼承許可權(quán)。角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系允許角色間的多繼承，受限繼承關(guān)系則進一步要求角色繼承關(guān)系是一個樹結(jié)構(gòu)。

場景。適用于角色之間的層次明確，如總經(jīng)理與副總經(jīng)理，業(yè)務(wù)部門如總經(jīng)理–團隊經(jīng)理–業(yè)務(wù)員。也適用于用戶分級管理，初級用戶只能使用部分功能，中級用戶能夠使用更多功能。

（3）RBAC2模型

加入了角色的訪問控制。規(guī)定了權(quán)限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應(yīng)遵循的強制性規(guī)則。

包括靜態(tài)職責分離SSD(Static Separation of Duty)和動態(tài)職責分離DSD(Dynamic DSD(Dynamic Separation of Duty)。

• 互斥角色 ：同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。案例：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。
• 基數(shù)約束 ：一個角色被分配的用戶數(shù)量受限；一個用戶可擁有的角色數(shù)目受限；一個角色的權(quán)限數(shù)目受限。案例：如VP類角色不可隨意分配給多個用戶。
• 先決條件角色 ：指要想獲得較高的權(quán)限，要首先擁有低一級的權(quán)限。案例：先有副總經(jīng)理全下，才能有總經(jīng)理權(quán)限。
• 運行時互斥 ：例如，允許一個用戶具有兩個角色，但不可同時激活這兩個角色。

（4）RBAC3模型

RBAC1+RBAC2的集合體。即支持角色間的繼承關(guān)系，又支持角色間的責任分離關(guān)系。一般無需如此全面負責的模型。

3、關(guān)于一般角色、數(shù)據(jù)角色、成員角色

角色一般可拆分為一般角色、數(shù)據(jù)角色、成員角色。

• 一般角色：可見功能菜單頁、功能操作按鈕、數(shù)據(jù)字段，均可通過顆粒度較細的權(quán)限，去組合成一般角色。
• 數(shù)據(jù)角色：指可查詢的數(shù)據(jù)范圍。同一個一般角色，如查看客戶數(shù)據(jù)，大區(qū)總監(jiān)能看到整個大區(qū)的數(shù)據(jù)，上海分公司經(jīng)理只能看到上?？蛻魯?shù)據(jù)。上級組織職能看到下級組織員工負責的數(shù)據(jù)，而不能看到其他平級組織及其下級組織的員工數(shù)據(jù)等。
• 成員角色：新建成員即自動賦予的角色，即普通用戶均有的常規(guī)權(quán)限，無需再手動配置。

4、常見的常規(guī)管理功能

（1）用戶管理

用戶按架構(gòu)新建在對應(yīng)的組織上。一般掛到機構(gòu)→部門（一級部門–二級部門）下。

對于公司內(nèi)部管理系統(tǒng)，管理用戶的前提，是需要合理的組織架構(gòu)，只有支持組織架構(gòu)的靈活配置，才能進一步支持組織內(nèi)人員的增刪調(diào)整。

（2）角色管理

所有角色的管理功能。新建角色時，可將角色建立在某級機構(gòu)或機構(gòu)及以下，代表此角色只能適用此級別或此級別以下級別。

（3）菜單管理（有的后臺叫欄目管理）

支持自主配置菜單一級二級，支持新增菜單、修改菜單、刪除菜單，更改菜單（修改菜單名、菜單順序等），每個菜單對應(yīng)一個權(quán)限。

（4）組管理

用戶所屬組，用于配置統(tǒng)一組同一部門用戶。有了用戶組，在新建角色時，可直接將角色賦予某個組，則進入此組的人員自動獲得對應(yīng)角色。

workflow

一個業(yè)務(wù)流程包含多個環(huán)節(jié)的審批確認關(guān)系，按照業(yè)務(wù)流程，將各個節(jié)點串接起來，即時工作流。系統(tǒng)實現(xiàn)各個節(jié)點的自動流轉(zhuǎn)，解決手工處理工作流程的低效和失誤，提高工作效率的同時，還可通過線上直接流程狀況進行實時跟蹤，實現(xiàn)業(yè)務(wù)流程流轉(zhuǎn)的自動化。

1、工作流常見的路由方式

（1）串行路由

按順序一個步驟接著一個步驟走流程：

案例：入職流程，人力專員提交——HRBP審批——人力總監(jiān)審批，順序走完流程。

（2）并行路由

同時可以執(zhí)行多個不同的節(jié)點：

（3）條件路由

滿足條件后導(dǎo)向一個節(jié)點，不滿足條件的導(dǎo)向另外一個節(jié)點。

案例：流程提交滿足XX模式，則走A節(jié)點，不滿足則走B節(jié)點。

（4）分支路由

分支路由平行分支出多條線路，多條線路之間是并行的關(guān)系。

案例：付款申請，提交后判斷，對公付款走對公審批，對私付款走對私審批。

（5）合并路由

并行的多路分支集結(jié)到一個點的路由方式，前序分支節(jié)點全部都經(jīng)過處理，最終才到匯合節(jié)點處理

案例：多個申請項目，同一天提交到終審崗審批。

（6）循環(huán)路由

下一步返回到原來的任意一個步驟，這之間形成的回路就是一個循環(huán)路由。

案例：發(fā)起的流程，條到某崗位后，再流轉(zhuǎn)到自己確認，再提交。

（7）自由跳轉(zhuǎn)

這種是很特殊的路由方式，在流程實際運行時跳出原來定義的線路，自由跳轉(zhuǎn)到任意的步驟。

案例：滿足某個條件，則自動跳過某個崗位，無需此崗位再審批。

2、常見節(jié)點動作

• 提交：每個節(jié)點的人將流程提交至下手崗位。
• 回退：可退回到某個節(jié)點繼續(xù)流轉(zhuǎn)，退回到發(fā)起崗，或退回到前手崗。
• 撤回：節(jié)點執(zhí)行完后、下一節(jié)點執(zhí)行前，可以收回進行修改然后再提交。
• 取消/撤銷：流程發(fā)起人執(zhí)行取消流程。
• 中止：流程提前結(jié)束，當前節(jié)點之后的其它節(jié)點不再執(zhí)行。
• 審批：表單中的某個字段，用于填寫審批意見。
• 會簽：通常用于審批后給相關(guān)的人簽字確認，需要簽字確認。
• 知會：指定的人知道有這個流程這么回事，并能查看流程，不需要簽字確認。
• 加簽：審批時，可以征求另一人或多人的意見，然后再回到原審批人。
• 跳簽：跳過接下來的一個或連續(xù)的多個節(jié)點，直接到指定的節(jié)點執(zhí)行。
• ……

3、上報關(guān)系

每個節(jié)點提交后，下一節(jié)點將有誰審批？一般會為對應(yīng)崗位的人員配置對應(yīng)的節(jié)點。但若涉及到分公司或分地區(qū)審批，則需要設(shè)計上報關(guān)系。

上報關(guān)系支持靈活配置前一崗與后一崗的對應(yīng)關(guān)系。如北京分公司的審批，提交到財務(wù)審核時，只能提交到北京財務(wù)部。合作公司的審批，只能提交到綜合財務(wù)部。此時就需要提前配置上報關(guān)系，北京分公司——北京財務(wù)部；合作公司—-綜合財務(wù)部。各個部門均可配置對應(yīng)上報關(guān)系，包括財務(wù)，人力，業(yè)務(wù)等。

最后，為用戶配置某個財務(wù)部的權(quán)限，則其僅可接收特定對應(yīng)的上報關(guān)系的審批申請。如權(quán)限為綜合財務(wù)部用戶，僅可收到合作公司提交的申請單。

BRAC和流程節(jié)點，在設(shè)計過程中，還需考慮其靈活性。

如操作員入職流程完畢后，自動賦予其崗位對應(yīng)角色權(quán)限，當然這可通過對用戶組分配角色實現(xiàn)。當操作員調(diào)崗時，根據(jù)調(diào)崗的跨度大小，自主確定是否更改權(quán)限或刪除權(quán)限。流程節(jié)點在系統(tǒng)中可根據(jù)對應(yīng)業(yè)務(wù)，后臺預(yù)備支撐性較強的節(jié)點變量，支持前臺配置，由管理員自主根據(jù)對應(yīng)業(yè)務(wù)流程，配置相應(yīng)的流轉(zhuǎn)節(jié)點。

作者：柴小英，先后混跡于大數(shù)據(jù)及互金領(lǐng)域，負責過資金端理財平臺及資產(chǎn)端信貸后臺，現(xiàn)任銀客集團資產(chǎn)端產(chǎn)品經(jīng)理

本文由 @柴小英 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pixabay，基于 CC0 協(xié)議