The Architecture Decisions That Make ERP Rollouts Actually Stick
ERP rollouts fail for a surprisingly consistent set of reasons — and almost none of them are technical. The teams are competent. The software is capable. The failure is usually architectural: decisions made in the first four weeks that quietly constrain everything that follows.
Start with the data model, not the UI
Every ERP implementation we've been brought in to rescue shared the same founding mistake: screens were designed before the underlying data model was agreed upon. The result is a system that looks finished but behaves inconsistently — because the entities that drive the business were never properly modelled. We now spend the first two weeks of every engagement doing nothing but mapping data. What is a 'product' in this business? What is an 'order'? How does inventory relate to procurement? Get this wrong and you're building on sand.
Plan for the integration layer on day one
An ERP that doesn't talk to your accounting software, your warehouse management system, and your e-commerce platform is not an ERP — it's an expensive island. We've seen clients spend 18 months building a core system and then discover that integration would have required a completely different database design. Integration is not a phase two problem. It defines the architecture from the first design decision.
The six patterns we return to
- Model your business entities before designing any screen
- Design integration interfaces before building internal modules
- Use event-driven architecture for cross-module communication
- Build your reporting layer as a separate read model from day one
- Define your access control model before writing any business logic
- Agree on a single source of truth for every critical data entity
An ERP should fit your business like a well-tailored suit. The moment you start tailoring the business to fit the software, you've lost.
The organisations that get this right treat ERP rollouts as a business transformation project with a software component — not the other way around. When the process is right, the technology follows cleanly. When the process is ignored, no amount of engineering fixes the underlying structural problems.
