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

在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的框架進行完善的。這裡面會有一張請假表單按照設定好的工作流進行流轉，涉及到表單引擎部分的内容我們這邊不拓展。我們重點關注流程設計。

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

來看一個問題。

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

這裡會用到我們說的流程複用性的原則，三個人部門平行，即使三個人領導不同，審批他們的人不同，但是三個人應該是共享一套流程的。可能是：發起人—>直線領導—>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設計産品。在這個過程中，工作流和權限系統幾乎不可或缺。

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

本文由 @忙裡偷賢 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部