CN115759992A - 一种业务处理方法、装置、存储介质及设备 - Google Patents

Abstract

本申请实施例提供一种业务处理方法、装置、存储介质及设备，该方法中，根据目标业务请求的业务功能和业务场景，从预设的多个主流程中确定目标主流程，再生成目标主流程下的多个子流程并按照对应的启动时段启动，之后，监控审批状态，获取审批结果信息，并基于所有子流程的节点的审批结果信息来确定最终的处理结果。这样，通过将冗长串行审批流转化为一个个子流程，多个子流程协同完成主流程审批，提升了响应时效，而且，不因单个审批人员的拒绝意见而中途退出，有助于厘清诉求的经过，提高了审批结果的公允性。

Description

一种业务处理方法、装置、存储介质及设备

技术领域

本申请涉及流程处理技术领域，具体而言，涉及一种业务处理方法、装置、存储介质及设备。

背景技术

在大部分单位中，为了保证工作流的顺利进行，针对每项业务请求均设置有对应的审批流程。然而，目前的OA(Office Automation，办公自动化)软件提供的多人协作审批流基本是串行的，响应时效较差，而且，当审批流中的一审批人出具拒绝意见时，申请往往会中途退出，这就导致审批结果经常出现不够公允的情况。

发明内容

本申请实施例的目的在于提供一种业务处理方法、装置、存储介质及设备，旨在解决相关技术中存在的多人协作审批流的响应时效较差，而且审批结果经常不够公允的问题。

第一方面，本申请实施例提供的一种业务处理方法，包括：

获取目标业务请求，根据所述目标业务请求的业务属性，从预设的多个主流程中确定目标主流程；所述业务属性包括业务功能和业务场景；

基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程，并确定各子流程的启动时段；其中，当所述业务属性满足预设条件时，所述目标主流程下的多个子流程的启动时段一致；

按照所述启动时段启动对应的子流程后，监控各子流程的节点的审批状态，获取各子流程的节点的审批结果信息，并基于所有子流程的节点的审批结果信息确定针对所述目标业务请求的处理结果。

在上述实现过程中，根据目标业务请求的业务功能和业务场景，从预设的多个主流程中确定目标主流程，再生成目标主流程下的多个子流程并按照对应的启动时段启动，之后，监控审批状态，获取审批结果信息，并基于所有子流程的节点的审批结果信息来确定最终的处理结果。这样，通过将冗长串行审批流转化为一个个子流程，多个子流程协同完成主流程审批，提升了响应时效，而且，不因单个审批人员的拒绝意见而中途退出，有助于厘清诉求的经过，提高了审批结果的公允性。

进一步地，在一些实施例中，所述从预设的多个主流程中确定目标主流程之前，包括：

将所述目标业务请求按照结构化字段落库。

在上述实现过程中，将获取到的目标业务请求转换成结构化、标准化的数据，并存入业务库中，这样，可以方便后续审批节点对该请求的查看处理，从而在一定程度上提高审批效率。

进一步地，在一些实施例中，所述基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程，包括：

将所述目标业务请求按照目标主流程对应的配置信息路由到主流程配置，生成主流程表；

根据所述主流程表生成所述目标主流程下的多个子流程，并根据所述配置信息生成各子流程的申请表单。

在上述实现过程中，提供一种将主流程拆分为多个子流程的具体方案。

进一步地，在一些实施例中，所述方法还包括：

接收子流程更改指令，根据所述子流程更改指令对所述目标主流程进行编辑；

其中，所述对所述目标主流程进行编辑包括以下至少一项：

调整指定的子流程的申请表单、撤销指定的子流程、新增指定的子流程、更换指定的子流程对应的节点。

在上述实现过程中，在审批过程中，可以在任意子流程节点进行干预，如调整表单内容、新增、撤销、转办等，使得审批过程更为合理、有效。

进一步地，在一些实施例中，当所述业务属性不满足预设条件时，所述目标主流程下的多个子流程具有审批顺序，每个子流程的节点的审批结果信息是下一个子流程的申请表单中的内容。

在上述实现过程中，将主流程拆分多个子流程后，也可进行串行审批，最后一个子流程的节点的审批结果信息，即终审意见汇总了前面各子流程的审批意见以及自身节点的审批意见而得到的，因此，系统根据终审意见来确定处理结果，具有公允的效力。

