以釘釘為例,拆解權限系統和工作流

0 評論 12524 瀏覽 111 收藏 17 分鐘

編輯導讀:權限系統可以從字面上理解,賦予不同用戶不同的權限,比如管理員可以增刪賬戶,普通員工只能讀寫數據。本文作者以釘釘為例,拆解權限系統和工作流,希望對你有幫助。

在B端產品從0到1設計的過程中,有一些基礎內容是繞不開的,比如人員系統、賬號系統、權限系統、工作流系統等等。但是這些系統也相對成熟,可以玩出花的地方也不多,對于這部分我們倒可以占據后發優勢,去學習行業內的產品是怎么做的。

這里給大家提供一個思路,SaaS的產品經理可以試著從非競品找到設計靈感。我們這篇文章主要聊一下權限系統和工作流,單從這兩個通用模塊來看,感覺OA系統有比較不錯的心得。我們以釘釘為例做一個權限系統和工作流部分的拆解,也算對平時工作的一個總結。

01?權限系統,RBAC(Role-Based Access Control)

權限系統可以從字面上理解,賦予不同用戶不同的權限,比如管理員可以增刪賬戶,普通員工只能讀寫數據。常規權限系統設計會用到RBAC模型,基于角色的訪問控制模型。在沒用到這個RBAC模型的情況下,用戶會和權限直接綁定。

(用戶-權限)

這個對于簡單系統是非常易懂的,對于人員變動不大的系統也是可以直接上手使用的。但是當有人員變動或者權限變動的時候,問題就出來了。以上圖為例,小路離職,索大升職,享有小路的全部權利,這個時候會產生比較大的變動。而根據RBAC,那么就會有三層結構,用戶-角色-權限。通過升維解決低維靈活度不夠的問題。RBAC會是下面這個樣子。

(用戶-角色-權限)

小路可以是管理員,也可以是組長,然后小路具有管理員和組長的所有權限。如果小路離職了的話,索大可以和管理員進行綁定,再和組長綁定。這時候角色和權限的關系是不需要改變的。

RBAC還有很多的變體,比如互斥角色、比如角色具有上下級關系,可以參考《RBAC權限系統分析、設計與實現》這個博客。

我們看看釘釘的實現方式。

(釘釘子管理員列表頁面)

(釘釘子管理員編輯頁面)

(釘釘子管理員添加人員頁面)

這是釘釘后臺的管理系統,在子管理員頁面里會有添加管理組,添加管理組人員,設定管理組的管理員,設置權限等。管理組會有一些默認的管理組,也可以由用戶新增。操作順序可以是:

(釘釘子管理員頁面流程)

釘釘產品已經非常龐大了,作為一個平臺產品,這邊的權限主要是針對不同應用的訪問和使用。釘釘的管理組就像一個角色,而成員就代表著用戶,最后為角色配置權限。引入角色對用戶和權限進行解耦的好處是,任何員工的離職入職,都不會影響到角色和權限直接的關系。而管理要做的,只是把人丟到對應的管理組即可。

釘釘對于這部分的管理是一步到位的,完成了用戶-角色-權限的配置。如果想要條理更清晰一些,可以先完成角色和權限的映射配置,再往角色里添加人員就可以了。

除了用戶- 角色- 權限這種形式,還可能出現更為復雜的問題。

比如權限的沖突,小路有兩個角色,一個角色是管理員,一個角色是組長,組長有開除員工的權限,管理員沒有開除員工的權限,那么小路最后應不應該有開除員工的權限?

這里可以考慮給角色加上優先級,出現沖突了以優先級高的角色所對應的權限為主。

再比如,角色組的問題。一個角色可以對應分配權限,而由角色構成的集合應該也可以被分配權限。如下圖:

(用戶-角色-權限,用戶-角色組-權限)

舉個例子:

  • 用戶:小路、小山、索大
  • 角色:項目經理、前端工程師、產品經理
  • 角色組:釘釘項目組
  • 權限:項目進度管理、項目組聊天窗、產品原型設計、產品開發

釘釘項目組作為角色組,可以由項目經理、前端工程師、產品經理這幾個角色組成,角色組有自己的權限,角色也有自己的權限,用戶還是和角色綁定,用在角色組里會有角色組的對應的權限,也會有角色對應的權限。

這里基于用戶-角色-權限這個父類可以派生出很多子類。這部分角色沒有處理好的話,很可能會影響到第二部分說的工作流,釘釘在這里設計的相對完善。

02?工作流,BPM(Business Process Management)

工作流也可以劃分為五個階段,分別是:

  • 業務流程發掘(Business Process Discovery)
  • 業務流程設計(Business Process Design)
  • 業務流程執行(Business Process Execution)
  • 業務流程管理維護(Business Process Administration)
  • 業務流程最優化(Business Process Optimization)

我們產品里常用到的是申請和審批,屬于業務流程的設計。

工作流里所涉及到的角色有:申請發起人、審批人、抄送人、執行人。

根據業務情況還會涉及到條件分支,比如報銷金額超過100W,需要總經理批,低于1000元,上級領導批就可以;請假時間超過30天需要人力主管批,低于3天直線主管批就可以等等。

我們看一下釘釘的工作流。釘釘的工作流是通過可視化編程做的,其實和之前說的低代碼屬于同一類產品,釘釘的工作流設計和低代碼平臺氚云、明道云等等非常像。對于釘釘布局低代碼也可以從這看到必然。

(釘釘工作流頁面)

(釘釘工作流添加節點頁面)

我們以釘釘的請假審批為例,可以看到釘釘的請假工作流是包含分支節點的,能夠進行申請條件的判斷。這個流程應該是基于activity的框架進行完善的。這里面會有一張請假表單按照設定好的工作流進行流轉,涉及到表單引擎部分的內容我們這邊不拓展。我們重點關注流程設計。

