基于表單字段的工作流審批節(jié)點設置審批角色的方法與流程

本發(fā)明涉及一種epr等管理軟件系統(tǒng)的工作流中審批節(jié)點審批角色的設置和管理方法，特別是涉及一種基于表單字段的工作流審批節(jié)點設置審批角色的方法。

背景技術：

基于角色的訪問控制（rbac）是近年來研究最多、思想最成熟的一種數據庫權限管理機制，它被認為是替代傳統(tǒng)的強制訪問控制（mac）和自主訪問控制（dac）的理想候選。傳統(tǒng)的自主訪問控制的靈活性高但是安全性低，強制訪問控制安全性高但是限制太強；基于角色的訪問控制兩者兼具，不僅易于管理而且降低了復雜性、成本和發(fā)生錯誤的概率，因而近年來得到了極大的發(fā)展?；诮巧脑L問控制（rbac）的基本思想是根據企業(yè)組織視圖中不同的職能崗位劃分不同的角色，將數據庫資源的訪問權限封裝在角色中，用戶通過被賦予不同的角色來間接訪問數據庫資源。

在大型應用系統(tǒng)中往往都建有大量的表和視圖，這使得對數據庫資源的管理和授權變得十分復雜。由用戶直接管理數據庫資源的存取和權限的收授是十分困難的，它需要用戶對數據庫結構的了解非常透徹，并且熟悉sql語言的使用，而且一旦應用系統(tǒng)結構或安全需求有所變動，都要進行大量復雜而繁瑣的授權變動，非常容易出現一些意想不到的授權失誤而引起的安全漏洞。因此，為大型應用系統(tǒng)設計一種簡單、高效的權限管理方法已成為系統(tǒng)和系統(tǒng)用戶的普遍需求。

基于角色的權限控制機制能夠對系統(tǒng)的訪問權限進行簡單、高效的管理，極大地降低了系統(tǒng)權限管理的負擔和代價，而且使得系統(tǒng)權限管理更加符合應用系統(tǒng)的業(yè)務管理規(guī)范。

然而，傳統(tǒng)基于角色的用戶權限管理和工作流控制方法均采用“角色對用戶一對多”的關聯(lián)機制，其“角色”為組/類性質，即一個角色可以同時對應/關聯(lián)多個用戶，角色類似于崗位/職位/工種等概念，這種關聯(lián)機制下對用戶權限的授權基本分為以下三種形式：

1、如圖1所示，直接對用戶授權，缺點是工作量大、操作頻繁且麻煩；審批流程中審批節(jié)點的審批操作主體是用戶，工作流審批節(jié)點直接選擇員工/用戶作為審批主體，當發(fā)生員工變動（如調崗、離職等），該員工涉及到的所有流程必須要作相應調整，特別是對于公司管理人員，其涉及到的審批流程多，流程調整的工作量大、繁雜，容易出錯或遺漏，影響企業(yè)的正常運營，甚至造成不可預估的損失。

即使只是員工審批權限發(fā)生變化，也需要對該員工涉及到的流程作出相應調整，也存在以上類似問題。

2、如圖2所示，對角色（類/組/崗位/工種性質）進行授權（一個角色可以關聯(lián)多個用戶），用戶通過角色獲得權限，審批操作主體是組/類性質角色；

3、如圖3所示，以上兩種方式結合。

以上的表述中，2、3均需要對類/組性質的角色進行授權，而通過類/組/崗位/工種性質的角色進行授權和工作流控制的方式有以下缺點：

1、用戶權限變化時的操作難：在實際的系統(tǒng)使用過程中，經常因為在運營過程中需要對用戶的權限進行調整，比如：在處理員工權限變化時，角色關聯(lián)的某個員工權限發(fā)生變化，我們不能因該個別員工權限的變化而改變整個角色的權限，因為該角色還關聯(lián)了其他權限未變的員工。因此為了應對該種情況，要么創(chuàng)建新角色來滿足該權限發(fā)生變化的員工，要么對該員工根據權限需求直接授權（脫離角色）。以上兩種處理方式，在角色權限較多的情況下對角色授權不僅所需時間長，而且容易犯錯，使用方操作起來繁瑣又麻煩，也容易出錯導致對系統(tǒng)使用方的損失。

員工/用戶的審批權限發(fā)生變化時，要么員工/用戶脫離角色，工作流審批節(jié)點直接選擇員工/用戶作為審批主體，要么新增角色來滿足審批流程的要求。第一種方式，當發(fā)生員工變動（如調崗、離職等），該員工涉及到的所有流程必須要作相應調整，特別是對于公司管理人員，其涉及到的審批流程多，流程調整的工作量大、繁雜，容易出錯或遺漏，影響企業(yè)的正常運營，甚至造成不可預估的損失。即使只是員工審批權限發(fā)生變化，也需要對該員工涉及到的流程作出相應調整，也存在以上類似問題。第二種方式，新增角色便涉及到角色的新建、關聯(lián)、授權工作，特別在角色多、角色關聯(lián)的用戶也多的情況下，角色具體關聯(lián)了哪些用戶是很難記住的。

2、要長期記住角色包含的具體權限難：若角色的權限功能點比較多，時間一長，很難記住角色的具體權限，更難記住權限相近的角色之間的權限差別，相近角色的權限也很容易混淆；若要關聯(lián)新的用戶，無法準確判斷應當如何選擇關聯(lián)。

3、因為用戶權限變化，則會造成角色創(chuàng)建越來越多（若不創(chuàng)建新角色，則會大幅增加直接對用戶的授權），更難分清各角色權限的具體差別。

4、調崗時，若要將被調崗用戶的很多個權限分配給另外幾個用戶承擔，則處理時必須將被調崗用戶的這些權限區(qū)分開來，分別再創(chuàng)建角色來關聯(lián)另外幾個用戶，這樣的操作不僅復雜耗時，而且還很容易發(fā)生錯誤。

傳統(tǒng)系統(tǒng)的工作流審批機制存在以下缺陷：

（1）審批節(jié)點中無法選擇流程發(fā)起人自身作為審批人員，在審批流程結束之前，審批流程的發(fā)起人無法復核確認其提交的申請的審批結果，例如：發(fā)起人發(fā)起了一個10000元的報銷審批請求，因發(fā)起人提交的內容有誤或其他原因，經過多級審批后核準報銷金額被修改為500元，最終的審批結果只允許報銷500元，審批流程結束。發(fā)起人收到審批結果后有異議的話，必須將之前的審批流程結果作廢，再重新提交一個審批申請，增加了系統(tǒng)內耗，降低了審批效率。

（2）對于組織結構比較復雜的跨省、跨國集團公司等，涉及到的審批流程數量非常多，審批流程流轉條件和流轉線路也很復雜，對于系統(tǒng)流程設置人員來說，工作量非常大，而且很容易在設置審批流程時出錯，系統(tǒng)使用很不方便、系統(tǒng)可靠性不高。

