面向中小企業(yè)SaaS的權(quán)限管理系統(tǒng)

25 評論 42072 瀏覽 338 收藏 12 分鐘

本文基于面向某個(gè)垂直行業(yè)的SaaS系統(tǒng)的設(shè)計(jì)經(jīng)驗(yàn),抽象出一套適合中小企業(yè)的權(quán)限管理體系,目標(biāo)是最大限度保留系統(tǒng)彈性的同時(shí),把系統(tǒng)復(fù)雜度和開發(fā)成本盡可能降低。enjoy~

面向企業(yè)級的SaaS(軟件及服務(wù))系統(tǒng),由于企業(yè)用戶的規(guī)模和內(nèi)部管理模式千差萬別,設(shè)計(jì)一套具備足夠彈性、符合絕大部分目標(biāo)企業(yè)用戶需求的權(quán)限管理系統(tǒng),是一個(gè)很大的挑戰(zhàn)。

我們可以看到,市面上面向多個(gè)行業(yè)的綜合性SaaS系統(tǒng),例如銷售易、紛享銷客等,由于它們的目標(biāo)客戶跨越了多個(gè)行業(yè)、多種規(guī)模,這些企業(yè)具備各種各樣的內(nèi)部管理風(fēng)格和模式,在權(quán)限系統(tǒng)的管理上,往往做得非常復(fù)雜,不僅具備部門、角色、職位、數(shù)據(jù)等各個(gè)維度的權(quán)限管理,各個(gè)功能模塊還有自己獨(dú)立的權(quán)限管理,雖然具備最大的彈性,卻給企業(yè)的系統(tǒng)管理帶來較大的負(fù)擔(dān)。

本文基于面向某個(gè)垂直行業(yè)的SaaS系統(tǒng)的設(shè)計(jì)經(jīng)驗(yàn),抽象出一套適合中小企業(yè)的權(quán)限管理體系,目標(biāo)是最大限度保留系統(tǒng)彈性的同時(shí),把系統(tǒng)復(fù)雜度和開發(fā)成本盡可能降低。

提煉的三個(gè)核心原則:

  • 企業(yè)-管理員-普通賬號三級權(quán)限
  • 功能和數(shù)據(jù)權(quán)限分離
  • 部門和角色分離

圍繞上述三個(gè)基本原則,我們力圖在滿足中小企業(yè)需求的前提下保持足夠的彈性,并嚴(yán)格控制復(fù)雜度和開發(fā)成本。詳細(xì)描述如下。

1. 權(quán)限從上到下分為三個(gè)層級:企業(yè)賬號(老板賬號)、管理員賬號、普通賬號

對于中小企業(yè)來說,公司的實(shí)際控制人,往往是公司的創(chuàng)始人或自然人大股東,因此企業(yè)賬號的使用者以及對應(yīng)綁定的手機(jī)號碼,都是公司的實(shí)際控制人,他應(yīng)該掌握最核心、權(quán)限最大的企業(yè)賬號,所以也可以稱為“老板賬號”。

但是在實(shí)際場景中,公司的實(shí)際控制人并不會直接管理公司的業(yè)務(wù)支撐系統(tǒng),因此,需要在系統(tǒng)首次部署時(shí),創(chuàng)建好企業(yè)賬號,并由企業(yè)賬號授權(quán)給某一個(gè)或多個(gè)系統(tǒng)管理員,由系統(tǒng)管理員去完成日常的角色創(chuàng)建、員工導(dǎo)入等工作。系統(tǒng)管理員,對應(yīng)的一般就是HR或行政部門的管理人員。當(dāng)然,企業(yè)賬號的權(quán)限高于管理員賬號,如果是小微型企業(yè),也可以由企業(yè)賬號直接替代管理員賬號的功能。

除了企業(yè)賬號和管理員賬號之外,其他各級員工所持有的賬號,都屬于普通賬號。普通賬號的部門、角色、數(shù)據(jù)等權(quán)限的設(shè)置,一律由系統(tǒng)管理員配置。

三個(gè)權(quán)限層級示意圖如下:

在實(shí)際系統(tǒng)中的核心業(yè)務(wù)步驟如下:

(1)企業(yè)購買系統(tǒng)時(shí),創(chuàng)建一個(gè)企業(yè)賬號,這個(gè)企業(yè)賬號綁定的手機(jī)號碼為公司實(shí)際控制人的手機(jī)號碼。該手機(jī)號碼必要時(shí)可以解綁(例如公司實(shí)際控制人變更),由于該功能觸發(fā)頻率很低,因此不需要在前端功能中實(shí)現(xiàn),只需要在購買協(xié)議中寫明,“購買企業(yè)可以通過書面方式提出企業(yè)賬號手機(jī)號碼綁定變更需求”即可。

