Most ERP programmes do not struggle because the technology is unusually complex. They struggle because the organisation cannot make decisions fast enough, cannot establish ownership early enough, or cannot treat data as an operational asset rather than a technical deliverable.
These problems appear “simple” because everyone agrees they matter. They are difficult because they sit in the overlap between business behaviour and delivery discipline.
Data is the most common example. Data migration is often presented as a workstream with clear steps: extract, cleanse, load, validate. In practice, data issues are rarely technical first; they are ownership issues first. Common failure patterns include:
- unclear master data ownership across domains
- disputes over “golden source” systems with no decision authority
- inconsistent rules between sites or business units
- pressure to go fast without a business sign-off model
When these conditions exist, teams can be highly capable and still rework the same data sets repeatedly. The cost is not only time. It also erodes business confidence—users experience inconsistent masters and assume the system is unreliable.
Decision latency is the second predictable delivery killer. Every programme has defects. What programmes do not survive is slow decision-making combined with continued build activity. When decisions take weeks, teams fill gaps with assumptions. Those assumptions show up later as rework across configuration, integration, testing, training and change.
Strong programmes create a decision rhythm. This is not bureaucracy. It is a clear process: decisions are logged, owners are named, inputs are defined, and closure is enforced. The programmes that move quickly tend to have a small number of empowered decision-makers and a transparent escalation path. Where we see delivery drift, it is often because decision rights are unclear and accountability is diluted across too many stakeholders.
That leads into the third issue: ownership. In many programmes, “ownership” is treated as participation rather than accountability. Workshops are well attended; decisions remain open. Then go-live approaches and the programme becomes reactive.
ERP delivery requires named owners for outcomes: process owners, data owners, testing owners, cutover owners. Without this, the programme becomes dependent on a small number of individuals working around organisational indecision.
Testing is where these issues become visible. Testing does not simply reveal software defects; it reveals gaps in process definition, weak training, incomplete integration, and poor data discipline. Under-resourced testing is often justified as a cost-saving measure. In reality it tends to increase cost later by forcing late rework under time pressure.
We consistently see higher stability where testing leadership is strong—people who can spot patterns, push for root cause analysis, and defend entry/exit criteria rather than accepting “we’ll fix it later”. In regulated environments or finance-heavy programmes, this discipline matters even more because quick fixes can create control and audit issues.
Change management is the final “simple” factor that creates real delivery risk when ignored. Change is not only communications and training. In many organisations, ERP introduces transparency: new controls, visible metrics, fewer workarounds. That transparency shifts behaviours and sometimes shifts power. Resistance is rarely framed as resistance; it appears as slow adoption, delayed sign-offs, or continual requirement changes.
From a hiring perspective, this is why many organisations are adjusting how they assess candidates. In 2026, technical skill remains essential—but the roles that most protect delivery are often those that reduce ambiguity: people who can drive decisions, enforce ownership, communicate risks clearly, and stabilise delivery behaviours under pressure.
In short: ERP does not fail because teams lack intelligence. It fails because the organisation does not establish ownership, data discipline and decision-making early enough. These are “simple” issues that require deliberate hiring and deliberate programme design.
