編輯導讀：EHR系統即人力資源管理系統，通過做權限系統可以方便維護，減少人力部門的工作量。本文通過實際案例，分析項目的不同階段要怎麼設置權限，希望對你有幫助。
原來已經寫過一篇關於權限系統的文章，涉及到各種類型的權限管理（B端產品權限設計，別踩了坑才想起我）。今天講一個比較垂直的，基於 RBAC 設計的 EHR 系統的權限設計過程，方便更多小夥伴參考。
為什麼要寫權限設計？講一下背景：
接手了 EHR 系統權限設計相對簡單，是直接採用用戶+權限的模式。在項目初期能快速的完成場景需求，但隨著業務的發展，薪酬計算、入離職審批、各種行政&人事通知，這種模式越來越不能滿足需要了，而且研發每次調整，也是花費不少時間，也是非常麻煩。
註：EHR 系統：即人力資源管理系統，通常包括員工管理、薪酬核算、入離職審批、績效系統等，主要是通過自動流程，減少人力化部門的工作量。
所以就開始做權限的升級。正好星球群的小夥伴也想了解下設計過程，我就簡單介紹下。做權限系統的目的很簡單：維護方便，權限清晰。我們基於經典的權限模型 RBAC（Role-Based Access Control）的思想設計，來優化下 EHR 的權限系統。
我就以實際項目的進展，來看項目在不同階段，怎麼設置權限的。
一、簡單的權限管理：用戶-權限
HR 項目剛開始只有一個「員工花名冊管理」，只有兩個角色，人事管理+HRBP，總的人數不超過 10 個。
權限有新增/批量導入員工信息、修改和查看員工信息。人事管理有增刪改查權限，HRBP 只能查看。
原來的產品經理，得到的需求很簡單，就是只做員工管理，也沒有想到，EHR 項目會變成一個集員工管理、薪酬核算、入離職審批、績效管理為一體的大工程。
所以前期就簡單的做了：用戶 – 權限。
這種方式，適合小工程和小團隊，並且不複雜的業務，研發和管理員能快速的進行配置，完成業務需求。
二、引入角色概念：用戶-角色-權限
接下來 EHR 系統進入了發展期，薪酬核算、社保核算等功能列入開發計劃，用戶也逐步增多，並且有一定的流動性。
團隊每加入一個小夥伴或有轉崗，就需要研發同學協助配置一系列權限，每次發布新功能，也都需要研發初始化一波權限，
特別是 EHR 的產品和研發同學，是沒有線上系統權限的，一旦發生因為權限配置遺漏，導致某些員工不能正常使用新功能，我們都無法知曉。還有薪酬模塊，HRBP 和人事管理需要權限隔離，是不能查看的。
現在的權限模型開始升級，嘗試使用 BRAC 權限模型，在用戶和權限中，加上角色的概念。
新增了角色：HRBP、人事管理、薪酬管理員、社保專員等。
由於員工薪酬和社保信息，屬於公司機密，只能由薪酬管理員和社保專員有查看、修改的權限，在權限的基礎上，增加了「薪酬密碼」功能，權限+薪酬密碼，雙重認證才能查看薪酬等隱私內容。
上線後新員工入離職、調崗等，只需要配置下角色就可以了。
三、細分化：用戶-（組織+角色）-權限
隨著EHR 系統模塊增加，新增了如部門助理、IT、行政、團隊負責人等等角色，分工也更加清晰。有些角色是不需要登錄 EHR 系統，但需要收到系統通知，越來越多的消息，反而成了業務團隊的負擔。
比如說原來 HRBP 可能負責一個大的業務團隊，現在要負責大團隊下 2、3 個小業務線。入離職流程要通知對應團隊的部門助理、it 等某些員工具備多角色，如員工 A 是部門助理，但又負責內部系統權限管理員，除了要收到每個月本部門的員工生日等提醒，還有負責關閉離職員工的內部系統權限這需要在原有的角色基礎上，增加所屬組織。當用戶使用某功能的時候，根據角色和所屬組織，來進一步約束。
上線後的效果：
身兼數職的助理小姐姐雖然通知類消息也很多，但與其無關的都去掉了。權限更加收緊，HRBP 小姐姐也只需要管理負責的業務團隊的事情。
四、權限設計：權限樹+權限點
權限管理可以分為權限樹和權限點。
比如說「員工信息管理」是個權限樹，包含增加、修改、刪除等權限點。功能權限通過對角色的權限樹進行修改來實現。需要注意的一個問題是，要定義好權限的最小粒度。如果要實現每一個權限的控制，相當於每一個權限對應功能都需要做封裝。大的頁面權限是必備的，但是有一些權限是可以封裝在一起，比如說「添加員工」和『批量導入員工信息』，這些是需要產品考慮的。權限的具體設計，不做重點說明。
五、小結
以上就是簡單的 RBAC 權限設計，儘管是基於 EHR 系統，但萬變不離其宗，都是基於RBAC 的3 個關鍵元素：用戶 – 角色 – 權限。實踐出真知，多看多學多做，才能成為自己的能力的一部分。
#專欄作家#
8年+網際網路資深產品經驗，多年B端產品管理經驗。具有多個從0到1的大型B端產品的孵化、重構、迭代經驗；主要教授產業網際網路產品相關的硬核知識點。
本文原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。