CN108805532A - 工作流审批节点高效审批方法 - Google Patents

Abstract

本发明公开了一种工作流审批节点高效审批方法，包括一个设置审批节点审批角色的步骤和一个审批角色高效审批的步骤，设置审批节点审批角色包括三种方式：指定角色、指定部门（部门主管角色）、按级别设置审批角色；审批角色高效审批过程：以第一个提交审批意见的审批角色的审批意见作为该审批节点的审批结果，只要有任意一个审批角色提交审批意见，该审批节点审批结束。本发明审批节点只要有任一个审批角色提交了审批意见，就确定了该审批节点的审批结果，该审批节点审批结束，其他审批角色的审批任务自动撤除，实现了高效、快速审批。特别适用于多人对同一个审批任务的审批权限相同，任何一个人给出审批意见皆可的情形。

Description

工作流审批节点高效审批方法

技术领域

本发明涉及一种ERP等管理软件系统的工作流审批方法，特别是涉及一种工作流审批节点高效审批方法。

背景技术

基于角色的访问控制（RBAC）是近年来研究最多、思想最成熟的一种数据库权限管理机制，它被认为是替代传统的强制访问控制（MAC）和自主访问控制（DAC）的理想候选。传统的自主访问控制的灵活性高但是安全性低，强制访问控制安全性高但是限制太强；基于角色的访问控制两者兼具，不仅易于管理而且降低了复杂性、成本和发生错误的概率，因而近年来得到了极大的发展。基于角色的访问控制（RBAC）的基本思想是根据企业组织视图中不同的职能岗位划分不同的角色，将数据库资源的访问权限封装在角色中，用户通过被赋予不同的角色来间接访问数据库资源。

在大型应用系统中往往都建有大量的表和视图，这使得对数据库资源的管理和授权变得十分复杂。由用户直接管理数据库资源的存取和权限的收授是十分困难的，它需要用户对数据库结构的了解非常透彻，并且熟悉SQL语言的使用，而且一旦应用系统结构或安全需求有所变动，都要进行大量复杂而繁琐的授权变动，非常容易出现一些意想不到的授权失误而引起的安全漏洞。因此，为大型应用系统设计一种简单、高效的权限管理方法已成为系统和系统用户的普遍需求。

基于角色的权限控制机制能够对系统的访问权限进行简单、高效的管理，极大地降低了系统权限管理的负担和代价，而且使得系统权限管理更加符合应用系统的业务管理规范。

然而，传统基于角色的用户权限管理和工作流控制方法均采用“角色对用户一对多”的关联机制，其“角色”为组/类性质，即一个角色可以同时对应/关联多个用户，角色类似于岗位/职位/工种等概念，这种关联机制下对用户权限的授权基本分为以下三种形式：1、如图1所示，直接对用户授权，缺点是工作量大、操作频繁且麻烦；审批流程中审批节点的审批操作主体是用户，工作流审批节点直接选择员工/用户作为审批主体，当发生员工变动（如调岗、离职等），该员工涉及到的所有流程必须要作相应调整，特别是对于公司管理人员，其涉及到的审批流程多，流程调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。

即使只是员工审批权限发生变化，也需要对该员工涉及到的流程作出相应调整，也存在以上类似问题。

2、如图2所示，对角色（类/组/岗位/工种性质）进行授权（一个角色可以关联多个用户），用户通过角色获得权限，审批操作主体是组/类性质角色；3、如图3所示，以上两种方式结合。

以上的表述中，2、3均需要对类/组性质的角色进行授权，而通过类/组/岗位/工种性质的角色进行授权和工作流控制的方式有以下缺点：1、用户权限变化时的操作难：在实际的系统使用过程中，经常因为在运营过程中需要对用户的权限进行调整，比如：在处理员工权限变化时，角色关联的某个员工权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。

员工/用户的审批权限发生变化时，要么员工/用户脱离角色，工作流审批节点直接选择员工/用户作为审批主体，要么新增角色来满足审批流程的要求。第一种方式，当发生员工变动（如调岗、离职等），该员工涉及到的所有流程必须要作相应调整，特别是对于公司管理人员，其涉及到的审批流程多，流程调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。即使只是员工审批权限发生变化，也需要对该员工涉及到的流程作出相应调整，也存在以上类似问题。第二种方式，新增角色便涉及到角色的新建、关联、授权工作，特别在角色多、角色关联的用户也多的情况下，角色具体关联了哪些用户是很难记住的。

2、要长期记住角色包含的具体权限难：若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，相近角色的权限也很容易混淆；若要关联新的用户，无法准确判断应当如何选择关联。

3、因为用户权限变化，则会造成角色创建越来越多（若不创建新角色，则会大幅增加直接对用户的授权），更难分清各角色权限的具体差别。

4、调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。

传统系统的工作流审批机制存在以下缺陷：（1）审批节点中无法选择流程发起人自身作为审批人员，在审批流程结束之前，审批流程的发起人无法复核确认其提交的申请的审批结果，例如：发起人发起了一个10000元的报销审批请求，因发起人提交的内容有误或其他原因，经过多级审批后核准报销金额被修改为500元，最终的审批结果只允许报销500元，审批流程结束。发起人收到审批结果后有异议的话，必须将之前的审批流程结果作废，再重新提交一个审批申请，增加了系统内耗，降低了审批效率。

（2）对于组织结构比较复杂的跨省、跨国集团公司等，涉及到的审批流程数量非常多，审批流程流转条件和流转线路也很复杂，对于系统流程设置人员来说，工作量非常大，而且很容易在设置审批流程时出错，系统使用很不方便、系统可靠性不高。

（3）在按级别设置审批时，系统无法实现对最高级部门主管所提交的审批请求的审批，一般需要单独为最高级部门主管分配专门的审批角色，增加了系统工作流设置人员的工作量。

（4）只能以审批流程提交角色作为判断标准来判断部门级别，无法自定义以表单中涉及到的其它角色或部门作为判断部门级别的标准，存在一定的使用局限性。

举例：对于一个合同审批流程，合同的签订角色请假了，让其同事替他发起了一个合同的审批，而系统认定其同事为流程的提交角色，在按级别审批时对于级别的判断均以其同事为准，无法客观体现合同签订角色所在的部门及职位。例如，合同的签订角色为市场部的销售人员1，其同事角色为研发部的研发人员1，原本该合同应由签订角色所在部门的主管-市场部主管角色审批，设置审批节点的审批级别为1时，系统会分配给研发人员1所在部门的主管-研发部主管角色进行审批，出现了审批流程的分配错误，使用不方便。

此外，传统工作流审批节点的审批方式单一，对于多人审批，多采用投票方式进行，然而投票方式通常需要每个审批角色都提交投票结果后才能得到该审批节点的审批结果，在实际应用过程中，审批效率低下，无法实现高效、快速审批。

发明内容

本发明的目的在于克服现有技术的不足，提供一种工作流审批节点高效审批方法，只要有任一个审批角色提交审批意见，就确定该审批节点的审批结果，该审批节点的审批结束，其他审批角色的审批任务自动撤除，实现高效、快速审批。特别适用于多人对同一个审批任务的审批权限相同，任何一个人给出的审批意见都能决定审批结果的情形。

