WO2020201830A1 - Systèmes et procédés pour générer, surveiller et analyser des réseaux d'événements à partir de données d'événements - Google Patents

Systèmes et procédés pour générer, surveiller et analyser des réseaux d'événements à partir de données d'événements Download PDF

Info

Publication number
WO2020201830A1
WO2020201830A1 PCT/IB2020/000248 IB2020000248W WO2020201830A1 WO 2020201830 A1 WO2020201830 A1 WO 2020201830A1 IB 2020000248 W IB2020000248 W IB 2020000248W WO 2020201830 A1 WO2020201830 A1 WO 2020201830A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
node
nodes
events
network
Prior art date
Application number
PCT/IB2020/000248
Other languages
English (en)
Inventor
Massimiliano DELSANTE
Claudiu BACIU
Original Assignee
Cognitive Technologies Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cognitive Technologies Limited filed Critical Cognitive Technologies Limited
Publication of WO2020201830A1 publication Critical patent/WO2020201830A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/26—Visual data mining; Browsing structured data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2477—Temporal data queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management

Definitions

  • a process can be considered to be a set of linked activities or events for delivering a desirable output.
  • Process mining can provide answers to such questions.
  • Process mining utilizes stored activity/event data to discover or identify a process, also sometimes referred to as a process model or event network, that is carried out by the organization, perhaps implicitly or without any explicit description or order. Once discovered, the process can then be analyzed. Said another way, process mining can be used for discovering, monitoring, and improving processes by extracting knowledge from event logs.
  • Event data can come from a variety of different sources, such as a database system, a comma-separated CSV file or spreadsheet, a transaction log, an Enterprise Resource Planning (ERP) system, a message log, an Application Programming Interface (API), etc.
  • Event data can include any kind of information, such as patient data in a hospital, trading information, data from websites or social media, and/or the like.
  • Process mining can allow companies to connect to varied data platforms and integrate with multiple data sources in order to extract and analyze information relating to processes. [0005] Additionally, process mining can allow companies to audit their processes and improve them by answering compliance related and performance related questions. Therefore, potential problems can be detected before they can have a negative impact on the operations of a company.
  • a multi-level process includes one or more complex processes involving steps/events/entities linked by many to many relationships.
  • multi-level processes include P2P (Purchase to Pay) and 02C (Order to Cash) processes.
  • P2P Purchase to Pay
  • 02C Organic Cash
  • a P2P process can be made up of different subprocesses, such as purchasing, ordering, invoicing, and payment. Multiple instances of purchasing can be linked to a single order. In a similar manner, multiple instances of an order may be linked to a single purchase. Therefore, each subprocess has to be analyzed separately in order to provide visibility on the actual end-to-end P2P process.
  • Process mining for multi-level processes should solve the problem of data convergence and the problem of data divergence. More specifically, data divergence can occur when several events of the same type are related to a single case (a case is a sequence of events). Data convergence can occur when one event is related to multiple cases.
  • Existing process mining techniques do not address the challenge of modeling and analyzing multi-level processes.
  • a system for generating an event network from event logs can include a database configured to receive a set of event logs associated with a sequence of n events. Each event can be a different event type than each other event of the sequence of n events. Each event log of the set of event logs can be associated with at least one event of the sequence of n events. Each event log can include a) timestamp information and b) a unique identifier for each event associated therewith.
  • the system can also include a controller communicably coupled to the database and configured to: assign an event identifier to each event log of the set of event logs based on the corresponding timestamp information to generate a set of event identifiers, generate a set of nodes based on the set of event logs and the set of event identifiers, and generate, for each leaf node, a corresponding event network to generate at least two event networks.
  • Each node can be based on each unique combination of the event type and the unique identifier in the set of event logs.
  • Each node can include a listing of the event identifiers of the set of event identifiers associated with its event type and with its unique identifier, the set of nodes can include (i) at least one root node associated with event 1 of the sequence of n events and (ii) at least two leaf nodes associated with event n of the sequence of n events.
  • the controller can be configured to for each leaf node: link the leaf node to one or more nodes corresponding to event n-1 in the sequence of n events, the leaf node and the one or more nodes corresponding to event n-1 having the same event identifier associated therewith, iteratively link each of the one or more nodes corresponding to event n-1 to one or more nodes corresponding to event n-2 having the same event identifier associated therewith until the at least one root node is linked.
  • Each event network can include the leaf node, the at least one root node, and all nodes linked therebetween.
  • the at least two event networks can have at least one node in common.
  • the system can include a display device communicably coupled to the controller and configured to generate a visual representation of the at least two event networks illustrating an area of overlap having the at least one node in common.
  • each event log can be associated with an event other than the event 1 or the event n includes two or more event identifiers.
  • the set of event logs received by the database includes a set of n tables, each table corresponding to a different event of the set of n events, the set of n tables being referentially constrained with respect to each other.
  • the controller is configured to sort the set of event logs into a single table in chronological order based on the referential constraints between the set of n tables prior to assigning the set of event identifiers.
  • each event log can further include a relationship attribute representing a link between that event and at least one other event in the sequence of n events.
  • the relationship attribute is an event identifier of the at least another event.
  • linking each node in the set of nodes to another node in the set of nodes visually can include rendering at least one of an incoming transition to that node from the other node or an outgoing transition from that node to the other node.
  • the number of event networks for the set of event logs is equal to the number of nodes in the set of nodes without outgoing transitions.
  • the controller can be further configured to generate a first event network of the at least two event networks by starting from a first leaf node of the at least two leaf nodes and traversing all nodes linked therebetween until the at least one root node.
  • the controller can be further configured to assign an event identifier with a Boolean value, the event identifier being associated with an event occurring in both the event networks of the at least two event networks.
  • the database can further include frequency information for each event of the sequence of n events and associated with the at least two event networks.
  • the controller can be further configured to, for a first event network of the at least two event networks: determine frequency information for each event in the first event network based on the frequency information associated with the at least two event networks, and generate a frequency analysis model for the first event network, the frequency analysis model including a visual representation of the frequency information for each event in the first event network.
  • the controller can be further configured to: determine a cost associated with each event in the first event network based at least in part on the frequency information associated with the at least two event networks, and generate a cost analysis model of the first event network, the cost analysis model including a visual representation of the cost associated with each event in the first event network.
  • the database can further include average throughput time for each event in the sequence of n events and associated with the at least two event networks.
  • the controller can be further configured to, for a first event network of the at least two event networks: generate a performance analysis model for the first event network, the performance analysis model including a visual representation of the average throughput time for each event in the first event network.
  • the database can further include information related to automation for each event of the sequence of n events and associated with the at least two event networks.
  • the controller can be further configured to for a first event network of the at least two event networks: determine an automation level for each event in the first event network based on the automation associated with that event, and generate a rework analysis model for the first event network, the rework analysis model including a visual representation of the automation level for each event in the first event network.
  • a method for generating an event network from event logs can include receiving a set of event logs associated with a sequence of n events. Each event can be a different event type than each other event of the sequence of n events. Each event log can be associated with at least one event of the sequence of n events. Each event log can include a) timestamp information and b) a unique identifier for each event associated therewith. The method can also include assigning an event identifier to each event log of the set of event log based on its corresponding timestamp information to generate a set of event identifiers.
  • the method can also include generating a set of nodes based on the set of event log and the set of event identifiers. Each node can be based on each unique combination of the event type and unique identifier in the set of event log. Each node can include a listing of the event identifiers of the set of event identifiers associated with that node’s event type and unique identifier.
  • the set of nodes can include (i) at least one root node associated with event 1 of the sequence of n events and (ii) at least two leaf nodes associated with event n of the sequence of n events.
  • the method can also include identifying, for each leaf node, a corresponding event network to identify at least two event networks, including for each leaf node: linking the leaf node to one or more nodes corresponding to event n-1 in the sequence of n events, the leaf node and the one or more nodes corresponding to event n-1 having the same event identifier associated therewith, iteratively linking each of the one or more nodes corresponding to event n-1 to one or more nodes corresponding to event n-2 having the same event identifier associated therewith until the at least one root node is reached.
  • Each event network can include the leaf node, the at least one root node, and all nodes linked therebetween.
  • the at least two event networks have at least one node in common.
  • the method can also include generating a visual representation of the at least two event networks illustrating an area of overlap having the at least one node in common.
  • each event log can be associated with an event other than the event 1 or the event n includes two or more event identifiers.
  • the set of event logs can include a set of n tables, each table corresponding to a different event of the set of n events, the set of n tables being referentially constrained with respect to each other.
  • the method can further include prior to the assigning, sorting the set of event logs into a single table in chronological order based on the referential constraints between the set of n tables.
  • each event log can further include a relationship attribute representing a link between that event and at least one other event in the sequence of n events.
  • the relationship attribute is a respective event identifier of the at least another event.
  • linking each node in the set of nodes to another node in the set of nodes visually can include rendering at least one of an incoming transition to that node from the other node or an outgoing transition from that node to the other node.
  • the number of event networks for the set of event logs is equal to the number of nodes in the set of nodes without outgoing transitions.
  • the method generating a first event network of the at least two event networks further includes starting from a first leaf node of the at least two leaf nodes and traversing all nodes linked therebetween until the at least one root node.
  • the method can further include for a first event network of the at least two event networks: determining frequency information of each event in the first event network based on frequency information associated with the at least two event networks, the event log including frequency information for each event of the sequence of n events and associated with the at least two event networks, and generating a frequency analysis model for the first event network.
  • the frequency analysis model can include a visual representation of the frequency information for each event in the first event network.
  • the method can further include determining a cost associated with each event in the first event network based at least in part on the frequency information associated with the at least two event networks, and generating a cost analysis model of the first event network, the cost analysis model including a visual representation of the cost associated with each event in the first event network.
  • the method can further include for a first event network of the at least two event networks: generating a performance analysis model for the first event network.
  • the performance analysis model can include a visual representation of an average throughput time for each event in the first event network.
  • a non-transitory computer readable medium for generating an event network from event logs is disclosed herein.
  • the non-transitory computer readable medium can be executed on a computing device encoded with instructions that, when executed, causes a processor to: receive a set of event logs associated with a sequence of n events, each event being of a different event type than each other event of the sequence of n events, each event log associated with at least one event of the sequence of n events, each event log including a) timestamp information and b) a unique identifier for each event associated therewith; assign an event identifier to each event log of the set of event logs based on its corresponding timestamp information to generate a set of event identifiers; generate a set of nodes based on the set of event logs and the set of event identifiers, each node based on each unique combination of the event type and unique identifier in the set of event log, each node including a listing of the event identifiers of the set of event identifiers associated with that node’s event type and unique identifier, the set of nodes including at least one
  • the instructions can also include instructions that when executed causes the processor to: identify, for each leaf node, a corresponding event network to identify at least two event networks, including for each leaf node: link the leaf node to one or more nodes corresponding to event n-1 in the sequence of n events, the leaf node and the one or more nodes corresponding to event n-1 having the same event identifier associated therewith; iteratively link each of the one or more nodes corresponding to event n-1 to one or more nodes corresponding to event n-2 having the same event identifier associated therewith until the at least one root node is reached.
  • Each event network can include the leaf node, the at least one root node, and all nodes linked therebetween.
  • the at least two event networks have at least one node in common.
  • the instructions can also include instructions that when executed causes the processor to generate a visual representation of the at least two event networks illustrating an area of overlap having the at least one node in common.
  • each event log can be associated with an event other than the event 1 or the event n includes two or more event identifiers.
  • the set of event log can include a set of n tables, each table corresponding to a different event of the set of n events, the set of n tables being referentially constrained with respect to each other.
  • the instructions can further causes the processor to: prior to the assigning, sort the set of event logs into a single table in chronological order based on the referential constraints between the set of n tables.
  • FIG. 1 illustrates an example P2P process.
  • FIG. 2 illustrates the many to many relationships of entities/events involved in a P2P process.
  • FIG. 3 illustrates the relationships among entity instances that could be stored in a schema disclosed herein.
  • FIG. 4 illustrates data divergence in an event network discovered by traditional methods for discovering event networks.
  • FIG. 5 illustrates data convergence in an event network discovered by traditional methods for discovering event networks.
  • FIG. 6 illustrates an example event network identified and/or generated by the systems and methods described herein.
  • FIG. 7 illustrates a method for identifying and generating event networks from event data.
  • FIG. 8 illustrates identification of nodes and relationships in a multi-level process using the systems and methods described herein.
  • FIG. 9 illustrates example event network generated using the systems and methods described herein.
  • FIG. 10A illustrates a first part of an example frequency model obtained by applying the systems and methods described herein on a P2P process for an automotive company.
  • FIG. 10B illustrates a second part of the example frequency model obtained by applying the systems and methods described herein on a P2P process for an automotive company.
  • FIG. 11 A illustrates a first part of an example performance model obtained by applying the systems and methods described herein on a P2P process for an automotive company.
  • FIG. 1 IB illustrates a second part of the example performance model obtained by applying the systems and methods described herein on a P2P process for an automotive company.
  • FIG. 12A illustrates a first part of an example cost model obtained by applying the systems and methods described herein on a P2P process for an automotive company.
  • FIG. 12B illustrates a second part of the example cost model obtained by applying the systems and methods described herein on a P2P process for an automotive company.
  • FIG. 13 A illustrates a first part of an example process model (rework model) obtained by applying the systems and methods described herein on a P2P process for an automotive company.
  • FIG. 13B illustrates a second part of the example process model (rework model) obtained by applying the systems and methods described herein on a P2P process for an automotive company.
  • FIG. 14 illustrates an example automotive P2P process in order to show the advantages offered by systems and methods.
  • FIG. 15A illustrates a frequency view model derived for the case in FIG. 14 using the systems and methods.
  • FIG. 15B illustrates a cost view model derived for the case in FIG. 14 using the systems and methods.
  • FIG. 15C illustrates a rework and automation model derived for the case in FIG. 14 using the systems and methods.
  • FIG. 16 illustrates event networks derived for the case in FIG. 14 using a traditional approach by selecting invoice as the process identifier.
  • FIG. 17 illustrates event networks derived for the case in FIG. 14 using a traditional approach by selecting purchase order as the process identifier.
  • FIGS. 18A illustrates a first part of an event network generated by a simulation engine described herein to simulate ulti-level processes for an industrial automotive P2P process.
  • FIG. 18B illustrates a second part of the event network generated by a simulation engine described herein to simulate multi-level processes for an industrial automotive P2P process.
  • FIG. 19 illustrates details of an invoice registered event in an example simulated model.
  • FIG. 20 illustrates an example simulated process and the relationships between the entities.
  • FIG. 21 A illustrates a first event network for the simulated case.
  • FIG. 2 IB illustrates a second event network for the simulated case.
  • FIG. 21C illustrates a third event network for the simulated case.
  • Event networks are derived from event data that includes information about events.
  • An event can represent any suitable activity (e.g., messaging), transaction (e.g., a trade), and/or other data (e.g., patient data) in a system that processes data electronically.
  • All events that are to be assigned to a transaction e.g., a business transaction
  • a case can be a trace (i.e., a sequence of events).
  • Each case can be identified by its individual case identifier (case ID)
  • the case ID is a representation of a case. It is unique to every case and can serve to uniquely identify the case.
  • Case ID can be alphanumeric, i .e., it can include a combination of letters and numbers.
  • Each event can have an associated case ID, a time stamp, and other attributes.
  • the time stamps can correspond to logged start and end time of the event.
  • Events are listed together with their attributes in an event log. Attributes include the case ID, the time stamps, and other attributes of the event (e.g., relationship attributes that represent a reiation/iink between two or more events, etc.) recorded by the system.
  • An event log can represent one or more cases of a process.
  • a process can be considered to be a set of linked activities or events, aimed to deliver a desirable output.
  • a process instance can identify an instance of a process that corresponds to the lifecycle of a single entity.
  • a process instance identifier can refer to the instance of the entity.
  • Process mining is the visualization and analysis of processes on the basis of event logs using algorithms and mathematical procedures. Put differently, process mining provides a set of tools and/or techniques that has the potential to utilize stored activity/event data to discover process models, also referred to as event networks, for subsequent analysis. Event logs can be created by data preparation from available process data/initial raw data in order to enable process mining.
  • Process mining can enable discovery, conformance checking, and improvement of processes by linking event logs with process models/event networks.
  • the resulting event networks can represent real world process flow based on actual event data, rather than on assumptions or tacit knowledge.
  • Event networks can configure and improve software systems that model and support real world process flows.
  • An unresolved technological problem with process mining includes modeling of multi level processes.
  • a multi-level process includes one or more complex processes involving events linked by many-to-many relationships. Examples of such processes in a real-world setting are the P2P (Purchase to Pay) process and the 02C (Order to Cash) process.
  • Standard process mining approaches do not address the problems of data convergence and data divergence.
  • Data divergence can occur when several events of the same type are related to a single case, i.e., a single trace of events from beginning to end.
  • Data convergence can occur when one event is related to multiple cases.
  • Event networks generated for multi-level process models using standard process mining approaches often introduce new self-loops that are incorrect (data divergence problem). This increases the complexity and ambiguity of analyzing the processes using these generated event networks. Additionally, in some cases, the generated event networks erroneously duplicate events (data convergence problem). This can bias the analysis of processes using these generated event networks.
  • Process mining techniques should be able to organize and sort such vast quantities of event data, and then use the organized data to accurately generate the complex event networks that give rise to them. Furthermore, these techniques should be able to provide valuable insights based on the data while simultaneously addressing the data divergence and data convergence problems for multi-level processes.
  • FIG. 1 illustrates the structure of an example P2P process 102 solely for purposes of explanation using an everyday scenario, where the starting event is the creation of a Purchase Request 104 and the end event is the issuance of the Purchase Invoice 110.
  • the P2P process 102 includes the events process request 104, process order 106, goods receipt 108, and purchase invoice 110.
  • FIG. 2 illustrates the many-to-many relationships (represented by asterixes (*) in FIG. 2) of entities involved in a P2P process.
  • purchase request 204 is followed by the event purchase order 206.
  • two instances of the event purchase request 204 can be associated with three different instances of the event purchase order 206.
  • two purchase requests can be invoked and sent by a company to three different vendors, thereby linking two instances of the event purchase request 204 with three instances of purchase order 206.
  • Purchase order 206 is followed by good receipt 208 and then by purchase invoice 210.
  • ERP Enterprise Resource Planning
  • SAP® Systems, Applications, and Products
  • JD Edwards ⁇ Oracle® Infor, etc.
  • SAP® Systems, Applications, and Products
  • JD Edwards ⁇ Oracle® Infor, etc.
  • table 1 represents purchase request 104 in FIG. 1 and/or purchase request 204 in FIG. 2.
  • the recorded event in this case is the request creation.
  • Table 2 represents purchase order 106 in FIG. 1 and/or purchase order 206 in FIG. 2.
  • the recorded event it this case the order creation.
  • Table 3 represents goods receipt 108 in FIG. 1 and/or goods receipt 208 in FIG. 2.
  • the recorded event is the registration of goods receipt.
  • Table 4 represents purchase invoice 110 in FIG. 1 and/or purchase invoice 110 in FIG. 2.
  • the recorded event is the registration of the invoice sent by the supplier.
  • Each row in every table represents an instance of that event type.
  • each row in the table represents an instance of the recorded event associated with that table.
  • every row in table 1 represents an instance of the event type purchase request 104 in FIG. 1 and/or purchase request 204 in FIG. 2. Therefore, every time a request creation is recorded, table 1 can store an ID associated with the request creation (i.e., PR ID), a row number associated with the request creation (i.e., PR ROW), and a timestamp associated with the request creation.
  • PR ID an ID associated with the request creation
  • PR ROW row number associated with the request creation
  • timestamp associated with the request creation.
  • purchase request 104 is followed by the event purchase order 106. Therefore, purchase order 106 is linked to the purchase request 104.
  • This information can be captured in the tables.
  • the tables can also include information to represent an association with different entity types.
  • the columns PR ID and PR ROW link an instance of purchase order to a specific instance of purchase request by linking table 2 back to table 1.
  • table 2 can store an ID associated with the order creation (i.e., PO ID), a row number associated with the order creation (i.e., PO ROW), and a timestamp associated with the order creation.
  • the table 2 also links that order creation to its corresponding request creation via PR ROW and PR ID. Therefore, an instance of the purchase order 106 can be linked back to an instance of the purchase request 104.
  • purchase order 106 is followed by goods receipt 108 linking goods receipt 108 to purchase order 106.
  • This information can be captured by the columns PO ID and PO ROW in table 3, that links the corresponding instances of goods receipt back to an instance of purchase order in table 2.
  • Goods receipt 108 is followed by purchase invoice 110 linking goods receipt 108 to purchase invoice 110.
  • This information can be captured by the columns GR ID and GR ROW in table 3, that links the corresponding instances of purchase invoice in table 4 back to the corresponding instances of goods receipt in table 3.
  • FIG. 3 illustrates a graphical view of the relationships among entity instances that could be stored in a schema as shown in the example above. That is, consider an example of entity instances stored in table 1, table 2, table 3, and table 4. A graphical view of the relationships among these entity instances is illustrated in FIG. 3.
  • purchase request 304a is associated with one instance of purchase order (stored in table 2).
  • Purchase request 304a is linked to PO 42580 (represented as 306a in FIG. 3).
  • Purchase request 304b is linked to two instances of purchase order (stored in table 2).
  • Purchase request 304b is linked to PO 42580 (represented as 306a in FIG. 3) and PO 42761 (represented as 306b in FIG. 3).
  • Purchase order 306a is associated with two instances of goods receipt (stored in table 3).
  • Purchase order 306a is linked to GR 90017 (represented as 308a in FIG. 3) and GR 89705 (represented as 308b in FIG. 3).
  • Purchase order 306b is associated with one instance of goods receipt (stored in table 3).
  • Purchase order 306b is linked to GR 89158 (represented as 308c in FIG. 3) ⁇
  • Goods receipt 308a is associated with one instance of purchase invoice (stored in table 4).
  • Goods receipt 308a is linked to PI 32688 (represented as 310a in FIG.3).
  • Goods receipt 308b is also associated with one instance of purchase invoice (stored in table 4).
  • Goods receipt 308b is linked to PI 32688 (represented as 310a in FIG.3).
  • Goods receipt 308c associated with another instance of purchase invoice (stored in table 4).
  • Goods receipt 308c is linked to PI 32079 (represented as 310b in FIG. 3).
  • Table 1, table 2, table 3, and table 4, as well as FIG. 1, FIG. 2, and FIG. 3 illustrate an example of a complex multi-level P2P process.
  • process mining should solve the problem of data convergence and the problem of data divergence, described in greater detail below.
  • one event is related to multiple cases, i.e., is part of multiple traces.
  • several events of the same type are related to a single case.
  • the problems of data convergence and data divergence can complicate case identification and should be solved in order to avoid the generation of biased statistics.
  • the purchase order 306a (order ID 42580) has two Goods Receipt events GR1 (with GR ID 90017 represented as 308a in FIG. 3) and GR2 (with GR ID 89158 represented as 308c in FIG. 3) and two Invoice Registration events PI1 (with PI ID 32688 represented as 310a in FIG. 3) and PI2 (with PI ID 32079 represented as 310b in FIG. 3).
  • FIG. 4 illustrates a process model 400 obtained by using traditional process mining using this trace.
  • two goods receipts 408 refer to different invoices 410, both of which are related to the purchase order 404, but are not related to each other.
  • the self-loops (self-loop 414a and self-loop 414b) on Goods Receipt 408 and Invoice Registration 410 are misleading because they indicate a rework on the same activity.
  • Rework indicates repeated activity. For instance, it indicates repeated activity of invoice registration 410 by changing minor details after the event has been already created. When an invoice is not registered right for the first time, the activity might need to be repeated again. This complexity and ambiguity of the process model increases when more good receipts and invoices are linked to the case, as the divergence problem introduces new loops.
  • the receipt event of the invoice with PI ID 32688 represented as 310a in FIG. 3, which is related to two different purchase orders (e.g., the purchase order 306a in FIG. 3 (i.e., purchase order with order ID 42580), and purchase order 306b in FIG. 3 (i.e., purchase order with order ID 42761)) is considered twice.
  • FIG. 5 illustrates a process model 500 obtained by using traditional process mining techniques using this trace.
  • the event invoice receipt PI1 i.e., invoice receipt 510
  • invoice receipt 510 is considered to be two different events. This data convergence problem can lead to extracting duplicate events and biased statistics.
  • invoice i.e., the case is identified by the case ID of the entity invoice receipt
  • the many-to- many relation between the invoices and purchase orders causes the resulting event log to still suffer from divergence and convergence.
  • invoice would duplicate the events related to the purchase order.
  • goods receipts i.e., the case is identified by the case ID of the entity goods receipt
  • purchase order POl is considered as an event for GR1 and GR2.
  • ERP systems store a large number of entities related to a process, and the relational structure allows each entity to have its own lifecycle which may or may not be related to other entities.
  • a single lifecycle of the entities offers a partial view of the business process can have multiple partial views, e.g. the P2P process can be seen from the point of view of the Order, of, but cannot describe by itself the way the organization is working.
  • Multi-level Process Mining Solution provides one or more technological improvements over existing process mining methodologies.
  • the multi-level process solution described herein begins with rethinking the concept of a case for a multi-level process. Using this solution, the case can be dynamically identified by discovering the correlation among the entities.
  • the entities can be mapped in the event log according to their mutual relationships. Therefore, it is possible to build their correlation/link the entities while parsing the event log.
  • FIG. 1, FIG. 2, and FIG. 3 (and table 1 -table 4) of the P2P process - events, that is, purchase request (purchase request 104 in FIG. 1 and/or purchase request 204 in FIG. 2), purchase order (purchase order 106 in FIG. 1 and/or purchase order 206 in FIG. 2), goods receipt (goods receipt 108 in FIG. 1 and/or goods receipt 208 in FIG. 2), and purchase invoice (purchase invoice 110 in FIG. 1 and/or purchase invoice 210 in FIG. 2) can be mapped and analyzed.
  • the mapping is as follow: 1) purchase request; 2) purchase order; 3) goods receipt; and 4) purchase invoice.
  • the mapping order corresponds to the natural sequence of the entities: a) a purchase request is created before the corresponding order; b) a purchase order is created after the corresponding request and before the goods receipt; c) a goods receipt is registered after the corresponding order and before the purchase invoice; and d) a purchase invoice is registered after the good receipt.
  • the purchase request is the root entity/event because it does not receive any incoming event from other entities.
  • the purchase invoice is the leaf entity/event because it does not generate any event on other entities.
  • the events recorded in the above event log are identified as belonging to the same case. Based on the entity mapping, the case is detected as the set of events involving the correlated entities.
  • the discovery phase e.g., the process of generating and/or discovering the event network
  • the multi-level process solution described herein takes into account that a single event can belong to one or more cases. Therefore, such events are considered just one time to avoid data divergence and data convergence.
  • the set of events belonging to the same process is normalized. Put differently, if the same event ID is present more than once it is reported just once, in order to obtain the right multiplicity between subprocesses, so that throughput time, resource allocation and cost allocation are correctly calculated.
  • FIG. 6 illustrates a process model for the above example generated using the multi level process mining solution described herein.
  • process variants of a multi-level process can be detected as unique sequences of different transitions.
  • process variants of a multi-level process can identify a unique event flow in the multi-level process.
  • FIG. 6 there are two unique transitions from request creation 604 to order creation 606, from order creation 606 to goods receipt 608, and from goods receipt 608 to invoice receipt 610 indicating two variants for the process starting from root entity with PR ID 10080 to the leaf entity with PI ID 32688.
  • the two process variants are: 1) purchase request 304b - purchase order 306a - goods receipt 308b - purchase invoice 310a; and 2) purchase request 304b - purchase order 306b - goods receipt 308a - purchase invoice 310.
  • the ulti-level process can be properly modeled and statistics (e.g., costs analysis, frequency analysis, time analysis, etc.) are not biased. Moreover, a user can see and analyze the multi-level process in a manner similar to a process with one-to-one relationships without extra effort. Therefore, an innovative aspect is the capability to present in a single event network several derived processes.
  • An example system for implementing the multi-level process solution can include a computing device.
  • computing device include mobile devices and smart phones (e.g., Apple iPhone®, Samsung Galaxy®, Google Pixel®, etc.), computers (e.g., desktops, personal computers, laptops etc.), and/or tablets and e-readers (e.g., Apple iPad®, Samsung Galaxy® Tab, Microsoft Surface®, Amazon Kindle®, etc.).
  • the computing device can include a processor (also referred to herein as a “controller”).
  • a processor can be a central processing unit (CPU).
  • CPU central processing unit
  • One form of processor is referred to as a microprocessor.
  • CPUs use communicative circuits to pass binary encoded signals acting as instructions to enable various operations. These instructions may be operational and/or data instructions containing and/or referencing other instructions and data in various processor accessible and operable areas of memory (e.g., registers, cache memory, random access memory, etc.).
  • Such communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations.
  • These stored instruction codes, e.g., programs may engage the CPU circuit components and other motherboard and/or system components to perform desired operations.
  • the processor can be communicatively coupled to a database.
  • the computing device includes the database.
  • the database can be stored in a memory (e.g., (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Blueray, CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.); an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable storage mediums; and/or other devices of the like) associated with the computing device.
  • the database can be stored on a cloud platform (e.g., Microsoft Azure®, Amazon® web services, IBM® cloud computing, etc.).
  • the processor and the database can be communicatively coupled to a display device.
  • the computing device can include a display interface which acts as the display device.
  • a display device separate from the computing device can be communicatively coupled to the processor.
  • the database can be configured to store event data associated with a process.
  • event data can be in the form of one or more tables.
  • event data can be event logs of a process.
  • an event log can include a sequence of events with each event being of a different event type than the other events.
  • the event log can include information such as a timestamp, a case ID, a name attribute that indicates the activity, and a relationship attribute that indicates the relationship between one or more events.
  • the case ID is a unique identifier for each event.
  • every other row in the event log can include two or more (two in the example shown in table 7) case IDs for each entry indicating that the events are linked together.
  • the event log can be a set of tables with each table corresponding to a different event.
  • the set of tables can be referentially constrained with respect to each other.
  • the controller communicably coupled to the database can use the event data to generate a process model for the multi-level process.
  • FIG. 7 illustrates a method 800 for implementing the multi-level process solution.
  • the following assumptions can be made by the method 800: 1) the events in the event data (e.g., event logs) need not be presented, provided, and other otherwise made available in any particular order (chronological or other); and 2) there can be a finite list of possible event types an event can belong to (e.g., “Request Creation”,“Order Creation”,“Invoice Receipt”).
  • the method 800 can be implemented by a controller.
  • the event data e.g., event logs
  • the method 800 can sort the event data into a single table in chronological order based on the referential constraints between the tables.
  • the sorted table illustrates the relationship between different entity types. Therefore, after sorting the data into a single table, the table can include for each entry - the event type, the timestamp, and one or more event identifiers. For instance, for an entry relating to a purchase request, the entry can include a PR ID, purchase request as event type, and the timestamp relating to that particular purchase request. In a similar manner, for an entry relating to a purchase order, the entry can include a PO ID, purchase order as the event type, the timestamp relating to that purchase order, and a PR ID that linking that purchase order entry to a specific purchase request.
  • a controller can assign a case ID and/or an event identifier to each entry of the event log.
  • the case IDs can be assigned based on timestamp information associated with each entry.
  • the method 800 can generate a set of nodes based on the event logs and the event identifiers of each entry of the event logs. More specifically, the method 800 can identify combinations of event type and the event identifiers. Each unique combination can be associated with a node. For example, a unique combination of a PR ID and purchase request type would generate a node.
  • the set of nodes can include at least one root node that is associated with a root entity and at least one leaf node that is associated with a leaf entity.
  • the method 800 can generate a process model and/or an event network for each leaf node.
  • the method 800 begins with a leaf node.
  • the method 800 then links the leaf node to one or more nodes that have the same event identifier as the leaf node. For instance, consider a leaf node of event type purchase invoice with an event identifier PI 1.
  • an entry of goods receipt includes an event identifier GR 1, a timestamp associated with that entry, and the event identifier PI 1 linking the purchase invoice PI 1 to the goods receipt GR 1.
  • a node of the event type goods receipt with event identifier GR 1 is generated for this entry.
  • the method 800 can link the leaf node to the node with the event identifier GR 1.
  • the method 800 can iteratively link each of the nodes starting from the leaf node to other nodes that the particular node shares an event identifier with, until the root node is reached. For instance, the method 800 can start from a node of the type purchase invoice. The method 800 can link this node to a node of the type goods receipt provided both these nodes share a common event identifier. The method 800 can then link the node of the type goods receipt to a node of the type purchase order provided both these nodes share a common event identifier. The method 800 can then link the node of the type purchase order to a node of the type purchase request provided both these nodes share a common event identifier. If the node of the type purchase request is a root node, the iterative process can end here.
  • a process model and/or an event network is this link of nodes that includes at least one leaf node, at least one root node, and all the nodes that are linked therebetween.
  • an event network can be generated by starting from a leaf node and traversing all nodes linked therebetween until a root node.
  • two or more process models can have one or more nodes in common.
  • the process models can be displayed on a display device.
  • Data preparation of event logs can include extracting and transforming source data by an Extract, Transform, Load (ETL) procedure to generate an event log that can be imported into a system that performs process mining.
  • ETL Extract, Transform, Load
  • the data preparation process is greatly simplified because the solution can recognize the correlated entities, and therefore the correlated sub-processes, directly from the relational tables.
  • the event log of a multi-level process can be automatically obtained through the composition of the event logs of each single processes, according to the relational tables and the multiplicity of the relationships.
  • the traces can be extracted for the four flat processes.
  • the denormalization (same event type repeated in the log of the flat process) can be directly obtained by the foreign keys of the relational model.
  • the traces are shown below:
  • the solution described herein i.e., method 800 in FIG. 8 can automatically sort the rows in chronological order and use the relationships to identify the subprocesses in a transparent way.
  • the solution does not require any explicit action on the user’s part to map the business entities and their relationships.
  • the solution produces the resulting trace of the multi-level process as illustrated below.
  • the table 12 includes entities each having its own lifecycle while participating in one or more variants of the multi-level process.
  • the term“process instance” refers to identifying the lifecycle of each instance of a process.
  • the above example therefore includes: a) 2 Purchase Request process instance -> Process Identifiers: 10070, 10080; b) 2 Purchase Order process instances - Process Identifiers: 42580, 42761; c) 3 Goods Receipt process instances - Process Identifiers: 89158, 89705, 90017; and d) 2 Purchase Invoice process instances -> Process Identifiers: 32079, 32688.
  • the relationship model between process instances can be generated in an iterative manner from the chronologically-sorted events.
  • FIG. 8 illustrates the identification of nodes and relationships for the above example using the methods 800 in FIG. 7.
  • the nodes can be identified as a pair of event type and their respective process instance identifier.
  • node 904a is identified as a combination of the event type“request creation” and process instance identifier“10070”, which is a unique combination.
  • node 904b is identified as a combination of the event type“request creation” and process instance identifier“10080.”
  • Node 906a is identified as a combination of the event type“order creation” and process instance identifier“42580.”
  • Node 906b is identified as a combination of the event type“order creation” and process instance identifier“42761.”
  • the relations of the process model can be generated whenever an event can be assigned to multiple process instances (e.g., has multiple process identifiers). More specifically, when a node associated with an event type has the same identifier as another node associated with a different event type (both the event types being consecutive events), these nodes can be linked. For example, event with event index 2 from the table 12 has two process identifiers“10070” and “42580.” Therefore, the node 906a associated with the event type“order creation” has two process identifiers“10070” and“42580.” The node 904a associated with the event type“request creation” has event identifier“10070.” This is event with event index 0 in table 12.
  • node 906a can be linked to node 904a since both the nodes have a common event identifier“10070.”
  • node 906a can be linked to node 904b and node 906b can be linked to node 904b.
  • the value assigned to each node can represent the list of event indexes that have been matched to that respective node. For instance, from table 12, process identifier“10070” is associated with event indexes“0” and“2.” Therefore, the values assigned to node 904a include “0” and“2.” In a similar manner, process“10080” is associated with event indexes“1,”“3,” and “4.” Therefore, the values assigned to node 904b include values“1,”“3,” and“4.”
  • FIG. 9 illustrates example process models generated using the solution described herein for the event logs shown in table 8 - table 11.
  • the nodes and relationships can be identified. More specifically, a node is associated with a unique combination of event type and process identifier.
  • An event type can be associated with an entity type. For instance, event type“Request creation” can be associated with entity type “Purchase Request.” In a similar manner, event type“order creation” can be associated with the entity type“Purchase order.”
  • the relationships can be generated by starting from a leaf node and traversing until the root node by linking nodes that are associated with a common identifier. For the example in table 12, starting from the leaf node 1010a until root node 1004a generates the link 1004a - 1006a -> 1008a -> 1010a. In a similar manner, starting from leaf node 1010a until root node 1004b generates the links: a) 1004b -> 1006a -> 1008a -> 1010a; and b) 1004b -> 1006b -> 1008b -> 1010a.
  • leaf node 1010b starting from leaf node 1010b until root node 1004b generates the link 1004b -> 1006b -> 1008c -> 1010b. Therefore, for each of the leaf nodes 1010a and 1010b a respective process model is generated. Put differently, two process models 1000a and 1000b can be generated using the multi-level process solution described herein.
  • the leaf nodes 1010a and 1010b do not have any outgoing relationships. Therefore, the number of generated multi-level process identifiers is equal to the number of nodes without outgoing relationships (e.g., leaf nodes).
  • the operation of assigning a multi-level process identifier to the existing events can be performed by traversing the relationship model, starting from leaf nodes towards all nodes without incoming relationships (e.g., root nodes).
  • each event can be assigned one or more multi-level process identifiers.
  • node 1004b and 1006b can be assigned multi-level process identifier 1000a and 1000b. However, node 1004a is assigned process identifier 1000a while node 1010b is assigned process identifier 1000b.
  • an additional parameter e.g., a Boolean value
  • each node can be used to indicate whether an event is shared by at least two event networks, or not. This can prevent the duplication of the event in a resulting multi-level process model when the nodes are parsed.
  • Boolean values for nodes that are shared by two or more event networks can be“TRUE”,“0”, and/or the like.
  • Boolean values for nodes that belong to a single event network can e“FALSE”,“1”, and/or the like. Then, nodes have the Boolean value“TRUE” are identified as shared nodes and are included once in the resulting process model. For instance, with reference to FIG.
  • a Boolean value of“TRUE” can be assigned to the event request creation 1004b with identifier 10080 in order to prevent duplication, while a Boolean value of“FALSE” can be assigned to the event goods receipt 1008c with identifier 89158. Therefore, as discussed above, event networks and/or process models can be generated for multi-level processes in a simple manner overcoming the data convergence and the data divergence problems.
  • the multi-level process mining solution described herein can be applied to several industrial processes. Using the multi-level process mining solution, a process can be analyzed along its entire lifecycle by discovering correct relationships between the different events/entities involved.
  • FIGS. 10A and 10B are an illustration of a frequency view of an industrial automotive P2P process.
  • FIGS. 10A and 10B illustrate an example process model obtained by applying the multi-level process mining solution described herein on a P2P process for an automotive company.
  • boxes represent activities.
  • the boxes can have different color borders with each color identifying an entity type that the activity belongs to.
  • the links between the boxes are transitions (e.g., transition 1102a, transition 1102b, transition 1102c, etc.) between the activities.
  • FIGS. 10A and 10B illustrate a process model generated using the multi-level process mining solution described herein (e.g., method 800 in FIG. 7).
  • the number next to the transitions in FIGS. 10A and 10B indicate the number of times that specific transition has occurred. For instance, in this example, transition 1102b has occurred 19675 times. The number within every box indicates the number of times that specific activity has occurred. For example, 19884 inside box 1104a indicates that the number of times the activity requisition created has occurred.
  • transition 1102b has frequencies that are greater than some outgoing transitions e.g., transition 1102c. This is likely because some activities can be carried out in parallel and/or because of reworks.
  • transition 1 102g the number in the bracket represents the number of times this transition is executed in parallel with another activity in the same process instance. For instance, transition 1102g is executed in parallel with another activity 10 times in the same process instance.
  • the circle icon at the bottom right corner of the nodes indicate model coverage.
  • circle 1106c is a full circle indicating that the model covers all relationships of the activity“order item created.” Put differently, all the incoming and outgoing relationships of this activity are displayed in the model. Circle 1106g and 1106i are partially full circles indicating that the model provides only partial coverage. That is, not all incoming and outgoing relationships of the activities“order changed: payment terms,” and“order changed: delivery dates” are displayed in the model.
  • Model coverage represents the level of detail associated with the visualization of the process model. If a user chooses 100% level of coverage for activities and 100% level of coverage for transitions, all the boxes will display full coverage. Put differently, the detail level (i.e., model coverage) can hide certain details in the displayed process model (i.e, if the user chooses partial coverage and not 100% coverage).
  • boxes can have a background color that visually represents the frequencies of an activity. For instance, a darker background color may indicate that the corresponding activity is more frequent.
  • the outlines of the boxes can have different colors that indicate an entity to which the activity is referring to.
  • FIGS. 11A and 11B is an illustration of a time performance view of an industrial automotive P2P process.
  • FIGS. 11A and 11B illustrate an example process model obtained by applying the multi-level process mining solution described herein on a P2P process for an automotive company.
  • the numbers next to the transitions represent the average waiting t time for the transitions.
  • transition 1202b has an average waiting time of 4 days and 12 hours.
  • the number within the boxes e.g., 0ms within box 1204a
  • the average time to execute the activity e.g., activity “requisition created”.
  • the number within the boxes are 0 because the corresponding event log includes only a column with start timestamp and does not include the end timestamp.
  • the average execution time is embedded in the waiting time.
  • the number 1210a represents the average and the maximum waiting request for the activity“requisition created.”
  • the first number“37.3” represents the average waiting request and the second number“59” represents the maximum waiting request for the activity“requisition created.”
  • the number 1208a represents the average and the maximum waiting time for the activity “requisition created.”
  • the first number“9 Id 23h” represents the average waiting time and the second number“255d lOh” represents the maximum waiting time for the activity“requisition created.”
  • the number 1212a represents the average and the maximum resource location for the activity“requisition created.”
  • the number“18.5” represents the average resource location and the number“39” represents the maximum resource location.
  • FIGS. 12A and 12B is an illustration of a cost view of an industrial automotive P2P process.
  • FIGS. 12A and 12B illustrate an example process model obtained by applying the multi level process mining solution described herein on a P2P process for an automotive company.
  • the model in FIGS. 12A and 12B shows the average cost associated with an activity. For instance, the average cost of the activity“requisition created” is7. The frequency of this activity is 19,884. Therefore, the average cost associated with all execution of this activity is 139, 188 which is also represented in the model. As seen in FIGS. 12A and 12B, since costs are associated with activities, the costs are shown inside the boxes and are not represented by the transitions.
  • FIGS. 13A and 13B is an illustration of a rework and automation view of an industrial automotive P2P process.
  • FIGS. 13A and 13B illustrate an example process model obtained by applying the multi-level process mining solution described herein on a P2P process for an automotive company.
  • an event log can include a column to indicate whether an activity is performed manually or is automated.
  • the process model in FIGS. 13A and 13B uses this information to show the automation level of each activity. For instance, the automation level of “requisition released” is 0% indicating that this activity is performed manually. However, the automation level of“order item created” is 34% indicating that this activity is automated by 34%.
  • FIG. 14 To understand the advantages offered by multi-level process mining solution compared to traditional mining approaches consider a process shown in FIG. 14. As seen in FIG. 14, five purchase order lines (e.g., purchase order 1506a-1506e) can be generated by five purchase requisition lines (e.g., purchase requisition 1504a-1504e) in five separate goods receipt (e.g., goods receipt 1508a-1508e). All of these order lines are registered in a unique invoice 1510.
  • purchase order lines e.g., purchase order 1506a-1506e
  • five purchase requisition lines e.g., purchase requisition 1504a-1504e
  • goods receipt e.g., goods receipt 1508a-1508e
  • FIGS. 15 A, 15B, and 15C illustrate the process model derived for the case in FIG. 14 using the multilevel process mining solution.
  • FIGS. 15 A, 15B, and 15C illustrate the relationships between entities are preserved.
  • FIGS. 15 A, 15B, and 15C illustrate the frequency view model 1600a, the cost view model 1600b, and the rework and automation view model 1600c respectively.
  • the process flow is linear until“invoice registered” 1616a, 1616b, and/or 1616c.
  • Five goods receipt e.g., represented as 1614a, 1614b, and 1614c
  • a unique invoice i.e., invoice 1510 in FIG. 14).
  • frequency view model 1600a this relationship is preserved on the transition between 1614a and 1616a.
  • this relation is preserved in the activity goods registered 1614a as frequency times cost (5 times 7). The invoice activity is triggered only once thereby making the invoicing less expensive. No reworks occur within this case.
  • FIG. 16 illustrates the frequency view model 1700a and the rework and automation model 1700b when invoice is selected as the process identifier.
  • FIG. 16 illustrates the frequency view model 1700a and the rework and automation model 1700b when invoice is selected as the process identifier.
  • non-existing self-loops can occur along the frequency view model 1700a using the traditional process mining approach. This happens because each activity before the Invoice Registration (1716a and 1716b) is performed five times. However, from the Invoice perspective (1 unique case) this results in a repetition making the process model inconsistent.
  • FIG. 17 illustrates the frequency view model 1800a and cost model 1800b when purchase order is selected as the process identifier.
  • process model 1800a the frequencies of invoice registered 1816a and invoice cleared 1818a are incorrect.
  • the frequency of the activities 1816a and 1818a is shown as five, even if in reality, all the order lines are registered to a single invoice. This happens because, from the perspective of purchase order, five order lines are invoiced. Therefore, the process model recognizes five invoice registrations and five clearing activities.
  • This inconsistency can lead to costs related to invoicing activities being strongly biased because of frequency errors. In this case, the costs are five times higher than the real cost because the costs of activities associated with invoicing can contribute five times to the total cost instead of contributing just once.
  • the systems and methods described herein can perform various types of what-if analysis on a multi level process.
  • the system for implementing the multi-process solution can include a simulation engine to perform what-if analysis on multi-level processes.
  • the multi-level process solution described herein can include the functionalities of the simulation engine (as described below) to generate process events starting from multi-level process models that are discovered by the multi-level process solution.
  • the controller in the system for implementing the multi process solution can include instructions to execute functionalities of the simulation engine that are described herein.
  • the simulation engine can generate simulated scenarios with multi-level process properties.
  • simulation scenarios can be generated from process models derived from the multi-level process mining solution described herein. Therefore, the simulation data can be automatically set according to the real process.
  • Some example data retrieved from the discovered models and used by the simulation engine include: a) historical case arrival distribution wherein the simulation follows the same case arrival distribution as real process; b) relationships and correlations between different entities; c) activity execution time and waiting time; d) resource allocation; and e) execution flow probabilities.
  • a user and/or a company may want to analyze a specific scenario in a multi-level process. For example, analyzing the effect of automating a specific event or activity in a multi-level process can offer a deep understanding about the impact that activity has on the multi-level process. For instance, the cost of the entire process may be reduced by 50% by automating that specific event.
  • the simulation engine can enable the analysis of such what-if scenarios. Additionally, the simulation engine can generate contextual data with the right distribution and correlation. Contextual data are optional columns provided in the rows of the event log that are mapped as event attributes in the discovered process, to enable a multi-dimensional data analysis.
  • contextual attributes for event types relating to purchase order can include - order material, order quantity, order currency, order category, order purchase group, order purchase organization, order supplier, order supplier country, order supplier city, etc.
  • Some contextual attributes can be correlated. For instance, an order supplier country that is Italy will include an order supplier city that is a city in Italy. The simulation engine can replicate the distribution of contextual data preserving their correlations.
  • a user can decide the what-if scenario and the corresponding event network can be generated.
  • An analysis of the corresponding frequency model, cost model, performance model, and/or the rework model can provide an impact that scenario has on the process itself.
  • the simulation engine can perform what-if analysis in which the“invoice registered” activity can be automated by 80%. In some implementation, automation of 80% can be equivalent to five minutes of robotic execution time.
  • FIGS. 18A and 18B illustrate a process model (frequency view) generated by the simulation engine for the industrial automotive P2P process.
  • the process model generated by the simulation engine reflects a workflow of the discovered process.
  • the automation of 80% to the“invoice registered” by the simulation engine can result in performance and cost improvement of the process.
  • FIG. 19 illustrates the invoice registered in an example simulated model.
  • 2012a represents the automation level of 80% in this example.
  • 2010b represents the waiting time (e.g., 6 days 3 hours/ 69 days 3 hours) after the simulation.
  • 2008b represents the resource allocation after the simulation.
  • FIG. 20 illustrates an example simulated case and the relationships between the entities.
  • two purchase order lines 2106a and 2106b are generated by two purchase requisition lines 2104a and 2104b and received in two separate good receipts 2108a and 2108b.
  • the purchase order lines are registered in a unique invoice 2110.
  • FIGS. 21A, 21B, and 21C illustrate the process models for the simulated case.
  • FIGS. 21 A, 21B, and 21C include the frequency view 2200a, cost view 2200b, and rework 2200c.
  • the simulated case contains improvements (improvements expected by the what-if analysis) to the original process.
  • the rework model 2200c shows that the“invoice registered” 2216c activity can be completely automated and performed by a robot. Therefore, as seen in the cost model 2200b, the cost associated with“invoice registered” 2216b is lower since no human resources are spent on this activity.
  • inventive embodiments are presented by way of example only and that, within the scope of the appended claims and equivalents thereto, inventive embodiments may be practiced otherwise than as specifically described and claimed.
  • inventive embodiments of the present disclosure are directed to each individual feature, system, article, material, kit, and/or method described herein.
  • inventive concepts may be embodied as one or more methods, of which an example has been provided.
  • the acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.
  • a reference to“A and/or B”, when used in conjunction with open-ended language such as“comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.
  • “or” should be understood to have the same meaning as“and/or” as defined above.
  • “or” or“and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as“only one of’ or“exactly one of,” or, when used in the claims,“consisting of,” will refer to the inclusion of exactly one element of a number or list of elements.
  • the term“or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e.“one or the other but not both”) when preceded by terms of exclusivity, such as“either,”“one of,”“only one of,” or“exactly one of.”“Consisting essentially of,” when used in the claims, shall have its ordinary meaning as used in the field of patent law.
  • the phrase“at least one,” in reference to a list of one or more elements should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements.
  • “at least one of A and B” can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Data Mining & Analysis (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Probability & Statistics with Applications (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne des systèmes et des procédés pour générer un réseau d'événements multi-niveau cohérent à partir de données d'événements représentant un processus complexe constitué de nombreux sous-processus, chacun impliquant diverses entités. Des données d'événements peuvent comprendre différents types d'événements, une estampille temporelle et un identificateur associé à chaque événement. Les données d'événements peuvent être triées sous la forme d'un tableau unique. Un ensemble de nœuds peut être généré sur la base d'une combinaison unique du type d'événement et de l'identificateur associé à chaque événement. Les nœuds peuvent comprendre au moins un nœud racine qui est associé à une entité racine et au moins un nœud feuille qui est associé à une entité feuille. À partir d'un nœud feuille, des nœuds qui sont associés à un identificateur commun peuvent être reliés de manière itérative jusqu'au nœud racine. Un ou plusieurs réseaux d'événements peuvent être identifiés sur la base des liens et relations entre les nœuds.
PCT/IB2020/000248 2019-04-05 2020-04-06 Systèmes et procédés pour générer, surveiller et analyser des réseaux d'événements à partir de données d'événements WO2020201830A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962829875P 2019-04-05 2019-04-05
US62/829,875 2019-04-05

Publications (1)

Publication Number Publication Date
WO2020201830A1 true WO2020201830A1 (fr) 2020-10-08

Family

ID=70861513

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2020/000248 WO2020201830A1 (fr) 2019-04-05 2020-04-06 Systèmes et procédés pour générer, surveiller et analyser des réseaux d'événements à partir de données d'événements

Country Status (1)

Country Link
WO (1) WO2020201830A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230196240A1 (en) * 2021-12-21 2023-06-22 Servicenow, Inc. Multi-Dimensional Process Mining and Analysis
US20240111780A1 (en) * 2022-10-03 2024-04-04 Ey Global Delivery Services India Llp Enterprise resource planning database extraction, transformation, and analysis

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170213167A1 (en) * 2016-01-26 2017-07-27 Celonis Gmbh Method for providing business process analyses

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170213167A1 (en) * 2016-01-26 2017-07-27 Celonis Gmbh Method for providing business process analyses

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230196240A1 (en) * 2021-12-21 2023-06-22 Servicenow, Inc. Multi-Dimensional Process Mining and Analysis
US20240111780A1 (en) * 2022-10-03 2024-04-04 Ey Global Delivery Services India Llp Enterprise resource planning database extraction, transformation, and analysis

Similar Documents

Publication Publication Date Title
US7574379B2 (en) Method and system of using artifacts to identify elements of a component business model
US10339038B1 (en) Method and system for generating production data pattern driven test data
Claes et al. Merging event logs for process mining: A rule based merging method and rule suggestion algorithm
US20140115012A1 (en) Data model optimization using multi-level entity dependencies
US8839198B2 (en) Automated analysis of composite applications
US9223847B2 (en) Using dimension substitutions in OLAP cubes
CN104572122A (zh) 一种软件应用数据的生成装置及方法
WO2007078814A2 (fr) Appareil et procede destines a la validation et a la visualisation de schemas strategiques
US20140310034A1 (en) Performance indicator analytical framework
US9235633B2 (en) Processing data in a data warehouse
US10672016B1 (en) Pathing and attribution in marketing analytics
Ali et al. A framework to implement data cleaning in enterprise data warehouse for robust data quality
US7653452B2 (en) Methods and computer systems for reducing runtimes in material requirements planning
EP3553714A1 (fr) Génération de produits livrables de projet utilisant des objets d'un modèle de données
US20130144880A1 (en) Business partner grouping
WO2020201830A1 (fr) Systèmes et procédés pour générer, surveiller et analyser des réseaux d'événements à partir de données d'événements
Passlick et al. Self-service business intelligence and analytics application scenarios: A taxonomy for differentiation
CN114443779A (zh) 一种基于数据目录的数据资源管理方法及系统
US10691663B2 (en) Database table copy
US11347796B2 (en) Eliminating many-to-many joins between database tables
CN112508119A (zh) 特征挖掘组合方法、装置、设备及计算机可读存储介质
US20130166892A1 (en) Generating a runtime framework
Tan et al. Finding similar time series in sales transaction data
US20140149186A1 (en) Method and system of using artifacts to identify elements of a component business model
US10949410B2 (en) Multi-threaded data analytics

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20728813

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20728813

Country of ref document: EP

Kind code of ref document: A1