(2)在部署和培訓(xùn)階段,可指導(dǎo)企業(yè)賬號持有人創(chuàng)建一個(gè)或多個(gè)管理員賬號,該賬號一般授權(quán)給行政總監(jiān)或人力資源總監(jiān),后續(xù)配置即由管理員賬號進(jìn)行。

(3)管理員賬號持有人需要接受系統(tǒng)培訓(xùn),掌握部門創(chuàng)建、角色創(chuàng)建、功能和數(shù)據(jù)權(quán)限分配等基本操作。管理員所有操作都必須記錄在案,供企業(yè)賬號持有人監(jiān)督,且管理員操作觸發(fā)異常行為規(guī)則(如大量分配高等級權(quán)限等)時(shí),系統(tǒng)會通過短信方式通知到企業(yè)賬號持有人,確保企業(yè)賬號對管理員的全方位掌控。

(4)企業(yè)賬號可隨時(shí)將管理員賬號禁用或設(shè)定為離職,但管理員賬號不可對企業(yè)賬號進(jìn)行任何配置或操作。

(5)企業(yè)賬號默認(rèn)擁有所有權(quán)限。

2. 功能權(quán)限和數(shù)據(jù)權(quán)限分離

功能權(quán)限,定義為可見、可以操作的功能范圍。例如某一部分菜單,或者某個(gè)頁面里的各種操作。

數(shù)據(jù)權(quán)限,定義為若干個(gè)數(shù)據(jù)類型里的具體可見范圍,例如“客戶”就是一個(gè)數(shù)據(jù)類型,它的權(quán)限舉例如“無權(quán)限”、“我的客戶”、“我所在部門的客戶”、“我所在部門及下級部門的客戶”。

通過功能權(quán)限和數(shù)據(jù)權(quán)限的分離,我們可以做到以下場景:需要開拓和維護(hù)客戶的角色集合,都可以擁有“客戶”這個(gè)菜單的權(quán)限,但不同的角色進(jìn)入“客戶”菜單的列表時(shí),看到的客戶范圍各不相同,極端情況是看不到任何客戶。且不同角色在同一個(gè)客戶頁面上,能進(jìn)行的操作也不同,例如有的角色可以新建客戶,有的卻不行,這就要由功能權(quán)限來控制。

可見,通過功能權(quán)限和數(shù)據(jù)權(quán)限的分離和配合,我們在具體的權(quán)限分配上有了非常大的彈性,且在技術(shù)層面的后臺系統(tǒng)的設(shè)計(jì)上,也非常合理、清晰。

而在具體設(shè)計(jì)上,需要保證以下4點(diǎn):

  1. 正確區(qū)分功能和數(shù)據(jù),入口性和操作性的都應(yīng)該歸類為功能
  2. 正確對數(shù)據(jù)進(jìn)行分類,避免存在分類后的某些數(shù)據(jù)存在交集
  3. 數(shù)據(jù)分類到多細(xì)的顆粒度,需要由行業(yè)特性決定
  4. 數(shù)據(jù)權(quán)限區(qū)分為查看、編輯和刪除

示例圖如下,由于涉及具體產(chǎn)品,對某些文字進(jìn)行了打碼:

3、部門和角色分離

部門的定義,自然就是公司行政組織架構(gòu)下的部門。

在本設(shè)計(jì)方案中,角色等同于職位,而在許多大型的SaaS系統(tǒng)中,為了更大的靈活性,往往會把角色和職位分開,但根據(jù)我們的判斷,對于中小企業(yè),設(shè)定角色一個(gè)就夠了,職位當(dāng)然還存在,但僅僅是一個(gè)不涉及權(quán)限管理的文本title了。

以一個(gè)銷售公司來說,角色可以包括:“渠道專員”、“渠道總監(jiān)”、“銷售專員”、“銷售經(jīng)理”、“總經(jīng)理”等等。

所謂的部門和角色分開,就是不同的部門可以有相同的角色,例如如果有渠道一部、渠道二部,則這兩個(gè)渠道部的員工的角色都可以設(shè)定為“渠道專員”,這兩個(gè)部門的管理者都可以設(shè)定為“渠道經(jīng)理”。再配合功能和數(shù)據(jù)權(quán)限,則進(jìn)一步配置“渠道專員”具有“渠道”菜單的功能權(quán)限,其能夠查看的渠道數(shù)據(jù)權(quán)限范圍則僅為“我的”,而“渠道經(jīng)理”同樣具有“渠道”菜單的功能權(quán)限,但其能夠查看的渠道數(shù)據(jù)權(quán)限的范圍則擴(kuò)大為“部門”。