进一步地，在一些实施例中，所述方法还包括：

将所述处理结果通知给所述目标业务请求的发起人和/或干系人。

在上述实现过程中，通过将处理结果知会发起人和/或干系人，实现流程闭环，并且推进处理结果的实现。

第二方面，本申请实施例提供的一种业务处理装置，包括：

确定模块，用于获取目标业务请求，根据所述目标业务请求的业务属性，从预设的多个主流程中确定目标主流程；所述业务属性包括业务功能和业务场景；

生成模块，用于基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程，并确定各子流程的启动时段；其中，当所述业务属性满足预设条件时，所述目标主流程下的多个子流程的启动时段一致；

处理模块，用于按照所述启动时段启动对应的子流程后，监控各子流程的节点的审批状态，获取各子流程的节点的审批结果信息，并基于所有子流程的节点的审批结果信息确定针对所述目标业务请求的处理结果。

第三方面，本申请实施例提供的一种电子设备，包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面任一项所述的方法的步骤。

第四方面，本申请实施例提供的一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，使得所述计算机执行如第一方面任一项所述的方法。

第五方面，本申请实施例提供的一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行如第一方面任一项所述的方法。

本申请公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本申请公开的上述技术即可得知。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种业务处理方法的流程图；

图2为本申请实施例提供的一种基于内部OA的智慧审批方案的工作流程的示意图；

图3为本申请实施例提供的一种业务处理装置的框图；

图4为本申请实施例提供的一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

如背景技术记载，相关技术中存在着多人协作审批流的响应时效较差，而且审批结果经常不够公允的问题。基于此，本申请实施例提供一种业务处理方案，以解决上述问题。

接下来对本申请实施例进行介绍：

如图1所示，图1是本申请实施例提供的一种业务处理方法的流程图，所述方法应用于单位的业务系统，这里的单位可以是企业，也可以是银行或其他金融机构等。

所述方法包括：

在步骤101、获取目标业务请求，根据所述目标业务请求的业务属性，从预设的多个主流程中确定目标主流程；所述业务属性包括业务功能和业务场景；

本步骤中提到的目标业务请求可以是指办公场景中需要审批人审批完成的诉求，这里的办公场景可以包括体系制度变更、法务合规修订、行政申请、数据安全类请求、或者人事申请等等。该目标业务请求的发起人可以是企业的内部员工，也可以是企业的合作伙伴、消费者等；相应地，该目标业务请求可以是请假申请、报销申请，也可以是业务办理申请、客诉申请等等。

本实施例中，系统中预先设置了多个主流程，每个主流程即是一个审批流，是对业务请求的审批活动的有序组合。这里的主流程可以包括若干个节点，每个节点可以是一个审批人员的用户端，也可以是一个分支环节上的多个审批人员的用户端。在一些实施例中，该主流程可以根据核实-评估-协调-执行原则进行设定，例如，针对客诉申请，主流程的节点可以包括负责对诉求经过进行核实的干系人、负责对诉求内容进行评估的初级审批、负责对诉求内容进行协调的高级审批，以及负责执行系统数据修改的节点。

系统接收目标业务请求后，根据该目标业务请求的业务功能和业务场景，从预先设置的多个主流程中确定出目标主流程。也就是说，本实施例中，不同业务功能可以对应不同的主流程，不同业务场景也可以对应不同的主流程。其中，目标业务请求的业务功能可以是指发起人提出目标业务请求对应诉求时使用的功能模块，例如，发起人提出客诉申请时，可以采用服务热线输入，也可以采用APP智能客服输入，这就是两种不同的业务功能；目标业务请求的业务场景可以是指目标业务请求对应的具体事项，例如，一个采购申请的业务场景可以包括该采购申请对应的具体采购产品以及预估金额等。不同业务功能和/或不同业务场景对应的主流程是不同的，这里的不同可以体现在节点数量上，也可以体现在具体的节点上，其可以根据企业规定以及历史处理记录进行设置。因而，系统根据目标业务请求的业务属性，可以确定出适合处理该目标业务请求的主流程。另外，在其他实施例中，用于确定目标主流程的业务属性还可以包括其他属性，如发起人的职位级别等。

在一些实施例中，在从预设的多个主流程中确定目标主流程之前，可以包括：将该目标业务请求按照结构化字段落库。也就是说，在获取到目标业务请求后，系统可以将该目标业务请求转换成结构化、标准化的数据，并存入业务库中，这样，可以方便后续审批节点对该请求的查看处理，从而在一定程度上提高审批效率。

