編輯導語：權限管理可以用來控制什麼人可以幹什麼事，需要根據每個用戶的部門、角色來清晰的劃分，以此來保障系統的數據安全。本文作者根據自身公司在引進使用crm客戶關系管理系統時的情況，對CRM系統的用戶權限管理進行了分析，一起來看一下吧。

在公司深耕教育行業8年之際，終于決定引入CRM（Customer Relationship Management）客戶關系管理系統，以下是一些系統使用心得。

一、背景分析

以往公司所有訂單數據均是依賴金數據這種表單收集系統，金數據有一個好處就是靈活，收集的數據最後都集中于一個個的表格裡，想要修改什麼信息非常方便，也很容易就創建出來複雜多變的表單來收集數據。

但是這也會帶來一個很大的問題就是數據容易洩露，不管是暴露在表單裡的數據還是表單收集來的數據（真的就發生過，噓~），再者就是在項目運營期間的數據輪轉包括數據統計都非常的不方便，對學生來說，這就是一次性的消費沒有賬戶概念，也不利于公司内部導流和複購。

還有一個問題就是數據權限問題，以我司舉例，我們的員工分為銷售部、産品部、客服部、技術支持以及其他職能部門。産品部分管公司的不同項目，銷售部按東南西北區域劃分市場，客服部是負責公司400客服熱線的部門。金數據收集來的數據對于所有這些員工是無差别展示的，總監和專員在數據呈現上沒有任何區别。

因此随着公司業務發展以及長期戰略規劃布局，決定抛棄以往方式，引入CRM系統，幫助公司實現更加數據化、标準化的前進發展，解決公司在客戶管理、銷售行為管理上的痛點、難點。

二、主要目标

公司希望所有的報名數據整合在一個系統，對學生生成賬戶，形成訂單記錄，為以後的更多玩法奠定基礎。再加上訂單會有大量B端産生的數據，所有B\C端的數據在項目後期又會統一運營，所以還會涉及到和自有系統的推送問題。

最重要就是保證數據安全，不管是對内的員工還是對外的競争對手。以我司舉例，我們的銷售部要看到自己負責的所有産品的數據，産品部要看到自己負責産品的所有區域的數據，客服部要看到自己支持部門的所有數據，技術支持要看到公司所有的訂單數據。所有這些員工誰該看到什麼、誰能幹什麼，這需要一套完善的權限管理辦法來實現。

權限管理簡單來說就是用來控制什麼人可以幹什麼事，需要根據每個用戶的部門、角色來清晰的劃分，以此來保障系統的數據安全。

本文也主要講解CRM系統的權限管理模塊内容。

三、實施辦法

先了解一下CRM系統的“三位一體”多維度權限管理方法，這種人、部門、角色的多維度權限管理辦法兼備靈活度和易用性，當人員與部門變動後，隻需簡單調整即可完成對應的組織權限關系，并且能根據需要處理用戶相關聯數據。

在CRM系統裡的每一個用戶都有一個部門的劃分，作為權限管理裡一個重要的層級。每一個用戶又可獨自分配角色和職能，而權限管理又以此分為角色管理和職能管理。

其中職能管理用來控制你能做什麼（比如能否查看訂單、能否删除訂單能否轉移訂單），角色管理是決定了你能操作哪些數據（比如隻能操作本人的數據、本人及下屬的、本部門、本部門及下屬部門或者全部數據）。以一張圖示來表明這種關系：

每種職能的功能權限構成“權”,每種角色的數據權限構成“限”。權 限=一個用戶完整的權限。

下面以訂單舉例，逐個分析每個部門用戶的權限管理辦法：

1. 銷售部

銷售部員工是按區域劃分各自的服務範圍，比如一部分員工專門負責華北區域的訂單，這些員工又分别負責各自的項目。

圖1

銷售部的員工需要的功能有基本的增删改查訂單權限，如上圖第三級列表，這些功能需要在職能管理中設置，職能管理配置截圖：

圖2

圖1的二級列表标簽是代表每個銷售員工依據自己職位的高低可視的數據範圍，比如專員A不應該看到專員B的數據，主管應該看到自己及下屬的數據，這種可視數據權限即需要在角色管理設置。角色管理配置截圖：

圖3

以上是銷售部員工基于部門&角色的權限管理辦法。但是銷售部員工的訂單負責人均是自己，也就是說除了自己别人都看不到也無法操作這些訂單，那産品部的權限該如何處理呢？

2. 産品部

産品部員工需要看到自己負責産品的四大區域的訂單，而這些訂單的訂單負責人已經劃分給銷售了，所以産品部無法直接看到訂單數據。再者一個銷售可能同時負責多個不同産品負責人的項目，因為這種相互交叉關聯，所以也無法利用系統的助理或者共享規則來實現。産品部和銷售部兩個部門的數據對應關系如下圖所示：

此時銷售部門的按照「部門」的數據劃分模式不能滿足産品部門了，所以産品部門就需要開啟數據權限多維度管理，新增「産品」管理維度，将業務對象“訂單”及其他需要的對象同時開啟産品維度管理，系統開啟截圖如下：

圖5

将需要開啟産品維度管理的對象開啟之後，給每一個用戶的權限設置選擇自己負責的産品，這也就構成了産品部門用戶的“限”，産品部門的“權”則和市場部門一樣根據自己的職能決定。産品選擇截圖:

3. 客服部

客服部是按照對應區域給各銷售人員配置的，類似于助理角色。因此可利用系統的“助理設置”，即把某銷售人員設置為經理，把其對應客服設置為他的助理即可。

因為系統的助理具有和經理一樣的數據查看權限，這樣如無特殊要求則無需新增一種新的角色，但是需要根據業務需要新建職能，來特殊控制客服部門的操作權限，例如客服隻能查看訂單詳情但是不可以删除訂單。系統配置截圖如下:

4. 技術支持

技術支持這一角色因為其角色的特殊性，所以需要看到公司所有人的訂單數據，所以在上圖3的角色權限設置為全部即可。但是技術支持又不需要像顧問或者客服一樣高的功能權限，這一點也在上圖2的職能權限設置即可。

有些時候技術支持不需看到訂單的某些特殊字段，此時利用CRM系統的一個特殊功能：每一個對象的每一個字段都可以針對每一個職能來單獨設置字段的可見\隻讀\導出權限。系統配置截圖如下：

四、思考總結

以上是以訂單舉例來盤點crm系統個用戶的權限管理辦法，總結一下就是有兩種權限管理緯度，部門和産品。

1）部門的權限管理辦法

用戶可擁有多個角色及多個職能，職能負責控制功能權限，角色負責管理數據範圍。給每一個用戶賦予角色和職能,再把權限賦予這些角色和職能，這樣的權限管理辦法也就是RBAC（Role-based Access Control）基于角色的權限控制模型。這樣的權限管理模式擁有極大程度的靈活、便利以及可拓展性，關于此模型詳解本站也有很多文章分析，感興趣的同學可以去搜索。

2）産品的權限管理辦法

直接給用戶勾選數據，這種就是傳統的權限管理模型，直接給用戶本身賦予權限。而這樣的管理模型無疑是不夠靈活的，一旦人員發生變動則有可能牽一發而動全身。

不管是什麼産品都有可能遇到不同等級的權限問題，了解不同權限管理辦法，在産品設計之初就應努力打造一個靈活、可拓展的權限模塊，避免用到時需要“傷筋動骨”。

本文由 @不做代碼狗了 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,

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

查看全部