管理系统中事务处理的管理方法与流程

本发明涉及一种erp、crm等管理系统中事务处理的管理方法。

背景技术

现有企业管理系统中对于意见/建议、投诉等事务的处理，通常是由公司安排给指派人进行指派，指派人再根据事务的具体内容指定被指派人来处理，这种传统的处理方式无法满足事务提交人对事务隐私性的需求，例如，对于投诉事务，如果由公司安排指派人，则有可能安排给被投诉人或被投诉人的下级来处理，则被投诉人很可能获得被投诉信息，这很可能直接影响投诉事务的公正处理，甚至对投诉提交人带来不利影响。这种情况会压抑员工反映公司存在的各种问题，对公司发展不利。

另外，传统企业管理系统中进行事务指派的都是固定的某员工/用户，当指派人离职、调岗时，该指派人涉及到的所有事务必须要作相应交接，工作量大、容易出错或遗漏。如不及时另设指派人，很有可能造成事务指派的滞后问题，一方面，会影响紧急事务的处理时效（如解决生产车间存在的安全隐患的意见/建议），有可能造成不可预估的损失；另一方面，员工提交的事务迟迟未得到响应，会给员工提交意见/建议、投诉等事务的积极性带来负面影响。

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

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

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

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

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

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

员工/用户的权限发生变化时，要么员工/用户脱离角色，要么新增角色来满足工作要求。第一种方式的缺陷同上述“直接对用户授权”方式的缺陷。第二种方式，新增角色便涉及到角色的新建、关联、授权工作，特别在角色多、角色关联的用户也多的情况下，角色具体关联了哪些用户是很难记住的。

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

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

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

技术实现要素：

本发明的目的在于克服现有技术的不足，提供一种管理系统中事务处理的管理方法，为事务提交人提供指定某用户/员工处理的功能，保障提交人提交的事务的隐私不被泄露，保证事务的公正处理。

本发明的目的是通过以下技术方案来实现的：管理系统中事务处理的管理方法，包括以下步骤：事务提交人提交事务处理请求：如果事务提交人要指定某用户/员工来处理该事务，由事务提交人在提交事务处理请求时指定其要指定的用户/员工，该事务处理请求被指定给该被指定的用户/员工；否则，事务提交人提交事务处理请求时，该事务处理请求被指定给预设的一个或多个指派者，指派者根据事务提交人提交的事务处理请求的内容指定被指派用户/员工来处理。

事务提交人指定其要指定的用户/员工，该事务处理请求被指定给该被指定的用户/员工后，该被指定的用户/员工不能将该事务转交给任何其他用户/员工。

所述的指派者包括员工、用户、组/类性质角色、独立个体性质角色中的一种或多种的组合。

所述的指派者为独立个体性质角色，独立个体性质角色与组/类性质角色不同，同一时段一个独立个体性质角色只能关联唯一的用户，而一个用户关联一个或多个独立个体性质角色。

在角色创建时或角色创建后为该角色选择一个部门，则该角色归属于该部门，根据角色的工作内容对角色进行授权（用户与角色进行关联后，用户获得关联角色的权限），且该角色的名称在该部门下唯一，该角色的编号在系统中唯一；所述用户跨部门调岗时，取消用户与原部门内的角色的关联，将用户与新部门内的角色进行关联。

指派者在指定被指派用户/员工时还包括一个填写指派备注的步骤。

管理系统中事务处理的管理方法，还包括一个被指派用户/员工选择是否接受指派者所指派事务的步骤，如果接受，以以下三种方式之一结束该次指派：（1）部分完成：事务提交人提交的事务未处理完结，还需要后续处理，被指派用户/员工确认部分完成后，该事务提交人提交的事务返回至指派者，等待指派者再次指派；（2）转交：事务提交人提交的事务未处理完结，还需要后续处理，被指派用户/员工确认转交并指定被转交用户/员工后，由该被转交用户/员工进行后续处理；（3）完结：事务提交人提交的事务全部处理完成/结束。

管理系统中事务处理的管理方法，还包括一个设置一个或多个监督者的步骤，在事务提交人所提交的事务处理完结后，监督者对事务提交人所提交的事务进行评价。

管理系统中事务处理的管理方法，还包括一个设置一个或多个监督者的步骤，在事务提交人所提交的事务处理完结后，监督者对指派者和/或每个参加事务处理的员工/用户进行评价。

