編輯導(dǎo)讀：權(quán)限系統(tǒng)可以從字面上理解，賦予不同用戶不同的權(quán)限，比如管理員可以增刪賬戶，普通員工只能讀寫數(shù)據(jù)。本文作者以釘釘為例，拆解權(quán)限系統(tǒng)和工作流，希望對你有幫助。

在B端產(chǎn)品從0到1設(shè)計的過程中，有一些基礎(chǔ)內(nèi)容是繞不開的，比如人員系統(tǒng)、賬號系統(tǒng)、權(quán)限系統(tǒng)、工作流系統(tǒng)等等。但是這些系統(tǒng)也相對成熟，可以玩出花的地方也不多，對于這部分我們倒可以占據(jù)后發(fā)優(yōu)勢，去學(xué)習行業(yè)內(nèi)的產(chǎn)品是怎么做的。

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

01 權(quán)限系統(tǒng)，RBAC（Role-Based Access Control）

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

（用戶-權(quán)限）

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

（用戶-角色-權(quán)限）

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

RBAC還有很多的變體，比如互斥角色、比如角色具有上下級關(guān)系，可以參考《RBAC權(quán)限系統(tǒng)分析、設(shè)計與實現(xiàn)》這個博客。

我們看看釘釘?shù)膶崿F(xiàn)方式。

（釘釘子管理員列表頁面）

（釘釘子管理員編輯頁面）

（釘釘子管理員添加人員頁面）

這是釘釘后臺的管理系統(tǒng)，在子管理員頁面里會有添加管理組，添加管理組人員，設(shè)定管理組的管理員，設(shè)置權(quán)限等。管理組會有一些默認的管理組，也可以由用戶新增。操作順序可以是：

（釘釘子管理員頁面流程）

釘釘產(chǎn)品已經(jīng)非常龐大了，作為一個平臺產(chǎn)品，這邊的權(quán)限主要是針對不同應(yīng)用的訪問和使用。釘釘?shù)墓芾斫M就像一個角色，而成員就代表著用戶，最后為角色配置權(quán)限。引入角色對用戶和權(quán)限進行解耦的好處是，任何員工的離職入職，都不會影響到角色和權(quán)限直接的關(guān)系。而管理要做的，只是把人丟到對應(yīng)的管理組即可。

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

除了用戶- 角色- 權(quán)限這種形式，還可能出現(xiàn)更為復(fù)雜的問題。

比如權(quán)限的沖突，小路有兩個角色，一個角色是管理員，一個角色是組長，組長有開除員工的權(quán)限，管理員沒有開除員工的權(quán)限，那么小路最后應(yīng)不應(yīng)該有開除員工的權(quán)限？

這里可以考慮給角色加上優(yōu)先級，出現(xiàn)沖突了以優(yōu)先級高的角色所對應(yīng)的權(quán)限為主。

再比如，角色組的問題。一個角色可以對應(yīng)分配權(quán)限，而由角色構(gòu)成的集合應(yīng)該也可以被分配權(quán)限。如下圖：

（用戶-角色-權(quán)限，用戶-角色組-權(quán)限）

舉個例子：

• 用戶：小路、小山、索大
• 角色：項目經(jīng)理、前端工程師、產(chǎn)品經(jīng)理
• 角色組：釘釘項目組
• 權(quán)限：項目進度管理、項目組聊天窗、產(chǎn)品原型設(shè)計、產(chǎn)品開發(fā)

釘釘項目組作為角色組，可以由項目經(jīng)理、前端工程師、產(chǎn)品經(jīng)理這幾個角色組成，角色組有自己的權(quán)限，角色也有自己的權(quán)限，用戶還是和角色綁定，用在角色組里會有角色組的對應(yīng)的權(quán)限，也會有角色對應(yīng)的權(quán)限。

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

02 工作流，BPM（Business Process Management）

工作流也可以劃分為五個階段，分別是：

• 業(yè)務(wù)流程發(fā)掘（Business Process Discovery）
• 業(yè)務(wù)流程設(shè)計（Business Process Design）
• 業(yè)務(wù)流程執(zhí)行（Business Process Execution）
• 業(yè)務(wù)流程管理維護(Business Process Administration)
• 業(yè)務(wù)流程最優(yōu)化（Business Process Optimization）

我們產(chǎn)品里常用到的是申請和審批，屬于業(yè)務(wù)流程的設(shè)計。

工作流里所涉及到的角色有：申請發(fā)起人、審批人、抄送人、執(zhí)行人。

根據(jù)業(yè)務(wù)情況還會涉及到條件分支，比如報銷金額超過100W，需要總經(jīng)理批，低于1000元，上級領(lǐng)導(dǎo)批就可以；請假時間超過30天需要人力主管批，低于3天直線主管批就可以等等。

我們看一下釘釘?shù)墓ぷ髁鳌ａ斸數(shù)墓ぷ髁魇峭ㄟ^可視化編程做的，其實和之前說的低代碼屬于同一類產(chǎn)品，釘釘?shù)墓ぷ髁髟O(shè)計和低代碼平臺氚云、明道云等等非常像。對于釘釘布局低代碼也可以從這看到必然。

