Systems and methods for intelligent orchestration of digital workforce

Abstract

Examples of the present disclosure relate to systems and methods for intelligent orchestration of digital workforces. Specifically, embodiments relate to prioritizing and sequencing workflows by managing Robotic Process Automation (RPA) robots.

Description

Technical Field

[0001] Examples of the present disclosure relate to systems and methods for intelligent orchestration of digital workforces. Specifically, embodiments relate to managing, prioritizing, and sequencing execution of tasks through Robotic Process Automation (RPA) robots. Background Art

[0002] RPA is an emerging form of business process automation technology that utilizes software robots or artificial intelligence (AI) workers (hereinafter individually and collectively referred to as "robots"). In traditional workflow automation tools, software developers use internal application program interfaces to generate action lists to automate tasks. In contrast, RPA systems develop action lists by observing users perform tasks in the application's graphical user interface, and then perform automation by repeating these tasks directly on the graphical user interface.

[0003] Traditionally, digital workers have been viewed as a cost-effective way to displace or transfer digital work from users. However, various factors often lead to underutilization of robots. In addition, as the size of the digital workforce increases, it becomes difficult to determine whether robots are working for the tasks that an enterprise expects.

[0004] Current systems utilize robots in a variety of inefficient or suboptimal ways, including: first-in, first-out techniques, human intervention to determine what tasks to perform, grouping tasks using queues with different priority levels, and scheduling. However, these techniques are procedural and time-intensive to set up, while not taking into account task-level business priorities and / or service agreements, dynamic variables and trends to predict the likelihood of work and corresponding tasks being generated.

[0005] Therefore, more efficient and effective systems and methods are needed to manage and distribute RPA robots by utilizing an orchestration layer to complete tasks in a shorter period of time while conserving system resources. Summary of the invention

[0006] Embodiments described herein are directed to systems and methods for prioritizing and sequencing workflows by managing, enabling, and sequencing RPA robots. Embodiments are configured to allow RPA robots to simulate user tasks, wherein the output of the RPA robots increases as the RPA robots become more aware of the application landscape on which they are provisioned. Embodiments may utilize a task queuing system configured to allow management of work and tasks based on business priorities, service level agreements, and other factors. Embodiments may include an orchestration layer configured to manage RPA robots for a series of channels for generating work.

[0007] Embodiments may include channels, API hardware, task queuing hardware, application prediction model hardware, task profile prediction model hardware, orchestration layer hardware, and RPA robots.

[0008] A channel can be a task or job (hereinafter individually and collectively referred to as a "task") created for the task queuing hardware. Tasks can be received from a self-service web form, a PDF processed by an OCR engine, a chatbot, an email or SMS, an existing range of business systems or applications, or triggered by an API, or any other task that requires computational processing. Tasks can be configured to be associated with any computing resource on which a user can perform tasks in the graphical user interface of an application.

[0009] The API hardware can be activated within the enterprise suite to trigger the queuing of tasks at the task queuing hardware. The API hardware can be configured to determine the task type, priority, etc. of different systems. The priority of the work can be determined by the AI ​​or by user action to prioritize the tasks to be completed.

[0010] The task queuing hardware may be configured to receive tasks from a channel via the API hardware, determine in what order and when the tasks are to be completed, and manage the RPA robots associated with the queued tasks.

[0011] The orchestration hardware can be configured to distribute work to the controllers of the RPA robots as they become available. The orchestration hardware can be configured to determine the current queue of tasks to be completed and determine which tasks to process based on input from the application prediction model hardware and the task profile prediction model hardware. Based on input from the model hardware, the orchestration hardware can dynamically determine the changing outlook for different work times for tasks and application trends without the need for fixed rules.

[0012] The application prediction model hardware may be configured to determine a predictive analysis to determine the future expected performance of the RPA robot associated with the queued tasks within a given time span. This may enable an increase in the throughput of the number of tasks that the RPA robot is able to perform within a given time span. The efficiency of the RPA robot may be associated with the duration required to perform a task at a given time based on other system requirements, the length of time required for the RPA robot to perform the task, and / or a combination.