在事务提交人所提交的事务处理完结后，还包括一个事务提交人对事务处理结果进行评价的步骤。

本发明的有益效果是：（1）本发明提供一种管理系统中事务处理的管理方法，为事务提交人提供了指定某用户/员工处理的功能，且该事务不能被转交给其他人处理，可保障提交人提交的事务的隐私不被泄露，保证了事务的公正处理。

例如：某员工张三要投诉常务副总经理，可以指定总经理来处理，总经理不能将该事务转交给其他任何人处理，因为总经理转交给任何人，该投诉信息都有可能被流传到常务副总经理处，因为不能转交，则只有投诉人本人和总经理知道，没有任何第三方知道，收到该投诉后即使总经理要去找常务副总了解情况，总经理也会考虑到保护投诉人隐私而技巧性地侧面了解，而不会直接将投诉问题向常务副总经理公开。

（2）采用独立个体性质角色作为指派者，发生指派者离职、调岗时，只需将新任指派人关联到指派角色即可自动获得当前所有的事务，减少了事务交接的工作量，而且能够实现无缝对接，不会出现事务指派的滞后或遗漏，确保紧急事务得到及时处理，避免员工提交的事务迟迟得不到响应而对员工积极性带来负面影响。

例如：原指派人张三离职或调岗，不再担任指派人，传统方式需要将张三所涉及到的所有事务全部交接给新接任的指派人李四，工作量大，容易出错或遗漏。如果未及时完成交接工作，会造成事务指派的滞后。本申请指派者是指派角色，所有事务都安排给指派角色，当张三离职、调岗时，直接由系统管理员（或相应管理员）取消张三对应的用户与指派角色的关联，再将新任的李四对应的用户关联到指派角色，则李四自动获得了指派角色当前所有事务。通过角色的关联就顺带实现了指派者手上事务的交接，工作量小，使用方便。

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

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

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

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

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

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

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

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

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

附图说明

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

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

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

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

具体实施方式

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

【实施例1】管理系统中事务处理的管理方法，所述的事务指问题、意见、建议、投诉、工作任务等中的一种或多种，包括以下步骤：事务提交人提交事务处理请求：（1）如果事务提交人要指定某用户/员工来处理该事务，由事务提交人在提交事务处理请求时指定其要指定的用户/员工，该事务处理请求被指定给该被指定的用户/员工。这种方式下，被指定的用户/员工不可以拒签/退回该事务（只能接受/签收），且只能以“完结”的方式结束事务提交人的该次指定；即使处理不了，也需要填写一个原因说明并结束（即：选择或确定“完结”）该事务的处理。被事务提交人指定的用户/员工不能转交但又觉得该事务不该他本人处理的（或觉得可以让提交人找其他人处理），可以回复：建议找某某处理（这也是一种处理结果），然后确认该事务处理完结。提交人提交的事务处理请求完结后，事务提交人可对这个事务的处理结果打分，事务提交人可以根据情况另外再发起一次事务请求，指定另外的员工/用户来处理，或采用方式（2）进行后续处理。

进一步的：被事务提交人指定的用户/员工可以拒签/退回/不处理事务提交人提交的事务（比如董事长接收了很多的信息/事务，有的是干扰信息，有的信息/事务董事长只需要了解等原因而不需要进一步处理）；

进一步的：可以设置哪些被事务提交人指定的用户/员工可以拒签/退回/不处理事务提交人提交的事务，则被授此权限的员工/用户就可以拒签/退回/不处理提交人提交的事务（比如可以设置董事长拥有该权限）；

进一步的：可以设置哪些事务提交人/被指派者/参加事务处理的员工/人或员工提交的事务/指派者/被指定的用户或员工不被评价（比如可以设置被指定用户/员工“董事长：张三”不被评价）。

（2）如果事务提交人不清楚该事务该由谁处理或不想指定事务处理人，事务提交人提交事务处理请求时，该事务处理请求被指定给预设的一个或多个指派者，指派者根据事务提交人提交的事务处理请求的内容指定被指派用户/员工来处理。指派者在选择被指派用户/员工时还可以填写指派备注，针对事务进行相关说明。

