Here is the most reliable law in business software, and the least popular: automation amplifies. Feed a system a good process and it gets faster, cheaper, more consistent. Feed it a broken one and you get the same chaos at higher speed, with better-looking reports about it. Companies rarely fail at ERP because the software was wrong; they fail because they automated how they thought work happened rather than how it actually did.
How work actually happens
In most growing companies there are two organisations. The official one lives in the org chart: requests go to managers, approvals follow policy, the process is documented somewhere. The real one lives in WhatsApp: the storekeeper messages the owner directly because that's faster, the discount gets approved with a thumbs-up emoji, and the one employee who "knows how it's done" carries the actual process in her head. The official organisation is what gets automated. The real one is what keeps running — now around the new system instead of through it. Six months later someone declares the ERP a failure. The ERP was fine. It faithfully automated a fiction.
The three symptoms worth taking seriously
You don't need a consultant to diagnose this; you need one honest week of observation. Approvals by WhatsApp — if commitments of money happen in a chat thread, your approval process has no owner, no record and no limit, and automating your "official" approval flow will change nothing. The one-person dependency — if a specific person being on leave can stall invoicing or shipping, the process lives in a human, and software can't automate what only she knows. Everyone does it differently — if three salespeople produce quotes three ways, there is no process to automate yet; there are three habits, and the system will inherit the loudest one.
Map first: the unglamorous method
The fix is almost embarrassingly low-tech. Watch the real work — not the described work — for one core flow: sales-to-cash, or purchase-to-pay, or month-end. Draw it as it is: every step, every handoff, every wait, every workaround, in the language your team actually uses. Then put numbers where they leak: how many days from delivery to invoice? How many touches per purchase order? How often is the same data typed twice? The as-is map is usually the first time an owner sees the company drawn honestly, and it changes the conversation instantly — from "we need a system" to "we need to stop doing this."
Only then design the to-be version: fewer handoffs, explicit approvals with named owners and limits, one way of doing each task. Design it with the people who live in it — they know where the bodies are buried, and their fingerprints on the design are what makes Monday morning adoption real.
Then, and only then, the system
Here is where the sequence pays. When a mapped, agreed process meets an ERP implementation, configuration stops being guesswork: the approval flow in the system is the one you designed, the quote template is the one everyone agreed to, the KPI on the dashboard is the number you chose to watch. Implementation gets faster and cheaper — less rework, fewer change requests, no "actually, that's not how we do it" in week seven. And the system becomes the enforcement mechanism the redesign always needed: the process stays fixed because deviating from it now takes more effort than following it.
That's the honest relationship between process work and software: mapping without implementation produces a beautiful PDF that changes nothing; implementation without mapping produces fast chaos. The value is in the sequence.
The UAE angle
Growing UAE SMEs feel this amplification law harder than most, for a structural reason: growth here can be fast, teams are multilingual, and compliance is unforgiving. A broken invoicing process isn't just slow — it now produces VAT filings from bad data, on a deadline, with penalties. Process discipline and compliance aren't two projects; the first is how the second stops being frightening.
Where to start
Pick the process that annoys you most — annoyance is excellent diagnostic data. Give it one mapping session. You'll leave with three things: an honest picture, a dirham estimate of what the leaks cost monthly, and a shortlist of fixes ranked by impact — some of which need no software at all. Whether the map leads to an ERP project, a one-page SOP, or just the retirement of one WhatsApp group, it will be the highest-leverage afternoon your operation has had in a while.
FAQ
Should I fix processes before implementing an ERP?
Yes — automation amplifies whatever it's given. Mapping first makes implementation faster and cheaper, and it's the difference between a system your team uses and one they work around.
What does business process mapping actually involve?
Observing the real work (not the documented version) for a core flow, drawing every step and handoff as-is, quantifying the leaks, then designing the to-be version with the team that lives in it.
How do I know my company needs process work?
Three reliable symptoms: approvals happening in WhatsApp, dependence on one person's memory, and the same task done differently by different people.
Does process optimisation always end in software?
No. Some fixes are pure process — an explicit approval limit, one agreed template, a weekly 20-minute review. Software enters where a fix needs enforcement to survive growth.