[0013] The task profile prediction model hardware may be configured to determine when certain types of tasks will be queued on the task queuing hardware, and what priority level will be assigned to any task. Based on the task profile prediction model's determination of the number and type of tasks to be received, the task queuing hardware may not assign an RPA robot to all current tasks, and may suspend at least one RPA robot until a higher priority task may be received.

[0014] These and other aspects of the present invention will be better appreciated and understood when considered in conjunction with the following description and accompanying drawings. The following description, although indicating various embodiments of the present invention and numerous specific details thereof, is provided by way of illustration and not limitation. Many substitutions, modifications, additions or rearrangements may be made within the scope of the present invention, and the present invention includes all such substitutions, modifications, additions or rearrangements. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Non-limiting and non-exhaustive embodiments of embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

[0016] Figure 1 A topology for intelligent orchestration of a digital workforce according to an embodiment is shown.

[0017] Figure 2 One embodiment of a server according to an embodiment is depicted.

[0018] Figure 3 A method for an RPA robot to perform actions to complete queued tasks according to an embodiment is described.

[0019] Figure 4 An RPA robot according to an embodiment is depicted.

[0020] Figure 5 A task queuing system according to an embodiment is depicted.

[0021] Figure 6 A topology for intelligent orchestration of a digital workforce is depicted according to an embodiment.

[0022] In the several views of the accompanying drawings, corresponding reference numerals indicate corresponding parts. It will be appreciated by those skilled in the art that the elements in the accompanying drawings are shown for simplicity and clarity and are not necessarily drawn to scale. For example, the sizes of some elements in the drawings may be enlarged relative to other elements to help improve the understanding of the various embodiments of the present disclosure. In addition, common but well-known elements that are useful or necessary in commercially feasible embodiments are generally not depicted so as to less obstruct the viewing of these various embodiments of the present disclosure. DETAILED DESCRIPTION

[0023] In the following description, many specific details are set forth to provide a thorough understanding of the present invention. However, it is apparent to one of ordinary skill in the art that these specific details are not required to implement the present invention. In other cases, in order to avoid making the present invention unclear, known materials or methods are not described in detail.

[0024] Now go to Figure 1 , Figure 1 A topology for intelligent orchestration of a digital workforce is described. Embodiments may be configured to drive effective and efficient utilization of RPA robots, thereby allowing more work to be completed in a shorter time frame. Topology 100 may include a client computing device 105 and a server 120 for work / task creation, both configured to be communicatively coupled via a network 110.

[0025] The network 110 can be a wired or wireless network, such as the Internet, an intranet, a LAN, a WAN, an NFC network, a Bluetooth, an infrared, a radio frequency, a cellular network, or another type of network. It is understood that the network 110 can be a combination of multiple different types of wired or wireless networks, all of which result in tasks being created in the queue.

[0026] The client computing device 105 may be a smart phone, tablet, laptop, computer, personal data assistant, or any other type of mobile device having a hardware processor configured to process instructions and connected to one or more parts of the network 130. The client computing device 105 may have a graphical user interface configured to allow a user to interact with the processor of the client computing device 105 to create a job. In an embodiment, the job and the corresponding task are configured to be transmitted to the server 120 via the network 110. The job and the task may be associated with a self-service web form, a PDF processed by an OCR engine, a chatbot, an email or SMS, an existing series of business systems or applications, or triggered by an API, etc. In an embodiment, each task may have associated keystrokes, inputs on a graphical user interface, or other actions that can be performed by a user. These tasks may also be completed by the RPA robot 140, which replaces the user to perform actions based on metadata associated with the task, such as keystrokes required on a graphical user interface. For example, a task generated by the client computing device 105 may be associated with entering a job profile and user privileges on the network.

[0027] The server 120 may be a computing resource configured to remotely provision, allocate, manage, and control the RPA robot 140 to perform tasks generated by the client computing device 105. The server 120 may be configured to set business metrics and initiate tasks through an entry point API. The entry point API of the server 120 may be initiated, automatically triggered, or combined in various ways within an enterprise through any of a plurality of client computing devices 105. The server 120 may be configured to allow an organization to have different tasks with different priorities to be completed first by the RPA robot 140. Business metrics may be weights, such as organizational priorities, service level agreements, and operational level agreements that may be associated with process or task levels. Business metrics associated with different tasks may be created autonomously by the server 120 and / or set by human users.

