The short answer
A company completes a major ERP rollout. Months of configuration, data migration, testing and training. The system goes live and performs correctly.
The week after, the same company starts mapping its own processes by hand.
That sequence is common enough to be worth explaining, because it looks like a failure of the implementation and it is not. The system is doing exactly what a system of record does: it records transactions with precision, enforces the rules it was configured with, and produces a complete account of everything that passed through it.
What it does not hold is an account of how the work happens around it. The system logs that a purchase order was approved. It has no record of the three people who exchanged messages to decide whether it should be, the spreadsheet one of them checked first, or the second approval that happens informally before the formal one is submitted.
Transactional completeness and process visibility are different properties. An organization can have the first in full and none of the second, and most organizations with mature systems are in exactly that position.
Key takeaways
- A system of record captures transactions. It does not capture the coordination that produces them.
- Rules that are configured are enforced and visible. Rules that live in judgment are invisible.
- Every system limitation generates compensating work, and the compensation happens outside the system by construction.
- More system coverage narrows the gap and does not close it, because the gap is made of what systems do not record.
- The question an ERP cannot answer is why a step exists, which is the question that determines whether it should.
- Establishing the operating picture is a separate exercise from implementing the system, and it is usually not scoped as one.
What the system records with precision
Worth stating clearly, because the argument is about scope rather than about quality.
A well-implemented ERP holds a reliable account of transactions, master data, configured approval thresholds, status at defined stages, timestamps, and the identity of whoever executed each recorded action. For questions about what was processed, when, by whom and against which rule, it is the most reliable source in the organization.
That scope covers a substantial share of what finance, procurement and operations teams need day to day. The limitation appears when the question changes from what was processed to how the work gets done.
What sits outside the record
| Layer | Example | Why the system misses it |
|---|---|---|
| Coordination | Messages exchanged to resolve a case before it is entered | Happens in a different medium entirely |
| Informal approval | A sign-off sought before the formal request is raised | Produces no transaction |
| Compensating work | A spreadsheet reconciling two systems that disagree | Exists because the systems do not connect |
| Judgment | Why an exception was resolved one way rather than another | The outcome is recorded, the reasoning is not |
| Preparation | Information assembled from elsewhere before a record can be created | Precedes the transaction |
| Rework | A case corrected and resubmitted | May appear as two clean transactions |
| Waiting | Time a case spends pending someone's attention | Visible as elapsed time, with no cause attached |
The bottom four rows are where most operational cost accumulates in mature system landscapes, and all four are invisible by construction.
Why implementation makes the gap more visible
There is a specific reason this surfaces right after a major rollout.
Before the implementation, the organization had a mix of systems and manual work, and nobody expected a complete picture. After the implementation, leadership reasonably expects that a system holding every transaction can answer operational questions. The first time someone asks how a process actually runs and the answer requires a manual exercise, the gap becomes explicit.
A second factor compounds it. Implementations frequently configure the process as designed, which means the exception paths that existed before are now handled outside the new system rather than inside it. The compensating work did not disappear. It moved, and in moving it became less visible than it was.
Why more instrumentation does not close it
The intuitive response is more coverage: connect the remaining systems, extend the configuration, add logging.
That narrows the gap and leaves its shape unchanged, for a structural reason. The categories listed above are not work that happens to be unrecorded. They are work that exists because of what systems cannot do.
A reconciliation spreadsheet exists because two systems disagree. Integrating them removes that specific spreadsheet. The next integration gap produces the next one.
An informal approval exists because the formal path is slow enough that people seek assurance first. Configuring the approval does not change the speed.
Judgment exists because some cases require it. No configuration converts judgment into a rule without removing the judgment.
Each round of instrumentation captures more of the previous generation of compensating work while the current generation forms around the new limitations.
System and work
Two pictures of the same operation
| System of record | Operating picture | |
|---|---|---|
| Answers | What was processed, when, by whom | How the work gets done, and why |
| Source | Transactions and configuration | The people performing the work |
| Complete for | Anything that produced a record | Anything that did not |
| Refreshes | Continuously | When someone establishes it |
| Governs | Compliance, audit, reporting | Redesign, automation, capacity decisions |
An organization needs both. Having the first in full says nothing about whether it has the second.
The questions an ERP cannot answer
These five determine most operational decisions, and none of them is derivable from transaction data.
What proportion of volume follows the configured path? The system shows which transactions used which route. It does not show the cases that were resolved outside it before they entered, or the ones that required work the configuration did not anticipate.
Why does this step exist? The configuration records that an approval is required at a threshold. The reason for the threshold, and whether that reason still holds, exists in the memory of whoever set it.
Where does the time actually go? Elapsed time between stages is visible. Whether that time was spent working, waiting for a person, or chasing an input is not.
Which steps could be removed? This requires knowing why each one exists, which is the second question.
What breaks if we change this? Downstream dependencies that run through the system are traceable. Dependencies that run through a spreadsheet somebody maintains are not.
Every one of these is answerable, by asking the people who perform the work. None is answerable from the record.
How to establish the operating picture after an implementation
1. Scope it to the processes that matter
A complete map of the organization is a larger exercise than most teams need. Start with the processes where a decision is pending: an automation candidate, a capacity question, a function reporting friction.
2. Ask the people who handle the exceptions
Process owners describe the configured process accurately, which is already documented. The operating picture lives with the people who deal with the cases the configuration did not anticipate.
3. Collect the artifacts
Ask directly about spreadsheets, trackers and shared documents maintained outside the system. Each one points to a specific gap, and the list is usually longer than the organization expects.
4. Quantify the compensation
For each artifact and each manual step, establish how much time it consumes and how often. This converts a list of annoyances into a ranked set of findings.
5. Separate the three kinds of manual work
Required by regulation, required because the consequence is irreversible, and created by a system limitation. The third is the recoverable portion and it is frequently described as one of the first two by people who inherited the step.
6. Compare across teams and markets
Where the same process runs in several places, divergence points to a cause. One market taking materially longer on the same work usually has a specific fixable reason.
7. Decide the disposition before the tooling
Remove, integrate, standardize or automate. Reaching for the configuration first produces automation of steps that should have been eliminated.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. It produces the operating picture that sits alongside the system of record.
Discovery Cycles run AI-led interviews across the roles that operate a process, adapting to each role and following up on why a step exists rather than recording only that it does. The Process Library structures the result into navigable documentation built from practice. The Insights Dashboard ranks findings by impact and effort with traceability to the input behind each one, and the Initiatives Dashboard converts priorities into business cases with owners.
Mercado Libre, the leading e-commerce and fintech ecosystem in Latin America, operating in 18 countries with more than 84,000 employees, is a useful illustration because the system landscape was extensive and the operating picture was still missing.
The company ran a fragmented estate spanning SAP, ARIBA, PIC, CLM, Jira, BigQuery, Tableau, Apache and Bypass. Its manual discovery model meant months of interviews covering under 1% of the workforce, requiring more than 100 coordination hours per initiative. It was carrying over 600 initiatives, many overlapping or misaligned, under a headcount freeze with 60 to 70 roles unfilled and more than 500 contractors covering manual work.
Horizon interviewed 2,000 employees in four days across Finance and related functions, reaching 100% of the targeted areas in five countries. The relevant mechanism is what happened next: transcripts were fused with data from SAP, ARIBA, PIC, BigQuery and Tableau to expose value gaps.
That combination is the point. System data established what was processed. The conversations established what happened around it. Setting the two against each other is what revealed where value was leaking, which neither source produces alone.
The engagement delivered 24 initiatives with ROI, effort and roadmap attached, $2.3M in projected annual savings from 12,000 to 13,000 hours automated, and 76 FTE equivalents avoided, with first implementations live in under a week. Contract cycles moved from 7 to 45 days down to under 10, and vendor onboarding from 30 to 45 days down to 7 or 8.
That is one engagement under specific conditions rather than a projection for any organization.
Post-implementation checklist
- Can your system answer what proportion of volume follows the configured path?
- Do you know which spreadsheets and trackers your teams maintain outside it?
- For each manual step, do you know why it exists and whether the reason still holds?
- Do you know the split between time spent working and time spent waiting?
- Did the implementation move exception handling outside the system?
- Can you compare how the same process runs across markets or business units?
- For your largest compensating artifact, do you know how many hours per week it consumes?
- Is there a plan to establish the operating picture, and is it scoped separately from the implementation?
- Who in the organization could answer question 1 today?
Common mistakes
Treating the gap as an implementation defect. The system is performing its function. Process visibility was never in scope.
Expecting the next integration to close it. Each round captures the previous generation of compensating work while the next forms.
Deriving current state from the configuration. It describes the process as designed, which is the version already documented.
Asking process owners only. They describe the configured process accurately. The operating picture is with the exception handlers.
Automating from the system view. Produces automation of the configured path, which is typically the part already working.
Postponing the exercise until the next programme. The compensating work compounds, and each month adds adaptations nobody records.
FAQ
Why can't an ERP tell you how work actually happens?
Because it records transactions and the configuration that governs them. The coordination that produces a transaction, the informal approval sought beforehand, the spreadsheet that bridges two systems, and the reasoning behind an exception all happen outside it and produce no record.
What is the difference between a system of record and an operating picture?
A system of record answers what was processed, when and by whom, and it is authoritative for that. An operating picture answers how the work gets done and why, including the steps that happen outside every system. The first is produced continuously by the software; the second has to be established deliberately.
Will connecting more systems solve the problem?
It narrows the gap without changing its shape. Compensating work exists because of what systems cannot do, so each integration removes a specific instance and the next limitation produces the next one. Judgment, informal coordination and preparation sit outside any configuration.
Why do companies map processes by hand after an ERP go-live?
Because the first operational question that requires knowing how work happens reveals that the system holds a different kind of information. Implementations also tend to configure the process as designed, which pushes exception handling outside the new system, where it is less visible than before.
What should you do after a major system implementation?
Establish the operating picture for the processes where a decision is pending. Ask the people handling exceptions, collect the artifacts maintained outside the system, quantify the time each consumes, separate required manual work from compensation, and decide the disposition before reaching for configuration or automation.
Can system data and employee evidence be combined?
Yes, and the combination is more useful than either alone. System data establishes volumes, timings and variants with precision. Employee evidence establishes cause, exceptions and the work that produced no record. Setting the two against each other is what exposes where value is leaking.
A complete record is a different thing from a clear picture
A mature system landscape gives an organization an accurate account of everything that passed through it, which is a real achievement and a necessary one.
The questions that drive operational decisions, about which step to remove, where capacity actually goes and what should be automated, depend on a picture of the work that happens between the records.
See it. Fix it. Own it.