產品設計:2B產品的賬號權限和組織架構

12 評論 16153 瀏覽 107 收藏 9 分鐘

本文作者從工作項目實踐出發,并結合案例等分享了2B產品中相關賬號權限和組織架構的相關知識,供大家一同參考和學習。

從2C產品轉戰2B產品,思考模式從用戶流量轉為業務流程,業務模式從C端的“平臺—商品-用戶”轉為B端的“平臺—賬號-企業員工”,用戶模式從C端的賬號散養到B端的賬號管控。B端產品集中于層次邏輯的設計,難點在賬號權限。

2B產品路線粗略分成2種:一是標品售賣,功能標準化;二是定制化,根據客戶業務,定制系統。

很多的SaaS的服務多數走標品路線,畢竟一入定制深似海,其中的苦猶如滔滔江水,綿綿不絕…..

無論是標品還是定制,權限管控和組織架構經常被cue的問題,這也是考驗一家SaaS產品是騾子還是馬的問題。廢話不多說,基于個人的項目經驗,淺談一下賬號權限和組織架構。

PS:本文探討的是滿足B端客戶使用的賬號權限,對于開通B端客戶賬號的實施平臺不在此討論

賬號權限

賬號權限:簡單來說,是對用戶是否具有增,刪,改,查的功能的控制

相對比較靈活的賬號權限設計方式為RBAC(Role-Based Access Control),中文名稱為基于角色的訪問控制。

簡單來說,根據一個人的身份不同賦予不同的操作功能,例如,你是一個兒子,也是一個丈夫,那么你就具有兩種角色,兒子的角色要對父母負責(例如:贍養父母),丈夫的角色對自己的妻孩負責(例如:養家糊口)。

有些因為角色先定義,繼而權限限定;有些因為權限先限定,再角色定義。這兩種方式,根據產品形態,選擇適合的一種方式即可。

賬號默認有管理員賬號和普通賬號兩種:管理員賬號為開通企業號時,由實施平臺開通的賬號,也就是該企業的租戶id;普通賬號是在已經開通的企業系統內,由管理員繼續開通的企業員工賬號。

普通賬號可以通過管理員賦權,擁有與管理員同等功能,即多個管理員并存。普通賬號也可已通過管理員賦權,僅擁有特定的操作權限,并被成為xx角色。

權限的劃分,涉及到功能拆解的顆粒度的大小。拆解越細,對于滿足不同用戶的需求來說可能更容易,但同時技術難度可能也會增加(良好的功能拆解與優秀的底層架構密不可分)。功能拆解的顆粒度根據自家的產品技術能力量力而為。

功能拆解對應著操作數據的歸屬,不同的數據歸屬對應功能拆解后的權限控制要求也不相同。

有些是共享流,所有賬號對同一個數據進行操作,例如:confluence協作工具,所有賬號對同一個業務流進行處理;

有些是獨立賬戶數據流,例如:釘釘里的報銷審批,每個賬號只有自己的審批操作(不考慮抄送等情況)。

賬號在無公司組織架構的情況下,可以通過賬號之間的上下關聯關系,搭建起賬號層次關系圖。賬號層次關系則需要考慮數據流操作關系,需要結合實際業務場景做處理。

例如:有些要求下級對上級全部可見,有些要求下級對上級不可見,有些要求下級對上級部分可見等。

某些情況,賬號需要和組織架構結合,那單純的賬號層級關系則無法滿足,為滿足企業復雜的情況,此時需要組織架構介入。

組織架構

組織架構:簡單來說,是企業的的架構樹狀圖。

不同的企業復雜度不同,繼而組織架構多種多樣。例如:復雜的公司組織架構,集團總部/區域劃分/區域下的地方性公司/公司下的業務部門/部門里的小組;簡單的公司組織架構,公司/部門。

組織架構在B端產品里,最常用的是與數據查看范圍關聯,賬號根據組織架構查看數據統計。例如:上圖中的公司1可查看其下所有部門的數據,區域1可查看公司1和公司2的所有數據。

組織架構有時與賬號權限相關,即根據組織架分配操作權限。

例如:負責區域1對應的賬號A1,負責區域2的對應賬號A2,負責公司的1的賬號為B1。則A1和A2為同組織級別的可具有相同的操作權限,但A1和A2的數據互不可看。B2為下一層級別,具有的不同于A1和A2的操作權限,可被A1查看,不可被A2查看。

組織架構有時并不是在自己產品系統內創建,而是對接客戶系統的組織架構,組織架構的層級識別則需要做二次梳理,需要與自己產品的邏輯相對應,方便產品整體設計。

復雜組合

公司的業務復雜度很難以一種方式滿足,常常是既走賬號權限把控,又走組織架構調整,越復雜的情況,越需要抽絲剝繭。

針對復雜的情況,可由內而外即從自身產品出發,結合業務場景分析,也可由外而內即先分析業務場景,再拆解到功能,再對應到自身產品去分析。

無論哪種方法,歸根結底到自家產品時,一定是要熟知自家產品的底層邏輯設計,每個模塊的產品邏輯,每個數據是共享流還是獨立流,自家產品分的越細致,應對B端的復雜情況越容易。

比如一盤菜,需要原料n種,需要調料m,調料做成了m個單個調料包而非一包混雜的,那么調味出來的菜味道將更可控。

賬號權限和組織結構是B端產品的一個設計基礎與重點,希望本篇能有一點作用。清楚理解賬號權限和組織架構的關系后,根據實際業務形態,慢慢梳理,總會有一套適合的產品設計。打好地基,高樓建起。

#專欄作家#

Lprecious,人人都是產品經理專欄作家。成長中的產品汪,關注車輛網行業和B端產業發展,目前從事人力資源SAAS解決方案行業。

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 感謝分享

    來自廣東 回復
  2. 你好,最近也做類似saas軟件的產品,關于組織架構這一塊比較苦惱,方便加個微信嗎?想請教一下您

    來自浙江 回復
    1. 可以啊,不過我也不是專業的哈,互相討論討論。微信L-lming

      來自上海 回復
    2. 可以加你微信嘛

      回復
    3. 我最近也在做這個

      回復
  3. 一通廢話,灌水?。。?!

    來自上海 回復
  4. 浪費時間哪

    回復
  5. 這么能講廢話 水一篇 也是本事

    回復
  6. 感謝分享

    回復
  7. 感覺說了一堆廢話 ??

    來自浙江 回復
    1. 圖示都被刪了,不刪的花,可能廢話感少點吧 ?

      來自上海 回復
    2. 感謝分享

      回復