Edge table representation of the process

Abstract

A system and method are provided for representing process execution in an edge table. Process execution data for a process including a plurality of activities is received. An edge table representing the execution of the process is generated based on the process execution data. Each row in the edge table identifies a transition from a source event to a destination event.

Description

[Technical field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Patent Application No. 16 / 728,686, filed December 27, 2019, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0002] The present invention relates generally to process mining, and more specifically to representing process execution in edge tables for process mining. [Background technology]

[0003] Process mining involves analyzing processes to identify trends, patterns, and other process analysis measures in order to improve efficiency and better understand the processes. Traditional process mining involves applying data mining algorithms to event logs, which record events that represent activities performed, timestamps, and case identifiers. Event logs are typically stored as tables, where each row (or record) in the table is associated with a single event. Thus, metrics or other representations may be easily computed for events based on the event logs. However, because event logs do not reflect the transitions from source events to destination events in a process, metrics cannot be easily computed for transitions from event logs. Summary of the Invention

[0004] According to one or more embodiments, a system and method are provided for representing the execution of a process with an edge table. The process may be a robotic process automation process.

[0005] Process execution data is received for a process that includes a plurality of activities. An edge table that represents the execution of the process is generated based on the process execution data. Each row in the edge table identifies a transition from a source event to a destination event.

[0006] In one embodiment, a process graph that hierarchically represents the execution of a process may be generated based on the edge table.

[0007] In one embodiment, one or more metrics are calculated based on the edge table. The one or more metrics may be associated with a transition from a source event to a destination event and / or with the destination event.

[0008] In one embodiment, the process execution data includes an event log of the process, and the edge table is generated by sorting the event log based on a case identifier and a timestamp and adding rows to the edge table based on the sorted event log.

[0009] These and other advantages of the present invention will become apparent to those skilled in the art from the following detailed description and accompanying drawings. [Brief description of the drawings]

[0010] [Figure 1A] 1 illustrates an exemplary process for document processing.

[0011] [Figure 1B] 1 illustrates an exemplary process for invoice processing.

[0012] [Diagram 2] 1 illustrates a method for generating an edge table representing an execution of a process according to one embodiment of the present invention.

[0013] [Diagram 3] 1 illustrates an exemplary edge table, according to one embodiment of the present invention.

[0014] [Figure 4] 1 illustrates a process graph that hierarchically represents a record of the execution of a process, according to an embodiment of the present invention.

[0015] [Diagram 5] 1 is a block diagram of a computing system according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] (Detailed Description) Process mining involves the analysis of processes to identify trends, patterns, and other process analysis tools. According to an embodiment of the present invention, process mining may be performed based on an edge table that represents the execution of a process. Each row of the edge table identifies a transition from a source event to a destination event of the execution of the process. Thus, metrics related to the transitions and / or destination events may be calculated from the edge table. One example of a process is shown in FIG. 1A as process 100 for document processing, which may be implemented as a robotic process automation RPA process. Another example of a process is shown in FIG. 1B as process 150 for invoice processing, which may be implemented as a business workflow.

[0017] Process 100 is shown in FIG. 1A as an RPA workflow for automated document processing performed using an RPA robot. However, it should be understood that process 100 may be any suitable process that can be modeled as a workflow, such as, for example, a business workflow. Process 100 includes activities 102-126. As shown in FIG. 1A, process 100 is modeled as a directed graph in which each activity 102-126 is represented as a node and each transition between activities is represented as an edge connecting the nodes. The transitions between activities represent the execution of process 100 from a source activity to a destination activity.

[0018] Process 100 begins at start activity 102 and proceeds to activity 104 where the email is classified. At activity 106, the classification is evaluated. If the email is classified as a claim at activity 106, process 100 proceeds to extract the claim at activity 108 and receive user input to approve the claim at activity 110. The business system is updated with the approval of the claim at activity 112. If the email is classified as an invoice at activity 106, process 100 proceeds to extract the invoice at activity 114 and evaluate the trustworthiness of the extracted invoice at activity 416. If the confidence is low at activity 116, user input is received to verify the invoice data at activity 118 and user input is received to verify the invoice at activities 120 and 122. If the confidence is high at activity 116, process 100 proceeds directly to activity 124 where user input is received to approve the invoice. The business system is updated with the approved invoice at activity 112. The process 100 ends at the end activity 126 .

[0019] 1B as a business workflow. Process 150 is modeled as a directed graph that includes activities 152-172, with each activity 152-172 represented as a node and each transition between activities represented as an edge connecting the nodes. A transition between activities represents the execution of process 150 from a source activity to a destination activity.