本发明的目的是通过以下技术方案来实现的：工作流审批节点高效审批方法，包括一个设置审批节点审批角色的步骤和一个审批角色高效审批的步骤：所述设置审批节点审批角色的步骤包括以下方式中的任意一种或多种的组合：（1）直接指定一个或多个角色作为审批角色；（2）直接指定一个或多个部门，以部门的部门主管角色担任审批角色；（3）按级别设置审批角色；所述审批角色高效审批的步骤：一个审批节点包含一个或多个审批角色，以第一个提交审批意见的审批角色的审批意见作为该审批节点的审批结果，只要有任意一个审批角色提交审批意见，该审批节点审批结束。

工作流审批节点高效审批方法，还包括一个设置审批角色对审批流程涉及的表单字段内容查看权限的步骤，同一审批节点的不同审批角色对表单字段内容的查看/修改权限相同。

工作流审批节点高效审批方法，还包括一个设置审批节点下一级流转节点的步骤，下一级流转节点包括两种：（1）该审批节点的审批结果为“通过”时的一个或多个通过节点；（2）该审批节点的审批结果为“驳回”时的一个或多个驳回节点；当通过/驳回时有多个通过节点/驳回节点可选时，由该第一个提交审批意见的审批角色选择一个通过节点/驳回节点；当通过/驳回时只有一个通过节点/驳回节点时，由该第一个提交审批意见的审批角色选择该通过节点/驳回节点，或者由系统自动进入该通过节点/驳回节点。

所述的角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

所述的审批流程基于用户-角色-权限的三层结构模型，其中：角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；用户层：用户通过关联的角色确定审批流程中的审批任务，并以关联角色的权限进行审批操作。

所述的用户-角色-权限三层结构模型的构建包括以下步骤：建立角色，每个角色是独立的个体，而非组/类；所述角色归属于部门，根据角色的工作内容对角色进行授权，且该角色的名称在该部门下唯一，该角色的编号在系统中唯一；所述账户跨部门调岗时，取消账户与原部门内的角色的关联，将账户（用户）与新部门内的角色进行关联；对建立的角色分别进行权限的授权；将用户关联到角色，其中，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

所述的审批流程包括一个开始节点、至少一个审批节点、一个结束节点：开始节点：审批流程开始；审批节点：选择审批角色，并对审批角色进行授权；结束节点：审批流程结束。

所述按级别设置审批角色的步骤包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：所述设置系统组织结构的步骤包括以下子步骤：SS1：创建系统组织结构中所包含的部门及角色；SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色；所述按部门级别设置审批角色的步骤包括：SSS1:选择（或设置）以按级别方式进行审批角色的设置；SSS2:选择审批流程对应表单中的角色性质字段、部门性质字段或者该审批流程的提交角色中的一个，作为级别主体；SSS3:填写具体的级别数值n，n为≥0的正整数（N的值也可采用其他符号代替，比如a、b、c、d，b比a大一级，c比a大两级，d比a大三级，以此类推）：（1）选择审批流程对应表单中的角色性质字段作为级别主体，以该字段对应的角色为判断标准判断级别：①当n=0时，由该字段对应的角色担任该审批节点的审批角色；②当n=1时，由该字段对应的角色所在部门的部门主管角色担任该审批节点的审批角色；若该字段对应的角色为其所在部门的部门主管角色，则由该字段对应的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；③当n=2时，由该字段对应的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；④当n=3时，由该字段对应的角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；⑤当n=4时，由该字段对应的角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；⑥以此类推；⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；（2）选择审批流程对应表单中的部门性质字段作为级别主体，以该字段对应的部门为判断标准判断级别：①当n=0时，由该字段对应的部门的部门主管角色担任该审批节点的审批角色；②当n=1时，由该字段对应的部门的上一级部门的部门主管角色担任该审批节点的审批角色；③当n=2时，由该字段对应的部门的上上一级部门的部门主管角色担任该审批节点的审批角色；④当n=3时，由该字段对应的部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；⑤以此类推；⑥当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；（3）选择审批流程的提交角色作为级别主体，以该提交角色为判断标准判断级别：①当n=0时，由工作流审批流程提交角色担任该审批节点的审批角色；②当n=1时，由工作流审批流程提交角色所在部门的部门主管角色担任该审批节点的审批角色；若提交角色为其所在部门的部门主管角色，则由提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；③当n=2时，由工作流审批流程提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；④当n=3时，由工作流审批流程提交角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；⑤当n=4时，由工作流审批流程提交角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；⑥以此类推；⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色。

所述表单中的角色性质字段、部门性质字段为必填单选项。

所述按级别设置审批角色的步骤包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：所述设置系统组织结构的步骤包括以下子步骤：SS1：创建系统组织结构中所包含的部门及角色；SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色；所述按部门级别设置审批角色的步骤包括：SSS1:选择（或设置）以按级别方式进行审批角色的设置；SSS2:选择审批流程对应表单中的角色性质字段、部门性质字段或者该审批流程的提交角色中的一个，作为级别主体；SSS3:填写具体的级别数值n，n为≥0的正整数（N的值也可采用其他符号代替，比如a、b、c、d，b比a大一级，c比a大两级，d比a大三级，以此类推）：（1）选择审批流程对应表单中的角色性质字段作为级别主体，以该字段对应的角色为判断标准判断级别：①当n=0时，由该字段对应的角色担任该审批节点的审批角色；②当n=1时，由该字段对应的角色所在部门的部门主管角色担任该审批节点的审批角色；若该字段对应的角色为其所在部门的部门主管角色，则由该字段对应的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；③当n=2时，由该字段对应的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；④当n=3时，由该字段对应的角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；⑤当n=4时，由该字段对应的角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；⑥以此类推；⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；⑧当n≥1时，需要设置“该字段对应的角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点由指定组审批；（2）选择审批流程对应表单中的部门性质字段作为级别主体，以该字段对应的部门为判断标准判断级别：①当n=0时，由该字段对应的部门的部门主管角色担任该审批节点的审批角色；②当n=1时，由该字段对应的部门的上一级部门的部门主管角色担任该审批节点的审批角色；③当n=2时，由该字段对应的部门的上上一级部门的部门主管角色担任该审批节点的审批角色；④当n=3时，由该字段对应的部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；⑤以此类推；⑥当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；⑦当n≥1时，需要设置“该字段对应的部门无上一级部门时”该审批节点由指定组审批；（3）选择审批流程的提交角色作为级别主体，以该提交角色为判断标准判断级别：①当n=0时，由工作流审批流程提交角色担任该审批节点的审批角色；②当n=1时，由工作流审批流程提交角色所在部门的部门主管角色担任该审批节点的审批角色；若提交角色为其所在部门的部门主管角色，则由提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；③当n=2时，由工作流审批流程提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；④当n=3时，由工作流审批流程提交角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；⑤当n=4时，由工作流审批流程提交角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；⑥以此类推；⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；⑧当n≥1时，需要设置“提交角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点由指定组审批；所述指定组审批包括以下三种情况中的一种：（1）指定组由一个或多个审批角色构成；（2）指定组由部门级别确定，选择级别主体时只能沿用该审批节点所选择的级别主体，且级别数值n只能设置为0；（3）指定组由部门级别确定，级别主体能够自主选择，指定组中包括一个或多个指定节点，当指定节点的级别数值n为非0时必须设置下一级指定节点，直到指定节点的级别数值n为0时，该审批节点的指定组设置完成。

本发明的有益效果是：（1）只要有任一个审批角色提交了审批意见，就确定了该审批节点的审批结果，该审批节点审批结束，其他审批角色的审批任务自动撤除，实现了高效、快速审批。特别适用于多人对同一个审批任务的审批权限相同，任何一个人都可以决定该节点审批结果的情形。

