編輯導語：與To C産品不同，SaaS産品的面向用戶大多為企業用戶，在産品的使用過程中，便會涉及到“權限管理”的相關問題。那麼，你知道SaaS産品的權限管理設計有哪些特點嗎？在SaaS産品權限設計中，又有哪些常見問題？

一、前言

SaaS産品大部分會面向企業用戶，而企業是由若幹個崗位相互協作的一個經營組織，每類崗位都有各自的職能，在企業經營管理的要求下，這些不同的崗位各司其職不可越權，否則可能給公司的正常經營帶來風險，比如在功能權限上，客服不能有财務資金管理的權限；在數據權限上，分公司員工不能有總部的數據權限等。

所以SaaS産品需要對不同崗位的功能和數據範圍進行約束，于是就有了「權限管理」。

1. 什麼是權限管理？

權限管理是指讓用戶隻能訪問自己在系統中被授權的資源的一種功能。

其解決了企業需要對不同崗位員工權限的區别管理的問題，能夠防範管理上違規操作的風險，體現在軟件中即是不同用戶擁有的功能或數據權限不同。

2. 什麼樣的企業需要權限管理？

當有敏感職責的崗位和其他崗位都需要使用同一系統時，這個企業在該産品中就需要用到權限管理功能。這類企業的特征是存在多個崗位，且某些崗位的職責其他崗位不能擁有。

敏感職責指的是某項工作隻讓特定的崗位來完成，如果其他員工操作會給經營管理帶來風險，體現在系統中就是某些功能隻允許部分員工操作。

比如連鎖零售店的收銀員和财務，分别會分配收銀和資金管理權限，收銀和資金管理都是敏感職責，其他大部分崗位都不允許擁有這兩項權限，不然資金上有出現問題的風險。

此時，使用權限管理就可以限制商品管理員、庫存管理員、美工等崗位不能擁有資金管理和收款權限，無法進行收款、資金提現操作，資金就是由特定崗位按照公司的流程制度來管理，不會出現職責範圍外的員工挪用資金的情況。

那麼，哪些企業會存在敏感職責的崗位呢？比如做零售、餐飲、酒店這些業務涉及到金錢的企業，政府這種數據要求保密的組織等等，如果SaaS産品面向具有這類特點的企業，就需要做權限管理。

二、SaaS産品權限管理設計有何特點？

“多租戶”是SaaS産品的一個基本特征，所以與企業内部管理軟件不同的是，SaaS産品需要讓n個企業都能在同一個産品中使用，需要找到不同企業權限管理的共性和區别，這就使得SaaS産品的權限管理具有了以下特點：

1. 産品中各租戶的權限管理相互獨立

因為SaaS産品所有企業用戶都是在同一個平台上使用，每個企業都是獨立的主體，不能互相影響，所以，與企業内部管理系統隻用考慮管理本公司員工權限管理不同，SaaS産品需要讓每個企業都能夠獨立管理各自的員工權限。

每個企業用戶登錄後，僅可查看和管理自己企業的用戶權限，這是産品能正常使用最基本的條件。如果不同企業之間能夠互相查看或管理其他企業的用戶，可想而知用戶對産品的安全性、可靠性會産生多大的質疑。

各租戶權限管理功能的關系圖

2. 權限管理需要兼容不同類型的組織架構

每個企業的組織架構不一定相同，比如集團企業和小微企業的組織架構不同，權限管理複雜度也會不同，所以這就給SaaS産品的權限管理帶來了另一個不同之處——需考慮是否要兼容不同的組織架構。

産品設計時，是否需要兼容不同類型的組織架構，由産品面向的客戶群體的組織架構特點來決定。

從組織層級的角度可以簡單分為2類組織架構：

1）單層級架構

指公司隻有總部這一個經營機構，總部下面無分機構的企業架構。

其特點是組織結構簡單，設計權限管理功能時不用考慮多機構的情況，例如非連鎖的零售、美容、餐飲店，其組織結構簡單，沒有分機構。

2）多層級架構

指公司除總部以外還分了其他經營機構的企業架構。

