實戰篇:B端權限管理
本篇以筆者做過的一個復雜項目為例,講講進行權限管理的實戰總結。
一、項目背景
本次項目是為某研究院搭建一套信息化系統,包括統一用戶管理平臺、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協議
這句話“可以為用戶分配相應的崗位,用戶與崗位的關系是一對多?!庇脩艉蛵徫皇且粚Χ?,不是多對多嗎,一個崗位只能屬于一個用戶?有點困惑。也是對崗位的理解不太能想明白,是用戶組的概念嗎
類似財務部、績效部等職能部門,需要查看銷售公司一和銷售公司二的的訂單數據,這個權限設計是否還適合呢
看完對組織架構和權限的關系清晰了很多哈,好棒
可以直接刪除角色嗎?如果可以直接刪除那么角色管理里面的用戶所隊形的權限是否也隨之消失
角色刪掉了,擁有這個崗位-角色的用戶,應該也會失去被刪掉的角色所關聯的權限。
角色是否能刪除,可以根據業務實際情況,分出不能刪的基礎角色 和可以刪的拓展性角色吧。。
為什么不直接在角色上加入數據權限,而是再引入一個崗位
職位 、匯報線 和實際工作在實際工作中是不一致或者交叉的
我理解是通過崗位關聯組織結構,而角色沒有關聯組織結構?
同問,銷售屬于崗位還是角色,為角色分配權限后那么該角色下的所有用戶也分配了,角色可以有很多用戶,崗位也可以有很多用戶,不知道崗位存在的意義,請解惑!
是的,加一個崗位,相當于多了一層關系,開發工作量更大。從文章描述來說,確實看不出崗位的作用。就算要數據隔離,其實角色本身就夠了。
一般的系統設計中,不會引入崗位,引入崗位會讓權限體系更為復雜,但并不是崗位沒有作用;崗位的引入可以解決集中復雜的業務場景:
1、一個多崗的情況下,該用戶不同崗位的上級查看不同的數據;
2、下級向上級匯報工作;
3、離職員工工作數據的繼承
等
解決了我很多問題
分配角色和職位中,數據權限,不能和部門用同一個字段。因為某部門下的人員可能需要他的上級數據權限
按理應該要拆分開,即使同一部門,默認權限可能相似,但部分人員可能會擁有特殊的權限
是的,數據權限一般是本人、本部門、本部門及下級部門之類的,跟部門/角色使用同一個字段是不合理的。向上的數據權限一般不是通用需求,可以通過團隊或者具體單據的權限去特殊處理。
貌似以當前這種維度來構建權限管理不利于后期的使用和維護。我覺得以公司為維度來搭建,其中用戶列表頁增加公司篩選,用公司、崗位、角色三個維度來關聯用戶權限和數據權限,這樣在對某個公司進行統計或者其他的時候都比較清晰,不會混在一起
您說的公司是指組織機構的維度嗎?
您好,看了您的文章受益匪淺,但是有兩點還有些疑問,能和您再請教一下嗎?
1、數據查看權限分成本人、本部門、本部門及下級部門,這里您說冗余且體驗感差,想問一下這樣設置是有什么坑嗎?
2、崗位和角色如何配合使用,能具體講解一下嗎?
如果可以,希望能添加您的微信具體咨詢一下可以嗎?
來,一起討論下權限管理。加個微信13628331823
1、數據查看權限說的“冗余”是指項目上我們產品把數據權限跟崗位綁定死了。分成本人、本部門、本部門及下級部門是沒有問題的。
2、不同的權限模型適用場景可以看這篇,人人社區不讓發
https://mp.weixin.qq.com/s?__biz=MzIzNjY3NzEyMw==&mid=2247483682&idx=1&sn=8e45340d19fff4bf338beee5ee27f325&chksm=e8d5704edfa2f9580a2e31513d701346b63c517724cf5e2aab1f115b7c8a75c90988fe045ee7&token=221420451&lang=zh_CN#rd
很贊
貌似也可以直接用戶對應角色,不用中間加一層“崗位”對應關系
三層權限模型適用場景也很多,但是在這個案例里面不太適合呢。因為這個案例的組織機構復雜,數據權限要求很細,如果用戶直接對應角色,數據權限管理在靈活性和可擴展性上都會比較受限
需要的,有些系統中叫復合角色
這個是什么意思?是類似于多個role集合成一個新的role???
復合角色的定義是怎樣的?它具體是為了解決什么問題(是解決某個角色擁有多個層級的權限問題嗎?)
感謝,受教了!
角色與崗位有什么區別???請教一下
角色是功能權限的合集,崗位可以理解成角色和組織機構(數據權限)的合集。
關于權限管理我總結過一篇文章,但是人人社區不讓發,希望對你有幫助~
https://mp.weixin.qq.com/s?__biz=MzIzNjY3NzEyMw==&mid=2247483682&idx=1&sn=8e45340d19fff4bf338beee5ee27f325&chksm=e8d5704edfa2f9580a2e31513d701346b63c517724cf5e2aab1f115b7c8a75c90988fe045ee7&token=221420451&lang=zh_CN#rd
之前糾結了好久,功能權限好控制,數據權限真的是一個用戶一個需求,看來復雜需求時,崗位來控制數據權限還是需要的,多謝!
先馬了 后面再看