[0028] Server 120 may include a physical computing device residing at a specific location, or may be deployed in a cloud computing network environment. In this description, "cloud computing" may be defined as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services), which may be rapidly provisioned via virtualization and released with minimal management effort or service provider interaction, and then scaled accordingly. Cloud models may consist of various features (e.g., on-demand self-service, extensive network access, resource pooling, rapid elasticity, measurable services, etc.), service models (e.g., software as a service ("SaaS"), platform as a service ("PaaS"), infrastructure as a service ("IaaS")), and deployment models (e.g., private cloud, community cloud, public cloud, hybrid cloud, etc.). Server 120 may include any combination of one or more computer-available or computer-readable media. For example, server 120 may include a computer-readable medium including one or more of a portable computer disk, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or flash memory) device, a portable compact disk read-only memory (CDROM), an optical storage device, and a magnetic storage device.

[0029] In this description, "cloud computing" may be defined as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be quickly provisioned via virtualization and released with minimal management effort or service provider interaction, and then scaled accordingly. The cloud model may consist of various features (e.g., on-demand self-service, extensive network access, resource pooling, rapid elasticity, measurable services, etc.), service models (e.g., software as a service ("SaaS"), platform as a service ("PaaS"), infrastructure as a service ("IaaS")), and deployment models (e.g., private cloud, community cloud, public cloud, hybrid cloud, etc.). In an embodiment, the server 120 may be configured to enable and disable RPA robots based on service level agreements, queued tasks, and / or combinations. For example, the server 120 may be configured to allocate computing resources based on computing resources to increase the number of RPA robots 140 to complete currently queued tasks and predicted future tasks. For example, the server 120 may be configured to determine a time frame required for a single RPA robot 140 to complete a current set of tasks. If the determined time frame is greater than a time threshold, the server 120 may determine a second time frame required for a plurality of RPA robots 140 to complete the current set of tasks, wherein the second time frame is less than the time threshold. Each time an RPA robot 140 completes a given task, this determination may be made dynamically based on an updated model associated with the RPA robot 140 that completed the task.

[0030] Server 120 may include task queuing hardware, orchestration hardware 130 , and RPA robot 140 .

[0031] The task queuing hardware may be configured to receive tasks to be performed by the RPA robot 140 from the client computing device 105. The task queuing hardware may be configured to determine what RPA robot 140 performs what task and when to perform it, which may be the current time or a future time. In response to the task queuing hardware receiving a task or work to be completed from the client computing device 105 through a channel, the task queuing hardware may assign a business or metric weighting to the task. Based on weightings, service level agreements, predictive models, etc., the task queuing hardware may supply computing resources, such as the RPA robot 140, to perform tasks or manage tasks in a queue. In an embodiment, the task may remain in the task queuing hardware until the RPA robot 140 completes another task. The task queuing hardware may also be configured to store a repository of task blueprints associated with tasks. The task blueprint may include inputs to be input by the RPA robot 140 associated with the task.

[0032] The orchestration hardware 130 may be a hardware computing device that is configured as a controller to assign work to the RPA robots 140. The orchestration hardware 130 may determine the tasks queued at the task queuing hardware to be completed, and determine which project to assign to the RPA robot 140 based on the application prediction model and the task profile prediction model through machine learning. These two models may be configured to allow the orchestration hardware 130 to make determinations dynamically without fixed rules. The orchestration hardware 130 may utilize recursive and continuous algorithms to determine the most effective and efficient use of the RPA robot 140 for current and anticipated future tasks at each instance once the RPA robot 140 has completed the task.

[0033] The RPA robot 140 can be software that is configured to perform tasks through a prescribed keystroke run table completed by the RPA robot 140 for a range of business systems and applications, simulating the interaction of human users. The RPA robot 140 can be configured as software located on a dedicated operating system and automatically performs assigned tasks. The RPA robot 140 can also be configured to generate data in response to completing a task. The data generated by the RPA robot 140 may include a given time period for completing a specific task, computing resources for completing a specific task, and the like.

