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