[0020] Process 150 begins at start activity 152 and proceeds to activity 154 where the invoice is received. Process 150 either proceeds to activity 156 to pay the employee and proceeds to end activity 172 to end the process 150, or proceeds to activity 158 to review the received invoice. The invoice will either be approved at activity 160, or process 150 will proceed to either request data at activity 162 and check the terms and conditions at activity 164, or proceed directly to activity 166 to perform a final check of the invoice and approve the invoice at activity 168. The invoice is paid at activity 170 and process 150 ends at end activity 172.

[0021] Conventionally, when a process (e.g., process 100 or 150) is executed, an event log is generated. The event log is typically formatted as a table with rows and columns. Each row (or record) in the event log is associated with an event representing the performed activity, a timestamp, a case identifier (ID), and possibly additional information, which are identified in the respective columns. Although such conventional event logs allow for the calculation of metrics for each event, such conventional event logs do not reflect transitions between events, and therefore metrics cannot be easily calculated for such transitions, especially for processes that include parallelism, such as those shown with respect to activities 108 and 114 of process 100 in FIG. 1A. Metrics for parallel events cannot be easily calculated using an event table and are difficult to use in accompanying business intelligence (BI) charts, such as (e.g., bar graphs).

[0022] An embodiment of the present invention generates an edge table that represents the execution of a process (e.g., process 100 or 150), where each row of the edge table is associated with a transition between events. Thus, each row of the edge table may represent a record of a transition from a source event to a destination event and a record of the destination event. Advantageously, an edge table according to an embodiment of the present invention facilitates the calculation of a metric (or other representation) related to the transition and / or the destination event, such that a single metric can be used to evaluate the transitions and events. Furthermore, an edge table according to an embodiment of the present invention may be important in cases where an event log is not generated (even though it is available).

[0023] 2 illustrates a method 200 for generating an edge table representing an execution of a process, according to one or more embodiments. The method 200 may be performed by any suitable computing device, such as the computer 500 of FIG.

[0024] At step 202, process execution data is received for a process including a first activity and a second activity. In one embodiment, the process execution data may be an event log of the execution of the process. However, it should be understood that the process execution data may include any data representative of the execution of the process, such as, for example, a process model or the output of a conformance checking algorithm.

[0025] At step 204, an edge table representing the execution of the process is generated based on the process execution data. Each row in the edge table identifies a transition from a source event to a destination event. To generate the edge table, attributes of the source event and the destination event are defined from the process execution data for each transition.

[0026] In one embodiment, for example, if the process execution data is an event log of the execution of a process, an edge table may be generated by first sorting all events in the event log based on their case ID, and then sorting each event with the same case ID by timestamp (oldest to newest). Then, for each respective event in the event log, the following steps are performed sequentially in one pass on the sorted event log. First, for the sorted event log, if there is no previous event with the same case ID as the respective event, a new row is added to the edge table with a null event as the source event and the respective event as the destination event. This allows the first event of a case to be listed as the destination event. Next, for the sorted event log, if there is a previous event with the same case ID as the respective event, a new row is added to the edge table with the immediately preceding event as the source event and the respective event as the destination event. With each new row added to the edge table, an event ID is assigned to each event, and additional attributes may be added to the events in the event log using the event ID, such that each row in the edge table includes attributes of a source event and a destination event.

[0027] In one embodiment, for example, if the process execution data is a business process model and notation (BPMN) process model, the edge table may be generated by storing each edge in the process model as a single transition between its source activity and its destination activity. The edge table may optionally include columns that identify the model node types of the nodes associated with the source activity and the destination activity. The model node type represents the semantics of the node and may be one of the following: Activity, And Gateway, Xor Gateway, Start, or End. Other node types are also possible. The node type is determined from the mining algorithm or direct input. Storing the model node types in the edge table allows the node types to be reused uniformly in process graphs and BI charts.

[0028] FIG. 3 illustrates an exemplary edge table 300, according to one or more embodiments. The edge table 300 may be generated in step 204 of FIG. 2. The edge table 300 of FIG. 3 represents an execution of the process 100, which will be described with reference to FIG. 1A. The edge table 300 includes columns 302 and rows 304. Each row 304 of the edge table 300 identifies a transition from a source event to a destination event. Each column 302 in the edge table 300 is associated with fields that identify various attributes of the source event and the destination event for each row 304. For example, column 302-A identifies a source activity, column 302-B identifies a destination activity, column 302-C identifies a timestamp of the source activity, column 302-D identifies a timestamp of the destination activity, and column 302-E identifies a case ID. The edge table 300 may include additional columns 302 that identify additional attributes, such as, for example, a name or a service level agreement.

