PROCEDURES FOR CORRECTING PROCESS ANOMALIES

Description

Field of the invention

[0001] The invention relates to a method for monitoring process instances that are being executed and for correcting process anomalies in these process instances. Background of the invention

[0002] More and more companies are using methods to analyze current processes. The processes to be analyzed can be executed in a computer system, with the help of a computer system, or outside of a computer system. The processes executed outside of a computer system can be technical processes, such as assembly processes, manufacturing processes, or the like.

[0003] An executed process is referred to as a process instance of a specific process. A process instance can comprise multiple process steps. Each process step typically generates data that is stored in a computer system. For example, the computer system can store who performed which process step of an ordering process and when. For an assembly process, for example, it can store when which assembly step was performed with which parameters (e.g., the torque when tightening screws) during the assembly of a vehicle – this data can be provided, for example, by sensors.

[0004] Information relevant for analyzing the processes can be extracted from this stored data.

[0005] These analyses are backward-looking or retrospective analyses of previously executed process instances, which can provide information about weaknesses in the respective processes. However, proactive intervention in the process instances to control faulty process instances is not possible, as the faulty process instances have already been executed, and errors in individual process instances can therefore only be discovered after they have been executed. For example, for a vehicle assembly process, it can only be determined after the assembly process has been completed that the assembly of this vehicle has exceeded a predetermined assembly time. With the methods known from the state of the art, it is at best possible to make improvements to future process instances based on the analysis of previously executed process instances.However, errors or anomalies – which may occur despite improvements to the process – in process instances that are currently running cannot be detected or even corrected.

[0006] The disclosure in US2016110277 concerns the logging of execution times of periodic jobs. A statistical analysis is performed to detect anomalies and inconsistencies. If a threshold is exceeded, corrective action is taken. Object of the invention

[0007] The object of the invention is therefore to provide solutions that make it possible to detect and correct errors or anomalies during the execution of the process instances. Inventive solution

[0008] This object is achieved according to the invention by a method according to the independent claim. Advantageous embodiments and further developments of the invention are specified in the dependent claims.

[0009] Accordingly, methods are provided for monitoring process instances in execution and for eliminating process anomalies in these process instances, each process instance comprising a number of process steps, process data being stored in at least one process log for the process steps of the process instances already executed, the process data for each process step comprising at least an identifier of the process step, an identifier with which the process step can be uniquely assigned to a process instance, and an order of the process step within the process instance, wherein a process anomaly is described with at least one sensor definition, wherein a process anomaly is assigned a set of generic actions for correcting the process anomaly, wherein (a) in a monitoring step, a sensor monitors the process log with regard to the process anomaly described in the sensor definition using the sensor definition and detects process instances or processes comprising several process instances that have the process anomaly described in the sensor definition, and (b) in a correction step for a process instance detected in the monitoring step, the process anomaly is corrected at the runtime of this process instance,wherein at least one generic action is selected from the set of generic actions associated with the process anomaly, a process intervention instance specific to the detected process or the detected process instance is generated based on the selected generic action, and the process intervention instance is executed to remedy the process anomaly of the detected process instance or the detected process.

[0010] A process anomaly is an error in a process instance that is currently executing. However, a process anomaly can also be a deviation of a process instance from a specified target value, although the deviation does not necessarily have to be an error, such as when the torque used to tighten a screw exceeds a target torque but is still below the maximum permissible torque.

[0011] The method according to the invention can be used to actively intervene in process instances that are currently being executed. For example, a specific technical process (e.g., a pasteurization process) can be intervened in if the sensor detects an anomaly (e.g., exceeding the pasteurization temperature) during the monitoring step. By intervening in the process, the anomaly can be remedied (e.g., the pasteurization device can be prompted to reduce the heat energy supplied).

[0012] In one embodiment of the invention, the process data for each process step are stored in the process protocol during the execution of the process step or at the end of the process step.

[0013] The sensor definition may contain data and / or instructions used in the monitoring step to select process instances and / or processes from the process log that meet a predetermined selection criterion.

[0014] The selection criterion can at least one static or dynamic parameter, at least one predetermined pattern, and / or at least one parameter that can be determined by means of pattern recognition where a deviation or non-deviation from the selection criterion means that the selection criterion is met and a deviation or non-deviation from the selection criterion is indicative of a process anomaly.

[0015] A process instance can have a plurality of sub-process instances, wherein the process steps of the sub-process instances can be executed in different source systems, and wherein the process data for the already executed process steps of the sub-process instances are merged in the at least one process log.

[0016] On the one hand, the process data are stored in a central process protocol, even if the sub-process instances are executed in different systems (e.g. if a sub-process of an assembly process is carried out with a first assembly machine and another sub-process of this assembly process is carried out with a second assembly machine).

[0017] In one embodiment of the invention, the sensor definition can include information about the times at which the monitoring step is executed. Depending on the requirements, real-time monitoring of process instances currently being executed is also possible.

[0018] It can be advantageous to filter the process log according to predetermined filter criteria before the monitoring step, with the filtered process log serving as the basis for the monitoring step. This allows the number of entries in the process log to be checked to be reduced if necessary, which is particularly advantageous when the process log contains a large amount of data (e.g., process data for several hundred million process steps). This can increase processing speed.

[0019] In one embodiment of the invention, the process data stored in the process log can be linked to additional auxiliary data describing the respective process instance and / or the respective process step. When the process intervention instance is generated, it is parameterized with the auxiliary data. This makes it possible to generate a process intervention instance tailored to the respective process instance (for which an anomaly is to be remedied) and to expand the sensor definition with data not stored in the process log.

[0020] The process intervention instance may comprise a number of non-invasive actions and / or a number of invasive actions, where the non-invasive actions are executed outside the source system in which the respective process instance is executed, and the invasive actions are executed in the source system in which the respective process instance is executed.

[0021] With an invasive action, the flow of the respective process instance in the source system can be changed and / or controlled.

[0022] The non-invasive actions and / or the invasive actions can be converted into instructions executable for the respective source system.

[0023] The selection of at least one generic action from the set of generic actions assigned to the process anomaly can be performed by performing a simulation for a number of the actions or combinations of actions contained in the set of generic actions. This simulation determines which action or combination of actions, when applied to the process instance, best leads to a predetermined result. This action or combination of actions is then selected. For several potentially suitable actions, an "optimal" action or combination of actions can thus be selected. This prevents the need to "test" an action or combination of actions on the running process instance.

[0024] The filter criterion can be formed by at least one attribute of the process log and the characteristics that this attribute can assume, wherein the characteristics are assigned to a user, wherein the process anomalies occurring in the filtered process log are also assigned to this user via the assignment of the characteristics of the attribute to the user.

[0025] It is particularly advantageous if the process log is stored in a computer system's main memory, preferably in such a way that successive process steps of a process instance are stored in adjacent memory locations. This allows the process log to be read from the memory as a continuous stream, i.e., memory location by memory location. Complex addressing or addressing procedures (e.g., to map references between successive process steps of a process instance), which are detrimental to performance, can thus be avoided. If it is known how many memory locations are occupied by a process instance, these can also be read block by block.

[0026] The monitoring step may be performed by an anomaly detection engine and the remediation step may be performed by an anomaly remediation engine, where the anomaly detection engine controls the execution of the sensor, whereby the execution of the sensor is triggered according to the times specified in the sensor definition, and the anomaly detection engine passes information about the process instances detected by the sensor to the anomaly correction engine.

[0027] The anomaly detection engine and the anomaly correction engine can be executed in a computer system. Short description of the characters