（釘釘工作流頁面）

（釘釘工作流添加節(jié)點頁面）

我們以釘釘?shù)恼埣賹徟鸀槔?，可以看到釘釘?shù)恼埣俟ぷ髁魇前种Ч?jié)點的，能夠進行申請條件的判斷。這個流程應(yīng)該是基于activity的框架進行完善的。這里面會有一張請假表單按照設(shè)定好的工作流進行流轉(zhuǎn)，涉及到表單引擎部分的內(nèi)容我們這邊不拓展。我們重點關(guān)注流程設(shè)計。

釘釘?shù)脑O(shè)計，是可以動態(tài)添加審批、抄送、執(zhí)行、分支節(jié)點的。這個按字面意思大家應(yīng)該能理解。其實我想說的是，在設(shè)計流程的時候有一個非常重要的原則。就是流程的復(fù)用性。

來看一個問題。

比如，小路是研發(fā)部一部的員工，小山是研發(fā)部二部的員工，索大是研發(fā)部三部的員工，三個部門是平行部門，他們各自領(lǐng)導(dǎo)不一樣。那么小路，小山，索大三個人的請假流程應(yīng)該怎么設(shè)計?

這里會用到我們說的流程復(fù)用性的原則，三個人部門平行，即使三個人領(lǐng)導(dǎo)不同，審批他們的人不同，但是三個人應(yīng)該是共享一套流程的?？赡苁牵喊l(fā)起人—>直線領(lǐng)導(dǎo)—>HR—>結(jié)束。所以在流程設(shè)計的時候要想實現(xiàn)流程的復(fù)用，其實并不是一件簡單的事情。

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

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

這一塊對比下來，釘釘思考的情況比較全面，所以這部分內(nèi)容對于需要設(shè)計流程的B端產(chǎn)品來說，是非常好的學(xué)習案例。

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

因為要把定義流程的工作交給用戶，那么用戶可能會設(shè)計出現(xiàn)各種奇奇怪怪的業(yè)務(wù)流程，而B端產(chǎn)品要能支持這些流程，一定是要有非常高的靈活度和非常極致的抽象。

所以這部分內(nèi)容其實考驗產(chǎn)品經(jīng)理的三個能力：對于業(yè)務(wù)需求的抽象能力、對于產(chǎn)品落地交互的具象能力，以及咨詢里說的MECE熟練度。而市面上做的好的產(chǎn)品是提供了落地實現(xiàn)的，這也是能節(jié)約我們大量時間的環(huán)節(jié)。

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

03 權(quán)限系統(tǒng)和工作流存在要素重疊

把權(quán)限系統(tǒng)和工作流放在一起寫，是因為二者會有一些重疊關(guān)系。認真看文章的小伙伴應(yīng)該發(fā)現(xiàn)了，角色這個詞是貫穿這兩部分的。我們看看如果一個B端產(chǎn)品，需要從0到1設(shè)計這兩部分會是怎樣？

（權(quán)限系統(tǒng)-工作流的設(shè)計流程）

我們創(chuàng)建的角色，可以作為權(quán)限系統(tǒng)里去分配權(quán)限，也可以在工作流里作為審批的執(zhí)行人。角色本質(zhì)是一層抽象，抽象的好處就在于能夠解耦用戶和權(quán)限，解耦用戶和審批人。抽象會帶來更多的復(fù)用性。

04 最后

B端產(chǎn)品在設(shè)計權(quán)限和工作流的時候，非常建議大家去看看釘釘、企微這些OA系統(tǒng)。審視OA產(chǎn)品，會發(fā)現(xiàn)OA系統(tǒng)對于權(quán)限，角色，工作流，玩的很明白，是非常好的學(xué)習方向。

飛書的審批功能目前看起來比企微和釘釘?shù)膶徟趸恍?，這和產(chǎn)品定位也有一些關(guān)系，飛書強在效率提升，釘釘強在辦公管理，企微強在關(guān)系鏈接，產(chǎn)品的基因會決定產(chǎn)品功能。

但是相信有釘釘、企微的先行探索，飛書也是能快速趕上的，畢竟存在后發(fā)優(yōu)勢。

現(xiàn)在SaaS是一個很火的領(lǐng)域，C端產(chǎn)品從0到1的設(shè)計產(chǎn)品的機會越來越稀少，SaaS的產(chǎn)品經(jīng)理會有更多機會能夠從0到1設(shè)計產(chǎn)品。在這個過程中，工作流和權(quán)限系統(tǒng)幾乎不可或缺。

大家之后工作中，可以借鑒這些做的比較成功的產(chǎn)品，看看這些甚至連間接競品都算不上的產(chǎn)品，學(xué)習他們的強勢，發(fā)揮自己的后發(fā)優(yōu)勢，節(jié)約時間去更快的迭代產(chǎn)品。

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

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