The Process You Think You Have
Why the process on paper is rarely the process in practice
Many process improvement programs begin with documentation that describes how work should happen. Rarely with evidence of how it actually does. That gap, between the assumed process and the real one, is one of the most common and least acknowledged barriers to effective process governance.
This article is about what as-is mapping actually requires, why most organizations underinvest in it, and what it enables when done well. It is part of a series on why BPM investment stalls at mid-level maturity.
The Gap Between Written and Real
Every organization has process documentation. Flow charts, RACI matrices, SOP libraries, ERP configuration guides. Most of it was written in a conference room by people describing how the process should work, or how it worked when the last system was implemented, several years and several reorganizations ago.
The gap between documented and actual begins at the moment of writing. Process documentation describes an intention: what the process should do, how it was designed to work. What it often fails to describe is how work actually happens today.
Processes accumulate workarounds. Documentation does not. A step that requires data from a decommissioned system gets replaced by a spreadsheet someone emails on Fridays. An approval that takes too long gets informally bypassed for orders below a certain threshold. A handoff between procurement and finance that nobody owns gets handled differently by whoever happens to be available. These adaptations are rational. They solve real problems. But they are invisible to the process documentation. Over time, the gap between what is written and what is done widens.
Process variation across organizational units compounds the workaround problem. Most large organizations have a single documented version of their core processes. In practice, P2P in the Nordic business unit operates differently from P2P in Central Europe. The approval thresholds differ. The supplier onboarding steps differ. The goods receipt confirmation practice differs. Each variant has evolved locally to fit local systems, local management preferences, or legacy practices from an acquisition that was never fully integrated. Much of this is at best locally or partially documented, and rarely consolidated into a single, shared view. All of it affects how governance, KPIs, and improvement initiatives actually land.
Process improvement investments are typically built on this incomplete picture. Organizations start from the single official version of the documentation. They design governance structures, appoint process owners, and build KPI frameworks on top of a description that does not accurately represent the variants actually in use. The governance is real. The foundation it rests on only partially reflects reality.
Process owner effectiveness depends directly on the quality of the picture they are working from. A process owner with end-to-end visibility of the documented process has visibility of an assumption, not of the actual flow of work, the actual handoffs, or the actual points where performance breaks down. The underlying data to act on is often there in the systems, but the frame for interpreting it is wrong.
The enabler of effective governance at every level is an accurate as-is baseline. Without it, governance investments are structurally sound but operationally misaligned. Level 3 governance built on Level 1 reality will tend to perform closer to Level 1 than Level 3. Not because the governance is wrong. Because it is governing an incomplete picture of the thing. What a complete picture requires is the subject of the next section.
What As-Is Mapping Actually Is
That complete picture is what as-is mapping is designed to produce. It is the discipline of documenting how work actually happens — not how it should happen, not how the system is configured to support it, but how people in the organization actually execute the process today.
It sounds straightforward. It is not.
The quality of as-is mapping varies significantly, and most organizations produce a version that is insufficient as a foundation for improvement. The most common output is a recreation of the existing documentation, because the people in the room describe the process as they understand it should work. The second most common is a cleaned-up version of reality: a map showing the formal steps while omitting the workarounds, exceptions, and informal fixes that constitute the majority of actual transactions.
Neither provides the foundation that effective process improvement requires. Both reproduce the same incomplete picture.
Genuine as-is mapping requires three things that most organizations underinvest in.
First, observation and data before interview. Pull the transaction data before any mapping session: how many purchase orders have a corresponding purchase requisition, how many invoices require manual intervention, what is the average cycle time end-to-end. Then watch how work is actually done, or analyze the data trail left by actual transactions through process mining. The data tells you where to look. The interview tells you why. Asking people how they do their work without this grounding produces the process they believe they follow, not the one that is running.
Second, exception mapping alongside the main flow. In most processes, exceptions are not edge cases. They represent a significant proportion of actual volume. In P2P, orders placed without purchase requisitions are not exceptions in the statistical sense; in some organizations they can represent a substantial share of spend, sometimes reported in the 20–40% range. In O2C, manual overrides of credit limits, split invoices, and delivery confirmations issued before goods receipt are commonplace. A process map that only shows the happy path is a map of a minority of transactions.
Third, variant mapping across organizational units. A single process map describes one version of the process. In practice, the same nominal process is often executed differently across business units, geographies, or legal entities, each with its own approval thresholds, system configurations, workarounds, and informal conventions. These variants are not random: they typically reflect legacy practices from previous organizational structures, acquisitions, or local system implementations. Mapping them is essential, because a standardization program that does not acknowledge the variants it is standardizing will encounter resistance it does not understand and produce compliance it cannot sustain. Variants are not exceptions to be managed. They are the reality to be standardized. The two patterns below show what this means in practice.
Figure 1: The As-Is Gap: Procure-to-Pay
The as-is gap illustrated in P2P — the same pattern of workarounds and variants appears in O2C, R2R, and most other end-to-end processes.
The Gap in Practice — Two Familiar Patterns
Consider what as-is mapping typically reveals in Procure-to-Pay, and how far the actual process diverges from the documented one.
The documented process shows: need identified → purchase requisition created → purchasing reviews and approves → purchase order issued to supplier → goods received → invoice matched → payment made. Clean, sequential, auditable.
The actual process, in many organizations, diverges at almost every step. Needs are identified, but purchase requisitions are created after the fact, if at all, because operational pressure requires ordering before the approval cycle completes. Purchasing reviews, but for a significant share of spend the review is retrospective. Purchase orders are issued, but frequently after verbal commitment has already been made to the supplier. Goods receipt is confirmed, but sometimes before physical receipt, to keep the invoice processing queue moving. Invoice matching fails at higher rates than the documented process assumes, requiring manual intervention that the process map does not account for.
The workarounds are not random. Each one exists because the formal process creates a bottleneck that operations cannot afford. The purchase requisition requirement slows ordering. The approval cycle does not fit the operational timeline. The goods receipt confirmation is a system requirement that lags physical reality. Each workaround is locally rational. Together they produce a process that looks controlled on paper and is not controlled in practice.
What makes the workaround problem harder to address is that the workarounds are not uniform. Business unit A has developed one set of adaptations; business unit B has developed another. When a process owner is appointed to govern P2P across the organization, they are not governing one process with some deviations. They are governing several distinct variants that share a name and a process map but diverge significantly in execution. Standardization, the move to genuine Level 3, requires first making those variants visible. Many as-is mapping exercises do not.
Order-to-Cash follows the same pattern with a different set of variants. Credit limit policies are interpreted differently across commercial teams. Revenue recognition timing varies between entities. Collection escalation procedures that are standardized centrally are adapted locally to preserve customer relationships. Each variant is defensible in isolation. Together they make it impossible to compare O2C performance across business units, or to identify which variant is producing the best outcomes.
Record-to-Report is structurally the most complex of the three, and the one where the variation dimension is hardest to see from the centre.
Figure 2: The As-Is Gap: Record-to-Report
The as-is gap in R2R — with an additional variant dimension that reflects differences in entity size, system maturity, and accounting policy interpretation across business units.
The documented process shows: transactions posted → period-end close activities → consolidation → financial statements prepared → reviewed and approved → disclosed. Each step has an owner, a timeline, and a system.
The actual process routinely involves late journal entries posted after the nominal close and manual adjustments at consolidation that should have been caught at entity level. Restatements surface during external audit preparation and require reopening periods already reported as closed. Close cycle time is managed as an aggregated metric. The distribution of effort within that cycle is rarely visible. Which entities are consistently late? Which account types generate the most manual adjustments? Where in the process is data quality actually breaking down?
In many organizations, the detailed answers simply are not visible at group level. The data exists in the ERP. It has not been looked at as a process flow rather than as a set of accounting outcomes.
The variation dimension is particularly acute in R2R. In a multi-entity organization, each business unit has its own close calendar, its own account structure conventions, its own judgment calls on accruals and provisions, and its own interpretation of group accounting policies. Group finance sees the consolidated result. It rarely sees the process variation that produced it. When close quality deteriorates, the symptom is visible in late submissions, restatements and audit findings, but the root cause requires as-is mapping at the entity level to diagnose accurately. That diagnostic capability is what determines whether an organization can advance beyond the maturity level it currently occupies.
Why This Matters for Maturity
Most organizations have the documentation that Level 2 requires. Fewer have the consistency. The documentation describes the intended process, not the actual one. Repeatable processes require more than a process map. They require that the process map reflects what is actually done.
Documentation written to describe the intended process creates governance that is formally correct and operationally misaligned. When used as the basis for training and system configuration, it embeds the assumption, not the reality. People follow the workarounds because the workarounds work. The formal process does not.
This creates a specific trap at Level 3. An organization can have all the governance infrastructure of Level 3 — process owners appointed, process maps in place, a center of excellence, a BPM framework — while the underlying transactional reality remains at Level 1. The governance structures are real, but they are grounded in a representation of the process that only partially reflects operational reality.
Advancing from Level 2 to Level 3 requires not just documentation but standardization: processes executed consistently, in the documented way, across the organization. Standardization on an incorrect as-is baseline produces a standardized description, not a standardized process. The workarounds remain. They are simply no longer visible in the official record.
Genuine as-is mapping is what removes this barrier. It makes the gap between documented and actual visible, and in doing so creates the foundation for every subsequent step in the improvement journey: gap analysis against best practice, process hierarchy design, automation sequencing, and process mining interpretation all depend on an accurate picture of what is actually happening.
An accurate as-is baseline is a primary enabler of effective governance. It is also the most commonly skipped step. Organizations that invest in it gain something no governance framework, no process owner appointment, and no KPI redesign can substitute for: a shared, evidence-based picture of the process they are actually trying to improve.
What This Means Before Your Next Transformation Investment
Before any process improvement initiative, whether a new governance structure, new system, best practice adoption, or automation program, the prior question is: are we working from an accurate picture of how work actually happens today?
Three questions determine this:
1. Was the current process documentation produced through observation and transaction data analysis, or through workshop reconstruction?
2. Does the process documentation explicitly map exceptions and workarounds alongside the main flow, or does it show only the intended happy path?
3. Does the organization have transaction-level data that quantifies the gap between documented and actual execution, such as the percentage of orders with purchase requisitions, first-time-right rates, and manual override frequency?
If the answer to any of these is no, the as-is baseline is incomplete. Governance investments made on an incomplete baseline will improve the description. Not the process. The barrier is not the governance design. It is the picture it is built on.
The next article examines what to do with an accurate as-is picture: how to identify best practice, how to conduct a gap analysis, and how to move from documented reality to a standardized process that the organization actually owns.
#BPM #ProcessManagement #BusinessTransformation #ProcessImprovement #OperationalExcellence #ProcessMining #P2P #R2R