ERP implementation step by step: stages, preparation and best practices

The decision to implement a new ERP system triggers far more than an IT project. The organisation commits budget, the time of key employees and technical resources, while still having to maintain continuity of day-to-day operations. The larger the company and the more complex its processes, the more dependencies need to be considered: from data quality and integrations with other systems to the way end users work.

That is why a successful ERP implementation begins before the first module is configured. It requires clear business objectives, scope, responsibilities, process architecture and a way to measure outcomes. Only then can the organisation move through the next stages: analysis, solution design, configuration, migration, testing, go-live and stabilisation.

Why is ERP implementation a business project, not just a technology project?

ERP implementation is a business project because its purpose is not simply to launch a system, but to change how processes are executed, controlled and measured across the organisation.

An ERP system integrates information and activities related to finance, purchasing, sales, warehousing, production and logistics, among other areas. In practice, this means that decisions made during implementation affect not only the IT architecture, but also the daily work of many teams.

That is why the starting point should be business-led:

business problem → objective → KPI → process → requirements → technology solution.

If this sequence is reversed and the company selects system features first, only to ask later what it actually wants to achieve with them, a gap can quickly emerge between the organisation’s expectations and the final solution.

A new ERP should not automatically reproduce every existing way of working either. If a process has relied for years on manual workarounds, additional spreadsheets or local procedures, transferring them one-to-one into a new platform may simply preserve the same problems.

The role of the project is therefore not only to implement technology, but also to determine how the organisation should work after the change.

What should justify an ERP implementation?

ERP should not be implemented simply because the current system is “old” or competitors use newer solutions. The project should stem from specific business problems or constraints.

Signs that the current environment is no longer supporting the organisation’s growth

One of the most common warning signs is growing information fragmentation. Individual departments work in different systems, data is additionally processed in spreadsheets, and preparing a report requires manually combining information from several sources.

The problem becomes particularly visible when:

• the same data is entered repeatedly in different places;
• teams use different versions of the same information;
• production or inventory planning takes place outside the core system;
• management reporting requires numerous manual operations;
• new integrations become increasingly difficult to maintain;
• changing one process requires modifications across several independent tools;
• the current architecture does not scale with the number of operations, customers, products or locations.

In these conditions, ERP can become a platform for organising processes and data. However, the system itself will not automatically solve organisational problems. If the root causes are unclear responsibilities, disorganised data or inconsistent processes, they need to be addressed as part of the project.

How do you build a business case for ERP implementation?

The business case should connect today’s problems with the specific outcomes expected after implementation. 

Instead of saying we need a modern ERP, it is better to define what the organisation wants to change. 

For example:

• shortening the financial month-end close;
• improving on-time order fulfilment;
• increasing the accuracy and timeliness of inventory information;
• reducing manual data re-entry;
• shortening report preparation time;
• increasing control over product or job costs;
• improving the quality of data used for planning.

Only assumptions defined in this way make it possible to assess later whether the investment actually delivered the expected result.

ERP implementation objectives and KPIs — how do you define project success?

ERP objectives can be considered at several levels. Some will relate to the organisation’s overall strategy, some to specific processes, and others to the technology architecture and data quality.

What matters most is that they are linked to real business problems and can be evaluated objectively.

From a business problem to a measurable objective

“Improving logistics” is a direction, but it is not yet a project objective. The same applies to “better reporting” or “more automation”.

During the preparation stage, it is worth clarifying:

• what exactly needs to change;
• in which process;
• for which user group;
• which metric will be used to assess the outcome;
• when the first effects are expected.

The SMART framework can be used here, but the methodology itself is not the most important point. The aim is to translate broad expectations into decisions that can later guide the project scope.

If one of the objectives is to improve production timeliness, requirements related to planning, material availability or production order reporting will take priority over functions that do not directly affect that outcome.

How do you select KPIs for an ERP implementation?

KPIs should be defined before the project starts. Without a baseline value, it is difficult to assess the scale of change later.

Depending on the implementation scope, they may include:

