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 is supposed to happen. Far fewer start with evidence of how it actually happens. The 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 examines 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 investments stall at mid-level maturity.
The Gap Between Written and Real
Every organization has process documentation. Flowcharts, RACI matrices, SOP libraries, ERP configuration guides. Most of it was created in conference rooms by people describing how the process should work, or how it worked when the last system was implemented, often several years and several reorganizations ago.
The gap between documented and actual begins at the moment of writing. Process documentation captures intent. It describes what the process is supposed to do and how it was designed to work. What it often fails to capture is how work actually happens today.
Processes accumulate workarounds. Documentation does not. A step that once relied on a system that no longer exists gets replaced by a spreadsheet sent every Friday. An approval that takes too long is quietly bypassed for orders below a threshold. A handoff between procurement and finance that no one clearly owns is handled differently depending on who is available. These adaptations are rational. They solve immediate problems. But they do not make their way back into the documentation. Over time, the gap between what is written and what is done continues to widen.
Process variation across organizational units amplifies the problem. Most large organizations maintain a single documented version of their core processes. In reality, Procure-to-Pay in a Nordic business unit operates differently from Procure-to-Pay in Central Europe. Approval thresholds differ. Supplier onboarding steps differ. Goods receipt practices differ. Each variant has evolved locally to fit specific systems, management preferences, or legacy practices from acquisitions that were never fully integrated. Some of this is documented locally. Very little is consolidated into a shared view. All of it shapes how governance, KPIs, and improvement initiatives actually play out.
Process improvement investments are typically built on this incomplete picture. Organizations start from the official version of the documentation. They design governance structures, appoint process owners, and define KPI frameworks on top of a description that only partially reflects reality. The governance is real. The foundation beneath it is not.
Process owner effectiveness depends directly on the quality of the picture they operate from. A process owner with end-to-end visibility of the documented process sees an assumption, not the actual flow of work, the real handoffs, or the points where performance breaks down. The data needed to act often exists in underlying systems. What is missing is the correct frame for interpreting it.
Effective governance at any maturity level depends on an accurate as-is baseline. Without it, governance investments may be structurally sound but operationally misaligned. Level 3 governance built on a Level 1 understanding of reality will behave closer to Level 1 than to Level 3. Not because the governance model is flawed, but because it is applied to an incomplete representation of the process.
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 is supposed to happen, not how systems are configured to support it, but how people in the organization 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 outcome is a recreation of existing documentation, where participants describe the process as they believe it should work. The second is a cleaned-up version of reality, a map that captures formal steps while omitting the workarounds, exceptions, and informal fixes that shape most transactions.
Neither provides a reliable foundation for improvement. Both reproduce the same incomplete picture.
Effective as-is mapping requires three elements that most organizations underinvest in.
First, observation and data before interviews. Pull transaction data before any mapping session. How many purchase orders have a corresponding requisition? How many invoices require manual intervention? What is the average end-to-end cycle time? Then observe how work is done, or analyze the data trail left by transactions through process mining. The data shows where to look. Interviews explain why. Without this grounding, people describe the process they believe they follow, not the one actually in operation.
Second, exception mapping alongside the main flow. In most processes, exceptions are not marginal. They represent a meaningful share of volume. In Procure-to-Pay, orders without requisitions are not rare; in some organizations they account for a significant share of spend. In Order-to-Cash, manual credit overrides, split invoicing, and early delivery confirmations are common. A process map that captures only the happy path reflects a minority of transactions.
Third, variant mapping across organizational units. A single process map captures one version of the process. In reality, the same process is executed differently across business units, geographies, or legal entities, each with distinct approval thresholds, system configurations, workarounds, and informal practices. These variants are not random. They reflect legacy structures, acquisitions, and local system choices. Mapping them is essential. A standardization effort that ignores existing variants will face resistance it cannot explain and deliver compliance it cannot sustain. Variants are not deviations to control. They are the reality that must be understood before it can be standardized.
The patterns below illustrate what this looks like 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 version.
The documented process is straightforward. Need identified. Purchase requisition created. Purchasing reviews and approves. Purchase order issued. Goods received. Invoice matched. Payment made. Clean, sequential, auditable.
The actual process, in many organizations, diverges at almost every step. Needs are identified, but requisitions are created after the fact, if at all, because operational pressure requires ordering before the approval cycle completes. Purchasing reviews activity, but often retrospectively. Purchase orders are issued, but frequently after a verbal commitment has already been made. Goods receipt is confirmed, sometimes before physical delivery, to keep invoice processing moving. Invoice matching fails more often than the documented flow assumes, requiring manual intervention that is absent from the process map.
These workarounds are not random. Each exists because the formal process introduces a bottleneck that operations cannot absorb. Requisition requirements slow ordering. Approval cycles do not match operational timelines. Goods receipt confirmation is tied to system requirements that lag physical reality. Each workaround is locally rational. Together, they produce a process that appears controlled on paper but is not controlled in practice.
The problem is further compounded by variation. Workarounds are not applied consistently. One business unit develops one set of adaptations. Another develops a different set. When a process owner is assigned to govern Procure-to-Pay at organizational level, they are not managing a single process with deviations. They are managing multiple distinct variants that share a name and a high-level map but differ materially in execution.
Standardization, the transition to a genuine Level 3, depends on making those variants visible. Many as-is mapping efforts do not.
Order-to-Cash follows the same structural pattern, with different points of divergence. 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 prevent meaningful comparison of performance across units and make it difficult to identify which variant produces the best outcomes.
Record-to-Report is structurally the most complex of the three, and the one where variation is least visible from the center.
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 is straightforward. Transactions posted. Period-end close activities performed. Consolidation completed. Financial statements prepared, reviewed, and approved. Disclosed. Each step has an owner, a timeline, and a supporting system.
The actual process tells a different story. Journal entries are posted after the nominal close. Manual adjustments appear at consolidation, often for issues that should have been resolved at entity level. Restatements surface during audit preparation and require reopening periods that were already reported as closed.
Close cycle time is tracked as a single aggregated metric. The distribution of effort within that cycle is rarely visible. Which entities consistently run late? Which account types generate the highest volume of manual adjustments? At what point in the process does data quality break down?
In many organizations, these questions cannot be answered at group level. The data exists in the ERP, but it is not analyzed as a process flow. It is reviewed as a set of accounting outcomes.
The variation dimension is particularly pronounced in Record-to-Report. In multi-entity organizations, each business unit operates with its own close calendar, account structure conventions, and judgment on accruals and provisions. Group accounting policies are interpreted locally. Group finance sees the consolidated result. It rarely sees the process variation that produced it.
When close quality deteriorates, the symptoms are visible in late submissions, restatements, and audit findings. The root cause is not. Identifying it requires as-is mapping at the entity level, with enough detail to expose where and how the process diverges.
That diagnostic capability is what determines whether an organization can move beyond its current maturity level.
Why This Matters for Maturity
Most organizations meet the documentation requirement associated with Level 2. Fewer achieve consistency in execution. The documentation describes the intended process, not the actual one. Repeatability requires more than a process map. It requires that the map reflects how work is truly performed.
Documentation that describes intent creates governance that is formally correct but operationally misaligned. When used as the basis for training and system configuration, it embeds assumptions rather than reality. People follow the workarounds because they are effective. The formal process is not.
This creates a specific trap at Level 3. An organization can establish the visible elements of Level 3, process owners, documented processes, a center of excellence, a BPM framework, while the underlying transactional reality remains closer to Level 1. The governance structures are in place. The foundation they rely on only partially reflects how the process actually runs.
Moving from Level 2 to Level 3 requires more than documentation. It requires standardization, with processes executed consistently, in the documented way, across the organization. Standardizing an incorrect as-is baseline produces a consistent description, not a consistent process. The workarounds remain. They are simply no longer visible in the official version.
Genuine as-is mapping removes this barrier. It makes the gap between documented and actual visible and creates the foundation for every subsequent step in process improvement. Gap analysis against best practice, process hierarchy design, automation sequencing, and interpretation of process mining all depend on an accurate picture of what is happening in practice.
An accurate as-is baseline is a primary enabler of effective governance. It is also one of the most commonly skipped steps. Organizations that invest in it gain something that no governance framework, process owner appointment, or KPI redesign can replace: a shared, evidence-based understanding of the process they are actually trying to improve.
What This Means Before Your Next Transformation Investment
Before launching any process improvement initiative, whether a new governance structure, system implementation, best practice adoption, or automation program, a more fundamental question comes first.
Are you working from an accurate picture of how work actually happens today?
Three questions determine this:
Was the current process documentation produced through observation and transaction data analysis, or through workshop reconstruction?
Does the documentation explicitly map exceptions and workarounds alongside the main flow, or does it show only the intended happy path?
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 the frequency of manual overrides?
If the answer to any of these is no, the as-is baseline is incomplete. Governance investments built on an incomplete baseline will improve the description, not the process. The limitation is not the governance design. It is the picture it is built on.
#BPM #ProcessManagement #BusinessTransformation #ProcessImprovement #OperationalExcellence #ProcessMining #P2P #R2R #KaldLabs