[0034] Figure 2 One embodiment of a server 120 is depicted. Those skilled in the art will appreciate that certain components associated with the server 120 may be stored locally at the client computing device 105. Thus, the components described below may also be stored at the client computing device 105.

[0035] The server 120 may include a processing device 205 , a communication device 210 , a memory device 215 , an orchestration hardware device 220 , a robot execution metadata 230 , an application data source module 235 , an application prediction model 240 , a task profile data source module 245 , a task profile prediction model 250 , and RPA availability hardware 155 .

[0036] The processing device 205 may include a memory, such as a read-only memory (ROM) and a random access memory (RAM), that stores processor-executable instructions, and one or more processors that execute the processor-executable instructions. In embodiments where the processing device 205 includes two or more processors, the processors may operate in parallel or in a distributed manner. The processing device 205 may execute an operating system of the server 120 or software associated with other components of the server 120.

[0037] The communication device 210 may be a device that allows the server 120 to communicate with another device via the network 130. The communication device 210 may include one or more wired / wireless transceivers for performing wireless communications via the network 110. The communication device 210 may be configured to receive tasks from the client computing device 105 and send data associated with completed tasks associated with the RPA robot 140 to the client computing device 105.

[0038] The memory device 215 may be a device that stores data generated or received by the server 110. The memory device 215 may include, but is not limited to, a hard drive, an optical drive, and / or a flash drive. In an embodiment, the memory device 215 may also be configured to store information received from the client computing device 105, such as business metrics, rules, etc. The memory device 215 may also be configured to store metadata associated with tasks, data associated with prediction models, and data associated with the RPA robot 140.

[0039] The orchestration hardware device 220 may be a hardware processing device that may be configured to determine which tasks stored within the task queuing system need to be completed, the weights associated with each task, analyze a predictive model of which tasks may need to be performed in a given time frame, analyze software applications associated with the tasks to be completed by the RPA robot 140, and determine the length of time and computing resources for the RPA robot 140 to complete the task. In this way, the orchestration hardware device 220 may be configured to manage the RPA robots 140 for tasks currently in the task queuing hardware and tasks predicted to be in the task queuing hardware, and manage computing resources to enable and disable the RPA robots 140 based on current and predicted future tasks and RPA robot efficiency.

[0040] The robot execution metadata 230 can be a hardware processing device configured to determine metadata associated with an RPA robot that completes a specific task. The metadata may include the computing resources required by the RPA robot 140 to complete the task, the operating system required to complete the task, the files required to complete the task, and the Internet protocol required to complete a given task. The metadata can be stored in the memory device 215 and used by subsequent RPA robots 140 to complete similar tasks. In this way, multiple RPA robots 140 can use metadata stored in the file repository to complete tasks, which can make the RPA robot 140 more efficient while limiting the computing resources required to perform the task. The robot execution metadata 230 can also include the process steps required to complete the task when the RPA is performing actions on the client device to complete the task. In an embodiment, the process steps can be set by the user before the RPA robot 140 performs the task, or recorded autonomously by the robot execution metadata 230 in response to the user performing the task.

[0041] The application data source 325 module can be a hardware processing device configured to generate metadata based on the performance metrics of the RPA robot that completes the tasks of the software program. For example, the performance metrics can include application performance per unit time. When the RPA robot 140 performs an automated process interaction, the performance metrics can be determined. For example, when the software application is started by the RPA robot, the RPA robot logs into the application, and the RPA robot browses different pages, the performance metrics can be collected. The collected metadata relates to the application performance relative to the personal data about the process.

[0042] The application prediction model 240 can be a hardware processing device that is configured to determine a predictive analysis to control the future expected performance of a software application within a given time span. For example, based on the available data set, the application prediction model can determine that the first software application is executed 15% slower at 09:23 compared to the 23% performance increase when the first software application is used at 10:54. The predictive analysis can be based on the average computing resources required by the server 120 for different time periods for multiple RPA robots to perform different tasks. The predictive analysis can result in an increase in the throughput of the number of tasks that the RPA robot 140 can perform in a given day based on the performance of different software applications at different times. In an embodiment, the predictive analysis and model operate within the desired business metrics provided.

