為什麼寫這篇文章？

寫這篇文章的目的有兩個：一個原因是，由於最近將近兩年都在接觸大型的系統，我有幸作為一個軟體實施方的一員，接觸並瞭解了幾個大型的專案，並自己也主導設計了一款軟體系統，我對於軟體的後臺設計有了一定程度的瞭解，有能力闡述清楚這個問題。另外一個原因是，曾經我作為一個軟體小白，想要在網上找到相應的資料，發現，大部分的文章都來自與開發人員，他們偏向於從技術層面進行闡述，讀起來晦澀難懂，很少從業務和原理上進行闡述，還有一部分文章闡述的層面較為淺顯，淺嘗輒止，並沒有從整體到部分進行完整的闡述，我這篇文章力求簡單明瞭，完整全面，任何人都通俗易懂。

系統後臺一般包括哪些內容，有什麼用處？

系統後臺一般是管理者進行系統管理的一個模組。根據軟體的不同用途，其管理的內容各不相同。舉個簡單的例子：今日頭條、騰訊視訊、頭條號等內容平臺，一般其後臺都會有內容稽核功能，使用者賬號管理、許可權分配等等。使用者釋出一篇文章，後臺進行稽核，通過後，方可進行展示。

我今天所闡述的系統後臺，指的是更為核心的東西，是一個系統的心臟。指的是許可權資料管理，這一個部分的設計最為複雜也是系統設計最難最基礎的部門。

許可權包括兩個部分：一個是操作許可權，一個是資料許可權。

操作許可權又包括兩個部分：一個是選單許可權，另外一個是按鈕許可權。

選單許可權。舉個例子來說：我們使用同一個辦公軟體系統，你是HR，你有招聘模組的選單，可以進行招聘相關的操作，我是財務，我有費用報銷模組的選單，而你沒有。這樣我們的選單是不一定的。我們都可以使用辦公軟體，但是我們的職位不同，所以分配的選單是不一樣的。

按鈕許可權。舉個例子：我們兩個都是人資部門的人，你是招聘專員，我是人資經理。我們雖然都有招聘選單，但是你沒有招聘需求審批的按鈕，你沒有相應的許可權操作，只有我可以進行招聘需求的審批。

資料許可權，說起來就比較簡單容易理解了，比如拿快消行業來說，我是上海區的省區經理，你是江蘇大區的省區經理，我們職位相同，我們都是省區經理，我們擁有的操作許可權也是一樣的，但是我們看到的資料是不一樣的，我是上海地區的經理，只能允許看到上海的銷售資料，江蘇地區的銷售資料我是看不到的，同理，江蘇區的省區經理也是一樣的。所有這些，都是可以通過資料許可權進行控制的。

怎麼進行許可權的控制？

我主要介紹一種常見的許可權控制方法，也是比較常用的許可權設計方式，這種是對小型或大型企業都非常適用。我們是以企業的角度設計這款系統的，所以在設計之初就有許多“不確定的因素”，我在這裡就一一介紹一下。

自上而下設計模式

這種模式貫徹了系統許可權管理，我們將企業分為公司—部門—崗位—角色—使用者，分層管理逐級降低，使許可權管理條理清晰。​

​

當公司—部門—崗位—角色—使用者都設定好了我們就可以設定許可權了，我們主要是在角色—使用者設定了功能許可權—資料許可權。

角色—功能許可權—資料許可權

他的設計原理是：把操作許可權分配給角色，這樣新增一個新的角色以後，就會給這個新增的角色分配相應的操作許可權，包括操作按鈕和操作選單。資料許可權也細分開來，不同角色崗位有獨立資料庫也可以共享資料。

功能授權

​

​

資料授權

​

​

使用者—功能許可權—資料許可權

使用者和角色的許可權的差不多，只是增加更多的功能對使用者的控制。

​

​

有人覺得公司—部門—崗位有什麼用呢？我在這裡解釋一下，公司和部門是必需的，我們為企業長久發展設計了總公司及子公司，方便企業的管理。部門可以看做一個個類群，對使用者使用者進行分類管理。這崗位就涉及到了工作流引擎和流程引擎。​

​

這種許可權設計方案適用於OA、ERP、MIS、CRM、電商平臺等系統，他可以根據企業的規模進行調整，幫助企業在任何時候都有一個舒適的管理環境。

這樣設計有什麼好處呢？

舉個例子說吧：當一個員工離職了，只需要停用該員工的使用者賬號，把職位移除，如果新來一個員工替代他，只需要給新員工新建一個使用者賬號，同時把使用者匯入角色就OK了，不需要重新分配資料許可權和操作許可權。

再舉個例子吧：當兩個員工A和B進行跨部門職位調崗時，該怎麼操作呢？先把A和B的部門調換，然後把他們所在的崗位中移除了，再分配的其他崗位上，在使用者介面重新分配資料庫。

如果有考慮有工作流的情況，就需要考慮流程節點處理物件，可以按照工作流崗位、角色和具體使用者三個維度進行配置，流程可以設定成整個企業也可以具體到某個角色。

此外，對於，有相應人員編制的企業來說，可以保證職位的固定，只會有使用者的增減，職位可以始終保持不變，這樣編制就得以控制了。