Every consulting engagement begins with discovery, and there are good reasons for this. Before recommending an automation, you have to understand what the work actually looks like, where the time goes, where the exceptions land, and which steps are amenable to a system that does not have a human's tolerance for ambiguity. A bad discovery produces a bad recommendation, and a bad recommendation produces an automation that fails on its first real cycle. The discipline is sound.
What is less sound is how long it takes.
How Big-4 process discovery actually works
A typical Big-4 process discovery for a single back-office function runs eight to twelve weeks. The work is a sequence of stakeholder interviews, current-state workshops, ride-alongs with practitioners, and the production of swim-lane diagrams that capture the work as the practitioners describe it. The output is a process map, often rendered in BPMN, with timing estimates per step, frequency annotations, and a list of identified pain points. The map is the artifact that justifies the engagement and informs the recommendations that follow.
Three problems with the interview-based process map
Three things about this map are worth noticing.
It is built from what people say they do, not from what they actually do. Process discovery via interview is structurally a self-report exercise. Practitioners describe the workflow as they remember it, which is a smoothed and rationalised version of how the work actually unfolds. The detours that consume a meaningful share of the time are usually invisible at this resolution: the email thread that the SOP does not mention, the spreadsheet a senior controller maintains because the ERP cannot, the five-minute conversation that resolves the exception nobody documented. A map built from interviews systematically understates the messy parts of the work because the practitioners themselves no longer perceive them as work; the workarounds have become invisible to the people who perform them every day.
It is authored. A consultant sits with a notebook, asks questions, and draws the diagram. The diagram is that consultant's interpretation of what the practitioner described. Two consultants doing the same exercise will produce two different maps. The variance is large, because the input is qualitative and the framework for compression is the consultant's training rather than the work itself.
It has a half-life of about three months. By the time a recommendation lands and an automation is being designed against it, the work has already shifted. New exceptions have emerged. A system has been upgraded. A new practitioner has joined the team and brought their own workarounds. The map is treated as canonical, but it was already approximate when produced and is more approximate now.
Observation-based process discovery via agents
A different way to produce a process map is to skip the interviews and watch the work directly.
This is what an observation-based agent does. It runs on the practitioner's machine, captures every click and paste and system write, identifies handoffs between people by observing which user touches which document next, and surfaces exceptions as the deviations from the modal path. The output is a process map generated from the observed event stream rather than authored from a notebook. The agent does not know which clicks are "real work" and which are "the way the team actually does it," so it captures both, and the result is comprehensive at the resolution that matters for automation. The map stays current because the same agent that produced it is still running and updates it as the work changes.
The implication for the engagement model is significant. Discovery collapses from twelve weeks to days. The downstream phases (design, pilot definition, pilot) compress with it because their input was the discovery output. The same agent that produced the map is the agent that ships the automation. There is no handoff to an offshore delivery centre, no consultant interpreting the diagram for an engineer, no three-week lag between phases. The engagement timeline collapses from six months to weeks. The consulting model that priced discovery as a six-figure twelve-week engagement cannot survive this.
A reasonable counter is that the consultant interview captures more than just clicks. The interview is how the consultant understands intent, not just behaviour, and intent is what informs the redesign decision. There is something to this. The agent observation produces the map; the operator conversation still produces the redesign decision. The consultant interview's job has been doing both at once, and the conversation about which clicks should become which steps in a redesigned workflow is still a conversation between the operator and the engineer who will build the redesign. What changes is that the conversation is anchored in observed data rather than self-reported memory, and the conversation can happen in days rather than weeks because the data is already there. Splitting the two jobs (agent for observation, operator for decision) is more accurate than the merged consultant-interview workflow that combines them.
Why discovery was the artifact, not the bottleneck
The deeper implication is that discovery, as the consulting industry has structured it for thirty years, was never really the bottleneck. It was the artifact that justified the rate. A discipline that takes a few days of observation and produces a better map than a twelve-week engagement cannot be sold as a six-figure twelve-week engagement. The reason it was always twelve weeks is that the engagement model required it to be. The fact that it can now be days is the fact that breaks the model.
The platform vendors have noticed. Constellation Research's coverage of the process-mining space documents the convergence: ServiceNow's Zurich release embeds process mining and agentic automation directly into the platform; ServiceNow acquired UltimateSuite in late 2023 and partnered with Celonis. The category that used to sell process mining as a diagnostic product is being absorbed into the platforms that deploy agents on top of the discovered processes. The deployment substrate and the diagnostic substrate are converging into the same thing, because they were never really separable in the first place. They were separated by the engagement model, not by the technology.
How to tell which engagement model you are buying
For an operator considering an AI engagement, the duration of the discovery phase is a useful diagnostic. If it is twelve weeks, the engagement is structured around the consultant's needs, not the work. If it is days and produces a continuously updated map that the automation operates against, the engagement is structured around the work. The shorter timeline is not a sales claim. It is a property of the technology, available to anyone who builds the engagement model around the technology rather than around the legacy P&L.