举例：在由销售人员3提交的请假审批中，销售经理1、销售经理2、人事主管2都有直接决定该审批的结果的权限，该审批节点中的审批角色由销售经理1、销售经理2、人事主管2组成，其中任意一人（角色）给出审批意见都可以决定该节点的审批结果。如：审批任务同步分配给销售经理1、销售经理2、人事主管2，销售经理2最先看到了该审批任务并提交了审批意见为“通过”，则该节点的审批以“通过”作为审批结果结束，不再需要销售经理1和人事主管2给出审批意见，销售经理1和人事主管2的审批任务自动撤除。

（2）设置审批角色的方式有：指定角色、指定部门、按级别设置审批角色：指定角色的好处：系统工作流设置人员在设置审批角色时只需选择相应的角色作为审批角色即可，无需选择具体的用户，即使该角色关联的用户发生变化，也不需要重新设置审批角色，操作便捷、不容易出错。

举例：公司的行政部有角色A、角色B，若角色A为行政部的部门主管角色，在进行请假的工作流审批设置时，只需选择角色A作为审批角色，而不用选择角色A关联的用户，即使角色A关联的用户由张三变为李四，也不需要重新进行审批角色的设置。

指定部门的好处：系统工作流设置人员在设置审批角色时只需选择相应的部门，则该部门的部门主管角色为审批角色，即使该部门的部门主管角色发生变化，则该部门当前的部门主管角色为审批角色，也不需要重新设置审批角色，操作便捷、不容易出错。

举例：公司的员工请假时都需要行政部门审批，本发明中只需要在审批节点中选择行政部门，行政部的部门主管角色则为审批角色，该部门主管角色对应的职员通过该部门主管角色获取审批任务并根据该部门主管角色的相关权限进行审批，无需选择具体某一职员进行审批设置，操作简单便捷；当行政部的部门主管角色由角色A变为角色B时，则由角色B对应的职员进行审批，不需要重新进行审批角色的设置。

按级别设置审批角色的好处：通过按部门级别设置审批角色的方式，系统工作流设置人员在设置审批角色时只需输入相应部门级别即可，多个审批流程能够有效整合在一个审批流程内，能够有效减少流转条件和流转线路，降低了系统工作流设置人员的工作量，提高了系统可靠性。比如：在费用报销审批流程中，在一个审批节点设置级别审批，且以提交角色作为级别主体，并设置级别为1，则所有的费用报销在该审批节点自动由提交角色所在的部门的部门主管角色进行审批。

（3）传统级别审批方式只能以审批流程提交角色作为判断标准来判断部门级别，无法自定义以表单中涉及到的其它角色或部门作为判断部门级别的标准，存在一定的使用局限性。

举例：对于一个合同审批流程，合同的签订角色请假了，让其同事替他发起了一个合同的审批，而系统认定其同事为流程的提交角色，在按级别审批时对于级别的判断均以其同事为准，无法客观体现合同签订角色所在的部门及职位。例如，合同的签订角色为市场部的销售人员1，其同事角色为研发部的研发人员1，原本该合同应由签订角色所在部门的主管-市场部主管角色审批，设置审批节点的审批级别为1时，系统会分配给研发人员1所在部门的主管-研发部主管角色进行审批，出现了审批流程的分配错误，使用不方便。

本申请可根据需要自定义以表单中涉及到的角色性质字段、部门性质字段或提交角色作为判断部门级别的标准，例如，在设置审批节点时，可以选择合同表单中的签订角色作为级别主体，以签订角色（而非一味默认为提交角色）作为标准判断部门级别，以此确定审批角色为市场部主管角色，使用更灵活、方便，通用性强。

（4）系统提供了最高级别部门主管的审批机制，避免出现最高级别部门主管无法通过级别审批方式完成审批流程的问题。

举例：企业的最高级领导董事长提交审批请求时，在级别审批中，董事长虽没有上级部门，但设置了指定组来审批董事长提交的审批请求。

指定组审批包括以下三种情况中的一种：①指定组由一个或多个审批角色构成，例如，由多个监事会的成员构成指定组，董事长的审批请求由监事会成员进行审批；②指定组由部门级别确定，选择级别主体时只能沿用该审批节点所选择的级别主体，且级别数值n只能设置为0；此种情况用于应对企业组织结构发生变化的情况，例如，某公司原最高级别主管为总经理，而组织结构变化后增设了董事会，最高级别主管变为董事长，审批节点中级别数值为0则审批角色自动变为董事长，而不是固定为总经理，避免出现审批角色不能适配组织结构变化的问题；③指定组由部门级别确定，级别主体能够自主选择，指定组中包括一个或多个指定节点，当指定节点的级别数值n为非0时必须设置下一级指定节点，直到指定节点的级别数值n为0时，该审批节点的指定组设置完成；此种情况适用于普通部门角色审批最高级部门主管所提交的审批请求，例如，财务部门的财务主管可以审核董事长所提交的合同审批请求中涉及的开票信息，最终要由董事长确认。

（5）审批节点在设置审批角色时部门级别n可以设置为0，即选择提交角色本身作为审批节点中的审批角色，在审批流程结束前，可以由提交角色本身进行审批确认，选择不同意后可返回重新审批，选择同意进入下一环节，多出了提交角色复核程序，避免出现审批结果不正确或审批结果与提交角色的预期不符而需要新建（重新提交）审批流程的问题，减少了系统内耗，提高了审批流程效率和可靠性。

举例：提交角色提交了一个10000元的报销审批请求，因提交角色所提交的内容有误或其他原因，经过多级审批后核准报销金额被修改为500元，在审批流程结束之前，由提交角色作为审批角色进行复核确认即可发现问题，选择不同意后可返回重新审批，选择同意进入下一环节，无需新建（重新提交）一个审批流程。

（6）工作流中审批操作的主体是角色，而且这个角色是独立的个体而不是传统组/类性质的角色，即使发生员工/用户变动（如调岗、离职等），或者是员工审批权限发生变化，只需将员工重新关联到新角色，或是针对性调整该角色审批权限即可，无需重新设置/调整流程，设置方便，不会出错或遗漏，不会影响企业的正常运营，极大提高了工作流的可靠性。以岗位号性质的角色为审批环节节点的审批授权主体，用户通过角色确定（获得）其有哪些审批任务，用户通过关联角色的权限进行审批操作即可；理解清晰简单，每个岗位号/工位号性质的角色是工作主体的最小单位，针对每个角色对审批的不同需求，本申请均能够很好满足。

（7）本申请角色对用户是一对一的关系，同一时段一个角色只能关联唯一的用户，这样做的好处是，只要将用户关联到角色即可获得权限（即用户获得其关联的角色的权限），而且角色的权限变更比传统机制中的用户权限变更要少得多。独立体性质（岗位号/工位号性质）的角色数量变化小，虽然员工流动大，但岗位号/工位号的变化小（甚至在一定时段内是没有变化的，即角色没有变化），这样将极大简化用户的权限管理，减少系统的开销。