• process lead time;
• on-time order fulfilment;
• inventory levels;
• number of manually performed operations;
• report preparation time;
• number of data errors or corrections;
• availability of cost and margin information;
• financial period close time;
• number of operations performed outside ERP;
• user adoption of new functions.

Not every metric will improve immediately after Go-Live. Some outcomes require process stabilisation and changes in the way users work. Measurement should therefore continue after the main project phase has ended.

Preparing the organisation for ERP implementation

Many decisions that affect implementation success are made before the actual configuration work begins.

The preparation phase helps organise objectives, processes, data and responsibilities. Without it, the analysis conducted with the implementation partner can quickly turn into a lengthy discussion about how the company actually works and who is authorised to make a specific decision.

AS-IS process audit and TO-BE design

The first step is to understand the current state, meaning the AS-IS processes.

The aim is not simply to create diagrams. It is necessary to establish how the process actually works, where manual workarounds appear, where delays occur and what dependencies exist between departments and systems.

Only then can the TO-BE state be designed — the way the organisation should operate after implementation.

The key principle is simple: a new system should not automate an inefficient process just because the company has been doing it that way for years.

In practice, the analysis may therefore lead not only to a list of ERP requirements, but also to recommendations for changing procedures, responsibilities or information flows.

Project scope — what do we implement now and what comes later?

ERP can cover a significant part of an organisation, but that does not mean every function and every business unit has to go live within a single project.

The scope should clearly define:

• processes included in the implementation;
• system modules;
• companies and locations;
• user groups;
• systems integrated with ERP;
• data to be migrated;
• functions deferred to later stages.

Equally important is the out of scope list, meaning elements deliberately excluded from a given phase.

This helps control one of the main risks in large projects: the gradual addition of new requirements after delivery has already started.

Project team and responsibilities

ERP cannot be solely an IT department project. The team should include people who understand business processes and can make, or prepare, decisions about how the organisation will operate in the future.

Depending on the scale of the project, key roles may include:

• Project Sponsor;
• Steering Committee;
• Project Manager on the organisation’s side;
• Project Manager on the partner’s side;
• Business Owners;
• Key Users;
• IT representatives;
• Data Owners;
• functional and technical experts from the implementation partner.

A RACI matrix can be helpful in defining who is responsible for carrying out a task, who makes the final decision, who should be consulted and who only needs to be informed.

A list of roles alone is not enough. Key Users and process owners must also have protected time to participate in workshops, testing and decision-making.

Data and integration readiness

Data migration should not be the first time the organisation starts assessing data quality.

Before the implementation begins, it is worth taking an inventory of:

• data sources;
• owners of individual data sets;
• duplicates and missing data;
• inconsistent dictionaries and reference data;
• historical data required in the new system;
• current interfaces;
• systems that need to operate alongside ERP;
• dependencies between applications.

This makes it possible to assess the scale of work earlier and avoid a situation where data issues block testing or production go-live.

How do you choose an ERP implementation methodology and strategy?

A methodology structures the way a project is delivered, but it should not be selected simply because one approach is currently more fashionable than another.

The decision depends on factors such as the stability of requirements, the number of integrations, the decision-making model, the ability to phase the solution and the organisation’s tolerance for change during delivery.

Waterfall, Agile or a hybrid approach?

In a Waterfall approach, successive phases are more strongly structured and follow from one another. Greater emphasis is placed on defining requirements, scope and outcomes upfront.

Agile assumes more iterative delivery, shorter cycles and more frequent validation of results.

In practice, large ERP projects do not always fit neatly into one of these categories. Some work may require a stable plan and formal approval gates, while other elements — such as specific extensions or interfaces — can be developed iteratively.

When choosing how the project will be delivered, it is worth assessing:

• how well known and stable the requirements already are;
• which decisions can be made iteratively;
• what dependencies exist between modules;
• when the business can validate successive outcomes;
• how scope changes will be managed;
• which elements require formal approval;
• when integration and end-to-end tests will be carried out.

The methodology should help manage the project, not force the project to fit a rigid theory.

Big Bang or phased implementation?

A separate decision concerns how the system will be launched.

In the Big Bang model, the organisation moves to the new solution at the same time across all areas included in the project. The Phased model spreads the rollout across successive modules, business units or locations.

