Your Team Didn't Fail the ERP — The ERP Failed Your Team

When an operations team is running three master spreadsheets alongside an active ERP, the instinct is to treat this as a discipline problem. Someone didn't enforce the system. Someone built a workaround and others followed. The files multiplied. Now there's a parallel infrastructure that nobody officially sanctioned and everyone actually uses.

That diagnosis feels right. It's also almost always wrong.

Spreadsheets Don't Lie About What the System Can't Do

A workaround spreadsheet is not random. It does something specific — something the ERP either can't do, can't do fast enough, or can't do without producing an output that requires manual correction before anyone will trust it.

The person who built it wasn't being undisciplined. They had a job to do and found the shortest path that worked.

This is worth taking seriously as a diagnostic signal.

In practice, the spreadsheets that survive and proliferate aren't convenience tools. They're load-bearing. They handle edge cases the ERP's data model doesn't accommodate, produce reports the ERP can't generate cleanly, or bridge two systems the ERP was never configured to connect.

If the file disappeared tomorrow, something would break — not because the team is addicted to Excel, but because the file is doing real work.

The question isn't why the team keeps using spreadsheets. The question is what the spreadsheets are doing that the ERP isn't.

Every Workaround Is a Documented Requirement

This is the reframe that changes how the spreadsheet conversation lands with leadership n- each workaround file is a specification. It describes, in precise and functional terms, a business process that needs software support and doesn't currently have it.

The pricing adjustment sheet that reconciles contract tiers against the ERP's flat rate logic? That's a pricing engine requirement.

The fulfillment tracker that accounts for regional lead times the ERP treats as uniform? That's a logistics configuration requirement.

The revenue recognition file that reorders recognized amounts because the ERP's period logic doesn't match the contract structure? That's a GL requirement.

None of these represent team failure. They represent a gap between the complexity of the actual business and the assumptions baked into the system the business is running on. The flagship article describes this gap directly — the point at which operational complexity has materially surpassed what rented software was designed to handle. The spreadsheets are where that gap becomes visible.

The strategic value of this reframe is practical. An operations director who can walk into a CFO conversation with a categorized inventory of workaround files — each one mapped to the process gap it's compensating for — is no longer presenting a discipline problem. They're presenting a requirements document. The logic already exists. The team has already built it. The question is whether to keep running it in Excel or formalize it in software that can enforce it reliably.

What the 40% Threshold Is Actually Measuring

The observation that a team spending roughly 40% of its operational bandwidth on workarounds has outgrown its stack isn't an arbitrary benchmark. It's a measurement of what percentage of the team's capacity is being consumed by compensating for the system rather than operating the business.

That number is hard to see in real time because the workarounds are distributed.

One analyst maintains the pricing file. Another owns the fulfillment tracker. A third produces the weekly revenue bridge. No individual is spending 40% of their week on spreadsheets — but collectively, the team is.

The overhead is invisible at the individual level and only becomes legible in aggregate.

What makes this threshold meaningful isn't the number itself — it's what it implies about trajectory.

A team at 20% workaround bandwidth has a system with gaps. A team at 40% has a system that is no longer the primary operational record. The ERP is processing transactions, but the decisions are being made from the spreadsheets. That inversion is what the threshold is trying to name. For teams who have arrived at this point because their ERP hasn't been updated in years, the Zombie ERP pattern describes the upstream cause — the spreadsheets proliferated because the system froze and stopped accommodating operational evolution.

How to Read the Spreadsheet Inventory Diagnostically

Not every workaround file carries the same signal. Some are genuinely about discipline — reports that the ERP can produce but someone ran manually once and never stopped.

These don't indicate system failure. They indicate process entropy, and they're worth cleaning up regardless of any larger evaluation.

The files that matter diagnostically share a set of characteristics. They're maintained by someone who understands the underlying business logic, not just the mechanics of the file. They're updated on a cadence that mirrors operational decisions — weekly, daily, or at close. They're referenced in meetings where real decisions get made. And crucially, they contain logic — formulas, lookups, conditional structures — that encodes a rule the ERP doesn't enforce.

When you find files that match this pattern, you're looking at the specification layer of a system that doesn't exist yet.

The business has already done the design work, informally, over months or years of adaptation. What hasn't happened is the translation of that design into software that can enforce it without human intervention.

That translation is what a well-scoped build project actually is — not a from-scratch invention, but a formalization of logic the team already understands and already runs.