（8）动态管理、入职调岗等的操作简单方便，效率高，可靠性高：入职/离职/调岗在审批流程中的应用简单，工作流程的审批的操作主体是角色，当员工/用户发生变化时不用重新设置审批流程（用户只需取消或关联角色即可：不再任职该岗位号/工位号的角色的用户就取消该角色关联，接手任职该岗位号/工位号的角色的用户关联该岗位号的角色，则关联该角色的用户自动就获得了该角色在审批工作流中的相关任务和权限，无需对审批工作流进行重新设置或对工作流中的角色进行重新授权，极大地提高了流程设置的效率、安全性和可靠性。

举例：因张三用户离职或调岗等原因，张三不再做“采购员3”这个角色的工作，则张三取消了与该角色的关联；另外李四接手做“采购员3”这个角色的工作，则将李四关联该角色，则李四自动获得了审批流程中“采购员3”这个角色的审批任务和审批权限。

（9）传统的权限管理机制将角色定义为组、工种、类等性质，角色对用户是一对多的关系，在实际的系统使用过程中，经常因为在运营过程中需要对用户的权限进行调整，比如：在处理员工权限变化的时候，角色关联的某个员工的权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。

但在本申请的方法下，因为角色是一个独立的个体，则可以选择改变角色权限即可达到目的。本申请的方法，虽然看起来在系统初始化时会增加工作量，但可以通过复制等方法，使其创建角色或授权的效率高于传统以组为性质的角色，因为不用考虑性质为组的角色在满足关联用户时的共通性，本申请方案会让权限设置清晰，明了；尤其是在系统使用一段时间后（用户/角色权限动态变化），该申请方案能为系统使用方大幅度提高系统使用中的权限管理效率，使动态授权更简单，更方便，更清晰、明了，提高权限设置的效率和可靠性。

（10）传统以组为性质的角色授权方法容易出错，本申请方法大幅降低了授权出错的几率，因为本申请方法只需考虑作为独立个体的角色，而不用考虑传统方法下关联该组性质角色的多个用户有哪些共通性。即使授权出错也只影响关联到该角色的那一个用户，而传统以组性质的角色则会影响关联到该角色的所有用户。即使出现权限授权错误，本申请的修正方法简单、时间短，而传统以组性质的角色在修正错误时需要考虑关联到该角色的所有用户的权限共通性，在功能点多的情况下不仅修改麻烦、复杂，非常容易出错，且很多情况下只能新创建角色才能解决。

（11）在传统以组为性质的角色授权方法下，若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，若要关联新的用户，无法准确判断应当如何选择关联。本申请方法的角色本身就具有岗位号/工位号的性质，选择一目了然。

（12）调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。

本申请方法则为：被调岗用户关联了几个角色，在调岗时，首先取消用户与原部门内的角色的关联（被取消的这几个角色可以被重新关联给其他用户），然后将用户与新部门内的角色进行关联即可。操作简单，不会出错。

（13）角色归属于部门，则该角色的部门不能被更换，角色为什么不能更换部门：理由1：因为本申请的角色性质等同于一个工位号/岗位号，不同的工位号/岗位号的工作内容/权限是不一样的，如销售部门下的销售员1角色和技术部门的开发人员1角色是完全不同的两个工位号/岗位号，其权限是不同的；理由2：若将销售员1角色的所属部门（销售部）更换为技术部，其销售人员1这个角色的权限不变，则在技术部存在拥有销售部权限的一个角色，这样会导致管理混乱及安全漏洞。

（14）一个角色在同一个审批流程中能够存在于不同审批节点，不同审批节点中该审批角色对表单字段的查看、修改权限可不同。优势举例：某角色为成都销售经理3，在合同审批工作流中，其存在于成都销售合同审批和上海销售合同审批两个审批节点；对于成都销售合同审批节点，在审批时该角色可查看该合同的客户名称、联系人、联系方式、产品数量、产品单价、合同金额等全部字段内容，且可修改产品单价、合同金额；但在上海销售合同审批节点却无法查看客户名称、联系人、联系方式等敏感字段内容，更不能作任何修改（但也可以设为具有查看权限，没有修改权限）。这样一来，能够自定义地设置角色在审批流程中的权限。

在审批节点选择一个或多个审批角色，在审批节点设置审批角色的权限，针对每个审批节点的每个审批角色能够进行独立的权限设置。例如：在一个合同表单的审批流程中，有某个审批节点设置了2个审批角色，分别为角色A、角色B，可设置角色A能够看到该合同表单中的合同金额字段及该字段的值，也可以看到该合同表单中的客户地址字段及该字段的值；设置角色B不能看到合同表单中的合同金额字段，或能看到合同金额字段但看不到该字段的值，看不到值时可用其他符号显示，比如*号，角色B能够看到该合同表单中的客户地址字段及该字段的值。

附图说明

图1为背景技术中系统直接对用户进行授权的方式示意图；

图2为背景技术中系统对组/类性质角色进行授权的方式示意图；

图3为背景技术中系统对用户直接授权和对组/类性质角色授权相结合的方式示意图；

图4为实施例中系统组织结构树状图；

图5为本发明系统通过独立个体性质角色对用户进行授权的方式示意图；

图6为本发明工作流审批流程示意图；

图7为本发明用户-角色授权方法流程图。

具体实施方式

下面结合附图进一步详细描述本发明的技术方案，但本发明的保护范围不局限于以下所述。

【实施例1】工作流审批节点高效审批方法，包括一个设置审批节点审批角色的步骤和一个审批角色高效审批的步骤：所述设置审批节点审批角色的步骤包括以下方式中的任意一种或多种的组合：（1）直接指定一个或多个角色作为审批角色；（2）直接指定一个或多个部门，以部门的部门主管角色担任审批角色；（3）按级别设置审批角色；设置审批角色的方式有：指定角色、指定部门、按级别设置审批角色：指定角色的好处：系统工作流设置人员在设置审批角色时只需选择相应的角色作为审批角色即可，无需选择具体的用户，即使该角色关联的用户发生变化，也不需要重新设置审批角色，操作便捷、不容易出错。

举例：公司的行政部有角色A、角色B，若角色A为行政部的部门主管角色，在进行请假的工作流审批设置时，只需选择角色A作为审批角色，而不用选择角色A关联的用户，即使角色A关联的用户由张三变为李四，也不需要重新进行审批角色的设置。

指定部门的好处：系统工作流设置人员在设置审批角色时只需选择相应的部门，则该部门的部门主管角色为审批角色，即使该部门的部门主管角色发生变化，则该部门当前的部门主管角色为审批角色，也不需要重新设置审批角色，操作便捷、不容易出错。

举例：公司的员工请假时都需要行政部门审批，本发明中只需要在审批节点中选择行政部门，行政部的部门主管角色则为审批角色，该部门主管角色对应的职员通过该部门主管角色获取审批任务并根据该部门主管角色的相关权限进行审批，无需选择具体某一职员进行审批设置，操作简单便捷；当行政部的部门主管角色由角色A变为角色B时，则由角色B对应的职员进行审批，不需要重新进行审批角色的设置。

按级别设置审批角色的好处：通过按部门级别设置审批角色的方式，系统工作流设置人员在设置审批角色时只需输入相应部门级别即可，多个审批流程能够有效整合在一个审批流程内，能够有效减少流转条件和流转线路，降低了系统工作流设置人员的工作量，提高了系统可靠性。

特别的，本申请审批角色高效审批的步骤：一个审批节点包含一个或多个审批角色，选择一个表示由这个角色审批，选择多个表示由这多个角色中的任意一个进行审批都可以，5种审批角色类型都可选。

以第一个提交审批意见的审批角色的审批意见作为该审批节点的审批结果，只要有任意一个审批角色提交审批意见，该审批节点审批结束。

