BPMN Mining
VI EN
Log in Sign up free
Docs / Features

Log versus design

Which cases bypass a control point — and what this comparison does not do.

The question this screen answers

Which cases bypass a control point? You already have the design diagram in the tool; now you upload one period's real event log and the tool tells you where cases went differently from the design. It does not add another process to your library.

Reach it from a process detail page → Compare with an event log. The file uses the same format as building a process from a log: MaHoSo, HoatDong, BatDau (and KetThuc if you have it).

Frequency deviation

The four tables below answer "did cases follow the right path?". The Frequency deviation table answers a different question, and usually a more valuable one: on the right path, did they run the right number of times? A process that matches 100% can still be completely wrong on frequency.

  • Step level — the design says how many times a step runs per case, the log says how many. This is what catches the case of "a step present in 34% of cases being counted as 0 runs".
  • Branch level — after step A, the design says what percentage of cases go to B, the log says what percentage did.

Only deviations large enough to be worth acting on are listed: at least 0.10 in absolute terms and 25% in relative terms, on a sample of at least 20 cases. AND gateway blocks are excluded from the branch comparison — there every branch runs, so a "split ratio" has no meaning.

Reading the five tables

  • Skipped steps — cases that go straight from A to C while the design requires passing through B. This is the table an auditor takes into an interview.
  • Undocumented paths — a pair of consecutive steps that appears in the log but has no matching path in the design.
  • Dead branches — flows in the design that no case travelled. That may simply mean this log period is too short, not that the branch is redundant.
  • Incomplete cases — they start or end somewhere other than the design's first and last step. They sit outside the denominator of the match rate.
  • Unknown activities — names in the log that match no step in the diagram.

What the “Matches the design” rate is measured on

The denominator is complete cases, not all cases. An extraction window cutting cases in half happens to most real logs, and a case missing its tail does not mean it went the wrong way. The count of incomplete cases sits right beside the rate, and when there is no complete case at all the screen says “not measurable” rather than printing a zero.

What this comparison does not do

Read this before quoting the figure in an audit report
This is not alignment-based conformance checking.
  1. It does not search for a cheapest alignment. It compares directly-follows relations only: each consecutive pair of steps in a case is checked against whether the design permits it. For a case that diverges in several places it lists each divergence rather than saying “2 steps missing, 1 extra”.
  2. It does not check repeat counts, branch conditions, timing or performers. A case that loops back to a top-up step nine times still counts as following the design if the design has that loop.
  3. It only compares activities whose name matches a STEP in the diagram. Gateways and events do not appear in business logs, so they are skipped in the comparison.
  4. Events sharing a timestamp. Logs that record only the date (no time of day) are the norm in Vietnamese ERP systems. When two events in one case carry exactly the same timestamp, the order between them comes from their line order in the file, not from time — so an export that is not sorted by time can make the match rate completely wrong. The number of affected cases is always printed above the rate.
  5. A shortcut reports only ONE detour — the shortest one, at most 6 steps. If the design has two different detours between the same pair of steps, only one set of skipped steps is named; a detour longer than 6 steps is filed as an undocumented path instead.
  6. AND gateways — a case entering a parallel block while dropping a whole branch counts as a violation (AND semantics are unambiguous). The check only asks whether each branch has at least one step recorded; it does not require every step inside a branch to run.
  7. Name merging — with it on, “Thẩm định” matches “tham dinh”. If your process has two steps that differ only by accents, they are being treated as one. With it off, names must match character for character.
The full list always travels with the result
The screen keeps only the warnings that change how you read this particular run — timestamp ties and incomplete cases. The complete list of limitations, including the sentences that only appear for certain diagram shapes, travels with the result data.
Anything unclear or missing?