[0043] The task profile data source module 245 can be a hardware processing device that is configured to generate metadata based on the profile of a task within a business or business unit before or after the task is queued within the task queuing system. In response to receiving a task from a client computing device, the robot execution metadata 235 can determine the attributes of the task. The attributes can include data such as the requester, the associated business process, time, and other values ​​that are tracked in order to build a view of common task types. These attribute values ​​can be used by the model to determine the profile of the task.

[0044] The task profile prediction model 250 can be a hardware device configured to determine when the task queuing hardware will receive certain types of tasks. The task profile prediction model 250 can be configured to determine what type of tasks can be received when based on historical data. For tasks with a priority level above a threshold, the probability above the threshold when these tasks will be received can be determined so that the RPA robot 140 can remain idle / suspended. This can allow the RPA robot 140 to perform actions to perform tasks in response to receiving a task. If the predicted task is not generated within the predicted window, other tasks will be performed by the RPA robot 140 in its place.

[0045] The RPA robot availability hardware 255 is configured to determine whether the orchestration hardware 120 has fully deployed the RPA robots to complete the current tasks in the task queuing system and the predicted future tasks regarding the efficiency of the corresponding application. In response to the RPA robot 140 completing the task, the RPA robot availability hardware 255 can determine the current number of supplied RPA robots to complete each task in the queue and the predicted amount of time required for the predicted tasks that will be in the queue within a given time period. If the predicted amount of time is lower than the given time period, the RPA robot availability hardware 255 can reduce the number of supplied RPA robots to save computing resources. If the predicted amount of time is greater than the given time period, the RPA robot availability hardware 255 can increase the number of supplied RPA robots for the purpose of efficiency. By determining the predicted amount of time in response to the RPA robot 140 completing the task, the predicted amount of time can be changed dynamically and continuously to optimize computing resources.

[0046] Figure 3 A method 300 for an RPA robot to perform actions to complete queued tasks according to an embodiment is shown. The operations of the method 300 presented below are intended to be illustrative. In some embodiments, the method 300 may be performed with one or more additional operations not described and / or without one or more of the operations discussed. In addition, Figure 3 The order in which the operations of method 300 are illustrated and described below is not intended to be limiting.

[0047] In some embodiments, method 300 may be performed in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed to process information, analog circuits designed to process information, state machines, and / or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices that perform some or all of the operations of method 300 in response to instructions electronically stored on an electronic storage medium. The one or more processing devices may include one or more devices configured by hardware, firmware, and / or software that are specifically designed to perform one or more operations of method 300.

[0048] At operation 310, a task to be completed may be received. In an embodiment, a priority weight and attributes may be assigned to the received task. The attributes may include the name of the task, the date and time the task was received, the date and time the task should be completed, and a unique identifier associated with the requester. The task may be defined by a prescribed keystroke run sheet that the RPA robot completes for a range of business systems and software applications, which may simulate the interaction of a human user.

[0049] At operation 320, the task queuing system may determine computing resources for all tasks in the real-time processing queue. In addition, the application prediction model may determine the future expected performance of the application associated with the tasks within the first time span, and the task profile prediction model may determine a prediction of the tasks to be received within the second time span. In an embodiment, the first time span and the second time span may be the same or different time periods, which may or may not overlap.

[0050] At operation 330 , the orchestration hardware system may determine whether an RPA robot is available to perform the received task based in part on the availability of the robot, the priority associated with the task, metadata associated with the received task, the profile prediction model, and the application prediction model.

[0051] At operation 340 , the orchestration hardware system may determine whether the RPA robot should perform the received task, another task in the queue, or remain idle.

[0052] At operation 350 , the RPA robot may perform actions to complete the task.

[0053] At operation 360, the task prediction model and the application prediction model may be updated based on the actions of the RPA robot to perform the task. The prediction model may be updated in response to the robot completing the task and the RPA robot becoming available. In this way, the RPA prediction model may be updated between the time it takes the RPA robot to perform the first task and the second task.