[0028] Details and features of the invention, as well as specific embodiments of the invention, will become apparent from the following description in conjunction with the drawing. It shows: Fig. 1 shows a block diagram of an anomaly detection engine; Fig. 2 shows a block diagram of an anomaly correction engine; Fig. 3 shows a block diagram of the routing engine; Fig. 4 shows a block diagram of the process intervention engine; Fig. 5 shows a block diagram of the notification engine; Fig. 6 shows a block diagram of an overall system of the invention; Fig. 7 shows a concrete example of a process instance being executed; Fig. 8 shows a block diagram to illustrate the basic inventive method; and Fig. 9 shows a network of process protocols, anomaly detection engines, and anomaly correction engines. Detailed description of the invention

[0029] The invention makes it possible for the first time to monitor the execution of process instances and to intervene during the execution of a process instance to correct an error or anomaly in that process instance. In this sense, a process in progress is also referred to as a process instance of that process.

[0030] According to the invention, the error or anomaly is remedied by executing a process intervention instance, which is generated during the execution of the process instance depending on the detected error or anomaly. Such a process intervention instance can, for example, influence or control the further execution of the process instance.

[0031] For example, in a source system running an ordering process, a payment hold can be initiated if a supplier's invoice is received before the ordered goods are delivered. According to another example, a PCB assembly machine in an ongoing assembly process can be prompted to change the assembly sequence of the components still to be assembled if the last components assembled threaten to exceed the maximum assembly time.

[0032] A process intervention instance therefore contains one or more instructions adapted to change or control the corresponding process instance. In the above example of the ordering process, this instruction can be, for example, an SAP ® transaction that initiates a payment block if the ordering process is executed in an SAP ® system. In the example of the placement machine, the instructions can be interpretable instructions by the placement machine that cause the placement machine to make a corresponding change to the placement sequence.

[0033] According to the invention, any type of process instance can be monitored and anomalies or errors can be corrected during execution. In particular, Process instances executed exclusively in a computer system (e.g. instances of an ordering process or instances of a payment process), process instances executed exclusively by technical devices (e.g. an assembly process executed by one or more assembly machines or a painting process executed by a painting robot), and process instances executed partly in a computer system and partly by technical devices (e.g. a just-in-time production process that includes an ordering process executed in a computer system and a production process executed by production machines), monitored and any anomalies or errors corrected during execution.

[0034] A process instance typically comprises several process steps. For example, an instance of an ordering process may include a step for checking the availability of a product, a step for ordering a specific quantity of the product, and a step for receiving an order confirmation. An instance of a painting process performed by a painting machine may include a step for requesting a specific color from a paint warehouse, a step for applying the color to the object, and a step for applying a clear coat.

[0035] Process data for the process steps already executed in a process instance currently being executed is stored in a process log. In addition to the process data to be stored in the process log, further data may arise or be generated during the execution of the process steps that do not need to be stored in the process log. The process data and this additional data are collectively referred to as source data. It can be advantageous to store the source data in the source system (e.g., in the computer system in which an ordering process is executed, or in a storage device assigned to an assembly facility), to extract the process data from the source system, and to store the extracted process data in the process log.

[0036] It is advantageous if the process data is stored in the process log in real time, i.e., immediately after the corresponding process step has been executed. This also enables real-time monitoring (or near-real-time monitoring) of the process instances, which in turn allows for intervention or control of the process instance in real time. This is particularly important when the process steps of a process instance are executed at short intervals (for example, in an assembly process where a large number of components are mounted on a circuit board within a few seconds).

[0037] The process log contains at least the information about which process steps took place for which objects (e.g. orders, production goods, logistics processes, assembly processes) at which times, i.e. for each process step at least an identifier of the process step, an identifier with which the process step can be uniquely assigned to a process instance, and an order of the process step within the process instance.

[0038] The order of the process step within the process instance can be specified, for example, by a consecutive unique number or by a timestamp (e.g., the execution time of the process step). Other ways of specifying the order are possible, for example, by a process step referencing its subsequent process step.

[0039] In addition, the process log can provide master data information about the objects or process instances, such as the quantity and price of an order, the production type of a good, the transport route of a logistics process, or the maximum duration and temperature of a pasteurization process. This master data information can either be stored in the process log or referenced using the process step identifier or the process instance identifier. This master data information is also called auxiliary data.

[0040] A process instance can have multiple sub-process instances, whereby the process steps of the sub-process instances can be executed in different source systems. For example, a procurement process (= process instance) can comprise an ordering process (= first sub-process instance) and a payment process (= second sub-process instance), whereby the ordering process is executed in an ordering system and the payment process is executed in an accounting system. In a production process (= process instance), the grinding (= first sub-process instance) of a component can be performed by a grinding machine and the painting (= second sub-process instance) of the component can be performed by a painting robot.

[0041] The process data of the executed process steps of the sub-process instances can be stored in separate process logs. However, it is advantageous if the process data of the sub-process instances are stored or merged in a common process log.

[0042] The process steps of a specific process instance are also referred to as process paths. Accordingly, a process protocol has multiple process paths.

[0043] For a process instance running in a computer system, the process data is usually provided by this computer system. The computer system in which a process instance is running is also referred to as the source system. For process instances run by technical equipment, such as production machines, the process data is usually provided by the respective technical equipment, such as measuring sensors (e.g., a torque and angle sensor in a screwing process). The technical equipment is also referred to as the source system. The source system is therefore the system that runs the process instance. If a process instance is run by multiple source systems (e.g., a first sub-process instance from source system A and a second sub-process instance from source system B), these source systems are collectively referred to as the source system.

[0044] The term "process anomaly" is also used below. A process anomaly is an error occurring in an executing process instance or a process instance's flow that leads to undesirable results or deviates from a predetermined target process.

[0045] It is advantageous if the process log is stored in the main memory of a computer system, preferably in such a way that successive process steps of a process instance are stored in adjacent memory cells. The process steps can then be read from the main memory as a continuous stream and in the correct order. This eliminates the need for complex sorting.

[0046] Fig. 1shows a block diagram of an anomaly detection engine to illustrate the sub-process for monitoring executing process instances and the mechanism for discovering or detecting process anomalies.

[0047] The basis for the anomaly detection engine is the process log, which also forms the data input for the anomaly detection engine. The anomaly detection engine is adapted to monitor the process log and detect anomalies in all or selected process instances stored in the process log.

[0048] The anomaly(s) to be detected in a process log or for process instances in the process log are characterized by one or more sensor definitions. In a monitoring step, a sensor of the anomaly detection engine uses the sensor definitions to monitor the process log for the process anomalies described in the sensor definitions. At the same time, the sensor detects process instances or processes comprising multiple process instances that exhibit the process anomalies described in the sensor definition.

[0049] The sensor definition can refer to both anomalies / problems in business processes and anomalies / problems in technical processes. Examples of business process environments include purchasing processes, sales processes, billing processes, IT service management, web analytics, or master data management. Examples of technical processes include logistics processes, production processes, or assembly processes.

[0050] The following are examples of different classes of anomalies that can be monitored and detected with the anomaly detection engine according to the invention, whereby other classes of anomalies are also possible. Timeout class: A timeout is characterized by an activity B not occurring or being carried out within a specified time period after the occurrence of an activity A, i.e. a specified time period between two activities or process steps of a process instance is exceeded. Examples: Raw materials must be ordered to execute a production process. The raw materials are not ordered within the specified time period, so that the customer order linked to the production process cannot be fulfilled by the customer's requested date. The prescribed heating time for the pasteurization of milk is exceeded. Timeout class: A timeout occurs when a minimum time difference between two process steps of a process instance is not met.Examples: A supplier's dangerous goods delivery arrives before the specified delivery date and leads to an overflow of the dangerous goods warehouse. The minimum cooling time required for hardening steel in the quenching process is not adhered to. Class: Unauthorized process pattern: An unauthorised process pattern is characterized, for example, by an unauthorised chronological sequence of process steps within a process instance or by an unauthorised combination of process parameters from several process steps within a process instance. Examples: A supplier's invoice is received before the ordered goods are received. The assembly sequence during the machine-controlled assembly of a machine is not adhered to. Class: Violation of responsibilities: A violation of responsibilities occurs when, for example,Two different process steps of a process instance are illicitly performed by the same person (or, in technical processes, by the same object / machine). Examples: The approval and payment of a supplier invoice are performed by the same person, thus violating the dual control principle. Initial assembly and wheelbase inspection during vehicle construction are performed using the same measuring device.