[0029] As shown in FIG. 3, row 302-A identifies a null source activity in column 302-A, identifies start activity 102 as the destination activity in column 302-B, identifies a null timestamp as the source activity timestamp in column 302-C, identifies a timestamp of 13:03:29 as the destination activity timestamp in column 302-D, and identifies a case identifier of 1 in column 302-E. Row 302-A identifies a transition from a null event to a start event so that metrics can be calculated for the start event. Row 304-B ​​identifies start activity 102 as the source activity in column 302-A, classifies email activity 104 as the destination activity in column 302-B, identifies a timestamp of 13:03:29 as the source activity timestamp in column 302-C, identifies a timestamp of 13:05:11 as the destination activity timestamp in column 302-D, and identifies a case identifier of 1 in column 302-E. The remaining transitions between the events are similarly specified in edge table 300. A null activity is illustratively shown in Figure 3, although other implementations are possible. As shown in edge table 300, the ordering of activities 102-126 is implicitly provided by the transition relationships in each row 304.

[0030] In step 206 of FIG. 2, one or more metrics are calculated based on the edge table. The metrics may be associated with transitions from source events to destination events and / or may be associated with the destination events. The metrics may include any suitable metrics. In one example, the metrics may include a number of events calculated as a number of rows or records in the edge table. In another example, the metrics may include a number of cases calculated as a number of unique case IDs identified in the edge table. In another example, the metrics may include a percentage of cases calculated as a percentage of the number of unique case IDs identified in the edge table to the total number of case IDs. In another example, the metrics may include an average throughput time calculated as an average of the throughput times of all activities. Other metrics may be calculated based on the edge table. The metrics may be used for visualization of exception handling, parallel processing, multi-instance graphs, conformance checks, custom key performance indicators, or any other application. In some embodiments, the calculated metrics may be stored as attributes in the edge table.

[0031] The edge table and / or the one or more calculated metrics are output at step 208. For example, the edge table and / or the calculated metrics may be output by displaying the edge table and / or the calculated metrics on a display device of the computer system, storing the edge table and / or the calculated metrics in memory or storage of the computer system, or transmitting the edge table and / or the calculated metrics to a remote computer system.

[0032] Advantageously, edge tables according to embodiments of the present invention allow for the definition of a single metric for both destination events and transitions from source events to destination events using a single table. As an example, edge tables allow for the calculation of metrics on transitions in cases of parallelism where there is no particular order between activities (i.e., activities can be performed in any order). Event logs are sequential and cannot capture the notion of parallelism.

[0033] In one embodiment, to facilitate the computation of metrics, a process graph may be generated based on the edge tables to hierarchically represent records of the execution of the process of method 200. Figure 4 illustrates an example process graph 400 that hierarchically represents records of the execution of a process, according to one or more embodiments. Each node in process graph 400 includes a set of records that identify transitions from source events to destination events.

[0034] The process graph 400 facilitates the computation of metrics at a root level 402, a destination activity level 404, a source activity level 406, and a record level 408. The root level 402 includes a root node that contains all records. Metrics across the entire process may be computed at the root node. The destination activity level 404 includes nodes, each associated with a unique destination activity. Each node in the destination activity level 404 includes all records of its associated destination activity. Metrics at a destination activity may be computed at the nodes of the destination activity level 404. The source activity level 406 includes nodes, each associated with a unique combination of a source activity and a destination activity. Each node in the source activity level 406 includes all records from its parent node that have the same source activity. Thus, each node in the source activity level 406 includes all records of its associated source activity and destination activity. Metrics for transitions from source activities to destination activities may be computed at the nodes of the source activity level 406. The record level 408 represents the individual records of an edge table. Although the metrics may be calculated at the recording level 408, the metrics will be calculated for each individual transition.

[0035] The process graph 400 may be generated using an edge table to define source / destination relationships between events. In particular, the process graph 400 may be generated from the edge table by placing each row (or record) of the edge table on its associated node (i.e., the root node, destination activity level nodes with the same destination activity, and source activity level nodes with the same source and destination activity).

[0036] Metrics may be calculated using the process graph 400. For example, graph metrics may be calculated for the entire process from the root level 402, activity metrics may be calculated at the destination activity level 404, and / or metrics for transitions may be calculated at the source activity level 406. Each node in the process graph 400 may have access to its parent node and its child nodes. Thus, for example, properties of all records with the same destination activity as the edge may be used when calculating metrics for a transition. For example, a case proportion metric returns the proportion of cases across a particular transition by calculating the number of unique case IDs determined from the nodes at the source activity level 406 divided by the total number of unique case IDs for the entire process determined from the root node at the root level 402, and converting the result to a proportion.