[0054] Figure 4An RPA bot 140 is depicted according to an embodiment. Figure 4 The components depicted in are described above, and for the sake of brevity, these components may not be described again.

[0055] like Figure 4 As depicted in , the RPA robot 140 can have a corresponding action list of tasks to be performed, which can be generated by a user inputting an action list or by copying the actions performed by the user for the same task in the application graphical user interface. The RPA robot 140 can then autonomously execute the action list directly on the GUI without the help of the user. The RPA can include an associated operating system 410, a local application 420, a remote file share 430, a Citrix receiver 440, and a browser 450.

[0056] The operating system 410 may allow the RPA robot 140 to execute software installed on the RPA robot 140. The executed software may enable the RPA robot 140 to control the local application 420 using data stored in the remote file share 430 via the receiver 440 and the browser 450.

[0057] Figure 5 A task queuing system 500 is depicted according to an embodiment. Figure 5 The components depicted in are described above, and for the sake of brevity, these components may not be described again.

[0058] In response to the server 120 receiving the task, the task queuing system 500 may be configured to add the task to the queue 510. In response to the RPA robot completing the task, the task may be removed from the queue 510. Each task added to the queue may have corresponding metadata, such as a unique identifier, a state, a name, an associated application, created data, started data, ended data, a number on the queue, and a business metric. In an embodiment, the business metric may include a business priority, a business service level agreement, a priority value, and a time value.

[0059] The business priority may be associated with a numerical value of importance, where a higher value may indicate a higher level of importance. The numerical value may be set by user interaction, or may be set based on the identity of the task. The time value may be a time period required to perform the task. A business service level agreement may indicate a minimum and / or maximum number of RPA robots that may be allocated to a given task queuing system, where if there are more RPA robots than tasks based on the business service level agreement, there may be idle RPA robots.

[0060] Figure 6 A topology for intelligent orchestration of a digital workforce according to an embodiment is depicted. Figure 6 The components depicted in are described above, and further description of these components is omitted for the sake of brevity.

[0061] like Figure 6 As shown, work or tasks may enter the work environment or entry point API 630 through different channels 105. The entry point API 630 may also receive business metrics 620, such as organizational priorities, service level agreements, and operating level agreements that may be associated with a process or task level.

[0062] The entry point API 630 may communicate with the task queuing system 610. The task queuing system 610 may also receive a business metric overlay 640 that allows a user to input data associated with the prioritization of tasks or work. The task queuing system 610 may also receive a business process 615, which may be a task blueprint or a repository of data to be executed by the RPA robot 140 to complete a task.

[0063] The orchestration hardware 130 may be configured as a controller that allocates work from the task queuing system 610 to the RPA robot 140 and transmits data indicating that the RPA robot 140 has completed the task to the task queuing system 610. The orchestration hardware 130 may also be configured to allocate tasks to the robot based on data from the task profile prediction model 250.

[0064] The robot execution metadata 230 may include data associated with data collected in response to the RPA robot 140 completing a task. The collected data may be sent to both the application data source module 235 and the task profile data source module 245. The data may then be used by both the application prediction model 240 and the task profile prediction model 250 to update the orchestration hardware 130 in response to the task being completed by the RPA robot 140.

[0065] Although the present technology has been described in detail for purposes of illustration based on what are presently considered to be the most practical and preferred implementations, it should be understood that such detail is solely for that purpose and that the present technology is not limited to the disclosed implementations, but rather is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the present technology contemplates that, to the extent possible, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0066] Throughout the specification, references to "one embodiment," "an embodiment," "an example," or "an example" mean that a particular feature, structure, or characteristic described in conjunction with the embodiment or example is included in at least one embodiment of the present invention. Therefore, the phrases "in one embodiment," "in an embodiment," "an example," or "an example" appearing throughout this specification do not necessarily all refer to the same embodiment or example. Furthermore, in one or more embodiments or examples, the particular features, structures, or characteristics may be combined in any suitable combination and / or sub-combination. Furthermore, it should be understood that the figures provided herein are for the purpose of explanation to persons of ordinary skill in the art, and that the figures are not necessarily drawn to scale.