在步骤102、基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程，并确定各子流程的启动时段；其中，当所述业务属性满足预设条件时，所述目标主流程下的多个子流程的启动时段一致；

与相关技术不同，本实施例将原本串行按顺序的审批流拆分为一个个子流程，每个子流程的载体是一个新的审批流。具体地，本步骤中提到的配置信息包括了主流程审批节点和主流程启动时间。系统基于目标主流程对应的配置信息，生成目标主流程下的多个子流程，例如，目标主流程对应的配置信息指示了主流程审批节点包括干系人甲、初级审批乙和高级审批丙，则系统可以生成对应于干系人甲的子流程1、对应于初级审批乙的子流程2以及对应于高级审批丙的子流程3。系统还基于目标主流程对应的配置信息，确定各子流程的启动时段，例如，目标主流程对应的配置信息指示了在工作日工作时间启动，则系统可以在工作日工作时间内配置各子流程的启动时段。

在一些实施例中，本步骤中提到的基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程可以包括：将所述目标业务请求按照所述所述目标主流程对应的配置信息路由到主流程配置，生成主流程表；根据所述主流程表生成所述目标主流程下的多个子流程，并根据所述配置信息生成各子流程的申请表单。也就是说，将目标业务请求按照配置信息路由到主流程配置，并生成主流程基本信息，这里的主流程基本信息可以包括目标业务请求的内容以及各子流程的信息，以目标业务请求是银行场景的客诉申请为例，主流程基本信息可以包括客户号、客户姓名、客户归属机构、客户诉求内容、各子流程对应的审批链以及审批人员账号等。该主流程基本信息以主流程表的形式呈现，之后，系统根据该主流程表生成目标主流程下的多个子流程，按照配置信息生成各子流程的申请表单，即组装生成子流程对应的电子申请表单进入审批流。需要说明的是，系统可以对该主流程表进行请求锁定及状态跟踪，请求锁定的目的是为了同一时间只处理同一主键的附属信息调整请求；另外，各子流程的申请表单可以是系统根据预设的模板生成的。

当业务属性满足预设条件时，目标主流程下的多个子流程的启动时段一致，也就是说，当业务属性满足预设条件时，可以采用并行审批的方式。这里的预设条件可以是指定业务功能和/或指定业务场景，例如，该指定业务功能可以是商务投诉模块，由于商务投诉模块输入的业务请求对处理时效要求较高，因此可以采用并行审批的方式，以避免因某个审批人员忘记处理而导致的整体处理时效慢。

在步骤103、按照所述启动时段启动对应的子流程后，监控各子流程的节点的审批状态，获取各子流程的节点的审批结果信息，并基于所有子流程的节点的审批结果信息确定针对所述目标业务请求的处理结果。

按照各子流程对应的启动时段来触发各个审批流。启动后，系统实时监控每个审批流的状态，并获取各子流程的节点的审批结果信息，这里的审批结果信息可以包括审批意见以及审批过程中输入的附件。最后，系统汇总所有子流程的节点的审批结果信息，以此确定出处理结果。在并行审批中，多个子流程的启动时段一致，也就是说，可以同时启动目标主流程下的多个子流程，以客诉申请为例，多个子流程同时启动，系统获取每个审批人员的审批意见以及上传的辅佐材料，并进行统计汇总，最终确定处理结果为同意客户客诉申请。如此，针对该客诉申请，提升了响应时效，在一定程度上起到了安抚客户的作用；而且，不因单个审批人员的拒绝意见而中途退出，有助于厘清客诉案件经过，得以公允裁定，避免案件升级造成损失。

在一些实施例中，当所述业务属性不满足预设条件时，所述目标主流程下的多个子流程具有审批顺序，每个子流程的节点的审批结果信息是下一个子流程的申请表单中的内容。也就是说，当业务属性不满足预设条件时，可以采用串行审批的方式，实现时，系统可以先启动第一个子流程，在第一个子流程的节点完成审批时，启动第二个子流程，并将第一个子流程的节点的审批意见以及附件等同时作为下一个子流程审批流申请表单的内容，以此类推，最后一个子流程的节点的审批结果信息，即终审意见实际上是汇总了前面各子流程的审批意见以及自身节点的审批意见而得到的，因此，系统根据终审意见来确定处理结果，同样具有公允的效力。

