Conformance Analysis

The Conformance Analysis View incorporates the conformance checking capability of QPR ProcessAnalyzer. There are two views in the conformance analysis: the other shows the violations, and the other shows possible root causes for the nonconformance using the Influence Analysis for Case Attributes.

Conforming vs Nonconforming Cases

The Conformance Statistics component shows summary information about the size of conforming and nonconforming cases.

Conformance Trend Chart

This chart shows the conforming cases count and total cases across time, which visualizes how the conformance rate has developed over time.

Top Violations

This table shows violations against the design model. There are following columns:

• Top Violations: this column shows the type of violation (i.e., the actual reason for the nonconformance). The types of violations are as follows:
  • Undesired event: the event occurred in the eventlog, but it's not in the design model and thus it should not occur at all. This violation is not shown in Snowflake models.
  • <X> occurred directly after <Y>: an event occurred in the wrong sequence in the eventlog, i.e. according to the design model, the event X should not occur right after event Y.
  • <X> is the starting event: case starts with an event that is not allowed in the design model. This type of violation is reported when the first event in of the case can occur later in the process but not as the first event. If the event is not allowed at all in the process, the violation would be reported as undesired event.
  • <X> is the ending event: case reaches its last event (thus far) in the eventlog, but according to the design model, the case should continue. Note that this "violation" may occur simply because the continuation events haven't yet occurred, and thus it's not a real violation in the process.
• Cases: Percentage of cases having the violation.
• Duration Impact: Shows the impact the violation has on the case duration, i.e. the average duration of all cases compared with the average duration of the violating cases. For example, the Duration Impact might show that, on average, cases with the violation take 5 days longer to finish than on average.
• Steps Impact: Shows the impact the violation has on the number of events, i.e. the average number of events among all cases compared with the average number of events in the violating cases. For example, the Steps Impact might show that, on average, there are 1.5 events more in the cases with the violation.

Conformance Flowchart

The flowchart highlights the violating event types and flows with red color. The violations information is the same as in the Top Violations table with one exception: In the flowchart, for the violating event types also the incoming and outgoing flows are shown as violations. These kind of violating flows are not listed in the Top Violations table to make the table more readable because the listed undesired event already implies that the related flows are violating.

In the flowchart, note that only the visible event types and flows may be shown as violations, so there may be violating event types and flows that are not shown due to the flowchart visibility settings. Note also that the conformance checking stops to the first violating flow while checking each case, and thus the checking might not detect correctly possible violations that are occurring after the first violation. The first violation can be "skipped" by either filtering the model or changing the design model.

Top Violating Variations

Shows the most common variations in the process that violate the design model.

Show Root Causes

Clicking the Show Root Causes button opens a view showing the Root causes analysis listing case attribute values that correlate with conformance violations. You can go back to the previous violations view by clicking the Show Violations button.

Design Model

The design model is the set and order of events against which the data in the QPR ProcessAnalyzer model is tested. The design model is defined using BPMN 2.0 notation.

Creating the Design Model

It's recommended to create the design model automatically based on the data in the as-is model. To do this, select from the context menu either Auto-create tasks and flows or Auto-create tasks only:

• Auto-create tasks and flows: Creates a design model that is effectively the same as the as-is model. Thus, the as-is model will conform perfectly to the design model. After the tasks and flows are created, you can edit the design model and remove the events and flows that shouldn't occur in the process. Note however, that the amount of flows that is created can easily be overwhelming. To overcome this, you can first use the flowchart to filter out those events and flows that shouldn't occur in the process, then use the auto-create option. Then, after creating the design model, you can remove the filter to check the conformance of the whole model.
• Auto-create tasks only: Generates only the tasks without any flows. The result is a model that needs to be filled with flows to be a valid design model.

Note that the previous design model is replaced by the generated model.

Editing the Design Model

The design model editor can be opened by clicking the Edit Design Model button. When editing the design model, only a subset of the BPMN elements are supported which are following: Start event, End event, Task, Gateway and Connector. Unsupported elements are not available in the tool palette.