How an ERP implementation works: stages, roles and common mistakes

An ERP implementation is not installing software. It is reshaping how a company handles money, inventory and people. Technology is rarely the main problem. Projects stall because of unclear decisions, poor data and no business-side owner. Below are the stages, the roles and the mistakes we see most often.

Diagnosis and design

During diagnosis, the team studies current processes, systems, data and pain points. The output is a shared view of scope, priorities and risks, plus a project plan. It is important to hear not only management but also the people who enter documents every day.

During design, the target processes in the system are described: how an order, a purchase or a month-end close will run. The team records where the standard is used and where a customisation is genuinely needed. Every deviation from standard needs a justification and an owner.

Building in short iterations

Instead of configuring the system for six months and showing it at the end, we work in short cycles, usually two to four weeks. Each cycle configures part of the processes, key users see the result on their own data and give feedback. Design mistakes surface early, while they are still cheap to fix.

Data migration

Migration runs alongside configuration, not at the end of the project: master data cleansing, transformation rules, several trial loads with reconciliation. Data is the business’s responsibility. A consultant can build the load, but only the client can decide which of three duplicate supplier records is the right one.

Training and go-live

Before go-live, users are trained by role and test the end-to-end scenarios themselves. A step-by-step cut-over plan and readiness criteria are drawn up. The go or no-go decision is made against those criteria, not against a date in the calendar.

Hypercare

The first weeks after go-live are a period of intensive support. The project team stays close to users, questions are resolved the same day, and the first month-end close is done together. Only once things are stable does the system move to business-as-usual support.

Implementation does not end at go-live. Cloud systems are updated regularly, the business changes, and new processes and users appear. Define the support model in advance: what your own team does, what the partner does, and how change requests are prioritised. A few months after go-live, run a review: which processes work as designed, where users work around the system, which reports nobody uses. That is a good source of the next round of improvements.

Roles

• Sponsor — a member of senior management who settles contested decisions and secures resources.
• Client-side project owner — the person accountable for the outcome, who knows the business. Not necessarily from IT.
• Key users — departmental experts who take part in design and testing, then train their colleagues.
• The integrator’s project manager and functional consultants.
• Client IT — integrations, infrastructure, access rights and ongoing support.

Key users need dedicated time for the project. If it runs “in their spare time”, it will drag on. During the key stages — design, testing and go-live — they usually need to give the project a large part of their working week, and their regular tasks should be reassigned for that period.

Common mistakes

• Too much customisation. Each one makes updates and support harder. It is often easier to change the process than the system, especially in cloud products with regular updates.
• Copying old processes one-for-one. A new system configured like the old one will repeat its problems.
• Weak data. If master data cleansing is left to the last month, go-live slips or goes ahead with errors.
• No internal owner. When the project “belongs” to the integrator or to IT, the business doesn’t make decisions and never takes ownership of the system.
• Training in the final week. Users who first see the system just before go-live resist it and make mistakes.
• Trying to launch everything at once. Sometimes it is wiser to go in waves: finance and purchasing first, then manufacturing or service.

An ERP is implemented by the company itself, not by the integrator. The integrator helps it get there faster and with fewer mistakes.

Signs the project is on track

• Contested questions are decided in days, not months.
• Key users see the system on their own data within the first weeks of configuration.
• Trial migrations pass reconciliation.
• The customisation list doesn’t grow after every meeting.

If any of these is not true, it is better to stop and sort it out now than at go-live.