Defining the requirements for an ERP system correctly: Why a wish list is good, but too many cooks spoil the broth

10.06.2020 ‐ Gerrit Pohl General

Gathering and selecting the requirements for a new ERP system is not an easy task. It can even be the most difficult part of the whole process, because it is an essential yet highly challenging task to bring the management’s ideas and the staff’s wishes together into one coherent whole. Many of us know from various projects how quickly discussions can degenerate once too many people and interest groups are involved in the decision-making process.

Top-down vs. bottom-up approach

There are different ways of defining the requirements for a new ERP system: the top-down or the bottom-up approach. With the top-down approach, management defines the requirements and the employees have to work with the system provided. In the bottom-up approach, the requirements are determined according to the wishes of the staff in each department.

The advantage of the top-down approach is that fewer people are involved in the decision-making process, making it less complex. This saves time and resources and projects can be completed faster and more cost-effectively. A disadvantage of this approach is that the wishes of the employees who ultimately work with the system are not sufficiently taken into account. As a result, they may feel ignored, the project could face internal resistance and the new system may not be accepted.

The bottom-up approach focuses on the wishes and requirements of the staff. But this is exactly where the challenge lies. Experience has shown that when introducing a new system, the employees take this opportunity to express all of their wishes, because they know that the next possible opportunity may not be for several years. This often leads to a very long wish list, and the cost to benefit ratio is pushed into the background. Furthermore, very few employees are fully aware of management’s strategic plans for the future of the company. This results in a lot of time and effort on the administrative side to ensure that only the requirements that are actually needed and make economic sense are in fact implemented.

It’s all in the mix

Maybe you know it from your current system. Do you really use all of the features? Or do you only use a fraction of the functions that were developed at great cost?

Let’s imagine the following scenario that often occurrs in practice: At the request of your financial accounting manager, the existing, somewhat outdated (but from his point of view irreplaceable!) accounting software had to be connected to your new ERP system by means of an expensive interface. Would you have prefered to follow your own instinct and opt for a system with an integrated accounting module? This would have caused initial resistance from your accounts department, which is understandable. Because after all, getting used to something new can cause pain and setbacks, especially in the initial phase. But in retrospect, would it perhaps have been a cheaper and better solution, especially with regard to the future?

Even if this is a fictional example, perhaps you have had a similar experience. That is why when using the bottom-up approach, it is important to make sure that the wish list is consistent with management requirements. After all, wishes often arise from what we are familiar with. But here is the question that we must ask ourselves: Are the existing processes compatible with the way the company wants to develop in the future?

Identifying the correct key users

You already guessed it, neither a pure top-down nor a bottom-up approach is the answer. Both approaches have advantages that we can profit from, but they also carry risks that need to be taken into account. So how should you proceed? In order to gain the greatest possible benefit from a new system, it is imperative to take into account the requirements of the end users and thus ensure that the changeover from the old to the new system is as smooth as possible and that acceptance is as complete as possible. To avoid too many cooks spoiling the broth and to create a wish list that is as structured as possible without making it too extensive, it makes sense to identify certain employees from the departments who are especially qualified to work on this, so-called key users. These key users should have a qualified overview of the wishes of their departments. They should be very familiar with the department’s processes and they should also have the energy and motivation to be involved in the project. For example: A young, new employee wants to prove himself, especially at the beginning of his career, is full of energy and is highly motivated, but does not know the processes of the department as well as a long-standing member of staff. The department manager on the other hand, knows the processes well. However, there is a great danger that she will have to deal with so many other projects at the same time that she will initially take a half-hearted approach. As the selection of the right people is extremely important at this point, a good IT partner will actively support you in this step, within the framework of change management.

When management’s company-specific and future focused knowledge is brought together with the task-oriented expertise of key users and the experience of a software service provider consultant, who knows exactly how this knowledge can be used, a catalogue of requirements can finally be created that takes the interests of all stakeholders into account.

Set priorities using MoSCoW

Once the catalogue of requirements has been drawn up, it must be prioritised in order to make a realistic and feasible timeframe and budget for the project. An approach we like to use is the MoSCoW method. It divides your requirements into the categories “must have”, “should have”, “could have” and “won’t have”.

Requirements that are marked with must have are critical for the operations of the company and essential for the success of the project. If even one must-have requirement is not included, the project should be considered a failure. However, must-have requirements can be downgraded when using agile project methodology if, for example, new requirements are deemed to be more important. For example, connection to weighing apparatus is one such requirement that is considered a must have for waste management and recycling companies and is thus critical to the success of a project.

Requirements that are classified as should have can be just as important as must haves but are often not as urgent or there is another way to fulfill the requirement. Provided that a should does not interfere with a must, these requirements should also be implemented. In practice, a DMS system is often classified as a should have. This is often implemented in the second phase of a project in order to focus on the ERP system in the core phase.

Requirements that are classified as could are desirable but not necessary and could improve the user experience or customer satisfaction with a small amount of effort on the part of the developers. These are usually included when time and resources allow. A customer login platform is currently a good example of a could have requirement.

Requirements marked won’t have, are the ones that are regarded by the stakeholders as the least important, with the smallest amount of payback or that are not necessary at the time. As a result, requirements marked won’t have are not scheduled for the project or subsequest implementation. These requirements are either dropped or reconsidered for inclusion at a later date. For example, if you only have a few vehicles in your fleet, a graphical route planning tool might be a won’t-have requirement.

This kind of prioritisation provides a clear overview of what is really needed. Once this has been achieved, it is much easier to make decisions. It also makes it possible to stagger the project, for example by having all of the must-have requirements ready for the go-live and then successively implementing the other requirements during operation.

Summary

When introducing new business software, it is important to select the right employees to be involved from the outset. The requirements analysis should be carried out in cooperation with a specialist IT service provider. Subsequent prioritisation is important for the timely and economic success of the project.