Conformance Checking
Comparing what happened against what should have. Where deviations are compliance findings and where they are process design gaps.
Procedure
Conformance checking compares the log against a model of the intended process and reports where they differ.
What it needs
A model of the intended process, which frequently does not exist in a usable form.
Where the documentation is a slide, it must be modelled properly before it can be checked against, and that modelling exercise is itself informative.
Rules rather than a full model are often sufficient: this activity must precede that one, this approval is mandatory, these two must be performed by different people.
Start with rules. They are faster, easier to agree, and produce clearer findings than a fitness score.
The deviation types
Skipped activity: a mandatory step did not happen.
Extra activity: something not in the model.
Wrong order, where a control happened after the thing it controls.
Repeated activity, which overlaps with rework.
Wrong resource, including segregation of duties breaches.
The compliance findings
These are the ones with direct value and they are usually found in the first analysis.
Approvals skipped on cases above a threshold.
The same person creating and approving, where segregation is required.
Payments made twice.
Controls performed after the fact, which is a control in name only.
Cases processed outside the authorised window or by an unauthorised role.
Each is a specific case number someone can verify, which is what makes them credible and what frequently pays for the project.
The design gap findings
The larger category and the more useful one.
A step skipped in a third of cases is not a discipline problem; it is a step that does not apply to those cases.
A deviation that is faster and produces the same outcome is an improvement the operation found and the documentation never absorbed.
A mandatory field routinely filled with a placeholder means the field is not needed or not knowable at that point.
Before reporting a deviation as non-compliance, ask whether the standard is wrong. Frequently it is, and the finding is that the process should change rather than the people.
Presenting it
Not as a fitness percentage, which nobody can act on.
As a ranked list of specific deviations, each with the case count, the rule broken and the value at stake.
With the compliance findings separated from the design gaps, because they go to different people and require different responses.
With examples. Three real case numbers per finding, verifiable.
Running it continuously
Conformance is the one analysis worth running on a schedule rather than as a project.
Alert on the rules that matter: segregation breaches, skipped mandatory approvals, duplicate payments.
Route to whoever can act, the same day.
Report the rate, trended, so a rise is visible before an audit finds it.
Writing the rules
Rules are faster to agree than a model and produce clearer findings.
One condition per rule, stated in business language.
"Every case above the threshold has an approval event before the payment event."
"The approval and the creation are performed by different resources."
"No case has two payment events."
Agreed with compliance, so the checks reflect what actually matters rather than what is easy to express.
Each rule produces a case list, which is what makes it actionable.
Start with five. A model-based fitness score can come later, or never.
When the standard is the problem
The question to ask before reporting a deviation as non-compliance.
A step skipped in a third of cases is not indiscipline.
Ask the people handling those cases why. The answer is usually that the step does not apply, or cannot be performed at that point.
Check whether the documented process was ever validated against how the work is actually possible.
Where the standard is wrong, the finding is that it should change, and reporting it as a compliance breach damages the credibility of every real breach you find.
Separate the two categories in every report, because they go to different people.
What a conformance result means
Conformance checking compares the log against a designed model, and the output is easily over-read.
A deviation is a difference, not a violation. Many deviations are correct handling of cases the model omits.
A conforming case can still be wrong, if the model itself is inadequate.
The useful output is the pattern of deviations, grouped, not the overall fitness score.
A low fitness score frequently means the model is out of date rather than that the process is out of control, and that is itself a finding worth reporting.
Never report fitness as a compliance figure without examining the deviations, because someone will act on the number.