（3）在按級別設置審批時，系統(tǒng)無法實現對最高級部門主管所提交的審批請求的審批，一般需要單獨為最高級部門主管分配專門的審批角色，增加了系統(tǒng)工作流設置人員的工作量。

（4）只能以審批流程提交角色作為判斷標準來判斷部門級別，無法自定義以表單中涉及到的其它角色或部門作為判斷部門級別的標準，存在一定的使用局限性。

舉例：對于一個合同審批流程，合同的簽訂角色請假了，讓其同事替他發(fā)起了一個合同的審批，而系統(tǒng)認定其同事為流程的提交角色，在按級別審批時對于級別的判斷均以其同事為準，無法客觀體現合同簽訂角色所在的部門及職位。例如，合同的簽訂角色為市場部的銷售人員1，其同事角色為研發(fā)部的研發(fā)人員1，原本該合同應由簽訂角色所在部門的主管-市場部主管角色審批，設置審批節(jié)點的審批級別為1時，系統(tǒng)會分配給研發(fā)人員1所在部門的主管-研發(fā)部主管角色進行審批，出現了審批流程的分配錯誤，使用不方便。

技術實現要素：

本發(fā)明的目的在于克服現有技術的不足，提供一種基于表單字段的工作流審批節(jié)點設置審批角色的方法，根據需要自定義以表單中涉及到的角色性質字段、部門性質字段或提交角色作為判斷部門級別的標準，以此確定審批角色，使用更靈活、方便。

本發(fā)明的目的是通過以下技術方案來實現的：包括一個設置系統(tǒng)組織結構的步驟和一個按部門級別設置審批角色的步驟：

所述設置系統(tǒng)組織結構的步驟包括以下子步驟：

ss1：創(chuàng)建系統(tǒng)組織結構中所包含的部門及角色，并設置各部門之間的層級關系；

ss2：設置各部門的部門主管角色；

所述按部門級別設置審批角色的步驟包括：

sss1:選擇以按級別方式進行審批角色的設置；

sss2:選擇審批流程對應表單中的角色性質字段、部門性質字段或者該審批流程的提交角色中的一個，作為級別主體；

sss3:填寫具體的級別數值n，n為≥0的正整數：

（1）選擇審批流程對應表單中的角色性質字段作為級別主體，以該字段對應的角色為判斷標準判斷級別：

①當n=0時，由該字段對應的角色擔任該審批節(jié)點的審批角色；

②當n=1時，由該字段對應的角色所在部門的部門主管角色擔任該審批節(jié)點的審批角色；若該字段對應的角色為其所在部門的部門主管角色，則由該字段對應的角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

③當n=2時，由該字段對應的角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

④當n=3時，由該字段對應的角色所在部門的上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑤當n=4時，由該字段對應的角色所在部門的上上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑥以此類推；

⑦當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；

（2）選擇審批流程對應表單中的部門性質字段作為級別主體，以該字段對應的部門為判斷標準判斷級別：

①當n=0時，由該字段對應的部門的部門主管角色擔任該審批節(jié)點的審批角色；

②當n=1時，由該字段對應的部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

③當n=2時，由該字段對應的部門的上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

④當n=3時，由該字段對應的部門的上上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑤以此類推；

⑥當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；

（3）選擇審批流程的提交角色作為級別主體，以該提交角色為判斷標準判斷級別：

①當n=0時，由工作流審批流程提交角色擔任該審批節(jié)點的審批角色；

②當n=1時，由工作流審批流程提交角色所在部門的部門主管角色擔任該審批節(jié)點的審批角色；若提交角色為其所在部門的部門主管角色，則由提交角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

③當n=2時，由工作流審批流程提交角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

④當n=3時，由工作流審批流程提交角色所在部門的上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑤當n=4時，由工作流審批流程提交角色所在部門的上上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑥以此類推；

⑦當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色。

當審批節(jié)點選擇的是級別審批時，對級別中對應的審批角色進行審批權限授權，則此級別中對應的審批角色的審批權限都相同。

所述表單中的角色性質字段、部門性質字段為必填單選項。

所述工作流的控制方法包括以下步驟：

s1：構建用戶-角色-權限的三層結構模型，其中：

角色層：工作流中流程發(fā)起及審批的操作主體為角色，每個角色是獨立的個體，而非組/類，同一時段一個角色只能關聯(lián)唯一的用戶，而一個用戶關聯(lián)一個或多個角色；

權限層：由工作流執(zhí)行中所需要使用的權限構成，權限直接授權給角色；

用戶層：用戶通過關聯(lián)的角色確定工作流中的審批任務，并以關聯(lián)角色的權限進行審批操作；

s2：利用三層結構模型對工作流進行控制，一個審批流程中包括一個開始節(jié)點、至少一個審批節(jié)點、一個結束節(jié)點：

開始節(jié)點：提交角色發(fā)起/申請/提交工作流，有工作流發(fā)起權限的角色才能作為提交角色發(fā)起/申請/提交工作流；系統(tǒng)根據提交角色所提交的表單確定審批流程，針對需要有工作流的表單設計一個或多個審批流程，但一個角色只能選擇該表單下的某一個審批流程；

審批節(jié)點：設置審批的部門的級別，并對級別中對應的審批角色進行審批權限授權；

結束節(jié)點：流程流轉到此節(jié)點后，表示該審批流程審批結束；

s3：用戶根據其關聯(lián)的角色確定所需處理的審批任務，并根據關聯(lián)的角色的權限進行審批操作。

在審批節(jié)點選擇一個或多個審批角色，一個角色在同一個審批流程中能夠存在于不同審批節(jié)點，在審批節(jié)點設置審批角色的權限，針對每個審批節(jié)點的審批角色能夠進行獨立的權限設置，不同審批節(jié)點中該審批角色對此表單字段的查看、修改權限可不同。

所述的步驟s1包括以下步驟：

（1）創(chuàng)建角色，每個角色是獨立的個體，而非組/類；

（2）對步驟（1）所創(chuàng)建的角色分別進行授權；

（3）將用戶關聯(lián)到角色，其中，同一時段一個角色只能關聯(lián)唯一的用戶，而一個用戶關聯(lián)一個或多個角色。

所述的角色創(chuàng)建時必須選擇一個部門，角色一旦創(chuàng)建后則該角色歸屬于該部門，且該角色名在該部門下唯一，角色編號在系統(tǒng)中唯一；

用戶跨部門調崗管理具體步驟：

（1）取消用戶與原部門內的角色的關聯(lián)；

（2）將用戶與新部門內的角色進行關聯(lián)。

所述的用戶能且只能通過其與角色的關聯(lián)確定權限，一個員工對應一個用戶賬號，一個用戶賬號對應一個員工。

所述角色的構成為：崗位名+崗內編號。