[0051] The above-mentioned classes of anomalies and the corresponding examples refer to the detection of anomalies in individual process instances or in individual process paths.

[0052] In addition to the process instance-specific detection of anomalies, the method according to the invention also enables the monitoring and detection of anomalies across process instances. This makes it possible to determine whether a process (= instances of this process) as a whole is in a normal or abnormal state. The following types of anomalies can be monitored and detected, for example. Accumulation anomaly: An accumulation anomaly refers to the unusual temporal accumulation of the occurrence of a specific process step across multiple process instances. The attribute "unusual" can refer either to a statically specified reference value or a dynamically determined value from the past. Examples: The rejection rate of customer orders increases unusually sharply. The scrap rate in a production process increases statistically significantly. Lead time anomaly: A lead time anomaly describes the unusual temporal development of the lead time between two process steps across multiple process instances. Using the method according to the invention, a significant deviation from a static reference value or from a dynamically determined reference value can be determined from past lead time values. Examples: The release process (e.g.The time between the creation and release of an order suddenly becomes unusually long across multiple process instances. The waiting time of a product within the production system becomes unusually long.

[0053] The sensor definition includes data and / or instructions used in the monitoring step to select process instances and / or processes from the process log that meet a predetermined selection criterion. Examples of predetermined selection criteria are those mentioned above for the classes of anomalies or types of anomalies.

[0054] In the example of the heating time in the pasteurization of milk mentioned above for the "Timeout" class, the instruction or selection criterion of the sensor definition could be: "Find all process instances of the 'Pasteurizing Milk' process where the heating time in the heating step is greater than 8 minutes." The heating time is recorded by a timer and made available for storage in the process log. As soon as the "Heating Step" process step has been executed for a process instance of the "Pasteurizing Milk" process, a corresponding entry is created for this process step in the process log. The heating time can be stored directly in the process log. Alternatively, the heating time for this process step can be stored in an external table referenced from the process log.Immediately after the corresponding entry is created in the process log, the sensor of the anomaly detection engine, which monitors the process log according to this sensor definition, can detect this anomaly and pass the detected anomaly to an anomaly correction engine (described in more detail below) for remediation.

[0055] In the above-mentioned example of the heating time during milk pasteurization, the instruction or selection criterion of the sensor definition could alternatively be as follows: "Find all process instances of the 'Pasteurizing Milk' process where more than 8 minutes have passed since the start of heating." The start of heating can be indicated in the process log, for example, by a timestamp. In this case, the heating time itself is not stored in the process log. Instead, the respective sensor continuously checks (e.g., every 5 seconds) whether the specified heating time (here, 8 minutes) has already been exceeded since the start of heating.

[0056] This alternative sensor definition has the significant advantage over the first sensor definition that exceeding the specified heating time can be detected or recognized while the heating step is being executed (with the first sensor definition, however, exceeding the specified heating time can only be detected after the heating step has ended). This allows the anomaly correction engine to intervene in the ongoing heating step using a corresponding process intervention instance and, for example, provide instructions to a pasteurization device that cause the pasteurization device to immediately terminate the heating step.

[0057] According to the invention, the above-mentioned classes and types of anomalies for process instances and processes as a whole can be described in a sensor definition, ie defined with the aid of data and / or instructions or selection criteria in the sensor definition.

[0058] The three types of sensor definitions described below can be provided. Sensor definition for anomalies caused by exceeding or falling below a statically defined parameter (static sensor): The above-described examples of process instance-dependent anomalies can be considered in the sensor definition in such a way that a specified parameter (a time interval, a target sequence of process activities, etc.) is not met, and the corresponding process instance therefore exhibits an anomaly. Sensor definition for anomalies using pattern recognition: The anomalies of the above-mentioned types "accumulation" and "throughput time" for cross-process instance anomalies represent examples of pattern recognition supported by the invention. Using a reference period in the past, typical patterns are extracted from process instances of a process, and deviations from these patterns during the observation period can be recognized as process anomalies.Examples: The anomaly detection engine's sensor continuously scans the rate of manual interventions within a procurement process (e.g., manual changes to order prices or quantities). If characteristics occur in the current week (= observation period) that deviate significantly from the level and fluctuation of the rate in the reference period (e.g., the previous year), a process anomaly is detected, which can be corrected by an anomaly correction engine. In a manufacturing process, a specific product is manufactured according to specific specifications. Compared to past production quantities, the sensor detects that the production quantity in the observation period is suddenly noticeably low. The anomaly correction engine can intervene in the manufacturing process to bring the production quantity back to the desired level.Sensor definition for anomalies due to exceedance / undershoot of a parameter dynamically determined using pattern recognition: In addition to the static sensor described above, the invention makes it possible to dynamically determine the parameter for defining an anomaly using a pattern recognition process. After specifying a parametric model, the parameters are calibrated based on patterns in a reference period. The parameters thus determined can be used as a basis for anomaly detection, as with the static sensor.

[0059] A detailed example of a sensor definition or a sensor is given below.

[0060] An example sensor definition is considered that allows a sensor of the anomaly detection engine to detect outstanding deliveries from the USA and Germany in a process log.

[0061] The process log, which contains at least one identifier for the process steps, an identifier that uniquely assigns the process steps to a process instance, and a sequence of process steps within the process instances (= minimal attributes of the process log), is enriched in this example with auxiliary data to enable the sensor to detect outstanding deliveries from the USA and Germany. The process log thus contains the minimal attributes of the process log and the necessary auxiliary data.

[0062] In addition to the aforementioned minimal attributes of the process protocol, the auxiliary data also flow into the sensor definition. All components relevant to this example are listed below. 1. The minimal attributes of the process protocol, i.e., the process steps with the corresponding assignments to a process instance and their execution times, are stored here in a "Process Steps" table. Table of process steps ID Process step Time of entry 10829382 Create order item 2018-01-03 10829382 Receive order confirmation 2018-01-04 10829382 Confirmed delivery date 2018-01-24 10182731 Create order item 2018-02-01 10182731 Receive order confirmation 2018-02-04 10182731 Confirmed delivery date 2018-02-05 10182731 Receive invoice 2018-02-09 20173621 Create order item 2017-12-02 20173621 Receive order confirmation 2017-12-08 20173621 Confirmed delivery date 2017-12-20 20173621 Receive goods 2017-12-20 20173621 Receive invoice 2017-12-21 20173621 Pay bill 2017-12-23 ... ... ... The "ID" column identifies the process instance, the "Process Step" column identifies the process step within the process instance, and the "Entry Time" column identifies the time at which the respective process step was executed. The "Entry Time" column also determines the order of the process steps within a process instance. 2. A list of all orders (which can be stored, for example, in a database in an "Orders" table), consisting of the order identifier (ID = order number) and an identifier for the respective supplier. Other attributes that are not necessary for the sensor definition according to this example can be provided, such as the currency and order value. Orders table ID supplier Net value currency 10829382 318623 1000 EUR 10182731 327462 2000 USD 20173621 621531 1500 EUR ... ... ... ... 3. Information about the suppliers. This is necessary for restricting the search to outstanding deliveries from the USA and Germany and is provided in many source systems in the form of a central master data table (here, the "Suppliers" table). This table contains at least an ID for the suppliers and the country assigned to each supplier. Other attributes that are not necessary for the sensor definition according to this example can be provided, such as the supplier's telephone number. Suppliers table supplier country Telephone number 318623 GER ... 327462 USA ... 621531 GER ... ... ... ...

[0063] A possible sensor definition that allows a sensor of the anomaly detection engine to detect outstanding deliveries from the US and Germany in a process log might look like this (according to a pseudocode): FILTER process equals 'Receive order confirmation' and process not equals 'Receive goods' and process not equals 'Send reminder' and "Suppliers"."Country" IN ('USA', 'GER') and DAYS_BETWEEN ( PU_MAX("Orders", "Process steps" . "Entry time", "Process steps" . "Process step" = 'Confirmed delivery date', TODAY()) ) >= 7

[0064] The filter condition (FILTER) examines the entire process log for the specified criteria and returns exactly those orders for which the criteria are violated and thus exhibit an anomaly.

[0065] The three "process-equals" expressions limit the data set to those orders for which the supplier's order confirmation has already been received, but no goods have yet been received and no reminder has been sent. This means that the process log is reduced to open orders (in the sense of goods not yet received).

[0066] The supplier origin conditions ("Suppliers"."Country" IN ('USA', 'GER')) ensure that only German and American suppliers are considered, according to the desired use case. In general, any attributes of the process protocol can be used here.

[0067] Finally, the "DAYS_BETWEEN..." condition specifies the anomaly condition (in this case, the timeout). If at least seven days elapse between the observation time and the last confirmed delivery date, the delivery is considered late and thus constitutes an anomaly.

[0068] The PU_MAX function is intended to determine the exact date furthest in the future for an order item.

[0069] If the anomaly detection engine sensor with the above sensor definition is applied to the above example of a process protocol, anomalies arise for orders 10829382 (19 days late) and 10182731 (seven days late) at the observation time of February 12, 2018 (e.g., the sensor's execution time). Order 20173621, however, does not represent an anomaly because, among other things, the goods have already been received and the condition "process not equals 'Received Goods'" is therefore not met.

[0070] The sensor itself can be executed at predefined times, e.g., cyclically every two days, or every Monday and Wednesday. Alternatively, the sensor's execution can be triggered by an entry in the "Process Steps" table, meaning that as soon as a new entry is added to this table, the sensor is executed. Triggering the sensor by adding an entry to the process log can be advantageous when real-time or near-real-time anomaly detection is required to be able to correct anomalies detected in real time.

[0071] Any process steps and attributes can be included in the sensor definition, and any calculation operations can be performed on them for anomaly detection. An example of an ordering process is shown above. Similar sensor definitions can also be defined for technical processes (e.g., manufacturing processes). The possibilities for sensor definitions are ultimately limited only by the data stored in the process log.

[0072] For example, a sensor definition can be defined for a painting process in the automotive industry in which components are painted using a painting robot. After a painting process, a measuring instrument can measure the applied paint thickness and save this measured value for the corresponding process instance (= painting process) in the process log. A corresponding sensor of the anomaly detection engine can monitor this process log and detect when a paint layer that is too thin has been applied to a component. The anomaly detection engine can then provide information about detected process instances to the anomaly correction engine described below, which can then generate appropriately adjusted process intervention instances. Using the process intervention instances, the anomaly correction engine can instruct the painting robot to apply another layer of paint to the corresponding component.A possible sensor definition for this sensor could be (according to pseudocode) as follows: . FILTER process equals 'Painting process completed' and process not equals 'Component has left the paint shop' and "Components"."Paint thickness" < 1.5 mm

[0073] A sensor according to this sensor definition returns all process instances (painting operations) where the painting process is complete, the paint thickness is less than 1.5 mm, and the corresponding component has not yet left the paint shop. The anomaly correction engine can then instruct the painting robot to repaint the component.

[0074] If the second condition in the sensor definition mentioned above is replaced by and process equals 'component has left the paint shop' then the anomaly correction engine could cause a transport device (e.g. a warehouse robot) to transport the component back to the paint shop to be painted again.

[0075] The sensor definitions described above and the anomaly detection using a sensor based on a process protocol offer several technical advantages, some of which are listed below. By merging potentially multiple components (minimal attributes of the process protocol and auxiliary data) of a source system, it becomes possible to provide sensors that can consider not only the sequence of process steps within a process instance, but also further dependencies between the process steps. This dependency can even extend across multiple processes and process types, i.e., a sensor can consider dependencies between process steps that belong to process instances of different processes or that belong to different process instances of one and the same process. For example, production, logistics, and sales processes in a company can be linked in this way, allowing a sensor to detect anomalies across multiple process instances. Example: An anomaly in a production process (e.g.A disruption (e.g. a timeout in a production process) may be accompanied by the unavailability of a previously reserved freight forwarder, which can affect the delivery to a customer on a confirmed date. By defining a comprehensive sensor, the impending delay of the deadline can be detected at the time of the production disruption. Multiple system landscapes can be taken into account. Singular anomaly detection systems are mono-systemic and therefore only able to detect deviations within a system landscape (e.g. in processes or process instances that are executed within a specific system, e.g. within an SAP ®< system or within a production plant). With the help of the process log, processes or process instances that are executed in different systems can be brought together and thus monitored by a single sensor.Example: An ordering process and a manufacturing process are executed sequentially for a specific product and together form a procurement process. Process data from the ordering process, which is executed in an SAP system, and process data from the manufacturing process, which is executed by a production machine, are stored in a common process log. A sensor can thus monitor the entire procurement process and detect anomalies within the entire procurement process, even though the ordering process and the manufacturing process are executed in different systems. A further technical advantage of the invention arises from the three types of sensor definitions (static parametric model, pattern recognition, dynamic parameterized model).In particular, sensor definitions using pattern recognition and a dynamically parameterized model enable automated anomaly detection, which cannot be accomplished manually, i.e., is only possible with the aid of the computer-implemented method according to the invention. Furthermore, different sensors can be condensed into a holistic signal, thus providing a higher-level sensor for detecting fundamental process weaknesses. Heterogeneous, singular signals from individual sensors can thus be recorded in parallel and evaluated simultaneously.

[0076] A higher-level sensor is also called a meta-sensor. A meta-sensor uses existing sensors as input, so a meta-sensor can be viewed as a sensor that monitors existing sensors. This makes it possible, for example, to detect clusters of certain anomalies across multiple sensors, which is explained in more detail using the following example.

[0077] The anomaly detection engine defines various individual sensors that monitor the process log for specific anomalies and detect these anomalies, for example: a sensor that detects the increase of an order price in an order item by the supplier, a sensor that detects the postponement of a delivery date in an order item by the supplier, and a sensor that detects the increase of the requested delivery quantity in a customer order by the customer.

[0078] For example, these three sensors share the attribute "material number," meaning that when a corresponding anomaly is detected, the sensors can provide data that includes the material number of the corresponding process instance. For example, a meta-sensor can be deployed that detects anomalies of the "accumulation" type, such as with regard to the material number. The meta-sensor deployed in this example can detect that, for example, in the current week, an accumulation is occurring across the individual sensors for a specific material (specified here by the material number). This accumulation may indicate that a shortage of this material is looming.

[0079] The anomaly detection engine, which also executes and controls the meta-sensor, can now provide information about the detected cluster to the anomaly correction engine. The anomaly correction engine can then generate corresponding process intervention instances, which, for example, can trigger an inventory management system to actively and automatically build up the inventory of this material, for example, by ordering additional material from alternative suppliers.

[0080] Such clusters can only be detected by means of a computer system because, on the one hand, a large number of sensors can detect different anomalies, all of which can contribute to a specific cluster, and, on the other hand, each sensor can detect a very large number of process instances, each of which can quantitatively influence the specific cluster in different ways.

[0081] With the sensors and sensor definitions described above, anomalies in process instances can be detected during the execution of the process instances. An anomaly detection engine executing the sensor passes the detected process instances or information about the detected process instances to an anomaly correction engine, which is adapted to eliminate the anomaly(s) in the detected process instances. The anomaly is eliminated during the execution of the respective detected process instance, i.e., the process instance is actively intervened in and, for example, the further execution of the process instance is controlled. Furthermore, the anomaly detection engine passes the sensor definition (or sensor) on the basis of which the sensor detected the process instances to the anomaly correction engine.

[0082] Fig. 2shows a block diagram of an anomaly correction engine to illustrate the subprocess for correcting executing process instances. "Correction" here means that anomalies in a process instance are corrected or eliminated. The anomaly detection engine and the anomaly correction engine can be executed on different systems connected to a communications network.

[0083] The anomaly correction engine is configured to assign a set of generic actions to each possible sensor definition or sensor. The generic actions assigned to a sensor can be used to "correct" the process instances detected by that sensor.

[0084] After the anomaly correction engine receives a process instance from the anomaly detection engine along with the respective sensor definition or sensor, at least one generic action is selected from the set of generic actions. If the set of generic actions assigned to a sensor contains multiple generic actions, the selection of a generic action can be based, for example, on one or more attribute values ​​of the respective process instance, or on the basis of a simulation that determines the most suitable action, as described in more detail below.

[0085] The generic actions each define a specific action that can be used to correct an anomalous process instance. The definition of the generic action is independent of the source system. For example, a generic action "Generate Reminder" is defined that can be used to correct a corresponding anomaly in a process instance running in an SAP ® system or in a process instance running in a Salesforce ® system.

[0086] Based on the selected generic action, a specific process intervention instance is created for the respective detected process instance. Unlike the generic action, the process intervention instance is source system-dependent. In the above example, for the generic action "Create reminder," different process intervention instances would be created for the SAP ® system and for the Salesforce ® system.

[0087] The process intervention instance itself is then adapted so that it can correct the anomaly in the specific detected process instance. This adaptation can be achieved, for example, via parameters of the process intervention instance, to which attribute values ​​of the respective process instance, e.g., a unique identifier of the process instance, can be passed. Other types of such adaptation are also possible.

[0088] The process intervention instance is then converted into an instruction executable by the source system (where the detected process instance is running). These instructions are then transferred by the anomaly correction engine to the corresponding source system and executed there.

[0089] In one embodiment of the invention, a process intervention instance can comprise multiple activities. These activities are also converted into instructions executable by the source system and then transferred by the anomaly correction engine to the corresponding source system and executed there. This embodiment is particularly advantageous if, to correct the anomaly of a detected process instance, For example, several independent activities must be executed in the source system, or several activities must be executed in different source systems. For example, a paint application that is too thin by a painting robot can lead to a delay of the promised delivery date. The generic action to correct this anomaly could be "repeat painting step." Based on this generic action, a process intervention instance is created that includes a first activity and a second activity. The first activity can be used to instruct the painting robot to apply an additional coat of paint. The second activity can be used to instruct an ERP system to notify the customer of a new delivery date. For both activities, the anomaly correction engine generates corresponding instructions and transmits them to the painting robot or to the ERP system.

[0090] According to the invention, two types of process intervention instances or activities are provided, namely non-invasive activities or process intervention instances, and invasive activities or process intervention instances.

[0091] Non-invasive activities or process intervention instances refer to activities that are performed outside the affected source system. According to the invention, any information from the process log can be utilized.

[0092] In the case of a dangerous goods overflow (see the above example for the anomaly class timeout), the product group of the material causing the overflow or the supplying manufacturer can be determined and visualized.

[0093] In addition to the static visualization of information from the process log, the anomaly correction engine also supports dynamic information calculation. For example, for the hazardous goods warehouse, using existing delivery schedules to customers, it can be automatically calculated when which capacities will become available and when the overflow will be resolved without further intervention.

[0094] Another example of a non-invasive activity is the invocation of a process analysis, which can be used to visualize and evaluate the entire process of a process instance based on the process log. Additional information, such as process metrics, can be calculated and displayed. The anomaly correction engine can link a detected anomaly with a process analysis associated with the process log, so that an activity can be executed that can directly perform an analysis of the underlying process for a detected anomaly. The information required for the analysis is contained in the process log (minimal data of the process log and auxiliary data), with the minimal data of the process log and the auxiliary data being linked accordingly.This makes it easy to filter the process log for a specific process instance or for the process instances of a specific process, so that only the data associated with these process instances is included in the analysis. This enables easy verification of the detected anomaly.

[0095] Invasive activities or process intervention instances, on the other hand, refer to activities that are executed within the affected source system and thus trigger changes in the source system in order to correct anomalies or actively make improvements in the executed process instance.

[0096] Invasive activities may include instructions that are executed exclusively in a computer system, are executed exclusively by technical devices (e.g. an assembly machine), or are executed partly in a computer system and partly by technical devices, to correct the respective anomaly.

[0097] In the above example of the unauthorized process pattern, where a supplier's invoice is received before the ordered goods are received, the process intervention instance generated by the anomaly correction engine can include an invasive activity that places a payment hold for the corresponding order in the source system (e.g., an ERP system in which the order process is executed). The anomaly correction engine thus intervenes in the flow of the process instance with the corresponding process intervention instance.

[0098] In the above example of a machine assembly out-of-order, the anomaly correction engine can generate a process intervention instance with an invasive activity, where the invasive activity causes an assembly machine to change the assembly order of the parts yet to be assembled.

[0099] In the above example of a timeout in a production process, a first invasive activity can trigger an acceleration of the subsequent production steps performed by a machine for timely completion. Additionally or alternatively, a second invasive activity can trigger an ERP system to inform the freight forwarder and the customer of a delayed delivery. This is also an example of how instructions can be executed partly in a computer system and partly by technical devices.

[0100] In the event of a hazardous goods warehouse overflow, the anomaly correction engine can create a process intervention instance that can trigger an automated reallocation of inventory or the early delivery of stored hazardous goods to create additional capacity.

[0101] According to the invention, three types of process intervention instances can be generated: Statically generated process intervention instances can be limited to reproducing information statically obtained from the process log associated with the anomaly. This includes, for example, displaying attributes of the anomaly, such as the supplier and reference document number in the case of a delayed delivery, the persons involved in a process compliance violation, or the duration of the timeout in a pasteurization process. Dynamically generated process intervention instances include metadata about the anomaly and the source system that goes beyond the process log. One result of this is, for example, linking an anomaly to a process analysis associated with the process log or generating an executable activity in the source system (= invasive activity).According to a third approach, an optimal action for generating a process intervention instance is determined from the set of generic actions using a simulation. For example, for all possible generic actions, it can be determined how the throughput time of a process instance changes when the actions are applied to the process instance, and the action for generating the process intervention instance can be selected for which the determined throughput time is closest to a target throughput time.

[0102] Building on the above example, in which a sensor of the anomaly detection engine detects outstanding deliveries from the USA and Germany, a desirable action may be to specifically remind the affected supplier. This is an example of a dynamically generated, invasive action because, on the one hand, attributes of the anomaly are incorporated into the creation of the process intervention instance, and, on the other hand, a direct execution of the process intervention instance (in the form of executable instructions) is initiated, thus causing a change in the source system. "Dynamic" in this case means that, for example, the supplier number is incorporated into the creation of the process intervention instance in order to specifically remind the affected supplier. "Invasive" means that the reminder is generated directly in the source system.

[0103] The process intervention instances described above and their creation offer several technical advantages, some of which are listed below.The generic actions can be defined uniformly for any module within a system and for different source systems. Only when the process intervention instances are executed do source-system-specific instructions need to be generated. In one embodiment of the invention, these instructions can also be generated by the source system itself if the anomaly correction engine provides the source system with the necessary information. This is a necessary prerequisite for actively controlling an overall process, particularly for anomalies that require simultaneous invasive intervention in multiple systems to correct the anomaly. A further advantage is the described linking of an anomaly with a process analysis associated with the process protocol.This provides an efficient method for specifically investigating anomalies, understanding their process flow in detail, and selecting the most appropriate course of action. Another significant technical advantage is the ability to determine the most appropriate course of action using simulation. This allows, for example, the impact of different assembly sequence arrangements in a production process or the development of hazardous goods inventory when adjusting planned delivery times to be simulated, and the most likely best option to be selected. However, manual "trial and error" in the currently executing process instance is not possible.

[0104] According to a further aspect of the invention, for effective process control, the allocation of process intervention instances to the responsible and acting processors can be provided. This aspect of the invention is described with reference to Fig. 3 ,which shows a block diagram of a routing engine. The task of the routing engine is to narrow down the process log for a given user so that all anomalies occurring therein correspond to the process instances to be processed by the user.

[0105] Incoming parameters of the routing engine are the process protocol, a mapping attribute (which can be an attribute of the process protocol), and instances (values) of the mapping attribute to be assigned to a given user.

[0106] Example: A specific purchaser is responsible for a purchasing item in the ordering process, and is assigned to the purchased material via the material master data of the source system. In this case, the assignment attribute is the material number, and the value of the assignment attribute assigned to the purchaser is the material number of the individual purchasing item.

[0107] Based on the incoming parameters, the routing engine compares the process log for a given user with respect to all instances of the mapping attribute and the instances assigned to the user and returns the portion of the process log that matches the instances of the mapping attribute assigned to the user. The result is a filtered process log that can be monitored by the anomaly detection engine (see also Fig. 4 ).

[0108] A technical advantage of the routing engine is that it automatically restricts the process log to the process anomalies relevant to the user. Manual assignment is not possible given the typically extremely high number of individual process instances (several millions) in the process log.

[0109] In addition to the process log attributes, anomaly attributes can also be included in the assignment. Assigning process instances to individual users using the routing engine is advantageous when the anomaly detection engine detects an anomalous process instance and the anomaly correction engine generates a process intervention instance, but the execution of the process intervention instance must be confirmed by a user. In cases where no user intervention is necessary, the assignment to a user can be omitted.

[0110] According to the above example of a timeout in a manufacturing process, the processor should initially be assigned via the corresponding assignment in the production order. If no improvement occurs in the process instance and completion is further delayed, the assignment should be made via another attribute, which is used to assign the process instance to the plant manager. According to the invention, the process instances continue to be monitored by the anomaly detection engine even after intervention in the process instance via a process intervention instance. The anomaly detection engine can thus determine whether a timeout still exists after a process intervention instance that has been confirmed by the processor.

[0111] In addition, it can be advantageous if the escalation of a process anomaly described above is stored as a rule in the routing engine.

[0112] In one embodiment of the invention, it may be advantageous to make the set of possible generic actions for creating process intervention instances dependent on the respective escalation level. For example, a generic action "Shut down machine" can only be made available to a plant manager for creating a corresponding process intervention instance, but not to a regular employee.

[0113] Another key advantage of the routing engine is that it can significantly reduce the process log for monitoring by the anomaly detection engine. This ensures efficient monitoring of the process log, especially with a very large number of process instances (typically several million).

[0114] Fig. 4shows a block diagram of a process intervention engine showing the relationships of the anomaly detection engine, the anomaly correction engine, and the routing engine for a given sensor.

[0115] The configuration of a sensor to identify a specific process anomaly includes the process log, the criteria (sensor definition) of the anomaly, the time interval of the periodic review of the process log for this anomaly, the assignment rule and the defined set of possible actions to resolve the anomaly.

[0116] Based on the sensor configuration, the (optional) calculation of the filtered process log for a user is performed based on the assignment rule. This, if necessary, filtered process log is then made available to the anomaly detection engine. The anomaly detection engine monitors the filtered process log and uses it to identify those process instances that match the sensor definition, i.e., that exhibit an anomaly according to the sensor definition. In a subsequent step, process intervention instances are generated for the identified or detected process instances and executed in the respective source systems.

[0117] According to a further aspect of the invention, a notification engine can be provided with which users can be informed about process anomalies (= process instances that exhibit an anomie). A block diagram of a notification engine is shown in Fig. 5 shown.

[0118] In contrast to Fig. 4 In the process intervention engine shown, the notification engine does not refer to a single sensor, but rather includes all anomalies assigned to a specific user across different sensors. The starting point for notifying a user is therefore the set of all process intervention instances assigned to him (in Fig. 5 (referred to as Process Intervention Store). This set is continuously updated according to the sensor frequency (sensor interval) in the sensor configuration, and newly emerging anomalies are collected over time.

[0119] In addition to the Process Intervention Store, the Process Intervention Register plays a crucial role in notification. The Process Intervention Register records or registers the anomalies already assigned to a user at the time of the previous notification.

[0120] The set of new anomalies, i.e., anomalies that have occurred since the last notification, is determined by comparing the Process Intervention Store with the Process Intervention Register. Furthermore, process intervention instances that are not already part of the Process Intervention Register are continuously checked for their status. This status can include the validity of an anomaly – if a new anomaly is resolved before the next notification, this anomaly can be removed from the Process Intervention Store or marked as invalid. Alternatively, for each anomaly to be transferred to the Process Intervention Register, it can be checked whether this anomaly still exists. This check can be performed using the Anomaly Detection Engine. The comparison and sending of the corresponding notification takes place at the times specified in the notification interval (e.g., daily from Monday to Friday at 11 a.m. and 3 p.m.).A user receives a notification with the bundled anomalies that are not yet part of the process intervention register and still exist at the time of the notification.

[0121] By decoupling the intervals for checking by the anomaly detection engine's sensors and the sending of notifications, the timeliness of process intervention instances can be controlled independently of user notifications. By bundling anomalies across sensors, users can be notified centrally. By taking the status of the anomalies into account, it is ensured that the responsible processor is only informed about anomalies that actually exist.

[0122] Fig. 6 shows a block diagram of an overall system of the invention.

[0123] Through the interaction of the anomaly correction engine and the notification engine, anomalies are detected and process intervention instances are created to correct the anomalies, which are sent notifications and thus promote anomaly correction.

[0124] Fig. 7 Using a specific executing process instance, it demonstrates the interaction between the source system, process log, anomaly detection engine, and anomaly correction engine. In this example, the process instance comprises two subprocess instances, P1 and P2.

[0125] Subprocess instance P1 is a sales process in which four steps have already been executed: "Create quotation," "Confirm delivery date," "Order production," and "Notify shipping company." Subprocess instance P1 was executed in an ERP system.

[0126] Subprocess instance P2 is a production process in which a specific prefabricated component is painted according to customer requirements. Three steps have already been executed in subprocess instance P2: "request component" (e.g., from a component warehouse), "paint component" (after painting, the component was dried), and "measure paint thickness." Subprocess instance P2 was executed by a painting robot equipped with appropriate sensors for measuring paint density.

[0127] For the two steps executed in the sub-process instances P1 and P2, corresponding entries are created in the process log (steps S1 and S2), where Fig. 7For simplicity, only the execution time and the identifier of the respective process step are shown. In addition to the "Measure paint thickness" step of sub-process instance P2, the measured paint density is also stored in the process log. The entries in the process log are advantageously generated immediately after the corresponding steps have been executed.

[0128] A sensor in the anomaly detection engine continuously monitors the process log (e.g., every two minutes). Fig. 7 In the example shown, the sensor definition specifies that the sensor monitors the process protocol to determine whether a "measure paint thickness" step was executed within a process instance in which the measured paint thickness is less than 3 mm.

[0129] In this example, a paint thickness of 1.5 mm was measured in the "Measure Paint Thickness" step. A paint thickness of less than 3 mm represents a process anomaly within the meaning of the present invention. The minimum paint thickness of 3 mm is fixed here. However, it can also be specified dynamically, for example, based on the requirements of the ordering customer.

[0130] Because the sensor has detected the aforementioned process anomaly, the invention provides for correcting this process anomaly. For this purpose, the anomaly detection engine informs the anomaly correction engine about which anomaly occurred in which process instance. In the example according to Fig. 7 the anomaly detection engine informs the anomaly correction engine that the process instance specified in the process log has measured too low a paint thickness.

[0131] For this specific process anomaly, the anomaly correction engine selects from a set of generic actions (which are defined in Fig. 7 not shown) selects the generic actions that can be used to resolve this process anomaly. In this example, these are the generic actions "Postpone Delivery Date" and "Repaint." The generic action "Postpone Delivery Date" is necessary here because repainting the component will delay its preparation for handover to the shipping company.

[0132] The anomaly correction engine generates process intervention instances from the selected generic actions. The process intervention instance "Postpone delivery date" is transferred by the anomaly correction engine to the ERP system (step S3), in which the first sub-process instance P1 was executed. The process intervention instance "Repaint" is transferred by the anomaly correction engine to the production system (e.g., to the painting robot) (step S4), in which the second sub-process instance P2 was executed. When generating the process intervention instances from the generic actions, the process intervention instances are adjusted using a number of parameters. The parameter values ​​can be fixed or, for example, can be set depending on the current process instance.For example, the generic action "Postpone Delivery Date" can be used for different process instances of different processes to postpone a delivery date. In this example, the anomaly correction engine can calculate the delay in the availability of the part from the duration of painting and drying the part and the availability of the painting robot, and pass this delay (e.g., 36 hours) as a parameter to the process intervention instance "Postpone Delivery Date."

[0133] The anomaly correction engine can pass the parameterized process intervention instances directly to the respective source system. The source systems can then convert the respective process intervention instances into instructions that are executable by the respective source system.

[0134] Alternatively and advantageously, however, the anomaly correction engine generates corresponding instructions executable by the respective source system from the process intervention instances and then passes these instructions to the respective source system. This has the advantage that the source systems do not need to be adapted to generate executable instructions from the process intervention instances. The creation of instructions from the process intervention instances can thus be handled centrally by the anomaly correction engine. The anomaly correction engine generates the corresponding instructions depending on the respective source system to which the instructions are to be made available.

[0135] The process intervention instances or the corresponding instructions are then executed by the respective source system. Entries can then be created in the process log for the corresponding steps (according to the executed instructions) (in Fig. 7 (not shown), which in turn can be monitored by the sensor of the anomaly detection engine. For repainting, the entries "04 / 19 / 2018 12:00 Repaint component," "04 / 19 / 2018 12:30 Drying process start," "04 / 19 / 2018 12:43 Drying process end," and "04 / 19 / 2018 12:32 Measure paint thickness, paint thickness 3.05 mm" could be generated in the process log. Since the paint thickness is now greater than 3 mm, the anomaly is considered resolved according to the sensor definition of the sensor monitoring the process log.

[0136] Fig. 7Using a specific executing process instance, it demonstrates the interaction between the source system, process log, anomaly detection engine, and anomaly correction engine. In this example, the process instance comprises two subprocess instances, P1 and P2.

[0137] Subprocess instance P1 is a sales process in which four steps have already been executed: "Create quotation," "Confirm delivery date," "Order production," and "Notify shipping company." Subprocess instance P1 was executed in an ERP system.

[0138] Subprocess instance P2 is a production process in which a specific prefabricated component is painted according to customer requirements. Three steps have already been executed in subprocess instance P2: "request component" (e.g., from a component warehouse), "paint component" (after painting, the component was dried), and "measure paint thickness." Subprocess instance P2 was executed by a painting robot equipped with appropriate sensors for measuring paint density.

[0139] For the two steps executed in the sub-process instances P1 and P2, corresponding entries are created in the process log (steps S1 and S2), where Fig. 7For simplicity, only the execution time and the identifier of the respective process step are shown. In addition to the "Measure paint thickness" step of sub-process instance P2, the measured paint density is also stored in the process log. The entries in the process log are advantageously generated immediately after the corresponding steps have been executed.

[0140] A sensor in the anomaly detection engine continuously monitors the process log (e.g., every two minutes). Fig. 7 In the example shown, the sensor definition specifies that the sensor monitors the process protocol to determine whether a "measure paint thickness" step was executed within a process instance in which the measured paint thickness is less than 3 mm.

[0141] In this example, a paint thickness of 1.5 mm was measured in the "Measure Paint Thickness" step. A paint thickness of less than 3 mm represents a process anomaly within the meaning of the present invention. The minimum paint thickness of 3 mm is fixed here. However, it can also be specified dynamically, for example, based on the requirements of the ordering customer.

[0142] Because the sensor has detected the aforementioned process anomaly, the invention provides for correcting this process anomaly. For this purpose, the anomaly detection engine informs the anomaly correction engine about which anomaly occurred in which process instance. In the example according to Fig. 7 the anomaly detection engine informs the anomaly correction engine that the process instance specified in the process log has measured too low a paint thickness.

[0143] For this specific process anomaly, the anomaly correction engine selects from a set of generic actions (which are defined in Fig. 7 not shown) selects the generic actions that can be used to resolve this process anomaly. In this example, these are the generic actions "Postpone Delivery Date" and "Repaint." The generic action "Postpone Delivery Date" is necessary here because repainting the component will delay its preparation for handover to the shipping company.

[0144] The anomaly correction engine generates process intervention instances from the selected generic actions. The process intervention instance "Postpone delivery date" is transferred by the anomaly correction engine to the ERP system (step S3), in which the first sub-process instance P1 was executed. The process intervention instance "Repaint" is transferred by the anomaly correction engine to the production system (e.g., to the painting robot) (step S4), in which the second sub-process instance P2 was executed. When generating the process intervention instances from the generic actions, the process intervention instances are adjusted using a number of parameters. The parameter values ​​can be fixed or, for example, can be set depending on the current process instance.For example, the generic action "Postpone Delivery Date" can be used for different process instances of different processes to postpone a delivery date. In this example, the anomaly correction engine can calculate the delay in the availability of the part from the duration of painting and drying the part and the availability of the painting robot, and pass this delay (e.g., 36 hours) as a parameter to the process intervention instance "Postpone Delivery Date."

[0145] The anomaly correction engine can pass the parameterized process intervention instances directly to the respective source system. The source systems can then convert the respective process intervention instances into instructions that are executable by the respective source system.

[0146] Alternatively and advantageously, however, the anomaly correction engine generates corresponding instructions executable by the respective source system from the process intervention instances and then passes these instructions to the respective source system. This has the advantage that the source systems do not need to be adapted to generate executable instructions from the process intervention instances. The creation of instructions from the process intervention instances can thus be handled centrally by the anomaly correction engine. The anomaly correction engine generates the corresponding instructions depending on the respective source system to which the instructions are to be made available.

[0147] The process intervention instances or the corresponding instructions are then executed by the respective source system. Entries can then be created in the process log for the corresponding steps (according to the executed instructions) (in Fig. 7 (not shown), which in turn can be monitored by the sensor of the anomaly detection engine. For repainting, the entries "04 / 19 / 2018 12:00 Repaint component," "04 / 19 / 2018 12:30 Drying process start," "04 / 19 / 2018 12:43 Drying process end," and "04 / 19 / 2018 12:32 Measure paint thickness, paint thickness 3.05 mm" could be generated in the process log. Since the paint thickness is now greater than 3 mm, the anomaly is considered resolved according to the sensor definition of the sensor monitoring the process log.

[0148] With reference to Fig. 8 Finally, the basic steps of the method according to the invention are summarized.

[0149] A machine carries out several steps, e.g. of a production process. The machine can also be a computer system in or with which a process (e.g. an ordering process in an ERP system) is carried out. The process carried out by the machine (= process instance) can comprise several process steps. Each process step generates data which is stored as process data PD in the process log. In the case of a machine, this data can include sensor data or operating parameters. In addition to this data, the process data comprises at least an identifier of the process instance and an identifier of the process step as well as information (e.g. a timestamp) which determines the sequence of the process steps of a process instance. Each process step stores the process data during execution or immediately after execution.

[0150] The process log can be stored in a database of a computer system connected to the machine via a communications network. It is advantageous if the database is stored in the computer system's main memory.

[0151] An anomaly detection engine controls a sensor (or multiple sensors) that continuously (or at specific time intervals) monitors the process log and, based on one or more sensor definitions, identifies faulty or anomalous process instances PI in the process log. Because the process data is saved in the process log during execution or immediately after the execution of the respective process steps, faulty or anomalous process instances can be detected while the respective process instance is being executed, i.e. before the execution of the respective process instance is complete. Depending on the time intervals at which the sensor (or sensors) query the process log, it is even possible to detect faulty or anomalous process instances.Anomalous process instances can be monitored in real time, which in turn enables intervention in the respective process instance in real time to correct the error or eliminate the anomaly.

[0152] The anomaly detection engine passes the detected process instances (PI) to the anomaly correction engine. In addition to the data from the detected process instances (PI), the anomaly detection engine can also pass additional data (auxiliary data) to the anomaly correction engine that further describes the respective process instance. For example, this data can include information about the customer for which the workpiece being machined is intended. The anomaly detection engine can query this auxiliary data from other databases and make it available to the anomaly correction engine.

[0153] In an alternative embodiment of the invention, this auxiliary data can also be queried by the anomaly correction engine, e.g., from additional databases. This is advantageous for reducing the load on the anomaly detection engine, especially when very large process protocols (e.g., with several hundred million process steps) need to be monitored, if possible, in real time.

[0154] The Anomaly Correction Engine creates process intervention instances for the process instances passed by the Anomaly Detection Engine, as described above. These process intervention instances are designed to control the respective process instance currently being executed. Fig. 8In the example shown, the anomaly correction engine generates one or more instructions for each process intervention instance and passes these to the respective source system (= in which the process instance is executed) for execution, which is located in the Fig. 8 The machine in the example shown is the machine. It is advantageous if the instructions are adapted to the respective source system so that they can be executed directly there. Fig. 8 In the example shown, the machine can be instructed to carry out a specific processing step with which the detected error or anomaly can be rectified.

[0155] The anomaly detection engine and the anomaly correction engine can run on the same computer system. Alternatively, the anomaly detection engine and the anomaly correction engine can run on separate computer systems connected via a communications network.

[0156] In one embodiment of the invention, multiple process logs can be present in which process data from different source systems is stored. Furthermore, multiple anomaly detection engines (each of which can control multiple sensors) can be provided, which monitor different process logs or monitor a process log jointly. Furthermore, multiple anomaly correction engines can be provided, each adapted to correct specific process anomalies. Depending on the detected process anomaly, the anomaly detection engines can be adapted to transfer the respective detected process instance to a corresponding anomaly correction engine. This allows a network of process logs, anomaly detection engines, and anomaly correction engines to be provided, in which each engine is configured to solve specific tasks, as exemplified in Fig. 9 shown.

Claims

1. Computer implemented method for monitoring process instances being executed in at least one source system and for eliminating process anomalies in these process instances, wherein each process instance comprises a number of process steps, wherein process data for the already executed process steps are stored in at least one process log, wherein for each process step the process data are stored in the process log during the execution of the process step, wherein the process data for each process step comprise at least - an identifier of the process step, - an identifier with which the process step can be clearly assigned to a process instance, and - a sequence of the process step within the process instance, wherein a process anomaly is described using at least one sensor definition, wherein a process anomaly is assigned a set of generic actions for eliminating the process anomaly, wherein (a) in a monitoring step, a sensor, using the sensor definition, monitors the process log for the process anomaly described in the sensor definition and detects process instances that have the process anomaly described in the sensor definition, and (b) in a correction step for a process instance detected in the monitoring step, the process anomaly is eliminated at the runtime of this process instance, wherein - at least one generic action is selected from the set of generic actions assigned to the process anomaly, - based on the selected generic action, a process intervention instance specific to the detected process is generated, and - the process intervention instance is executed to eliminate the process anomaly of the detected process instance.

2. Method according to claim 1, wherein the sensor definition contains data and / or instructions with which, in the monitoring step, process instances that satisfy a predetermined selection criterion are selected from the process log.

3. Method according to the preceding claim, wherein the selection criterion is - at least one static or dynamic parameter, - at least one predetermined pattern, and / or - at least one parameter that can be determined by means of pattern recognition, wherein in the case of a deviation or non-deviation from the selection criterion, the selection criterion is fulfilled and a deviation or non-deviation from the selection criterion is indicative of a process anomaly.

4. Method according to claim 1, wherein a process instance has a plurality of sub-process instances, wherein the process steps of the sub-process instances can be executed in different source systems, and wherein the process data for the already executed process steps of the sub-process instances are merged in the at least one process log.

5. Method according to claim 1, wherein the sensor definition comprises information about the times at which the monitoring step is executed.

6. Method according to claim 1, wherein prior to the monitoring step, the process log is filtered according to predetermined filter criteria, and wherein the filtered process log is the basis for the monitoring step.

7. Method according to claim 1, wherein the process data stored in the process log can be linked to further auxiliary data describing the relevant process instance and / or the relevant process step, wherein when the process intervention instance is generated, it is parameterized with the auxiliary data.

8. Method according to the preceding claim, wherein the process intervention instance has a number of non-invasive actions and / or a number of invasive actions, wherein - the non-invasive actions are executed outside the source system in which the relevant process instance is executed, and - the invasive actions are executed in the source system in which the relevant process instance is executed.

9. Method according to the preceding claim, wherein the sequence of the relevant process instance in the source system is changed and / or controlled with an invasive action.

10. Method according to claim 8, wherein the non-invasive actions and / or the invasive actions are converted into instructions which are executable for the relevant source system.

11. Method according to claim 1, wherein the at least one generic action is selected from the set of generic actions assigned to the process anomaly in such a way that a simulation is carried out for a number of the actions or combinations of actions contained in the set of generic actions, in which simulation it is determined which action or combination of actions applied to the process instance best leads to a predetermined result, wherein this action or combination of actions is selected.

12. Method according to claim 6, wherein the filter criterion is formed by at least one attribute of the process log and the characteristics that this attribute can assume, wherein the characteristics are assigned to a user, wherein, by means of the assignment of the characteristics of the attribute to the user, the process anomalies occurring in the filtered process log are also assigned to this user.

13. Method according to claim 1, wherein the process log is stored in a working memory of a computer system, preferably in such a way that successive process steps of a process instance are stored in adjacent memory cells.

14. Method according to claim 5, wherein the monitoring step is executed by an anomaly detection engine and the correction step is executed by an anomaly correction engine, wherein - the anomaly detection engine controls the execution of the sensor, wherein the execution of the sensor is triggered according to the times specified in the sensor definition, and - the anomaly detection engine transfers information about the process instances detected by the sensor to the anomaly correction engine.