Do You Need ERP or Just Better Processes?

Most ERP projects begin with a list of symptoms rather than a diagnosis. Month-end takes three weeks. Nobody trusts the inventory numbers. Three departments keep separate versions of the customer list. Approvals sit in someone's inbox for days. The conclusion drawn from that list is almost always the same: the system is inadequate, and a better system will fix it. Sometimes that is correct. Often it is not, and the tell is straightforward. If the problem is that the organisation cannot do something the software does not support, software is the answer. If the problem is that nobody has decided who owns a process, what the rules are, or what the data should mean, then new software will encode the confusion at greater expense and with better dashboards. The uncomfortable version: a system implementation forces process decisions, which is why implementations sometimes appear to fix process problems. You could have made those decisions without spending the money.

The diagnostic questions

Six questions separate a software problem from a process problem, and they can be answered in a fortnight. Can somebody name the owner of the process end to end? Not the owner of each step — the person accountable for the outcome. If the answer is a committee or a shrug, the problem is not the system. Are the rules written down and consistent? Approval thresholds, credit terms, discount authority, when an order becomes firm. If five people give five answers, no software will reconcile them. Is the data definition agreed? What counts as an active customer, when revenue is recognised, what a unit of measure means for a product sold in cases and consumed in pieces. Ambiguity here produces reports nobody trusts regardless of platform. Are people working around the current system or fighting it? A workaround implies the system cannot do something. A fight — duplicate entry, private spreadsheets, side agreements — usually implies the process was never agreed, or that the system was configured to a process nobody follows. Does the current system actually lack the capability? Ask the question precisely. A surprising proportion of mid-market organisations run ten to twenty percent of the functionality they already paid for, because the modules were never configured or the training never happened. What happened last time? If a previous implementation failed to deliver, the cause is more likely to be present in the organisation than in the software that was replaced. A useful rule: if three or more of these point at process, an implementation will not fix them. It will surface them, painfully, at the worst possible moment — during data migration and user acceptance testing — and the project will be blamed for problems it merely exposed.

What to do instead

Process work does not require a programme. It requires a handful of decisions made by someone with the authority to make them. Name owners. Write the rules on one page per process and circulate them. Agree the definitions of the ten most contested data fields. Measure the actual cycle times — order to invoice, invoice to cash, requisition to purchase order — so the argument about where the delay sits becomes a fact rather than an opinion. Fix the three worst handovers. Then re-run the diagnostic. This takes six to twelve weeks and a fraction of an implementation budget. Two outcomes are possible, and both are good. Either the symptoms substantially improve, in which case the money was saved. Or the symptoms persist and you now have documented processes, agreed definitions and named owners — which is precisely the input an implementation needs and almost never gets. Organisations that do the process work first consistently report shorter, cheaper implementations, because the requirements were decided by the business rather than improvised in workshops under time pressure.

Practical Guidance for Operations Diagnostic Session

• Separate capability gaps from decision gaps before scoping anything. Write each complaint on a card and sort it into the two piles. The distribution is the diagnosis.
• Audit what your current system can already do. Unused modules, unconfigured workflow and untrained users are extremely common, and cheaper to fix than to replace.
• Measure three cycle times before changing anything. Without a baseline, no one can tell whether the eventual project worked.
• Name a single owner per end-to-end process. Ownership split at the handovers is the most frequent root cause and the cheapest thing to fix.
• Write the contested rules down on one page each. Approval limits, credit terms, discount authority, revenue recognition triggers. Circulate for objection rather than for consensus.
• Fix master data definitions early, whichever path you take. Customer, item and supplier definitions determine the quality of every report in any system.
• Ask why the last change did not deliver. If the answer is organisational, the next one will hit the same obstacle.
• Give the process work a deadline and a review. Six to twelve weeks, then re-run the diagnostic and make the software decision on evidence.

The Regional Dimension