基于表單字段的工作流審批節(jié)點設置審批角色的方法，包括一個設置系統(tǒng)組織結構的步驟和一個按部門級別設置審批角色的步驟：

所述設置系統(tǒng)組織結構的步驟包括以下子步驟：

ss1：創(chuàng)建系統(tǒng)組織結構中所包含的部門及角色，并設置各部門之間的層級關系；

ss2：設置各部門的部門主管角色；

所述按部門級別設置審批角色的步驟包括：

sss1:選擇以按級別方式進行審批角色的設置；

sss2:選擇審批流程對應表單中的角色性質字段、部門性質字段或者該審批流程的提交角色中的一個，作為級別主體；

sss3:填寫具體的級別數值n，n為≥0的正整數：

（1）選擇審批流程對應表單中的角色性質字段作為級別主體，以該字段對應的角色為判斷標準判斷級別：

①當n=0時，由該字段對應的角色擔任該審批節(jié)點的審批角色；

②當n=1時，由該字段對應的角色所在部門的部門主管角色擔任該審批節(jié)點的審批角色；若該字段對應的角色為其所在部門的部門主管角色，則由該字段對應的角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

③當n=2時，由該字段對應的角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

④當n=3時，由該字段對應的角色所在部門的上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑤當n=4時，由該字段對應的角色所在部門的上上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑥以此類推；

⑦當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑧當n≥1時，需要設置“該字段對應的角色為其所在部門的部門主管角色，且該部門無上一級部門時”該審批節(jié)點由指定組審批；

（2）選擇審批流程對應表單中的部門性質字段作為級別主體，以該字段對應的部門為判斷標準判斷級別：

①當n=0時，由該字段對應的部門的部門主管角色擔任該審批節(jié)點的審批角色；

②當n=1時，由該字段對應的部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

③當n=2時，由該字段對應的部門的上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

④當n=3時，由該字段對應的部門的上上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑤以此類推；

⑥當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑦當n≥1時，需要設置“該字段對應的部門無上一級部門時”該審批節(jié)點由指定組審批；

（3）選擇審批流程的提交角色作為級別主體，以該提交角色為判斷標準判斷級別：

①當n=0時，由工作流審批流程提交角色擔任該審批節(jié)點的審批角色；

②當n=1時，由工作流審批流程提交角色所在部門的部門主管角色擔任該審批節(jié)點的審批角色；若提交角色為其所在部門的部門主管角色，則由提交角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

③當n=2時，由工作流審批流程提交角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

④當n=3時，由工作流審批流程提交角色所在部門的上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑤當n=4時，由工作流審批流程提交角色所在部門的上上上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑥以此類推；

⑦當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；

⑧當n≥1時，需要設置“提交角色為其所在部門的部門主管角色，且該部門無上一級部門時”該審批節(jié)點由指定組審批；

所述指定組審批包括以下三種情況中的一種：

（1）指定組由一個或多個審批角色構成；

（2）指定組由部門級別確定，選擇級別主體時只能沿用該審批節(jié)點所選擇的級別主體，且級別數值n只能設置為0；

（3）指定組由部門級別確定，級別主體能夠自主選擇，指定組中包括一個或多個指定節(jié)點，當指定節(jié)點的級別數值n為非0時必須設置下一級指定節(jié)點，直到指定節(jié)點的級別數值n為0時，該審批節(jié)點的指定組設置完成。

本發(fā)明的有益效果是：

（1）傳統(tǒng)級別審批方式只能以審批流程提交角色作為判斷標準來判斷部門級別，無法自定義以表單中涉及到的其它角色或部門作為判斷部門級別的標準，存在一定的使用局限性。

舉例：對于一個合同審批流程，合同的簽訂角色請假了，讓其同事替他發(fā)起了一個合同的審批，而系統(tǒng)認定其同事為流程的提交角色，在按級別審批時對于級別的判斷均以其同事為準，無法客觀體現合同簽訂角色所在的部門及職位。例如，合同的簽訂角色為市場部的銷售人員1，其同事角色為研發(fā)部的研發(fā)人員1，原本該合同應由簽訂角色所在部門的主管-市場部主管角色審批，設置審批節(jié)點的審批級別為1時，系統(tǒng)會分配給研發(fā)人員1所在部門的主管-研發(fā)部主管角色進行審批，出現了審批流程的分配錯誤，使用不方便。

本申請可根據需要自定義以表單中涉及到的角色性質字段、部門性質字段或提交角色作為判斷部門級別的標準，例如，在設置審批節(jié)點時，可以選擇合同表單中的簽訂角色作為級別主體，以簽訂角色（而非一味默認為提交角色）作為標準判斷部門級別，以此確定審批角色為市場部主管角色，使用更靈活、方便，通用性強。

（2）系統(tǒng)提供了最高級別部門主管的審批機制，避免出現最高級別部門主管無法通過級別審批方式完成審批流程的問題。

舉例：企業(yè)的最高級領導董事長提交審批請求時，在級別審批中，董事長雖沒有上級部門，系統(tǒng)設置指定組來審批董事長提交的審批請求。

指定組審批包括以下三種情況中的一種：

①指定組由一個或多個審批角色構成，例如，由多個監(jiān)事會的成員構成指定組，董事長的審批請求由監(jiān)事會成員進行審批；

②指定組由部門級別確定，選擇級別主體時只能沿用該審批節(jié)點所選擇的級別主體，且級別數值n只能設置為0；此種情況用于應對企業(yè)組織結構發(fā)生變化的情況，例如，某公司原最高級別主管為總經理，而組織結構變化后增設了董事會，最高級別主管變?yōu)槎麻L，審批節(jié)點中級別數值為0則審批角色自動變?yōu)槎麻L，而不是固定為總經理，避免出現審批角色不能適配組織結構變化的問題；

③指定組由部門級別確定，級別主體能夠自主選擇，指定組中包括一個或多個指定節(jié)點，當指定節(jié)點的級別數值n為非0時必須設置下一級指定節(jié)點，直到指定節(jié)點的級別數值n為0時，該審批節(jié)點的指定組設置完成；此種情況適用于普通部門角色審批最高級部門主管所提交的審批請求，例如，財務部門的財務主管可以審核董事長所提交的合同審批請求中涉及的開票信息，最終要由董事長確認。

（3）審批節(jié)點在設置審批角色時部門級別n可以設置為0，即選擇提交角色本身作為審批節(jié)點中的審批角色，在審批流程結束前，可以由提交角色本身進行審批確認，選擇不同意后可返回重新審批，選擇同意進入下一環(huán)節(jié)，多出了提交角色復核程序，避免出現審批結果不正確或審批結果與提交角色的預期不符而需要新建審批流程的問題，減少了系統(tǒng)內耗，提高了審批流程效率和可靠性。

舉例：提交角色提交了一個10000元的報銷審批請求，因提交角色所提交的內容有誤或其他原因，經過多級審批后核準報銷金額被修改為500元，在審批流程結束之前，由提交角色作為審批角色進行復核確認即可發(fā)現問題，選擇不同意后可返回重新審批，選擇同意進入下一環(huán)節(jié)，無需新建一個審批流程。

