A new ERP promises a lot: all data in one place, no more lists alongside the system, reports at the push of a button. The implementation itself, however, is one of the biggest projects a business takes on. Every area is affected, every employee has to relearn, and the data from the old system has to come across cleanly.

The sequence is the same for almost every implementation, whether it becomes a standard system or a solution tailored to your workflows. This guide describes the steps, the typical mistakes and the questions to settle before you start.

Taking stock

The start is not choosing a system, but asking what the business does today. Which workflows are there, from order receipt to invoice? Which special routes have grown up over time? Which lists, mailboxes and notes run alongside the old system? And which other programs depend on it, such as the web shop, accounts or shipping?

The best way to see this is at the workplace: watching a real order travel through the business. How to write it down without producing a thick binder is described in the guide Documenting business processes.

Sometimes taking stock also shows that no new ERP is needed at all. In eight questions, our system check assesses whether your system should be kept, extended or replaced.

Selection and concept

Taking stock produces a list of requirements: what the new system must do, what would be good to have, what can go. The important split is between what every business in your industry needs and what only your business does this way. A standard usually covers the first well. The second decides the choice: does it fit into the settings of a standard system, or does it need workflows of its own? For the second route, besides building everything from scratch, there are foundations that bring the usual parts and leave room for your own. ElbDesk, the foundation we build on, is one of them.

Then comes the concept: how the workflows will look in the new system, which roles there are, which systems are connected, through interfaces where possible. The guide High-level and detailed concept describes how to get from the rough picture to the detail.

Data migration

Customers, suppliers, items, prices, open orders: without this data the new system is empty. Migration usually takes more effort than expected, because the data in the old system has become inconsistent over time. Duplicate customers, outdated items and fields that everyone filled in differently come to light at the latest now.

So clean up before the data moves, not afterwards. How migration is prepared in trial runs is in the guide on moving old data to a new system.

Testing and acceptance

Before the new system goes into daily use, it is checked with real workflows: a typical order, a complaint, a credit note, the month-end close. The checking should be done by the employees who will later work with it, not only by the project lead. They know the special routes that are in no concept.

Testing needs a separate test environment with real, migrated data. How acceptance works is described in the guide Acceptance and test environment.

Training

The best software does not help if employees work around it. Train along your own workflows, not along the menus. Someone in the warehouse does not need to know how accounts post, but must master every step in their own area with confidence.

It has proven useful to name one person in each area who knows the system particularly well and answers colleagues’ questions first. Day to day, they are the first point of contact.

The switch

There are two routes for the switch. With a cut-over date, the old system is switched off and the new one switched on on a fixed day, all areas at once. With a step-by-step switch, one area moves after another, and the old system keeps running for the rest. Which route fits depends on the size of the system and on the risk the business can carry. The guide Cut-over date or step by step compares both.

When replacing a system, we take the step-by-step route and develop on ElbDesk.

Operation

The implementation does not end with the switch. After go-live, questions and small errors turn up that nobody noticed in testing. Decide beforehand who takes them in, who decides and how quickly there is a response. After that, new requirements arrive, and the system grows with the business.

Typical mistakes

  • The system is chosen before the workflow. Whoever buys first and then checks what the business needs ends up adapting the business to the software.
  • The data is looked at too late. If the mess only shows up during migration, there is no time left to clean up.
  • Employees only join for the training. Those who were not asked during concept and testing only find the gaps in daily work.
  • Every special request is built in. Not every old detour deserves a place in the new system. Some workflows get better when they are simplified.
  • Operation after go-live is not planned. Without a fixed contact, questions end up in somebody’s mailbox.

Questions before you start

  • Which workflows must the new system cover, and which run alongside the old one today?
  • Who in the business knows the special routes, and does that person have time for the project?
  • What state is the data in that is to be migrated?
  • Which other systems need to be connected?
  • Cut-over date or area by area, and what does the way back look like if something does not work?
  • Who is the day-to-day contact after the switch?

If you can answer these questions before asking for quotes, you will talk to vendors as an equal and quickly see who has understood your business.