其特點是組織結構較複雜，機構之間存在上下級關系，有的還存在平級關系，使得權限管理需要考慮跨機構的場景。

例如連鎖零售、餐飲企業，制造業、地産、物流、醫院、教育行業的集團型企業，會有很多分支經營機構，目标客戶是這類大中型企業的SaaS産品，權限管理就會變得複雜。

3. 存在可标準化的通用角色

盡管不同企業都有自己獨立的權限管理功能，但有些角色在各公司都存在，且這些角色的權限在每個企業中可以相同，所以SaaS平台可以将這些角色默認設置為所有企業都有，即為标準化的通用角色。

通用角色的作用是方便新客戶快速配置員工權限。舉個例子，某線下零售店主，新入駐一家零售SaaS平台，需要配置倉庫管理員、商品管理員、收銀員、導購員的員工權限：

第一種方案，進入到用戶權限分配頁面後，沒有通用角色，店主需要先創建角色，然後進入權限列表後，發現權限項共100個以上，店主需要逐個權限項識别，判斷能否賦給該角色，每個角色都需要如此配置，如果有不懂，還需要咨詢平台客服/售後，進行講解。

第二種方案，進入到用戶權限分配頁面後，有通用角色，已默認配置好了各角色的通用權限，店主直接選擇倉庫管理員、商品管理員、收銀員、導購員賦給員工。

兩種方案對比，顯然第二種方案能幫助新客快速使用産品，減少培訓成本。這一點對于SaaS産品來說比較重要，因為SaaS産品需要依賴足夠大的客戶規模實現盈利，如果每入駐一個客戶，都需要對客戶進行系統培訓，那麼當客戶規模越來越大時，培訓成本不免非常高昂。

所以，就需要提煉出通用角色，默認定義好這些角色的權限。

比如上述的這款零售SaaS産品，目标客戶是服裝店，那麼導購員、收銀員就可作為通用角色，導購員默認擁有商品管理、會員管理、訂單查詢的權限，收銀員默認擁有訂單管理、收銀管理的權限。

新客分配員工權限時，可以直接選擇角色分配給員工，快速高效。

三、SaaS産品權限設計常見的問題

我們入職一家SaaS公司後，通常是在已有的産品上做叠代，已有了一套權限管理功能，所以較少考慮權限管理，但假如有一天我們要打造一款新的SaaS産品時，就必須得從0到1設計權限管理功能。

而權限管理設計不合理，可能會出現A崗位的員工擁有B崗位的權限，而B崗位含敏感職責，導緻公司在使用系統時存在管理風險，權限問題一旦暴露出來，會影響客戶對系統的信任度，進而對老客戶的續費和新客戶的訂購意願産生負面影響。

以下是SaaS産品權限設計中常見的問題。

1. 沒有做數據權限控制

這種情況是指同企業下的用戶之間完全沒有做數據權限控制，即同企業下面的任何賬号在同一頁面中，可查看的數據範圍相同。

有些情況下，企業内不同員工允許看到的數據範圍會不相同。比如某汽車經銷公司有多個銷售部，每個銷售部不允許看其他銷售部的客戶數據，每個銷售員不允許看其他銷售員的客戶數據，否則可能會出現搶客戶的情況，每個銷售部主管又需要看到自己部門的所有客戶數據。

這時，如果系統沒有數據權限控制，那麼就會出現每個員工都可以看到所有客戶數據，沒辦法滿足上述情況下的需求。

有的産品會做成【我的客戶】和【公司客戶】2個頁面查看客戶數據，解決無法自定義配置數據權限的問題。

【我的客戶】頁面中隻有本員工的客戶數據，【公司客戶】頁面中包含公司所有客戶。普通員工沒有【公司客戶】權限，而管理者有這個權限，所以就解決了普通員工隻允許查看自己的客戶數據，管理者可以查看所有客戶數據的問題。

但顯然這樣也沒有完全解決問題。

前面提到過“某汽車經銷公司有多個銷售部”，如果按上面這種方案，那麼每個銷售部的主管都可以看到其他銷售部的數據，同樣存在互相搶客戶的風險。

