Process Mining Concepts: Difference between revisions
(→Flow) |
|||
(19 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
The process mining concepts that are used by QPR ProcessAnalyzer, are defined in this page and their relations are shown in the diagram. | |||
[[File:Process mining concepts.png|right|800px]] | |||
== Case == | == Case == | ||
A case consist of a sequence of events describing how the case | Case is an instance in the process which flow is analyzed. Cases can be chosen differently depending on the analysis. A case consist of a sequence of events describing how the case flows through the process. | ||
Case has a starting time, which is the timestamp of the first event of the case, and an ending timestamp, which is the timestamp of the last event of the case. Case has a duration which is the difference between the last and first timestamps. Case belongs to a specific variation. | |||
== Event == | == Event == | ||
Event describes that something happened in a specific time. In QPR ProcessAnalyzer, event represent a specific timestamp and thus it does not have a duration. Still, it's possible to store duration information as an event attribute to be used in the analyses. Each event belongs to a specific case. Each event has an event type which describes what what happened in the event. Events may have following event attributes, for example: | |||
* Person and work role that triggered the event | * Person and work role that triggered the event | ||
* Location where it was done | * Location where it was done | ||
Line 17: | Line 17: | ||
* Environmental conditions | * Environmental conditions | ||
* Any activity specific factor that might affect the outcome | * Any activity specific factor that might affect the outcome | ||
== Event type == | == Event type == | ||
Event type describes the type of activity that an event represents. All events have a specific type, e.g. ''Order sent'', ''Goods received'' or ''Invoice paid''. In a flowchart, the process is shown as a flow from event types to other. Each event has specific number of starting and ending flows, i.e. transitions to and from other events (which is visualized in the flowchart). | |||
== Variation == | == Variation == | ||
Line 36: | Line 29: | ||
== Flow == | == Flow == | ||
Flow is a transition from an event type to other event type | Flow is a transition from an event type to other event type, and it describes all transitions that have occurred in all cases in the eventlog. There are also start and end flows, meaning case start and case end, and thus in the starting flow there is no starting point and in the end flow there is no ending point. Flow means that there are no other events occurred between the start and end event, thus the ending event occurred directly after the start event. Note also that flows always has a direction: flow from A to B is different than flow from B to A. Starting and ending event types can be the same. | ||
== Flow occurrence == | == Flow occurrence == | ||
Flow occurrence means a transition from an event to other within a certain case. Flow occurrences are thus related to a unique case and have unique starting and ending events. The first and last flow occurrences of a case are special, as the first flow occurrence does not have a starting event and the last flow occurrences does not have an ending event. There are thus always one more flow occurrences in a case than there are events. Flow occurrences has a duration which is the difference between the starting and ending event timestamps (first and last flow occurrences are again exceptions). Note that the type of the starting and ending events can be same, and in that case there is a direct loop in the process. Note also that flow occurrences with the same starting and ending events may occur several times in a case, that is called an indirect loop. | |||
== Path == | == Path == | ||
Path is a sequence of events of specific types that a case goes through. In contrast to a variation (which contains all events in a case), a path only contains part of the event sequence. For example case with a variation A->B->C->D->E contains e.g. paths A->B->C, B->C->D and D->E. | |||
== Case and Event attribute == | == Case and Event attribute == | ||
In addition to the eventlog, cases and events can have additional information related to them. For example, a case in a sales process might have information about customer, region, sales revenue, sold items, or an event might contain information who performed the event and what was the geographical position of the event. These are examples of case and event attributes. | |||
In QPR ProcessAnalyzer, case attributes are stored to a datatable, where there is a row for each case and column for each case attributes. There needs to be one column for the case id to identify the row. Case attributes have a certain data type, such as string, integer, decimal number, date, boolean or duration. Event attributes are stored as additional columns in the events (eventlog) datatable. Note that also event type and event timestamps can also be perceived as event attributes, but in QPR ProcessAnalyzer these basic information of the eventlog are not part of the event attributes. | |||
== Project== | |||
Project is a collection of related dashboards, models, datatables, scripts and secure strings, e.g. they belong to the same analyzed process. Projects can also be created hierarchically by adding child projects to a project. Projects are also import for the access control, because user rights are set in the project level. | |||
[[File:ProcessAnalyzer concepts.png|right|700px]] | |||
== Model == | == Model == | ||
Model consists of a list of events and cases, forming an eventlog. Separate models should be created for each analyzed process. Processes can be e.g. Purchase-to-pay, Quote-to-cash, Request-to-resolution or Idea-to-product. Models belong to projects in QPR ProcessAnalyzer, helping to organize content. | |||
== Filter and Filter Rule == | == Filter and Filter Rule == | ||
Filters are used to choose specific parts of a model for more detailed analysis, i.e. slice the model in a smaller part. Filter consist of one or more filter rules. | |||
There are two kinds of filter rules: case filter rules and event type filter rule. Case filter rules filter | There are two kinds of filter rules: case filter rules and event type filter rule. Case filter rules filter cases, and thus the number of cases in the eventlog decreases. The event type filters filter events of specific types, and thus the number of cases don't decrease but the process flow in individual cases may change as some events are left out. Note that event type filter rules may filter out all events of a case, which results in cases that don't have events at all. Cases that don't have events, are not shown as cases in the analysis. | ||
Details about filter rules: | |||
* For a filter to match, all the filter rules need to match, i.e. there is an AND logic between the filter rules. | |||
* For a filter to match all the filter rules need to match, i.e. there is an AND logic between the filter rules. | |||
* There are include and exclude type of filter rules, i.e. the filter rule can either include the matched cases/events or exclude them from the resulting eventlog. | * There are include and exclude type of filter rules, i.e. the filter rule can either include the matched cases/events or exclude them from the resulting eventlog. | ||
* Filter rules are applied in the order they are defined. | * Filter rules are applied in the order they are defined. | ||
* Each filter rule modifies the eventlog affecting the next filter rules. | * Each filter rule modifies the eventlog affecting the next filter rules. | ||
Note that filters are only for filtering eventlogs. The expression language provides more generic filtering capabilities for any objects. | Note that filters are only for filtering eventlogs. The expression language provides more generic filtering capabilities for any objects. | ||
== Script == | |||
Scripts are programmed routines to perform e.g. ETL tasks, e.g fetch data from source systems and store to datatables. | |||
== Datatable == | |||
Datatables are a generic storage of tabular data. Datatables can be used to store events (eventlog) and cases (case attributes), and in addition any intermediate results needed by ETL. Also additional data needed by dashboards can be stored to datatables. | |||
== Secret == | |||
Secrets are texts which need to be kept secret, and passwords to be used to login to the datasources for data extraction can be stored as secure strings. Secure strings can be added, changed and used in scripts, but their contents cannot be viewed, keeping the data secure. |
Latest revision as of 08:53, 3 October 2024
The process mining concepts that are used by QPR ProcessAnalyzer, are defined in this page and their relations are shown in the diagram.
Case
Case is an instance in the process which flow is analyzed. Cases can be chosen differently depending on the analysis. A case consist of a sequence of events describing how the case flows through the process.
Case has a starting time, which is the timestamp of the first event of the case, and an ending timestamp, which is the timestamp of the last event of the case. Case has a duration which is the difference between the last and first timestamps. Case belongs to a specific variation.
Event
Event describes that something happened in a specific time. In QPR ProcessAnalyzer, event represent a specific timestamp and thus it does not have a duration. Still, it's possible to store duration information as an event attribute to be used in the analyses. Each event belongs to a specific case. Each event has an event type which describes what what happened in the event. Events may have following event attributes, for example:
- Person and work role that triggered the event
- Location where it was done
- Cost incurred by the event
- Work effort expended
- Environmental conditions
- Any activity specific factor that might affect the outcome
Event type
Event type describes the type of activity that an event represents. All events have a specific type, e.g. Order sent, Goods received or Invoice paid. In a flowchart, the process is shown as a flow from event types to other. Each event has specific number of starting and ending flows, i.e. transitions to and from other events (which is visualized in the flowchart).
Variation
Variation (or variant) means the sequence of events that a case goes through. If another case has different events or they are in different order, the case belongs to a different variation. Duration between the events or occurrence timestamps don't matter in regards to which variation a case belongs to. In theory, in an eventlog there is a minimum of one variation and maximum number of variations equals the case count.
Usually, the more there are event types, the more there are variations comparing to the case count. Analyzing variations might be challenging if there are lot of them. One methods to reduce the number of variations, is to exclude event types that are less important from the analysis point of view.
Variations are important in the conformance analysis point of view, because the conformance analysis classifies each variation either as a conformant or nonconformant against a certain BPMN model.
Flow
Flow is a transition from an event type to other event type, and it describes all transitions that have occurred in all cases in the eventlog. There are also start and end flows, meaning case start and case end, and thus in the starting flow there is no starting point and in the end flow there is no ending point. Flow means that there are no other events occurred between the start and end event, thus the ending event occurred directly after the start event. Note also that flows always has a direction: flow from A to B is different than flow from B to A. Starting and ending event types can be the same.
Flow occurrence
Flow occurrence means a transition from an event to other within a certain case. Flow occurrences are thus related to a unique case and have unique starting and ending events. The first and last flow occurrences of a case are special, as the first flow occurrence does not have a starting event and the last flow occurrences does not have an ending event. There are thus always one more flow occurrences in a case than there are events. Flow occurrences has a duration which is the difference between the starting and ending event timestamps (first and last flow occurrences are again exceptions). Note that the type of the starting and ending events can be same, and in that case there is a direct loop in the process. Note also that flow occurrences with the same starting and ending events may occur several times in a case, that is called an indirect loop.
Path
Path is a sequence of events of specific types that a case goes through. In contrast to a variation (which contains all events in a case), a path only contains part of the event sequence. For example case with a variation A->B->C->D->E contains e.g. paths A->B->C, B->C->D and D->E.
Case and Event attribute
In addition to the eventlog, cases and events can have additional information related to them. For example, a case in a sales process might have information about customer, region, sales revenue, sold items, or an event might contain information who performed the event and what was the geographical position of the event. These are examples of case and event attributes.
In QPR ProcessAnalyzer, case attributes are stored to a datatable, where there is a row for each case and column for each case attributes. There needs to be one column for the case id to identify the row. Case attributes have a certain data type, such as string, integer, decimal number, date, boolean or duration. Event attributes are stored as additional columns in the events (eventlog) datatable. Note that also event type and event timestamps can also be perceived as event attributes, but in QPR ProcessAnalyzer these basic information of the eventlog are not part of the event attributes.
Project
Project is a collection of related dashboards, models, datatables, scripts and secure strings, e.g. they belong to the same analyzed process. Projects can also be created hierarchically by adding child projects to a project. Projects are also import for the access control, because user rights are set in the project level.
Model
Model consists of a list of events and cases, forming an eventlog. Separate models should be created for each analyzed process. Processes can be e.g. Purchase-to-pay, Quote-to-cash, Request-to-resolution or Idea-to-product. Models belong to projects in QPR ProcessAnalyzer, helping to organize content.
Filter and Filter Rule
Filters are used to choose specific parts of a model for more detailed analysis, i.e. slice the model in a smaller part. Filter consist of one or more filter rules.
There are two kinds of filter rules: case filter rules and event type filter rule. Case filter rules filter cases, and thus the number of cases in the eventlog decreases. The event type filters filter events of specific types, and thus the number of cases don't decrease but the process flow in individual cases may change as some events are left out. Note that event type filter rules may filter out all events of a case, which results in cases that don't have events at all. Cases that don't have events, are not shown as cases in the analysis.
Details about filter rules:
- For a filter to match, all the filter rules need to match, i.e. there is an AND logic between the filter rules.
- There are include and exclude type of filter rules, i.e. the filter rule can either include the matched cases/events or exclude them from the resulting eventlog.
- Filter rules are applied in the order they are defined.
- Each filter rule modifies the eventlog affecting the next filter rules.
Note that filters are only for filtering eventlogs. The expression language provides more generic filtering capabilities for any objects.
Script
Scripts are programmed routines to perform e.g. ETL tasks, e.g fetch data from source systems and store to datatables.
Datatable
Datatables are a generic storage of tabular data. Datatables can be used to store events (eventlog) and cases (case attributes), and in addition any intermediate results needed by ETL. Also additional data needed by dashboards can be stored to datatables.
Secret
Secrets are texts which need to be kept secret, and passwords to be used to login to the datasources for data extraction can be stored as secure strings. Secure strings can be added, changed and used in scripts, but their contents cannot be viewed, keeping the data secure.