标准化多维链式预授权管理系统的制作方法

本发明涉及企业授权管理系统，尤其是一种链式预授权管理系统。

背景技术：

当企业规模达到一定程度，企业负责人就会难以通过自己随时发号施令来带领团队开展业务。这时企业负责人就需要考虑设置授权矩阵，向下属分配管理权限，进行授权管理。与此同时，相应的审批流程也会建立，而不再是总经理一支笔审批。

传统的授权管理受限于工具，权限分配往往仅能做得按岗位分配。但是，即使岗位相同，也可能因为如下原因管理者需要考虑分配给不同程度的权限，或者对权限做出调整：

下属的管理能力处于不同的发展阶段；

下属的管理风格不同；

企业内部外部的实际情况已经发生变化；

在实际业务操作中，管理者的确会根据以上情况对实际授权自觉或不自觉地不断做出调整，实际的业务沟通、审批也在相应的不断调整，但是作为正式授权管理依据的授权矩阵（或者叫授权明细表、审批权限表等等之类）往往不能及时更新，相应的正式的审批流也就因为不能及时更新，成为不能没有的、但又只是走形式的“影子审批”。一旦形成台面下的实际审批和台面上的影子审批这样重复审批流程，业务效率降低、审批结果矛盾就不可避免。组织中常见的管理问题如审批事项多如繁星、管理者不堪重负，审批流程冗长、效率低下，审批者跟风表态、集体免责，博弈行为、影子审批流问题造成的上下沟通障碍都与此有或多或少的关系。因此，要解决这些问题，不光需要有正确的授权管理理念，还需要更有效率的授权管理工具。问题的解决之道在于通过授权管理工具来清晰界定权限属性，建立责任追溯和激励机制推动授权体系有效地运转；对授权行为和权限行使进行监督，明确授权人与被授权人的责任；为事后问题分析、考核奖惩、内部审计留下分析线索，形成闭环机制。

技术实现要素：

为解决企业组织授权管理过程中的上述这些问题，本发明提供一种标准化多维链式预授权管理系统，通过事务管理平台将业务全过程分解为相对独立而又环环紧扣的预授权、业务申请、决定、业务执行四个关键步骤，利用多维链式预授权方式向一线管理者和业务执行者明确规范地传递战略意图和行动规则框架，保证了实际业务能够被充分掌控，使得授权体系有效运转。本发明采用的技术方案是：

一种标准化多维链式预授权管理系统，包括一个事务管理平台，事务管理平台上设有标准化预授权语言，事务管理平台的使用者通过标准化预授权语言与事务管理平台交互，完成业务过程的四个步骤，包括：预授权、业务申请、决定、业务执行；

事务管理平台的使用者包括授权人、被授权人即决定人、关注人和业务申请人。

进一步地，所述标准化预授权语言中定义了预授权要素和动作；

预授权要素包括：

1.1)业务场景：指由因业务需要而发生的消费行为的一系列要素的组合；

1.2)预授权中的角色，包括：

提出业务申请的业务申请人，拥有提交权；

能够参与发表意见，提供决策支持、对业务进行评价的关注人，拥有审核权、知情权；

负责最终对一项业务申请是否可以开始执行作出决定的决定人，拥有审批权；

将自己的权限分解授予下级的授权人；

1.3)权限维度及条件范围；在事务管理平台中可选择的服务、商品按与权限维度一致的维度进行分类；

1.4)授权有效期；

1.5）可使用次数：实际业务申请可以调用预授权文件作为依据的最大次数；

1.6)授权状态：有效、失效、待确认；

1.7)业务场景授权id：针对每个业务场景进行的授权都会有相应的唯一的id；

1.8)上级业务场景授权id：除最高一级业务场景授权外，每个业务场景进行的授权都会有相应的上级授权id作为依据；

动作要素包括：

2.1)预授权：针对某个设定的业务场景，已经从上一级得到预授权的某个授权人，在自己得到的授权权限范围内，区分出不同的子业务场景，分别设定业务申请人名单、关注人、决定人，以及包含权限维度和条件范围在内的授权要素；