[0037] In one embodiment, transitions between events in an edge table can be directly represented in a BI chart. Edge tables can be filtered or expanded so that the resulting edge tables can be displayed directly as process graphs and / or BI charts. Edge tables can behave as regular tables in a BI system, so that all BI features, such as filtering, selection, calculating metrics, joining to other tables, adding new (derived) attributes, etc., are available on transitions in the edge table.

[0038] Various embodiments of the invention are now described. In one embodiment, the edge table may be used to check the compatibility of another event log. The compatibility model may be generated or imported, for example, from a BPMN model. In one embodiment, the edge table may be used to add activities and transitions that are not part of the event log, for example, to add missing parts of a process or to add common start and / or end activities.

[0039] In one embodiment, the edge table may be used as a cache to speed up process calculations. In one embodiment, the edge table may be combined with an event log. In one embodiment, the edge table contains all the information of the event log.

[0040] In one embodiment, the edge table may directly represent parallelism, e.g., mined from event logs using process mining algorithms or directly encoded in the input data. Parallelism information is also directly utilized in BI charts. By explicitly encoding parallelism, metrics that properly account for parallelism can be calculated. In traditional process mining, parallelism is often ignored.

[0041] In one embodiment, the edge table has one row per transition, representing the model. In one embodiment, the edge table has one row per event, representing all transitions in the event log.

[0042] FIG. 5 is a block diagram illustrating a computing system 500 configured to perform the method described with reference to FIG. 2, according to an embodiment of the present invention. In some embodiments, the computing system 500 may be one or more computing systems illustrated and / or described herein. The computing system 500 includes a bus 502 or other communication mechanism for communicating information and a processor(s) 504 coupled to the bus 502 for processing information. The processor(s) 504 may be any type of general-purpose or application-specific processor, including a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a graphics processing unit (GPU), multiple instances thereof, and / or any combination thereof. The processor(s) 504 may also have multiple processing cores, at least some of which may be configured to perform specific functions. In some embodiments, multiple parallel processing may be used.

[0043] The computing system 500 further includes a memory 506 that stores information and instructions executed by the processor(s) 504. The memory 506 may be comprised of random access memory (RAM), read-only memory (ROM), flash memory, cache, static storage devices such as magnetic or optical disks, or other types of non-transitory computer-readable media, or any combination thereof. The non-transitory computer-readable media may be any available media accessible by the processor(s) 504 and may include volatile media, non-volatile media, or both. Additionally, the media may be removable, non-removable, or both.

[0044] Additionally, the computing system 500 includes a communications device 508, such as a transceiver, to provide access to communications networks via wireless and / or wired connections in accordance with currently existing or future implemented communications standards and / or protocols.

[0045] The processor(s) 504 are further coupled via bus 502 to a display 510 suitable for displaying information to a user. The display 510 may also be configured as a touch display and / or any suitable tactile I / O device.

[0046] A keyboard 512 and cursor control device 514, such as a computer mouse, touchpad, and the like, are further coupled to the bus 502 to allow a user to interface with the computing system. However, in certain embodiments, a physical keyboard and mouse may not be present and the user may interact with the device solely through the display 510 and / or touchpad (not shown). Any input device type and combination may be used as a matter of design choice. In certain embodiments, no physical input devices and / or displays are present. For example, a user may interact with computing system 500 remotely via another computing system in communication with computing system 500, or computing system 500 may operate autonomously.

[0047] The memory 506 stores software modules that provide functionality when executed by the processor(s) 504. The modules include an operating system 516 for the computing system 500 and one or more additional functionality modules 518 configured to perform all or a portion of the processes described herein, or derivatives thereof.

[0048] Those skilled in the art will appreciate that the "system" may be embodied as a server, an embedded computing system, a personal computer, a console, a personal digital assistant (PDA), a mobile phone, a tablet computing device, a quantum computing system, or any other suitable computing device or combination of devices without departing from the scope of the present invention. Presenting the functions described above as being performed by a "system" is not intended to limit the scope of the present invention in any way, but rather to provide an example of many embodiments of the present invention. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in a localized and distributed manner consistent with computing technologies, including cloud computing systems.

