Every Business Has a DNA. Most ERPs Ignore It — And That's Why They Fail.

Fifteen years into implementing enterprise software for 453 customers across 13 countries, I have stopped being surprised by a pattern that still surprises most ERP buyers.

The customers whose implementations failed were not short on features. They had bought the same modules everyone else buys — finance, inventory, procurement, production, sales, CRM. They had attended the same demos, signed the same contracts, paid the same six-figure licences. Their software was not incomplete.

Their software did not fit.

And the gap — the specific, stubborn, unignorable gap between what the ERP assumed their business was and what their business actually was — accounted for less than ten percent of their total operations. Sometimes less than five.

That is the part I want to write about. Because that small percentage is where ERP implementations quietly fail, and it is also where the biggest gains in adoption come from if you are willing to meet it head-on.

The 90 percent is a commodity. The 10 percent is the company.

Walk into any manufacturing business doing thirty million dollars in revenue. Walk into any trading company moving goods across three states. Walk into any services firm billing by project and retainer. Ninety percent of what they do is indistinguishable from their competitors.

They raise purchase orders. They receive goods. They book invoices. They run month-end close. They chase receivables. They pay statutory dues. They manage inventory, reconcile banks, close books, file returns.

That ninety percent is what every ERP on the market handles well. SAP Business One handles it. NetSuite handles it. Odoo handles it. ERPNext handles it. MaayaERP handles it. If that were the whole problem, the entire industry would have been solved years ago and ERP consultants would be out of work.

It is the remaining ten percent that makes the company the company.

Consider what it actually contains, in the businesses I have worked with:

• A three-tier approval matrix where the plant head signs off before finance, because the plant head has veto authority over raw material commitments that finance does not understand.
• A purchase order format that prints in Tamil on the left side and English on the right, because half the suppliers read one and half read the other.
• A quality rejection workflow that bypasses the standard non-conformance process when the customer is one of three specific marquee accounts, because those three customers will not wait.
• A gamified sales incentive engine that rewards a pumps salesman for spotting an electrical opportunity at a customer site, because the business runs three verticals and the value lives in the cross-sell.

None of this is in the brochure. None of this shows up in the demo. None of this is covered in any standard training. But every one of these rules is the reason the business works.

This is the company's DNA. It is the accumulated wisdom of every operator who ever said this is how we do it here. It is rarely written down. It is almost never in the standard operating procedure document. It is in the heads of the people who have been there ten, fifteen, twenty years.

And when an ERP forces that DNA into a standard-issue workflow, two things happen. The operators either reject the system — they keep a spreadsheet, they keep a WhatsApp group, they keep a notebook — or they comply with it and the business quietly loses the edge that made it work in the first place.

I have watched both. Let me show you what the first one looks like up close.

The WhatsApp group that was running a multi-vertical enterprise

One of our customers is a multi-vertical industrial equipment manufacturer with operations across five countries and three business lines — pumps, electrical, and plumbing. Before we worked with them, the single biggest growth lever in their business was also the single biggest source of silent leakage.

A pumps salesman would visit a large industrial customer and notice, walking through the plant, that the customer also needed electrical panels. Or that a new building was going up and plumbing had not yet been specified. The salesman would take a photograph, jot down a contact name, and send the lead to a WhatsApp group with the other vertical's team tagged.

Then the lead would disappear.

No one knew if it had been allocated to the right person. No one knew whether it had been followed up. No one knew whether the salesman who sourced the lead ever got credit for it when the deal closed months later. Half the time the deal did not close, because by the time the electrical team called, the customer had already purchased from a competitor. The other half the time the deal closed, and the pumps salesman who had surfaced the opportunity had no idea it had happened — so the next time he visited a customer, the incentive to mention the other verticals was weaker.

The leakage was invisible on any report, because no report could see it. The CRM had no module for cross-vertical referrals. The ERP had no workflow for multi-team attribution. The finance system had no logic for splitting an incentive across two business units. The whole mechanism that was supposed to make them a multi-vertical enterprise rather than three siloed businesses was running on WhatsApp messages and the goodwill of individual operators.

This was the 10 percent. And it was the whole point of the company being structured the way it was.

When we built this into their MaayaERP instance, the customization was not small. We built a lead capture form specific to cross-vertical referrals, attribution logic that tied each lead to the originating salesman, a status workflow that pushed the lead through qualification, allocation, follow-up, and closure with visibility to both teams, and — this was the insight that made it work — a gamification layer that computed incentives across multiple parameters, of which cross-vertical referrals was one. Salesmen did not just earn on their own sales. They earned on the ecosystem they created.

New sales from cross-vertical leads went up twenty percent in the year following go-live. That number is worth saying slowly: a twenty-percent lift in a line of revenue that had always existed but could never be measured, let alone optimised. Not a new product. Not a new market. Not a new salesman. Just the removal of the gap between how the business actually worked and how their software pretended they worked.

