Query Process Mining in Plain English — and Verify Before You Report

Workflow area: Process Modeling & Mining · Tier: Core · Hands-on time: ~40 minutes

Process mining turned event logs into the most honest witness a BA can call: timestamps do not misremember, and the variant explorer shows the process as it ran, not as the SOP describes it. Copilots in Celonis, SAP Signavio PI and Apromore now put that witness behind a chat box — which is a genuine democratization and a genuine new failure mode. A natural-language answer arrives stripped of the scoping decisions that produced it: which time window, which case types excluded, whether "cycle time" meant mean or median, whether incomplete cases were counted. The number is real arithmetic over the wrong slice — the wrong-query-plausible-chart problem in process clothing. The discipline is mechanical and non-negotiable: for every copilot finding, open the underlying view, read the applied filters, and reproduce the headline number once by hand before it enters any deliverable.

When to use — and when not to

• Use it for bottleneck, variant and rework questions"which activity has the longest waiting time?", "what share of cases loop back to intake?", "how many variants cover 80% of cases?" are exactly what copilots answer fast.
• Use it to prepare SME sessionsmined exception paths and top variants make walkthrough questions concrete: "the log shows 14% of claims revisit assessment — what is happening there?"
• Use it to put numbers under gap analysescycle times, rework rates and variant counts feed pb-26's gap table as evidence rather than assumption.
• Skip it if the event log itself is unvalidatedmining a log with broken case IDs, missing activities or timezone chaos produces precise nonsense; data quality checks come first.
• Skip the causal leapmining shows what happened and how often, never why. "Approvals stall on Fridays" is a pattern; the reason needs humans (tag hypotheses for SME confirmation, don't publish them as findings).
• Skip copilot numbers you cannot reproduceif you cannot make the underlying view show the same figure, the figure does not go in the report. No exceptions for deadlines.

The recipe

1. 1.

   Validate the log before the first question. Check case-ID integrity, activity-name consistency, timestamp sanity (timezones, midnight clusters that betray batch imports), and the log's time window and completeness. Ask the copilot to help: "profile this event log for quality issues that would distort cycle-time analysis." Record the log version and extraction date — every finding will cite it.

2. 2.

   Ask structured questions, demand scope with every answer. In the copilot (Celonis Process Copilot, Signavio PI, Apromore):

   Copy

   For each answer you give, always state: the time window applied,
   case-completeness filter (all cases / closed only), any case-type
   exclusions, and whether averages are mean or median.
   
   Questions:
   1. What are the top 10 variants by case count, and what share of
      all cases do they cover?
   2. Which activity has the longest average waiting time before it,
      and what is the median vs mean?
   3. What percentage of cases contain rework (any activity occurring
      more than once)? Which activities are most re-executed?
   4. Where do cases that breach the [X-day] SLA differ from cases
      that meet it — which activities or handoffs appear only in
      breaching cases?
   5. What share of cases follow the documented happy path exactly?
   

3. 3.

   Verify in the raw views — this is the playbook. For each finding you might report: open the variant explorer / process graph behind it, read every applied filter, and reproduce the number once (re-derive the rework percentage from the case counts, recompute one median from the underlying cases or an export). Good working notes look like this:

   Copy

   COPILOT: "Average approval waiting time is 4.2 days."
   CHECK: view had filter "closed cases, last 90 days" — copilot
   didn't mention 90 days. Mean 4.2 / median 1.8 → skew from 31
   cases waiting >20 days, all one region. REVISED FINDING: median
   wait 1.8 days; a 6% tail (Region East, n=31) waits 20+ days —
   worth its own investigation. Evidence: variant view #V-12,
   log v2026-07-14.
   

   Findings routinely survive verification in changed form — usually narrower, sharper, and more useful than the copilot's first sentence.

4. 4.

   Separate findings from hypotheses. Write each verified item as: claim, number, scope (window, filters, log version), evidence link. Anything causal — why the tail waits, whether the rework is policy or workaround — goes in a separate HYPOTHESES section tagged for SME confirmation. Take that section into a pb-23-style session with people who work the process; their explanations (an approval workaround, a policy-mandated recheck, a system retry) reclassify each hypothesis as policy, workaround or waste.

5. 5.

   Report with scope attached. Every number in the deliverable carries its scope inline ("median 1.8 days; closed cases, Apr–Jun, excl. test cases") and its evidence link. A process-mining finding without its scope is how the same log ends up "proving" opposite things in two different decks.

Make it yours

• Celonis Process Copilot: strongest at scale with wired ERP connections; save your verified question-plus-scope pairs as analysis views so the verification path is one click for the next analyst.
• SAP Signavio Process Intelligence: natural fit where models live in Signavio — link mined evidence directly to the process models it tests, and let conformance checking quantify happy-path adherence.
• Apromore for the accessible path: upload a CSV event log and get variant exploration and copilot-style querying without an enterprise deployment — ideal for one-off diagnostics and training your verification habit.
• No mining tool at all: for small logs (<100k events), a pandas profile generated with an LLM's help answers the top-variant and rework questions; the verification rule is identical — inspect the code, reproduce one number.

Quality check

• Every reported number was reproducedonce, by hand or in the raw view, and the reproduction is noted with the evidence link; unreproduced numbers were cut.
• Scope travels with every figuretime window, completeness filter, exclusions, mean-vs-median; a scopeless number is treated as wrong until proven otherwise.
• The log's quality and version are documentedfindings cite the log extract and date, and known data defects are listed with their expected distortion.
• Findings and hypotheses never mixwhat the log shows is separated from why it might be so, and every causal statement is tagged with the SME who confirmed it or remains labeled hypothesis.
• Distribution shape was checkedmeans were compared against medians and tails inspected; at least one "average" in every analysis is hiding a tail worth naming.
• Counter-evidence was soughtyou asked at least one question designed to break your main finding (different window, segment split) and reported what it showed.