Atlas
The Atlas is the part of this library that is not about software. Five positions on how ERP delivery actually succeeds or fails — because the failures are almost never technical, and the technical ones are almost always a symptom.
Why it matters
Programmes are recovered by changing how people work together far more often than by changing the system. The modules, streams and considerations elsewhere in this library describe what to build. The Atlas describes the conditions under which building it works.
- The failure modes repeat: Decisions nobody owned, problems nobody raised, language nobody understood, people nobody consulted.
- They are not discovered late by accident: They are visible early and uncomfortable to name.
- They cost more than any technical decision: A configuration mistake is a week; a disengaged business is the whole programme.
The positions
- 01
Ask for help
Escalating early is a skill, and programmes punish it by accident until someone deliberately stops doing so.
- 02
Be a hero
The person who says the unwelcome thing in the room where it matters is worth more than any assurance report.
- 03
Change is the word
Every ERP programme is a change programme that happens to involve software, and treating it otherwise is the single most common mistake.
- 04
Ditch the dirty talk
Jargon is how a programme stops being understood by the people who have to accept it.
- 05
Empower people
Decisions made where the knowledge is are faster and better than decisions escalated to where the authority is.
None of these are soft. Each has a direct, measurable effect on schedule: decision latency, defect discovery time, acceptance at go-live, adoption in the first quarter.
What you need in place
- Permission to raise problems: Demonstrated by what happens to the first person who does.
- Real business ownership: Not a sponsor who attends, an owner who decides.
- Plain language: In requirements, in training, in communications.
- Delegation into the programme: So the people doing the work can settle what they know.
- Time for the change work: Scheduled and resourced, not assumed to happen alongside.
Questions to ask
01Bad news
How long does it take a problem to reach the person who can act on it?
Measure it once and the culture becomes visible.
02Ownership
Who in the business will be accountable for this working?
If the answer is the programme, adoption will not happen.
03Language
Could a new starter read our requirements and understand them?
If not, neither can the people signing them.
04Decisions
How many decisions escalate that did not need to?
Each one is latency the schedule pays for.
05Capacity
Do the people doing the change work have time for it?
Usually they have a day job and a programme role.
Metrics and KPIs to track
Decision latency
Request to decision, by forum.
Issue age at escalation
How long problems sit before being raised.
Business participation
Business days contributed against planned.
Acceptance first time
Deliverables accepted without rework.
Adoption
Process actually performed in the system after go-live.
Covers