Three local factors make this diagnostic more valuable in the Gulf than the generic version suggests — and one makes the software answer genuinely unavoidable. The first is the founder-and-owner operating model common across regional family businesses and trading groups. Decision authority is frequently concentrated, informal and exercised outside whatever system exists — approvals given verbally or over a messaging app, terms agreed by the owner directly with a long-standing counterparty. An ERP implementation into that environment does not fail for technical reasons; it fails because the system encodes an approval hierarchy the organisation does not actually use, and within months the workaround becomes the process again. The diagnostic question here is not what the policy says but what happens when the owner calls. The second is turnover. Employment-linked residency and high mobility mean process knowledge is unusually fragile: the person who knew why the pricing works that way may have left the country. Undocumented process is therefore more expensive here than in markets with longer tenure, and the documentation exercise pays for itself even if no software is ever purchased. The third is entity complexity. Groups running mainland companies, free-zone entities and a Saudi subsidiary have genuine structural reasons for divergent processes, and it is worth distinguishing legitimate divergence — different statutory requirements, different licences, different functional currencies — from accidental divergence, where two entities do the same thing differently because nobody compared them. The exception that forces the software answer: regulatory interfaces. Saudi e-invoicing clearance, wage protection file submission, VAT and corporate tax reporting are not process preferences. They are externally specified, machine-validated obligations, and an organisation running on spreadsheets and a legacy accounting package may genuinely be unable to comply without a system change. When a regulator validates your document format in real time, better process discipline is not a substitute for capability.

The objection worth taking seriously

The honest counter-argument is that process-first is frequently advice to do the hard, unfunded thing, and that it fails for predictable reasons. Process improvement without a forcing event tends to stall. There is no deadline, no budget, no external party asking for status, and no consequence for the manager who declines to change. An implementation supplies all four. Several organisations have genuinely used a system project as the only available mechanism to make decisions the business had avoided for a decade — expensive, but effective, and the alternative was continued paralysis. There is also a real risk of the diagnostic becoming the deliverable: three months of process mapping, a consultant's report, a set of recommendations, and no change. That outcome is worse than an imperfect implementation, because it consumes credibility as well as money. And sometimes legacy systems really are the constraint. A package that cannot produce a compliant tax document, cannot support a second currency, or is no longer supported by anyone alive is not a process problem however carefully you define ownership. The balanced position: run the diagnostic, but time-box it hard and attach it to a decision date. If the organisation cannot make process decisions in twelve weeks with a named sponsor, that is itself the finding — and it predicts exactly how the implementation will go, which is worth knowing before signing the contract rather than after.

Common Questions

How do we tell the difference quickly?

Ask whether the current system could do it if configured correctly, and whether the organisation has agreed what "correctly" means. Capability gap points to software; agreement gap points to process. Most complaint lists contain both, and the ratio determines the sequence.

Is it ever right to buy the system first?

Yes — when a regulatory or statutory requirement cannot be met by the current platform, when the vendor has ended support, or when the organisation has demonstrably failed to make process decisions without an external forcing event. Be honest about which of those applies.

Who should run the diagnostic?

Someone independent of the software decision, with the operational detail to test claims and enough seniority to be told uncomfortable things. If the person facilitating also stands to implement, the answer will tend toward implementation.

Can AI substitute for an ERP upgrade?

Not for the transactional core — a document that must be cleared by a tax authority still needs a system that produces it correctly. But AI has genuinely changed the arithmetic on two of the classic reasons for replacement. Reporting and reconciliation complaints, historically a major driver, can often be addressed by extracting data from the existing system rather than replacing it. And document-heavy bottlenecks like invoice capture, supplier onboarding and exception handling can be automated around a legacy platform. The caveat is that AI amplifies master data quality problems rather than solving them, so an organisation with contested definitions and duplicate records will get confident, fast, wrong answers — which returns you to the process work either way.

---

Operations Diagnostic Session — software fixes capability gaps; it encodes decision gaps at higher cost, with better dashboards.