被指派用户/员工可以选择是否接受指派者所指派的事务（接受/签收、退回/拒签），如果接受（指派者指派的用户/员工在被指派时可以选择是否接受指派者所指派的事务，被转交用户/员工在被转交时也可以选择是否接受转交用户/员工所转交的事务；但事务提交人在提交事务处理请求时指定的用户/员工只能接受/签收，不能退回/拒签），以以下三种方式之一结束该次指派（事务提交人在提交事务处理请求时指定的用户/员工只能以以下“完结”的方式结束事务提交人的指定）：（1）部分完成：事务提交人提交的事务未处理完结，还需要后续处理，被指派用户/员工确认部分完成后，该事务提交人提交的事务返回至原指派者，等待原指派者指派给其他用户/员工。

（2）转交：事务提交人提交的事务未处理完结，还需要后续处理，被指派用户/员工确认转交并指定被转交用户/员工后，由该被转交用户/员工进行后续处理；被转交用户/员工可以再次转交（被转交用户/员工也以“部分完成、转交、完结”这三种方式之一结束该次转交，此三种方式为：“1、部分完成：事务提交人提交的事务未处理完结，还需要后续处理，被转交用户/员工确认部分完成后，该事务提交人提交的事务返回至原指派者，等待原指派者指派给其他用户/员工；2、转交：事务提交人提交的事务未处理完结，还需要后续处理，被转交用户/员工确认转交并指定另外的被转交用户/员工后，由该另外的被转交用户/员工进行后续处理；3、完结：事务提交人提交的事务全部处理完成/结束，被转交用户/员工确认完结，则该事务的处理到此结束，不进行后续处理”）。

（3）完结：事务提交人提交的事务全部处理完成/结束，完结并不是该事务一定已经解决，该事务不处理也可以确定为完结，即该事务完结或该事务的处理到此结束，被指派用户/员工确认完结后，该事务的处理到此结束，不进行后续处理（事务提交人在提交事务处理请求时指定的用户/员工只能以“完结”的方式结束事务提交人的指定，事务提交人在提交事务处理请求时指定的用户/员工若确认“完结”，则事务提交人提交的事务全部处理完成/结束，完结并不是该事务一定已经解决，该事务不处理也可以确定为完结，即该事务完结或该事务的处理到此结束，被指定用户/员工确认完结后，该事务的处理到此结束）。

进一步的：指派者可以选择其权限内可查阅的和该提交事务有关的其他事务/信息/数据等与该提交事务进行关联，便于该提交事务的处理人员在处理该提交事务时可以查阅相关信息，有助于对提交事务的处理。比如有个事务处理完结后，事务提交人不满意（可能该事务没被处理或对处理结果不满意），原事务提交人再次发起事务提交给指派者，则指派者可以选择此前该人提交的事务与该次提交的事务关联，以便于后续处理人员能够了解该提交事务的前后相关情况。

被指派用户/员工或被转交用户/员工或被指定用户/员工在事务处理过程中（在接受指派/转交/指定后，被指派用户/员工或被转交用户/员工在选择以上三种方式之一结束其指派或转交之前，被指定用户/员工在选择“完结”方式结束其指定之前），可以填写事务处理信息和相关信息并保存，以供相关人员了解事务处理进度及详情。

相应的，所述的指派者收到的事务处理进度包括：（1）未处理：包括已指派未处理和未指派；（2）已处理过，但未完结；（3）完结：事务提交人提交的事务已处理完结。还可以以标注事务处理程度等方式显示对提交事务的处理情况，以方便快速了解提交事务的处理情况，尤其是了解/监督有的事务并没有处理，但还是选择了完结。

事务提交人可以是员工、用户、组/类性质角色、独立个体性质角色等。事务提交人可以看到自己所提交的所有事务，以及每个事务的处理过程及详细处理记录（在事务处理过程中，事务处理的进度要随时反馈给事务提交人，而且可以在处理环节填写处理记录等信息），进一步的，也可以设置为事务提交人只能看到必要的处理进度信息，但看不到敏感的处理记录。指派者可以查看所有经其自己指派的事务内容、处理过程及相关处理信息，非自己指派的事务无法查看，进一步的，也可以设置为指派人只能看到必要的处理进度信息，但看不到敏感的处理记录；事务处理完结后指派者对自己指派的事务，要么什么都看得到（事务内容、处理过程及相关处理信息），或什么都看不到（事务内容、处理过程及相关处理信息）；或，指派者能够看到指派的事务内容，但看不到处理过程及相关处理信息。