进一步地，在一些实施例中，上述方法还可以包括：接收子流程更改指令，根据所述子流程更改指令对所述目标主流程进行编辑，所述对所述目标主流程进行编辑包括以下至少一项：调整指定的子流程的申请表单、撤销指定的子流程、新增指定的子流程、更换指定的子流程对应的节点。也就是说，在审批过程中，可以在任意子流程节点进行干预，如调整表单内容、新增、撤销、转办等。例如，系统管理员可以对待发起的子流程进行编辑，以调整对应的申请表单的内容；当系统管理员发现审批过程中有一子流程超时未处理时，可以对该子流程进行撤销；系统管理员可以在任意子流程后新增子流程，以辅助审批流完整；系统管理员可以将某个子流程转交给其他人进行处理。如此，使得审批过程更为合理、有效。

另外，在确定出处理结果后，系统可以将处理结果通知给该目标业务请求的发起人和/或干系人。这里的干系人指的是在满足目标业务请求后其利益可能受积极或消极影响的个人，例如，在银行场景中，当发起人提出的诉求是更换业务员时，该业务员即为该诉求的干系人。通过将处理结果知会发起人和/或干系人，实现流程闭环，并且推进处理结果的实现，例如，当处理结果是不同意更换业务员时，将该处理结果告知该业务员后，可以促进该业务员及时与发起人进行沟通协商；或者，当处理结果是同意更换业务员时，将该处理结果告知该业务员后，可以促进该业务员将相关工作内容移交给更换后的业务员。还有，对于每笔主流程的审批过程，可以认定至少一个责任人，并下发责任认定通知书，如此，进一步提升审批效率和审批质量。

本申请实施例，根据目标业务请求的业务功能和业务场景，从预设的多个主流程中确定目标主流程，再生成目标主流程下的多个子流程并按照对应的启动时段启动，之后，监控审批状态，获取审批结果信息，并基于所有子流程的节点的审批结果信息来确定最终的处理结果。这样，通过将冗长串行审批流转化为一个个子流程，多个子流程协同完成主流程审批，提升了响应时效，而且，不因单个审批人员的拒绝意见而中途退出，有助于厘清诉求的经过，提高了审批结果的公允性。

为了对本申请的方案做更为详细的说明，接下来介绍一具体实施例：

本实施例涉及银行内部OA办公软件完成多人协作的审批流的场景，在本实施例之前，业内大部分日常办公场景应用都是基于单指向的向上级申请某项诉求，其响应时效较差，而且当审批流中的一审批人出具拒绝意见时，申请会中途提出，审批结果不够公允。基于此，本实施例提供一种基于内部OA的智慧审批方案，以解决这一问题。

该方案的工作流程如图2所示，包括：

S201、接收各业务功能的请求数据；例如，客诉类申请有服务热线输入、也有APP智能客服输入等；

S202、将请求数据结构化、标准化入库；具体地，不同业务功能不同渠道来源的请求按照结构化字段落业务库；

S203、按照业务功能和业务场景确定主流程配置；具体地，针对不同业务功能和不同场景可设置不同主流程，主流程审批节点可设置，主流程启动时间可设置，例如设定工作日工作时间启动；

S204、按照主流程配置路由生成各业务单元的主流程申请；具体地，已入业务库的申请请求按照配置信息路由到主流程配置，并生成主流程基本信息，进入主流程表进行请求锁定及状态跟踪，请求锁定目的是为了同一时间只处理同一主键的附属信息调整请求；

S205、组装生成子流程对应的电子申请表单进入审批流；具体地，根据主流程表生成主流程下的多个子流程，按照配置信息首先生成第一个子流程的指定模板的电子申请表单；

S206、按照启动时段配置触发单个审批流；具体地，按照启动时段配置，启动第一个子流程，子流程的审批流申请调用内部OA审批工具；

S207、实时获取审批意见；具体地，流程中实时监控每个审批流的状态，并获取审批意见，以及审批过程中输入的附件，审批流每个节点的审批时间及意见、附件等同时作为下一个子流程审批流申请表单的内容；

