本文作者從工作項目實踐出發(fā)，并結(jié)合案例等分享了2B產(chǎn)品中相關(guān)賬號權(quán)限和組織架構(gòu)的相關(guān)知識，供大家一同參考和學(xué)習(xí)。

從2C產(chǎn)品轉(zhuǎn)戰(zhàn)2B產(chǎn)品，思考模式從用戶流量轉(zhuǎn)為業(yè)務(wù)流程，業(yè)務(wù)模式從C端的“平臺—商品-用戶”轉(zhuǎn)為B端的“平臺—賬號-企業(yè)員工”，用戶模式從C端的賬號散養(yǎng)到B端的賬號管控。B端產(chǎn)品集中于層次邏輯的設(shè)計，難點(diǎn)在賬號權(quán)限。

2B產(chǎn)品路線粗略分成2種：一是標(biāo)品售賣，功能標(biāo)準(zhǔn)化；二是定制化，根據(jù)客戶業(yè)務(wù)，定制系統(tǒng)。

很多的SaaS的服務(wù)多數(shù)走標(biāo)品路線，畢竟一入定制深似海，其中的苦猶如滔滔江水，綿綿不絕…..

無論是標(biāo)品還是定制，權(quán)限管控和組織架構(gòu)經(jīng)常被cue的問題，這也是考驗一家SaaS產(chǎn)品是騾子還是馬的問題。廢話不多說，基于個人的項目經(jīng)驗，淺談一下賬號權(quán)限和組織架構(gòu)。

PS：本文探討的是滿足B端客戶使用的賬號權(quán)限，對于開通B端客戶賬號的實施平臺不在此討論

賬號權(quán)限

賬號權(quán)限：簡單來說，是對用戶是否具有增，刪，改，查的功能的控制

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

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

有些因為角色先定義，繼而權(quán)限限定；有些因為權(quán)限先限定，再角色定義。這兩種方式，根據(jù)產(chǎn)品形態(tài)，選擇適合的一種方式即可。

賬號默認(rèn)有管理員賬號和普通賬號兩種：管理員賬號為開通企業(yè)號時，由實施平臺開通的賬號，也就是該企業(yè)的租戶id；普通賬號是在已經(jīng)開通的企業(yè)系統(tǒng)內(nèi)，由管理員繼續(xù)開通的企業(yè)員工賬號。

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

權(quán)限的劃分，涉及到功能拆解的顆粒度的大小。拆解越細(xì)，對于滿足不同用戶的需求來說可能更容易，但同時技術(shù)難度可能也會增加（良好的功能拆解與優(yōu)秀的底層架構(gòu)密不可分）。功能拆解的顆粒度根據(jù)自家的產(chǎn)品技術(shù)能力量力而為。

功能拆解對應(yīng)著操作數(shù)據(jù)的歸屬，不同的數(shù)據(jù)歸屬對應(yīng)功能拆解后的權(quán)限控制要求也不相同。

有些是共享流，所有賬號對同一個數(shù)據(jù)進(jìn)行操作，例如：confluence協(xié)作工具，所有賬號對同一個業(yè)務(wù)流進(jìn)行處理；

有些是獨(dú)立賬戶數(shù)據(jù)流，例如：釘釘里的報銷審批，每個賬號只有自己的審批操作（不考慮抄送等情況）。

賬號在無公司組織架構(gòu)的情況下，可以通過賬號之間的上下關(guān)聯(lián)關(guān)系，搭建起賬號層次關(guān)系圖。賬號層次關(guān)系則需要考慮數(shù)據(jù)流操作關(guān)系，需要結(jié)合實際業(yè)務(wù)場景做處理。

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

某些情況，賬號需要和組織架構(gòu)結(jié)合，那單純的賬號層級關(guān)系則無法滿足，為滿足企業(yè)復(fù)雜的情況，此時需要組織架構(gòu)介入。

組織架構(gòu)

組織架構(gòu)：簡單來說，是企業(yè)的的架構(gòu)樹狀圖。

不同的企業(yè)復(fù)雜度不同，繼而組織架構(gòu)多種多樣。例如：復(fù)雜的公司組織架構(gòu)，集團(tuán)總部／區(qū)域劃分／區(qū)域下的地方性公司／公司下的業(yè)務(wù)部門／部門里的小組；簡單的公司組織架構(gòu)，公司／部門。

組織架構(gòu)在B端產(chǎn)品里，最常用的是與數(shù)據(jù)查看范圍關(guān)聯(lián)，賬號根據(jù)組織架構(gòu)查看數(shù)據(jù)統(tǒng)計。例如：上圖中的公司1可查看其下所有部門的數(shù)據(jù)，區(qū)域1可查看公司1和公司2的所有數(shù)據(jù)。

組織架構(gòu)有時與賬號權(quán)限相關(guān)，即根據(jù)組織架分配操作權(quán)限。

例如：負(fù)責(zé)區(qū)域1對應(yīng)的賬號A1，負(fù)責(zé)區(qū)域2的對應(yīng)賬號A2，負(fù)責(zé)公司的1的賬號為B1。則A1和A2為同組織級別的可具有相同的操作權(quán)限，但A1和A2的數(shù)據(jù)互不可看。B2為下一層級別，具有的不同于A1和A2的操作權(quán)限，可被A1查看，不可被A2查看。

組織架構(gòu)有時并不是在自己產(chǎn)品系統(tǒng)內(nèi)創(chuàng)建，而是對接客戶系統(tǒng)的組織架構(gòu)，組織架構(gòu)的層級識別則需要做二次梳理，需要與自己產(chǎn)品的邏輯相對應(yīng)，方便產(chǎn)品整體設(shè)計。

復(fù)雜組合

公司的業(yè)務(wù)復(fù)雜度很難以一種方式滿足，常常是既走賬號權(quán)限把控，又走組織架構(gòu)調(diào)整，越復(fù)雜的情況，越需要抽絲剝繭。

針對復(fù)雜的情況，可由內(nèi)而外即從自身產(chǎn)品出發(fā)，結(jié)合業(yè)務(wù)場景分析，也可由外而內(nèi)即先分析業(yè)務(wù)場景，再拆解到功能，再對應(yīng)到自身產(chǎn)品去分析。

無論哪種方法，歸根結(jié)底到自家產(chǎn)品時，一定是要熟知自家產(chǎn)品的底層邏輯設(shè)計，每個模塊的產(chǎn)品邏輯，每個數(shù)據(jù)是共享流還是獨(dú)立流，自家產(chǎn)品分的越細(xì)致，應(yīng)對B端的復(fù)雜情況越容易。

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

賬號權(quán)限和組織結(jié)構(gòu)是B端產(chǎn)品的一個設(shè)計基礎(chǔ)與重點(diǎn)，希望本篇能有一點(diǎn)作用。清楚理解賬號權(quán)限和組織架構(gòu)的關(guān)系后，根據(jù)實際業(yè)務(wù)形態(tài)，慢慢梳理，總會有一套適合的產(chǎn)品設(shè)計。打好地基，高樓建起。

#專欄作家#

Lprecious，人人都是產(chǎn)品經(jīng)理專欄作家。成長中的產(chǎn)品汪，關(guān)注車輛網(wǎng)行業(yè)和B端產(chǎn)業(yè)發(fā)展，目前從事人力資源SAAS解決方案行業(yè)。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

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