釘釘的設計,是可以動態添加審批、抄送、執行、分支節點的。這個按字面意思大家應該能理解。其實我想說的是,在設計流程的時候有一個非常重要的原則。就是流程的復用性。

來看一個問題。

比如,小路是研發部一部的員工,小山是研發部二部的員工,索大是研發部三部的員工,三個部門是平行部門,他們各自領導不一樣。那么小路,小山,索大三個人的請假流程應該怎么設計?

這里會用到我們說的流程復用性的原則,三個人部門平行,即使三個人領導不同,審批他們的人不同,但是三個人應該是共享一套流程的??赡苁牵喊l起人—>直線領導—>HR—>結束。所以在流程設計的時候要想實現流程的復用,其實并不是一件簡單的事情。

釘釘給出的設計思路其實是比較接地氣也能解決問題的,大家也可以對比看看企業微信,兩家產品在審批人選擇這部分交互是比較類似。我們具體來看一下。

  • 指定人員:指定具體的人,釘釘限制了20個人。這部分要慎用,一旦流程指定到具體的人,一個是復用性變差,第二是一旦有人離職,容易造成流程的崩潰。
  • 發起人自選:在發起人提交申請時,自行選擇一個人批復。這種情況很適用于請假半天,需要有人知道就好的情況,不是很重要的申請可以這么設計。
  • 連續多級主管:這個功能比較好用,也可以直觀理解。小路是一個研發工程師,小山是下路領導,索大是小山領導。當選擇多級主管的時候,級數選擇2,那么下路的申請會順著report line一直到索大那邊。
  • 部門主管:指定某個部門的領導,比如請假要指定到HR主管,報銷要指定到財務主管。
  • 直屬主管:指定到個人的直接上級。
  • 表單內部門控件對應主管,表單內部門控件對應角色:這里我放在一起說,這部分功能是比較處理復雜情況的時候需要用的,比如表單內部門控件對應角色,小路是研發部一部的部長,小山是研發部的前端工程師,索大是研發部產品經理。但是部門有一個助理角色,幫助部長處理事務的,這個助理不是崗位,是角色。索大是研發部一部的助理。所以當要指定到角色的時候,就可以通過表單內部門空間對應角色指定到一個虛擬的角色,而不是實際的崗位。這邊比較繞,而且沒有特別好的描述。所以我說釘釘這塊比較接地氣,但是很能解決一些實際需求。
  • 角色:虛擬設置的角色,供指定,指定角色的好處,和前文說的RBCA是一樣的,角色是一個抽象,可以帶來更好的拓展性和靈活性。
  • 發起人自己:這個沒什么好說的,可能表單流轉過程會有某個時刻需要流回自己手里。
  • 表單內的聯系人:這個也是一個靈活性比較高的功能,是指表單內有控件出現了聯系人,在這個位置可以選為當前節點的執行人。

這一塊對比下來,釘釘思考的情況比較全面,所以這部分內容對于需要設計流程的B端產品來說,是非常好的學習案例。

自己做了一些流程的工作,這里說說感受。

因為要把定義流程的工作交給用戶,那么用戶可能會設計出現各種奇奇怪怪的業務流程,而B端產品要能支持這些流程,一定是要有非常高的靈活度和非常極致的抽象。

所以這部分內容其實考驗產品經理的三個能力:對于業務需求的抽象能力、對于產品落地交互的具象能力,以及咨詢里說的MECE熟練度。而市面上做的好的產品是提供了落地實現的,這也是能節約我們大量時間的環節。

啰嗦一句,就是借鑒的過程,需要弄清原產品背后的邏輯。比如釘釘里的選擇人員,為什么要給這么多選項,我們自己的產品需不需要這么多選項?這些都是要自己思考清楚的。

03?權限系統和工作流存在要素重疊

把權限系統和工作流放在一起寫,是因為二者會有一些重疊關系。認真看文章的小伙伴應該發現了,角色這個詞是貫穿這兩部分的。我們看看如果一個B端產品,需要從0到1設計這兩部分會是怎樣?

(權限系統-工作流的設計流程)

我們創建的角色,可以作為權限系統里去分配權限,也可以在工作流里作為審批的執行人。角色本質是一層抽象,抽象的好處就在于能夠解耦用戶和權限,解耦用戶和審批人。抽象會帶來更多的復用性。

04?最后

B端產品在設計權限和工作流的時候,非常建議大家去看看釘釘、企微這些OA系統。審視OA產品,會發現OA系統對于權限,角色,工作流,玩的很明白,是非常好的學習方向。

飛書的審批功能目前看起來比企微和釘釘的審批要弱化一些,這和產品定位也有一些關系,飛書強在效率提升,釘釘強在辦公管理,企微強在關系鏈接,產品的基因會決定產品功能。

但是相信有釘釘、企微的先行探索,飛書也是能快速趕上的,畢竟存在后發優勢。

現在SaaS是一個很火的領域,C端產品從0到1的設計產品的機會越來越稀少,SaaS的產品經理會有更多機會能夠從0到1設計產品。在這個過程中,工作流和權限系統幾乎不可或缺。

大家之后工作中,可以借鑒這些做的比較成功的產品,看看這些甚至連間接競品都算不上的產品,學習他們的強勢,發揮自己的后發優勢,節約時間去更快的迭代產品。

#專欄作家#

忙里偷賢,公眾號:忙里偷賢,人人都是產品經理專欄作家。B端產品,低代碼玩家,工具類產品思考者。熱愛分享,務實的理想主義者。

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

題圖來自 Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!