Choose the ERP approach before choosing the screens.
Clarify requirements, compare systems and plan the business decisions that an ERP programme will require.
What this covers.
The decisions that have to be settled before an ERP is selected or configured: the process model, the approval structure, the entity and ledger design, what master data exists and who owns it, and which requirements are genuinely non-negotiable as opposed to habitual. Requirements are written so they can be tested against, not so they can be agreed with.
How it runs.
Workshops with the finance, supply and operations teams together rather than separately, because the disagreements between them are the point. We produce a requirement set, a process design, a data position and a realistic view of effort. Where a requirement will be expensive, we say so at the point it is raised.
Where it fits.
Before a selection, before a re-implementation, or when a programme has stalled and needs the decisions unpicking. It is the cheapest phase of an ERP programme and the one that determines the cost of every phase after it.
What you get, and what it depends on.
A requirement set written to be tested against, a target process design, a data position and a realistic view of effort. It depends on finance, supply and operations being in the room together, because the disagreements between them are the material.
How we can work together
The model is chosen to suit the work, not to suit us. We will tell you when a fixed price is the wrong instrument.
Readiness review
Where you are against where a programme would need you to be.
Selection support
Requirements, scoring, scripted demonstrations and a documented recommendation.
Programme reset
A stalled programme unpicked back to the decisions that were skipped.
What would a better working day look like?
Bring us the process you want to improve. We’ll explore the product, technology and delivery work it needs.