一、問題的提出
對一套企業管理軟體系統從軟體人員調研、設計到交付用戶使用一個主要環節是：管理軟體所具有的針對用戶處理業務操作模塊劃分；系統如何進行管理與維護。這就軟體管理設計中的“用戶”、“角色”、“權限”，即系統所具有的用戶有哪些；每個用戶所扮演什么角色；不同角色所具有的管理權限，這三個概念（“用戶”、“角色”、“權限”）及相互關聯關系在許多檔案資料敘述甚多，軟體研發人員在整個設計程序中無不關注，每個管理軟體系統的使用者也在關注“我以什么角色身份”登錄系統；我的角色身份登錄后可以在管理軟體中操作哪些具體業務。這是一個問題所對應來源于兩個方面的關注。
如何把可以操作的各類業務（包含系統管理、維護）模塊授權與可以登錄的操作人員（角色劃分及角色所獲取的權限）軟體開發人員一般是依據用戶需求而確定，即：用戶提出“根據業務性質劃分確定角色”、“針對各類角色予以授權操作”。早期（上世紀70、80年代）的企業管理軟體一般對可以使用“操作權限”設定方法，即一個單獨的“人員操作權限”模塊授權于登錄系統人員可以使用的模塊。
RBAC（Role-Based Access Control，基于角色的訪問控制）是現在軟體設計者普遍采用的角色劃分及角色所具有權限分配方法。這種方法的基本思路是：一個可以登錄系統的用戶→確定該用戶所扮演的角色→該角色對管理系統所具有的操作權限，這是一種三層架構的設計模式，由以下三個方面關聯構成。
1、登錄用戶
具體登錄管理軟體的操作人員。
2、用戶角色
登錄操作人員所扮演角色，諸如：“系統管理”、“賬務管理”、“庫房管理”等等。
3、角色具有權限
不同用戶即便其角色一樣，其操作權限也可能不盡相同。例如同樣是“庫房管理”角色，有的角色具有“材料采購訂單管理”、“材料入庫制單”權限，某些角色切具有“材料入庫制單”權限。
其實際基礎業務環節有多少就應該有多少種權限可以對各類角色進行授權
以資料庫管理系統為例，需要建立“登錄用戶（人員）”、“角色劃分”、“登錄用戶角色分配、授權”三個資料表進行管理，形成一（個用戶）對多（角色、權限）的資料關系。
如何劃分登錄用戶→用戶所扮演角色→具體用戶角色的權限分配是管理軟體開發人員所關注、探討的一個問題，因為它關聯牽扯到企業管理框架（管理體制【企業負責制】、企業部門劃分乃至職責范圍及權限范圍）
這種三層架構的設計方法存在如下弊端：
1、交付企業用戶使用不是一目了然，操作比較麻煩
2、管理體制變更后原有用戶、角色、權限需要重新定義分配
3、企業下屬部門重新設定后某些操作頁面程式對面需要重新撰寫
4、系統維護作業量相應增加
如下兩個框架圖形，是一個典型的RBAC設計框架從設計思路到資料表關聯程序，其繁瑣的操作頁面、操作程序不具有一定邏輯思維的人比較難以掌握。
A、圍繞組織架構設計管理圖
圖1-1 圍繞企業組織架構邏輯框架
軟體設計和用戶關注的組織框架包含：企業管理體制、管理權限劃分、各個管理人員的角色、每種管理角色所具有的操作權限。
B、資料表關聯圖
軟體開發設計人員從圖1-1中歸納為資料表的描述有：“用戶表”、“角色表”、“權限表”而后關聯出“用戶角色”表與“角色權限”表，如圖1-2.
圖1-2 用戶、角色及權限資料關系
上述處理關聯著企業的企業框架中的職能結構、層次結構、部門結構、職權結構這四種結構，無論結構中任何一個發生變化，僅僅靠上述處理難以湊效。大家熟知“財務科（部）”、“供應科（部）”等部門一般企業均應設定，但機構精簡后可以把這兩個部室合并為一個后，原有的“財務科（部）”、“供應科（部）”不復存在，那么原有的用戶、角色將也隨之消失不可再用，原有系統操作模塊都得重新改寫維護，其作業量可想而知。
隨著大資料時代的到來，企業管理資訊的重要性已經被人們所重視，管理中的資料資訊不在僅僅是算算賬、出幾張報表的事情，而是及時精準、最小化的基礎資料資訊，為提供各個管理層面的管理人員提供真實可信決策資訊依據。
譬如：如下如何企業、（行政、事業）部門都所使用到的“賬務管理”軟體系統，這里歸納出客戶需求的業務模塊將達到上百個之多（包含系統管理維護），如圖1-3。
賬務管理常用功能模塊
圖1-3 賬務管理部分功能模塊
如果按照“RBAC”處理方法即便假定企業管理框架不發生變化也是麻煩之事。圍繞賬務管理中描述資料最小屬性的“編碼”管理就包括18個編碼型別類。不可能“編碼管理”作為一個型別的角色，因為它涉及到不同的管理層面；試想如果把其中任意組合的“編碼”作為一個角色，這種組合有多少種，你可以用組合公式計算一下。
二、業務物件層面階梯化、最小化
上述的圖RBAC（Role-Based Access Control）角色劃分權限設定是建立職能結構、層次結構、部門結構、職權結構這四種結構之上，即與企業的管理層次、部門結構、管理者的管轄范圍權限相關，不同的職能、層次、企業部門設定、權限劃分管理軟體的總體框架結構勢必不同，一旦某個層面發生改變系統框架、資料框架、軟體代碼也將隨之發生改變。這種RBAC方法使得軟體的生命周期并不十分長久，軟體的維護成本與企業所負擔的成本勢必大大增加。
怎么辦呢？我們不妨這樣去考慮。在任何一個企業（可以包括政府部門、事業單位）無論其職能結構、層次結構、部門結構、職權結構如何劃分，但需要處理的作業物件業務是一致的，所得到的管理結果目標完全相同。譬如財務賬務管理、庫房材料管理，這些作業業務任何企業都會有人去做，至于它由誰去做不應該受到企業是否部門結構的限制，即便沒有財務管理部門或材料管理部門，企業總的有人去管理賬務，總的去管理庫房材料，只要安排勝任此項業務人員去做就可以。
圖1-3 賬務管理功能模塊以表格形式給出了業務物件層面階梯化、最小化的設計思路基礎，描述了把所需處理的賬務管理業務階梯化（層次化），把每一項要處理的業務最小化。譬如“編碼管理”下屬的18種型別編碼“記賬科目”、“部門編碼”等編碼是編碼管理中的最小化業務層面；“記賬憑證”下屬的“憑證制證”、“記賬憑證審核”、“憑證登賬”、“憑證查詢”等是“憑證管理”業務中的最小化業務層面。這里“編碼管理”、“憑證管理”作為管理層面的父節點，而下屬具體業務則為這些父節點下屬的子節點。
軟體開發人員在調研中的一個主要任務就是把需求客戶的每一個業務層面（管理什么，如何管理、管理程序、管理方法）完全清楚，而不是就事論事，由業務層面的“父”節點逐步確定下屬“子”節點，這就是這里提出來的“業務物件層面階梯化、最小化”最終歸結為如圖1-3的線性發生描述方式，隨著這種描述的產生管理軟體框架也就成型，也為登錄界面的樹形結構和模塊設計奠定基礎。
這里最小層面的作業業務是構成軟體框架內的一個具體操作頁面。至于頁面布置、頁面上各種功能需求（按鈕或選單）代碼就是程式代碼撰寫人員的主要作業。
三、業務物件授權于登錄用戶的具體操作人員
1、基本思想
A、至下向上歸納法
先確定最基礎全部業務子節點→逐級歸納各個子節點歸屬的父節點。
譬如：在賬務管理先把應該有哪些最小（不能再往下細分）需要管理的作業業務并予以冠名，“憑證錄入”、“憑證審核”、“憑證登賬”、“憑證查詢”、“科目明細賬”、“現金日記賬”、“銀行日記賬”、“科目編碼”、“部門編碼”、“產品商品編碼”等等屬于最基礎的業務作業層面，有了這些基礎業務層面，而后逐級向上確定它們各自所屬的上級父節點（某級父節點還可能具有上級父節點）。
B、由上向下歸納法
從大類業務環節開始確定各個業務管理環節（父節點）→把各個基礎業務層面的子節點歸類于相應的父節點。
譬如：在賬務管理中首先從大的業務環節層面認定要做哪些管理業務（父節點），而后逐級鄉下歸納屬于某父節點之內的業務管理環節，圖1-3中的“賬務基礎”、“產品商品銷售”、“資金控制”都屬于一級父節點，在這些節點下確認下屬包含業務層面的子節點，直到每個子節點最小化。
圖2-1 賬務基礎業務環節層次結構
無論是至下向上還是由上向下歸納都會歸納、抽象出類如圖1-3的“業務物件層面階梯化、最小化”管理模塊結構圖。
2、模塊、用戶、操作授權資料及資料關系
一個管理系統所應具有的逐級管理模塊已然確定，那么這些模塊如何讓可以登錄系統人員進入實施他們具體的操作，這是人們關注的事情。這里給出記錄這三個資訊的資料表，“模塊表”記錄如圖1-3的全部資料記錄；“用戶表”記錄可以登錄管理系統的全部操作人員（包含系統管理員）；“操作授權表”記錄“用戶表”內人員已經授權的“模塊表”中區域資料記錄，這里需要指出，最基礎子節點具有N個，只要授權其中之一那么上級父節點也一并授權，目的在于滿足操作界面完整的樹形結構顯示。圖2-2通過“操作人員表”與“模塊表”的關聯確定了“操作人員表”的資料記錄。
圖2-2 操作權限表關聯獲取
這一設計思路具有如下優點：
A、和圖1-2（用戶、角色及權限資料關系）比較由五個資料表表的關聯簡化成為三個資料表，簡化后的管理方法便于理解；
B、減少了程式代碼撰寫；
C、“業務模塊”便于添加、修改、洗掉而不影響原有管理系統的整體代碼；
D、突破了制約于“企業管理體制”的框架思路，即不受你的企業管理權限如何分配，也不受你的企業行政管理體系如何更變。
四、管理實體
以前述的“賬務管理”為實體，下面敘述如何實作“業務物件層面階梯化、最小化”設計企業管理系統。
1、假定
假定已經考慮到的各個層面的管理模塊已經保存在“模塊編碼表”內；已經建立了“操作人員（登錄用戶）資料表”，該表至少具有一條具有系統管理權的操作人員，其登錄特征為賬戶序號=0，人員序號=0；已經建立了“操作授權表”（如圖2-1），且已經具有了系統管理人員的權限記錄；已經建立了一套具有獨立管理的“賬務管理”賬戶。
2、操作人員授權管理
A、系統操作人員登錄
對可以登錄“賬務管理”賬戶的每一操作人員，他們可以哪些頁面，做些什么業務處理必須由“系統管理人員”完成。在操作界面圖4-1下登錄后予以授權
圖4-1 賬務管理操作人員登錄
以賬務人員登錄后頁面中以樹形選單顯示了“系統管理人員”所具有的操作頁面。如圖4-2
圖4-2 系統管理人員具有的操作樹形選單
B、操作人員授權
在圖4-2操作選單下點擊“人員操作授權”后進入如圖4-3的授權頁面。
圖4-3 人員授權管理頁面
在授權頁面下在全部操作模塊串列中的選擇框予以選擇，以決定某操作人員的操作模塊，這些模塊既是操作人員的處理業務。
在圖4-3中顯示了被授權人的“登錄賬戶序號”及“登錄人員序號”，授權后告知相應人員，該操作人員就可以以這個“登錄特征”在圖4-1的登錄頁面下登錄。
C、已經授權的操作人員登錄
“登錄賬戶序號”=4、“登錄人員序號”=5登錄后所具有的操作樹形選單如圖4-4.
圖4-2 具有賬務處理基礎操作人員登錄后的樹形選單
在圖4-2的樹形選單下給這里出了“賬務基礎”的全部業務模塊，但并非對每一個涉及“賬務基礎”的操作人員對這些模塊全部授權，在圖4-3人員授權管理頁面下可以有選擇的進行授權，可以是一種業務模塊，也可以是任意業務模塊的各種組合。對已經授權的業務作業模塊還可以重新授權，予以取消或增補新的授權。
僅僅從登錄操作人員登錄后他們可以做什么，這里給出的思路、方法與前述的“RBAC（Role-Based Access Control）角色劃分權限”從頁面管理、具體操作要簡化明了了許多，
本文給出了C/S（客戶服務器管理方式）下的的處理方式，實事上流行的B/S（瀏覽器管理方式）也完全的可行，只要改變一下瀏覽器具體頁面的布置就完全可以。其授權所管理的資料表，具體的關聯方式的程式流程、代碼基本一致。
uj5u.com熱心網友回復：
我想說 我們系統涉及到權限有角色，崗位，用戶這三個詞，想想也是醉醉的。uj5u.com熱心網友回復：
我做個測驗
uj5u.com熱心網友回復：
你可以到這看
uj5u.com熱心網友回復：
搞半天是來打廣告的？ 表示看到這么長的帖 就沒想看下去的欲望
uj5u.com熱心網友回復：
講的不錯，路過有識訓uj5u.com熱心網友回復：
看到這個登錄界面，我就覺得可以放棄了。uj5u.com熱心網友回復：
說了半天，其實就是從資料表為主的設計，改為操作選單為主的設計。其實還遠遠不夠！
uj5u.com熱心網友回復：
我來戳破一下這種傳統的垃圾泡沫：首先，假設以 lz 說認為很不好的那種設計方法，它是針對靜態資料表的。它明顯是說某些人、某些角色，對某些資料表有增刪改查權限。這樣就很難應用到實際流程中，因為實際管理流程往往需要在不斷地進行管理方式探索和調整中去改變各個作業節點對資料的查詢修改方式，管理是高級的——而資料表是低級的，其實不是因為程式員設計了資料表所以管理者才知道怎樣管理，相反地100資料表往往并不對應著20個管理流程中的100個管理界面，也就是資料表跟管理流程細節存在著嚴重的“阻抗不對稱”性，會產生嚴重的分歧。
那么 lz 于是歸結為選單權限，歸結為一個人有沒有權限打開某種界面的做法上。這其實是一種簡化，如果是為了揚棄上面的錯誤的做法，那么完全可以理解。但是這肯定是極端簡化的情況。因為很簡單，比如說要處理用戶報修任務，那么系統就根據保修的內容將下一級任務派發給完全不同的單位的人員了，然后不同的單位有不同的處理流程，比如說是負責電的部門跟負責水管的部門的人處理報修的流程就不同，進一步地任何一個作業深入了之后其涉及到的人、物、“資料”都跟流程走、而不是跟這人或者部門走。
lz 所做出的考慮，本質上還是資料的靜態思維方式，也就是認為給某些角色的人賦予某種資料或者程式界面的進入權限就萬事大吉了。而真正的企業管理軟體應該是按照流程走的，比如說我把某個申請書給了一個銀行專管員，那么這個銀行人員就能看到我的詳細資料，然后按照內部流程走下去、隨后的銀行其它人員能夠看我的詳細資料的一部分。而負責其它十幾億人的申請書的銀行人員，只要他沒有參與我的申請流程，就不可能看到我的資料的任何一部分。這個時候如果你糾結某種資料表應該被某些人你隨便查看和修改、或者某種操作模塊應該被某些人隨便查看和使用，那么是不是就太 low 了呢？
uj5u.com熱心網友回復：
這還有一個重要的原因，就是很多資訊系統里邊的資料庫資料，其實都是比較原始的查詢資訊，也就是讓企業（不管多大）雇傭幾個錄入人員錄入的檔案資訊。以這種思維方式設計的軟體，必定就是簡單的增刪該查思維方式。而管理作業流系統就好是軟體資訊的版本管理系統一樣，或者說好像是區塊鏈的基礎版本系統一樣，資料是行為日志，資料決不允許“刪改”，只允許“增查”。當你有這樣的資料結構，再來看管理軟體中的“權限控制”，你就非常簡單和直觀了，每一個人只看自己的行為歷史就行了。一個領導假設需要看報表，那么她發起一個任務，讓系統給她自己發來一份報告，那么這個報告是她自己的私有的一條資料，而不是什么別人的資料被她看到。
uj5u.com熱心網友回復：
lz 所說“不可能“編碼管理”作為一個型別的角色，因為它涉及到不同的管理層面；試想如果把其中任意組合的“編碼”作為一個角色，這種組合有......”這就是把角色看成了資料表（或者說是資料表中的分類Class欄位）的查詢約束了！這就是翻來覆去都是對靜態資料庫表（或者是表中的某一個分類欄位）查詢約束的思路，永遠跳不出這個思路！這就是傳統的資料庫表設計模式跟管理資訊系統的多變（每一個企業都不太一樣）的阻抗不匹配性的最主要原因！企業管理流程經常變化，那么開發管理資訊系統的根本核心是從資料庫表出發還是從管理流程出發？
管理流程變化中，往往是某個環節的某個表單就是要去綜合訪問許多表的個別欄位，也許某個表單今天不需要訪問庫存表、而明天就需要訪問庫存表的50個欄位中的5個欄位。那么你說某用戶、或者某雷用戶到底有沒有訪問庫存表的權限？或者訪問庫存表中某類編碼的庫存的權限？
這純粹是坑爹的——但是卻是很多人樂此不疲地——權限管理思維方式。他是從資料表出發，而不是從管理流程出發。如果從管理流程出發那么權限即使定義到了“每一個記錄 and 每一個欄位”這一級別，也還是不行，因為還是有時間因素、歷史因素，例如一個權限其實是從一個流程的發起人開始、中間每一個審批或者填寫的程序都會改變隨后的流程表現，而這就直接決定了隨后的資料的權限。所以“每一個記錄 and 沒一個欄位”其實權限都取決于每一個創建它的流程的整個歷史鏈條的共同作用，而不是什么靜態地寫死、預先規定誰能訪問某類資料！
uj5u.com熱心網友回復：
總是能看到一個吹逼的 用嘴打破傳統 卻不給出一個立新的東西這樣的人
都是
流氓
uj5u.com熱心網友回復：
“部門”跟“角色”這兩個概念看似重疊，但在一般的軟體系統里“部門”屬于雇員管理模塊，“角色”屬于權限管理模塊。uj5u.com熱心網友回復：
百度一下 SAP 的PFCG 就好了轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/10325.html
標籤：企業信息化