（4）通過按部門級別設置審批角色的方式，系統(tǒng)工作流設置人員在設置審批角色時只需選擇級別主體并輸入級別數值即可，多個審批流程能夠有效整合在一個審批流程內，能夠有效減少流轉條件和流轉線路，降低了系統(tǒng)工作流設置人員的工作量，提高了系統(tǒng)可靠性。

（5）工作流中審批操作的主體是角色，而且這個角色是獨立的個體而不是傳統(tǒng)組/類性質的角色，即使發(fā)生員工/用戶變動（如調崗、離職等），或者是員工審批權限發(fā)生變化，只需將員工重新關聯(lián)到新角色，或是針對性調整該角色審批權限即可，無需重新設置/調整流程，設置方便，不會出錯或遺漏，不會影響企業(yè)的正常運營，極大提高了工作流的可靠性。以崗位號性質的角色為審批環(huán)節(jié)節(jié)點的審批授權主體，用戶通過角色確定其有哪些審批任務，用戶通過關聯(lián)角色的權限進行審批操作即可；理解清晰簡單，每個崗位號/工位號性質的角色是工作主體的最小單位，針對每個角色對審批的不同需求，本申請均能夠很好滿足。

（6）本申請角色對用戶是一對一的關系，同一時段一個角色只能關聯(lián)唯一的用戶，這樣做的好處是，在每次創(chuàng)建用戶時都不再需要進行分配權限的操作，只要將用戶關聯(lián)到角色即可，而且角色的權限變更比傳統(tǒng)機制中的用戶權限變更要少得多。獨立體性質（崗位號/工位號性質）的角色數量變化小，雖然員工流動大，但崗位號/工位號的變化?。ㄉ踔猎谝欢〞r段內是沒有變化的，即角色沒有變化），這樣將極大簡化用戶的權限管理，減少系統(tǒng)的開銷。

（7）動態(tài)管理、入職調崗等的操作簡單方便，效率高，可靠性高：入職/離職/調崗在審批流程中的應用簡單，工作流程的發(fā)起及審批的操作主體是角色，當員工/用戶發(fā)生變化時不用重新設置審批流程（用戶只需取消或關聯(lián)角色即可：不再任職該崗位號/工位號的角色的用戶就取消該角色關聯(lián)，接手任職該崗位號/工位號的角色的用戶關聯(lián)該崗位號的角色，則關聯(lián)該角色的用戶自動就獲得了該角色在審批工作流中的相關任務和權限，無需對審批工作流進行重新設置或對工作流中的角色進行重新授權，極大地提高了流程設置的效率、安全性和可靠性。

舉例：因張三用戶離職或調崗等原因，張三不再做“采購員3”這個角色的工作，則張三取消了與該角色的關聯(lián)；另外李四接手做“采購員3”這個角色的工作，則將李四關聯(lián)該角色，則李四自動獲得了審批流程中“采購員3”這個角色的審批任務和審批權限。

（8）傳統(tǒng)的權限管理機制將角色定義為組、工種、類等性質，角色對用戶是一對多的關系，在實際的系統(tǒng)使用過程中，經常因為在運營過程中需要對用戶的權限進行調整，比如：在處理員工權限變化的時候，角色關聯(lián)的某個員工的權限發(fā)生變化，我們不能因該個別員工權限的變化而改變整個角色的權限，因為該角色還關聯(lián)了其他權限未變的員工。因此為了應對該種情況，要么創(chuàng)建新角色來滿足該權限發(fā)生變化的員工，要么對該員工根據權限需求直接授權（脫離角色）。以上兩種處理方式，在角色權限較多的情況下對角色授權不僅所需時間長，而且容易犯錯，使用方操作起來繁瑣又麻煩，也容易出錯導致對系統(tǒng)使用方的損失。

但在本申請的方法下，因為角色是一個獨立的個體，則可以選擇改變角色權限即可達到目的。本申請的方法，雖然看起來在系統(tǒng)初始化時會增加工作量，但可以通過復制等方法，使其創(chuàng)建角色或授權的效率高于傳統(tǒng)以組為性質的角色，因為不用考慮性質為組的角色在滿足關聯(lián)用戶時的共通性，本申請方案會讓權限設置清晰，明了；尤其是在系統(tǒng)使用一段時間后（用戶/角色權限動態(tài)變化），該申請方案能為系統(tǒng)使用方大幅度提高系統(tǒng)使用中的權限管理效率，使動態(tài)授權更簡單，更方便，更清晰、明了，提高權限設置的效率和可靠性。

（9）傳統(tǒng)以組為性質的角色授權方法容易出錯，本申請方法大幅降低了授權出錯的幾率，因為本申請方法只需考慮作為獨立個體的角色，而不用考慮傳統(tǒng)方法下關聯(lián)該組性質角色的多個用戶有哪些共通性。即使授權出錯也只影響關聯(lián)到該角色的那一個用戶，而傳統(tǒng)以組性質的角色則會影響關聯(lián)到該角色的所有用戶。即使出現權限授權錯誤，本申請的修正方法簡單、時間短，而傳統(tǒng)以組性質的角色在修正錯誤時需要考慮關聯(lián)到該角色的所有用戶的權限共通性，在功能點多的情況下不僅修改麻煩、復雜，非常容易出錯，且很多情況下只能新創(chuàng)建角色才能解決。

（10）在傳統(tǒng)以組為性質的角色授權方法下，若角色的權限功能點比較多，時間一長，很難記住角色的具體權限，更難記住權限相近的角色之間的權限差別，若要關聯(lián)新的用戶，無法準確判斷應當如何選擇關聯(lián)。本申請方法的角色本身就具有崗位號/工位號的性質，選擇一目了然。

（11）調崗時，若要將被調崗用戶的很多個權限分配給另外幾個用戶承擔，則處理時必須將被調崗用戶的這些權限區(qū)分開來，分別再創(chuàng)建角色來關聯(lián)另外幾個用戶，這樣的操作不僅復雜耗時，而且還很容易發(fā)生錯誤。

本申請方法則為：被調崗用戶關聯(lián)了幾個角色，在調崗時，首先取消用戶與原部門內的角色的關聯(lián)（被取消的這幾個角色可以被重新關聯(lián)給其他用戶），然后將用戶與新部門內的角色進行關聯(lián)即可。操作簡單，不會出錯。

（12）創(chuàng)建角色時，需要選定一個部門，一旦該角色創(chuàng)建完成，則部門不能被更換，角色為什么不能更換部門：

理由1：因為本申請的角色性質等同于一個工位號/崗位號，不同的工位號/崗位號的工作內容/權限是不一樣的，如銷售部門下的銷售員1角色和技術部門的開發(fā)人員1角色是完全不同的兩個工位號/崗位號，其權限是不同的；

