Ask three people in a large organization how a process works and you get three answers.
Leadership describes the process as designed: the sequence that was agreed, the controls that were approved, the handoffs the operating model specifies. Management describes the process as reported: what the status updates say, what the dashboard shows, what gets escalated. The people performing the work describe the process as run: the actual sequence, including the step added two years ago for a case the design never anticipated.
All three accounts are accurate within their own frame. None of them is the process.
This shows up most clearly in well-run organizations, which is the part that surprises people. In a company with weak management the divergence would be a symptom of something going wrong. In a company with strong management it is structural: each level has a different vantage point, each vantage point is partial, and nothing in the organization is designed to reconcile them.
The consequence is practical. Any decision that depends on knowing how work currently happens is being made from one of the three versions, and usually from the one furthest from the work.
Key takeaways
- Three versions of every process coexist: as designed, as reported, and as performed.
- Each account is accurate from its own position, which is why everyone involved is confident.
- Divergence grows with organizational distance and with time since the process was last reviewed.
- Reporting systems compress the performed process into categories the design anticipated, which hides the exceptions.
- Decisions made from the designed version tend to address steps that were already working.
- Reconciling the three requires collecting from all levels at once, since asking sequentially produces accounts that cannot be compared.
Why the three versions form
The design anticipates fewer cases than reality produces
A process is specified for the cases visible when it is written. Over the following years the business encounters cases the specification did not cover: a new market with a different tax treatment, a customer segment with a contractual exception, a system that was replaced and handles one field differently.
Each new case is handled by someone improvising a response. The improvisation works, it repeats, and it becomes part of how the work gets done. The specification stays as written, because updating it is nobody's task and because changing an approved process requires an approval of its own.
Reporting compresses what it was built to measure
Status systems record progress against defined stages. That is what makes them useful and it is also what makes them incomplete.
When a case takes an unusual path, the reporting system records the stage it reached, not the detour it took to get there. When a step is performed outside the system, no record exists at all. Management sees a process that moves through the expected stages at a measurable pace, which is a true description of the part the system can see.
Distance compounds the difference
The further someone sits from the execution, the more their picture depends on summaries. Each summary removes the exceptions, because exceptions are hard to summarize and because the person producing the summary reasonably assumes the detail will not be useful.
By the time a description reaches an executive it has passed through several compressions. What survives is the shape of the process. What is removed is everything that makes it expensive.
Nobody is positioned to notice
The structural part is that no role in a conventional organization sees all three versions.
The operator knows their own version and has no visibility into how other teams run the same process. The manager sees reports from several teams and does not see what each team actually does. The executive sees the design and the aggregate numbers.
Divergence is detectable only from a position that collects all three at once, and most organizations have no such position.
Three versions
What each level can see
| Version | Held by | Built from | Systematically missing |
|---|---|---|---|
| Intended | Leadership, process owners | Design documents, operating model | Every adaptation made since the design |
| Reported | Management | Status systems, dashboards, escalations | Work performed outside the system, exception paths |
| Real | The people performing the work | Daily practice | Visibility into how other teams run the same process |
Each version is accurate within its frame. The cost of the process concentrates in what the first two cannot see.
Where the gap produces decisions that fail
Automation scoped against the intended version. The build addresses the designed sequence, which is typically the part already running smoothly. The exception path continues to consume the same effort, and the business metric does not move.
Headcount approved against the reported version. The queue is visible, the backlog is real, and nobody established what the additional people would spend their time on. Frequently a substantial share of the work is compensation for a gap that more capacity would absorb rather than remove.
System selection against the intended version. Requirements are derived from how the process is supposed to run. The gaps surface during user acceptance testing, when the timeline has no room left.
Improvement programmes that optimize an accurate description of the wrong thing. The analysis is rigorous, the recommendations follow from it, and the whole exercise rests on a current-state picture assembled from the design.
In each case the work was competent. The input was one version of three.
Why asking does not resolve it by itself
The obvious response is to ask the people doing the work. That is correct and it is harder than it sounds, for three reasons.
The word "process" retrieves the intended version. Asked to describe their process, most people describe the official one, because that is what the term means. The spreadsheet they maintain is not a process in their mind. It is what they do to get the work done.
Describing an adaptation can feel like admitting a deviation. If the framing suggests the exercise checks compliance, people describe the version they are supposed to follow. The framing has to be about difficulty for the answers to be about practice.
One person's version is still one version. The real process varies across teams and markets. An interview with a single operator produces a third account to add to the other two, with no way to tell which parts generalize.
Resolving the divergence requires collecting from across the population, in a form that allows comparison, with questions aimed at difficulty rather than at adherence.
The questions that retrieve the performed version
| Question | What it surfaces |
|---|---|
| Walk me through the last case you handled | The actual sequence, with its exception |
| What happens when the standard path does not work | The exception distribution |
| Which spreadsheets or trackers do you maintain | Work happening outside every system |
| Who do you go to when something is stuck | The informal routing map |
| What did this look like two years ago | Adaptations the documentation never absorbed |
| What would you warn a new person about | The parts that are hard and undocumented |
None of these contains the word process, which is the point.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. The divergence described above is the specific condition it was built to resolve.
Discovery Cycles run AI-led interviews across every level and function that touches a process, asynchronously and at the same time. Collecting simultaneously is what makes the three versions comparable: leadership's account, management's account and the operator's account arrive in a form that can be set against each other rather than sequentially, where each is interpreted through whatever came before.
The Insights Dashboard groups findings by process and cause rather than by who reported them, so a pattern appearing in one team and again in three others becomes a systemic finding. The Process Library structures the result into documentation built from practice, and the Initiatives Dashboard converts priorities into business cases with owners.
Grupo HZ, a multi-company industrial holding with more than 65 years in packaging and paperboard, operating across Argentina, Brazil and Chile with a shared services centre covering Administration, Finance, Procurement and Treasury, shows what the gap costs when it goes unreconciled.
Spreadsheets, email and manual validations were the backbone of critical processes, with no integrated workflows. There was no visibility into where time was being lost or which processes carried the highest automation potential. Pricing errors in the core system went undetected without manual cross-checks, creating downstream issues in billing and auditing.
Horizon ran 55 structured interviews across six departments asynchronously. The engagement identified 33 actionable findings and quantified the time impact of each inefficiency down to the hour, per area: Procurement at 48.3 hours per week, Accounts Payable at 34, Treasury at 21.55, Credit and Collections at 10.5, Sales and Commercial in Chile at 6.5, and Planning and Costing at 2.9. Roughly 123 hours per week in total.
The documented outcome was a change in how leadership framed the problem, moving from a view that the operation needed more people to a view that it needed better processes, and freeing around three FTEs for strategic work without adding headcount. The engagement returned 182% ROI and saved 159 discovery hours against the manual approach.
That shift is the three versions being reconciled. Leadership held the intended version, in which the work was necessary and the constraint was capacity. The performed version contained 123 hours per week of repetitive manual work that nobody had quantified.
That is one engagement under specific conditions rather than a projection for any organization.
Diagnostic checklist
- For your three most important processes, when was the design last updated?
- Can you state what proportion of volume follows the documented path?
- Have you asked an operator and a process owner the same question and compared the answers?
- Does your reporting distinguish cases that followed the standard path from cases that did not?
- Do you know which steps happen outside every system of record?
- Does any role in your organization see all three versions?
- When a decision depends on the current state, which version is it using?
- Have you compared how the same process runs across teams or markets?
- Who would notice if the design and the practice diverged further?
Question 6 is the structural one. In most organizations the honest answer is nobody, and that is the condition that allows the gap to persist.
Common mistakes
Treating divergence as a management failure. It appears in well-run organizations, because it comes from vantage points rather than from discipline.
Resolving it with a documentation project. Documentation records intent. Rewriting it more carefully produces a better version of the intended process.
Asking one operator and treating it as the real version. It is a third account, with no way to tell what generalizes.
Using the word process in the question. It retrieves the official answer.
Collecting sequentially. Accounts gathered weeks apart by different people cannot be compared reliably.
Reconciling once. The three versions diverge continuously, so a single reconciliation describes a moment.
FAQ
Why do people in the same company describe a process differently?
Because each level sees a different version. Leadership holds the process as designed, management sees the process as reported through status systems, and the people performing the work know the process as run, including the adaptations made for cases the design never anticipated. Each account is accurate from its own position.
What is the gap between documented and actual processes?
It is the accumulation of adaptations made after the documentation was written: steps added for new cases, workarounds for system limitations, informal approvals, and local variations by market or team. The gap grows with time since the last review and with the number of changes to systems, policy and team structure.
Why does reporting miss how work actually happens?
Status systems record progress against stages the design anticipated. When a case takes an unusual path, the system records the stage reached rather than the detour. When a step happens outside any system, no record exists. The reporting is accurate about the part it can observe.
How do you find out how a process really runs?
Ask about the last specific case rather than the general process, ask what happens when the standard path fails, ask which spreadsheets and trackers people maintain, and ask who they go to when something is stuck. Collect across levels and teams at the same time so the accounts can be compared.
Does this happen in well-managed organizations?
Frequently, and more visibly than in poorly managed ones. The divergence comes from the structure of vantage points rather than from weak management. No conventional role sees all three versions, so nothing in the organization is positioned to notice the gap widening.
The company is the hardest place to see clearly
Every large organization contains three accounts of how it works, held by people who are each describing what they can see.
The decisions that matter, about what to automate, where to add capacity, and which system to replace, depend on a fourth thing: the version nobody holds, which is the one assembled from all of them.
See it. Fix it. Lead it.