The figure that gets quoted is 65% of ERP projects fail. The failure pattern is consistent, and almost all of it is decided in the first ninety days, often before the contract is signed.
By Mohammad Jamnagarwala · Simply Five Studio
The figure that gets quoted, in every consultant deck and analyst report, is that sixty-five percent of ERP projects fail. The figure is roughly correct. The interesting question is not whether ERP rollouts fail, but when. The answer is the first ninety days. By the time the project formally goes live, the failure has usually already happened. Go-live is the moment the failure becomes visible to the founder, not the moment it was caused.
This essay is the pattern. Five symptoms that show up early, all of which are detectable before the contract is signed, and the diagnostic a founder can run on a vendor before committing.
The most common cause of a ninety-day failure is that nobody wrote down how the business actually runs before the system was scoped. The vendor demoed the standard ERP. The founder watched the demo and recognised parts of it. The contract got signed. The configuration began. Six weeks in, the implementation team started asking questions like, how does your firm handle a partial dispatch where the customer changes the destination address mid-route, and the answer turned out to be different in every branch.
The operational map is the document that should exist before the ERP is selected. Who does what, in what sequence, with what exceptions, against what record. A factory floor's actual workflow rarely matches the demo's idealised one. The gap between the two is where customisation cost lives, and customisation cost compounds fast.
The firms that get this right spend two to four weeks documenting the operation before the vendor enters the room. The documentation is not glossy. It is a notebook, a whiteboard photo, and a series of sit-downs with the team. It is the same diagnostic phase that appears in our approach work, because the diagnostic saves more money than any negotiation on price.
The second pattern. The founder announces the new system in a meeting. The team receives the news. The vendor's trainer arrives on the go-live week. Two days of training are conducted. The system goes live the following Monday. Three weeks later, the team has quietly reverted to the spreadsheets they always used, and the new system runs in parallel with nobody inputting anything beyond what the founder personally checks.
Change management is not a memo. It is the daily reinforcement, by someone the team respects, that the new system is the only system. It is the senior operations head sitting with the team for the first month and answering questions in real time. It is the founder visibly closing the old shortcuts. It is the recognition that the old workflow has muscle memory that the new system has to displace, and displacement takes longer than training.
We saw the pattern starkly during the Carbiforce, Metaldur, and Kawacut build. The shared owners of the three brands committed personally to the floor visits for the first sixty days. Adoption stabilised in week ten. Without that commitment, the adoption curve would have flattened at thirty percent and the project would have joined the sixty-five percent.
The third failure pattern is the decision to move every workflow on the same day. Sales, inventory, purchase, finance, payroll, customer portal, all live on the same Monday. The reasoning is usually that running parallel systems for too long is exhausting, and that a clean break forces adoption.
The reasoning is wrong. The clean break is also a clean failure surface. Any one workflow that breaks brings the whole rollout into question. The team loses confidence in the system. The founder loses confidence in the vendor. The recovery takes months.
The pattern that works is a staged rollout against a sequence the business can absorb. Inventory and purchase first. Sales and quotation next. Customer portal and dashboards last. Each stage runs for four to six weeks before the next one begins. The team builds confidence on small wins. The founder sees value early. The vendor learns the firm's exceptions on workflows where the stakes are contained, before applying the learning to the high-stakes workflows.
The ES Haji industrial ERP is the example we point to. RFQ and vendor coordination went live first. Quotations and purchase order workflows followed. Customer and vendor dashboards came in the next stage. Tally integration closed the loop last. Every stage had a working previous stage to fall back on.
The fourth pattern. The vendor's implementation team ships the system and disappears. The handoff is to a customer success representative whose job is ticket triage. The questions that come up in week three of live operation, the unexpected exceptions, the small bugs that compound into team frustration, have nowhere to land. The vendor's response time is measured in days.
This is the structural problem with treating ERP as a product purchase rather than a system commission. The product purchase ends at delivery. The system commission is a multi-year relationship. The firms that succeed treat the implementation team and the long-term support team as the same team, with the same context, available on the same channels the founder uses to reach his own staff.
A founder evaluating vendors should ask, literally, who will I be talking to in month four, and how fast will they respond. If the answer involves a ticket queue, the rollout has a higher chance of joining the sixty-five percent. The longer treatment of this point sits in our essay on three years of one system.
The fifth pattern is the most preventable. The founder, exhausted by the build-up to go-live, books a holiday for the first two weeks of live operation. The team encounters its first unexpected situation on day three. The decision required is small but only the founder can make it. The team waits. The work-around becomes the workflow. By the time the founder returns, the work-around has become muscle memory, and the system's intended path is permanently bypassed.
The founder must be available for the first thirty days of live operation. Not in a supervisory sense, in a decision-making sense. The questions that arrive in those days set the operational pattern that the system will run on for years. The cost of being absent for those decisions is far larger than the cost of postponing the holiday.
Before a founder signs an ERP contract, the diagnostic that prevents the ninety-day failure has five questions. Has the operational map been drawn, in this firm, in writing. Who in the team has been identified to carry the change management work for the first sixty days. What is the staged rollout sequence and what does each stage deliver. Who specifically, with name and phone number, is the post-go-live point of contact in month four. Is the founder available on-site for the first thirty days.
If any of the five answers is uncertain, the contract is not ready to sign. The firm is buying a ninety-day failure at full price.
The work we do under the internal systems practice is structured to prevent each of these patterns. The diagnostic phase produces the operational map. The build phase respects the staged rollout. The partnership phase is the same team the firm met on day one, available in the months when the questions matter most. Decision infrastructure is what the firm gets at the end. The first ninety days are where it is decided whether the firm gets there at all.
If you are within ninety days of an ERP decision and the diagnostic above raises any uncertainty, the right next step is a conversation before the contract, not after. Start a Conversation.
Accounting software produces statutory output. ERP automates the workflows of a generic business. Neither is the same as the structured truth a founder needs to run a specific business. That third thing is decision infrastructure, and it is what founder-led firms eventually outgrow SaaS to acquire.
Every six months a founder asks why they need another system when Tally already runs the books. The honest answer is a diagnostic, not a sales pitch. Here is how to run one on your own business.
Tally is the financial system of record. An ERP is the operational system of record. Most founders buy one and assume it is also the other. The confusion costs years.
The contact form takes about two minutes. The reply comes from the founder within two working days.
