Why is ERP implementation so difficult?
Why is an ERP implementation so difficult? I read and hear it all too often, and judging by the responses to the first part of this blog, it is a ‘hot topic’. In this first blog, I gave 5 tips. If you have not read them yet, read them first. In this follow-up, I will go into more detail about what is involved in an ERP implementation and help you with tips 6 through 10.
Haven’t read the first part yet? Why is an ERP implementation so difficult?
6. Ensure you have a good project team
In the first part of this article, it became clear that success starts with good preparation. The preparation itself is already a project. But no matter how well the preparation has gone, success depends on a good project team and good project management. A good team and the right project manager are worth their weight in gold; they will have to make the project a success. Make sure that every discipline within the company is represented in the project team.
Great stories have a personality. Consider telling a great story that gives personality. Writing a story with personality for potential customers helps build a relationship. This is reflected in small quirks such as word choices or turns of phrase. Write from your point of view, not from someone else’s experience.
Great stories are for everyone, even if they are written for one person only. If you try to write with a broad, general audience in mind, your story will sound fake and lack emotion. No one will be interested. Write for one person. If it is real for one, it is real for the rest.
And I cannot say it often enough. Implementing an ERP system is a project. So make sure that the people selected for the project are (partially) freed up for it. An ERP implementation is not something you just do on the side. If you want to be successful, the people involved really need to be given sufficient time by senior management.
7. Use scenarios
As soon as the project team has been formed, start creating usage scenarios. A usage scenario or scenario, in short, describes a real example of how one or more people or organizations actually work with the system. They describe the steps, events and/or 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 a more general description of the critical actions, without indicating exactly how these are carried out.
Create several scenarios for each process that clearly describe the current way of working. If it is already clear that a particular way of working needs to be adjusted, it makes sense to describe the desired way of working. You can use these during software selection. You can ask software vendors to demonstrate this case in their ERP system.
The scenarios are not only a useful aid in software selection, but further along in the process they also serve to set up test scenarios.
8. Choose a project methodology
There are different methods for approaching a project. I do not think there is a good or bad project methodology, but which methodology is most suitable depends on the organization, the size of the organization, and the expected complexity of the project. At the extremes, people speak of waterfall-based methods and Agile project methods. In a waterfall method, the project is phased, and the project phases are described and handed over in a very formal and structured way. This assumes that it is exactly clear at the start of the project what needs to be built. Changes along the way are possible, but costly.
My preference is for an Agile project approach. In an Agile project method, it is not entirely clear in advance what needs to be built. The project goes through a more evolutionary process. The project is divided into short work segments (called iterations or sprints). After each sprint, a part is delivered, assessed and, if possible, even put into operation. Because each sprint is delivered to the end user, better collaboration arises and you receive feedback sooner. This feedback is incorporated directly into a subsequent sprint.
The disadvantage of Agile, however, is the speed at which work is done. Sprints follow each other quickly and decisions must 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 do not work only with sprints, but also with ‘milestones’. For example, toward sprint 3. After this milestone, I often advise taking a pause and skipping 1 sprint. It gives everyone the opportunity to properly evaluate what has been produced once again. Prevent quality from being overshadowed by too rapid a succession of sprints.
9. Customizing the ERP system
A large part of the implementation lies in adapting the standard software so that it is made suitable for the purpose. No functionality is added; instead, existing functionality is modified. Think of screens, workflows and reports. It is possible that these adjustments are made through the software interface. The adjustments are then stored in the system database. If the software allows it through 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 making these adjustments through the interface as much as possible. It is better to define these adjustments in software code and have the system execute them. By recording all adjustments in code, it is always clearly documented what has been changed (and of course you can also document why). For future updates, you can also test this code (automatically) against the new version.
Adjustments made through the interface are often done more quickly, and that is also the danger. Adjusting a screen here and adding an extra field there. Afterwards, no one remembers that these adjustments were made, and everyone thinks it is standard. Adjustments written in code are at least safeguarded.
10. Custom software
Custom software. For many, it is a daunting word and stands for problems. I do not agree with that. Customization is an opportunity to make your software perfect. The first consideration you need to make is whether the customization truly has added value. The approach is not to look at how much it costs to create the customization, but first to calculate what it costs if you do not have the customization made and start working in the standard way. If you know what it costs you per year to do nothing, then you also know what the customization may cost (assume a period of 7 to 8 years that you will be working with the software).
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 software development. It does not have to be difficult, but you do need the necessary experience with the ERP system’s framework used and with software development itself. So ask for examples that the supplier has already created 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 lies 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 in the preparation phase. We still need to choose a package and implement it. Follow us and we will let you know when the next blog is available.
