Process Mining Concepts

Process mining and QPR ProcessAnalyzer uses the basic concepts that are defined and described in this page.

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 flowed through the process.

Event

Consists of an Event Type and the transition to another Event Type. Therefore includes a time component. An event is a change in the state of matters that has happened or is expected to happen, having a meaning in a particular context. The word event is also used to mean a software object inside a computer program that represents such an occurrence in a computing system, typically causing a state transition. An event does not have a duration. Durations are expressed in terms of the time between two events. An event typically signifies the beginning or completion of an activity or the state change of a business object. Process mining typically deals with these events. Relevant attributes of an event can be derived from the context and corresponding activity. Mandatory attributes for an event include a timestamp and an identifier associating it with a process case. Several optional attributes can be identified, depending on the context, 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

A process case may contain different types of events. Each event type has a special meaning related to the particular activity and business object state transition it is associated with.

In computerized or digital transaction systems, event logs typically contain the end events only and the start events of activities are not necessarily recorded. Durations are calculated from the time between the end events. Flows are used to represent both the causality and the duration.

Event type

The individual activities or organizations that are named in the process flow chart.

An activity is the basic building block of a process model. All human work is modeled as being performed within activities. An activity is executed by a work role. The purpose of an activity is to produce value adding output. Input from preceding activities and output to succeeding activities are provided in the form of business objects in well-defined states. In a digitalized business process, execution of an activity results in changing the state of business objects.

An activity has a duration, and there may be waiting time or slack between the end of an activity and the start of the next activity.

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. Flow represents transitions that have occurred in all cases in the eventlog (not just in a single case). Starting and ending event types can be the same. 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.

Flow occurrence

Flow occurrence is a historical fact or actual instance of a flow. A timestamp and identifiers of the related events are needed for distinct identification. Note that the flow occurrence is an artificial concept. It is the events that actually occur, and the flow is just a relationship between the events.

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 a events. 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

Cases usually have additional information related to it. For example, a case in a sales process might have customer, region, sales revenue, sold items as case 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. Case attributes may have different data types depending on the data, such as string, integer, decimal number, date, boolean or duration.

Case Attributes hold the same attribute value for all event types in a case. For example, you can show the top three order types, product categories, or manufacturing plants for each alternative process flow in the Flowchart Analysis.

Event attributes: Event Attribute values can vary from event to event inside a case. For example, you can have the Flowchart Analysis show the top three users in each separate event type to see easily which users are part of which event types.

When using Event Attributes in Profiling Analysis, you can show which values are found for an event attribute, and also create a filtered view based on an event attribute. For example, you can show processes where a particular user has been involved.

Model

In an organizational context, a process is the way that people work together and apply methods and tools, to accomplish predefined common objectives. The objectives include the value that the output of the process is expected to produce to its stakeholders. A process model is an abstraction representing a process. It is the organization of work in terms of a functionally cohesive or causally connected set of activities triggered by a common event, executed by work roles, and creating or altering the state of some business object(s). A process case is a particular execution instance or an execution trace of a process. In process modeling context, a simple case contains a linear sequence of activities. A more complex case may contain parallel execution paths. In process mining context, the case contains only the end events of activities, not the activities themselves. Relevant attributes of a process case depend on the context. They apply to a case and the contained events as a whole. For example, in insurance claims processing, relevant case attributes could include:

• Customer
• Insurance policy
• Vehicle registration id
• Location of accident
• Claims handler

Every case attribute has a type, which defines what kind of data can be represented by the attribute, for example:

• Integer
• Logical truth (TRUE or FALSE)
• Date and time

Among different process categories, transactional processes are of particular interest, for example:

• Purchase-to-pay
• Quote-to-cash
• Request-to-resolution
• Idea-to-product

Filter and Filter Rule

There are two kinds of filter rules: case filter rules and event type filter rule. Case filter rules filter out cases, and the number of cases decreases. The event type filters filter out events, so the number of cases doesn't decrease but the process flow in individual cases may change as event types 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. It's not possible to show those cases in flowcharts or calculated durations for them.

Filters are used to slice the eventlog, to create smaller eventlogs to be used in the analysis. Filter consist of one or more filter rules.

• The filter rules are targeted either to cases or events.
• 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.
• Case count only covers cases which have events in the eventlog.

Note that filters are only for filtering eventlogs. The expression language provides more generic filtering capabilities for any objects.