理由2：若將銷售員1角色的所屬部門（銷售部）更換為技術部，其銷售人員1這個角色的權限不變，則在技術部存在擁有銷售部權限的一個角色，這樣會導致管理混亂及安全漏洞。

（13）一個角色在同一個審批流程中能夠存在于不同審批節(jié)點，針對每個審批節(jié)點的審批角色能夠進行獨立的權限設置，不同審批節(jié)點中該審批角色對此表單字段的查看、修改權限可不同。優(yōu)勢舉例：某角色為成都銷售經理3，在合同審批工作流中，其存在于成都銷售合同審批和上海銷售合同審批兩個審批節(jié)點；對于成都的銷售合同，在審批時該角色可查看該合同的客戶名稱、聯(lián)系人、聯(lián)系方式、產品數量、產品單價、合同金額等全部字段內容，且可修改產品單價、合同金額；但在審批上海銷售合同時卻無法查看客戶名稱、聯(lián)系人、聯(lián)系方式等敏感字段內容，更不能作任何修改。這樣一來，能夠自定義地設置角色在審批流程中的權限。

附圖說明

圖1為背景技術中系統(tǒng)直接對用戶進行授權的方式示意圖；

圖2為背景技術中系統(tǒng)對組/類性質角色進行授權的方式示意圖；

圖3為背景技術中系統(tǒng)對用戶直接授權和對組/類性質角色授權相結合的方式示意圖；

圖4為實施例中系統(tǒng)組織結構樹狀圖；

圖5為本發(fā)明工作流控制方法流程圖；

圖6為本發(fā)明系統(tǒng)通過獨立個體性質角色對用戶進行授權的方式示意圖；

圖7為本發(fā)明工作流審批流程示意圖；

圖8為本發(fā)明用戶-角色授權方法流程圖。

具體實施方式

下面結合附圖進一步詳細描述本發(fā)明的技術方案，但本發(fā)明的保護范圍不局限于以下所述。

【實施例1】基于表單字段的工作流審批節(jié)點設置審批角色的方法，包括一個設置系統(tǒng)組織結構的步驟和一個按部門級別設置審批角色的步驟：

所述設置系統(tǒng)組織結構的步驟包括以下子步驟：

ss1：創(chuàng)建系統(tǒng)組織結構中所包含的部門及角色，并設置各部門之間的層級關系，如圖4所示，部門a比部門b高一級，部門a比部門c高兩級……；

ss2：設置各部門的部門主管角色；

所述按部門級別設置審批角色的步驟包括：

sss1:選擇以按級別方式進行審批角色的設置；

sss2:選擇審批流程對應表單中的角色性質字段、部門性質字段或者該審批流程的提交角色中的一個，作為級別主體；選擇級別主體時，能且只能選擇一個；

表單上可以有多個角色性質、部門性質的字段（如簽訂角色、負責角色、簽訂部門、負責部門等），但一個流程只有一個流程提交角色；

sss3:填寫具體的級別數值n，n為≥0的正整數：

（1）選擇審批流程對應表單中的角色性質字段作為級別主體，以該字段對應的角色為判斷標準判斷級別，例如，流程的提交角色為d2，但選擇的表單中的角色性質字段為簽訂角色，該簽訂角色為角色d3：

①當n=0時，由選定的角色d3擔任該審批節(jié)點的審批角色；

②當n=1時，由選定的角色d3所在部門d的部門主管角色d1擔任該審批節(jié)點的審批角色；若選定的角色為其所在部門的部門主管角色，則由選定的角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

③當n=2時，由選定的角色d3所在部門d的上一級部門c的部門主管角色c1擔任該審批節(jié)點的審批角色；

④當n=3時，由選定的角色d3所在部門d的上上一級部門b的部門主管角色b1擔任該審批節(jié)點的審批角色；

⑤當n=4時，由選定的角色d3所在部門d的上上上一級部門a的部門主管角色a1擔任該審批節(jié)點的審批角色；

⑥以此類推；

⑦當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；例如：對于角色d3而言，部門級別最高應為4，當部門級別設置為6時，由最高級別部門a的部門主管角色a1擔任該審批節(jié)點的審批角色。

（2）選擇審批流程對應表單中的部門性質字段作為級別主體，以該選定的部門為判斷標準判斷級別，例如，選擇的表單中的部門性質字段為簽訂部門，該簽訂部門為部門d：

①當n=0時，由選定部門d的部門主管角色d1擔任該審批節(jié)點的審批角色；

②當n=1時，由選定部門d的上一級部門c的部門主管角色c1擔任該審批節(jié)點的審批角色；

③當n=2時，由選定部門d的上上一級部門b的部門主管角色b1擔任該審批節(jié)點的審批角色；

④當n=3時，由選定部門d的上上上一級部門a的部門主管角色a1擔任該審批節(jié)點的審批角色；

⑤以此類推；

⑥當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；例如：對于部門d而言，部門級別最高應為3，當部門級別設置為6時，由最高級別部門a的部門主管角色a1擔任該審批節(jié)點的審批角色。

（3）選擇審批流程的提交角色作為級別主體，以該提交角色為判斷標準判斷級別，例如，若提交角色為角色d2，則：

①當n=0時，由工作流審批流程提交角色d2擔任該審批節(jié)點的審批角色；

審批節(jié)點在設置審批角色時部門級別n可以設置為0，即選擇提交角色d2本身作為審批節(jié)點中的審批角色，在審批流程結束前，可以由提交角色d2本身進行審批確認，選擇不同意后可返回重新審批，選擇同意進入下一環(huán)節(jié)，多出了提交角色復核程序，避免出現審批結果不正確或審批結果與提交角色的預期不符而需要新建審批流程的問題，減少了系統(tǒng)內耗，提高了審批流程效率和可靠性。

舉例：提交角色d2提交了一個10000元的報銷審批請求，因提交角色d2所提交的內容有誤或其他原因，經過多級審批后核準報銷金額被修改為500元，在審批流程結束之前，由提交角色d2作為審批角色進行復核確認即可發(fā)現問題，選擇不同意后可返回重新審批，選擇同意進入下一環(huán)節(jié)，無需新建一個審批流程。

②當n=1時，由工作流審批流程提交角色d2所在部門d的部門主管角色d1擔任該審批節(jié)點的審批角色；（若提交角色是d1，他是其所在部門d的部門主管角色，則由提交角色所在部門d的上一級部門c的部門主管角色c1擔任該審批節(jié)點的審批角色）

③當n=2時，由工作流審批流程提交角色d2所在部門d的上一級部門c的部門主管角色c1擔任該審批節(jié)點的審批角色；

④當n=3時，由工作流審批流程提交角色d2所在部門d的上上一級部門b的部門主管角色b1擔任該審批節(jié)點的審批角色；

