資料權限是B端産品經理需要掌握的技能點之一，這篇文章，作者從資料權限的基礎概念開始講起，向我們介紹了資料權限管理模型、特殊業務場景的通用設計，文末還提供一種特殊的權限設計思路，我們一起來看下吧。
上一篇分享了功能權限設計，這一篇詳細分享資料權限架構。文末會提供一種特殊的權限設計思路，一定要看到最後哦！
一、資料權限基礎概念
1、資料權限
資料權限管理：定義登入使用者可以檢視哪些資料記錄。即：定義使用者登入系統之後，可以檢視哪些客戶、哪些訂單、哪些産品等資料記錄。
2、對象級資料權限
對象級資料權限包括：對于功能對象資料的增、删、改、查四類操作：
- 查：使用者允許檢視資料；
- 增：使用者允許建立資料；
- 删：使用者允許檢視并删除資料；
- 改：使用者允許檢視并修改資料。
注：增、删、改這三類權限，通常在功能權限控制中也可以通過按鈕是否可以使用來進行控制，但對象的資料權限定義時，也會對這個對象是否允許增、删、改進行限制。資料權限定義到對象層，是更底層的權限限制，如果對象資料限制不允許建立，即使開放建立按鈕也無法建立。
二、資料權限管理模型
1、基礎權限模型
- 全部資料安全性：允許使用者檢視系統所有資料。一般授予系統管理者、企業高層（如：CEO、CFO等）
- 本部門及下級部門資料安全性：允許使用者檢視目前部門及下級部門的所有資料，預設是按資料建立人歸屬的部門進行檢視，即：檢視資料建立人的部門為登入使用者的部門或者下級部門的資料。一般授予部門負責人
- 本部門資料安全性：允許使用者檢視目前部門的所有資料，預設是按資料建立人歸屬的部門進行檢視，即：檢視資料建立人的部門為登入使用者的部門的資料。一般授予部門負責人
- 本人及下級資料安全性：允許使用者檢視本人及下屬員工的所有資料，預設是按資料建立人進行檢視，即：檢視資料的建立人為目前使用者或者下屬員工的資料。一般授予部門負責人、小組組長等
- 本人資料安全性：允許使用者檢視本人的所有資料，預設是按資料建立人進行檢視，即：檢視資料的建立人為目前使用者的資料。一般授予普通業務人員
權限管理基礎模型可支援較為簡單的一些業務場景，如：客戶管理中，銷售業務員僅檢視自己建立的客戶，銷售總監可以檢視銷售部的所有客戶，CEO可以檢視企業所有客戶。
2、基于資料歸屬人的權限模型
在實際業務中，稍微複雜一些的場景，基礎權限模型就已經遠遠無法滿足業務需求了。
以一個實際場景來說明：企業希望通過撥打400熱線電話做售前咨詢的客戶，配置設定給到銷售人員進行做跟進成交。由客服人員在CRM系統中為客戶建檔，然後配置設定給到銷售業務員跟進。
在這個場景中，客戶的建立人為客服人員，基礎權限模型可以滿足每個客服隻能檢視自己建立的客戶。但是，對于銷售人員而言，這部分客戶都不是自己建立的，也就沒辦法檢視到這部分客戶，無法開展工作。
那麼在這種情況下，我們就需要重新來定義資料歸屬，什麼是“我的資料”。通常情況下，資料的建立人會預設認為是資料的歸屬人。但是，由于業務的需要，資料記錄會在不同的使用者之間進行資料的轉移操作，也就是說：在這種情況下，資料的建立人并不一定是資料的歸屬人。
那麼在上訴的場景中，客戶資料的歸屬人，在資料建立時，歸屬人為客服人員。當客服人員将客戶配置設定給到銷售業務員時，銷售業務員成了資料的歸屬人。在基礎的權限模型中，将原本通過建立人/建立人所屬部門為基礎的權限優化成通過歸屬人及歸屬部門為基礎的權限，就可以解決銷售人員無法檢視到客服建立的客戶資料了。
3、基于角色自定義歸屬的權限模型
在企業複雜的業務場景中，【基于資料歸屬人的權限模型】同樣沒辦法滿足較為複雜的業務需求。将【2】中的實際場景再做延伸進行說明：
客戶配置設定給到銷售業務員進行跟進後，在跟進過程中，如果需要報價給到客戶時，銷售業務員需要加入報價專員負責報價。
在這個場景中，資料歸屬人為銷售業務員，報價專員也需要加入進來，能夠檢視到客戶，為客戶進行報價。但是在這個過程中，銷售業務員仍然需要跟進客戶，資料歸屬人沒辦法直接轉移給到銷售業務員。
那麼在這種場景下，我們又需要重新來定義資料的歸屬，“什麼是我的資料”。
- 對于客服人員而言，建立人為自己的是我的資料；
- 對于銷售業務員而言，銷售業務員為自己的是我的資料；
- 對于報價專員而言，報價專員為自己的是我的資料。
也就是說，對于不同角色的使用者而言，“我的資料”的定義是不同的。那麼就需要能夠給不同角色去定義“什麼是我的資料”的能力。
那麼，在進行權限配置時，支援使用者在定義角色的同時，還需要支援使用者定義“我的資料”。如下圖：
在配置不同功能子產品的資料權限時，除了定義權限類型（本人可見、本部門可見等），還可以支援使用者自定義配置權限字段，以滿足不同角色可以檢視到不同的“我的資料”。
如：
- 客服人員根據“建立人”字段檢視我的資料；
- 銷售業務員根據“銷售員”字段檢視我的資料；
- 報價專員根據“報價員”字段檢視我的資料。
三、特殊業務場景的通用設計
1、權限覆寫
在實際業務場景中，當使用者通路某一資料記錄時，該記錄關聯了其他的單據，使用者需要同步檢視關聯的這部分單據資料。
如：CRM系統中的客戶資料，客戶同時關聯了聯系人資料、訂單資料、合同資料等。當使用者檢視客戶A時，需要檢視到A客戶的所有聯系人、訂單、合同資料。但是由于客戶A可能有多個銷售同時跟進，該客戶的聯系人、訂單、合同資訊并非都是由該使用者建立，單一的資料權限便無法滿足該業務場景。
那麼，當使用者操作通路客戶A的權限時，他需要同步可以擷取到通路A關聯的業務單據對象資料的權限。即：擁有客戶對象資料的通路權限時，需要覆寫客戶相關聯對象原本的資料權限。
2、團隊成員
在實際業務中，對于某一記錄，需要将資料共享給到多個使用者共同通路、編輯。如：對于商機的跟進，需要不同角色的人員參與，需要銷售人員負責維護客戶、顧問負責方案制定、實施人員進行可行性評估、報價專員制作報價、投标人員負責投标資料整理等。對于不同的商機，不同角色對應的業務員均不一樣，需靈活指派員工進行負責。
那麼，在這種場景下需要有個群組的概念，将這部分人員組成一個群組對資料記錄負責，并且共享相關内容，這個群組即是團隊成員的概念。由資料的負責人進行組建，可将相關使用者加入團隊成員中，共享指定的資料記錄。
3、共享規則
團隊成員适用于靈活組建資料負責群組的場景，不同的資料記錄可組建不同的團隊。那在實際業務中，會存在一些相對固定的資料共享的場景。
如：公司派遣一名導師去到不同的門店進行指導。當教育訓練導師去門店進行指導前，就需要将該門店的訂單資料共享給到導師。這種場景下，每個訂單去添加導師的通路權限明顯是不現實，這就需要有批量共享的能力，将該門店的訂單打包共享給到教育訓練導師。
那麼，對于這種有固定規則的資料共享場景，可以将這些固定規則統一抽象，形成共享規則，更友善地完成資料共享。
4、崗位層級
一般的權限設計中，資料權限通常與人、組織進行綁定。但是通過人群組織進行綁定的方式，比較難解決一些特殊的業務場景，如：
- 企業的人員變動頻繁，人員的離職/入職需要完成大量的資料交接工作；
- 一人多崗的業務場景下，難以實作不同崗位的資料權限隔離，如：使用者不同崗位的上級上司檢視對應崗位的資料。
引入崗位，可以将資料與人解綁，通過崗位與資料進行關聯。員工離職的資料繼承，可以通過繼承崗位進行實作；一個多崗的場景，使用者不同崗位的資料與各崗位關聯，崗位的上級上司隻能檢視對應崗位的資料。
那麼，首先要在系統中建立崗位層級管理，崗位與組織架構類似，也是自上而下的樹狀結構。頂層為企業CEO，一層一層向下延展。
其次，在資料記錄中記錄資料關聯的使用者崗位，一人多崗的場景下，資料關聯的崗位可以由使用者手工選擇或者預設為目前登入的崗位等，可根據實際業務而定。
四、特别的權限設計架構 – 頁面級資料權限控制
目前，市面上大多數産品的資料權限均控制在對象層，在具體的功能對象上按角色設定資料權限。當擁有該角色的使用者登入系統後，在該對象的各個頁面均根據設定的資料安全性執行資料檢視。如：銷售人員角色的使用者設定了允許檢視本人的客戶資料權限，那麼客戶的各個頁面，銷售人員均檢視自己建立的資料。
這種權限架構下，有一些特殊的場景無法滿足，如：銷售人員檢視客戶資料時隻允許檢視本人的客戶資料。
但是，銷售人員在做客戶報備時，需要根據提報的客戶資料，在系統中與全部客戶資料進行查重，檢視客戶是否已經報備過。在這種場景下，對象級權限控制則無法滿足業務，銷售人員因隻允許檢視本人的資料，報備時也隻能與本人的客戶資料進行查重。
這裡分享一種特殊的權限設計架構，頁面級資料權限控制。注：這種權限設計架構可以滿足大部分的業務場景，但是，整體權限架構較為複雜，維護成本也相對較高，并不推薦所有的系統資料權限設計按這個模式設計，僅作為思維拓展。
首先，在對象層設定資料權限時，設定的是資料權限模闆，如：本部門的資料安全性，設定按哪個部門（建立部門、歸屬部門、更新部門等）字段作為權限字段；本人的資料安全性，設定按哪個使用者（建立人、歸屬人、更新人等）字段作為權限字段。
其次，在頁面層按不同的角色可設定引用哪一個資料權限模闆。如：對于銷售人員而言，客戶清單執行本人的資料安全性，僅可以檢視自己建立的客戶資料；客戶報備頁面執行全部資料安全性，銷售人員可根據客戶資訊查詢系統所有客戶資料。
本文由 @茶話B端 原創釋出于人人都是産品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。