Conformance Analysis: Difference between revisions

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
The Conformance Analysis View incorporates the [[Conformance Checking in QPR ProcessAnalyzer|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.
The Conformance Analysis View incorporates the [[Conformance Checking|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.


== AS-IS Model ==
== AS-IS Model ==

Revision as of 00:48, 11 December 2021

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.

AS-IS Model

This panel shows the real model data. You can use the AS-IS Model to filter cases. Note that you are not bound to using just the Flowchart analysis, as you can change the analysis by right-clicking the analysis and selecting a different type of analysis shown on the AS-IS Model panel.

Conforming vs Nonconforming Cases

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

Conformance Trend

This panel shows the case counts of conforming cases and total cases per month.

Top Violations

This panel shows the violations against the design model.

  • Top Violations: this column shows the violation. The main types of violations are as follows:
    • Undesired event: the event exists in the model, but not in the design model.
    • X occurred directly after Y: an event occurred in the wrong sequence in the model, i.e. according to the design model, the event X should not occur right after event Y.
    • Case did not complete: case finishes in the model data, but according to the design model, the case should still continue.
  • Cases: the percentage of cases having the violation.
  • Duration Impact: shows the impact the violation has on case duration, i.e. the average duration of the total amount of cases in the model compared with the average duration of the violating cases. For example, the Duration Impact might show that, on average, cases with the violation take 29 days longer to finish.
  • Steps Impact: shows the impact the violation has on event count, i.e. the average event count in the total amount of cases in the model compared with the average event count in the violating cases. For example, the Steps Impact might show that, on average, there are 1.5 less events in the cases with the violation.

Top Violating Variations

Shows the variations that violate the design model rules sorted by size.

Show Root Causes

Clicking this button will open a view similar to the current one, except that it uses Influence Analysis for to show which factors influence the cases that violate the design model rules:

  • Cases #: the total number of cases that have this case attribute value.
  • Nonconformance %: the percentage of nonconforming cases of the total number of cases shown on this row.
  • Contribution %: the percentage of the cases with the shown attribute value that contributes to the cases not conforming to the design model rules.

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.