[0049] It should be noted that some of the system features described herein are presented as modules to better emphasize implementation independence. For example, the modules may be implemented as hardware circuits including custom Very Large Scale Integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Also, the modules may be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, and the like. The modules may also be implemented at least in part in software for execution by various types of processors. For example, an identified unit of executable code may include one or more physical or logical blocks of computer instructions that may be organized as, for example, an object, a procedure, or a function. Nevertheless, the executable identified modules need not be physically located together, but may include separate instructions stored in different locations that, when logically combined, comprise the modules and accomplish the purpose stated for the modules. Furthermore, the modules may be stored on a computer readable medium such as, for example, a hard disk drive, a flash device, a RAM, a tape, and / or any other non-transitory computer readable medium used to store data without departing from the scope of the present invention. Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed across several different code segments, different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within a module, and may be embodied and organized in any suitable form within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed in different locations across different storage devices, or may simply exist at least in part as electronic signals on a system or network.

[0050] The above merely illustrates the principles of the disclosure. Thus, it will be understood that those skilled in the art can devise various arrangements that embody the principles of the disclosure and fall within its spirit and scope, although not explicitly described or shown herein. Furthermore, all examples and conditional language cited herein are intended primarily for educational purposes only to aid the reader in understanding the principles of the disclosure and the concepts that the inventors have contributed to the development of the technology, and should be construed as not being limited to such specifically cited examples and conditions. Furthermore, all descriptions herein that refer to the principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to encompass their structural and functional equivalents. Furthermore, such equivalents are intended to include not only currently known equivalents, but also equivalents developed in the future.

Claims

1. Receiving process execution data for a process including a plurality of activities; generating an edge table representing execution of the process based on the process execution data, each row of the edge table identifying a transition from a source event to a destination event; outputting the edge table; Including, the process execution data includes an event log of the process; generating an edge table representing execution of the process based on the process execution data, Sorting the event log based on a case identifier and a timestamp; adding rows to the edge table based on the sorted event log; 4. A computer-implemented method comprising:

2. calculating one or more metrics based on the edge table; The computer-implemented method of claim 1 , further comprising:

3. Calculating one or more metrics based on the edge table includes: Calculating one or more metrics associated with the transition from the source event to the destination event. The computer-implemented method of claim 2 , comprising:

4. Calculating one or more metrics based on the edge table includes: The computer-implemented method of claim 2 , further comprising calculating one or more metrics associated with the event of interest.

5. generating a process graph based on the edge table, the process graph hierarchically representing the execution of the process; The computer-implemented method of claim 1 , further comprising:

6. The computer-implemented method of claim 1 , wherein the process is a robotic process automation process.

7. a memory for storing computer instructions; at least one processor configured to execute the computer instructions; An apparatus comprising: The computer instructions are configured to cause the at least one processor to perform the following operations: receiving process execution data for a process including a plurality of activities; generating an edge table representing execution of the process based on the process execution data, each row of the edge table identifying a transition from a source event to a destination event; and outputting the edge table; the process execution data includes an event log of the process; generating an edge table representing execution of the process based on the process execution data, Sorting the event log based on a case identifier and a timestamp; and adding rows to the edge table based on the sorted event log.

8. The operation includes: Calculating one or more metrics based on the edge table; The apparatus of claim 7 further comprising:

9. Calculating one or more metrics based on the edge table includes: calculating one or more metrics associated with the transition from the source event to the destination event; 9. The apparatus of claim 8.

10. Calculating one or more metrics based on the edge table includes: The apparatus of claim 8 further comprising: calculating one or more metrics associated with the event of interest.

11. The operation includes: The apparatus of claim 7 , further comprising: generating a process graph based on the edge table, the process graph hierarchically representing the execution of the process.

12. The apparatus of claim 7 , wherein the process is a robotic process automation process.

13. A computer program stored on a non-transitory computer readable medium, the computer program configured to cause at least one processor to perform operations including: receiving process execution data for a process including a plurality of activities; generating an edge table representing execution of the process based on the process execution data, each row of the edge table identifying a transition from a source event to a destination event; and outputting the edge table; the process execution data includes an event log of the process; generating an edge table representing execution of the process based on the process execution data, Sorting the event log based on a case identifier and a timestamp; adding rows to the edge table based on the sorted event log; A computer program comprising:

14. The operation includes: The computer program product of claim 13 , further comprising: calculating one or more metrics based on the edge table.

15. Calculating one or more metrics based on the edge table includes: calculating one or more metrics associated with the transition from the source event to the destination event; 15. A computer program according to claim 14.

16. Calculating one or more metrics based on the edge table includes: calculating one or more metrics associated with the event of interest; 15. A computer program according to claim 14.

17. The operation includes: generating a process graph based on the edge table, the process graph hierarchically representing the execution of the process.

14. A computer program product as claimed in claim 13.

18. The computer program product of claim 13 , wherein the process is a robotic process automation process.

Images