成熟CRM系統的權限體系解析
權限體系的價值在于支撐不同用戶處理職責范圍內的業務,保護業務處理的順暢進行而不被干擾,降低發生誤操作風險,更保障業務數據的安全。權限體系是后臺/B端產品的產品經理繞不過去的領域。本文通過對微軟CRM等成熟CRM后臺的權限體系的解析,為B端產品經理提供參考。
權限體系的核心要素
權限體系的要素有:組織、角色、用戶和權限、頁面、視圖。
- 組織、角色、用戶是基于業務變化可即時調整的。
- 權限是最底層屬性,由開發人員基于業務需求開發實現。權限約束的對象是后臺的具體實例。根據數據接口安全需要,可設計專用的接口權限。
- 頁面、視圖是系統按照業務配置、給對應用戶呈現的內容。
1. 組織
組織有多個類型,常見有三種:
- 基于行政組織來設置的,但又可能會不同于行政組織。比如總部在行政上會有銷售副總、銷售部長、營銷部長,而在營銷系統的權限配置中,不會創建公司高管、下面設銷售部、營銷部,而是將銷售總監、銷售部長、營銷部長放在在一個部門里,給不同角色。
- 基于某個業務線來設置,比如按產品線維度,A1產品線的只能看到AI產品線相關的線索、訂單等業務數據。
- 臨時項目組織。因業務需要,臨時創建的組織,從多個組織中拉入人員,共同處理某特定業務。
2. 角色
角色是權限分配的單位與載體。復雜業務中,角色可基于不同業務組織創建,以限定業務范圍。
3. 用戶
用戶歸屬于某個組織、且擁有某個或多個角色的權限。因組織所在的位置或等級、以及角色,決定了用戶擁有的權限。存在即使角色相同,但因組織等級不同,可見的數據范圍也不同的情況。
4. 權限
權限分功能權限、組織權限、數據權限。
(1)功能權限:
常見的功能權限有新增(建)、編輯、查詢、刪除、停用、分配、分享、提交、審批等。功能權限+組織權限,決定了可以看到多大范圍的業務數據,因查詢是最基礎的功能權限。比如可以查詢到本部門所有訂單數據,但只能修改單據的所有人(Owner)是本人的訂單。
權限體系較為精細的平臺,對分享還做了限制,比如張三分享某數據給李四時,可設置李四是否可以再分享出去。這樣的業務場景多用于B端業務,比如商機跟進??蛻羰怯蠥E負責,售前顧問提供解決方案,就會出現1個AE對多個售前顧問,客戶數據需要定向的共享給售前顧問。
(2)組織權限:
分個人、部門、本下級、組織4個等級。比如個人是指一線的銷售顧問,部門指銷售顧問所在的部門(也可以是小組);本下級指本級以及下級部門的權限、如銷售大區;組織級指當前組織下所有業務部門的權限。
下圖為功能與組織權限授權頁面:
(3)數據權限:
此處特指字段級權限。指某角色或某用戶能否查看或編輯某個實例中的某個字段。字段級權限應用場景較少,比如費用審批中最終審批人確定的核準金額字段。字段級權限一般與頁面、視圖融合在一起配置使用,畢竟不讓人家看到字段的值,就干脆不要讓人家看到這個字段了。
5. 頁面
頁面有新建、編輯、查詢頁面。大部分場景下,新建、編輯、查詢頁面所顯示的字段信息是一致的,即使用同一個頁面布局。為了提高用戶體驗或輸入效率,新建、編輯會與查詢頁面不同,增加很多交互控制,或功能按鈕。
同一個實例,可以配置多個頁面,并分配給多個角色,不同角色看到的頁面內容不同。注意與字段級權限的配合。比如管理人員看到的商機頁面與銷售員是不同的,通過配置的方式給管理人員配置頁面。
6. 視圖
視圖可以通俗的理解為列表。可以配置多個視圖,并分配給指定用戶或團隊,不同角色看到的列表中的字段不同。
靈活的系統可以支持用戶自行定義視圖中放哪些字段、字段的前后順序和業務數據的排序規則,也可以將多個字段的輸入值作為篩選條件、而自定義一個視圖。當然,能否自定義視圖也是需要權限控制的。每個業務數據會有默認的視圖。同樣,需要注意與字段級權限的配合,即使增加了不可見字段,列表顯示字段值為“-”或“****”。
權限體系的使用
有些平臺通過分配菜單權限給不同角色的方式來呈現數據視圖,還要給業務數據的查詢權限,賦權較復雜,非常的不靈活。而且,權限大的用戶會看到同一個業務數據有多個菜單,比如運維和系統管理員。合理的做法是:
- 菜單入口:用戶擁有某業務數據的查詢權限,登錄后就可以該業務數據的菜單入口。菜單入口分組呈現,比如客戶管理在營銷、銷售、服務里都可以看到。
- 視圖:點擊菜單后,系統根據當前用戶和對應角色匹配視圖。
- 可見的數據范圍:視圖中呈現的數據是按照用戶所在的組織即組織權限來提供業務數據的。視圖中呈現的功能按鈕是根據當前用戶的功能權限、業務交互控制規則來顯示的。如,即使有審批權限,但當前數據的審批狀態為已審批,審批按鈕隱藏或置灰。
- 可操作的功能:打開某條業務數據時,系統根據當前用戶對應角色匹配頁面。頁面中呈現的功能按鈕是根據當前用戶的功能權限、業務交互控制規則來顯示的。
總結
CRM系統較為靈活,需要強壯的權限體系來支撐,對系統的持續迭代非常重要。我們在架構設計時,需要統一和標準化權限體系,開發和產品在理解上達成一致。新增業務功能時,產品經理專注于業務設計,而不需要多考慮權限體系對業務的約束和限制。
本文由 @王建儒 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
學習收藏了,今天就當一回課代表吧。搭建私域流量運營,當然必須要有工具。給大家推薦一款由【人人都是產品經理】【起點課堂】旗下獨立研發的私域流量運營工具——糧倉·企微管家。糧倉·企微管家是一款基于企業微信的一款營銷型SCRM系統。集裂變獲客、留存促活、銷售變現、客戶管理于一體的私域增長閉環系統。覆蓋企業客戶運營的生命周期,助力企業私域流量運營,提升售前/售后服務能力。還可以免費開始使用哦~ http://996.pm/M0A06
《B端平臺權限體系設計:RBAC模型的技術實現邏輯》已提交審核,如沒有找到或未審核通過,可在公眾號『王建儒的B星球』中找
最近比較忙,有空我會寫比較細的權限實現方法。B端產品經理、后端開發是必須理解權限體系的,不然后走彎路的。
我看了有很多平臺的設置很多菜單權限,通過菜單來配置組織權限。舉例,簡單的CRM可以玩玩,如果平臺有10+業務中心、上百張業務表,50+角色,就會很容易出錯。
一直沒搞懂角色權限與組織權限間有什么差異?兩者權限配置是否有交叉?
角色包括了功能+組織+數據權限,舉個例子:銷售經理可以看到銷售顧問的客戶數據:功能權限是客戶數據的查看權限,組織權限是本小組/部門所有銷售顧問的客戶數據,數據權限是除了看到銷售顧問看到的之外,還可以看到這個客戶的信用信息,或者可以修改某個信用信息中的字段,比如建議授信額度。
功能+組織+數據可否理解為存在父子關系
不是父子關系,是相互關聯、組合,形成權限約束
“組織權限是本小組/部門所有銷售顧問的客戶數據”是什么意思?是說組織權限是本小組/部門所有銷售顧問的客戶數據查看權限嗎?
是指本小組/部門下所有人的客戶數據的權限,比如說查詢權限。但如果給了修改權限,那經理也可以修改顧問的客戶數據的。其他權限的類似,比如分享等。規則就是功能權限+組織權限,是組合約束的。
權限體系的使用,這部分不知道我的理解是否正確,請指正:
1. 用戶登錄后,有什么功能權限,也就是菜單和按鈕的權限,取決于用戶所在的用戶組。每個用戶組里,可分配不同的菜單組合。
2. 用戶點擊菜單后,能看什么數據,取決于用戶所在的組織結構。系統通過組織權限(個人、部門、本下級、組織)來判斷可以該用戶可以看的什么數據。
問題1:
菜單權限分2兩類:1)非業務數據類的,這個單獨賦權;2)業務數據類的,只要有查詢權限即可見的。
用戶組可以理解為角色嗎?有些平臺比較復雜,還會建立角色組的
問題2:
用戶查詢業務數據時,根據用戶所在的組織+角色上的組織權限與業務記錄上的owner對應的組織來判斷的。
學習了
為什么不能在PC上不能回復一些英文,比如微軟的CRM產品名稱?
看樣子是從事Dynamic CRM(office 365)的大佬,總結的棒棒噠,望可以向您請教。
看來你也是從事微軟CRM產品的大佬哦,我們多交流。我目前喜歡幫客戶自建私域平臺。
當然,微軟CRM我非常認可,商業產品中非常不錯的產品。只是別用標準方案,根據客戶業務自己玩。平臺很好
是的,標準方案基本上不適合本土企業,大部分都是在這個框架中進行行業定制化,然后多項目中復用
專題內容 #汽車行業營銷領域數字化平臺# 敬請關注!
已發布(3篇):1-汽車行業營銷領域數字化平臺概述、2-車企的渠道價值評估、3-數字化轉型的驅動力與方向
審核中(2篇):4-車企為什么要做數字化營銷平臺?5-車企線索管理的定位與流程
已完稿(1篇):6-中臺化的線索管理
文章都很有深度,有理論有實踐,真大佬,期待交流
感謝關注、留言。我最近在思考如何與大家更直接的溝通,想想還是蠻期待的
是不是可以開個微信公眾號,畢竟大家平時微信用的最多
看我個人信息
加我,建群
敗給平臺的違禁詞了
您好,已經加您了