ERP redesigns fail for structural reasons ALT

Most ERP redesigns begin with the right instinct: the interface looks dated, users are complaining, and the team secures a budget for “modernisation. “New colours, refreshed typography, updated icons. Six months later the updated system goes live — and nothing changes. Productivity stays flat. Errors persist. People find workarounds exactly as before.

The problem isn’t the design. The problem is that designers answered the wrong question. Most ERP redesigns begin with the right instinct: the interface looks dated, users are complaining, and the team secures a budget for “modernisation.” New colours, refreshed typography, updated icons. Six months later the updated system goes live — and nothing changes. Productivity stays flat. Errors persist. People find workarounds exactly as before.

The problem isn’t the design. The problem is that designers answered the wrong question.

An ERP system is not an application in the conventional sense. It is an organisation’s operational model encoded in an interface. Every screen reflects a decision about how some part of the business should function: who owns data, what the sequence of actions is, where accountability boundaries lie.

When that model diverges from reality — from how people actually work, make decisions, and resolve exceptions — no visual wrapper can conceal it. Users will copy data into spreadsheets. They will run informal approval chains over messaging apps. They will pull reports manually because the built-in analytics don’t cut data the way they need.

This is where most projects fail fundamentally: they hire UI designers when they need systems thinkers who can work at the intersection of operational logic and user experience.

Across manufacturing, logistics, and finance teams, we see the same patterns: redesigns fail before the interface work even begins.

• Data models do not match how users think.
• People see one “document”. The system sees several related tables spread across different modules.
• Access rights follow the org chart, not the workflow.
• One department may formally own a process, but five teams often participate in it. The system does not reflect that handoff.
• Exceptions are treated as edge cases, not daily work.
• Non-standard orders, urgent deliveries, and manual adjustments are part of real operations. Without a legitimate path, users work around the system.

Before opening Figma, you need to spend weeks inside the client’s operational reality. Not in meeting rooms — on warehouse floors, in accounting departments, beside dispatchers. Watch where people pause, where they open parallel spreadsheets, where they explain to a colleague “how things actually work here.”

Those moments are not the residue of bad habits. They are a diagnostic: the system doesn’t support what needs to be done. And that is precisely where real design begins.

In practice, this means rethinking information architecture before touching screens. It means treating access rights as an operational policy question, not a technical configuration. It means designing legitimate paths for exceptions — so they don’t disappear into the shadows.

ERP systems govern money, inventory, people, and obligations. The cost of errors here isn’t a degraded user experience — it’s real financial loss. That’s why a redesign that starts at the visual layer will always lose to one that starts with a structural understanding of how the organisation actually operates.