业务调度方法、装置、电子设备、介质及产品与流程

1.本公开涉及互联网技术领域，可应用于金融科技技术领域，特别涉及一种业务调度方法、装置、电子设备、介质及产品。


背景技术：

2.随着互联网快速发展，金融机构的大部分业务已完成线上化改造，客户到网点的频次越来越低。在此背景下，金融机构逐渐从“坐商”向“行商”转变，大力推动外拓营销工作。
3.现有的外销营销包括两种模式，第一种模式为采用专人专岗的流水线分工，由不同的人负责不同类型的业务，串行式为客户服务，例如，甲负责协助客户完成借记卡申请及激活等需要使用专用终端机办理的业务，乙负责协助客户完成app下载、绑卡、优惠领取等无需使用专用终端机办理的业务，丁负责对客户开展反诈、防涉诈宣传及贷款、理财等咨询教育类业务。第二种模式为不进行分工，每个人都负责所有类型的业务，并行式为客户提供服务。例如，甲、乙、丙均负责协助客户完成借记卡申请及激活等需要使用专用终端机办理的业务、负责协助客户完成app下载、绑卡、优惠领取等无需使用专用终端机办理的业务和负责对客户开展反诈、防涉诈宣传及贷款、理财等咨询教育类业务。
4.然而，在第一种模式下，当不同业务之间具备依赖性时，必须等某一业务完成后才能办理另一业务，存在时间浪费，业务办理效率低。在第二种模式下，需要给所有客户经理配备专用终端机，以确保其能满足客户的所有业务需求，成本较高，此外，由于业务员一般无法同时精通所有业务，在为客户办理其不熟悉的业务时效率较低且容易导致业务事故，影响客户的体验，甚至给客户带来损失。


技术实现要素：