Why this is not one customer's story

I tell this story not because the customer is exceptional. I tell it because the pattern is universal.

Every serious business I have walked into in fifteen years has had its own version of the WhatsApp group. A CFO maintaining a parallel spreadsheet for three years because the ERP's GL structure does not match how she reports to the board. A plant manager running production allocation on a printed whiteboard because the MRP module does not understand their actual constraint logic. A purchase head keeping a personal approval notebook because the system's routing rules were configured by a consultant who did not understand the industry. A regional sales head running a shadow CRM in Google Sheets because the real CRM does not recognise the way her territory actually breaks down.

These are not small workarounds. Each one represents a piece of the business's actual operating model that the ERP could not absorb. Each one is where the real decisions are being made. And each one is quietly confirming, every day, that the software was not worth fully committing to.

The industry data tells this story in numbers. On average, only 26 percent of a company's employees actually use the ERP their company has paid for. Panorama Consulting's research finds that only 38 percent of organisations realise even half of the benefits they expected from their implementation. Gartner puts the rate of projects that miss their original business case above 70 percent. Panorama's 2025 analysis of over 2,400 discrete-manufacturing implementations puts the failure rate for manufacturers specifically at 73 percent, with average cost overruns of 215 percent. Eighty-two percent of CIOs name employee resistance as the top adoption barrier. Only 11 percent of ERP projects go live on schedule.

These are not outliers. They are the base rate. And every serious study, when it actually asks why, converges on the same answer: the users did not use the system because the system did not fit how they work. The mismatch between the company's DNA and the ERP's assumptions is not a training problem. It is a modelling problem. And it is the default.

Why the industry keeps solving the wrong problem

The standard industry response to the DNA problem is to sell customization as a separate, sequential phase after go-live. The pattern is familiar.

Month one to six: configure the standard modules. Train the users on the out-of-box workflows. Go live on a compromise version of the business.

Month six to twelve: begin Phase Two. Raise change requests. Scope customization. Quote customization. Debate customization scope. Build, test, deploy customization. Hope the users have not already given up.

This is the model SAP uses. It is the model NetSuite uses. It is the model most Odoo and ERPNext partners use. It is the reason ERP implementations are quoted at eighteen months and finish at thirty. It is the reason the industry failure rates are what they are.

The sequential model assumes that the business can run on generic workflows while the real workflows get built. That assumption is wrong. The business cannot run on generic workflows, which is why the users keep the spreadsheet, the WhatsApp group, and the notebook. By the time the customized workflows arrive six months later, the users have built a parallel system that works, and nobody wants to switch off the parallel system for an ERP workflow that still does not quite fit.

There is also a commercial logic to sequential customization that the industry does not advertise. Phase Two is where the margins are. It is quoted per change request, billed at premium rates, and open-ended. The implementation partner has every incentive to defer as much as possible into Phase Two. The customer does not know this going in. They discover it at month nine, when the total project cost has tripled and the system still does not reflect how they actually work.

What we do instead

MaayaERP ships customization during implementation, not after.

That sentence sounds small. In practice, it reorganises the entire delivery model.

When we begin a customer engagement, the first four weeks are not configuration. They are DNA mapping. A named senior specialist — one human, assigned to the customer from discovery to go-live, not a rotating team — sits with the operators and documents the rules that are not in the brochure. The approval matrix that has three tiers instead of two. The print format that is bilingual. The quality rejection path that branches on customer identity. The gamified cross-vertical incentive engine that turns three siloed sales teams into one.

These are not change requests. They are not Phase Two items. They are the implementation.

By week eight, the customized workflows are built into the code — not the configuration layer, the code. They are tested against real data. They are demonstrated to the operators whose DNA they encode. By week ten, the operators are using a system that matches how they actually work, not a system that makes them work differently.

The 90-day go-live is not despite the depth of customization. It is because of it. We do not defer the hard part to Phase Two. There is no Phase Two. There is one phase, and the customized workflows ship inside it.

When I describe this to buyers who are comparing us to NetSuite or SAP Business One, the first reaction is usually disbelief. The second is a question about how this is possible economically. The answer is that we have spent fifteen years building the tooling, the team, and the commercial model that makes it work. We quote the customization up front, in the base engagement. We do not hide it in Phase Two because we do not have a Phase Two. Our specialists are trained in DNA mapping, not generalists rotated from project to project. The code-level customization architecture has been refined over fifteen years and six products — not a retrofit.

What happens when DNA meets software

When the part of the workflow that makes the business what it is gets encoded into the ERP instead of routed around it, the users adopt the ERP. When it does not, they route around it, and the ERP becomes expensive accounting software.