具體設(shè)計(jì)上:

  1. 最大部門即為公司
  2. 管理員賬號和普通賬號均可禁用或設(shè)置為離職
  3. 不同部門可以配置相同角色
  4. 相同角色的功能權(quán)限和數(shù)據(jù)權(quán)限是一樣的

4. 權(quán)限系統(tǒng)和其他功能設(shè)計(jì)的關(guān)系

總結(jié)完權(quán)限系統(tǒng)三個(gè)核心的基本原則后,我們還需要指出一點(diǎn):權(quán)限系統(tǒng)的設(shè)計(jì)方案,在整個(gè)系統(tǒng)中絕不是孤立的,它能否實(shí)現(xiàn)設(shè)計(jì)目標(biāo),并和整個(gè)系統(tǒng)完美配合,還需要做到以下幾點(diǎn):

首先,菜單和功能的設(shè)計(jì),必須是最小顆粒度,否則就和數(shù)據(jù)權(quán)限產(chǎn)生沖突。例如:我們只需要一個(gè)“客戶”菜單即可,不同角色在“客戶”菜單里能干什么事情,由功能權(quán)限和數(shù)據(jù)權(quán)限配合進(jìn)行控制,但切不可出現(xiàn)“我的客戶”+“全部客戶”兩個(gè)菜單,這明顯和數(shù)據(jù)權(quán)限有根本沖突,且也是一種不優(yōu)美、不合理、擴(kuò)展性差的設(shè)計(jì)。

其次,數(shù)據(jù)的分類,必須符合業(yè)務(wù)需求,且劃分合理。有些數(shù)據(jù)都是公開的可以不歸入數(shù)據(jù)權(quán)限進(jìn)行管理,所有角色默認(rèn)都有即可;有些數(shù)據(jù)需要進(jìn)一步細(xì)分,例如同樣以“客戶”舉例,在某些公司的業(yè)務(wù)規(guī)則中,就需要將客戶的基本信息和聯(lián)系信息分開控制,管理層可以看客戶基本信息,但只有客戶負(fù)責(zé)人才可以看聯(lián)系信息,這種情況就需要將客戶的數(shù)據(jù)權(quán)限分為“客戶基本信息”和“客戶聯(lián)系信息”兩個(gè)。

最后,權(quán)限變更的記錄和所有賬號的行為軌跡記錄一樣重要。權(quán)限系統(tǒng)本質(zhì)是進(jìn)行權(quán)力的限制,沒有監(jiān)管的權(quán)力必定是會失控的。在出現(xiàn)問題的時(shí)候,必須同時(shí)配合權(quán)限變更的記錄、角色變更的記錄和賬號的行為軌跡記錄進(jìn)行追責(zé)和存證,確保維護(hù)企業(yè)的合法權(quán)益。

總結(jié)

在合理設(shè)計(jì)的前提下,權(quán)限系統(tǒng)也并非越復(fù)雜越好。只有符合目標(biāo)客戶需求并具備最大彈性的權(quán)限系統(tǒng),才是最好的。

 

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

