Why is an ERP implementation so difficult?

And I can't say it often enough. Implementing an ERP system is a project. So make sure that the people selected for the project are (partially) released for this. You don't just add an ERP implementation. If you want to be successful, people really need to be given enough time for this by upper management.

7. Use scenario's

As soon as the project team has been formed, we start creating usage scenarios. A use case, or scenario for short, describes an actual example of how one or more people or organizations actually work with the system. They describe the steps, events, and actions that occur while using the system. Usage scenarios can be very detailed and describe exactly how someone works with the user interface (the screens, buttons, reports, etc.). But it can also be more of a more general description of the critical actions, but then it is not indicated how exactly they are carried out.

Create several scenarios for each process that accurately describe the current working method. If it is already clear that a certain working method needs to be adapted, it is useful to describe the desired working method. You can use this in the package selection. You can ask suppliers of the software to demonstrate this case in their ERP system. 

The scenarios are not only a good tool for package selection, but they also serve to set up test scenarios later in the process.

8. Choose a project methodology

There are different methods of tackling a project. I don't think there is a good or bad project method, but it depends on the organization and size of the organization and the expected complexity of the project, which method is best suited. In extreme, one speaks of waterfall-based methods and Agile project methods. With a waterfall method, the project is phased, and the project phases are described and transferred in a very formal and structured way. It is assumed that at the start of the project it is exactly clear what needs to be made. Changes along the way are possible, but costly.

My preference is a Agile project approach. With an Agile project method, it is not entirely clear in advance what needs to be made. The project is going through a more evolutionary process. The project is divided into short work parts (called iterations or sprints). After each sprint, a part is delivered, assessed and, if possible, even put into operation. Because every sprint is delivered to the end user, better cooperation is created and you receive feedback sooner. This feedback is immediately processed in a subsequent sprint.

The disadvantage of Agile is the speed at which work is done. Sprints follow each other quickly and decisions have to be made (very) quickly. Although I believe that a wrong decision is often better than no decision. In the start-up phase, it is therefore important to look at the availability of the project team and how long a sprint should last. And don't just work with sprints, but also with 'milestones'. For example, to sprint 3. After this milestone, I regularly recommend skipping a moment of rest and 1 sprint. It gives everyone the opportunity to properly evaluate what has been produced. Prevent quality from being snowed under by too fast succession of sprints.

9. Adjusting the ERP system

A large part of the implementation is in adapting the standard software so that it is suitable for the purpose. No functionality is added, but existing functionality is modified. Think of screens, workflows, and reports. These adjustments might be made through the interface of the software. Adjustments are then stored in the system's database. If the software allows it via the interface, it is tempting to also add fields to the database and include them in the screens.

My opinion is that you should avoid these adjustments via the interface as much as possible. It is better to record these adjustments in software code and have them implemented by the system. By recording all changes in code, what has been changed is clearly documented at all times (and you can of course also document why). You can also test this code (automatically) against the new version for future updates.

Adjustments via the interface are often made faster, and that is also the danger. Customize a screen here and an extra field there. No one knows afterward that these adjustments were made, and everyone thinks it is standard. Changes written in code are in any case guaranteed.

10. Custom software

Custom Software. For many it is a deterrent word and guarantees trouble. I do not agree with that. Customization is an opportunity to make your software perfect. The first consideration you have to make is whether the customization has real added value. The approach is not to look at how much it costs to make the custom work, but to first calculate what it will cost if you do not have the custom work made and start working in the standard way. If you know what it will cost you per year to do nothing, then you also know what the customization may cost (assume that you work with the software for 7 to 8 years).

Keep in mind that not every ERP System is suitable for customization. So if you need customization, select a package and a supplier with a track record in the field of software development. It doesn't have to be difficult, but you do need to have the necessary experience with the 'framework' of the ERP System used and the development of software itself. So ask for examples that the supplier has already made and delivered.

And to ensure future compatibility, you can make agreements with your supplier. For example, you can take out a maintenance contract that guarantees migration of the software to future versions.

Success is in the preparation, and I have now shared 10 points with you that give you a greater chance of a successful ERP implementation. But we are still preparing. We still have to choose a package and implement it. Follow us, and we will inform you when the follow-up blog is available.