⑤當n=4時，由工作流審批流程提交角色d2所在部門d的上上上一級部門a的部門主管角色a1擔任該審批節(jié)點的審批角色；

⑥以此類推；

⑦當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色。例如：對于角色d2而言，部門級別最高應為4，當部門級別設置為6時，由最高級別部門a的部門主管角色a1擔任該審批節(jié)點的審批角色。

本申請方案在原基于提交角色級別授權方式的優(yōu)勢基礎上，還有另一優(yōu)勢：可以選擇不同性質的角色，如合同表單上有合同簽訂角色、合同新增角色、合同負責角色，該審批節(jié)點本來不應該以提交角色判定級別，而應以合同簽訂角色判斷級別。比如，報銷表單的第一個審批節(jié)點要以提交角色的上級，另外的一個審批節(jié)點要以報銷角色的上級審批（報銷角色和提交角色可能是不同的角色）。

傳統(tǒng)級別審批方式只能以審批流程提交角色作為判斷標準來判斷部門級別，無法自定義以表單中涉及到的其它角色或部門作為判斷部門級別的標準，存在一定的使用局限性。

舉例：對于一個合同審批流程，合同的簽訂角色請假了，讓其同事替他發(fā)起了一個合同的審批，而系統(tǒng)認定其同事為流程的提交角色，在按級別審批時對于級別的判斷均以其同事為準，無法客觀體現合同簽訂角色所在的部門及職位。例如，合同的簽訂角色為市場部的銷售人員1，其同事角色為研發(fā)部的研發(fā)人員1，原本該合同應由簽訂角色所在部門的主管-市場部主管角色審批，設置審批節(jié)點的審批級別為1時，系統(tǒng)會分配給研發(fā)人員1所在部門的主管-研發(fā)部主管角色進行審批，出現了審批流程的分配錯誤，使用不方便。

本申請在設置審批節(jié)點時，可以根據需要選擇合同表單中的簽訂角色作為級別主體，以簽訂角色（而非一味默認為提交角色）作為標準判斷部門級別，以此確定審批角色為市場部主管角色，使用更靈活、方便，通用性強。

【實施例2】基于表單字段的工作流審批節(jié)點設置審批角色的方法，包括一個設置系統(tǒng)組織結構的步驟和一個按部門級別設置審批角色的步驟：

所述設置系統(tǒng)組織結構的步驟包括以下子步驟：

ss1：創(chuàng)建系統(tǒng)組織結構中所包含的部門及角色，并設置各部門之間的層級關系，如圖4所示，部門a比部門b高一級，部門a比部門c高兩級……；

ss2：設置各部門的部門主管角色；

所述按部門級別設置審批角色的步驟包括：

sss1:選擇以按級別方式進行審批角色的設置；

sss2:選擇審批流程對應表單中的角色性質字段、部門性質字段或者該審批流程的提交角色中的一個，作為級別主體；

sss3:填寫具體的級別數值n，n為≥0的正整數：

（1）選擇審批流程對應表單中的角色性質字段作為級別主體，以該選定的角色為判斷標準判斷級別，例如，流程的提交角色為d2，但選擇的表單中的角色性質字段為簽訂角色，該簽訂角色為角色d3：

①當n=0時，由選定的角色d3擔任該審批節(jié)點的審批角色；

②當n=1時，由選定的角色d3所在部門d的部門主管角色d1擔任該審批節(jié)點的審批角色；若選定的角色為其所在部門的部門主管角色，則由選定的角色所在部門的上一級部門的部門主管角色擔任該審批節(jié)點的審批角色；

③當n=2時，由選定的角色d3所在部門d的上一級部門c的部門主管角色c1擔任該審批節(jié)點的審批角色；

④當n=3時，由選定的角色d3所在部門d的上上一級部門b的部門主管角色b1擔任該審批節(jié)點的審批角色；

⑤當n=4時，由選定的角色d3所在部門d的上上上一級部門a的部門主管角色a1擔任該審批節(jié)點的審批角色；

⑥以此類推；

⑦當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；例如：對于角色d3而言，部門級別最高應為4，當部門級別設置為6時，由最高級別部門a的部門主管角色a1擔任該審批節(jié)點的審批角色。

⑧當n≥1時，需要設置“選定的角色為其所在部門的部門主管角色，且該部門無上一級部門時”該審批節(jié)點由指定組審批。

（2）選擇審批流程對應表單中的部門性質字段作為級別主體，以該選定的部門為判斷標準判斷級別，例如，選擇的表單中的部門性質字段為簽訂部門，該簽訂部門為部門d：

①當n=0時，由選定部門d的部門主管角色d1擔任該審批節(jié)點的審批角色；

②當n=1時，由選定部門d的上一級部門c的部門主管角色c1擔任該審批節(jié)點的審批角色；

③當n=2時，由選定部門d的上上一級部門b的部門主管角色b1擔任該審批節(jié)點的審批角色；

④當n=3時，由選定部門d的上上上一級部門a的部門主管角色a1擔任該審批節(jié)點的審批角色；

⑤以此類推；

⑥當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色；例如：對于部門d而言，部門級別最高應為3，當部門級別設置為6時，由最高級別部門a的部門主管角色a1擔任該審批節(jié)點的審批角色。

⑦當n≥1時，需要設置“選定的部門無上一級部門時”該審批節(jié)點由指定組審批。

（3）選擇審批流程的提交角色作為級別主體，以該提交角色為判斷標準判斷級別，例如，若提交角色為角色d2，則：

①當n=0時，由工作流審批流程提交角色d2擔任該審批節(jié)點的審批角色；

審批節(jié)點在設置審批角色時部門級別n可以設置為0，即選擇提交角色d2本身作為審批節(jié)點中的審批角色，在審批流程結束前，可以由提交角色d2本身進行審批確認，選擇不同意后可返回重新審批，選擇同意進入下一環(huán)節(jié)，多出了提交角色復核程序，避免出現審批結果不正確或審批結果與提交角色的預期不符而需要新建審批流程的問題，減少了系統(tǒng)內耗，提高了審批流程效率和可靠性。

舉例：提交角色d2提交了一個10000元的報銷審批請求，因提交角色d2所提交的內容有誤或其他原因，經過多級審批后核準報銷金額被修改為500元，在審批流程結束之前，由提交角色d2作為審批角色進行復核確認即可發(fā)現問題，選擇不同意后可返回重新審批，選擇同意進入下一環(huán)節(jié)，無需新建一個審批流程。

②當n=1時，由工作流審批流程提交角色d2所在部門d的部門主管角色d1擔任該審批節(jié)點的審批角色；（若提交角色是d1，他是其所在部門d的部門主管角色，則由提交角色所在部門d的上一級部門c的部門主管角色c1擔任該審批節(jié)點的審批角色）

③當n=2時，由工作流審批流程提交角色d2所在部門d的上一級部門c的部門主管角色c1擔任該審批節(jié)點的審批角色；

