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 Big-4 process discovery for a single back-office function 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. Gartner's 2019 Market Guide for Process Mining opens by calling traditional process discovery "costly and time-consuming, because of gaps in business knowledge, a lack of objective validation techniques and poor formalisms," and the structure of the exercise is why: interviews have to be scheduled around the practitioners' actual jobs, workshop outputs have to be reconciled against each other, and weeks pass before a diagram exists. 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
The map is built from what people say they do rather than 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 rationalized 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. Gartner's guide describes the same gap from the systems side: the formal procedures baked into enterprise applications are "often compromised by informal behavior that bypasses governance."
The map 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.
The map decays. 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, and a new practitioner has joined the team and brought their own workarounds. The IEEE Task Force on Process Mining made this point in its 2011 Process Mining Manifesto: few processes are in steady state, processes change while they are being analyzed, and "the goal should not be to create a fixed model." 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 2011 manifesto called maps that behave this way "living process models."
Discovery collapses from weeks of interviews to days of observation. 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. The work no longer hands off to an offshore delivery center, and no consultant interprets the diagram for an engineer, so the lag between phases goes away. The engagement compresses end to end, and the consulting model that sold discovery as its own billable phase can't survive that compression.
A reasonable counter is that the consultant interview captures more than just clicks. The interview is how the consultant gets at intent as well as behavior, 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 merging them in a single interview.
What the discovery phase was for
The deeper implication is that the long discovery phase, as the consulting industry has structured it since the reengineering wave of the 1990s, did commercial work as much as analytical work. The map was the deliverable that proved the fee had been earned, so the phase that produced it had to be long enough and formal enough to carry the engagement's economics. A discipline that produces a better map from a few days of observation can't support that pricing, and once the map arrives in days, the phase that carried the economics has nothing left to bill. That is what 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 system that deploys the agents and the system that produces the diagnostic are converging into the same product, because they were never really separable. The engagement model separated them, and the technology never required it.
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 discovery is quoted in weeks and billed as its own phase, the engagement is structured around the consultant's economics. If it runs in days and produces a continuously updated map that the automation operates against, the engagement is structured around the work. The shorter timeline is a property of the technology rather than a sales claim, and it is available to anyone willing to build the engagement model around the technology instead of around the legacy P&L.