The Documented Process Is Not the Real Process

The Documented Process Is Not the Real Process

Ask a company what step one of a process is and you will almost always get a clean answer: an email arrives. Ask the person who actually opens that inbox and the answer gets longer. Forty different senders, no two formatted the same way, half the payload buried in PDF attachments, and a routing decision for the ambiguous ones that lives entirely in one person's head, built up over years and never written down anywhere. Build the automation against the first answer and you have built it against a process that does not exist.

That last line is the one worth sitting with. It is not exceptions in general that hurt a process. Processes handle known exceptions constantly, and handle them fine, because someone already thought to build a path for them. It is the exception nobody wrote down that causes the damage, precisely because nothing in the system is prepared for it. An automation project inherits that same vulnerability, at scale, the moment it goes live on a process that was mapped from a conversation instead of from the work itself.

Why the Interview Gets the Wrong Answer, Reliably

This is not a documentation failure that better documentation would fix. It is structural. A manager describes the policy, because the policy is what they are accountable for and what they can articulate cleanly in an hour-long workshop. The person doing the work every day knows the policy too, but they also know the two dozen ways real inputs fail to match it, and the informal adjustments that quietly keep the process functioning despite that. Academic research on this gap calls the second category workarounds: goal-directed deviations that process participants perform to get past an obstacle the documented process does not account for. A 2025 study in Business & Information Systems Engineering found that event data from real process execution frequently does not match the documented model precisely because of this pattern, and that the mismatch is not noise to be cleaned up. It is where the actual process lives.

Nobody is lying in the workshop. The manager's answer is true of the policy. It is simply not true of the work, and the gap between the two is invisible until someone sits with the process long enough to see where reality quietly diverges from the org chart's version of events.

Why Process Mining Doesn't Close This Gap Alone

Process mining, the discipline of reconstructing how a process actually ran from system-generated event logs rather than from interviews, is a genuine advance on the workshop, and it is worth using wherever the work already leaves a clean digital trail. Conformance checking, its core technique, compares the documented "to-be" model against the "as-is" execution recorded in the logs and surfaces every point where they diverge.

The limitation is upstream of the technique rather than in it. Process mining can only reconstruct what a system logged. Most of what breaks a first automation attempt happens before anything touches a system at all: a phone call, a judgment call made reading a PDF, an exception routed by instinct rather than by a documented rule. A log cannot show you a decision that never generated a log entry. That is the gap that gets closed by a person watching the actual work, not by a better dashboard on top of the work that was already instrumented.

What Discovery Actually Produces

This is the argument for treating discovery as a distinct, paid phase rather than a courtesy call before the "real" work starts. A five-day mapping sprint, spent alongside the people who do the job rather than interviewing the people who manage them, produces an Exception Ledger: every real deviation from the documented process, captured against the specific moment and the specific person, rather than reconstructed weeks later from memory in a workshop.

That ledger is what makes a fixed-price build quote a real number instead of a guess wearing a decimal point. Scope a build against the documented process and the fixed price is fixed against fiction: the system encounters the undocumented exception on day one in production instead of during discovery, at exactly the point the research above shows the damage is worst, because nothing in the build was prepared for it. Scope it against the Exception Ledger instead, and the price reflects the process that will actually run through the system, not the version of it that fit cleanly on a whiteboard.

The Test for Whether You Need This

Not every process needs a five-day sprint. The signal that one does is simple: ask the person who owns the process what happens in the case that does not fit the pattern, and watch whether the answer is a documented rule or a shrug followed by "we just handle it." If the honest answer is the second one, the documented process and the real process have already diverged, and building automation before closing that gap means discovering the divergence in production, at the point where it is expensive to fix rather than cheap to note down.

This is also the reason the risk sits on us rather than on you at this stage. If the mapping sprint surfaces nothing you did not already know, you do not pay for it. That is not a marketing line, it is the actual test of whether the discovery earned its cost, and it is why the artifact matters more than the exercise: the point is not to have done discovery, it is to walk away with a ledger you could not have produced any other way. For how that ledger fits the rest of the engagement, see how to buy AI delivery that actually ships, and for what the build looks like once the process is actually known, see why most of the resulting system should not be AI at all.

Sources & References