2.2)转授权：对于某个业务场景，决定人以得到的上一级预授权为依据，把业务场景拆分成为多个子业务场景或者不拆分，以自己为授权人，再转授给他人；转授的预授权每个权限维度的条件范围必须小于等于作为转授权依据的上一级预授权中每个权限维度的条件范围；

2.3)授权修改：对预授权的要素内容进行修改；修改后的预授权的每个权限维度的条件范围仍旧必须小于等于作为转授权依据的上一级预授权中每个权限维度的条件范围。

进一步地，

业务场景中一系列要素的组合包括：消费行为的时间、地点、涉及的人物、消费行为的多个维度。

进一步地，每项业务预授权必须有唯一的一个或一组决定人，在出现必须一致同意的共同决定这种特殊情形时，决定人为不分先后的一组人，业务必须得到所有决定人同意才能执行。

进一步地，事务管理平台对实际业务抽样出多个权限维度，并进行标准化；利用多个权限维度组合进行授权管理，每个权限维度具有相应的条件范围。

进一步地，事务管理平台中的预授权文件体系构成了业务场景驱动的授权链；事务管理平台让授权人按业务场景事件进行预授权，被授权人通过将得到的预授权进行逐级向下的转授权，形成成系列的适用于不同业务场景的授权链条。

进一步地，事务管理平台中设置了授权冲突控制机制；上级业务场景授权修改时，记录修改时间，由后台对所有下级业务场景授权进行授权冲突检查，并提醒授权人是否强制要求修改下级业务场景授权，如果是，提醒“可能影响正常业务”，在下级修改授权前将所有下级授权变成“待确认”状态；待下级修改无冲突后方可生效；如果否，仅向被授权人提醒冲突，下级授权继续生效。

进一步地，事务管理平台通过数据接口接入电商平台；

业务申请人通过事务管理平台从事务管理平台中的预授权文件发起、转到电商平台中在预授权的权限范围控制之下搜索、选择所需商品和服务；或先进入电商平台选择所需商品和服务，下单后提供预授权文件号，系统自动检查选择商品和服务是否符合预授权规定的权限范围。

进一步地，业务过程的四个步骤具体包括：

步骤1：预授权

授权人根据业务需要，针对不同业务场景，将自己的权限进行分解，分别授予一系列被授权人的过程；

预授权在事务管理平台中通过以下两个步骤实现：

（1）授权人通过终端使用事务管理平台提供的标准化预授权语言向事务管理平台上传预授权文件；

（2）事务管理平台向预授权文件中列明的被授权人即决定人、业务申请人、关注人推送预授权文件；

步骤2：业务申请

（3）业务申请人使用终端通过事务管理平台提交业务申请以及相关的授权依据，授权依据为预授权文件号；每个预授权文件具有唯一的预授权文件号；

（4）事务管理平台根据业务申请中提供的预授权文件号查找相应的决定人和关注人，并检查业务申请是否已经超过决定人的被授权范围，如果超过则进入业务申请已经超过决定人的被授权范围时的特殊流程；如果未超过则进行下一流程节点（5）；

（5）事务管理平台向决定人和所有关注人推送业务申请；

步骤3：决定

（8）决定人对业务申请作出批准或不批准的决定；

（9）事务管理平台向申请人推送业务申请审批结果；如果决定人做出不批准的决定，除关注人仍能发表意见外，将业务申请退回业务申请人；

步骤4：业务执行

（10）业务申请人按批准的业务申请中的要求选择符合服务或商品进行消费；事务管理平台会根据决定人批准的业务申请对业务申请人的选择范围进行控制；

（11）业务申请人确认实际消费金额，发起支付请求；

（12）事务管理平台验证支付请求的内容与批准的业务申请是否矛盾；如果矛盾，则要求申请人检查修改支付请求，否则拒绝执行；如果无矛盾，则进入下一流程节点（13）；

（13）通过支付接口将支付指令发给银行或其他支付机构。

更进一步地，业务申请已经超过决定人的被授权范围时的特殊流程具体包括：

