平臺型業(yè)務系統(tǒng)權(quán)限建設及常見問題解決方案
權(quán)限是系統(tǒng)的地基,產(chǎn)品設計之初需先考慮框架設計,SAAS系統(tǒng)或其他平臺型業(yè)務系統(tǒng)更需系統(tǒng)梳理權(quán)限,體系化設計。本文結(jié)合實際信貸業(yè)務系統(tǒng),重點從權(quán)限體系搭建流程及過程中常見問題解決方案兩個方面進行闡述。
一、權(quán)限基本要素
權(quán)限規(guī)定了一個用戶或一類用戶在系統(tǒng)中能操作的數(shù)據(jù)邊界,通過菜單(功能)授權(quán)和數(shù)據(jù)隔離對每個用戶的操作范圍進行限制。映射到實際業(yè)務中,就是每個人工作范圍和權(quán)利(責任)大小的體現(xiàn)。
如條線業(yè)務的某部門業(yè)務員只能操作他范圍內(nèi)的功能,查看他自己有關的數(shù)據(jù),往上權(quán)限依次擴大,管理部門銷售的部門經(jīng)理,城市經(jīng)理,區(qū)域總監(jiān)等。
操作權(quán)限:菜單及功能操作權(quán)限,基于列表查詢和頁面操作,按權(quán)限code單獨配置。菜單為功能集合,控制模塊和頁面展示。一般在授權(quán)時,按樹形組織或矩陣組織,模塊-菜單-功能。在業(yè)務系統(tǒng)中,操作權(quán)限就是每個用戶可以操作的業(yè)務范圍和職權(quán)大小,是日常職權(quán)的線上映射。
數(shù)據(jù)權(quán)限:數(shù)據(jù)歸集有多種形式,如按組織結(jié)構(gòu)(公司、部門)、按業(yè)務區(qū)域。一般按組織結(jié)構(gòu)進行數(shù)據(jù)隔離,有該部門的權(quán)限,才能看到該部門。數(shù)據(jù)權(quán)限基于業(yè)務需要而進行歸集,如業(yè)務系統(tǒng)中,存在業(yè)務逐層上報的形式,故需要按組織結(jié)構(gòu)逐層歸集;數(shù)據(jù)型的系統(tǒng)中,需控制數(shù)據(jù)范圍(如城市);資源型系統(tǒng)中,需控制資源分配(按商戶分配資源和數(shù)據(jù))。不同類型的組織對應不同的數(shù)據(jù)權(quán)限類型,可將數(shù)據(jù)進行歸集和分類,再對應組織類型進行設計。
在數(shù)據(jù)權(quán)限中均存在基礎數(shù)據(jù)單元(最小單位),如組織結(jié)構(gòu)的最小單位是員工(角色),每個員工都能看到自己歸屬(業(yè)務歸屬、生成、操作)的數(shù)據(jù)。若員工沒有額外授予權(quán)限,則他無法看到其他同事或者所在部門產(chǎn)生的數(shù)據(jù)。如果授權(quán)了,即使是一個底層員工,也能看到更大范圍的數(shù)據(jù)。
商戶體系下的授權(quán):在平臺型系統(tǒng)中,一般會統(tǒng)一維護商戶,給商戶進行初始化權(quán)限分配,再由商戶內(nèi)部進行二級授權(quán)。平臺統(tǒng)一控制各商戶的權(quán)限,商戶僅能在權(quán)限范圍內(nèi)進行操作。具體在后文敘述。
權(quán)限管理員授權(quán):一般在系統(tǒng)中,權(quán)限配置都收歸到指定的崗位或人員手上,如行政、人事對業(yè)務員進行統(tǒng)一授權(quán),各業(yè)務側(cè)負責人負責權(quán)限管理,或指定專員管理權(quán)限。建議將組織結(jié)構(gòu)、崗位授權(quán)等抽成公共模塊,便于給不同類型的權(quán)限管理員授權(quán)。
二、權(quán)限系統(tǒng)搭建流程
如何設計權(quán)限體系(以平臺型系統(tǒng)為例):
商戶后臺:商戶初始化,給每個商戶設置初始權(quán)限,再由商戶admin設置其崗位和部門。但是單獨配置的效率太低,這里可以通過腳本一鍵初始化包括初始權(quán)限、部門和崗位。商戶管理一般包括:商戶信息、聯(lián)系人設置、合作方式配置,通道配置,權(quán)限配置等。
組織架構(gòu):搭建樹狀組織架構(gòu),在每個部門下建設崗位,崗位按部門批量授權(quán),須在每個部門下選擇一個負責人崗位,用于工作流中的數(shù)據(jù)流轉(zhuǎn),審批流對應上級、上上級這些。
崗位管理:統(tǒng)一維護平臺崗位和角色組,批量授權(quán)。一般崗位可按平臺和業(yè)務機構(gòu)組織,平臺型崗位可統(tǒng)一授權(quán)。機構(gòu)組織可按分公司或具體部門批量授權(quán)。
員工管理:新增員工,對員工分配角色(崗位),通過兼崗分配多個角色,從而繼承多個權(quán)限。每個員工默認擁有自身產(chǎn)生的數(shù)據(jù),或者單據(jù)歸屬的數(shù)據(jù)權(quán)限。員工管理操作:編輯信息,兼崗、在職狀態(tài)管理等。
賬號管理:將賬號授權(quán)、狀態(tài)、密碼等集中管理。賬號列表與員工列表的差別在于,如果一個員工有多個賬號,在賬號列表一個員工有多條記錄,在員工列表是一條記錄。賬號管理的核心操作包括:功能授權(quán)、數(shù)據(jù)授權(quán)、狀態(tài)管理、重置密碼等。
三、權(quán)限應用常見問題及解決方案
1. 如何解決批量授權(quán)與單賬號授權(quán)沖突問題
場景:在通過角色批量授權(quán)后,具體員工的權(quán)限往往會單獨調(diào)整(同崗不同權(quán)),員工單獨授權(quán)后,隨業(yè)務變動崗位又需要批量增減權(quán)限,這樣能否直接覆蓋員工單獨配置的權(quán)限?
首先這里需要明確一個原則,在大部分業(yè)務場景中,對員工單獨授權(quán)的權(quán)限集優(yōu)先級大于對崗位批量授權(quán)的,即員工單獨授權(quán)不能被覆蓋。這里建議采用增量判斷,即本輪更新是否單獨操作了該權(quán)限。若單獨更新,則再細分兩種情況判斷,情況一,單獨增加。
例如單獨給某員工增加了權(quán)限A,崗位授權(quán)無勾選此項(未單獨選中或去除),保存時,該員工仍然擁有A權(quán)限;若員工單獨本來擁有權(quán)限A,但在批量授權(quán)時勾選掉了,則員工該項權(quán)限會被移除;若單獨給某員工減少了權(quán)限A,但是又在崗位管理勾選上了,這種情況下員工會增加該權(quán)限。再批量授權(quán)的基礎上,再想進行單獨操作,需要管理員單獨處理。
2. 崗位集中授權(quán)后,業(yè)務“特權(quán)”部門要單獨授權(quán)怎么處理
前面提到批量授權(quán)分為角色組、通用崗位兩層,復雜機構(gòu)可在該基礎上增加一級部門崗位授權(quán)。即在崗位管理對全公司(子公司)崗位批量授權(quán)的基礎上,再次在部門授權(quán)這一級對崗位進行單獨售前,增加批量授權(quán)靈活度。
如業(yè)務調(diào)整,需要某部門客戶經(jīng)理辦理某業(yè)務,而其他部門則不允許辦理,可在深圳分公司-業(yè)務一團隊-業(yè)務一部,下面所屬的客戶經(jīng)理單獨增加某些權(quán)限,不會影響到其他部門同崗位權(quán)限。
3. 員工抱怨切換多個崗位效率太低,有消息不能及時觸達,應該怎么解決?
場景:不同崗位會收到不同的待辦任務(推送消息),若每個均需要切換處理,會造成處理不及時,效率低下。這種情況可通過待辦中心解決。其中一種解決方案是,將待辦任務歸集到主崗位待辦列表,在待辦列表可實現(xiàn)快速審批。但這樣有個弊端,系統(tǒng)傳參的審批人崗位會傳當前崗位(主崗位),與其他角色對應的流程崗位對不上。
這里建議審批傳參時忽略崗位信息,以審批人為準,即將當前審批人的姓名帶入,而身份(職級)不帶入,這樣可以避免原流程設計的節(jié)點審批對象崗位或身份(上級)不對應的情況。這種方案效率最高,但是易出錯。
另一種解決方案是做待辦紅點提醒,通過消息框匯總各角色待辦消息數(shù)量,讓員工知道其他角色有待辦任務,及時切換。
4. 功能權(quán)限配置需要每個按鈕都配置嗎,如何避免權(quán)限碼過于繁瑣
通過權(quán)限碼配置權(quán)限,開發(fā)往往傾向于每個頁面,tab,按鈕都單獨加上權(quán)限,這樣做可以精細控制每個功能,但會造成配置過于繁瑣,授權(quán)時工作量加大,對使用者不友好。
結(jié)合使用場景具體分析,有些功能的使用群體是單一的角色,不需要進行過度區(qū)分,如憑證核對頁面,只有一兩個核查員進行操作,此時可與開發(fā)約定,列表頁、詳情頁(或彈窗)單獨一個權(quán)限,將操作權(quán)限獨立成一個權(quán)限。這樣既課保證數(shù)據(jù)操作安全,又可簡化操作。實際業(yè)務中,大多數(shù)頁面或功能不需要細化權(quán)限顆粒度到每個按鈕或tab,需要產(chǎn)品在設計時與開發(fā)另行約定。
四、結(jié)語
權(quán)限是根據(jù)業(yè)務場景而設計的,脫離業(yè)務場景談權(quán)限就是耍流氓,每個系統(tǒng)的權(quán)限系統(tǒng)都長得不一樣,適用業(yè)務的就是最好的。掌握基本原理,結(jié)合業(yè)務實際逐層推衍,一套適用的系統(tǒng)方案可以設計出來。作為系統(tǒng)底層,權(quán)限設計要系統(tǒng),靈活,考慮到未來可能的業(yè)務調(diào)整。
系統(tǒng)設計是需要沉淀的,權(quán)限只是其中一小部分,這需要不斷積累沉淀,正如詩人所說:“凡是你經(jīng)歷的,世人皆無法奪去”。
共勉。
本文由 @摘星 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于 CC0 協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
這也是一種不錯的方案,動作上研發(fā)都默認定義了權(quán)限code,有沒有要求要可視化配置而已。一般我傾向于沒用到的權(quán)限不做單獨定義,同一承接性動作合并定義
“有些功能的使用群體是單一的角色,不需要進行過度區(qū)分,如憑證核對頁面,只有一兩個核查員進行操作,此時可與開發(fā)約定,列表頁、詳情頁(或彈窗)單獨一個權(quán)限,將操作權(quán)限獨立成一個權(quán)限”
星老師這條能再細說下嗎TAT我現(xiàn)在就是把每個角色所有功能按鈕都顯示在權(quán)限配置頁面了…怎么篩選哪些功能權(quán)限是不用配置的啊
4. 功能權(quán)限配置需要每個按鈕都配置嗎,如何避免權(quán)限碼過于繁瑣
關于這個我是這樣做的,定義了一個權(quán)限組的概念,與權(quán)限是一對多的關系,權(quán)限組代表了某個業(yè)務操作所需要的全部權(quán)限,比如新增采購單據(jù)是一個權(quán)限組,里面包含了新增按鈕的操作權(quán)限,單據(jù)提交寫入的數(shù)據(jù)權(quán)限等,這樣業(yè)務在角色配置時只需要配上新增單據(jù)這個權(quán)限,就代表了該角色可以完成對應的操作
主要是讓業(yè)務去理解操作權(quán)限和數(shù)據(jù)權(quán)限實在麻煩 ┓(?′?`?)┏