The enterprise system is usually not the problem, and treating it as one leads to an expensive answer. It posts correctly, it closes the ledger, it holds the master data, and it does the standard part of the standard process about as well as anything else on the market would.
What it does not do is the part of your process that is specific to your company. The approval that has to go to a person who is not in the module's hierarchy. The exception that needs judgement before anything can be posted. The handoff between two legal entities that were separate companies eighteen months ago. The data that has to be assembled from three places before it is even eligible to be entered. None of that is a defect in the software. It is outside the scope the software was built for.
That work still has to happen, so it happens somewhere. It happens in a spreadsheet, a shared mailbox and a weekly meeting. Within a few months the spreadsheet has quietly become the system of record for that slice of the process, and two years later it surfaces in an audit as a deficiency.
The Twenty Percent Has A Recognisable Shape
Across finance and operations processes the work that falls outside the enterprise system tends to take five forms.
- Pre-system assembly. Data is collected, matched and cleaned before it is eligible to be entered. The module accepts a clean record and has no opinion about where it came from.
- Approvals that do not fit the hierarchy. The real approver depends on the customer, the contract, the amount and who is available, and the module supports a tree of managers.
- Exceptions requiring judgement. A small percentage of items do not match, and each one needs a person to decide. The module can flag them; it cannot hold them, assign them, or record how they were resolved.
- Cross-entity handoffs. A step starts in one entity's books and ends in another's. Two instances, two charts of accounts, and a person in the middle carrying the mapping.
- Post-system reconciliation. Something has to be compared to something else the module does not know about — a bank file, a partner statement, a clinical or operational system.
If you can name which of the five your painful process is, you have already scoped most of the work.
The enterprise system is the system of record for the ledger. Something else has become the system of record for the decision.
Why The Spreadsheet Wins Every Time
The spreadsheet does not win because anyone thinks it is a good answer. It wins because it is available on Tuesday and the alternative is a project.
Configuring or extending the enterprise system means an internal queue, an integration partner, a testing cycle and a change window. Research on enterprise resource planning implementation and its critical success factors (Umble, Haft & Umble, European Journal of Operational Research, 2003) documents how much organizational preparation these systems demand before they deliver, which is the same reason a small extension carries so much overhead. The point was made even earlier by the argument that an enterprise system imposes its own logic on the company (Davenport, Harvard Business Review, 1998): these packages encode a generic model of how the work should run, and the parts of your business that do not match that model are pushed to the edges.
The edges are where a person with a deadline puts a spreadsheet.
The scale of this is visible in public filings. Over the trailing twelve months, SEC full-text search returns 54 filings describing the implementation of a new enterprise resource planning system and 239 filings describing cost-savings initiatives. Those are filings rather than companies. A large share of the promised savings in that second group depends on process changes that live in exactly the twenty percent the first group's projects will not cover.
The Cost Arrives Twice
The first arrival is operational and everyone feels it. The step takes three days instead of three hours because it waits for a person, and it waits for a person because there is nowhere else for it to wait. Cycle time, overtime in the final week of the period, and a small number of people who cannot take holiday at month end.
The second arrival comes later and costs more. The slice of process that lives in a spreadsheet cannot demonstrate who performed it, in what order, with which version of the input — which is the argument in why a spreadsheet stops being a control the moment someone asks for the trail. At that point it stops being an operational annoyance and becomes a disclosure question. Work on market reactions to restatement announcements (Palmrose, Richardson & Scholz, Journal of Accounting and Economics, 2004) measured significantly negative announcement returns, with the reaction more severe where the restatement involved core operations or suggested a broader problem rather than an isolated one. Internal control weaknesses and information uncertainty (Beneish, Billings & Hodder, The Accounting Review, 2008) finds the same theme from a different angle: disclosed weaknesses raise the market's uncertainty about the numbers themselves.
Two arrivals, one root cause, and the second one is priced by people who never see the spreadsheet.
Build Around The System, Not Instead Of It
The instinct when the twenty percent hurts is to replace the eighty percent. That is the most expensive available response and it rarely addresses the actual gap, because the replacement package has its own generic model and its own edges.
The alternative is a thin workflow layer that owns the steps around the enterprise system and writes back through the interfaces the vendor supports. The division of responsibility is clean:
| Enterprise system | Workflow layer | |
|---|---|---|
| Owns | The ledger, master data, posting | The steps before and after posting |
| Holds | Transactions | Exceptions, approvals, mappings, evidence |
| Changes | On a release cycle | On a two-week cycle |
| Answers | What the balance is | Who decided, when, on what basis |
Three design rules keep this from becoming a second system nobody can retire. First, the enterprise system remains the system of record for anything financial; the workflow layer never holds a balance. Second, every integration goes through a supported interface, never a database write, so an upgrade does not silently break the process. Third, the evidence the workflow layer produces — who acted, when, on what version — is stored independently of both systems, so it survives a future migration.
Where language models are useful in this layer, they belong on the reading and drafting surfaces rather than in the execution path: extracting fields from a supplier document, proposing a match, drafting an explanation for a variance. The decision itself stays deterministic and recorded, which is the pattern described in keeping AI on the surfaces and the execution deterministic. A suggestion a named person accepts is auditable. A model that posts an entry is not.
First Steps
- Name which of the five shapes your worst process is. Pre-system assembly, approvals outside the hierarchy, exceptions needing judgement, cross-entity handoff, or post-system reconciliation. One sentence is enough.
- Count the touches, not the hours. For one cycle, write down every time the work stops and waits for a person to look at it. Waiting time, rather than working time, is usually most of the elapsed duration.
- Ask what would have to be true for the enterprise system to do it. If the answer is a configuration change already scheduled, wait for it. If the answer is a customization, an upgrade or a module you do not own, the work belongs beside the system rather than inside it.
One Workflow, Beside The System You Already Run
The useful scope here is almost always one workflow rather than a program. One process, from the point where the enterprise system stops to the point where it resumes, with the exceptions held as items, the approvals recorded against real identities, and the result written back through a supported interface.
A fifteen-minute call — nothing paid, nothing signed — takes one such process apart: where the boundary with the enterprise system sits, what has to be built, what it costs, and whether it should be built at all. Sometimes the honest answer is that a configuration change already in your vendor's queue will cover it, and that is a good outcome for the price.
Where building is the answer, that work runs as a monthly engineering partnership, with the targets for each release written down before it starts and paid-for deliverables transferring to you monthly. Afterwards, $15,000 a month puts one accountable person on keeping it running as the systems on both sides of it change. The enterprise system keeps doing what it does well. The twenty percent stops being a spreadsheet.
References
- Umble, E. J., Haft, R. R., & Umble, M. M. Enterprise Resource Planning: Implementation Procedures and Critical Success Factors. European Journal of Operational Research, 2003.
- Davenport, T. H. Putting the Enterprise into the Enterprise System. Harvard Business Review, 1998.
- Palmrose, Z.-V., Richardson, V. J., & Scholz, S. Determinants of Market Reactions to Restatement Announcements. Journal of Accounting and Economics, 2004.
- Beneish, M. D., Billings, M. B., & Hodder, L. D. Internal Control Weaknesses and Information Uncertainty. The Accounting Review, 2008.
- U.S. Securities and Exchange Commission. EDGAR Full-Text Search. Filing counts cited are from full-text search over the trailing twelve months.