也就是说，只要有任一个审批角色提交了审批意见，就确定了该审批节点的审批结果，该审批节点审批结束，其他审批角色的审批任务自动撤除，实现了高效、快速审批。特别适用于多人（多审批角色）对同一个审批任务的审批权限相同，任何一个人（角色）给出的审批意见都能决定该节点审批结果的情形。

举例：在由销售人员3提交的请假审批中，销售经理1、销售经理2、人事主管2都有直接决定该审批的结果的权限，该审批节点中的审批角色由销售经理1、销售经理2、人事主管2组成，其中任意一人（角色）给出审批意见都可以决定该节点的审批结果。如：审批任务同步分配给销售经理1、销售经理2、人事主管2，销售经理2最先看到了该审批任务并提交了审批意见为“通过”，则该节点的审批以“通过”作为审批结果结束，不再需要销售经理1和人事主管2给出审批意见，销售经理1和人事主管2的审批任务自动撤除。

【实施例2】工作流审批节点高效审批方法，还包括一个设置审批角色对审批流程涉及的表单字段内容查看权限的步骤，同一审批节点的不同审批角色对表单字段内容的查看权限必须相同。当一个审批节点有多个审批角色时，设置字段的查看及修改权限也是针对所有审批角色设置的一个统一权限，而不是针对每一个审批角色设置权限。因为各审批角色的审批权限都相同，任一个审批角色都能决定节点的审批结果，因此必须保证每个审批角色所看到的表单字段内容都是相同的。

审批角色默认能查看表单的全部字段（字段内容），默认禁止修改表单的全部字段（字段内容）；用户可以设置禁止审批角色在当前步骤查看某些字段（字段内容），或者授权可以修改某些字段（字段内容）。

【实施例3】工作流审批节点高效审批方法，还包括一个设置审批节点下一级流转节点的步骤，下一级流转节点包括两种：（1）该审批节点的审批结果为“通过”时的一个或多个通过节点；（2）该审批节点的审批结果为“驳回”时的一个或多个驳回节点；当通过/驳回时有多个通过节点/驳回节点可选时，由该第一个提交审批意见的审批角色选择一个通过节点/驳回节点；当通过/驳回时只有一个通过节点/驳回节点时，由该第一个提交审批意见的审批角色选择该通过节点/驳回节点，或者由系统自动进入该通过节点/驳回节点。

【实施例4】按级别设置审批角色的步骤包括一个设置系统组织结构的步骤和一个按级别设置审批角色的步骤：所述设置系统组织结构的步骤包括以下子步骤：SS1：创建系统组织结构中所包含的部门及角色；SS2：设置各部门之间的层级关系，如图4所示，部门A比部门B高一级，部门A比部门C高两级……，并设置各部门的部门主管角色；所述按部门级别设置审批角色的步骤包括：SSS1:选择（或设置）以按级别方式进行审批角色的设置；SSS2:选择审批流程对应表单中的角色性质字段、部门性质字段或者该审批流程的提交角色中的一个，作为级别主体；选择级别主体时，能且只能选择一个；表单上可以有多个角色性质、部门性质的字段（如签订角色、负责角色、签订部门、负责部门等），但一个流程只有一个流程提交角色；SSS3:填写具体的级别数值n，n为≥0的正整数（N的值也可采用其他符号代替，比如a、b、c、d，b比a大一级，c比a大两级，d比a大三级，以此类推）：（1）选择审批流程对应表单中的角色性质字段作为级别主体，以该字段对应的角色为判断标准判断级别，例如，流程的提交角色为d2，但选择的表单中的角色性质字段为签订角色，该签订角色为角色d3：①当n=0时，由选定的角色d3担任该审批节点的审批角色；②当n=1时，由选定的角色d3所在部门D的部门主管角色d1担任该审批节点的审批角色；若选定的角色为其所在部门的部门主管角色，则由选定的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；③当n=2时，由选定的角色d3所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色；④当n=3时，由选定的角色d3所在部门D的上上一级部门B的部门主管角色b1担任该审批节点的审批角色；⑤当n=4时，由选定的角色d3所在部门D的上上上一级部门A的部门主管角色a1担任该审批节点的审批角色；⑥以此类推；⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；例如：对于角色d3而言，部门级别最高应为4，当部门级别设置为6时，由最高级别部门A的部门主管角色a1担任该审批节点的审批角色。

（2）选择审批流程对应表单中的部门性质字段作为级别主体，以该选定的部门为判断标准判断级别，例如，选择的表单中的部门性质字段为签订部门，该签订部门为部门D：①当n=0时，由选定部门D的部门主管角色d1担任该审批节点的审批角色；②当n=1时，由选定部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色；③当n=2时，由选定部门D的上上一级部门B的部门主管角色b1担任该审批节点的审批角色；④当n=3时，由选定部门D的上上上一级部门A的部门主管角色a1担任该审批节点的审批角色；⑤以此类推；⑥当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；例如：对于部门D而言，部门级别最高应为3，当部门级别设置为6时，由最高级别部门A的部门主管角色a1担任该审批节点的审批角色。

（3）选择审批流程的提交角色作为级别主体，以该提交角色为判断标准判断级别，例如，若提交角色为角色d2，则：①当n=0时，由工作流审批流程提交角色d2担任该审批节点的审批角色；审批节点在设置审批角色时部门级别n可以设置为0，即选择提交角色d2本身作为审批节点中的审批角色，在审批流程结束前，可以由提交角色d2本身进行审批确认，选择不同意后可返回重新审批，选择同意进入下一环节，多出了提交角色复核程序，避免出现审批结果不正确或审批结果与提交角色的预期不符而需要新建（重新提交）审批流程的问题，减少了系统内耗，提高了审批流程效率和可靠性。

举例：提交角色d2提交了一个10000元的报销审批请求，因提交角色d2所提交的内容有误或其他原因，经过多级审批后核准报销金额被修改为500元，在审批流程结束之前，由提交角色d2作为审批角色进行复核确认即可发现问题，选择不同意后可返回重新审批，选择同意进入下一环节，无需新建（重新提交）一个审批流程。

②当n=1时，由工作流审批流程提交角色d2所在部门D的部门主管角色d1担任该审批节点的审批角色；（若提交角色是d1，他是其所在部门D的部门主管角色，则由提交角色所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色）③当n=2时，由工作流审批流程提交角色d2所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色；④当n=3时，由工作流审批流程提交角色d2所在部门D的上上一级部门B的部门主管角色b1担任该审批节点的审批角色；⑤当n=4时，由工作流审批流程提交角色d2所在部门D的上上上一级部门A的部门主管角色a1担任该审批节点的审批角色；⑥以此类推；⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色。例如：对于角色d2而言，部门级别最高应为4，当部门级别设置为6时，由最高级别部门A的部门主管角色a1担任该审批节点的审批角色。

本申请方案在原基于提交角色级别授权方式的优势基础上，还有另一优势：可以选择不同性质的角色，如合同表单上有合同签订角色、合同新增角色、合同负责角色，该审批节点本来不应该以提交角色判定级别，而应以合同签订角色判断级别。比如，报销表单（报销审批流程）的第一个审批节点要以提交角色的上级，另外的一个审批节点要以报销角色的上级审批（报销角色和提交角色可能是不同的角色）。