[0067] Embodiments according to the present invention may be implemented as devices, methods or computer program products. Therefore, embodiments of the present invention may take the form of complete hardware embodiments, complete software embodiments (including firmware, resident software, microcode, etc.) or embodiments of combined software and hardware aspects, which may all be generally referred to as "modules" or "systems" herein. In addition, the present invention may take the form of a computer program product implemented in any tangible expression medium having a computer-usable program code implemented in the medium.

[0068] Any combination of one or more computer-usable or computer-readable media may be utilized. For example, a computer-readable medium may include one or more of a portable computer disk, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or flash memory) device, a portable compact disk read-only memory (CDROM), an optical storage device, and a magnetic storage device. The computer program code for performing the operations of the present invention may be written in any combination of one or more programming languages.

[0069] The flowcharts and block diagrams in the flowcharts illustrate the possible implementation architectures, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram may represent a module, segment or portion of a code, which includes one or more executable instructions for implementing a specified logical function. It will also be noted that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can be implemented by a combination of a dedicated hardware-based system or dedicated hardware and computer instructions that performs a specified function or action. These computer program instructions may also be stored in a computer-readable medium, which may guide a computer or other programmable data processing device to work in a particular manner, so that the instructions stored in the computer-readable medium produce an article of instruction means including an instruction device that implements the function / action specified in the flowchart and / or block diagram.

[0070] The following is a list of embodiments that may be claimed:

[0071] 1. A system for intelligent orchestration of digital workforce:

[0072] A task queuing system configured to receive a first task;

[0073] a first robotic process automation robot configured to perform actions to perform the first task;

[0074] and orchestration hardware configured to manage the first robotic process automation robot performing the action to perform the first task based on an application prediction model and a task prediction model, wherein the application prediction model is configured to determine an overdue performance of a computing resource associated with the first task at a first time period compared to a second time period, and the task prediction model is configured to determine future tasks to be added to the task queuing system within a period of time.

[0075] 2. The system of embodiment 1, wherein the orchestration hardware is configured to enable and disable a second robotic process automation robot in response to a robotic process automation robot performing an action to perform the first task in response to the first robotic process automation robot performing an action to perform the first task.

[0076] 3. The system of embodiment 1, wherein the task prediction model is configured to determine the future tasks to be added to the task queuing system based on a history of tasks added to the task queuing system.

[0077] 4. The system of embodiment 1, wherein the first robotic process automation robot is configured to generate metadata based on performance metrics of the first robotic process automation robot performing actions to perform the first task.

[0078] 5. The system of embodiment 1, wherein the first task comprises a prescribed run list of keystrokes associated with a client computing device to be automated by the first robotic process automation robot.

[0079] 6. The system of embodiment 1, wherein the first task comprises a business metric, the business metric being assigned a numerical value based on a priority.

[0080] 7. A system according to embodiment 1, wherein the task queuing system receives a second task, and in order to save computing resources, the orchestration hardware idles the first robotic process automation robot based on an application prediction model and a task prediction model when the second task is in the task queuing system.

[0081] 8. The system of embodiment 7, wherein the second task is the only task in the task queuing system.

[0082] 9. The system of embodiment 1, wherein the task queuing system is configured to determine an amount of computing resources required to complete all received tasks within the period of time.

[0083] 10. A system according to embodiment 1, wherein the overdue performance of the computing resources associated with the first task at the first time period compared to the second time period is based on the percentage of computing resources required by the first robotic process automation robot to perform the first task at the first time period and the second time period.

[0084] 11. A computer-implemented method for intelligent orchestration of a digital workforce, the method comprising:

[0085] Receive the first task;

[0086] performing, via a first robotic process automation robot, actions to perform the first task;

[0087] managing, via orchestration hardware, the first robotic process automation robot to perform the action based on an application prediction model and a task prediction model to perform the first task;

[0088] determining an overdue performance of computing resources associated with the first task at a first time period compared to a second time period; and

[0089] Future tasks to be added to the task queuing system within a period of time are determined.

[0090] 12. The method according to embodiment 11, further comprising:

[0091] A second robotic process automation robot is activated and deactivated in response to the robotic process automation robot performing an action to perform the first task in response to the first robotic process automation robot.