Big Bang limits the period in which two environments operate in parallel, but it places high demands on data preparation, testing and the go-live plan.

A phased implementation spreads the change over time and makes it possible to learn from successive go-lives. On the other hand, it may require temporary maintenance of additional interfaces and increase the complexity of the transitional architecture.

There is no single model that is right for every organisation. The strategy should be aligned with the processes, dependencies between business units and the organisation’s tolerance for operational risk.

ERP implementation stages step by step

The detailed course of the project depends on the system, the organisation and the chosen methodology. In practice, however, six core phases can be identified to structure the journey from the initial diagnosis to stable operation in the new environment.

Stage 1. Diagnosis — needs, objectives and scope

The diagnosis precedes the main implementation work. Its purpose is to establish why the organisation needs change, which processes should be included and how the outcome will be assessed.

At this stage, the organisation should agree on, among other things:

• business case;
• main project objectives;
• KPIs;
• initial scope;
• stakeholders;
• governance model;
• roles and responsibilities;
• decision-making process.

This is also a good time to formally begin communication around the project. Users do not need to know every technical detail, but they should understand why the organisation is investing in the change and what will be expected of them.

Stage 2. Analysis — processes and Fit & Gap

Analysis turns business objectives into specific system requirements.

The project team works on AS-IS and TO-BE processes, validates user needs and compares them with the standard capabilities of the selected ERP.

A key tool is Fit & Gap.

Fit means that the system standard meets the business requirement.

Gap occurs when the requirement is not covered and a decision is needed: change the process, configure an alternative solution or build an extension.

This is one of the points at which decisions are made that can later have a major impact on cost and the ability to develop the environment.

Not every reported requirement has to be delivered. Prioritisation can use approaches such as MoSCoW, dividing requirements into:

• Must have;
• Should have;
• Could have;
• Won’t have within the current scope.

This helps separate genuinely critical elements from functions that can be moved to later stages.

Stage 3. Solution design

Once the requirements have been approved, the functional and technical design is created.

At this stage, the project defines, among other things:

• module configuration;
• solution architecture;
• data model;
• integrations;
• roles and permissions;
• required extensions;
• information exchange mechanisms;
• migration strategy;
• security and access requirements.

In manufacturing environments, the design may additionally include BOM structures, routings, MRP or APS processes, as well as ERP integrations with MES, WMS, CAD or SCADA systems.

The purpose of this phase is to create an architecture detailed enough for functional and technical teams to move into configuration and build without repeatedly returning to fundamental design decisions.

Stage 4. Configuration, integrations and data migration

At this stage, the designed solution begins to operate in the test environment.

The system is parameterised, required integrations are built and — where justified — functional extensions are developed.

Configuration before customisation

Adapting the system to the organisation does not mean that every difference from the current way of working should result in custom code.

Every customisation should have a clear business justification and take into account its later consequences for:

• maintenance;
• upgrades;
• testing future versions;
• migration;
• integrations;
• the total lifecycle cost of the system.

If standard functionality can support the process without losing key business value, adapting the process is often more rational than extending the system.

This does not mean abandoning extensions altogether. In some organisations, a specific process genuinely represents a source of competitive advantage and requires an individual solution. The important point is that this should be a conscious decision.

Data cleansing and migration

Migration is not simply the technical transfer of records from the old database to the new one.

Data may contain:

• duplicates;
• inactive master records;
• different formats;
• inconsistent naming;
• missing values;
• information that should not be migrated.

The migration process should therefore include:

inventory → cleansing → mapping → trial migration → validation → production migration.

Data Owners play an important role here. These are the people who are accountable from the business side for a specific data domain. They should confirm that data after migration is complete, correct and ready to be used in production processes.

Stage 5. Testing, training and Go-Live preparation

A system that works technically is not yet ready to go live.

Before Go-Live, the organisation needs to verify not only individual functions, but above all processes that span multiple modules and systems.

UAT and end-to-end testing

UAT — User Acceptance Testing — is the phase in which business users verify whether the solution correctly supports real-world work scenarios.