(s1).事务管理平台首先查询是否存在上级预授权文件；若不存在则自动驳回业务申请；若存在则进入下一流程节点(s2)；

(s2).由决定人决定驳回业务申请或提交上一级审批；当决定驳回时，事务管理平台将业务申请退回申请人；当决定提交上一级审批时，进入下一流程节点(s3)；

(s3)事务管理平台查找上一级预授权文件中的决定人和关注人；

(s4)事务管理平台将业务申请的预授权文件号换作上一级预授权文件号；决定人换作上一级决定人；将上一级预授权文件中的关注人和本级预授权文件中的关注人合并，作为业务申请的关注人；

然后返回流程节点(4)。

本发明的优点：本发明简化了授权动作，允许管理者用链式方式向下级自助地在it系统中进行预授权，给予管理者在授权工具上极大的自由度；在实际业务超出对下级预授权范围时事务管理平台可自动向上回溯，确定有权限的决策人，将业务请求自动提交该决策人审批，保证例外管理流程也能最大可能地标准化和简单；这种授权方式能够完美能够适应各种复杂多变业务场景、完美支持各种不同的管理风格和管理方式，除了能支持传统的企业组织形式外，也特别能支持现代企业组织网络化的发展趋势。

本发明通过改进的授权管理工具来清晰界定权限属性，建立责任追溯和激励机制推动授权体系有效地运转；对预授权行为和权限行使进行监督，明确授权人与被授权人的责任；保证了实际业务能够被充分掌控，使得授权体系有效运转。

附图说明

图1为本发明的业务全过程示意图。

图2为本发明的业务申请未超过预授权范围时的基本流程示意图。

图3为本发明的业务申请超过预授权范围时的复杂流程示意图。

图4为本发明的授权链示意图。

图5为本发明的业务执行流程图。

图6为本发明的转授权的实例示意图。

具体实施方式

下面结合具体附图和实施例对本发明作进一步说明。

标准化多维链式预授权管理系统（下简称smcbp)的技术方案如下：

smcbp将业务分解为四个关键步骤：预授权、业务申请、决定、业务执行（选择服务或商品、接受服务或商品、确认消费金额、发出付款指令），并将这个四步骤作为相互关联的全过程进行管理，如图1所示；

步骤1：预授权

授权人根据业务需要，针对不同业务场景，将自己的权限进行分解，分别授予一系列被授权人的过程；

预授权在事务管理平台中通过以下两个步骤实现：

（1）授权人通过智能手机等移动设备使用事务管理平台提供的标准化预授权语言向事务管理平台上传预授权文件；

（2）事务管理平台向预授权文件中列明的被授权人即决定人、业务申请人、关注人推送预授权文件；

步骤2：业务申请

（3）业务申请人使用智能手机等移动设备通过事务管理平台提交业务申请以及相关的授权依据，授权依据为预授权文件号；每个预授权文件具有唯一的预授权文件号；

（4）事务管理平台根据业务申请中提供的预授权文件号查找相应的决定人和关注人，并检查业务申请是否已经超过决定人的被授权范围，如果超过则进入业务申请已经超过决定人的被授权范围时的特殊流程；如果未超过则进行下一流程节点（5）；

（5）事务管理平台向决定人和所有关注人推送业务申请；

关注人发表意见

关注人发表意见不是业务流程的必需步骤，并且在业务申请从发起到关闭全过程均可进行；

（6）关注人通过事务管理平台发表意见并提交；

（7）事务管理平台将关注人发表的意见推送决定人、其他关注人和业务申请人；

步骤3：决定

（8）决定人对业务申请作出批准或不批准的决定；

（9）事务管理平台向申请人推送业务申请审批结果；如果决定人做出不批准的决定，除关注人仍能发表意见外，将业务申请退回业务申请人；

步骤4：业务执行

（10）业务申请人按批准的业务申请中的要求选择符合服务或商品进行消费；事务管理平台会根据决定人批准的业务申请对业务申请人的选择范围进行控制；

（11）业务申请人确认实际消费金额，发起支付请求；