本实施例为事务提交人提供了指定某用户/员工处理的功能，且事务提交人指定其要指定的用户/员工，该事务处理请求被指定给该被指定的用户/员工后，该被指定的用户/员工不能将该事务转交给任何其他用户/员工。可保障提交人提交的事务的隐私不被泄露，保证了事务的公正处理。

例如：某员工张三要投诉常务副总经理，可以指定总经理来处理，总经理不能将该事务转交给其他任何人处理，因为总经理转交给任何人，该投诉信息都有可能被流传到常务副总经理处，因为不能转交，则只有投诉人本人和总经理知道，没有任何第三方知道，收到该投诉后即使总经理要去找常务副总了解情况，总经理也会考虑到保护投诉人隐私而技巧性地侧面了解，而不会直接将投诉问题向常务副总经理公开。

【实施例2】设置一个监督者，在事务提交人所提交的整个事务处理完结后，监督者对事务提交人所提交的事务进行评价，监督者还可对指派者和/或每个参加事务处理的员工/用户进行评价。评价方式包括打分、满意/不满意评价等中的一种或多种，评价的角度包括：态度、处理效率、结果、过程等中的一种或多种。

由监督者进行打分，主要是考虑到有些事务是对公司有积极作用的。事务必须在处理完结后才能打分，因为有可能一开始看起来事务很有价值，但是经过处理人分析处理后发现该事务其实没有什么价值。对事务的打分只能是0分及以上的分数，不能是负分，对参加事务处理的员工/用户的打分可以是负分。

在事务提交人所提交的整个事务处理完结后，事务提交人也可以对事务处理结果进行评价，评价事务处理效率、结果满意度等。

也可设置为：监督者不能对事务提交人直接指定的用户/员工及其处理过程进行评价，也不能对该事务进行评价，因为评价可能泄露隐私。当然也可根据需要设置为：监督者可以对事务提交人直接指定的用户/员工（也可以设置为：设置监督者可以对哪些指派者/对哪些事务处理者/对哪些事务处理角色关联的用户/对哪些事务处理角色关联的用户对应的员工）及其处理过程进行评价，也能对该事务（对应事务）进行评价。

【实施例3】所述的指派者包括员工、用户、组/类性质角色、独立个体性质角色等。

本实施例中，所述的指派者为独立个体性质角色，独立个体性质角色与组/类性质角色不同，如图4所示，同一时段一个独立个体性质角色只能关联唯一的用户，而一个用户关联一个或多个独立个体性质角色。一个用户对应一个员工，一个员工对应一个用户，员工通过其对应的用户关联的角色（独立个体性质角色）确定（获得）权限。员工和用户相互均为1对1关系且终生绑定，用户对应员工后，则该用户归属于该员工，用户不能再关联其他的员工；若该员工离职，该用户也不能对应其他的员工，员工再次入职后，该员工还是使用原来的用户。

在角色创建时或角色创建后为该角色选择一个部门，则该角色归属于该部门，根据角色的工作内容对角色进行授权，且该角色的名称在该部门下唯一，该角色的编号在系统中唯一；所述用户跨部门调岗时，取消用户与原部门内的角色的关联，将用户与新部门内的角色进行关联。

在事务提交人明确由谁来处理其事务的情况下，指定用户/员工来处理其事务而不是角色：因为如果指定的是角色，在企业长期运营涉及员工变动过程中，一个角色仍可能涉及到多名用户/员工，无法确保该事务的隐私，所以只指定确定的用户/员工来处理这类事务。

采用独立个体性质角色作为指派者，发生指派者离职、调岗时，只需将新任指派人（指派人对应的用户）关联到指派角色即可自动获得当前所有的事务，减少了事务交接的工作量，而且能够实现无缝对接，不会出现事务指派的滞后或遗漏，确保紧急事务得到及时处理，避免员工提交的事务迟迟得不到响应而对员工积极性带来负面影响。

例如：原指派人张三离职或调岗，不再担任指派人，传统方式需要将张三所涉及到的所有事务全部交接给新接任的指派人李四，工作量大，容易出错或遗漏。如果未及时完成交接工作，会造成事务指派的滞后。本申请指派者是指派角色，所有事务都安排给指派角色，当张三离职、调岗时，直接由系统管理员（或相应管理员）取消张三对应的用户与指派角色的关联，再将新任的李四对应的用户关联到指派角色，则李四自动获得了指派角色当前所有事务。通过角色的关联就顺带实现了指派者手上事务的交接，工作量小，使用方便。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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