題圖來源于網(wǎng)絡(luò)

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 有個(gè)問題,在此方案里如何設(shè)定部門主管,便于后續(xù)業(yè)務(wù)中的審批等操作。

    回復(fù)
  2. 寫的挺好,就是數(shù)據(jù)權(quán)限中,不應(yīng)該把編輯 刪除 劃入吧

    來自浙江 回復(fù)
  3. 公司內(nèi)部B端產(chǎn)品,角色按照流程劃分的。(例如:瀏覽者、發(fā)布者、審核人、系統(tǒng)管理員),那么,權(quán)限的級別劃分可以也按照角色嗎??

    來自北京 回復(fù)
  4. 我還有一個(gè)問題就是,好像我只要確認(rèn)員工的上下級關(guān)系就可以確定數(shù)據(jù)的范圍權(quán)限了 – –

    來自湖南 回復(fù)
    1. 可以的

      來自廣東 回復(fù)
  5. 為什么在數(shù)據(jù)權(quán)限那里區(qū)分查看,編輯,刪除呢? 查看 編輯和刪除不是功能操作權(quán)限嗎?

    來自湖南 回復(fù)
    1. 同問

      回復(fù)
    2. 小小白理解:查看等操作是功能權(quán)限。但是數(shù)據(jù)的權(quán)限的設(shè)置無非就是查看、編輯、刪除等。

      來自北京 回復(fù)
    3. 增刪改查是最基本的功能,必然是屬于功能權(quán)限。只能說作者有點(diǎn)沒走心

      來自上海 回復(fù)
    4. 應(yīng)該是把數(shù)據(jù)權(quán)限做了讀寫分離 這樣容易引起歧義。

      來自安徽 回復(fù)
    5. 功能權(quán)限是指我能否操作這個(gè)按鈕;數(shù)據(jù)權(quán)限是我操作這個(gè)功能時(shí)能影響的數(shù)據(jù)范圍,比如:查看/編輯員工信息,我作為組長,只能查看/編輯我自己組的員工,而不是全公司的員工。

      來自廣東 回復(fù)
  6. fusion,干貨

    來自上海 回復(fù)
  7. 但感覺saas面向中小企業(yè),權(quán)限配置還是過于繁瑣,一直在思考著一個(gè)輕量級的,畢竟中小企業(yè)架構(gòu)不復(fù)雜。

    來自四川 回復(fù)
  8. 不錯(cuò),深受啟發(fā),希望以后多分享一下干貨! ??

    來自廣東 回復(fù)
  9. 最近正在做這塊,很有幫助。感謝分享

    來自廣東 回復(fù)
  10. 做過一些特定行業(yè)內(nèi)的管理系統(tǒng),涉及權(quán)限。因?yàn)樾袠I(yè)數(shù)據(jù)數(shù)據(jù)差異,權(quán)限差異挺大的,特別復(fù)雜,而試圖做的簡單通用則不滿足業(yè)務(wù)管理需求,存在風(fēng)險(xiǎn)。
    如果說權(quán)限體系抽象,感覺還是有點(diǎn)困難,不知有沒有什么好的建議,謝謝。

    回復(fù)
    1. 事實(shí)上,就算是大而全、覆蓋全行業(yè)的那些SaaS,具體到特定行業(yè)也普遍存在不滿足全部需求的情況。所以這些SaaS公司才會同時(shí)也搞Pass,讓大家一起針對特定行業(yè)去定制開發(fā)。

      來自廣東 回復(fù)
  11. 這樣會存在一定的局限性,例如一個(gè)部門的人員只需要處理兩個(gè)門店的銷售數(shù)據(jù),就會存在局限,可以適當(dāng)考慮將數(shù)據(jù)權(quán)限做成可配置項(xiàng)。

    回復(fù)
    1. 確實(shí)是。進(jìn)一步擴(kuò)展是往數(shù)據(jù)分類和具體權(quán)限靈活配置的方向去了,但復(fù)雜度也大大提高了,這個(gè)方案只能說是精簡版

      來自廣東 回復(fù)
  12. 訂閱了,期待下一篇作品

    來自山東 回復(fù)
  13. 呢【【,=】】

    回復(fù)
  14. 非常好,最近正在做一款產(chǎn)品的權(quán)限設(shè)計(jì),多謝了!另外想請教下,想以后往中后臺產(chǎn)品設(shè)計(jì)發(fā)展,請問有哪些學(xué)習(xí)途徑和方法?謝謝

    來自上海 回復(fù)
    1. 中后臺側(cè)重對業(yè)務(wù)流程進(jìn)行合理抽象、簡化或優(yōu)化,強(qiáng)調(diào)邏輯性,各類狀態(tài)也更復(fù)雜。具體的學(xué)習(xí)途徑可以從幾個(gè)方面著手:首先學(xué)習(xí)工作流設(shè)計(jì)、權(quán)限設(shè)計(jì)等通用的內(nèi)容,這些已經(jīng)有現(xiàn)成的成熟套路;其次可以選擇一些知名產(chǎn)品,注冊試用賬號進(jìn)行全流程分解學(xué)習(xí);最后在試用或工作實(shí)踐中,建議重視流程圖的規(guī)范性,在規(guī)范的流程圖中不斷提高抽象思維、提煉和簡化能力。

      來自廣東 回復(fù)
    2. 謝謝您的回復(fù),現(xiàn)在有做一些中后臺的產(chǎn)品設(shè)計(jì),但是感覺都在皮毛上,沒有深入的全局了解、掌控和規(guī)劃,總感覺還游離在體系在外,謝謝您的建議,希望以后能和您多交流

      來自上海 回復(fù)
    3. 希望互相學(xué)習(xí) ??

      來自廣東 回復(fù)