本篇以筆者做過的一個複雜項目為例，講講進行權限管理的實戰總結。
一、項目背景
本次項目是為某研究院搭建一套信息化系統，包括統一用戶管理平臺、CSS系統、CRM系統、兩套LIMS系統。
其中統一用戶管理平臺由客戶IT部門管理，決定哪個用戶能夠登錄哪個系統。
CRM系統由內部管理人員、商務、內勤、辦公室、財務等人員使用，用於客戶管理和內部管理，需要實現很多跨部門協同的功能，而且是以上各系統中使用人員和範圍最廣的一個系統。
以下分析均以CRM系統為例：
- 信息化基礎：該研究院IT基礎薄弱，目前只有GLP實驗室管理系統。
- 組織架構：該研究院組織架構較為複雜，包括總部和子公司。部分人員交織在一起，而且組織機構還在不斷調整中。
二、權限管理實戰
在具體項目中，我們按照【梳理組織架構 – 確定權限管理設計框架 – 開展具體的產品設計 – 梳理角色權限和數據權限 – 初始化配置 – 根據客戶需要進行調整】的順序，去實現合適的權限管理。
1. 梳理組織架構
對客戶實際組織架構和業務情況進行了解梳理，總結如下：
- 其中財務部歸總部管理，財務部管理所有下屬子公司和業務部門的費用、風險控制。子公司一為獨立法人公司，但部分員工、資產和資質仍歸屬總部。
- 子公司一簽署的合同主體既有獨立法人公司的，又有總部的。但子公司一的員工、資產和資質將逐漸從總部剝離。
- 子公司二為獨立法人公司，簽署的合同主體、授信均為本公司。
- 業務一部歸總部管理，簽署的合同主體、授信均為總部。
- 子公司一、子公司二、業務一部的業務數據要進行隔離。
2. 確定權限管理設計框架
通過對組織機構的梳理，並通過用戶訪談對業務進行了深入的理解，我們總結出：
- 該系統需要對各子公司和業務部門的客戶數據和業務數據進行隔離；
- 各子公司和業務部門均有銷售經理、辦公室經理、商務、內勤、辦公室幾個角色，而且通過了解，同角色的人員所負責的事項都是相同的；
- 有一些特殊的權限管理需求：例如商務、內勤只具有本人的業務單據權限，但可以查看操作所屬法人公司的到賬、授信、客戶餘額等數據。
可以看出，傳統的權限管理模型顯然不能滿足該系統的權限管理需要。如果使用傳統的RBAC模型，也存在多個角色重複創建、無法管理數據權限的問題。
因此，我們確定在CRM系統上，應該使用基於RBAC的擴展模型。通過崗位管理用戶在系統中的功能權限和數據權限，以滿足客戶需求。
3. 開展具體的產品設計
（1）用戶管理
1）用戶列表、查詢
用戶列表頁展示用戶名（即用戶在系統中的賬號名）、姓名（用戶實際姓名）、電話、郵箱、狀態、部門、崗位等有價值的信息。
同時具備編輯、啟用、分配崗位功能。
2）用戶新增、編輯、刪除
本項目中，用戶的新增、刪除均通過統一用戶管理平臺進行，並分配系統級權限。
各系統中自行編輯、分配權限。
用戶的字段包括登錄郵箱、手機號碼、姓名、用戶名、部門、性別等字段，其中姓名和部門為必填項。
3）禁用
如果出現用戶離職的情況，可以將用戶禁用，不可登錄系統，防止業務數據流失。
4）分配崗位
可以為用戶分配相應的崗位，用戶與崗位的關係是一對多。
（2）組織機構管理
1）組織機構列表、查詢
左側為組織機構，可以編輯組織的層級關係。
右側為該組織機構下的崗位列表，可以對崗位進行查看、編輯、刪除、分配角色和數據權限、分配用戶的操作。
2）新增、編輯部門
點擊組織機構右側的“+”按鈕，可新增子部門。
填寫部門編碼、部門名稱、部門類型、公司類型。默認新增部門為所選部門的子部門。
其中，公司類型是這個項目的特殊需求，與客戶業務相關，正常權限管理一般不需要這個字段。
3）刪除部門
點擊部門右側的“刪除”圖標，可以刪除該組織節點。
（3）角色管理
1）角色列表
左側為角色列表，右側為角色對應的功能權限。功能權限可以根據客戶需求，可以細緻到按鈕級，也可以只管理到頁面級別。
2）角色新建
點擊“新建角色”按鈕，輸入角色編碼、名稱和備註。
其中，如果有特殊的權限需求，一般要與角色編碼掛鉤，這種情況下角色編碼需要與技術團隊約定規則，不可隨意變更。
3）分配功能權限
點擊左側的角色名稱，可以在右側列出的功能列表中，對該角色分配相應的功能權限。
（4）崗位管理
1）崗位列表
在崗位列表頁可查看崗位名稱、崗位編碼和部門。並可對崗位進行查看、刪除、編輯、分配角色和數據權限、分配用戶的操作。
2）新建崗位
點擊左側的組織機構，即可創建該組織節點下的崗位，部門默認為左側所選的組織節點。
填寫崗位名稱、崗位編碼、選擇部門。崗位編碼同角色編碼，若有特殊權限需求，要與開發制定相應的規則，不可隨意變更。
3）崗位詳情
點擊“查看”按鈕，可以查看崗位詳細信息和具有該崗位的人員列表。
4）分配角色和數據權限
為崗位分配其角色和數據權限。
崗位和角色之間是多對多的關係，一個崗位可以具有多種角色，一種角色也可被賦予多個崗位。
數據權限本次項目上做的非常冗餘、用戶體驗極差，給每個角色又配置了相同的名稱和數據權限，即“職能”，系統管理員還不能編輯崗位職能。（我也不知道當時產品和開發咋想的哈哈哈）
通常來說，應當直接分配數據權限：本人、本部門、本部門及下級部門，簡單明瞭。
另外，若組織機構比較複雜，可以加上“法人公司”的數據權限，往上追溯離用戶最近的法人公司。用戶即具備法人公司下的業務數據權限。
5）分配用戶
點擊“分配用戶”按鈕，可將崗位分配給用戶。用戶與崗位是多對多的關係。
4. 梳理角色權限表單
通過組織機構分析和產品設計，我們已經抽象出可以使用CRM系統的角色。
這時就需要產品經理梳理角色權限表單，目的有二：
- 測試階段需要初步驗證業務流程是否可以正常進行；
- B端客戶對系統一般不太熟悉和了解，讓用戶梳理角色權限是不太可能的。因此在上線前我們往往會初始化角色權限，用戶只需要在後續使用中進行調整即可。
角色權限表單可參考下圖：
5. 梳理數據權限
對各崗位的數據權限進行梳理，若存在無法通過系統配置的特殊權限需求，需要與開發溝通，通過代碼寫死或者約定一定的規則，用角色編碼或崗位編碼實現。
例如：本項目上，商務人員、內勤人員的客戶和委託單數據權限為本人，但是對於循環授信、到賬公告和客戶餘額，他們又需要查看和使用其所屬法人公司的數據。
6. 系統上線、試運行
系統上線時，需要對角色權限進行初始化配置，並通過用戶培訓和配置文檔將配置規則教給客戶。
上線試運行期間，可以由運維人員協助客戶對實際業務的新情況調整權限配置，在過程中讓客戶IT人員逐漸熟悉權限配置規則。
在使用過程中，客戶也必然會提出一些新的特殊權限的需求，這時候需要產品進行評估，根據對現有權限框架的影響決定是否變更。
最後，權限管理體系下的用戶登錄有兩種方式：
- 用戶登錄時，僅能選擇一個崗位，其在系統中可查看和操作的功能和數據均為該崗位的功能權限和數據權限；
- 用戶使用一個賬號登錄，登錄後具有其所有崗位的全集功能和數據權限。這種情況下，在權限配置時，一定要特別注意角色的靜態互斥和動態互斥。
PS：對於特殊權限，大家有何高見歡迎評論指教，感謝！
本文由 @夏至 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議