S208、根据终审意见执行系统参数修改；具体地，主流程过程中，可在任意子流程节点人工干预，可对待发起的子流程进行编辑调整申请表单内容，可对审批中超时未处理的子流程进行撤销，可对任意子流程后新增子流程辅助审批流完整，可将流程中子流程转办他人或多人处理等；当各子流程的启动时段配置一致时，将所有子流程的审批结果进行汇总，得到终审意见，当各子流程的启动时段配置不一致时，将最后一个子流程的审批结果确定为终审意见，之后，终审意见作为系统执行数据修改的条件，终审通过业务系统化实时执行修改，用户实时感受变化；

S209、消息推送知会发起人或干系人；具体地，对于每笔主流程的审批过程，可认定责任人，并下发责任认定通知书。对于终审结束后的系统执行结果知会发起人或干系人，做到流程闭环。

本实施例方案，可以按照核实-评估-协调-执行原则设定主流程，业务系统对接内部OA审批流工具，各业务模块可根据实际情况设定主流程的节点，原本串行按顺序的审批流被拆分为一个个子流程，每个子流程的载体是一个新的审批流，审批流中的审批人可对审批申请出具意见，无论同意或拒绝，主流程仍然会不受影响的自动执行下去，直至主流程终审完成。当然在智慧审批主流程过程中，可在任意子流程节点进行干预，如新增、撤销、转办等。

这一方案至少具有以下优点：第一、从审批时效看，大大降低了单个审批流处理时长，将冗长串行审批流，转化为一个个小流程，多个子流程协同完成主流程审批，尤其对于客诉类申请件，响应时效提升，一定程度起到缓解和安抚客户作用；第二、从管理者的角度，可利用结构审批数据管理业务单元内的各审批人，对处理时效慢，超时不处理，随意给予审批结果后被申诉等行为可采取督办、通报、责任认定等管理动作，起到反向倒逼，逐步训练审批人的作用；第三、对于发起人来说，智慧审批更加公允，让原本审批流程中途退出的申请可以跨级触达高级审批人，得以公允裁定，如针对客诉类申请件时，有助于厘清客诉件经过，及时出具终审意见，避免案件升级造成损失；第四、该智慧审批方案带有业务属性，对接内部OA审批工具，根据终审结果自动化执行业务系统数据修改，减少业务系统的运营成本，提高运营效率。

与前述方法的实施例相对应，本申请还提供业务处理装置及其应用的终端的实施例：

如图3所示，图3是本申请实施例提供的一种业务处理装置的框图，所述装置包括：

确定模块31，用于获取目标业务请求，根据所述目标业务请求的业务属性，从预设的多个主流程中确定目标主流程；所述业务属性包括业务功能和业务场景；

生成模块32，用于基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程，并确定各子流程的启动时段；其中，当所述业务属性满足预设条件时，所述目标主流程下的多个子流程的启动时段一致；

处理模块33，用于按照所述启动时段启动对应的子流程后，监控各子流程的节点的审批状态，获取各子流程的节点的审批结果信息，并基于所有子流程的节点的审批结果信息确定针对所述目标业务请求的处理结果。

在一些实施例中，上述装置还包括落库模块，所述落库模块用于：在从预设的多个主流程中确定目标主流程之前，将所述目标业务请求按照结构化字段落库。

在一些实施例中，上述生成模块32包括第一子模块，所述第一子模块用于：将所述目标业务请求按照目标主流程对应的配置信息路由到主流程配置，生成主流程表；根据所述主流程表生成所述目标主流程下的多个子流程，并根据所述配置信息生成各子流程的申请表单。

在一些实施例中，上述装置还包括编辑模块，所述编辑模块用于：接收子流程更改指令，根据所述子流程更改指令对所述目标主流程进行编辑；其中，所述对所述目标主流程进行编辑包括以下至少一项：调整指定的子流程的申请表单、撤销指定的子流程、新增指定的子流程、更换指定的子流程对应的节点。

在一些实施例中，当所述业务属性不满足预设条件时，所述目标主流程下的多个子流程具有审批顺序，每个子流程的节点的审批结果信息是下一个子流程的申请表单中的内容。

在一些实施例中，上述装置还包括通知模块，用于：将所述处理结果通知给所述目标业务请求的发起人和/或干系人。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

