實戰(zhàn)篇:B端權(quán)限管理
本篇以筆者做過的一個復(fù)雜項目為例,講講進行權(quán)限管理的實戰(zhàn)總結(jié)。
一、項目背景
本次項目是為某研究院搭建一套信息化系統(tǒng),包括統(tǒng)一用戶管理平臺、CSS系統(tǒng)、CRM系統(tǒng)、兩套LIMS系統(tǒng)。
其中統(tǒng)一用戶管理平臺由客戶IT部門管理,決定哪個用戶能夠登錄哪個系統(tǒng)。
CRM系統(tǒng)由內(nèi)部管理人員、商務(wù)、內(nèi)勤、辦公室、財務(wù)等人員使用,用于客戶管理和內(nèi)部管理,需要實現(xiàn)很多跨部門協(xié)同的功能,而且是以上各系統(tǒng)中使用人員和范圍最廣的一個系統(tǒng)。
以下分析均以CRM系統(tǒng)為例:
- 信息化基礎(chǔ):該研究院IT基礎(chǔ)薄弱,目前只有GLP實驗室管理系統(tǒng)。
- 組織架構(gòu):該研究院組織架構(gòu)較為復(fù)雜,包括總部和子公司。部分人員交織在一起,而且組織機構(gòu)還在不斷調(diào)整中。
二、權(quán)限管理實戰(zhàn)
在具體項目中,我們按照【梳理組織架構(gòu) – 確定權(quán)限管理設(shè)計框架 – 開展具體的產(chǎn)品設(shè)計 – 梳理角色權(quán)限和數(shù)據(jù)權(quán)限 – 初始化配置 – 根據(jù)客戶需要進行調(diào)整】的順序,去實現(xiàn)合適的權(quán)限管理。
1. 梳理組織架構(gòu)
對客戶實際組織架構(gòu)和業(yè)務(wù)情況進行了解梳理,總結(jié)如下:
- 其中財務(wù)部歸總部管理,財務(wù)部管理所有下屬子公司和業(yè)務(wù)部門的費用、風(fēng)險控制。子公司一為獨立法人公司,但部分員工、資產(chǎn)和資質(zhì)仍歸屬總部。
- 子公司一簽署的合同主體既有獨立法人公司的,又有總部的。但子公司一的員工、資產(chǎn)和資質(zhì)將逐漸從總部剝離。
- 子公司二為獨立法人公司,簽署的合同主體、授信均為本公司。
- 業(yè)務(wù)一部歸總部管理,簽署的合同主體、授信均為總部。
- 子公司一、子公司二、業(yè)務(wù)一部的業(yè)務(wù)數(shù)據(jù)要進行隔離。
2. 確定權(quán)限管理設(shè)計框架
通過對組織機構(gòu)的梳理,并通過用戶訪談對業(yè)務(wù)進行了深入的理解,我們總結(jié)出:
- 該系統(tǒng)需要對各子公司和業(yè)務(wù)部門的客戶數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)進行隔離;
- 各子公司和業(yè)務(wù)部門均有銷售經(jīng)理、辦公室經(jīng)理、商務(wù)、內(nèi)勤、辦公室?guī)讉€角色,而且通過了解,同角色的人員所負責(zé)的事項都是相同的;
- 有一些特殊的權(quán)限管理需求:例如商務(wù)、內(nèi)勤只具有本人的業(yè)務(wù)單據(jù)權(quán)限,但可以查看操作所屬法人公司的到賬、授信、客戶余額等數(shù)據(jù)。
可以看出,傳統(tǒng)的權(quán)限管理模型顯然不能滿足該系統(tǒng)的權(quán)限管理需要。如果使用傳統(tǒng)的RBAC模型,也存在多個角色重復(fù)創(chuàng)建、無法管理數(shù)據(jù)權(quán)限的問題。
因此,我們確定在CRM系統(tǒng)上,應(yīng)該使用基于RBAC的擴展模型。通過崗位管理用戶在系統(tǒng)中的功能權(quán)限和數(shù)據(jù)權(quán)限,以滿足客戶需求。
3. 開展具體的產(chǎn)品設(shè)計
(1)用戶管理
1)用戶列表、查詢
用戶列表頁展示用戶名(即用戶在系統(tǒng)中的賬號名)、姓名(用戶實際姓名)、電話、郵箱、狀態(tài)、部門、崗位等有價值的信息。
同時具備編輯、啟用、分配崗位功能。
2)用戶新增、編輯、刪除
本項目中,用戶的新增、刪除均通過統(tǒng)一用戶管理平臺進行,并分配系統(tǒng)級權(quán)限。
各系統(tǒng)中自行編輯、分配權(quán)限。
用戶的字段包括登錄郵箱、手機號碼、姓名、用戶名、部門、性別等字段,其中姓名和部門為必填項。
3)禁用
如果出現(xiàn)用戶離職的情況,可以將用戶禁用,不可登錄系統(tǒng),防止業(yè)務(wù)數(shù)據(jù)流失。
4)分配崗位
可以為用戶分配相應(yīng)的崗位,用戶與崗位的關(guān)系是一對多。
(2)組織機構(gòu)管理
1)組織機構(gòu)列表、查詢
左側(cè)為組織機構(gòu),可以編輯組織的層級關(guān)系。
右側(cè)為該組織機構(gòu)下的崗位列表,可以對崗位進行查看、編輯、刪除、分配角色和數(shù)據(jù)權(quán)限、分配用戶的操作。
2)新增、編輯部門
點擊組織機構(gòu)右側(cè)的“+”按鈕,可新增子部門。
填寫部門編碼、部門名稱、部門類型、公司類型。默認新增部門為所選部門的子部門。
其中,公司類型是這個項目的特殊需求,與客戶業(yè)務(wù)相關(guān),正常權(quán)限管理一般不需要這個字段。
3)刪除部門
點擊部門右側(cè)的“刪除”圖標,可以刪除該組織節(jié)點。
(3)角色管理
1)角色列表
左側(cè)為角色列表,右側(cè)為角色對應(yīng)的功能權(quán)限。功能權(quán)限可以根據(jù)客戶需求,可以細致到按鈕級,也可以只管理到頁面級別。
2)角色新建
點擊“新建角色”按鈕,輸入角色編碼、名稱和備注。
其中,如果有特殊的權(quán)限需求,一般要與角色編碼掛鉤,這種情況下角色編碼需要與技術(shù)團隊約定規(guī)則,不可隨意變更。
3)分配功能權(quán)限
點擊左側(cè)的角色名稱,可以在右側(cè)列出的功能列表中,對該角色分配相應(yīng)的功能權(quán)限。
(4)崗位管理
1)崗位列表
在崗位列表頁可查看崗位名稱、崗位編碼和部門。并可對崗位進行查看、刪除、編輯、分配角色和數(shù)據(jù)權(quán)限、分配用戶的操作。
2)新建崗位
點擊左側(cè)的組織機構(gòu),即可創(chuàng)建該組織節(jié)點下的崗位,部門默認為左側(cè)所選的組織節(jié)點。
填寫崗位名稱、崗位編碼、選擇部門。崗位編碼同角色編碼,若有特殊權(quán)限需求,要與開發(fā)制定相應(yīng)的規(guī)則,不可隨意變更。
3)崗位詳情
點擊“查看”按鈕,可以查看崗位詳細信息和具有該崗位的人員列表。
4)分配角色和數(shù)據(jù)權(quán)限
為崗位分配其角色和數(shù)據(jù)權(quán)限。
崗位和角色之間是多對多的關(guān)系,一個崗位可以具有多種角色,一種角色也可被賦予多個崗位。
數(shù)據(jù)權(quán)限本次項目上做的非常冗余、用戶體驗極差,給每個角色又配置了相同的名稱和數(shù)據(jù)權(quán)限,即“職能”,系統(tǒng)管理員還不能編輯崗位職能。(我也不知道當時產(chǎn)品和開發(fā)咋想的哈哈哈)
通常來說,應(yīng)當直接分配數(shù)據(jù)權(quán)限:本人、本部門、本部門及下級部門,簡單明了。
另外,若組織機構(gòu)比較復(fù)雜,可以加上“法人公司”的數(shù)據(jù)權(quán)限,往上追溯離用戶最近的法人公司。用戶即具備法人公司下的業(yè)務(wù)數(shù)據(jù)權(quán)限。
5)分配用戶
點擊“分配用戶”按鈕,可將崗位分配給用戶。用戶與崗位是多對多的關(guān)系。
4. 梳理角色權(quán)限表單
通過組織機構(gòu)分析和產(chǎn)品設(shè)計,我們已經(jīng)抽象出可以使用CRM系統(tǒng)的角色。
這時就需要產(chǎn)品經(jīng)理梳理角色權(quán)限表單,目的有二:
- 測試階段需要初步驗證業(yè)務(wù)流程是否可以正常進行;
- B端客戶對系統(tǒng)一般不太熟悉和了解,讓用戶梳理角色權(quán)限是不太可能的。因此在上線前我們往往會初始化角色權(quán)限,用戶只需要在后續(xù)使用中進行調(diào)整即可。
角色權(quán)限表單可參考下圖:
5. 梳理數(shù)據(jù)權(quán)限
對各崗位的數(shù)據(jù)權(quán)限進行梳理,若存在無法通過系統(tǒng)配置的特殊權(quán)限需求,需要與開發(fā)溝通,通過代碼寫死或者約定一定的規(guī)則,用角色編碼或崗位編碼實現(xiàn)。
例如:本項目上,商務(wù)人員、內(nèi)勤人員的客戶和委托單數(shù)據(jù)權(quán)限為本人,但是對于循環(huán)授信、到賬公告和客戶余額,他們又需要查看和使用其所屬法人公司的數(shù)據(jù)。
6. 系統(tǒng)上線、試運行
系統(tǒng)上線時,需要對角色權(quán)限進行初始化配置,并通過用戶培訓(xùn)和配置文檔將配置規(guī)則教給客戶。
上線試運行期間,可以由運維人員協(xié)助客戶對實際業(yè)務(wù)的新情況調(diào)整權(quán)限配置,在過程中讓客戶IT人員逐漸熟悉權(quán)限配置規(guī)則。
在使用過程中,客戶也必然會提出一些新的特殊權(quán)限的需求,這時候需要產(chǎn)品進行評估,根據(jù)對現(xiàn)有權(quán)限框架的影響決定是否變更。
最后,權(quán)限管理體系下的用戶登錄有兩種方式:
- 用戶登錄時,僅能選擇一個崗位,其在系統(tǒng)中可查看和操作的功能和數(shù)據(jù)均為該崗位的功能權(quán)限和數(shù)據(jù)權(quán)限;
- 用戶使用一個賬號登錄,登錄后具有其所有崗位的全集功能和數(shù)據(jù)權(quán)限。這種情況下,在權(quán)限配置時,一定要特別注意角色的靜態(tài)互斥和動態(tài)互斥。
PS:對于特殊權(quán)限,大家有何高見歡迎評論指教,感謝!
本文由 @夏至 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
這句話“可以為用戶分配相應(yīng)的崗位,用戶與崗位的關(guān)系是一對多?!庇脩艉蛵徫皇且粚Χ?,不是多對多嗎,一個崗位只能屬于一個用戶?有點困惑。也是對崗位的理解不太能想明白,是用戶組的概念嗎
類似財務(wù)部、績效部等職能部門,需要查看銷售公司一和銷售公司二的的訂單數(shù)據(jù),這個權(quán)限設(shè)計是否還適合呢
看完對組織架構(gòu)和權(quán)限的關(guān)系清晰了很多哈,好棒
可以直接刪除角色嗎?如果可以直接刪除那么角色管理里面的用戶所隊形的權(quán)限是否也隨之消失
角色刪掉了,擁有這個崗位-角色的用戶,應(yīng)該也會失去被刪掉的角色所關(guān)聯(lián)的權(quán)限。
角色是否能刪除,可以根據(jù)業(yè)務(wù)實際情況,分出不能刪的基礎(chǔ)角色 和可以刪的拓展性角色吧。。
為什么不直接在角色上加入數(shù)據(jù)權(quán)限,而是再引入一個崗位
職位 、匯報線 和實際工作在實際工作中是不一致或者交叉的
我理解是通過崗位關(guān)聯(lián)組織結(jié)構(gòu),而角色沒有關(guān)聯(lián)組織結(jié)構(gòu)?
同問,銷售屬于崗位還是角色,為角色分配權(quán)限后那么該角色下的所有用戶也分配了,角色可以有很多用戶,崗位也可以有很多用戶,不知道崗位存在的意義,請解惑!
是的,加一個崗位,相當于多了一層關(guān)系,開發(fā)工作量更大。從文章描述來說,確實看不出崗位的作用。就算要數(shù)據(jù)隔離,其實角色本身就夠了。
一般的系統(tǒng)設(shè)計中,不會引入崗位,引入崗位會讓權(quán)限體系更為復(fù)雜,但并不是崗位沒有作用;崗位的引入可以解決集中復(fù)雜的業(yè)務(wù)場景:
1、一個多崗的情況下,該用戶不同崗位的上級查看不同的數(shù)據(jù);
2、下級向上級匯報工作;
3、離職員工工作數(shù)據(jù)的繼承
等
解決了我很多問題
分配角色和職位中,數(shù)據(jù)權(quán)限,不能和部門用同一個字段。因為某部門下的人員可能需要他的上級數(shù)據(jù)權(quán)限
按理應(yīng)該要拆分開,即使同一部門,默認權(quán)限可能相似,但部分人員可能會擁有特殊的權(quán)限
是的,數(shù)據(jù)權(quán)限一般是本人、本部門、本部門及下級部門之類的,跟部門/角色使用同一個字段是不合理的。向上的數(shù)據(jù)權(quán)限一般不是通用需求,可以通過團隊或者具體單據(jù)的權(quán)限去特殊處理。
貌似以當前這種維度來構(gòu)建權(quán)限管理不利于后期的使用和維護。我覺得以公司為維度來搭建,其中用戶列表頁增加公司篩選,用公司、崗位、角色三個維度來關(guān)聯(lián)用戶權(quán)限和數(shù)據(jù)權(quán)限,這樣在對某個公司進行統(tǒng)計或者其他的時候都比較清晰,不會混在一起
您說的公司是指組織機構(gòu)的維度嗎?
您好,看了您的文章受益匪淺,但是有兩點還有些疑問,能和您再請教一下嗎?
1、數(shù)據(jù)查看權(quán)限分成本人、本部門、本部門及下級部門,這里您說冗余且體驗感差,想問一下這樣設(shè)置是有什么坑嗎?
2、崗位和角色如何配合使用,能具體講解一下嗎?
如果可以,希望能添加您的微信具體咨詢一下可以嗎?
來,一起討論下權(quán)限管理。加個微信13628331823
1、數(shù)據(jù)查看權(quán)限說的“冗余”是指項目上我們產(chǎn)品把數(shù)據(jù)權(quán)限跟崗位綁定死了。分成本人、本部門、本部門及下級部門是沒有問題的。
2、不同的權(quán)限模型適用場景可以看這篇,人人社區(qū)不讓發(fā)
https://mp.weixin.qq.com/s?__biz=MzIzNjY3NzEyMw==&mid=2247483682&idx=1&sn=8e45340d19fff4bf338beee5ee27f325&chksm=e8d5704edfa2f9580a2e31513d701346b63c517724cf5e2aab1f115b7c8a75c90988fe045ee7&token=221420451&lang=zh_CN#rd
很贊
貌似也可以直接用戶對應(yīng)角色,不用中間加一層“崗位”對應(yīng)關(guān)系
三層權(quán)限模型適用場景也很多,但是在這個案例里面不太適合呢。因為這個案例的組織機構(gòu)復(fù)雜,數(shù)據(jù)權(quán)限要求很細,如果用戶直接對應(yīng)角色,數(shù)據(jù)權(quán)限管理在靈活性和可擴展性上都會比較受限
需要的,有些系統(tǒng)中叫復(fù)合角色
這個是什么意思?是類似于多個role集合成一個新的role???
復(fù)合角色的定義是怎樣的?它具體是為了解決什么問題(是解決某個角色擁有多個層級的權(quán)限問題嗎?)
感謝,受教了!
角色與崗位有什么區(qū)別???請教一下
角色是功能權(quán)限的合集,崗位可以理解成角色和組織機構(gòu)(數(shù)據(jù)權(quán)限)的合集。
關(guān)于權(quán)限管理我總結(jié)過一篇文章,但是人人社區(qū)不讓發(fā),希望對你有幫助~
https://mp.weixin.qq.com/s?__biz=MzIzNjY3NzEyMw==&mid=2247483682&idx=1&sn=8e45340d19fff4bf338beee5ee27f325&chksm=e8d5704edfa2f9580a2e31513d701346b63c517724cf5e2aab1f115b7c8a75c90988fe045ee7&token=221420451&lang=zh_CN#rd
之前糾結(jié)了好久,功能權(quán)限好控制,數(shù)據(jù)權(quán)限真的是一個用戶一個需求,看來復(fù)雜需求時,崗位來控制數(shù)據(jù)權(quán)限還是需要的,多謝!
先馬了 后面再看