传统级别审批方式只能以审批流程提交角色作为判断标准来判断部门级别，无法自定义以表单中涉及到的其它角色或部门作为判断部门级别的标准，存在一定的使用局限性。

举例：对于一个合同审批流程，合同的签订角色请假了，让其同事替他发起了一个合同的审批，而系统认定其同事为流程的提交角色，在按级别审批时对于级别的判断均以其同事为准，无法客观体现合同签订角色所在的部门及职位。例如，合同的签订角色为市场部的销售人员1，其同事角色为研发部的研发人员1，原本该合同应由签订角色所在部门的主管-市场部主管角色审批，设置审批节点的审批级别为1时，系统会分配给研发人员1所在部门的主管-研发部主管角色进行审批，出现了审批流程的分配错误，使用不方便。

本申请在设置审批节点时，可以根据需要选择合同表单中的签订角色作为级别主体，以签订角色（而非一味默认为提交角色）作为标准判断部门级别，以此确定审批角色为市场部主管角色，使用更灵活、方便，通用性强。

【实施例5】按级别设置审批角色的步骤包括一个设置系统组织结构的步骤和一个按级别设置审批角色的步骤：所述设置系统组织结构的步骤包括以下子步骤：SS1：创建系统组织结构中所包含的部门及角色；SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色，如图4所示，部门A比部门B高一级，部门A比部门C高两级……；所述按部门级别设置审批角色的步骤包括：SSS1:选择（或设置）以按级别方式进行审批角色的设置；SSS2:选择审批流程对应表单中的角色性质字段、部门性质字段或者该审批流程的提交角色中的一个，作为级别主体；SSS3:填写具体的级别数值n，n为≥0的正整数（N的值也可采用其他符号代替，比如a、b、c、d，b比a大一级，c比a大两级，d比a大三级，以此类推）：（1）选择审批流程对应表单中的角色性质字段作为级别主体，以该选定的角色为判断标准判断级别，例如，流程的提交角色为d2，但选择的表单中的角色性质字段为签订角色，该签订角色为角色d3：①当n=0时，由选定的角色d3担任该审批节点的审批角色；②当n=1时，由选定的角色d3所在部门D的部门主管角色d1担任该审批节点的审批角色；若选定的角色为其所在部门的部门主管角色，则由选定的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；③当n=2时，由选定的角色d3所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色；④当n=3时，由选定的角色d3所在部门D的上上一级部门B的部门主管角色b1担任该审批节点的审批角色；⑤当n=4时，由选定的角色d3所在部门D的上上上一级部门A的部门主管角色a1担任该审批节点的审批角色；⑥以此类推；⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；例如：对于角色d3而言，部门级别最高应为4，当部门级别设置为6时，由最高级别部门A的部门主管角色a1担任该审批节点的审批角色。

⑧当n≥1时，需要设置“选定的角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点由指定组审批。

（2）选择审批流程对应表单中的部门性质字段作为级别主体，以该选定的部门为判断标准判断级别，例如，选择的表单中的部门性质字段为签订部门，该签订部门为部门D：①当n=0时，由选定部门D的部门主管角色d1担任该审批节点的审批角色；②当n=1时，由选定部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色；③当n=2时，由选定部门D的上上一级部门B的部门主管角色b1担任该审批节点的审批角色；④当n=3时，由选定部门D的上上上一级部门A的部门主管角色a1担任该审批节点的审批角色；⑤以此类推；⑥当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；例如：对于部门D而言，部门级别最高应为3，当部门级别设置为6时，由最高级别部门A的部门主管角色a1担任该审批节点的审批角色。

⑦当n≥1时，需要设置“选定的部门无上一级部门时”该审批节点由指定组审批。

（3）选择审批流程的提交角色作为级别主体，以该提交角色为判断标准判断级别，例如，若提交角色为角色d2，则：①当n=0时，由工作流审批流程提交角色d2担任该审批节点的审批角色；审批节点在设置审批角色时部门级别n可以设置为0，即选择提交角色d2本身作为审批节点中的审批角色，在审批流程结束前，可以由提交角色d2本身进行审批确认，选择不同意后可返回重新审批，选择同意进入下一环节，多出了提交角色复核程序，避免出现审批结果不正确或审批结果与提交角色的预期不符而需要新建（重新提交）审批流程的问题，减少了系统内耗，提高了审批流程效率和可靠性。

举例：提交角色d2提交了一个10000元的报销审批请求，因提交角色d2所提交的内容有误或其他原因，经过多级审批后核准报销金额被修改为500元，在审批流程结束之前，由提交角色d2作为审批角色进行复核确认即可发现问题，选择不同意后可返回重新审批，选择同意进入下一环节，无需新建（重新提交）一个审批流程。

②当n=1时，由工作流审批流程提交角色d2所在部门D的部门主管角色d1担任该审批节点的审批角色；（若提交角色是d1，他是其所在部门D的部门主管角色，则由提交角色所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色）③当n=2时，由工作流审批流程提交角色d2所在部门D的上一级部门C的部门主管角色c1担任该审批节点的审批角色；④当n=3时，由工作流审批流程提交角色d2所在部门D的上上一级部门B的部门主管角色b1担任该审批节点的审批角色；⑤当n=4时，由工作流审批流程提交角色d2所在部门D的上上上一级部门A的部门主管角色a1担任该审批节点的审批角色；⑥以此类推；⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色。例如：对于角色d2而言，部门级别最高应为4，当部门级别设置为6时，由最高级别部门A的部门主管角色a1担任该审批节点的审批角色。

⑧当n≥1时，需要设置“提交角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点由指定组审批；所述指定组审批包括以下三种情况中的一种：（1）指定组由一个或多个审批角色构成；（2）指定组由部门级别确定，选择级别主体时只能沿用该审批节点所选择的级别主体，且级别数值n只能设置为0；（3）指定组由部门级别确定，级别主体能够自主选择，指定组中包括一个或多个指定节点，当指定节点的级别数值n为非0时必须设置下一级指定节点，直到指定节点的级别数值n为0时，该审批节点的指定组设置完成。

系统提供了最高级别部门主管的审批机制，避免出现最高级别部门主管无法通过级别审批方式完成审批流程的问题。

举例：企业的最高级领导董事长提交审批请求时，在级别审批中，董事长虽没有上级部门，但设置了指定组来审批董事长提交的审批请求。

指定组审批包括以下三种情况中的一种：①指定组由一个或多个审批角色构成，例如，由多个监事会的成员构成指定组，董事长的审批请求由监事会成员进行审批；②指定组由部门级别确定，选择级别主体时只能沿用该审批节点所选择的级别主体，且级别数值n只能设置为0；此种情况用于应对企业组织结构发生变化的情况，例如，某公司原最高级别主管为总经理，而组织结构变化后增设了董事会，最高级别主管变为董事长，审批节点中级别数值为0则审批角色自动变为董事长，而不是固定为总经理，避免出现审批角色不能适配组织结构变化的问题；③指定组由部门级别确定，级别主体能够自主选择，指定组中包括一个或多个指定节点，当指定节点的级别数值n为非0时必须设置下一级指定节点，直到指定节点的级别数值n为0时，该审批节点的指定组设置完成；此种情况适用于普通部门角色审批最高级部门主管所提交的审批请求，例如，财务部门的财务主管可以审核董事长所提交的合同审批请求中涉及的开票信息，最终要由董事长确认。

【实施例6】如图5所示，所述的角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