（12）事务管理平台验证支付请求的金额、支付对象等内容与批准的业务申请是否矛盾；如果矛盾，则要求申请人检查修改支付请求，否则拒绝执行；如果无矛盾，则进入下一流程节点（13）；

（13）通过支付接口将支付指令发给银行或其他支付机构。

其中，在已经存在业务申请相应的预授权文件的前提下，从业务申请开始的基本流程如图2所示；

在流程节点（4）中提及的业务申请已经超过决定人的被授权范围时的特殊流程如图3所示；

(s1).事务管理平台首先查询是否存在上级预授权文件；若不存在则自动驳回业务申请；若存在则进入下一流程节点(s2)；

(s2).由决定人决定驳回业务申请或提交上一级审批；当决定驳回时，事务管理平台将业务申请退回申请人；当决定提交上一级审批时，进入下一流程节点(s3)；

(s3)事务管理平台查找上一级预授权文件中的决定人和关注人；

(s4)事务管理平台将业务申请的预授权文件号换作上一级预授权文件号；决定人换作上一级决定人；将上一级预授权文件中的关注人和本级预授权文件中的关注人合并，作为业务申请的关注人；

然后返回流程节点(4)。

标准化多维链式预授权管理系统(smcbp)的关键技术点：

（一）标准化预授权语言；

对预授权的要素和动作进行抽象后标准化、极简化，能够让管理者可以自助进行授权操作，保证权限能够及时调整而不产生业务混乱。

预授权要素：

1.1)业务场景：指由因业务需要而发生的消费行为的一系列要素的组合；包括消费行为的时间、地点（商户地址）、涉及的人物（业务申请人、决定人、参与意见人）、消费行为的多个维度如消费内容、消费商户、涉及金额范围等等。每一个预授权动作都是针对某个或某些业务场景而进行的管理行为；每一个层次的业务场景都可能是上一层次业务场景的子集；

1.2)预授权中的角色：根据rcdi法则，权限会有提交权(responsibility)、审核权(consult)、审批权(decision)和知情权(informed)；与此对应，在每个业务场景中，都会有四种角色：

提出业务申请的业务申请人(requestor)，拥有提交权；

能够参与发表意见，提供决策支持、对业务进行评价的关注人(advisor)，拥有审核权、知情权；对于一个业务场景，由授权人和决定人（被授权人）决定哪些关注人可以参与业务预授权的过程发表意见；这种机制能够避免泛滥式的集体决策。

负责最终对一项业务申请是否可以开始执行作出决定的决定人(decisionmaker)，拥有审批权；每项业务预授权必须有唯一的一个或一组决定人，以保证n+1审批的内部控制原则，但又避免不必要的层层审批；唯一的一个或一组决定人也能保证不出现“议而不决”、无人拍板的情形；在某些情况下，会出现“必须一致同意”的共同决定这种特殊情形，这时决定人为不分先后的一组人，业务必须得到所有人同意才能执行；只要有一个人拒绝则就不能执行。

将自己的权限分解授予下级的授权人(authorizer)；

1.3)权限维度及条件范围；

以下是一些权限维度和相对应条件的部分实例；

•单次金额范围:1000<x<5000

•累计金额范围:10000<x<50000

•允许消费商户类型:餐厅、茶座、咖啡馆、百货商店

•人均消费范围：100<x<500

•物品单价范围：50<x<200

•交通工具：飞机、高铁、的士、巴士……

在事务管理平台中可选择的服务、商品按与权限维度一致的维度进行分类，以保证可以将实际执行的业务与授权文件和批准后业务申请中的授权范围进行检查；也就是说事务管理平台所接入的电商平台的服务、商品分类与事务管理平台权限维度的维度分类相一致；

1.4)授权有效期：为一个精确到天的时间区间；

1.5）可使用次数：实际业务申请可以调用预授权文件作为依据的最大次数；

1.6)授权状态：有效、失效、待确认；

1.7)业务场景授权id：针对每个业务场景进行的授权都会有相应的唯一的id；

1.8)上级业务场景授权id：除最高一级业务场景授权外，每个业务场景进行的授权都会有相应的上级授权id作为依据；

动作：

