Twenty-two articles in this series have addressed how to build, control, cost and defend AI workflows. Every one of them assumed a prior step: that the firm knows what the process being automated currently is. That assumption is the subject of this article, and it does not hold as often as it should.
Key Takeaway
Process discovery means identifying how processes actually execute in the real world rather than how they were designed on paper, and one source describes the gap as often startling: processes that should take hours routinely take days, and approval paths designed as linear sequences operate as complex networks of rework and exception handling. Process mining reconstructs that picture from event logs, which requires three attributes present in the data: a case identifier, an activity, and a timestamp. That precondition is where most Canadian mid-market firms will stop, because work tracked in email and spreadsheets does not produce an event log. The four documented programme failures are trying to mine everything at once, producing insight nobody acts on, selecting a tool before scoping a problem, and abandoning the exercise on discovering poor data quality. The single most useful output for an AI decision is the variant distribution, because the share of volume running the standard path is a forecast of the achievable straight-through rate before anything is spent.
A Note On The Figures
A disclosure before the substance, because the quantitative claims in this area are among the least reliable this series has encountered.
One source reports that organisations lose between 20 and 30 percent of annual revenue to process inefficiencies, attributing the figure to a major consultancy[1]. Another reports that organisations using process mining identify an average of 14.3 million dollars in annual automation and optimisation opportunities, attributing it to a 2026 report by a process mining vendor, and reports cycle time reductions of 20 to 40 percent, compliance improvements of 15 to 25 percent and automation deployment 30 to 50 percent faster[2].
We report these and would not rely on any of them.
The revenue figure describes an undefined quantity: process inefficiency has no standard definition, and a loss of a quarter of revenue to it would be an extraordinary finding requiring extraordinary support. It reaches us at second hand from a commercial blog without a citation.
The dollar figure comes from a process mining vendor's own report on the value of process mining, which is the same structural bias this series flagged in the total cost and lock-in articles: the party reporting the benefit sells the remedy. An identified opportunity is also not a realised saving, and the distance between those is the subject of one of the four failure modes below.
The argument in this article does not depend on any of them. It rests on the qualitative finding that documented and actual processes differ, which is checkable by any firm on its own data.
The Gap Between Designed And Actual
The finding that motivates everything else, and the one worth taking seriously.
One source describes the gap that process mining makes visible as often startling: processes that should take hours routinely take days, approval paths designed as linear sequences operate as complex networks of rework and exception handling, and automation opportunities invisible to human analysis become obvious when data reveals exactly where work piles up and cycle times balloon[2].
Another frames discovery as identifying, mapping and analysing how business processes actually execute in the real world, not how they were designed on paper[3].
The middle clause of that first quotation is the one a Canadian finance professional should sit with. A linear approval sequence operating as a network of rework describes something most practice leaders would recognise once it is named, and which no process document records.
The reason it goes unrecorded is not negligence. Documentation captures the intended path because that is what someone set out to describe. Rework loops, informal escalations, work sent back for correction and the handling of exceptions are all things that happen to a process rather than things anybody designed into it.
Connect that to the substitution myth argument from earlier in this series. The function allocation article established that firms decompose work into tasks and allocate them, using an inventory built from how the work is understood. If that inventory describes an intended path and the actual work runs through a network of rework, the allocation was performed against a description of something that does not occur.
What Process Mining Is
The mechanics, stated briefly.
One source describes it as a technique to discover, monitor and improve processes by extracting knowledge from information systems, drawing on event logs and audit trails across systems such as enterprise resource planning and customer relationship platforms to reveal what is happening in the business. It defines a discovery process as using event log data to create a process model without influence from an existing model[4].
An academic paper describes the operation: a discovery method takes an event log as input and produces a model capturing the control-flow relations between tasks observed in or implied by the log, and notes that methods proposed over two decades strike different tradeoffs between scalability, accuracy and complexity of the resulting models[5].
A practitioner guide names common algorithms and describes the output as a graph in which nodes are activities and edges are transitions between them[6].
The phrase without influence from an existing model is what distinguishes this from documentation. The output is derived from what the systems recorded, so it is not constrained by anyone's account of how the work is done.
Two further operations build on discovery, and both matter later: conformance checking, being whether a new log follows the discovered model, and bottleneck analysis, being which parts are constraining[7].
The Three Attributes
The data requirement, which is the gate everything else passes through.
An academic paper states it plainly: methods use the key attributes of case identifier, activity and timestamp, hidden in an event log, as clues to discover a process model, and notes that a user must currently specify them manually, which can be an exhaustive task[7].
Those three are worth translating into finance terms because they determine whether a firm can do this at all.
Case identifier is the thing being processed: an invoice number, a client file, an engagement, a transaction. Every event must be attributable to one case.
Activity is what happened: received, coded, reviewed, approved, posted, queried, corrected.
Timestamp is when, with enough precision to order events within a case.
Given those three across enough cases, an algorithm can reconstruct the paths work actually takes. Without any one of them, it cannot.
The requirement is modest in principle and, as the next section argues, decisive in practice.
The Precondition Most Firms Fail
The honest assessment for this publication's readership, and the point at which our advice departs from the vendor material. This section is our own analysis.
Consider where a Canadian mid-market professional firm's work actually happens. A client sends documents by email. Someone saves them to a folder. Work is performed in a spreadsheet or an accounting package. A file is reviewed, which may be a conversation. Approval may be an email or a verbal confirmation. The engagement is tracked in practice management software that records dates for milestones and not for state transitions.
Ask the three questions of that. Is there a case identifier consistently applied across the systems involved? Is each meaningful activity recorded as an event? Is each event timestamped?
For most such firms the answer to at least two is no, and frequently to all three. Email has timestamps and no case identifier. The practice management system has case identifiers and few activity events. The spreadsheet has neither.
So process mining, as the literature describes it, is not available to a large share of the businesses being told they should do it. The event log the technique requires does not exist, and creating one is an instrumentation project rather than an analysis project.
That is not an argument against the discipline. It is an argument that the vendor framing, in which a firm connects a tool to its systems and receives a picture, assumes an operational maturity most Canadian mid-market firms do not have and would need to build first.
The proportionate response is set out below, and it starts from what such a firm does have.
Three Different Things Under One Label
A distinction that determines which approach is available.
One source observes that process discovery is a catch-all label for three different approaches: process mining, which uses system event logs to reconstruct flows and measure performance; task mining, which captures user interactions; and a newer AI-assisted category aimed at extracting tribal knowledge from people's heads and converting it into structured documentation[3].
It argues that if discovery does not capture how work actually happens and convert it into planning-ready outputs, a transformation is built on assumptions[3].
The three differ in what they require and what they can see, and this is our own elaboration.
Process mining requires event logs and sees what systems recorded. It cannot see work performed outside those systems, which in a professional firm is a great deal.
Task mining requires instrumentation of what people do on their machines and sees the desktop work that process mining misses. It also raises employment and privacy considerations in Canada that a firm should take advice on before deploying.
Structured knowledge extraction requires people's time and sees what they can articulate, which brings the bias problem below.
For a firm without event logs, the second and third are the available options, and the third is the one most Canadian professional practices can run without procuring anything.
Why Interviews Are Not A Substitute
The limitation of the accessible method, which the sources name and which deserves care.
One source states that traditional discovery relied on manual interviews and sticky notes, describing the result as slow, biased, and outdated the moment it was finished[1].
That is a vendor characterising the alternative to its product, and it is nonetheless substantially right about the bias, for reasons this publication has documented elsewhere.
The productivity measurement article reported a randomised trial in which experienced practitioners were wrong about the direction of an effect on their own work, both before and after experiencing it. If self-report about elapsed time is unreliable, self-report about process shape is unlikely to be better.
Three specific distortions are worth anticipating in a finance context, and these are our own.
People describe the intended path, because that is what they were trained on and what they believe they do.
People omit workarounds, sometimes because the workaround is so habitual it is invisible, and sometimes because describing it to a partner feels like admitting something.
And people under-report exception handling, because exceptions are memorable individually and hard to characterise in aggregate. Asked what proportion of files are straightforward, most practitioners will overstate it.
The practical mitigation is not to abandon interviews but to check them against whatever records exist. Even a partial timestamp trail from one system will show whether the reported path matches the observed sequence.
The Question Worth Asking
What a firm should actually want from this exercise, which is narrower than a full process picture.
A process mining output includes a set of variants: the distinct paths that cases actually take through the process. A perfectly standardised process has one variant. Real processes have many, and the distribution across them is the useful artefact.
The questions that distribution answers are: how many distinct paths exist, what share of volume runs the most common one, and what causes cases to leave it.
Those are not aesthetic questions about process hygiene. As the next section argues, they are the input to the automation decision.
A source describes the visible pattern as approval paths designed as linear sequences operating as complex networks of rework and exception handling[2], which is a statement about variant proliferation.
For a Canadian firm, the recognisable version is that the standard engagement runs one way, and then there are the ones where the client sent documents late, where a prior-year adjustment surfaced, where the ownership changed, where a query went unanswered for three weeks. Each is a variant, and each is a path the automation will encounter.
Variant Analysis Is Your STP Forecast
The argument we consider most valuable in this article, and it is our own.
The straight-through processing article in this series reported wildly conflicting benchmark claims, from roughly a third of invoices processed touchless in independent compilations to eighty percent or more in vendor material, and concluded that a firm should not adopt an external benchmark as a target because the populations differ.
Variant analysis answers the question those benchmarks cannot: what share of your own volume runs a path simple enough to automate.
The reasoning is direct. Automation handles the cases it was built for. Cases that deviate become exceptions. So the share of volume on the standard variant is an upper bound on the achievable touchless rate for an automation built against that variant, before any consideration of whether the technology performs.
A firm whose most common variant carries seventy percent of volume has a ceiling near seventy percent. One whose most common variant carries thirty percent, with the remainder spread across a long tail, has a ceiling near thirty, and no amount of model quality changes that.
This is why the benchmark conflict in that article was unresolvable in general and is entirely resolvable for a specific firm. The right target is a property of your own variant distribution.
It also predicts the exception composition problem that article identified. As automation absorbs the standard variant, the residual is composed entirely of the tail, which is by construction more varied and harder, and the variant analysis tells you in advance how varied.
Our recommendation is that any Canadian firm considering a material automation investment should establish its variant distribution first, because it converts an unbounded question about vendor claims into a bounded question about its own work.
Four Ways The Programme Fails
The most useful practitioner content in this material, and it is unusually candid.
One guide names four patterns. The boil-the-ocean start, where a team tried to mine every process simultaneously and the data preparation alone broke the programme, with the remedy being to start with one high-value process. The insight-without-action programme, where output is produced, dashboards are built, leadership is impressed and nothing changes, with a named business owner holding authority and budget as prerequisite. The tool-first selection, where a tool was chosen from vendor demonstrations before a real use case was scoped and does not match the problem, with the remedy being to scope the problem first. And the data-quality surrender, where the team discovered data quality was poor, gave up, and returned to gut-feel process design[6].
All four are recognisable and two deserve their own treatment below.
The first is worth noting for its specific mechanism: the programme failed at data preparation rather than at analysis. That matches the total cost article's finding that data preparation is the largest cost category in AI implementation, and it locates the failure before anyone reached the interesting part.
The third is the same error the retrieval article identified in a different domain, where teams tune the visible layer because it is adjustable. Selecting a tool is a decision that feels like progress and can be made without understanding the problem, which is precisely why it happens first.
Insight Without Action
The failure mode this publication would flag hardest, because it is the most likely.
The pattern as described is that mining output is produced, dashboards are built, leadership is impressed, and nothing changes, with the stated prerequisite being a named business owner with authority and budget for process change[6].
The productivity measurement article in this series reached a structurally identical conclusion about a different measurement: that a firm can produce numbers and change nothing, and that the value of measurement is entirely in the decisions it alters.
The reason this failure is likely in a professional services firm is specific and worth naming. Process change in a practice means changing how partners and managers work, and the person who commissioned the analysis frequently lacks authority over that.
So the prerequisite is not a technical one. Before commissioning any discovery exercise, a firm should be able to name who will act on the finding and confirm that they can, and if the honest answer is that the finding would go to a committee, the exercise will produce a document.
We would add a sharper test. Before starting, write down what you would do if the analysis showed the standard variant carries a low share of volume. If there is no answer to that, the analysis is not decision-relevant and should not be run.
The Data Quality Surrender
The fourth failure, and the one that converges with a finding from elsewhere in this series.
The pattern is a team discovering that data quality is poor, abandoning the exercise, and returning to intuition-based process design[6].
The retrieval article reported the same structure in a different context, where a source argued that data quality sets a ceiling on retrieval accuracy that algorithm tuning cannot close.
What is worth extracting is that the discovery of poor data quality is itself a finding, and frequently the most important one.
A firm that cannot reconstruct how its own work flowed has learned something material about its records, and the AI series' recurring conclusions depend on exactly that capability. The lineage article argued that a correlation identifier carried across systems is the difference between evidence that can be assembled and evidence that cannot. The incident article argued that questions become answerable only if logging preceded them.
So the data quality finding is not a reason to stop. It identifies the instrumentation gap that the rest of the AI programme will encounter later, in circumstances less forgiving than an analysis exercise.
Our framing for a Canadian firm is that failing the precondition is a result, and the appropriate response is to record what was missing and treat it as scope for the automation project rather than as a reason to proceed on intuition.
Conformance Checking As An Ongoing Control
The operation that turns a one-time analysis into a control, and which the vendor material under-uses.
One paper describes conformance checking as identifying whether a newly given event log follows the discovered process model[7].
Stated that way it sounds narrow. What it provides is a mechanism for detecting that a process has changed shape without anyone declaring a change.
That is the same problem this series has now described at three other layers. The drift article addressed a model changing under a validated workflow. The protocol article addressed a component changing after adoption. The retrieval article addressed a corpus degrading as it grows.
Here it is the process itself. Practices accumulate workarounds, new client circumstances create new paths, and staff turnover changes how work is handled, none of which produces a notification.
Conformance checking against a discovered baseline detects that drift, and it does so on the same principle as the regression testing recommended throughout: establish a baseline, re-measure on a schedule, and treat divergence as a signal.
Conformance After Deployment
The specific application to an AI workflow, offered as our own analysis.
A firm that discovers its process, automates part of it, and stops measuring has a picture of the pre-automation process and a system running against something else.
The function allocation article established that inserting a technology creates new tasks and changes what remains, so the post-automation process is necessarily different from the one that was measured. The straight-through processing article established that the exception population becomes progressively harder as automation improves.
Both of those are changes in process shape, and both are exactly what conformance checking measures.
The practical value is in answering questions a firm otherwise cannot. Has the exception path grown as a share of volume? Have new variants appeared since deployment? Is work being routed around the automation, which is the behaviour the deskilling article identified when practitioners quietly maintain parallel manual processes?
That last question is the one we would most want answered, because informal circumvention is invisible in every other measure. A workflow's statistics look healthy when the difficult cases are being handled elsewhere by people who stopped using it.
A Caveat About Discovered Models
An honest qualification from the academic literature.
The benchmark paper notes that the various discovery methods proposed over two decades strike different tradeoffs between scalability, accuracy and complexity of the resulting models[5].
That phrasing carries an implication worth surfacing for a business reader. A discovered model is an output of an algorithm applied to a log, and different algorithms applied to the same log produce different models.
The tension is between a model simple enough to understand and a model faithful enough to be accurate. A highly accurate model of a messy real process is itself messy, sometimes to the point of being unreadable, and a readable model has abstracted something away.
This is the same caution the chunking discussion in the retrieval article raised: a method's apparent superiority depends on the data it is applied to and on which criterion you are optimising.
For a Canadian firm the consequence is modest but worth knowing. A discovered process map is a representation with parameters, not a photograph, and a map that looks clean may be clean because the settings suppressed low-frequency paths, which are the exceptions you were trying to find.
The question to ask of any such output is what proportion of cases it accounts for.
The Proportionate Version
What a Canadian mid-market firm should actually do, given that it probably fails the precondition. This section is our own analysis.
The full discipline requires event logs most such firms lack. The underlying question does not require them.
Pick one process and one period. The most repeated engagement type, over a completed cycle.
Take a sample of actual cases, not a description. Twenty to thirty files. Reconstruct what happened to each from whatever traces exist: emails, file versions, timesheet narratives, system dates.
Record the path each one took. Not the intended path, the actual sequence including rework, requeries and escalation.
Count the distinct paths and their shares. This is the variant distribution, produced manually.
Identify what pushed cases off the standard path. These become the exception rules the automation will need, and the trigger conditions for the dynamic allocation the function allocation article recommended.
A sample of thirty files will not support statistical claims about a long tail, and it will reliably show whether the standard variant carries most of the volume or a minority of it, which is the decision-relevant question.
The exercise costs a few days and, on the argument above, bounds the achievable automation outcome before any procurement occurs.
A Worked Case: Fourteen Paths
A Canadian practice preparing to automate a recurring compliance engagement. The reconstruction illustrates the reasoning rather than reporting a specific engagement.
The documented process has six steps in sequence, and everyone describes it that way.
A reconstruction of thirty completed files finds fourteen distinct paths. The documented sequence occurs in a minority of them. The others involve information requested twice, work returned for correction, a step performed out of order because the client supplied documents late, and an escalation not recorded anywhere.
That is the network of rework the literature describes appearing where a linear sequence was designed[2].
The automation was to be built against the documented six-step path, which describes a minority of actual cases. Had it been built, the majority would have become exceptions, and the firm would have concluded that the technology underperformed.
The variant share is the forecast. It tells the firm its ceiling before it spends, and it identifies which deviations are frequent enough to be worth designing for rather than routing to a person.
It also surfaces the more valuable finding. Several variants exist because of an upstream information request that could be restructured, and fixing that raises the standard variant's share without any automation at all, which is the improvement the vendor material describes as the point of the exercise[2].
What To Do
Establish the variant distribution before committing to automation. The share of volume on the standard path bounds the achievable touchless rate, which is the number external benchmarks cannot give you.
Check the three attributes before assuming process mining is available. Case identifier, activity, timestamp. Most mid-market firms fail at least two.
If you fail the precondition, run the manual version. Thirty files, reconstructed paths, counted variants. A few days, and it answers the decision-relevant question.
Do not substitute interviews for evidence. People describe the intended path, omit habitual workarounds, and overstate the share of straightforward cases.
Name who will act before you start. If the finding would go to a committee, the exercise produces a document. Write down in advance what you would do with an unfavourable result.
Scope the problem before selecting a tool. Tool-first selection is a documented failure mode and it happens because choosing feels like progress.
Treat poor data quality as a finding, not a stopping point. It identifies the instrumentation gap the rest of your AI programme will meet later, under worse conditions.
Re-measure after deployment. Conformance against the discovered baseline detects growing exception paths, new variants, and work being routed around the automation.
Ask what proportion of cases a process map accounts for. A clean map may be clean because low-frequency paths were suppressed, and those are the exceptions.
Fix the process before automating it where you can. Consolidating variants raises the ceiling at no technology cost.
The Limits Of This Analysis
Several caveats matter, and the quantitative ones are severe. The revenue-loss figure, the identified-opportunity dollar figure and the percentage improvement ranges are reported by commercial publications, are attributed to sources we did not access, and in one case originate with a process mining vendor reporting on the value of process mining; we report them to characterise what circulates and rely on none of them. One source reads as promotional for a named platform. The academic sources are a benchmark review and a preprint on attribute identification, cited for their descriptions of method and data requirements rather than for results. Task mining raises employment, privacy and consent considerations in Canada that this article does not address and on which a firm should take advice before deploying. The argument that variant share bounds the achievable straight-through rate, the assessment that most Canadian mid-market firms fail the event log precondition, the three interview distortions, the proportionate manual method, the application of conformance checking to post-deployment monitoring and the worked case are our own analysis. The suggested sample of thirty files supports a directional reading of variant concentration and does not support statistical inference about a long tail. This article does not address process modelling notation, simulation, workflow engine selection, or organisational change management, some of which this publication treats separately. Nothing here is a substitute for professional advice on process design.
Frequently Asked Questions
Why measure the process before automating it?
Can we do process mining at all?
What should we do instead?
Why is the variant distribution the important output?
What most often goes wrong with these programmes?
Should we stop if our data is poor?
References
- CodeBrewTools. (2026, April 11). 10 Best AI Process Mining Tools 2026, on the reported claim that organisations lose between 20 and 30 percent of annual revenue to process inefficiencies attributed to a major consultancy, the goal of creating a representation reflecting reality rather than idealised handbook versions, and the characterisation of traditional discovery through interviews as slow, biased and outdated on completion. Note: a commercial listing publication; the revenue figure is unsourced, describes an undefined quantity, and we do not rely on it. codebrewtools.com/blogs/ai-process-mining-tools-2026
- Ainformat. Process Mining Business Optimization 2026, on the gap between designed and actual process being often startling with processes taking days rather than hours and approval paths designed as linear sequences operating as complex networks of rework and exception handling, and on reported figures for identified annual opportunities and percentage improvements in cycle time, compliance and deployment speed. Note: a commercial publication; the dollar figure is attributed to a report by a process mining vendor on the value of process mining, and we do not rely on it. ainformat.com/detail/2947
- Brooks, A. (2026, January 11). Process Discovery Tools in 2026: How to Choose the Right Approach, on discovery being a catch-all label for three approaches comprising process mining from system event logs, task mining from user interactions, and AI-assisted extraction of tribal knowledge into structured documentation, and on the argument that discovery which does not capture how work actually happens leaves transformation built on assumptions. Note: a personal publication in a commercial context. medium.com/@avery.brooks_59610/process-discovery-tools-in-2026
- Microsoft Power Automate. What Is Process Mining, on process mining as a technique to discover, monitor and improve processes by extracting knowledge from event logs and audit trails across enterprise systems, and on a discovery process using event log data to create a model without influence from an existing process model. Note: published by a platform vendor. microsoft.com/en-us/power-platform/products/power-automate/topics/process-mining
- Augusto, A., Conforti, R., Dumas, M., La Rosa, M., Maggi, F. M., Marrella, A., Mecella, M., & Soo, A. Automated Discovery of Process Models from Event Logs: Review and Benchmark. arXiv preprint 1705.02288, on automated discovery taking an event log as input and producing a model capturing control-flow relations between tasks observed in or implied by the log, and on methods striking different tradeoffs between scalability, accuracy and complexity. Note: cited for its description of the operation and its tradeoff characterisation rather than for benchmark results. arxiv.org/pdf/1705.02288
- Internative. Process Mining Guide: Enterprise Teams (2026), on discovery algorithms reconstructing a process graph from an event log with nodes as activities and edges as transitions, and on the four programme failure modes of the boil-the-ocean start where data preparation broke the programme, the insight-without-action programme requiring a named business owner with authority and budget, the tool-first selection made from vendor demonstrations before scoping a use case, and the data-quality surrender. Note: a commercial consultancy publication. internative.net/insights/blog/process-mining-enterprise-teams-2026
- Toyoda, K., Gan Kai Ying, R., Zhang, A. N., & Tan, P. S. Identifying the Key Attributes in an Unlabeled Event Log for Automated Process Discovery. arXiv preprint 2301.12829, on discovery methods using the key attributes of case identifier, activity and timestamp hidden in an event log, the requirement that a user specify them manually, and the subsequent operations of conformance checking, being whether a new log follows the discovered model, and bottleneck analysis. Note: preprint. arxiv.org/pdf/2301.12829
This article discusses process analysis practice and is provided for general informational purposes. Its quantitative claims are drawn from commercial publications citing sources we did not access, including a vendor report on the value of that vendor's own category, and we rely on none of them. Task mining raises Canadian employment and privacy considerations not addressed here. Nothing here is a substitute for professional advice on process design.