所述的审批流程基于用户-角色-权限的三层结构模型，其中：角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；所述角色的构成为：岗位名+岗内编号；权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；用户层：用户通过关联的角色确定（获得）审批流程中的审批任务，并以关联角色的权限进行审批操作。

如图6所示，所述的审批流程包括一个开始节点、至少一个审批节点、一个结束节点：开始节点：发起/申请/提交工作流，进一步的，发起角色发起/申请/提交工作流作为开始节点，或者由第一个审批节点作为开始节点；审批节点：选择审批角色，并对审批角色进行授权；系统根据发起角色所提交的表单确定审批流程，针对需要有工作流的表单设计一个或多个审批流程，但一个角色只能选择该表单下的某一个审批流程（同一个角色只能存在于同一个表单的其中一个流程中）；举例: 采购合同表单有两种流程，分别为P1流程和P2流程，如果在P1流程的开始节点中选择了角色A，那么在P2流程的开始节点就不能再选择角色A，此时角色A新增一个采购合同的审批，提交审批时自动进入P1流程。

结束节点：审批流程流转到此节点时该审批节点审批结束，该结束节点不进行审批操作；或者以最后一个审批节点作为结束节点，该结束节点需要进行审批操作。

如图7所示，所述的用户-角色-权限三层结构模型的构建包括以下步骤：建立角色，每个角色是独立的个体，而非组/类；所述角色归属于部门，根据角色的工作内容对角色进行授权，且该角色的名称在该部门下唯一，该角色的编号在系统中唯一；所述账户跨部门调岗时，取消账户与原部门内的角色的关联，将账户（用户）与新部门内的角色进行关联；对建立的角色分别进行权限的授权；将用户关联到角色，其中，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

以下对通过独立个体性质角色对用户进行授权方式所具备的优势进行分析：用户通过其与角色的关联确定权限，如果要修改用户的权限，通过调整角色所拥有的权限以达到改变关联了该角色的用户的权限的目的。一旦用户关联角色后，该用户就拥有了该角色的所有操作权限。

角色对用户的关系为一对一（该角色与一个用户关联时，其他用户则不能再关联该角色；若该角色未被用户关联，则可以被其他用户选择关联）。用户对角色的关系为一对多（一个用户可以同时关联多个角色）。

角色的定义：角色不具有组/类/类别/岗位/职位/工种等性质，而是一个非集合的性质，角色具有唯一性，角色是独立存在的独立个体；在企事业单位应用中相当于岗位号（此处的岗位号非岗位，一个岗位同时可能有多个员工，而同一时段一个岗位号只能对应一个员工）。

举例：某个公司系统中可创建如下角色：总经理、副总经理1、副总经理2、北京销售一部经理、北京销售二部经理、北京销售三部经理、上海销售工程师1、上海销售工程师2、上海销售工程师3、上海销售工程师4、上海销售工程师5……用户与角色的关联关系：若该公司员工张三任职该公司副总经理2，同时任职北京销售一部经理，则张三需要关联的角色为副总经理2和北京销售一部经理，张三拥有了这两个角色的权限。

传统角色的概念是组/类/岗位/职位/工种性质，一个角色能够对应多个用户。而本申请“角色”的概念相当于岗位号/工位号，也类同于影视剧中的角色：一个角色在同一时段（童年、少年、中年……）只能由一个演员来饰演，而一个演员可能会分饰多角。

在创建角色之后，可以在创建用户的过程中关联角色，也可以在用户创建完成后随时进行关联。用户关联角色后可以随时解除与角色的关联关系，也可以随时建立与其他角色的关联关系。

所述角色的构成为：岗位名+岗内编号。例如：车间生产工人1、车间生产工人2、车间生产工人3……角色是独立个体，相当于岗位号、工位号的概念，不同于传统权限管理体系中的角色，传统体系中角色的概念是岗位/职位/工种等的组/类性质。

【实施例7】以下举例员工张三进入某公司后，员工、用户与角色之间的关系为：1、新入职：员工新入职，直接为该用户（员工）选择相应的岗位号/工位号的角色进行关联即可，例：张三入职公司（公司为张三分配了一个张三用户），工作内容是在销售一部，负责北京区域冰箱产品的销售（对应的角色是销售一部下的“销售工程师5”这个角色），则张三用户直接选择“销售工程师5”这个角色关联即可。

2、增加职位：张三工作一段时间后，公司还安排张三负责北京区域电视产品的销售（对应的角色是销售一部下的“销售工程师8”这个角色）并兼任售后部主管（对应售后部主管1这个角色），则张三用户再增加关联销售一部下的“销售工程师8”和售后部下的“售后部主管1”这两个角色，此时，张三员工关联了三个角色，分别为销售一部下的“销售工程师5”、“销售工程师8”和售后部下的“售后部主管1”，张三用户则拥有了这三个角色的权限。

3、减少职位：又过了一段时间，公司决定让张三任职售后部经理（对应售后部下“售后部经理”这个角色），且不再兼任其他工作。则张三用户关联售后部下“售后部经理”这个角色，同时取消此前关联的三个角色（销售一部下的“销售工程师5”、“销售工程师8”和售后部下的“售后部主管1”），此时，张三用户只拥有售后部下“售后部经理”这个角色的权限。

4、角色权限的调整（针对角色本身所拥有的权限的调整）：如公司决定增加售后部经理的权限，则只需增加对售后部经理这个角色的授权即可，则张三用户因为售后部经理这个角色的权限增加了，张三用户的权限也增加了。

5、离职：一年后，张三离职了，则取消张三用户与售后部下“售后部经理”这个角色的关联即可。

举例：公司在动态的经营中，职员的入职、离职是经常持续发生的，但岗位号/工位号的变化非常少(甚至在一定时期内是没有变化的)。

传统授权方法：在系统功能点多的情况下，以传统的组/类性质的角色进行授权，不仅授权工作量大，繁杂，而且很容易出错，甚至出错了在短时间内都不容易发现，容易对系统使用方造成损失。

本申请授权方法：本申请是对岗位号/工位号性质的角色进行授权，用户关联角色而确定（获得）权限，则对用户权限的控制，通过简单的用户-角色的关联关系来实现，让权限控制变得简单、易操作，清晰明了，大幅度提高了授权效率和授权可靠性。

以上所述仅是本发明的优选实施方式，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。

Claims (10)

1.工作流审批节点高效审批方法，其特征在于，包括一个设置审批节点审批角色的步骤和一个审批角色高效审批的步骤：

所述设置审批节点审批角色的步骤包括以下方式中的任意一种或多种的组合：

（1）直接指定一个或多个角色作为审批角色；

（2）直接指定一个或多个部门，以部门的部门主管角色担任审批角色；

（3）按级别设置审批角色；

所述审批角色高效审批的步骤：一个审批节点包含一个或多个审批角色，以第一个提交审批意见的审批角色的审批意见作为该审批节点的审批结果，只要有任意一个审批角色提交审批意见，该审批节点审批结束。

2.根据权利要求1所述的工作流审批节点高效审批方法，其特征在于：还包括一个设置审批角色对审批流程涉及的表单字段内容查看权限的步骤，同一审批节点的不同审批角色对表单字段内容的查看/修改权限相同。

3.根据权利要求1所述的工作流审批节点高效审批方法，其特征在于：还包括一个设置审批节点下一级流转节点的步骤，下一级流转节点包括两种：

（1）该审批节点的审批结果为“通过”时的一个或多个通过节点；