2.1)预授权：针对某个设定的业务场景，已经从上一级得到预授权的某个授权人authorizer，在自己得到的授权权限范围内，区分出不同的子业务场景，分别设定业务申请人名单、关注人、决定人，以及包含权限维度和条件范围在内的授权要素；最高级别的授权人默认对所有业务场景拥有所有权限；

2.2)转授权：对于某个业务场景，决定人以得到的上一级预授权为依据，把业务场景拆分成为多个子业务场景（或者不拆分），以自己为授权人，再转授给他人；转授的预授权每个权限维度的条件范围必须小于等于作为转授权依据的上一级预授权中每个权限维度的条件范围；下面如图6所示，是一个转授权的实例：

2.3)授权修改：对预授权的要素内容进行修改；修改后的预授权的每个权限维度的条件范围仍旧必须小于等于作为转授权依据的上一级预授权中每个权限维度的条件范围。

（二）多维权限控制；

传统授权管理方式以及相应系统往往使用一个维度（一般为单次额度或累计额度）进行授权管理和业务控制。事务管理平台对实际业务抽样出多个权限维度，并进行标准化；利用多个权限维度组合进行授权管理，每个权限维度具有相应的条件范围；对于战略意图传达的精准度和灵活度，会比使用一个维度进行授权管理高得多。例如，某项预授权的范围可以是：

•单次金额范围:1000<x<5000

•累计金额范围:10000<x<50000

•允许消费商户类型:餐厅、茶座、咖啡馆、百货商店

•人均消费范围：100<x<500

•物品单价范围：50<x<200；

（三）链式授权管理；

事务管理平台中的预授权文件体系构成了业务场景驱动的授权链；

事务管理平台让授权人按业务场景事件进行预授权，被授权人可通过将得到的预授权进行逐级向下的转授权，形成成系列的适用于不同业务场景的授权链条。

对每个企业而言，全部授权是多组从上而下的业务场景授权构成的授权链构成。最高级的授权是总经理对各种业务场景的授权。其余授权都是对总经理的业务场景授权逐级进行转授权的下级授权。一个授权链的简化示意图如图4所示。

事务管理平台的标准化多维链式预授权工具，在标准化授权语言的基础上，简化了授权动作，允许管理者用链式方式向下级自助地在it系统中进行预授权，给予管理者在授权工具上极大的自由度；在实际业务超出对下级预授权范围时事务管理平台可自动向上回溯，确定有权限的决策人，将业务请求自动提交该决策人审批，保证例外管理流程也能最大可能地标准化和简单；这种授权方式能够完美能够适应各种复杂多变业务场景、完美支持各种不同的管理风格和管理方式，除了能支持传统的企业组织形式外，也特别能支持现代企业组织网络化（大量出现矩阵式组织、跨部门团队等等）的发展趋势。

（四）授权冲突控制机制；

授权链中的上下级预授权文件之间可能因为人员变动修改、授权修改等原因出现冲突，不再满足“转授的预授权每个权限维度的条件范围必须小于等于作为转授权依据的上一级预授权中每个权限维度的条件范围“这个条件。因此，需要有额外的授权冲突控制机制。

上级业务场景授权修改时，记录修改时间，由后台对所有下级业务场景授权进行授权冲突检查，并提醒授权人是否强制要求修改下级业务场景授权，如果是，提醒“可能影响正常业务”，在下级修改授权前将所有下级授权变成“待确认”状态；待下级修改无冲突后方可生效；如果否，仅向被授权人提醒冲突，下级授权继续生效。

（五）去中心化自助式移动授权维护；

传统it授权管理方式是设置系统管理员，由系统管理员根据管理者的需求在it系统中设置权限。通常权限的设置有分用户设置和分用户组设置两种方式。分用户设置可以保证权限设置的灵活性，但授权管理复杂。分用户组对同一组设置相同权限，能够一定程度地简化授权管理，但也带来了僵化的问题。而且由于管理者的权限设置需要通过一定方式将授权人、被授权人、业务申请人的沟通内容传达给系统管理员，很容易由于组织流程上、内部沟通上的各种障碍，造成it系统中的权限设置出现与实际业务情形、管理需求脱节的情形。