This is visible across our customer base not as a marketing claim but as operational data. Operator login rates, transaction completion rates, exception-handling volumes inside the system — the measurements that matter for adoption — consistently tell the same story across the deployments we run. The sequential-customization industry measures adoption at 26 percent on average. The implementations where DNA is encoded up front do not produce that number.

There is a second-order effect that is harder to measure and more important.

An operator who uses the ERP for the full workflow — including the three-tier approval, the bilingual print format, the cross-vertical incentive — becomes a producer of data, not just a consumer of it. The system starts to see the business at full resolution. Reports reflect reality. Exception analysis becomes possible. AI agents can be trained on actual operational data, not the watered-down subset that survives the compromise.

I have watched the same manufacturing business, two years apart, move from a state where the CEO checked the dashboard and distrusted it because it did not match the spreadsheet, to a state where the CEO checked the dashboard and cancelled the spreadsheet. The difference was not a new feature. The difference was that the DNA had been encoded in, and the data had become true.

The wrong customer for this model

I have to say this because evidence-first means honest about fit.

This model is wrong for a business whose operations genuinely do fit a standard workflow. If you are running a distribution company that does straightforward buy-sell-invoice, has no exceptional approval logic, has no industry-specific compliance layer, and has no workflow your people have built that you want to preserve, then a configuration-only ERP is cheaper and faster. Buy Zoho, buy Tally, buy an off-the-shelf SaaS. You do not need us.

This model is also wrong for a business that wants to buy software and treat it as a commodity. Our customers commit to a 4-week DNA mapping phase with a senior specialist. They give us access to the people who actually run the operations, not just the CFO's office. They treat the implementation as a partnership, not a procurement exercise. If that is not the relationship you want with your ERP vendor, we are the wrong choice.

The right customer for MaayaERP is the one who has already recognised themselves in this article. The finance head maintaining a parallel spreadsheet. The plant operators sending critical information by WhatsApp. The sales team whose real incentive structure lives nowhere in the system. The executive who knows the software does not fit, has been told that is the price of using enterprise software, and has been suspicious of that answer.

That suspicion is correct. The software should fit. The DNA is the whole point.

What the next fifteen years look like

When I look back at fifteen years of implementations, the pattern I see is that my thinking about ERP has moved from feature-first to workflow-first to DNA-first. Early on, I believed that a complete feature set solved the problem. A few years in, I believed that good workflow modelling solved the problem. Now I believe that the problem is DNA, and features and workflows are two of the tools you use to encode it.

This is also why we built the Pi Family of vertical platforms — PoultryCare, RestoPi, FeedPi, LivMatrix, StratoPi — alongside MaayaERP. In some industries, the DNA is shared enough that it makes sense to pre-encode it into a vertical platform rather than re-encoding it per customer. But even in those verticals, the last five percent belongs to the specific operator. The Pi Family is evidence that DNA-first thinking scales. MaayaERP is evidence that DNA-first thinking works at the enterprise level, where no vertical platform will ever fit.

If you are evaluating ERP right now and you have read this far, you already know where your DNA lives. You know which workflows your people work around. You know where the spreadsheets are. You know which WhatsApp group is doing the real work.

The question is not whether the software will accommodate your business. The software will always accommodate something. The question is whether the software will accommodate your business — the three-tier approval, the bilingual PO, the cross-vertical incentive, the thing nobody else does the way you do it.

Fifteen years in, I am only interested in building software that answers that question with a yes.

---

Next step

If this framing matches how you think about your business, start with a 4-week DNA assessment. A named senior specialist, four weeks of sitting with your operators, a written map of where your business's DNA actually lives and which parts of it your current software ignores. No demos. No slide decks. No commitment.

Just a clear answer to one question: how does your business actually work, and which five to ten percent of it is your software failing to see?

Book a DNA assessment →

---

Sources and citations

The industry statistics cited in this article are drawn from the following publicly available sources:

• 26% average ERP employee usage rate — RubinBrown ERP Advisory Services industry analysis, drawing on Panorama Consulting Group data
• 55–75% ERP project failure rate — Gartner and Panorama Consulting Group, widely cited industry range
• 73% failure rate in discrete manufacturing, 215% average cost overruns — Panorama Consulting Group 2025 ERP Report, analysing 2,400+ implementations
• 38% of organisations realise at least half of expected benefits — Panorama Consulting Group ERP Report
• >70% of ERP implementations miss original business case goals — Gartner research
• 82% of CIOs cite employee resistance as top adoption barrier — CFO Club / Panorama survey data
• 11% of ERP projects go live on schedule — Panorama Consulting Group implementation timeline data
• User adoption identified as the #1 reason ERP investments fail — convergent finding across Panorama, Prosci, and multiple independent industry studies