（2）该审批节点的审批结果为“驳回”时的一个或多个驳回节点；

当通过/驳回时有多个通过节点/驳回节点可选时，由该第一个提交审批意见的审批角色选择一个通过节点/驳回节点；当通过/驳回时只有一个通过节点/驳回节点时，由该第一个提交审批意见的审批角色选择该通过节点/驳回节点，或者由系统自动进入该通过节点/驳回节点。

4.根据权利要求1所述的工作流审批节点高效审批方法，其特征在于：所述的角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

5.根据权利要求4所述的工作流审批节点高效审批方法，其特征在于：所述的审批流程基于用户-角色-权限的三层结构模型，其中：角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；

权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；

用户层：用户通过关联的角色确定审批流程中的审批任务，并以关联角色的权限进行审批操作。

6.根据权利要求5所述的工作流审批节点高效审批方法，其特征在于：所述的用户-角色-权限三层结构模型的构建包括以下步骤：

建立角色，每个角色是独立的个体，而非组/类；所述角色归属于部门，根据角色的工作内容对角色进行授权，且该角色的名称在该部门下唯一，该角色的编号在系统中唯一；所述账户跨部门调岗时，取消账户与原部门内的角色的关联，将账户与新部门内的角色进行关联；

对建立的角色分别进行权限的授权；

将用户关联到角色，其中，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

7.根据权利要求1所述的工作流审批节点高效审批方法，其特征在于：所述的审批流程包括一个开始节点、至少一个审批节点、一个结束节点：

开始节点：审批流程开始；

审批节点：选择审批角色，并对审批角色进行授权；

结束节点：审批流程结束。

8.根据权利要求1所述的工作流审批节点高效审批方法，其特征在于：所述按级别设置审批角色的步骤包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：

所述设置系统组织结构的步骤包括以下子步骤：

SS1：创建系统组织结构中所包含的部门及角色；

SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色；

所述按部门级别设置审批角色的步骤包括：

SSS1:选择以按级别方式进行审批角色的设置；

SSS2:选择审批流程对应表单中的角色性质字段、部门性质字段或者该审批流程的提交角色中的一个，作为级别主体；

SSS3:填写具体的级别数值n，n为≥0的正整数：

（1）选择审批流程对应表单中的角色性质字段作为级别主体，以该字段对应的角色为判断标准判断级别：

①当n=0时，由该字段对应的角色担任该审批节点的审批角色；

②当n=1时，由该字段对应的角色所在部门的部门主管角色担任该审批节点的审批角色；若该字段对应的角色为其所在部门的部门主管角色，则由该字段对应的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；

③当n=2时，由该字段对应的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；

④当n=3时，由该字段对应的角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；

⑤当n=4时，由该字段对应的角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；

⑥以此类推；

⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；

（2）选择审批流程对应表单中的部门性质字段作为级别主体，以该字段对应的部门为判断标准判断级别：

①当n=0时，由该字段对应的部门的部门主管角色担任该审批节点的审批角色；

②当n=1时，由该字段对应的部门的上一级部门的部门主管角色担任该审批节点的审批角色；

③当n=2时，由该字段对应的部门的上上一级部门的部门主管角色担任该审批节点的审批角色；

④当n=3时，由该字段对应的部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；

⑤以此类推；

⑥当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；

（3）选择审批流程的提交角色作为级别主体，以该提交角色为判断标准判断级别：①当n=0时，由工作流审批流程提交角色担任该审批节点的审批角色；

②当n=1时，由工作流审批流程提交角色所在部门的部门主管角色担任该审批节点的审批角色；若提交角色为其所在部门的部门主管角色，则由提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；

③当n=2时，由工作流审批流程提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；

④当n=3时，由工作流审批流程提交角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；

⑤当n=4时，由工作流审批流程提交角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；

⑥以此类推；

⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色。

9.根据权利要求8所述的工作流审批节点高效审批方法，其特征在于：所述表单中的角色性质字段、部门性质字段为必填单选项。

10.根据权利要求1所述的工作流审批节点高效审批方法，其特征在于：所述按级别设置审批角色的步骤包括一个设置系统组织结构的步骤和一个按部门级别设置审批角色的步骤：

所述设置系统组织结构的步骤包括以下子步骤：

SS1：创建系统组织结构中所包含的部门及角色；

SS2：设置各部门之间的层级关系，并设置各部门的部门主管角色；

所述按部门级别设置审批角色的步骤包括：

SSS1:选择以按级别方式进行审批角色的设置；

SSS2:选择审批流程对应表单中的角色性质字段、部门性质字段或者该审批流程的提交角色中的一个，作为级别主体；

SSS3:填写具体的级别数值n，n为≥0的正整数：（1）选择审批流程对应表单中的角色性质字段作为级别主体，以该字段对应的角色为判断标准判断级别：

①当n=0时，由该字段对应的角色担任该审批节点的审批角色；

②当n=1时，由该字段对应的角色所在部门的部门主管角色担任该审批节点的审批角色；若该字段对应的角色为其所在部门的部门主管角色，则由该字段对应的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；

③当n=2时，由该字段对应的角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；

④当n=3时，由该字段对应的角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；

⑤当n=4时，由该字段对应的角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；

⑥以此类推；

⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；

⑧当n≥1时，需要设置“该字段对应的角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点由指定组审批；

（2）选择审批流程对应表单中的部门性质字段作为级别主体，以该字段对应的部门为判断标准判断级别：

①当n=0时，由该字段对应的部门的部门主管角色担任该审批节点的审批角色；

②当n=1时，由该字段对应的部门的上一级部门的部门主管角色担任该审批节点的审批角色；

③当n=2时，由该字段对应的部门的上上一级部门的部门主管角色担任该审批节点的审批角色；

④当n=3时，由该字段对应的部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；

⑤以此类推；

⑥当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；

⑦当n≥1时，需要设置“该字段对应的部门无上一级部门时”该审批节点由指定组审批；

（3）选择审批流程的提交角色作为级别主体，以该提交角色为判断标准判断级别：①当n=0时，由工作流审批流程提交角色担任该审批节点的审批角色；

②当n=1时，由工作流审批流程提交角色所在部门的部门主管角色担任该审批节点的审批角色；若提交角色为其所在部门的部门主管角色，则由提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；

③当n=2时，由工作流审批流程提交角色所在部门的上一级部门的部门主管角色担任该审批节点的审批角色；

④当n=3时，由工作流审批流程提交角色所在部门的上上一级部门的部门主管角色担任该审批节点的审批角色；

⑤当n=4时，由工作流审批流程提交角色所在部门的上上上一级部门的部门主管角色担任该审批节点的审批角色；

⑥以此类推；

⑦当部门级别的设置超过系统组织结构中的最高级别部门时，由最高级别部门的部门主管角色担任该审批节点的审批角色；

⑧当n≥1时，需要设置“提交角色为其所在部门的部门主管角色，且该部门无上一级部门时”该审批节点由指定组审批；

所述指定组审批包括以下三种情况中的一种：

（1）指定组由一个或多个审批角色构成；

（2）指定组由部门级别确定，选择级别主体时只能沿用该审批节点所选择的级别主体，且级别数值n只能设置为0；

（3）指定组由部门级别确定，级别主体能够自主选择，指定组中包括一个或多个指定节点，当指定节点的级别数值n为非0时必须设置下一级指定节点，直到指定节点的级别数值n为0时，该审批节点的指定组设置完成。