Patent Application
20250103988
Many organizations rely on software to run their business such as enterprise resource planning (ERP) software. ERP helps companies create and track orders, generate and clear invoices, receive payments, interact with a website, and the like. ERP software also offers opportunities to perform process mining on the business process. Process mining is a technique that provides insight about a business process to an organization. In many cases, process mining includes executing algorithms on log data from a runtime environment of the business process to identify trends, patterns, variants and other details of the process and how it unfolds. The result of the processing mining is a graph (i.e., a diagram) that represents events within the process using elements in the diagram. The diagram usually provides the viewer with an understanding of how their own process performs without much insight into how to make it better.
Features and advantages of the example embodiments, and the manner in which the same are accomplished, will become more readily apparent with reference to the following detailed description taken in conjunction with the accompanying drawings.
Throughout the drawings and the detailed description, unless otherwise described, the same drawing reference numerals will be understood to refer to the same elements, features, and structures. The relative size and depiction of these elements may be exaggerated or adjusted for clarity, illustration, and/or convenience.
In the following description, specific details are set forth in order to provide a thorough understanding of the various example embodiments. It should be appreciated that various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the disclosure. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art should understand that embodiments may be practiced without the use of these specific details. In other instances, well-known structures and processes are not shown or described in order not to obscure the description with unnecessary detail. Thus, the present disclosure is not intended to be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features disclosed herein.
Process mining is an analysis method that helps organizations improve the way that they run their business. The result of a process being mined is a graph diagram that visualizes the process. Traditional process mining methods merely provide descriptive analysis of the process within the diagram. If action recommendations are provided at all, they are typically provided based on rules that are hardcoded into the process mining software. To conclude, the process diagram provides little insight into how an organization can make their process better.
Furthermore, a realistic timeline for performing a process mining project is a few months and it requires process mining vendors that are familiar with the software system being mined. The vendors typically build custom dashboards and business logic for mining the process which requires significant manual development work. The result is significant time and costs being consumed. Further, there may be different business logics implemented between different vendors which prevents for a standardization for purposes of benchmarking. Another drawback is that process mining may “mine” the entire state space of the software for that process which, after accounting for customer-specific adaptions of the process, ultimately leads to a custom overview of the entire process. The payoff for the mining project can usually only be realized at this detailed level, which makes it prohibitively expensive to cover many processes.
Furthermore, once a mining project is complete, the data can continue to be monitored, but the data extraction can no longer be modified in an easy manner. As a result, if a mining project requires new or different requirements, a completely new mining project will need to be implemented.
The example embodiments include a software system (also described herein as a host system) that provides a suite of software that can generate a process diagram, such as those traditionally generated from process mining, using document data instead of runtime process data. The system can build a custom process diagram (e.g., graph) with nodes representing events or activities within the process and edges between the nodes representing a flow/execution dependencies among the events. Furthermore, the edges can be annotated with additional attributes of the process such as the average amount of execution time that it takes between two events, etc. However simply generating a custom process diagram still does not provide an owner/developer of the process with an understanding of how other processes in a similar field are performing the process in a different and improved manner.
According to various embodiments, the host system may generate additional insight into a process by externally “benchmarking” the customer's process against best-in-class process versions based on a common reference model. The reference model may be a maximum version of the process (all possible steps) while a customer has a subset of the maximum version. The benchmarking can visually show what steps are different in the process versions executed in other companies that are “external” to the customer thereby allowing the customer's process to be externally benchmarked. In doing so, the customer can visually see and understand how other process versions in the same field/business area are performing the process and what steps they are doing differently. For example, if another entity is performing the same process but with less execution time, the host system may identify which steps are causing the slower executing time in the target process and make suggestion on how to improve these steps. The steps may be extracted from the reference diagram and used to define changes to perform to create a target process.
By benchmarking the target process using data from process versions of other customers (i.e., external benchmarking), the example embodiments can provide helpful insight to process owners, department heads or developers of the software with actions and other process steps that can improve the execution of their own process. No other methodology of this kind exists today.
In the example embodiments, the reference model can be thought of as a complete picture of the process type including all possible known (i.e., defined) steps used by the other processes and the directed edges between these displaying the flow of the process. The host system may generate multiple reference models for different types of processes. The processes may be business processes, sales processes, ordering processes, delivery process, etc. The host system may compare the process diagram of a target process to a reference diagram (of a reference process) and identify changes that can be made to the target process to improve the target process based on the reference diagram. In addition, the host system can visually show these changes within the process diagram of the target process thereby visually showing the owner/developer of the process the changes that can be made to improve the process based on the best-practices of the industry. That is, the host system can provide a process overview as well as recommendations on how to fix/improve the process based on how other entities and organizations are performing the same process in a more efficient manner.
The events or activities that are described herein may refer to milestones or blockers. For example, a business process that involves the sale of goods may include a requirement that a sales order (document) be created which identifies the goods and a requirement that an invoice (document) be generated and cleared. These three actions can be considered milestones. For example, the first milestone may be “creating a sales order”, a second milestone may be “creating an invoice”, and a third milestone may be “clearing the invoice”.
Meanwhile, blockers are occurrences or events that block the process from moving forward and will usually remain in place until the block is removed, if they don't directly terminate the process instance (e.g., the manual cancelation of an order). Referring again to the example of the three milestones above, the process may require that the buyer sign and return the sales order before the invoice can be generated by the system. In this example, failure to receive a signed sales order may be considered a blocker to the process. Until the signed sales order is received, the block will remain in place. Other contextual information reflecting such as unwanted or unintentional behavior (e.g., wrong sequence of process steps) can also be covered in such a definition of a blocker to surface these issues to the people responsible of running the process.
Such standardized milestones and blockers have been and can be identified from years of expertise in the field of process insights and avoid unnecessary mining projects which attempt to mine the entire state space of the process including parts of the process that are unrelated to the ultimate success of the process. While process mining can give you the whole state space including all irrelevant variants, paths and events, the example embodiments focus on identifying the standard blockers typically encountered by most businesses and the paths chosen to remedy these blockers. From a commercial perspective, the customer does not have to decide on one process to understand in depth but can get insights into challenges and blockers in a standardized way across the whole process landscape. The software system may provide pages of user interfaces which enable users to choose or otherwise select a subset of milestones from the predefined/standardized list and a subset of blockers for each milestone from another predefined/standardized list.
The data for identifying the insights can be extracted from process data stored in an underlying data store/database, for example, sales data, sales orders, invoices, payment transactions, account summaries, and the like, which can be used to see how the process is performing. To do this, the host system may query the process data and generate insights according using the systems and methods described in U.S. patent application Ser. No. 18/118,857, filed on Mar. 13, 2023, in the United States Patent and Trademark Office, the entire disclosure of which is fully incorporated herein by reference for all purposes.
In some embodiments, the process insights may be stored in a table or other data structure that can be analyzed by the host system to identify a list of events that occur during the process. Details of the events may be recorded in an event log such as a table or other structure. Furthermore, the host system can insert “virtual” events into the event log which are not found in the raw data but can be inferred from the other events that are found in the event log. The event log may include enough detail to build a process diagram (e.g., a graph) using existing process mining algorithms. The resulting process diagram may include a plurality of nodes that represent the plurality of milestones of the process, and/or other events that occur within the process. The nodes may include edges in-between which illustrate the “flow” of the process between the milestones and/or events. The flow may include directional edges, and annotations on the directional edges which include runtime attributes of the process such as completion percentage between two steps, average execution times, distribution between different succeeding edges and the like.
The host system may analyze the process diagram to provide the customer with intelligence associated with their process. For example, the host system may identify performance attributes of the process over time including what percentage of users reach each milestone, what percentage of users follow different paths within the process diagram, an order among the different steps in the process, and the like. The host system may also compare the performance attributes of the process to performance attributes of other processes that are of similar type. For example, the host system may compare a process diagram of a customer's process to a reference diagram (e.g., a process model) that is generated based on other process implementations of other customers that are of similar type. Here, the host system may overlay the reference diagram on top of the diagram of the target process to visualize the different flows between the two processes. For instance, customers can learn that in their make-to-stock process, process steps which they enforce in sequence are executed in arbitrary order by their industry peers, resulting in a process that, on average, executes 20% quicker. Furthermore, the host system may analyze the flows to identify which steps can be used to improve the target process and recommend suggestions on how to improve the target process based on alternative process steps identified from the reference diagram.
In this example, a user such as a process expert may interact with the software application 122 via a user device 110 such as a laptop computer, a mobile device, a desktop computer, a server, and the like. For example, the user may use the user device 110 to connect to a website, uniform resource locator (URL), or other location where the software application 122 is hosted. In some examples, the software application 122 is a progressive web application, a mobile application, or the like. In some embodiments, the software application 122 is actually a suite of multiple applications. The software application 122 may include a front-end with a user interface 112 that is output on a screen/display of the user device 110 once a session is established between the user device 110 and the host platform 120.
According to various embodiments, the user may select a system where the process data is located from among the data system 126 and the data system 130. In this example, the data system 130 is accessed via an application programming interface (API) such as API 132. The software application 122 may output guidance for the user via the user interface 112 to assist the user in selecting the correct system. A schema of the selected system may be uploaded to the software application 122 via the user interface 112. For example, the user may upload a file, a document, a spreadsheet, or the like which includes the schema information.
The software application 122 may also provide various user interfaces which enable the user to define milestones within the process and blockers for those milestones. The user interfaces may be accessible via a same page of the software application 122 or across multiple different pages of the software application 122. The user may also define a script or other instructions with query commands for querying the data necessary for analyzing the milestones and blocker(s) of the milestone via the user interface. Each blocker may have its own query, for example, a structured query language (SQL) query, or the like. The software application 122 may provide user interfaces and standardized lists of milestones and blockers (e.g., via drop-down menus, etc.) that the user can select from. Furthermore, software application 122 may also provide support and assistance in developing queries for accessing the data from the underlying data system.
When all queries for all blockers have been generated, the software application 122 may create a single script, API call, etc., which can be executed by a query processor 124 on the selected data system to retrieve the data necessary for analyzing each of the blockers via a single command. For example, the software application 122 may generate a structured query language (SQL) query for each of the blockers and then create a single script which extracts a union of all of the fields necessary from the data system. In some embodiments, the data system may also include an API, such as data system 130 which includes an API 132. In this example, the query generated by the software application 122 may include query commands and/or API calls for extracting or pushing the process data from the data system 130.
The generated script, query, etc. may be stored by the software application 122 and accessed by the user via the user device 110 or any other user with access to the process data via the software application 122. Here, the user may provide an identifier of the process (e.g., a process ID, etc.). In response, the software application 122 may query the selected data system based on the previously generated query corresponding to the process ID, and execute one or several analytic queries on the process data to generate insights about the process which can be displayed on the user interface 112. The process insights may include identifiers of milestones (e.g., events, activities, etc.) within the process and any blockers associated with the milestones. In addition, the insights may include context associated with the milestones and blockers such as how many users/customers are affected by the blockers, how many customers/users fail to finish the process, where customers are getting stuck in the process, and the like.
The process data that is pulled/extracted from the data systems 126 and 130 may include values of table data that are queried from tables stored in therein including order data, invoice data, payment data, shipping data, transportation data, inventory data, and the like. Through this data, the software application 122 can analyze the process data to identify insights associated with the process. For example, the software application 122 may identify how long it takes for each milestone to be reached (e.g., the amount of time that elapses between milestones) and the blockers that block these milestones from being achieved. To identify the duration between milestones, the software application 122 may use timestamps of when the process enters the two respective milestones on average and subtract the two.
In addition to identifications of the milestones and blockers of the process, the insights may also include an amount of elapsed time on average between the milestones such as an average amount of execution time between two process events, the number of processes that make it to each milestone (e.g., a percentage, ratio, etc.), the total cost of each process event, how each blocker affects the achievement of milestones within the process, and the like.
In this example, milestone 310 represents a step of generating a sales order, milestone 320 represents a step of generating an invoice based on the sales order, and milestone 330 represents clearing the invoice (based on successful payment). The milestone 310 includes four blockers which are shown below the milestone 310 including a blocker 316 directed to manually released documents. Other blockers including cancellation of documents, not transferring an order to the invoicing department, returning the sales order for errors, and the like. To assist the user in understanding the issues, the host system can display an identifier of the number of blockers 312 within the milestone 310, and also attributes 314 of the milestone 310 inside a content area of the graphical user interface (GUI) object of the milestone 310 on the user interface 300.
In addition to identifying the amount of time and the attributes of the milestones and the blockers, the host system (e.g., software application 122, etc.) may distinguish different graphical objects on the screen. As an example, the host system may highlight an object with a bold line 318 to identify this blocker as something that needs to be addressed more urgently as it is causing a lot of loss within the process. Thus, the system can identify a priority among the different blockers and display visual indicators of such priority or arrange the display of the blockers in an order based on the priority, etc. This priority is based on thresholds the process experts provided based on their experience for what is considered good or bad for the process execution when they defined the blockers.
In some embodiments, each milestone may be associated with a document that is involved in the process such as an order, an invoice, a financial document, or the like. The blockers may refer to actions or other events/items within the process that block or otherwise prevent the milestone (e.g., the document) from being completed in some way such as incorrect content, not yet submitted, submitted and returned, canceled, etc. Furthermore, each of the milestones 310, 320, and 330, may be visualized along with a number of documents generated for each milestone and the percentage or ratio of such documents that compete the milestone. For example, in
The events may include actions that occur within the process including creating a sales order, shipping the item to the customer, receiving payment for the item from the customer, etc. In many cases, the events may correspond to the milestones and/or the blockers already identified. The host system may identify the events within the event log 400 and pair the events with a corresponding timestamp from the record to generate a log entry in the event log 400. In other words, the host system may pair activities identified from the insight data with timestamps found in the insight data to generate an activity definition that can be analyzed for additional process insights. The process may be performed by an executable script creating one event log per standardized milestones definition of the process. Accordingly, the definition of this script generation the event log 400 is a one-time effort. The time it takes the script to complete execution (i.e., create the log) is based on the amount of data to process. Furthermore, state-of-the-art process mining solutions can display first process graphs (i.e., diagrams) within minutes.
For example, the event log 400 can be used to build a process graph of the process. For example, the process graph may be similar in appearance as a process diagram created from process mining. However, in this case, historical data (e.g., document data, etc.) is used to mine the process without interacting with the process.
For example, the host platform described herein (e.g., the software application 122 shown in
Additionally, virtual events can be constructed wherever necessary. For example, a process mining algorithm may identify that after an event such as an invoice being created, the process does not provide any additional activity. In this example, the algorithm may infer a missing event (e.g., sending the invoice to the customer, etc.) based on comparisons of the process to implementations of other customers. In this case, a virtual event can be constructed and added to the process diagram, indicated as “missing”.
The process diagram may be stored within a repository. In some embodiments, a process diagram may be in the format of a Business Process Model and Notation (BPMN) model which is a standard for business process modeling. For example, the BPMN model can provide a graphical notation for specifying business processes in a Business Process Diagram (BPD) based on a flowcharting technique very similar to activity diagrams from Unified Modeling Language (UML). The objective of BPMN is to support business process management, for both technical users and business users, by providing a notation that is intuitive to business users, yet able to represent complex process semantics. The BPMN specification also provides a mapping between the graphics of the notation and the underlying constructs of execution languages, particularly Business Process Execution Language (BPEL).
BPMN models are expressed by simple diagrams constructed from a limited set of graphical elements. For both business users and developers, they simplify understanding of business activities' flow and process. BPMN's four basic element categories are Flow objects (e.g., events, activities, gateways, etc.), connecting objects (e.g., sequence flow, message flow, association, etc.), swim lanes (e.g., pool, lane, dark pool, etc.), and artifacts (e.g., data object, group annotation, etc.). These four categories enable creation of simple business process diagrams (BPDs). BPDs also permit making new types of flow object or artifact, to make the diagram more understandable.
Furthermore, the process diagrams described herein may be processed based on thresholds which are used to ensure the most relevant process variants are exported. For example, a process may include the following events (event A=created, event B=shipped, and event C=paid) which are observed in all permutations. Here simply constructing a graph diagram of such a process would result in a rather trivial graph/diagram which would not lead to insights about how the process is run. However, if the event sequence A, B, C makes up only 5% of the process runs while the event sequence A, C, B makes up 95% of all paths, a diagram showing these two variants is relevant and specific for the process and its owner/developer. His generation ensures traceability via identifiers (e.g., event type references for activities in process models, etc.) This also allows the host system to be used to automatically add live insights (e.g., KPI values) from process insights or other data sources to the corresponding activities in the process models.
When the process diagram has been created, the host system may select a reference diagram of the process and analyze it for additional insights. The reference diagram may be generated in advance and may include a sequence of steps that are best-practices in the industry for that type of process. The reference diagrams can be generated by users, generated by analysis, or the like. Here, the host system may compare the process diagram to the reference diagram to provide additional insight about how to improve the target process shown in the process diagram.
The reference diagram 620 may be supplied by the user (organization) that also submits the process diagram 600. As another example, the reference diagram 620 may be identified by the host platform, such as by searching for the reference diagram 620 using a search interface as described in
According to various embodiments, the system described herein may overlay the reference diagram 620 on top of the process diagram 600 to generate a visualization of steps that can be integrated into the process diagram 600 to help improve the execution of the target process corresponding to the process diagram 600. Furthermore, the system may remove steps to prevent the process from becoming more complicated and thereby simplifying the process. For example,
The overlaying process may integrate pieces of the reference diagram 620 into the process diagram 600. For example, the system may connect an edge 635 between an existing node (E4) of the process diagram 600 and a new node (E6) in the reference diagram 620 as shown in
Here, the software may distinguish the recommended changes (different data flow/steps) on the user interface from the existing flow of the target process using highlighting, bold lines, thicker lines, different colors, shading, and the like. As a result, a viewer can quickly see what changes to make to the target process based on the alternative data flow including the node 636 and the edges 631, 632, 633, 634, 636, and 637 therein.
Based on process performance metrics collected and derived for each different version of the process diagram customers might have implemented, customers can query the system to display the flow(s) associated with the best results when it comes to, e.g., completion rate, overall execution time or least manual effort. Since each customer might have optimized for different performance metrics, the customer can inspect which ones are most promising and easiest to adapt when overhauling their own processes. This, of course, needs to ensure anonymity of customers, e.g., by never displaying individual models but only aggregates of the top N customers for a metric.
According to various embodiments, the software application 662 may manage an index of information about the reference diagrams that are stored in the repository 664. For example, each diagram may have a description associated therewith that describes the type of process and the steps therein. The software application 662 may compare the search terms to these descriptions to identify a reference diagram with a description that most closely matches the search input. As another example, other attributes such as process type, location, etc. may be provided for the search and used to identify the reference diagram.
According to various embodiments, the system described herein may overlay a reference diagram (of a reference process) on the process diagram 500 shown in
In the example of
In 920, the method may include displaying the process diagram via a user interface of a software application. Here, the diagram may be rendered within a window, slot, or other area with a template of the software application. In 930, the method may include selecting a reference diagram of a reference process from a data store, where the reference diagram has a different sequence of nodes corresponding to a different sequence of events than the sequence of events in the diagram. In 940, the method may include identifying an improvement to the process based on the reference diagram. In 950, the method may include modifying the diagram to include a different execution flow included in the reference diagram based on the identified improvement. For example, the method may include overlaying the reference diagram on top of/over the process diagram. In doing so, the differences between the process and the reference process can be visualized.
In some embodiments, generating the diagram may include annotating an edge between two nodes within the diagram corresponding to two different events within the process with an average execution time between the two different events. In some embodiments, the generating may include querying the data store for document data of the process, and identifying the sequence of events that occur within the process and the execution times between the sequence of events based on the document data. In some embodiments, the modifying may include inserting an alternative edge within the diagram between an existing node among the plurality of nodes within the diagram and a new node included in the different execution flow from the reference diagram.
In some embodiments, the selecting the reference diagram may include displaying a search bar via the user interface, receiving an input search term via the search bar displayed on the user interface, querying a plurality of descriptions of a plurality of respective reference diagrams in a storage device based on the search term, and selecting the reference diagram based on the queried plurality of descriptions in comparison to the input search term. In some embodiments, the modifying may include overlaying the reference diagram on top of the process diagram within the user interface, and identifying the improvement within the process diagram based on a comparison of an alternative process flow within the overlaid reference diagram to an existing process flow within the process diagram.
In some embodiments, the modifying may include visually distinguishing the alternative process flow within the overlaid reference diagram from an existing process flow of the process diagram when the reference diagram is overlaid on the process diagram. In some embodiments, the method may further include identifying a variant that occurs in each of the process and the reference process and identifying differences between the occurrences of the variant in each of the process and the reference process, and displaying the differences via the user interface.
The network interface 1010 may transmit and receive data over a network such as the Internet, a private network, a public network, an enterprise network, and the like. The network interface 1010 may be a wireless interface, a wired interface, or a combination thereof. The processor 1020 may include one or more processing devices each including one or more processing cores. In some examples, the processor 1020 is a multicore processor or a plurality of multicore processors. Also, the processor 1020 may be fixed or it may be reconfigurable. The input/output 1030 may include an interface, a port, a cable, a bus, a board, a wire, and the like, for inputting and outputting data to and from the computing system 1000. For example, data may be output to an embedded display of the computing system 1000, an externally connected display, a display connected to the cloud, another device, and the like. The network interface 1010, the input/output 1030, the storage 1040, or a combination thereof, may interact with applications executing on other devices.
The storage 1040 is not limited to a particular storage device and may include any known memory device such as RAM, ROM, hard disk, and the like, and may or may not be included within a database system, a cloud environment, a web server, or the like. The storage 1040 may store software modules or other instructions which can be executed by the processor 1020 to perform the methods described herein. According to various embodiments, the storage 1040 may include a data store having a plurality of tables, records, partitions and sub-partitions. The storage 1040 may be used to store database records, documents, entries, and the like.
According to various embodiments, the storage 1040 may include a data store such as a database that is configured to store document data of a process or multiple processes. Meanwhile, the processor 1020 may be configured to generate a process diagram that includes a sequence of nodes that correspond to a sequence of events that occur within a process and edges between the plurality of nodes which indicate execution times between the plurality events within the process. The processor 1020 may display the process diagram via a user interface of a software application. The processor 1020 may select a reference diagram of the process from a data store, where the reference diagram comprises a different sequence of nodes corresponding to a different sequence of events that occur within the reference process. The processor 1020 may identify an improvement to the process based on the reference diagram. The processor 1040 may modify the process diagram to include a different execution flow included in the reference diagram based on the identified improvement.
As will be appreciated based on the foregoing specification, the above-described examples of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting program, having computer-readable code, may be embodied or provided within one or more non-transitory computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed examples of the disclosure. For example, the non-transitory computer-readable media may be, but is not limited to, a fixed drive, diskette, optical disk, magnetic tape, flash memory, external drive, semiconductor memory such as read-only memory (ROM), random-access memory (RAM), and/or any other non-transitory medium.
The computer programs (also referred to as programs, software, software applications, “apps”, or code) may include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, apparatus, cloud storage, internet of things, and/or device (e.g., magnetic discs, optical disks, memory, programmable logic devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The “machine-readable medium” and “computer-readable medium,” however, do not include transitory signals. The term “machine-readable signal” refers to any signal that may be used to provide machine instructions and/or any other kind of data to a programmable processor.
The above descriptions and illustrations of processes herein should not be considered to imply a fixed order for performing the process steps. Rather, the process steps may be performed in any order that is practicable, including simultaneous performance of at least some steps. Although the disclosure has been described in connection with specific examples, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the disclosure as set forth in the appended claims.