④當n=3時，由工作流審批流程提交角色d2所在部門d的上上一級部門b的部門主管角色b1擔任該審批節(jié)點的審批角色；

⑤當n=4時，由工作流審批流程提交角色d2所在部門d的上上上一級部門a的部門主管角色a1擔任該審批節(jié)點的審批角色；

⑥以此類推；

⑦當部門級別的設置超過系統(tǒng)組織結構中的最高級別部門時，由最高級別部門的部門主管角色擔任該審批節(jié)點的審批角色。例如：對于角色d2而言，部門級別最高應為4，當部門級別設置為6時，由最高級別部門a的部門主管角色a1擔任該審批節(jié)點的審批角色。

⑧當n≥1時，需要設置“提交角色為其所在部門的部門主管角色，且該部門無上一級部門時”該審批節(jié)點由指定組審批；

所述指定組審批包括以下三種情況中的一種：

（1）指定組由一個或多個審批角色構成；

（2）指定組由部門級別確定，選擇級別主體時只能沿用該審批節(jié)點所選擇的級別主體，且級別數值n只能設置為0；

（3）指定組由部門級別確定，級別主體能夠自主選擇，指定組中包括一個或多個指定節(jié)點，當指定節(jié)點的級別數值n為非0時必須設置下一級指定節(jié)點，直到指定節(jié)點的級別數值n為0時，該審批節(jié)點的指定組設置完成。

系統(tǒng)提供了最高級別部門主管的審批機制，避免出現最高級別部門主管無法通過級別審批方式完成審批流程的問題。

舉例：企業(yè)的最高級領導董事長提交審批請求時，在級別審批中，董事長雖沒有上級部門，系統(tǒng)設置指定組來審批董事長提交的審批請求。

指定組審批包括以下三種情況中的一種：

①指定組由一個或多個審批角色構成，例如，由多個監(jiān)事會的成員構成指定組，董事長的審批請求由監(jiān)事會成員進行審批；

②指定組由部門級別確定，選擇級別主體時只能沿用該審批節(jié)點所選擇的級別主體，且級別數值n只能設置為0；此種情況用于應對企業(yè)組織結構發(fā)生變化的情況，例如，某公司原最高級別主管為總經理，而組織結構變化后增設了董事會，最高級別主管變?yōu)槎麻L，審批節(jié)點中級別數值為0則審批角色自動變?yōu)槎麻L，而不是固定為總經理，避免出現審批角色不能適配組織結構變化的問題；

③指定組由部門級別確定，級別主體能夠自主選擇，指定組中包括一個或多個指定節(jié)點，當指定節(jié)點的級別數值n為非0時必須設置下一級指定節(jié)點，直到指定節(jié)點的級別數值n為0時，該審批節(jié)點的指定組設置完成；此種情況適用于普通部門角色審批最高級部門主管所提交的審批請求，例如，財務部門的財務主管可以審核董事長所提交的合同審批請求中涉及的開票信息，最終要由董事長確認。

當審批節(jié)點選擇的是級別審批時，對級別中對應的審批角色進行審批權限授權，則此級別中對應的審批角色的審批權限都相同。

舉例：n=1時，a3、b3、c3、d3分別提交審批流程時，則對應的審批主管分別為a1、b1、c1、d1，且a1、b1、c1、d1的審批權限都一樣。

【實施例3】如圖5所示，工作流的控制方法包括以下步驟：

s1：構建用戶-角色-權限的三層結構模型，其中：

角色層：工作流中流程發(fā)起及審批的操作主體為角色，每個角色是獨立的個體，而非組/類，同一時段一個角色只能關聯(lián)唯一的用戶，而一個用戶關聯(lián)一個或多個角色；

權限層：由工作流執(zhí)行中所需要使用的權限構成，權限直接授權給角色；

用戶層：用戶通過關聯(lián)的角色確定工作流中的審批任務，并以關聯(lián)角色的權限進行審批操作；

s2：如圖7所示，利用三層結構模型對工作流進行控制，一個審批流程中包括一個開始節(jié)點、至少一個審批節(jié)點、一個結束節(jié)點：

開始節(jié)點：提交角色發(fā)起/申請/提交工作流，有工作流發(fā)起權限的角色才能作為提交角色發(fā)起/申請/提交工作流；系統(tǒng)根據提交角色所提交的表單確定審批流程，針對需要有工作流的表單設計一個或多個審批流程，但一個角色只能選擇該表單下的某一個審批流程（同一個角色只能存在于同一個表單的其中一個流程中）；

舉例:采購合同表單有兩種流程，分別為p1流程和p2流程，如果在p1流程的開始節(jié)點中選擇了角色a，那么在p2流程的開始節(jié)點就不能再選擇角色a，此時角色a新增一個采購合同的審批，提交審批時自動進入p1流程。

審批節(jié)點：設置審批的部門的級別，并對級別中對應的審批角色進行審批權限授權；

結束節(jié)點：流程流轉到此節(jié)點后，表示該審批流程審批結束；

s3：用戶根據其關聯(lián)的角色確定所需處理的審批任務，并根據關聯(lián)的角色的權限進行審批操作。

在審批節(jié)點選擇一個或多個審批角色，一個角色在同一個審批流程中能夠存在于不同審批節(jié)點，在審批節(jié)點設置審批角色的權限，針對每個審批節(jié)點的審批角色能夠進行獨立的權限設置，不同審批節(jié)點中該審批角色對此表單字段的查看、修改權限可不同。優(yōu)勢舉例：某角色為成都銷售經理3，在合同審批工作流中，其存在于成都銷售合同審批和上海銷售合同審批兩個審批節(jié)點；對于成都的銷售合同，在審批時該角色可查看該合同的客戶名稱、聯(lián)系人、聯(lián)系方式、產品數量、產品單價、合同金額等全部字段內容，且可修改產品單價、合同金額；但在審批上海銷售合同時卻無法查看客戶名稱、聯(lián)系人、聯(lián)系方式等敏感字段內容，更不能作任何修改（但也可以設為具有查看權限，沒有修改權限）。

【實施例4】如圖6和圖8所示，所述的步驟s1包括以下順序子步驟：

s101：創(chuàng)建角色，每個角色是獨立的個體，而非組/類；

s102：對s101所創(chuàng)建的角色分別進行授權；

s103：將用戶關聯(lián)到角色，其中，同一時段一個角色只能關聯(lián)唯一的用戶，而一個用戶關聯(lián)一個或多個角色。用戶只能通過其與角色的關聯(lián)確定權限，如果要修改用戶的權限，通過調整角色所擁有的權限以達到改變關聯(lián)了該角色的用戶的權限的目的。對用戶不直接授權，而是通過其所關聯(lián)的角色對用戶進行授權，一旦用戶關聯(lián)角色后，該用戶就擁有了該角色的所有操作權限。