Testing should cover complete end-to-end flows.

In a manufacturing company, this could mean testing the process from demand and material availability, through order execution, to product receipt, shipment and financial settlement.

This helps identify issues that are not visible when individual modules are tested in isolation.

Testing should also cover:

• integrations;
• roles and permissions;
• reporting;
• performance;
• exception processes;
• data after trial migration.

User training

Training should not be limited to demonstrating the interface.

Above all, users need to understand how they will carry out their process after implementation and how the way they enter data affects subsequent stages.

In large organisations, the Train the Trainer model works well: Key Users or designated trainers first gain in-depth knowledge and then pass it on to subsequent groups.

This approach also helps retain competencies within the organisation after the project ends.

Stage 6. Go-Live, Hypercare and stabilisation

Go-Live is the point at which the organisation moves to the production environment, but it is not the end of the implementation work.

Immediately before launch, the cutover plan is executed, covering final data migration, integration activation, process switching and verification of team readiness, among other activities.

After launch, the Hypercare period begins — a phase of more intensive user support and rapid response to issues that emerge in real-world operation.

At this point, tickets should be classified according to their impact on the process:

• issues that block operations;
• issues that limit work;
• issues that do not critically affect continuity;
• development needs that do not require immediate change.

Once the environment has stabilised, responsibility gradually moves to the target maintenance and development model.

Change Management — how do you prepare employees for the new ERP?

Even a well-designed and thoroughly tested ERP will not deliver its full value if the organisation bypasses the new processes.

A system change often means greater standardisation of work. Information that could previously be added later or handled outside the system becomes an essential part of subsequent process steps.

For users, this may initially feel like an additional obligation. That is why Change Management should be part of the project from the beginning, not an activity introduced only shortly before training.

Change communication

Communication should primarily answer the questions users are likely to have:

• why is the company changing the system;
• what exactly will change in my work;
• which problems is the new process intended to solve;
• when will the change take place;
• where can I get support;
• how can I report an issue or need.

A generic message about “digital transformation” is not enough. The closer the organisation gets to Go-Live, the more specific the information for individual teams should become.

Key Users as the link between the project and the business

Key Users are particularly important because they participate in the project at several stages.

They support:

• process analysis;
• requirements validation;
• UAT testing;
• scenario preparation;
• training;
• Hypercare;
• feedback collection.

This means that after the system is launched, the organisation is not entirely dependent on the external implementation team.

How do you measure User Adoption?

User adoption can also be measured.

Depending on the project, it is worth analysing, for example:

• use of new functions;
• number of processes still performed outside ERP;
• errors caused by incorrect system use;
• number of support tickets;
• training completion;
• use of prepared instructions;
• compliance with new procedures.

This makes it possible to distinguish a technology problem from a situation in which the solution works correctly but has not yet been sufficiently adopted by the organisation.

How long does an ERP implementation take and what affects the timeline?

There is no single universal ERP implementation timeframe.

A project covering one organisational unit and a few core processes will have a different scale from an environment transformation across a corporate group involving multiple locations, systems and integrations.

The timeline is primarily influenced by:

• functional scope;
• number of companies and locations;
• number of users and processes;
• number of integrations;
• scale of migration;
• condition of source data;
• number of required extensions;
• availability of the business team;
• Big Bang or Phased model;
• number of test cycles;
• time required for approvals.

The biggest mistake is to build the schedule solely around the time the technical team needs for configuration.

In large projects, a significant part of the calendar is taken up by workshops, business decisions, data preparation, testing and rework.

How do you build a realistic implementation schedule?

The schedule should include not only activities, but also decision points and dependencies.

It is worth defining:

• milestones;
• exit criteria for individual phases;
• data delivery deadlines;
• migration windows;
• test cycles;
• approval deadlines;
• the scope freeze point before Go-Live;
• cutover plan;
• Hypercare period.

If one of the key stages slips, the impact on the entire project should be assessed instead of trying to recover time by shortening testing or limiting training.

How much does an ERP implementation cost and what affects the budget?

The cost of ERP implementation is not limited to the licence price.

The total budget may include:

• licences or subscriptions;
• analysis and implementation services;
• infrastructure;
• integrations;
• data migration;
• functional extensions;
• training;
• involvement of the internal team;
• testing;
• post-go-live support;
• ongoing maintenance and development.

When comparing proposals, it is therefore worth analysing the scope of the entire solution, not just a single rate or the cost of the technology.

What most often increases project costs?

One of the main factors is a change in scope after delivery has already started.

If requirements emerge only during configuration or testing, the change may require redesign, additional technical work and another round of testing.

Costs are also increased by:

• poor data quality;
• more integrations than originally assumed;
• extensive customisation;
• unclear requirements;
• delayed decisions;
• limited availability of Key Users;
• process changes after design approval;
• expanding the number of business units included in the go-live.

Good cost control is therefore not only about negotiating rates. Above all, it is about controlling project decisions.

The most common risks and mistakes in ERP implementation

Risks should be identified as early as possible and assigned to owners. This prevents the project from reacting only once an issue is already affecting the schedule or Go-Live.

The risk register should be a living part of the project and updated as new information emerges.

How do you assess whether an ERP implementation has been successful?

Launching the system on schedule is an important milestone, but it does not in itself mean business success.

After stabilisation, the organisation should return to the KPIs defined before the project.

The assessment may include:

• process lead times;
• data quality;
• number of manual operations;
• on-time performance;
• inventory control;
• reporting quality;
• availability of management data;
• integration stability;
• user adoption levels;
• number of processes still performed outside ERP.

If the results differ from the assumptions, this does not always indicate a technology problem. The issue may lie in process configuration, data, the way the system is used or objectives that were poorly defined from the outset.

That is why post-implementation analysis should look not only at the results themselves, but also at the causes of any deviations.

What happens after ERP implementation? Maintenance, optimisation and development

An ERP system should not “freeze” once Hypercare ends.

Processes, the company’s offering, organisational structure, regulatory requirements and the technology landscape all change. New user needs also emerge — needs that did not exist during the initial implementation or were deliberately left outside the original scope.

After stabilisation, the next cycle begins:

maintenance → observation → optimisation → development.

This may include:

• improvements to existing processes;
• new modules;
• reporting development;
• integrations;
• end-to-end process automation using ERP and RPA; 
• additional organisational units;
• platform upgrades;
• reducing accumulated technical debt.

In a mature ERP environment, system development should be linked to the organisation’s business roadmap rather than reduced to responding to individual tickets.

Checklist before starting an ERP implementation

Before entering the delivery phase, it is worth checking whether the organisation has the basic project foundations in place:

• Defined business case.
• Agreed objectives and KPIs.
• Defined in-scope and out-of-scope boundaries.
• Appointed Project Sponsor.
• Established Steering Committee and decision escalation process.
• Selected Business Owners and Key Users.
• Documented key AS-IS processes.
• Defined core TO-BE assumptions.
• Completed initial data inventory.
• Identified integrations and dependent systems.
• Selected system rollout strategy.
• Prepared rules for managing scope changes.
• Protected capacity of the business team.
• Planned communication and Change Management.

If some of these points are still open, it does not mean the project cannot start. They are, however, a useful indication of which areas need to be clarified during the pre-implementation analysis.

ERP implementation FAQ

A well-planned ERP implementation is the beginning of system development, not the end of the project

Successful ERP implementation requires technology to be combined with knowledge of processes, data and how the organisation operates.

Choosing a platform alone will not fix inconsistent processes, automatically clean up data or make users adopt a new way of working. Success depends on the quality of the analysis, the solution design, business engagement, consistent scope management and the organisation’s readiness for change.

At MINDBOX, we therefore look at ERP projects through a Human + Tech perspective. Technology is a tool for transformation, but its value emerges only when it supports well-designed processes and people who know how to use it.

A well-planned implementation also creates a foundation for further change: automation, integration of new solutions, use of data and continued modernisation of the IT environment.

If your organisation is preparing for an ERP implementation or modernisation, it is worth starting by organising processes, objectives, data and the solution architecture. MINDBOX can support this journey from pre-implementation analysis and implementation through to stabilisation and further system development.