Perspective
ERP Is Not Software
Why the system everyone files as an application is actually the operating model of the company, and what goes wrong when it is treated as the former.
The most expensive misunderstanding in enterprise technology is the belief that ERP is software.
It is filed that way. It appears in the application portfolio, it has a vendor, it has a license renewal and a support contract and a version number. Every artifact around it says application. And that filing is what makes the next decision go wrong.
An ERP system is the encoded operating model of the company. It contains the answer to how a product is costed, which is the answer to what it is worth making. It contains the scheduling logic, which is the answer to what the plant runs next. It contains the inventory position, the procurement rules, the order fulfillment path, and the material requirements plan. Those are not features. Those are decisions the business has already made, written down in a form that executes.
Change the costing method and you change what you sell.
I have owned that stack across two multi-plant food manufacturers. Infor Adage owned outright, Oracle JD Edwards operated, Infor M3 selected and implementation underway at my departure. Underneath them the capability set that actually matters: material requirements planning, production scheduling, capacity planning, materials management, procurement, product costing, inventory, and order fulfillment, with MES and PLM environments running alongside.
None of those are IT functions. Every one of them is a business function that happens to run on a platform, and the distinction is the reason ERP projects fail at the rate they do.
When ERP is treated as software, the evaluation becomes a feature comparison. Vendors are scored on modules. The selection is made on functionality and price, and the implementation is scoped as a technical migration. Then the project meets the actual company, and the actual company discovers that the new system encodes a different set of decisions than the old one. Costing works differently. Scheduling assumes a different plant model. The chart of accounts does not map cleanly. And nobody owns the decision about which behavior is correct, because everyone believed they were buying a tool.
When ERP is treated as an operating model, the work starts somewhere else entirely. It starts with what the business actually does, which is almost never what the documentation says it does. It starts by finding out which processes exist because they are right and which exist because a prior system made them necessary. That distinction is the entire project. Carry a workaround forward into a new platform and you have paid several million dollars to preserve a limitation you no longer have.
At one manufacturer the Adage environment reached end of extended support, which meant the decision could not be deferred any further. I ran the evaluation. The capital budget was then cut by thirty-six percent, and the initiative had to survive that cut on its own merits against every other claim on the money. It did, because the case was never framed as a technology refresh. It was framed as what the company would be unable to do if the platform underneath its costing, scheduling, and fulfillment stopped being supported. The recommendation selected M3, and the implementation was underway when I left.
The lesson I took from it is narrow and I have never seen it fail. The business case for an ERP is not a technology argument, and if you make it as one you will lose to a piece of equipment.
A plant manager asking for a new line can put a number on the output. An ERP request that describes modules and versions cannot compete with that, and should not. But an ERP request that describes what the company will not be able to do, quantified, against a date that is not negotiable, is a different conversation. That version competes, because it is finally speaking the same language as everything else on the capital list.
There is one more consequence and it outlasts the project.
Whoever owns the ERP owns the definitions. What counts as a finished good. When revenue is recognized. What a standard cost includes. Those definitions propagate into every report the executive team reads, and once they are wrong they are wrong everywhere, quietly, in every direction at once.
That is not an application to administer. That is the source of truth for how a company understands itself, and it deserves an owner who knows the difference.
— Keith Formell
© 2026 Keith Formell · New Lenox, Illinois