70% of ERP implementations fail. Because companies ask the wrong question first.

Usually when something starts to hurt. Either rapid growth in markets, channels, SKUs or warehouses outpaces the spreadsheets holding things together, or the existing ERP has become so rigid that every change needs outside consultants. Both moments trigger the same reflex, buying a new or better ERP. That is exactly when it pays to step back and define the architecture first.

Most failures are architectural, not technological. In most cases the company chose a system before defining what it should do, driven by time pressure and by a consulting market whose revenue depends on implementation scope. The whitepaper walks through a case where a by-the-book rollout brought a nine-figure company close to insolvency.

A clearly bounded one. The ERP is hard to beat for finance: posting integrity, master data consistency, compliance and tax. Many consumer goods companies keep it as a lean financial backbone and let a PIM, OMS, WMS and planning tools own their domains. Deeper integration can work too, as long as the boundaries are drawn deliberately from the start.

Vendor selection should come last, not first. Start by defining what the ERP should and should not do, then redesign the target processes, then design the system architecture. Only then pick the vendor that fits that architecture. The whitepaper sets out this four-step sequence with the questions to answer at each step.

Keep the ERP's scope deliberately lean and give every data domain one clear master system. Interfaces should follow a consistent, API-based logic instead of manual exports or fragile batch jobs. That way you can swap a WMS or upgrade a planning tool without touching the ERP, and future system changes become structured programs rather than existential risks.

Overruns are the norm rather than the exception. According to Panorama Consulting, 75% of ERP projects exceed their timeline and half go over budget, often by three to four times. In the worst case, a failed go-live stops orders from being fulfilled and finance from closing the books.

Clear ownership before configuration. Every system needs an explicit responsibility and every data domain one source of truth. Otherwise unclear responsibilities simply turn into hard-coded permissions. Fragmentation comes from unclear ownership and undefined data flows, not from the number of systems.

Because choosing a system quietly defines the scope. Modules shape later discussions, standard workflows steer process design and exceptions become customization requests. Before long, a system implementation has grown into a full transformation program. The better first question is what the ERP should be responsible for, and what it should leave alone.

You need to know where friction occurs in your operations today, which systems already work reliably and where data conflicts arise. You also need to decide which platform holds the source of truth for each domain and what the ERP should explicitly not do. The whitepaper argues these must be answered before any vendor demo, because undefined boundaries turn into integration conflicts later.

Monolithic architectures once made centralization look efficient, and many partners still extend the ERP's footprint because that matches how they deliver. The result is a system that turns weak workflows, unclear responsibilities and inefficiencies into digital routines. With every customization it gets harder to change, until the platform slows the business down.

No, but the earlier the better. Even with a vendor in place, you can still define what the ERP should own and which processes to simplify before configuring them. In one example from the whitepaper, a company dropped a rarely used cash-on-delivery process instead of digitizing it, which removed a whole layer of complexity.