角色對用戶的關系為一對一（該角色與一個用戶關聯(lián)時，其他用戶則不能再關聯(lián)該角色；若該角色未被用戶關聯(lián)，則可以被其他用戶選擇關聯(lián)）。用戶對角色的關系為一對多（一個用戶可以同時關聯(lián)多個角色）。

角色的定義：角色不具有組/類/類別/崗位/職位/工種等性質，而是一個非集合的性質，角色具有唯一性，角色是獨立存在的獨立個體；在企事業(yè)單位應用中相當于崗位號（此處的崗位號非崗位，一個崗位同時可能有多個員工，而同一時段一個崗位號只能對應一個員工）。

舉例：某個公司系統(tǒng)中可創(chuàng)建如下角色：總經理、副總經理1、副總經理2、北京銷售一部經理、北京銷售二部經理、北京銷售三部經理、上海銷售工程師1、上海銷售工程師2、上海銷售工程師3、上海銷售工程師4、上海銷售工程師5……

用戶與角色的關聯(lián)關系：若該公司員工張三任職該公司副總經理2，同時任職北京銷售一部經理，則張三需要關聯(lián)的角色為副總經理2和北京銷售一部經理，張三擁有了這兩個角色的權限。

對角色的授權：系統(tǒng)對角色的授權包括但不限于對表單的授權、對菜單的授權或對功能的授權。對表單的操作授權包括但不限于增刪插改。

傳統(tǒng)角色的概念是組/類/崗位/職位/工種性質，一個角色能夠對應多個用戶。而本申請“角色”的概念相當于崗位號/工位號，也類同于影視劇中的角色：一個角色在同一時段（童年、少年、中年……）只能由一個演員來飾演，而一個演員可能會分飾多角。

對角色的授權包括但不限于對表單的授權、對菜單的授權或對功能的授權。

所述的角色創(chuàng)建時必須選擇一個部門，角色一旦創(chuàng)建后則該角色歸屬于該部門，且該角色名在該部門下唯一，角色編號在系統(tǒng)中唯一，根據角色的工作內容對角色進行授權。

如果用戶要變換部門則涉及到跨部門調崗，其具體操作過程包括：

（1）取消用戶與原部門內的角色的關聯(lián)；

（2）將用戶與新部門內的角色進行關聯(lián)。

在創(chuàng)建角色之后，可以在創(chuàng)建用戶的過程中關聯(lián)角色，也可以在用戶創(chuàng)建完成后隨時進行關聯(lián)。用戶關聯(lián)角色后可以隨時解除與角色的關聯(lián)關系，也可以隨時建立與其他角色的關聯(lián)關系。

【實施例5】所述的步驟s1包括以下順序子步驟：

s101：建立角色，每個角色是獨立的個體，而非組/類；

s102：將用戶關聯(lián)到角色，其中，同一時段一個角色只能關聯(lián)唯一的用戶，而一個用戶關聯(lián)一個或多個角色；

s103：對s101所建立的角色分別進行授權。

所述的角色創(chuàng)建時必須選擇一個部門，角色一旦創(chuàng)建后則該角色歸屬于該部門，且該角色名在該部門下唯一，角色編號在系統(tǒng)中唯一。

工作流控制方法，還包括一個用戶跨部門調崗管理步驟，具體包括：

（1）取消用戶與原部門內的角色的關聯(lián)；

（2）將用戶與新部門內的角色進行關聯(lián)。

【實施例6】角色的構成為：崗位名+崗內編號。例如：車間生產工人1、車間生產工人2、車間生產工人3……角色是獨立個體，相當于崗位號、工位號的概念，不同于傳統(tǒng)權限管理體系中的角色，傳統(tǒng)體系中角色的概念是崗位/職位/工種等的組/類性質。

【實施例7】以下舉例員工張三進入某公司后，員工、用戶與角色之間的關系為：

1、新入職：員工新入職，直接為該用戶（員工）選擇相應的崗位號/工位號的角色進行關聯(lián)即可，例：張三入職公司（公司為張三分配了一個張三用戶），工作內容是在銷售一部，負責北京區(qū)域冰箱產品的銷售（對應的角色是銷售一部下的“銷售工程師5”這個角色），則張三用戶直接選擇“銷售工程師5”這個角色關聯(lián)即可。

2、增加職位：張三工作一段時間后，公司還安排張三負責北京區(qū)域電視產品的銷售（對應的角色是銷售一部下的“銷售工程師8”這個角色）并兼任售后部主管（對應售后部主管1這個角色），則張三用戶再增加關聯(lián)銷售一部下的“銷售工程師8”和售后部下的“售后部主管1”這兩個角色，此時，張三員工關聯(lián)了三個角色，分別為銷售一部下的“銷售工程師5”、“銷售工程師8”和售后部下的“售后部主管1”，張三用戶則擁有了這三個角色的權限。

3、減少職位：又過了一段時間，公司決定讓張三任職售后部經理（對應售后部下“售后部經理”這個角色），且不再兼任其他工作。則張三用戶關聯(lián)售后部下“售后部經理”這個角色，同時取消此前關聯(lián)的三個角色（銷售一部下的“銷售工程師5”、“銷售工程師8”和售后部下的“售后部主管1”），此時，張三用戶只擁有售后部下“售后部經理”這個角色的權限。

4、角色權限的調整（針對角色本身所擁有的權限的調整）：如公司決定增加售后部經理的權限，則只需增加對售后部經理這個角色的授權即可，則張三用戶因為售后部經理這個角色的權限增加了，張三用戶的權限也增加了。

5、離職：一年后，張三離職了，則取消張三用戶與售后部下“售后部經理”這個角色的關聯(lián)即可。

舉例：公司在動態(tài)的經營中，職員的入職、離職是經常持續(xù)發(fā)生的，但崗位號/工位號的變化非常少(甚至在一定時期內是沒有變化的)。

傳統(tǒng)授權方法：在系統(tǒng)功能點多的情況下，以傳統(tǒng)的組/類性質的角色進行授權，不僅授權工作量大，繁雜，而且很容易出錯，甚至出錯了在短時間內都不容易發(fā)現，容易對系統(tǒng)使用方造成損失。

本申請授權方法：本申請是對崗位號/工位號性質的角色進行授權，用戶關聯(lián)角色而確定權限，則對用戶權限的控制，只是通過簡單的用戶-角色的關聯(lián)關系來實現，讓權限控制變得簡單、易操作，清晰明了，大幅度提高了授權效率和授權可靠性。

以上所述僅是本發(fā)明的優(yōu)選實施方式，應當理解本發(fā)明并非局限于本文所披露的形式，不應看作是對其他實施例的排除，而可用于各種其他組合、修改和環(huán)境，并能夠在本文所述構想范圍內，通過上述教導或相關領域的技術或知識進行改動。而本領域人員所進行的改動和變化不脫離本發(fā)明的精神和范圍，則都應在本發(fā)明所附權利要求的保護范圍內。