本申请还提供一种电子设备，请参见图4，图4为本申请实施例提供的一种电子设备的结构框图。电子设备可以包括处理器410、通信接口420、存储器430和至少一个通信总线440。其中，通信总线440用于实现这些组件直接的连接通信。其中，本申请实施例中电子设备的通信接口420用于与其他节点设备进行信令或数据的通信。处理器410可以是一种集成电路芯片，具有信号的处理能力。

上述的处理器410可以是通用处理器，包括中央处理器(CPU，Central ProcessingUnit)、网络处理器(NP，Network Processor)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器410也可以是任何常规的处理器等。

存储器430可以是，但不限于，随机存取存储器(RAM，Random Access Memory)，只读存储器(ROM，Read Only Memory)，可编程只读存储器(PROM，Programmable Read-OnlyMemory)，可擦除只读存储器(EPROM，Erasable Programmable Read-Only Memory)，电可擦除只读存储器(EEPROM，Electric Erasable Programmable Read-Only Memory)等。存储器430中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器410执行时，电子设备可以执行上述图1方法实施例涉及的各个步骤。

可选地，电子设备还可以包括存储控制器、输入输出单元。

所述存储器430、存储控制器、处理器410、外设接口、输入输出单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线440实现电性连接。所述处理器410用于执行存储器430中存储的可执行模块，例如电子设备包括的软件功能模块或计算机程序。

输入输出单元用于提供给用户创建任务以及为该任务创建启动可选时段或预设执行时间以实现用户与服务器的交互。所述输入输出单元可以是，但不限于，鼠标和键盘等。

可以理解，图4所示的结构仅为示意，所述电子设备还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。

本申请实施例还提供一种存储介质，所述存储介质上存储有指令，当所述指令在计算机上运行时，所述计算机程序被处理器执行时实现方法实施例所述的方法，为避免重复，此处不再赘述。

本申请还提供一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行方法实施例所述的方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种业务处理方法，其特征在于，包括：

获取目标业务请求，根据所述目标业务请求的业务属性，从预设的多个主流程中确定目标主流程；所述业务属性包括业务功能和业务场景；

基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程，并确定各子流程的启动时段；其中，当所述业务属性满足预设条件时，所述目标主流程下的多个子流程的启动时段一致；

按照所述启动时段启动对应的子流程后，监控各子流程的节点的审批状态，获取各子流程的节点的审批结果信息，并基于所有子流程的节点的审批结果信息确定针对所述目标业务请求的处理结果。

2.根据权利要求1所述的方法，其特征在于，所述从预设的多个主流程中确定目标主流程之前，包括：

将所述目标业务请求按照结构化字段落库。

3.根据权利要求1所述的方法，其特征在于，所述基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程，包括：

将所述目标业务请求按照目标主流程对应的配置信息路由到主流程配置，生成主流程表；

根据所述主流程表生成所述目标主流程下的多个子流程，并根据所述配置信息生成各子流程的申请表单。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

接收子流程更改指令，根据所述子流程更改指令对所述目标主流程进行编辑；

其中，所述对所述目标主流程进行编辑包括以下至少一项：

调整指定的子流程的申请表单、撤销指定的子流程、新增指定的子流程、更换指定的子流程对应的节点。

5.根据权利要求1所述的方法，其特征在于，当所述业务属性不满足预设条件时，所述目标主流程下的多个子流程具有审批顺序，每个子流程的节点的审批结果信息是下一个子流程的申请表单中的内容。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

将所述处理结果通知给所述目标业务请求的发起人和/或干系人。

7.一种业务处理装置，其特征在于，包括：

确定模块，用于获取目标业务请求，根据所述目标业务请求的业务属性，从预设的多个主流程中确定目标主流程；所述业务属性包括业务功能和业务场景；

生成模块，用于基于所述目标主流程对应的配置信息，生成所述目标主流程下的多个子流程，并确定各子流程的启动时段；其中，当所述业务属性满足预设条件时，所述目标主流程下的多个子流程的启动时段一致；

处理模块，用于按照所述启动时段启动对应的子流程后，监控各子流程的节点的审批状态，获取各子流程的节点的审批结果信息，并基于所有子流程的节点的审批结果信息确定针对所述目标业务请求的处理结果。

8.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述的方法。

9.一种电子设备，其特征在于，包括处理器、存储器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如权利要求1至6任一项所述的方法。

10.一种计算机程序产品，其特征在于，所述计算机程序产品在计算机上运行时，使得计算机执行如权利要求1至6任一项所述的方法。

Images