5.本公开的主要目的是提供一种业务调度方法、装置、电子设备、介质及产品，旨在部分解决现有技术中业务办理效率低、成本较高、不熟悉的业务时效率较低且容易导致业务事故的技术问题。
6.为实现上述目的，本公开第一方面提供一种业务调度方法，包括：根据待处理业务的属性信息将待处理业务分解为多个子业务，对所述多个子业务进行分类，并确定所述多个子业务之间的依赖关系，其中，所述依赖关系用于表征所述多个子业务的执行顺序；根据所述多个子业务的业务类型创建维护角色，为每一维护角色创建任务队列，基于所述依赖关系将所述多个子业务按照业务类型添加至对应维护角色的任务队列中；响应于待处理业务的申请请求，调用对应的任务队列指示该任务队列对应的维护角色执行所述待处理业务。
7.根据本公开的实施例，所述业务调度方法还包括：响应于任务队列为空，基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色。
8.根据本公开的实施例，所述基于加权惩罚最小优先的启发式贪婪法变更空的任务
队列对应的维护角色，具体包括：获取每一维护角色处理对应子业务的耗时，所述子业务在所述任务队列中的等待时间，所述待处理业务的申请请求对应的用户的到达时刻；计算每一维护角色处理所述子业务的综合惩罚因子；确定每一维护角色处理待处理业务的申请请求对应的子任务的状态变量；建立所述耗时，所述等待时间，所述到达时刻和所述综合惩罚因子、状态变量与所述待处理业务的申请请求对应的所有子业务的综合开销之间的关系；确定综合开销最小时各维护角色的数量；根据各维护角色的数量变更空的任务队列对应的维护角色。
9.根据本公开的实施例，所述计算每一维护角色处理所述子业务的综合惩罚因子，具体包括：对于每一子业务，获取该子业务对应的维护角色的第一数量以及等待执行该子业务的待处理业务的申请请求的第二数量；对于每一维护角色，响应于该维护角色执行的当前子任务为对应的任务队列中的子任务，将该维护角色处理执行的当前子任务的综合惩罚因子设置为1；响应于该维护角色执行的当前子任务不为对应的任务队列中的子任务，根据所述第一数量和所述第二数量计算维护角色处理执行的当前子任务的综合惩罚因子。
10.根据本公开的实施例，所述确定每一维护角色处理待处理业务的申请请求对应的子任务的状态变量，具体包括：对于每一维护角色，响应于该维护角色执行的当前子任务为对应的任务队列中的子任务，将所述状态变量设置为1；响应于该维护角色执行的当前子任务不为对应的任务队列中的子任务，将所述状态变量设置为0。
11.根据本公开的实施例，所述获取每一维护角色处理对应子业务的耗时，具体包括：获取业务耗时数据库的各子业务的历史耗时数据；对于每一子业务，计算该子业务对应的所有历史耗时数据的平均值，作为维护角色处理该子业务的耗时。
12.根据本公开的实施例，所述任务队列的类型包括专用终端机类、非专用终端机类和咨询教育类。
13.本公开第二方面提供一种业务调度装置，包括：分解模块，用于根据待处理业务的属性信息将待处理业务分解为多个子业务，对所述多个子业务进行分类，并确定所述多个子业务之间的依赖关系，其中，所述依赖关系用于表征所述多个子业务的执行顺序；创建模块，用于根据所述多个子业务的业务类型创建维护角色，为每一维护角色创建任务队列，基于所述依赖关系将所述多个子业务按照业务类型添加至对应维护角色的任务队列中；调度模块，用于响应于待处理业务的申请请求，调用对应的任务队列指示该任务队列对应的维护角色执行所述待处理业务。
14.根据本公开的实施例，所述业务调度装置还包括：变更模块，用于响应于任务队列为空，基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色。
15.本公开第三方面提供一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器执行根据上述所述的方法。
16.本公开第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有可执行指令，该指令被处理器执行时使处理器执行根据上述所述的方法。
17.本公开第五方面提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现根据上述所述的方法。
18.根据本公开实施例提供的业务调度方法、装置、电子设备、介质及产品，至少具备
以下有益效果：
19.基于业务的属性信息对业务进行分解，对子业务进行分类，实现业务的分流，对分流后的子业务创建对应的维护角色及任务队列，将分流后的业务加入对应的任务队列中，一方面可以实现业务的明确分工，另一方面基于依赖关系可以快速地识别任务队列中待处理的子业务进行及时处理，从而降低了客户排队时间，显著提升外拓营销的业务办理效率，进而提升人效及客户满意度。
20.在某一任务队列为空，也即存在维护角色空闲的情况下，基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色，将空闲的维护角色变更为当前需要的维护角色，在最小综合开销的情况下，实现维护角色的充分利用，进一步提升了业务办理效率，进而提升人效及客户满意度。
附图说明
21.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。
22.图1示意性示出了根据本公开实施例的业务调度方法及装置的系统架构100；
23.图2示意性示出了根据本公开一实施例的业务调度方法及装置应用场景图；
24.图3示意性示出了根据本公开一实施例的业务调度方法的流程图；
25.图4示意性示出了根据本公开另一实施例的业务调度方法的流程图；
26.图5示意性示出了根据本公开实施例的基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色的方法流程图；
27.图6示意性示出了根据本公开实施例的综合惩罚因子的计算方法流程图；
28.图7示意性示出了根据本公开实施例的状态变量的确定方法流程图；
29.图8示意性示出了根据本公开实施例的总开销最小化求解方法流程图；
30.图9示意性示出了根据本公开一实施例的业务调度装置的框图；
31.图10示意性示出了根据本公开另一实施例的业务调度装置的框图
32.图11示意性示出了根据本公开一实施例的变更模块的框图；
33.图12示意性示出了根据本公开实施例的适于实现上文描述的方法的电子设备的框图。
具体实施方式
34.以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
35.在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在
或添加一个或多个其他特征、步骤、操作或部件。
36.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
37.在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。
38.附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读存储介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。
39.在本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供、公开和应用等处理，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。
40.在本公开的技术方案中，在获取或采集用户个人信息之前，均获取了用户的授权或同意。
41.针对相关技术中存在的技术问题，本公开实施例提供了一种业务调度方法，包括：根据待处理业务的属性信息将待处理业务分解为多个子业务，对多个子业务进行分类，并确定多个子业务之间的依赖关系，其中，依赖关系用于表征多个子业务的执行顺序。根据子业务的业务类型创建维护角色，为每一维护角色创建任务队列，基于关系将子业务按照业务类型添加至对应维护角色的任务队列中。响应于待处理业务的申请请求，调用对应的任务队列指示该任务队列对应的维护角色执行所述理业务。
42.图1示意性示出了根据本公开实施例的业务调度方法及装置的系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。
43.如图1所示，根据该实施例的系统架构100可以包括终端101，网络102和服务器103。网络102用于终端101与服务器103之间提供通信链路。
44.终端101例如可以是带有触摸显示屏的电子设备，例如可以包括手机、电脑、智能柜机，客户可以通过在触摸显示屏上点击对应的功能框发起业务申请请求。网络102可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。其中有线方式例如可以是采用线缆及以下多种接口中的任一种连接：光纤通道、红外线接口、d型数据接口、串行接口、
usb接口、usb type-c接口或dock接口，无线方式例如可以是采用无线通信方式连接的，其中的无线通信例如可采用蓝牙、wi-fi、infrared、zigbee等多个无线技术标准中的任一个。服务器103通过网络102接收终端101发起的业务申请请求，根据业务申请请求对应的待处理业务的属性信息，将待处理业务分解为多个子业务，对多个子业务进行分类，并确定多个子业务之间的依赖关系，根据多个子业务的业务类型创建维护角色，为每一维护角色创建任务队列，基于依赖关系将多个子业务按照业务类型添加至对应维护角色的任务队列中，响应于业务申请请求，调用对应的任务队列指示该任务队列对应的维护角色执行待处理业务。
45.需要说明的是，本公开实施例所提供的业务调度方法可以由服务器103执行。相应地，本公开实施例所提供的业务调度装置可以设置于服务器103中。或者，本公开实施例所提供的业务调度方法也可以由不同于服务器103且能够与终端101和/或服务器103通信的服务器或服务器集群执行。相应地，本公开实施例所提供的业务调度装置也可以设置于不同于服务器103且能够与终端101和/或业务调度平台103通信的服务器或服务器集群中。或者，本公开实施例所提供的业务调度方法也可以部分由服务器103执行，部分由终端101执行。相应的，本公开实施例所提供的业务调度装置也可以部分设置于服务器103中，部分设置于终端101中。
46.应该理解，图1中的终端、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端、网络和服务器。
47.本公开实施例提供的业务调度方法，可以应用于金融科技领域。
48.图2示意性示出了根据本公开一实施例的业务调度方法及装置应用场景图。
49.如图2所示，现有n个客户，需要办理的业务包括有借记卡业务、信用卡业务、咨询类业务，现有服务的工作人员有m个。
50.采用现有技术中的第一模式进行业务处理，可以选择m个工作人员中的一部分处理借记卡业务和信用卡业务中需要使用终端机的业务、一部分处理借记卡业务和信用卡业务中不需要使用终端机的业务，余下一部分处理咨询类业务，当n个客户中有一部分需要办理借记卡业务和信用卡业务中需要使用终端机的业务时，便安排m个工作人员中处理对应业务的工作人员为客户办理业务，而当需要使用终端机的业务的客户数量大于能够处理对应业务的工作人员的数量时，则多余部分的客户需要等待其他客户业务办理完成后才能进行办理，则存在时间浪费，业务办理效率低的问题。
51.采用现有技术中的第一模式进行业务处理，则m个工作人员都同时具备办理借记卡业务、信用卡业务、咨询类业务的能力，实际操作中显然存在很大的难度，并且，每个工作人员都需要配备专用终端机，以确保其能满足客户的所有业务需求，成本较高。
52.而采用本公开实施例提供的业务调度方法，对n个客户的借记卡业务、信用卡业务、咨询类业务均进行业务分解分流，根据分解的子业务类型为m个工作人员创建维护角色，并为每一个维护角色创建任务队列，将n个客户分解后的子业务添加至对应的任务队列中，一方面可以实现业务的明确分工，另一方面基于依赖关系可以快速地识别任务队列中待处理的子业务进行及时处理，并且，基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色，实现空闲岗位的灵活调度，能够至少部分解决现有技术存在的问题。
53.应当理解是，本公开实施例提供的业务调度方法不仅限于应用于金融科技领域，上述描述只是示例性的，对于例涉及业务调度的例如物流等其他技术领域，都可以应用本公开实施例的业务调度方法。
54.图3示意性示出了根据本公开一实施例的业务调度方法的流程图。
55.如图3所示，该业务调度方法例如可以包括操作s301～s303。
56.在操作s301，根据待处理业务的属性信息将待处理业务分解为多个子业务，对多个子业务进行分类，并确定多个子业务之间的依赖关系，其中，依赖关系用于表征多个子业务的执行顺序。
57.在操作s302，根据多个子业务的业务类型创建维护角色，为每一维护角色创建任务队列，基于依赖关系将多个子业务按照业务类型添加至对应维护角色的任务队列中。
58.在操作s303，响应于待处理业务的申请请求，调用对应的任务队列指示该任务队列对应的维护角色执行待处理业务。
59.在本公开实施例中，网点可以基于营销业务的属性信息对外拓的营销业务进行自定义分解、分类及关系定义，得到业务分流标准。属性信息是业务本身具备的特征，用于表征不同类型的业务或者同一类型业务不同环节的子业务，例如，对于银行而言，其业务可以包括借记卡业务、信用卡业务，理财业务，金融咨询教育业务，每一业务都可以配置对应属性信息以便业务系统能够直接根据属性信息识别具体需要办理的业务类型。又例如，对于借记卡业务或信用卡业务而言，其包括申请、激活、绑定等业务环节，将所有的环节办理完成意味整个业务办理结束，而为了业务系统能够更好地识别不同环节的子业务，也可以为不同环节的子业务配置对应的属性信息，后续业务系统便可以根据属性信息快速地识别当前业务所处的子环节。
60.示例性地，基于属性信息的配置，在分解环节，借记卡办理业务可分解为借记卡申请、借记卡激活、app下载、公众号关注、借记卡绑定、防涉诈教育，信用卡办理业务可分解为信用卡申请、信用卡激活、app下载、公众号关注、信用卡绑定、防涉诈教育。在分类环节，借记卡申请、借记卡激活、信用卡申请、信用卡激活可归类为专用终端机类业务，app下载、公众号关注、借记卡绑定、信用卡绑定可归类为非专用终端机类业务，防涉诈教育可归类为咨询教育类业务；在依赖关系定义环节，借记卡激活需要在借记卡申请完成后进行，app下载需要在借记卡激活完成后进行，借记卡绑定需要在app下载完成后进行，防涉诈教育无前序依赖关系，可在任意时候进行，信用卡激活需要在信用卡申请完成后进行，app下载需要在信用卡激活完成后进行，信用卡绑定需要在app下载完成后进行，防涉诈教育无前序依赖关系，可在任意时候进行。
61.在本公开实施例中，基于分解及分类好的子业务，网点可以基于子业务的类型创建外拓营销的维护角色及任务队列，网点需要为外拓营销任务创建独立任务队列，以为客户提供线上排队取号服务。在创建任务队列时，网点需要为外拓营销工作人员指定其主要的维护角色，如：甲主要维护角色为专用终端机类业务，乙主要维护角色为非专用终端机类业务，丙主要维护角色为咨询教育类业务。为了业务更细致，更能满足客户的需求，对于专用终端机类业务、非专用终端机类业务、咨询教育类业务还可以进一步分解，例如，甲主要维护角色为借记卡的专用终端机类业务，乙主要维护角色为信用卡的专用终端机类业务，丙主要维护角色为借记卡的非专用终端机类业务，丁主要维护角色为信用卡的非专用终端
机类业务，戊主要维护角色为理财产品咨询类业务，己主要维护角色为防诈教育类业务。具体维护角色可以根据当前应用场景的实际应用需求配置，本公开不做限制。
62.根据本公开的实施例，当客户通过终端选择拟办理的业务并发起业务申请请求，系统网点服务器获取业务申请请求，对业务申请请求进行解析，得到客户需要办理的业务，根据定义的业务分流标准对客户需要办理的业务进行分解形成子业务，例如，如客户a拟预约借记卡办理业务，根据预定业务分流标准，该业务可分解为借记卡申请、借记卡激活、app下载、公众号关注、借记卡绑定、防涉诈教育子业务；客户b拟办理信用卡激活业务，根据预定业务分流标准，该业务可分解为信用卡激活、app下载、公众号关注、信用卡绑定、信用卡分期咨询子业务；客户c拟办理理财产品业务，根据预定业务分流标准，该业务可分解为理财产品的介绍、理财产品的办理、理财产品后期收益的结算等。
63.网点服务器将分解后的子业务根据子业务的类型及业务依赖关系分流至相应维护角色的任务队列。如：客户a的借记卡申请业务和客户b的信用卡激活业务被添加至专用终端机类子队列，客户b的app下载、公众号关注业务被添加至非专用终端机类子队列，客户a的防涉诈教育业务被添加至咨询教育类子队列。通过调用对应的任务队列，便可以快速办理客户a和客户b的对应的子业务。服务器对已办理完成子业务的客户进行重新调度。如：在客户a办理完借记卡申请业务后，根据预定义的业务分流标准，其紧后业务为借记卡激活，故将客户a的借记卡激活业务添加至专用终端机类子队列；在客户a办理完借记卡激活业务后，根据预定义的业务分流标准，其紧后业务为app下载，故将客户a的app下载业务添加至非专用终端机类子队列。
64.根据本公开实施例提供的业务调度方法，基于业务的属性信息对业务进行分解，对子业务进行分类，实现业务的分流，对分流后的子业务创建对应的维护角色及任务队列，将分流后的业务加入对应的任务队列中，一方面可以实现业务的明确分工，另一方面基于依赖关系可以快速地识别任务队列中待处理的子业务进行及时处理，从而降低了客户排队时间，显著提升外拓营销的业务办理效率，进而提升人效及客户满意度。
65.图4示意性示出了根据本公开另一实施例的业务调度方法的流程图。
66.如图4所示，该业务调度方法除包括操作s301～操作s303，还包括操作s304。
67.在操作s301，根据待处理业务的属性信息将待处理业务分解为多个子业务，对多个子业务进行分类，并确定多个子业务之间的依赖关系，其中，依赖关系用于表征多个子业务的执行顺序。
68.在操作s302，根据多个子业务的业务类型创建维护角色，为每一维护角色创建任务队列，基于依赖关系将多个子业务按照业务类型添加至对应维护角色的任务队列中。
69.在操作s303，响应于待处理业务的申请请求，调用对应的任务队列指示该任务队列对应的维护角色执行待处理业务。
70.在操作s304，响应于任务队列为空，基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色。
71.在本公开实施例中，当某一维护角色的任务队列为空时，可以根据规则s2进行人员调度。如当前没有客户在咨询教育类子队列中，则根据规则s2将负责咨询教育类业务的工作人员调度至其他岗位。规则s2可以采用基于加权惩罚最小优先的启发式贪婪算法生成调度方案。
72.图5示意性示出了根据本公开实施例的基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色的方法流程图。
73.如图5所示，该于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色的方法例如可以包括操作s501～操作s505。
74.在操作s501，获取每一维护角色处理对应子业务的耗时，子业务在任务队列中的等待时间，待处理业务的申请请求对应的用户的到达时刻。
75.在操作s502，计算每一维护角色处理子业务的综合惩罚因子。
76.在操作s503，确定每一维护角色处理待处理业务的申请请求对应的子任务的状态变量。
77.在操作s504，建立耗时，等待时间，到达时刻和综合惩罚因子、状态变量与待处理业务的申请请求对应的所有子业务的综合开销之间的关系。
78.在操作s505，确定综合开销最小时各维护角色的数量，根据各维护角色的数量变更空的任务队列对应的维护角色。
79.进一步地，图6示意性示出了根据本公开实施例的综合惩罚因子的计算方法流程图。
80.如图6所示，该计算方法例如可以包括操作s601～操作s603。
81.在操作s601，对于每一子业务，获取该子业务对应的维护角色的第一数量以及等待执行该子业务的待处理业务的申请请求的第二数量。
82.在操作s602，对于每一维护角色，响应于该维护角色执行的当前子任务为对应的任务队列中的子任务，将该维护角色处理执行的当前子任务的综合惩罚因子设置为1。
83.在操作s603，对于每一维护角色，响应于该维护角色执行的当前子任务不为对应的任务队列中的子任务，根据第一数量和第二数量计算维护角色处理执行的当前子任务的综合惩罚因子。
84.进一步地，图7示意性示出了根据本公开实施例的状态变量的确定方法流程图。
85.如图7所示，该确定方法例如可以包括操作s701～操作s703。
86.在操作s701，对于每一维护角色，判断该维护角色执行的当前子任务是否为对应的任务队列中的子任务。
87.在操作s702，响应于该维护角色执行的当前子任务为对应的任务队列中的子任务，将状态变量设置为1。
88.在操作s703，响应于该维护角色执行的当前子任务不为对应的任务队列中的子任务，将状态变量设置为0。
89.根据本公开实施例提供的业务调度方法，在某一任务队列为空，也即存在维护角色空闲的情况下，基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色，将空闲的维护角色变更为当前需要的维护角色，在最小综合开销的情况下，实现维护角色的充分利用，进一步提升了业务办理效率，进而提升人效及客户满意度。
90.为了进一步清楚地阐述基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色，以生成调度策略的过程，下面举例进行说明。
91.示例性地，对基于加权惩罚最小优先的启发式贪婪法生成调度策略的相关符号定义如下：
92.m：工作人员序号(维护角色)，m＝1，...，m，即共有m个工作人员。
93.i：业务类型序号，i＝1，...，i，即共有i种业务。
94.j：客户序号，j＝1，...，j，即共有j个客户。
95.p
ij
：客户j处理子业务i所需的时间(耗时)。
96.t：当前时刻。
97.rj：客户j到达时刻。
98.s
ij
：客户j在子业务i对应的任务队列中等待的时间。
99.ej：客户j实际结束流程的时刻，用于更新业务耗时数据库。
100.在本公开一实施例中，获取每一维护角色处理对应子业务的耗时，具体可以包括：获取业务耗时数据库的各子业务的历史耗时数据。对于每一子业务，计算该子业务对应的所有历史耗时数据的平均值，作为维护角色处理该子业务的耗时p
ij
。
101.如前文所述，每个工作人员都预先分配有维护角色(主任务)，所有工作人员对应的维护角色可以不同，也可是所有工作人员分为几组，每组内的工作人员的维护角色相同，具体工作人员维护角色的分配可以根据实际需求配置，本公开不做限制。为保证整体业务效率，在调度时会优先令工作人员从事主任务，在处理非主任务时会设置相应惩罚因子。
102.工作人员m处理子业务i的综合惩罚因子可以通过以下方式计算：
103.当工作人员m当前处理的子业务i是为工作人员m分配的维护角色对应的主任务时，将工作人员m处理子业务i的综合惩罚因子w
mi
设置为1。
104.当工作人员m当前处理的子业务i是为工作人员m分配的维护角色对应的主任务时，将工作人员m处理子业务i的综合惩罚因子w
mi
设置为a
mi
与di之积。其中，a
mi
为工作人员m处理业务i的代价，di为等待进行子业务i的客户的数量，或称为等待执行子业务i的待处理业务的申请请求的第二数量。a
mi
一种优选的取值为：
[0105][0106]
其中，mi为子业务i对应的维护角色(工作人员)的第一数量。
[0107]
进一步地，需要定义在t时刻，工作人员m是否为第j个客户处理第i个业务的状态变量，状态变量需要满足约束条件：
[0108]
当在t时刻，工作人员m(主任务为i)为第j个客户处理第i个业务，则状态变量ω
mij
(t)设置为1。
[0109]
除在t时刻，工作人员m为第j个客户处理第i个业务这种情况外，其他情况对应的状态变量ω
mij
(t)均设置为0。例如，由于客户提交业务申请请求，服务器也响应该业务申请请求后，可能还需要等待一段等待时间，客户提交业务申请请求后拿号，当服务器响应该业务申请请求时会叫号，从叫号到客户开始办理业务中间会存在一段空档时间，也即，当t＜rj时，表明客户还没到达业务办理的区域，不能开始安排任务，因此，状态变量设置为0。
[0110]
基于上述计算的综合惩罚因子和状态变量，可以建立耗时，等待时间，到达时刻和综合惩罚因子、状态变量与待处理业务的申请请求对应的所有子业务的综合开销之间的关系，具体可以关系可以如下：
[0111]
基于业务耗时数据库的历史数据估算的处理第j个客户所有业务的系统综合开销cj
为：
[0112][0113]
则处理j个客户所有业务的系统综合开销为∑cj，此时，优化目标为∑cj最小化，即最小化外拓营销业务的总完成时间，优化的数学模型可以为：
[0114][0115]
对应的约束条件具体可以如下：
[0116][0117][0118][0119]
以上三个约束条件的物理意义分别为：工作人员m在同一时间只能处理一个业务；客户j在同一时间只能进行一个业务的办理；同一时间处理所有任务的工作人员不能超过m个。
[0120]
由于cj的复杂性，而且每次都要基于当前任务列表，从t时刻优化到所有任务结束时刻，因此，∑cj最小化是一个非凸、np-hard问题。
[0121]
图8示意性示出了根据本公开实施例的∑cj最小化求解方法流程图。
[0122]
如图8所示，该求解方法例如可以包括操作s801～操作s805。
[0123]
在操作s801，由当前时刻t的调度状态，更新w
mi
、rj、s
ij
的值，且根据ω
mij
(t)的约束条件确定优化问题的可行域。
[0124]
在操作s802，利用加权乘法最小准则，计算单位惩罚矩阵。
[0125]
在本公开实施例中，对每一个工作人员，计算单位惩罚矩阵γi×j，取矩阵中最小值对应的i*和j*，令ω
mi*j*
(t)为1，对于其余的i和j，令ω
mij
(t)为0，记此调度结果矩阵为ω*(t)，其中，单位惩罚矩阵γi×j为：
[0126][0127]
在操作s803，基于当前时刻t对应的队列调度状态，假设在t时刻不进行任何任务调度，计算t+1时刻的w
mi
、rj、s
ij
的值。
[0128]
计算过程可以为：令t取t+1，执行操作s801～操作s802，调度结果矩阵为ω*(t+1)。
[0129]
在操作s804，基于当前时刻t对应的队列调度状态，假设在t时刻和t+1时刻不进行
任何任务调度，计算t+2时刻的w
mi
、rj、s
ij
的值。
[0130]
计算过程可以为：令t取t+2，执行操作s801～操作s802，调度结果矩阵为ω*(t+2)。
[0131]
在操作s805，对于ω*(t)、ω*(t+1)、ω*(t+2)，分别计算此轮调度后的∑cj，取令∑cj结果最小的ω*作为最优调度策略。
[0132]
综上所述，本公开实施例提供的业务调度方法，在现有线上排队叫号系统的基础上完成对外拓营销场景的适配，基于系统自动实现业务自动分解、分流及空闲岗位的灵活调度，解决当前外拓营销存在的分工模式不成熟导致的业务办理效率低问题。
[0133]
图9示意性示出了根据本公开一实施例的业务调度装置的框图。
[0134]
如图9所示，业务调度装置900可以包括分解模块910、创建模块920及调度模块930。
[0135]
分解模块910，用于根据待处理业务的属性信息将待处理业务分解为多个子业务，对多个子业务进行分类，并确定多个子业务之间的依赖关系，其中，依赖关系用于表征多个子业务的执行顺序。
[0136]
创建模块920，用于根据多个子业务的业务类型创建维护角色，为每一维护角色创建任务队列，基于依赖关系将多个子业务按照业务类型添加至对应维护角色的任务队列中。
[0137]
调度模块930，用于响应于待处理业务的申请请求，调用对应的任务队列指示该任务队列对应的维护角色执行待处理业务。
[0138]
图10示意性示出了根据本公开另一实施例的业务调度装置的框图。
[0139]
如图10所示，业务调度装置900例如还可以包括变更模块940。
[0140]
变更模块940，用于响应于任务队列为空，基于加权惩罚最小优先的启发式贪婪法变更空的任务队列对应的维护角色。
[0141]
图11示意性示出了根据本公开一实施例的变更模块的框图。
[0142]
如图11所示，变更模块940例如可以包括获取单元941、计算单元942、确定单元943、构建单元944以及变更单元945。
[0143]
获取单元941，用于获取每一维护角色处理对应子业务的耗时，子业务在所述任务队列中的等待时间，待处理业务的申请请求对应的用户的到达时刻。
[0144]
计算单元942，用于计算每一维护角色处理所述子业务的综合惩罚因子。
[0145]
确定单元943，用于确定每一维护角色处理待处理业务的申请请求对应的子任务的状态变量。
[0146]
构建单元944，用于建立耗时，等待时间，到达时刻和综合惩罚因子、状态变量与待处理业务的申请请求对应的所有子业务的综合开销之间的关系。
[0147]
变更单元945，确定综合开销最小时各维护角色的数量，根据各维护角色的数量变更空的任务队列对应的维护角色。
[0148]
根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门
阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
[0149]
例如，分解模块910、创建模块920、调度模块930、变更模块940中的任意多个可以合并在一个模块/单元/子单元中实现，或者其中的任意一个模块/单元/子单元可以被拆分成多个模块/单元/子单元。或者，这些模块/单元/子单元中的一个或多个模块/单元/子单元的至少部分功能可以与其他模块/单元/子单元的至少部分功能相结合，并在一个模块/单元/子单元中实现。根据本公开的实施例，分解模块910、创建模块920、调度模块930、变更模块940中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，分解模块910、创建模块920、调度模块930、变更模块940中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
[0150]
需要说明的是，本公开的实施例中业务调度装置部分与本公开的实施例中业务调度方法部分是相对应的，其具体实施细节及带来的技术效果也是相同的，在此不再赘述。
[0151]
图12示意性示出了根据本公开实施例的适于实现上文描述的方法的电子设备的框图。图12示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
[0152]
如图12所示，根据本公开实施例的电子设备1200包括处理器1201，其可以根据存储在只读存储器(rom)1202中的程序或者从存储部分1208加载到随机访问存储器(ram)1203中的程序而执行各种适当的动作和处理。处理器1201例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器1201还可以包括用于缓存用途的板载存储器。处理器1201可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
[0153]
在ram 1203中，存储有电子设备1200操作所需的各种程序和数据。处理器1201、rom 1202以及ram1203通过总线1204彼此相连。处理器1201通过执行rom 1202和/或ram1203中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom 1202和ram 1203以外的一个或多个存储器中。处理器1201也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
[0154]
根据本公开的实施例，电子设备1200还可以包括输入/输出(i/o)接口1205，输入/输出(i/o)接口1205也连接至总线1204。电子设备1200还可以包括连接至i/o接口1205的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1206；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1207；包括硬盘等的存储部分1208；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1209。通信部分1209经由诸如因特网的网络执行通信处理。驱动器1210也根据需要连接至i/o接口1205。可拆卸介质1211，诸如磁盘、
光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1210上，以便于从其上读出的计算机程序根据需要被安装入存储部分1208。
[0155]
根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1209从网络上被下载和安装，和/或从可拆卸介质1211被安装。在该计算机程序被处理器1201执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
[0156]
本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
[0157]
根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质。例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
[0158]
例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom1202和/或ram 1203和/或rom 1202和ram 1203以外的一个或多个存储器。
[0159]
附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。