[0092] 13. The method according to embodiment 11, further comprising:

[0093] The future tasks to be added to the task queuing system are determined based on a history of tasks added to the task queuing system.

[0094] 14. The method according to embodiment 11, further comprising:

[0095] Metadata is generated based on performance metrics of the first robotic process automation robot performing actions to perform the first task.

[0096] 15. The method of embodiment 11, wherein the first task includes a prescribed keystroke schedule associated with a client computing device, the prescribed keystroke schedule to be automated by the first robotic process automation robot.

[0097] 16. The method of embodiment 11, wherein the first task comprises a business metric, the business metric being assigned a numerical value based on a priority.

[0098] 17. The method of embodiment 11, further comprising:

[0099] Receive the second task;

[0100] idling the first robotic process automation robot when the second task is in the task queuing system based on the application prediction model and the task prediction model; and

[0101] Computing resources are saved by idling the first robotic process automation robot.

[0102] 18. The method of embodiment 17, wherein the second task is the only task in the task queuing system.

[0103] 19. The method according to embodiment 11, further comprising:

[0104] An amount of computing resources required to complete all received tasks within the period of time is determined.

[0105] 20. A method according to embodiment 11, wherein the overdue performance of the computing resources associated with the first task at the first time period compared to the second time period is based on the percentage of computing resources required by the first robotic process automation robot to perform the first task at the first time period and the second time period.

Claims

1. A computer-implemented method for intelligent orchestration of a digital workforce, the method comprising: Receive the first task; performing, via a first robotic process automation robot, actions to perform the first task; managing, via orchestration hardware, the first robotic process automation robot to perform the action based on an application prediction model and a task prediction model to perform the first task; determining an expected performance of computing resources associated with the first task at a first time period compared to a second time period; and determining future tasks to be added to the task queuing system over a period of time.

2. The method according to claim 1, further comprising: The second robotic process automation robot is activated and deactivated based on a service level agreement and / or queued tasks.

3. The method according to claim 1, further comprising: The future tasks to be added to the task queuing system are determined based on a history of tasks added to the task queuing system.

4. The method according to claim 1, further comprising: Metadata is generated based on performance metrics of the first robotic process automation robot performing actions to perform the first task.

5. The method according to claim 1, wherein: The first task includes a prescribed keystroke schedule associated with a client computing device, the prescribed keystroke schedule to be automated by the first robotic process automation robot.

6. The method according to claim 1, wherein: The first task includes a business metric that is assigned a value based on a priority level.

7. The method according to claim 1, further comprising: Receive the second task; idling the first robotic process automation robot when the second task is in the task queuing system based on the application prediction model and the task prediction model; as well as Computing resources are saved by idling the first robotic process automation robot.

8. The method according to claim 7, wherein: The second task is the only task in the task queuing system.

9. The method according to claim 4, further comprising: An amount of computing resources required to complete all received tasks within the period of time is determined using previously generated metadata.

10. The method according to claim 1, wherein: The expected performance of computing resources associated with the first task at the first time period compared to the second time period is based on a percentage of computing resources required by the first robotic process automation robot to perform the first task at the first time period and the second time period.

11. The method according to claim 1, further comprising: Determining the amount of time a current number of supplied robotic process automation robots would take to complete each task in the queue and the amount of time predicted by the task prediction model to complete the tasks within the period of time, wherein if the determined amount of time is less than the period of time, reducing the number of supplied robotic process automation robots, and if the determined amount of time is greater than the period of time, increasing the number of supplied robotic process automation robots.

12. The method according to claim 1, further comprising: determining the computing resources required for the Robotic Process Automation Robot to complete the received task; managing the robotic process automation robot for tasks currently in the task queuing system and tasks predicted in the task queuing system; as well as Computing resources are managed to enable and disable robotic process automation robots based on current and predicted future tasks in the task queuing system and robotic process automation robot efficiency.

13. A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any one of claims 1 to 12.

14. A server comprising means for implementing the method according to any one of claims 1 to 12.

15. The server of claim 14, comprising a task queuing system and the first robotic process automation robot.

16. A system comprising the server according to claim 14, a task queuing system and the first robotic process automation robot.

Images