面向中小企業SaaS的權限管理系統
本文基于面向某個垂直行業的SaaS系統的設計經驗,抽象出一套適合中小企業的權限管理體系,目標是最大限度保留系統彈性的同時,把系統復雜度和開發成本盡可能降低。enjoy~
面向企業級的SaaS(軟件及服務)系統,由于企業用戶的規模和內部管理模式千差萬別,設計一套具備足夠彈性、符合絕大部分目標企業用戶需求的權限管理系統,是一個很大的挑戰。
我們可以看到,市面上面向多個行業的綜合性SaaS系統,例如銷售易、紛享銷客等,由于它們的目標客戶跨越了多個行業、多種規模,這些企業具備各種各樣的內部管理風格和模式,在權限系統的管理上,往往做得非常復雜,不僅具備部門、角色、職位、數據等各個維度的權限管理,各個功能模塊還有自己獨立的權限管理,雖然具備最大的彈性,卻給企業的系統管理帶來較大的負擔。
本文基于面向某個垂直行業的SaaS系統的設計經驗,抽象出一套適合中小企業的權限管理體系,目標是最大限度保留系統彈性的同時,把系統復雜度和開發成本盡可能降低。
提煉的三個核心原則:
- 企業-管理員-普通賬號三級權限
- 功能和數據權限分離
- 部門和角色分離
圍繞上述三個基本原則,我們力圖在滿足中小企業需求的前提下保持足夠的彈性,并嚴格控制復雜度和開發成本。詳細描述如下。
1. 權限從上到下分為三個層級:企業賬號(老板賬號)、管理員賬號、普通賬號
對于中小企業來說,公司的實際控制人,往往是公司的創始人或自然人大股東,因此企業賬號的使用者以及對應綁定的手機號碼,都是公司的實際控制人,他應該掌握最核心、權限最大的企業賬號,所以也可以稱為“老板賬號”。
但是在實際場景中,公司的實際控制人并不會直接管理公司的業務支撐系統,因此,需要在系統首次部署時,創建好企業賬號,并由企業賬號授權給某一個或多個系統管理員,由系統管理員去完成日常的角色創建、員工導入等工作。系統管理員,對應的一般就是HR或行政部門的管理人員。當然,企業賬號的權限高于管理員賬號,如果是小微型企業,也可以由企業賬號直接替代管理員賬號的功能。
除了企業賬號和管理員賬號之外,其他各級員工所持有的賬號,都屬于普通賬號。普通賬號的部門、角色、數據等權限的設置,一律由系統管理員配置。
三個權限層級示意圖如下:
在實際系統中的核心業務步驟如下:
(1)企業購買系統時,創建一個企業賬號,這個企業賬號綁定的手機號碼為公司實際控制人的手機號碼。該手機號碼必要時可以解綁(例如公司實際控制人變更),由于該功能觸發頻率很低,因此不需要在前端功能中實現,只需要在購買協議中寫明,“購買企業可以通過書面方式提出企業賬號手機號碼綁定變更需求”即可。
(2)在部署和培訓階段,可指導企業賬號持有人創建一個或多個管理員賬號,該賬號一般授權給行政總監或人力資源總監,后續配置即由管理員賬號進行。
(3)管理員賬號持有人需要接受系統培訓,掌握部門創建、角色創建、功能和數據權限分配等基本操作。管理員所有操作都必須記錄在案,供企業賬號持有人監督,且管理員操作觸發異常行為規則(如大量分配高等級權限等)時,系統會通過短信方式通知到企業賬號持有人,確保企業賬號對管理員的全方位掌控。
(4)企業賬號可隨時將管理員賬號禁用或設定為離職,但管理員賬號不可對企業賬號進行任何配置或操作。
(5)企業賬號默認擁有所有權限。
2. 功能權限和數據權限分離
功能權限,定義為可見、可以操作的功能范圍。例如某一部分菜單,或者某個頁面里的各種操作。
數據權限,定義為若干個數據類型里的具體可見范圍,例如“客戶”就是一個數據類型,它的權限舉例如“無權限”、“我的客戶”、“我所在部門的客戶”、“我所在部門及下級部門的客戶”。
通過功能權限和數據權限的分離,我們可以做到以下場景:需要開拓和維護客戶的角色集合,都可以擁有“客戶”這個菜單的權限,但不同的角色進入“客戶”菜單的列表時,看到的客戶范圍各不相同,極端情況是看不到任何客戶。且不同角色在同一個客戶頁面上,能進行的操作也不同,例如有的角色可以新建客戶,有的卻不行,這就要由功能權限來控制。
可見,通過功能權限和數據權限的分離和配合,我們在具體的權限分配上有了非常大的彈性,且在技術層面的后臺系統的設計上,也非常合理、清晰。
而在具體設計上,需要保證以下4點:
- 正確區分功能和數據,入口性和操作性的都應該歸類為功能
- 正確對數據進行分類,避免存在分類后的某些數據存在交集
- 數據分類到多細的顆粒度,需要由行業特性決定
- 數據權限區分為查看、編輯和刪除
示例圖如下,由于涉及具體產品,對某些文字進行了打碼:
3、部門和角色分離
部門的定義,自然就是公司行政組織架構下的部門。
在本設計方案中,角色等同于職位,而在許多大型的SaaS系統中,為了更大的靈活性,往往會把角色和職位分開,但根據我們的判斷,對于中小企業,設定角色一個就夠了,職位當然還存在,但僅僅是一個不涉及權限管理的文本title了。
以一個銷售公司來說,角色可以包括:“渠道專員”、“渠道總監”、“銷售專員”、“銷售經理”、“總經理”等等。
所謂的部門和角色分開,就是不同的部門可以有相同的角色,例如如果有渠道一部、渠道二部,則這兩個渠道部的員工的角色都可以設定為“渠道專員”,這兩個部門的管理者都可以設定為“渠道經理”。再配合功能和數據權限,則進一步配置“渠道專員”具有“渠道”菜單的功能權限,其能夠查看的渠道數據權限范圍則僅為“我的”,而“渠道經理”同樣具有“渠道”菜單的功能權限,但其能夠查看的渠道數據權限的范圍則擴大為“部門”。
具體設計上:
- 最大部門即為公司
- 管理員賬號和普通賬號均可禁用或設置為離職
- 不同部門可以配置相同角色
- 相同角色的功能權限和數據權限是一樣的
4. 權限系統和其他功能設計的關系
總結完權限系統三個核心的基本原則后,我們還需要指出一點:權限系統的設計方案,在整個系統中絕不是孤立的,它能否實現設計目標,并和整個系統完美配合,還需要做到以下幾點:
首先,菜單和功能的設計,必須是最小顆粒度,否則就和數據權限產生沖突。例如:我們只需要一個“客戶”菜單即可,不同角色在“客戶”菜單里能干什么事情,由功能權限和數據權限配合進行控制,但切不可出現“我的客戶”+“全部客戶”兩個菜單,這明顯和數據權限有根本沖突,且也是一種不優美、不合理、擴展性差的設計。
其次,數據的分類,必須符合業務需求,且劃分合理。有些數據都是公開的可以不歸入數據權限進行管理,所有角色默認都有即可;有些數據需要進一步細分,例如同樣以“客戶”舉例,在某些公司的業務規則中,就需要將客戶的基本信息和聯系信息分開控制,管理層可以看客戶基本信息,但只有客戶負責人才可以看聯系信息,這種情況就需要將客戶的數據權限分為“客戶基本信息”和“客戶聯系信息”兩個。
最后,權限變更的記錄和所有賬號的行為軌跡記錄一樣重要。權限系統本質是進行權力的限制,沒有監管的權力必定是會失控的。在出現問題的時候,必須同時配合權限變更的記錄、角色變更的記錄和賬號的行為軌跡記錄進行追責和存證,確保維護企業的合法權益。
總結
在合理設計的前提下,權限系統也并非越復雜越好。只有符合目標客戶需求并具備最大彈性的權限系統,才是最好的。
本文由 @Alex 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來源于網絡
有個問題,在此方案里如何設定部門主管,便于后續業務中的審批等操作。
寫的挺好,就是數據權限中,不應該把編輯 刪除 劃入吧
公司內部B端產品,角色按照流程劃分的。(例如:瀏覽者、發布者、審核人、系統管理員),那么,權限的級別劃分可以也按照角色嗎??
我還有一個問題就是,好像我只要確認員工的上下級關系就可以確定數據的范圍權限了 – –
可以的
為什么在數據權限那里區分查看,編輯,刪除呢? 查看 編輯和刪除不是功能操作權限嗎?
同問
小小白理解:查看等操作是功能權限。但是數據的權限的設置無非就是查看、編輯、刪除等。
增刪改查是最基本的功能,必然是屬于功能權限。只能說作者有點沒走心
應該是把數據權限做了讀寫分離 這樣容易引起歧義。
功能權限是指我能否操作這個按鈕;數據權限是我操作這個功能時能影響的數據范圍,比如:查看/編輯員工信息,我作為組長,只能查看/編輯我自己組的員工,而不是全公司的員工。
fusion,干貨
但感覺saas面向中小企業,權限配置還是過于繁瑣,一直在思考著一個輕量級的,畢竟中小企業架構不復雜。
不錯,深受啟發,希望以后多分享一下干貨! ??
最近正在做這塊,很有幫助。感謝分享
做過一些特定行業內的管理系統,涉及權限。因為行業數據數據差異,權限差異挺大的,特別復雜,而試圖做的簡單通用則不滿足業務管理需求,存在風險。
如果說權限體系抽象,感覺還是有點困難,不知有沒有什么好的建議,謝謝。
事實上,就算是大而全、覆蓋全行業的那些SaaS,具體到特定行業也普遍存在不滿足全部需求的情況。所以這些SaaS公司才會同時也搞Pass,讓大家一起針對特定行業去定制開發。
這樣會存在一定的局限性,例如一個部門的人員只需要處理兩個門店的銷售數據,就會存在局限,可以適當考慮將數據權限做成可配置項。
確實是。進一步擴展是往數據分類和具體權限靈活配置的方向去了,但復雜度也大大提高了,這個方案只能說是精簡版
訂閱了,期待下一篇作品
呢【【,=】】
非常好,最近正在做一款產品的權限設計,多謝了!另外想請教下,想以后往中后臺產品設計發展,請問有哪些學習途徑和方法?謝謝
中后臺側重對業務流程進行合理抽象、簡化或優化,強調邏輯性,各類狀態也更復雜。具體的學習途徑可以從幾個方面著手:首先學習工作流設計、權限設計等通用的內容,這些已經有現成的成熟套路;其次可以選擇一些知名產品,注冊試用賬號進行全流程分解學習;最后在試用或工作實踐中,建議重視流程圖的規范性,在規范的流程圖中不斷提高抽象思維、提煉和簡化能力。
謝謝您的回復,現在有做一些中后臺的產品設計,但是感覺都在皮毛上,沒有深入的全局了解、掌控和規劃,總感覺還游離在體系在外,謝謝您的建議,希望以后能和您多交流
希望互相學習 ??