B端產品設計:用戶角色權限系統(tǒng)設置

16 評論 38263 瀏覽 413 收藏 10 分鐘

本文首先對B端產品的用戶與需求進行了解析,進而利用RBAC模型做了權限劃分,并做了詳細的案例分析。

在做過了一些B端產品后,就會發(fā)現(xiàn)所以B端端產品有很多共同的部分,比如系統(tǒng)設置里的用戶角色權限以及基礎信息的維護,雖然B端產品可能業(yè)務不一樣,產品服務的人群、產品價值不一樣,但是用戶體系卻是每個系統(tǒng)必不可少的。

1. B端產品的用戶

1.1 B端產品的用戶

B端和C端不一樣,C端一般針對的是個人用戶,涉及的關系結構相對來說比較簡單,關注個體數(shù)據(jù)以及個體產生的價值。同時B端產品的用戶一般是企業(yè),這就決定了使用系統(tǒng)直接的同事需要相互協(xié)作,共同去完成一件事。

1.2 B端產品用戶的需求

B端客戶一般客戶角色多元化,每個用戶對系統(tǒng)的需求和職能也是不一樣的,這就需要我們根據(jù)他們的使用需求去劃分,讓系統(tǒng)使用者不會被其他事項干擾或者看到不該看到的東西。所以這就需要B端產品能夠根據(jù)每個用戶的需求去“自定義功能”,就是系統(tǒng)的設計要靈活,系統(tǒng)管理者可以靈活配置自己想要的權限以及管理自己的員工。

2. RBAC模型

在傳統(tǒng)權限模型中,我們直接把權限賦予用戶。RBAC模型的基本思想就是,對系統(tǒng)操作的各種權限不是直接授予具體的用戶,而是在用戶集合與權限集合之間建立一個角色集合。

每一種角色對應一組相應的權限。一旦用戶被分配了適當?shù)慕巧?,該用戶就擁有此角色的所有操作權限。這樣做的好處是,不必在每次創(chuàng)建用戶時都進行分配權限的操作,只要分配用戶相應的角色即可,而且角色的權限變更比用戶的權限變更要少得多,減少系統(tǒng)的開銷和頻繁設置。

RBAC0模型中角色和權限是多對多的,一個用戶擁有的權限是他所有角色的集合。如下圖,用戶1假如擁有角色1、角色2、角色3三個角色的話,那擁有的權限是權限1、權限2、權限3。

RBAC1模型中在角色中引入了分層的概念,即角色中可以分為多個等級,每個等級對應的權限是不一樣的,把權限分給用戶時,需要分到對應的角色等級。一般角色等級低的擁有的權限少,角色等級高的權限是所有等級低的權限集合。

RBAC2模型中在RBAC1模型中的基礎上對角色進行了一些限制:

  • 互斥角色限制:同時擁有兩個角色以上,且有角色互斥時,系統(tǒng)提醒職能選擇一個,比如公司職業(yè)中,如果選擇商務角色,生成結算單,并提交給財務審核時,這時候就不能賦予這個員工財務角色。否則他就可以自己提交結算單自己審核結算單了。
  • 角色數(shù)量限制:一個員工的角色是有限的 了,不能無限制的添加;
  • 先決條件限制:若一個員工想獲得更高權限時,需要獲得低級權限,比如想獲得產品總監(jiān)的權限那就需要從產品助理的角色先到產品經理的權限;

3. 詳細案例設計

3.1 公司管理

一個B端的用戶角色權限系統(tǒng)大致可以包含:公司管理、部門管理、角色管理、用戶管理。在一個集團中,往往在不同地區(qū)有不通的子公司或者合資公司,那如果這些公司里的員工同時用這套系統(tǒng),那就需要進行公司管理,如下圖:

一般公司管理,需要基本信息包含企業(yè)名稱、企業(yè)聯(lián)系人、聯(lián)系人號碼、社會統(tǒng)一信用代碼、通訊地址、法人信息以及一些證件信息上傳營業(yè)執(zhí)照、法人身份證照片等。

公司管理的錄入一般是為了后期的員工管理以及一些基礎信息維護時的歸屬,一般頁面設計如下:

3.2 部門管理

公司向下就是部門管理,在權限設計時,有時也會賦予部門一些權限,只要是這個部門的人都具有部門權限,當用戶再賦予角色時,會在部門權限的基礎上累計添加的角色權限。

即我們可以把一個部門看成一個用戶組,如銷售部,財務部,再給這個部門直接賦予角色,使部門擁有部門權限,這樣這個部門的所有用戶都有了部門權限。

