The gap between the ERP the board thinks the business runs on and the spreadsheets it actually runs on — and a working diagnosis of how to close it.
The board sees the ERP name on every presentation slide. The auditors see it in the general ledger. The system integrator that implemented it three years ago sees it as a reference. And yet the CFO's assistant maintains a master reconciliation spreadsheet that pulls from four systems every Monday morning. The sales manager keeps her own tracker of what customers actually promised, separate from the CRM. The operations lead maintains an Excel file for daily production planning because the ERP's planning module was configured for a business the operations lead does not recognise. Purchase requisitions travel on email attachments. Stock reconciliations happen in Excel. Management reports are assembled by copying numbers out of the ERP into a workbook, adding adjustments, and formatting for the board.
ERP was configured for a version of the business that the business no longer is. Sometimes the configuration was correct at implementation and the business has since changed — new product lines, new geographies, new commercial arrangements, new regulatory context. Sometimes the configuration was never quite right and the operators worked around it from day one. Sometimes the ERP is powerful enough in principle but the process design that would activate that power was never done — the workflow was left to the software vendor, whose standard flow assumed a business the actual business is not. Panorama Consulting's annual ERP report has documented, year after year, that a large share of ERP implementations produce lower-than-expected utilisation. The spreadsheet workarounds fill the gap the ERP cannot.
The cost shows up in five places. First, the CFO's month-end takes ten days rather than three, because the reconciliation is manual. Second, the management report the board sees is a workbook someone maintained rather than a system output, which means the same question asked twice produces two answers. Third, the sales team's forecast lives in a spreadsheet the CFO does not trust. Fourth, working capital is worse than it should be because inventory data across systems disagrees. Fifth, every attempt to add a new capability — a new BI dashboard, a new integration, a new AI use case — hits the same wall: the ERP's data is not clean enough or complete enough for the new capability to work, because the operational reality lives in Excel.
The ERP is not the problem. The workflow the business runs under the ERP is the problem. Installing another ERP, upgrading to the newest version, or migrating to a cloud edition will not eliminate the spreadsheet workarounds — the workflow issues that produced the workarounds will migrate with the business. This pattern is why HBR's most-cited transformation piece frames the failure mode as one of workflow and organisation rather than technology (Tabrizi et al., 2019). The instinct to *replace the ERP* is the instinct that produces the next spreadsheet layer three years later.
The ERP, in most cases. If the ERP handles the general ledger, statutory reporting, procure-to-pay and order-to-cash even imperfectly, replacing it is the most expensive way to solve a problem that a workflow reengineering can address at a fraction of the cost. Also do not replace the operational Excel files that senior operators use to actually run the business — those files encode institutional knowledge the ERP was never asked to hold. The redesign starts with which of those Excel files should become a system of record and which should stay operational.
The processes the ERP was purchased to run — but was never quite configured for. Order-to-cash, procure-to-pay, inventory management, month-end close. In most mid-market businesses, a focused reengineering of two or three of these processes eliminates the majority of the spreadsheet workarounds. The reengineering has three parts: (1) redesign the process to match how the business actually operates, (2) reconfigure the ERP to support the redesigned process, and (3) codify what leaves the ERP into a report and what stays inside it. Done properly, the CFO's month-end drops from ten days to three.
The systems that already sit around the ERP. Most mid-market operators have five or more systems talking to the ERP badly: the CRM, the payroll system, the banking portals, the manufacturing execution system on the shop floor, and the accounting-adjacent tools finance uses. Integration here is not about heroic engineering. It is about making each system's data land in the ERP in the shape the ERP expects, and about exposing the ERP's data to the systems that need it. Most of this is standard middleware work; the difficulty is knowing which integrations matter.
The reconciliation work. Every mid-market business we have seen has a small number of people whose job is effectively human middleware — reconciling stock, cash, receivables, payables between systems. That work should be automated. Not to make those people redundant — in most cases they become the operators who handle exceptions, and their productivity multiplies — but because human middleware is where errors compound. Automating the reconciliation makes month-end faster, makes working capital more accurate, and makes the ERP's data actually trustworthy.
AI helps at three specific points in an ERP-plus-Excel operation. First, in exception handling — flagging the cases the humans need to look at, so the humans stop looking at everything. Second, in reconciliation — matching transactions across systems that describe them differently. Third, in commentary — drafting the narrative that goes with the management pack so finance stops writing it from scratch every month. None of these require a general *AI transformation programme*. Each is a specific, narrow use case where the return is measurable.
The right sequence starts with the process that produces the largest month-end pain. Usually that is either order-to-cash or inventory reconciliation. Reengineer that single process. Configure the ERP for the redesigned process. Automate the reconciliation. Expose a clean report. When leadership sees the credibility of the change, fund the next process. A common eighteen-month arc looks like: months 1–3 diagnose the specific processes producing the workarounds; months 4–9 reengineer and reconfigure the first process; months 10–15 reengineer the second; months 16–18 build out the reporting layer that leadership sees. Each phase pays back before the next begins.
A business does not need a large internal IT function to do this work. What it needs is senior digital leadership who can diagnose which processes to reengineer and in what order, plus specialists who know the specific ERP well enough to reconfigure it without breaking what already works, plus operational discipline from the leadership team while the change is being sequenced. The internal-IT-team-shaped hole most mid-market businesses have is exactly the shape Jettifi is designed to fill — senior core, specialists per engagement, operational independence handed over.
A Jettifi engagement of this class begins with a process diagnostic, not an ERP audit. Which processes produce the workarounds? Which of those matter for the P&L? What would each of them need for the ERP to actually run them? The output is a sequenced reengineering plan — process by process, ERP-configuration by ERP-configuration, integration by integration, report by report. Senior Jettifi core runs the diagnostic; specialists are assembled around the specific ERP (SAP, Oracle, Zoho, Tally, MS Dynamics, custom). The engagement ends when the ERP is running the processes the ERP was purchased to run — and the spreadsheets are back to being operational, not structural.
Discuss the processes the ERP was purchased to run
Talk to Jettifi →For the underlying working paper, read the Digital Reengineering pillar or the executive edition of The Guide.