事务管理平台提供的预授权管理方式不一定需要专门的后台人员进行权限维护，完全支持授权人自助式地利用移动设备进行预授权、转授权、授权修改。专门的后台人员进行权限维护仅仅是一种补充方式。这种特性能够管理人员随时随地根据业务需要通过移动设备对预授权进行调整，让授权管理与实际业务高度吻合。

（六）嵌入业务；

事务管理平台将业务申请人获取服务或商品等各种内外部资源的电商平台通过数据接口连接入了事务管理平台，业务申请人可以通过事务管理平台从平台中的预授权文件发起、转到电商平台中在预授权的权限范围控制之下搜索、选择所需商品和服务；也可以先进入电商平台选择所需商品和服务，下单后提供预授权文件号，系统自动检查选择商品和服务是否符合预授权规定的权限范围。无论哪种方式，事务管理平台都保证了业务的实际落实完全受预授权所控制。嵌入业务的预授权管理保证管理沟通、审批与业务执行紧密衔接，避免审批规避行为和影子审批流程产生。业务执行的流程如图5所示。

（七）预授权的优点；

在实际业务过程中，被管理者对管理者的响应时间要求上看，预授权、业务申请、决定、业务执行四个关键步骤具体不同的响应时间要求。预授权相对时间要求宽松，实际业务中一般按年调整都不会对业务产生不利影响；而业务申请和决定的响应时间要求就可能缩短为按天计算；而业务执行的操作动作特别是确认消费金额、发起支付请求、完成支付很可能会要求当时当场完成。事务管理平台将业务全过程分解为相对独立而又环环紧扣的预授权、业务申请、决定、业务执行四个关键步骤，利用多维链式预授权方式向一线管理者和业务执行者明确规范地传递战略意图和行动规则框架，保证了实际业务能够被充分掌控；同时，多维链式预授权的有效掌控，让日常业务只需一个审批步骤（决定人批准）即可执行，一线管理者和业务执行者可以在日常业务快速决策、快速行动。

（八）标准化多维链式预授权的价值；

现代企业在员工治理层面越来越强调敏捷的小团队管理。公司平台只提供简易的协作机制，更多地下放决策权力，“让听得见炮声的人呼唤炮火”。这种相对分权的决策环境，追求团队成员能够快速反应和执行，会对决策的价值观标准产生更强的依赖性，要求员工都能清晰地掌握决策的价值观标准。

新生代员工的思维越来越具有自我驱动意识，不再是被动地接受指令。他们追求对文化的认同，只要找到在文化上能够相匹配的组织，公司只需要告诉他们基本的任务和执行标准，他就能够进行自我管理。这时，公司只需要有一套及时、公平的评价和反馈机制即可。传统绩效考核都会在期末进行绩效面谈。这种总结式的面谈的确有它的效果，但是这种制度设计忽视了日常的双向沟通。设计价值观行为评价机制，特别强调在发生关键事件时，员工与主管之间的主动沟通。发生正向关键行为事件时，一般情况下，鼓励员工主动与主管沟通，便于确认价值观行为的评价等级；发生负向关键行为事件是，强调主管要主动与员工沟通，找到发生问题的原因，找到改进办法，提出改进建议。“日常一对一面谈”机制，更有利于促进工作绩效。

多维链式预授权在业务性质和管理层次两个方向上都具有了灵活性，特别支持“让听得见炮声的人呼唤炮火”这种管理方式。多维权限控制的特点保证了公司可以准确地向下传递基本的任务和执行标准；链式预授权能够帮助公司管理者把这些基本的任务和执行标准传递地最前端最能“听得见炮声”的管理者。事件驱动型、嵌入业务的授权和执行控制保证了员工与主管之间必要而有主次的主动沟通。并且，由于紧密嵌入业务，保证了业务过程和结果信息能够被自动、不干扰业务地收集、整理、结构化，为公司建立及时、公平的评价和反馈机制，激励员工，也为进行长期战略分析，都打下了良好的基础。