用戶組概念可以更方便的給群體用戶授權,且不影響用戶本來就擁有的角色權限。

部門設計一般有所屬公司、上級部門、部門名稱、部門分類,部門的劃分只要是為下方的用戶權限以及數(shù)據(jù)權限做準備。一般設計如下:

3.3 角色管理

角色對應的是權限,一般包含功能權限,精確到功能操作權限,字段權限,包含字段是否可讀或者使用、以及一些數(shù)據(jù)權限,是只能看見自己的數(shù)據(jù)還是可以看見同部門的、其他部門的、以及整個公司、或者整個地區(qū)的數(shù)據(jù),這些都是靠角色去設置。

功能權限

對于后臺產品來講,針對功能菜單來劃分用戶權限其實是比較粗顆粒度的一種管理方式,這種模式下用戶一旦獲得授權即可使用該菜單欄下的全部數(shù)據(jù)查看權限和功能操作權限,頁可以針對單個菜單下的操作按鈕進行權限設置。

字段使用

字段的設置在對象向下,用來區(qū)分不同角色進入同一菜單下見到和可使用的字段是不一樣的。用戶可對業(yè)務下的字段進行可見或者只讀形式的設置。

需要注意,角色一般不做刪除,只用禁用啟用操作,禁用時會校驗是否當前有用戶在使用,如果有使用時提醒設置者去更換賬號角色方可禁用。

3.4 員工管理

員工管理是對應的賬號,在公司、部門、角色設置好后,我們就可以對員工進行管理了,一般員工包含在系統(tǒng)中的使用賬號的和不使用賬號的。

在對用戶管理進行分配角色時,我們可以分配一個角色,也可以分配多個角色,也可以快捷分配所有的角色。

一般到此一般喜用的角色權限就可以滿足業(yè)務需求了,但后期可能會涉及到多個系統(tǒng)去使用一個用戶體系,這就需要產品跟隨業(yè)務模式進行調整,但是一般基本模型不會變更。

The end !

 

本文由 @ Shirley 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 關于”部門掛載一個部門角色,當用戶加入到這個部門就自動繼承這個部門的角色“;
    這個我之前也設計過,但是有兩個問題:
    1.就是當這個用戶被移出這個部門的時候,那么這個繼承的角色要一并自動移除嗎?
    2.部門可以是一個用戶組,那用戶組的管理是不是還有一個單獨的管理模塊去管理?

    來自安徽 回復
    1. 只是停用吧

      來自江蘇 回復
    2. 1、用戶加入這個部門的時候 給他設置好角色權限 被移出的時候 只要移除這個賬號就可以啊 和角色有什么關系
      2、部門里面可以給每個用戶的賬號分上下級

      來自江西 回復
  2. 寫的很細致,期待新作品

    來自山東 回復
  3. 有收獲,感謝~

    來自山西 回復
  4. 簡單明了,感謝感謝

    來自江蘇 回復
  5. 各位大佬,我想請教一下。角色管理和部門管理為什么不能合到一起,例如角色管理既有角色的屬性也有部門的屬性

    回復
    1. 部門是可以具備角色的屬性的,但是會導致授權不靈活。因為B端部門管理通常要求跟企業(yè)的實際運作組織架構保持一致,合在一起會導致無法去新增跟組織無關的角色。你可以把“角色”理解為“用戶組”,用戶組的成員可以是人、組織、崗位,這樣的“用戶組”能否覆蓋絕大多數(shù)的B端授權場景。

      來自上海 回復
  6. 各位大佬,我想請教一下。角色管理和部門管理不能合到一起,例如角色管理既有角色的屬性也有部門的屬性?

    回復
  7. 這不是銷售易里的截圖 嗎 ??

    來自上海 回復
  8. 有一個問題想問一下,如果A在A部門,但是需要管理B部門的部分同事,這樣的數(shù)據(jù)范圍怎么設定呢?

    來自上海 回復
    1. 可以創(chuàng)建一個B部門的管理角色(對應部分同事),再將這個角色賦予A

      來自福建 回復
    2. 將B部分同事所在部門權限賦予A也是可以解決的!

      來自浙江 回復
    3. 這樣的話,那B部門剩余的同事,也被A管理了

      來自上海 回復
    4. 1、創(chuàng)建一個用戶組,包含B部門的部分同事。2、創(chuàng)建數(shù)據(jù)權限,將A的這個數(shù)據(jù)權限,自定義指定為該用戶組

      來自上海 回復
  9. 基本都差不多

    來自廣東 回復