A custom ERP is delivered in five phases: Understand, Define, Build, Prove and Operate, with rollout running in waves inside the build. The calendar length depends on how far your processes differ from the standard, how many systems it connects to, how clean your data is and how fast your team decides. This article sets out what each phase must produce, so that you can judge a bidder's dates by the work behind them.
Phase 1: Understand
Engineers and an analyst study the work as it runs, with time on your premises. The output is a set of documents you keep.
- A problem definition in terms of money, time or risk
- Current-state process maps, with the exceptions
- A register of constraints and the people who own them
- An estimate of where the largest gains sit
Check before moving on: can a person outside IT read these and say whether they describe the business?
Phase 2: Define
The team turns the findings into a design.
- A target architecture and a data model
- A phased roadmap that names the first module
- Success measures, such as close length or stock accuracy
- A commercial structure for the build
Check: does the roadmap name what goes live first, and what stays on the old systems until later?
Phase 3: Build and roll out
Work moves in short releases. A good plan puts working software in a live environment every fortnight or so, so users see progress all along and not only at the end, with a running test suite and a versioned scope behind it.
Check: ask to see the software at the end of the first fortnight. If it is a slide deck, the plan has not started.
Rollout runs in waves, often overlapping with the build of later modules. Each wave covers one site, one department or one module. Data migration, training and a period of parallel running belong here. See moving data into a new ERP and big-bang versus phased rollout.
Check: is there a rule for when the old system is switched off, such as agreement on a full month-end close?
Phase 4: Prove
Before and after go-live, the system is tested against real conditions: a security review, load and failover drills, user acceptance sign-off and written runbooks.
Check: are the results written down, with someone other than the builders reviewing them?
Phase 5: Operate
The system then runs under an agreed support level with a named on-call person, and a quarterly review of the roadmap.
Check: who is on call at 2 a.m. in month-end week, and is it written down?
What moves the date
The same five drivers that set the price also set the date: process variance, integrations, data condition, how many modules go into the first release, and how much work happens on site. They are explained in the five cost drivers of a custom ERP. Two more affect only the calendar.
- Decision speed. When design waits three weeks for an answer, the date moves by three weeks.
- Team size. More engineers add speed in build, a little in discovery and nothing for pending decisions.
Decision speed is the factor buyers underestimate most. Name one person with authority over scope, and agree how quickly questions get answered. Your side has work too: the people who run the processes need hours each week during discovery and build.
Cutting time without cutting safety
Some compression works.
- Go live module by module. Value arrives sooner, and risk is smaller per release.
- Start the data work on day one, not after the screens exist.
- Fix the first module's scope and keep later modules off the critical path.
- Decide quickly on the questions that block build work.
Other compression fails. Adding engineers to the discovery phase adds little. Skipping the parallel run saves a month and risks the close. Cutting the testing phase only moves the cost to your users.
How to read a bidder's timeline
Ask each bidder for these, in writing.
- A duration for each of the five phases, in weeks.
- The assumptions behind each, such as the number of integrations and the data profile.
- The date of the first release that users can touch.
- The hours per week they expect from your staff.
- What happens to the dates if a decision takes longer than agreed.
Timelines that cannot say what they assume will change at the first surprise. For the cost side of the same assumptions, see the five cost drivers of a custom ERP. For the delivery sequence in full, see the custom ERP implementation guide.
What your team does in each phase
A schedule fails as often from missing client time as from vendor delay. Plan these roles before kickoff.
| Phase | Your side provides |
|---|---|
| Understand | People who do the work, available to be watched and questioned, plus a sponsor who can settle disputes between departments |
| Define | One person who decides scope, and an engineer who knows the current systems |
| Build and roll out | A product owner who reviews each release and answers questions within the working week, and department leads who release staff for training and own the cutover day |
| Prove | A reviewer for test results and the person who signs acceptance |
| Operate | A named contact for incidents |
If any of these roles is unfilled, the plan has a gap that the vendor cannot close. Raise it at the start, with names.
Questions buyers ask
What is a realistic schedule for a custom ERP?
It depends on process variance, integrations, data and decision speed. Ask for a duration per phase with its assumptions.
Can we stop after discovery?
Ask each bidder for terms that let you exit after any phase with that phase's documents in hand.
When do users see software?
In the build phase, from the first fortnightly release.
Where Brihat Infotech fits
Brihat Infotech builds and runs custom ERP systems in these five phases, and a client may exit after any phase with its documents. Start a conversation.