解決方案：

在用戶的權限管理操作，增加選擇客戶管理模塊數據範圍的配置，選項包含本人、本部門、本公司。

配置本人時，用戶隻能看到本人的客戶數據，配置本部門時，該用戶可以看到本部門的客戶數據，本公司同理。

當然，也不是所有SaaS産品都需要數據權限控制，這并不是标配邏輯，需不需要做數據權限控制與産品的業務性質和客戶的組織結構有關。

比如産品的業務中不存在員工之間的敏感數據，那麼就完全不需要數據權限控制。

再如客戶群體隻有小微企業，沒有多個部門，即便存在敏感的客戶數據，用【我的客戶】和【公司客戶】兩個頁面權限也可以實現數據控制。

2. 支持配置數據權限，但不支持跨機構配置數據權限

這種情況是指系統支持配置本人/本部門/本公司數據權限，但無法自定義控制隻允許擁有哪幾個機構的數據權限。

在隻有一個機構的企業中，不支持跨機構配置數據權限不會有問題，但在多機構的企業中，可能會無法滿足客戶權限管理的需求。

比如某集團公司在各一線城市都設有分公司，屬于多機構企業，員工A隻在深圳分公司任職，那麼數據權限就不能設置成“本公司”，否則就能查到總部的數據。

也許有人會說，開發時把“本公司”的數據權限定義為本所屬機構的數據權限，如果員工在分公司任職，就有該分公司的數據權限，如果在總部任職，就有總部的數據權限，不就解決這個問題了嗎？

但是，假如員工B在總部任職，組織架構上隻屬于本部，卻分管了廣州和深圳分公司的财務數據，那麼分配數據權限時，廣州和深圳這2個分機構的數據權限員工B需要擁有，但總部下面其他的分公司的數據不能擁有。

如果系統不支持跨機構自定義數據權限，就無法滿足這種應用場景。

解決方案：

可以在權限管理中上，加上跨機構分配數據權限的邏輯，在用戶權限分配的界面，支持選擇擁有哪些分公司的數據，解決同一用戶在多個機構均有數據權限的問題。

關系圖

假如上圖中的用戶1分管深圳和北京分公司的财務，那麼在用戶權限分配的界面，可以把深圳和北京分公司的數據權限都勾選給該員工，即滿足了該員工僅允許擁有這2個分公司數據權限的需求。

3. 不設置通用角色，新客使用權限管理的學習成本高

通用角色是指企業開通賬号時，在角色列表中默認給出已經配置好權限的角色，其适合在産品的目标企業群體普遍存在相同職責的用戶時，平台給出标準化的角色配置。

例如某零售SaaS産品的目标客戶是服裝店，那麼導購員、收銀員就是目标客戶中通用的角色，導購員可以默認擁有商品管理、會員管理、訂單查詢的權限，收銀員默認擁有訂單管理的權限。

前文中已經闡述了關于通用角色的作用，很多SaaS産品沒有設置通用角色，在産品初期用戶量小、權限項少時不會暴露出問題，當産品用戶規模越來越大、功能越來越多時，不免會有新客戶因為不懂如何配置繁多的權限而中斷了産品的使用，增加新客流失率。

畢竟，并不是所有的客戶都有耐心研究系統，市面上還有更多使用起來便捷的産品可以選擇。

解決方案：

設置産品的公共角色，定義好這些角色默認擁有的權限，所有企業注冊後即可使用這些角色，配置員工權限時，可以直接勾選該員工有什麼權限。

“有贊”産品定義的通用角色

四、結語

權限管理是SaaS産品搭建系統之初就需要定義好的基礎功能，如果因設計不當而使後期再來改造，則會影響所有企業用戶的賬号使用，影響平台的穩定性和可靠性；而如果過度設計，對于創業初期的SaaS團隊來說研發成本又不免高昂。

因此，我們需要根據SaaS産品面向客戶群體的特征，選出合适的設計方案，才能讓權限管理滿足客戶的使用場景。

作者：子文，公衆号：SaaS産品聞

本文由 @子文 原創發布于人人都是産品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部