Customizing the ERP system – good or bad?

Most organizations today have the insight that as a customer you should keep down the number of customer-unique customizations. This has come as an insight after many years of painful upgrades, and where one of the reasons for the problems has been the customer’s customizations. During the 1980s and 1990s, it was quite common for the vendors of ERP systems to show great willingness to customize, and in some cases even to encourage customers to make unique customizations. This to be able to offer a system solution that was completely tailored to the customer’s unique needs. After a few years, however, most customers began to realize that the price in the long run became very high as each upgrade became both complicated and expensive. And over time, these customizations became a direct obstacle to the continuous development of the business.

The thing to remember when it comes to “the old days” customizations was that customers often had several hundred of customizations and where these customizations were poorly documented and lacked traceability. The result was that the consultants who later worked with the upgrades had to work blindly and without knowledge of the logic that was built into the customizations. The result was thus messy with many tests and fire alarms once the upgrade was to be performed. For some customers, the upgrade also meant that several functions were actually “downgraded” when they were forced to give up some features that were built into the customizations.

If we move to 2021 and look at how the vendors act today, we can state that most vendors try to persuade the customer to refrain from customizations. The model today is that the customer should use the system’s standard processes and, as far as possible, try to adapt their processes to the system’s flows. And if we add so-called public cloud systems, it is in many cases not even possible to make customer-unique customizations as the source code is common for all customers.

Does the above mean that it is only good to refrain from unique customer customizations? To answer this question, one should define what lies in the concept of “customization”. In the past, customization meant making changes and additions to the system’s source code, which in the long run was bad for both the customer and the vendor. Over the past 15 years, however, we have seen that most business systems have significantly improved opportunities for “configuration” and where the system’s processes and functions can be influenced to better support the customer’s unique needs. In some cases, only with standard parameter setting and other cases via a combination of parameter setting and additional scripting (outside the source code) or standardized APIs. This should also be considered as a form of customization, but where the customer does not become as bound as when the source code changes.

Custom customizations via change of source code should always be avoided. On the other hand, making adjustments in the form of scripts outside the source code can be justified if the customer has unique needs. It is important to understand that the term “standard system” means that the system is used by many customers, which is not the same as the system actually being suitable for all customers. And there are actually many organizations that have become successful based on the fact that they work differently compared to other organizations. And in these cases, it is justified to find a system solution that affirms the customer’s identity instead of forcing the customer to change their processes to become equal to the competitors.

The basic principle should be to follow the system’s standard processes as far as possible but accept customizations where they can be commercially justified. But it is also important to think long-term and ensure that the customization is implemented and maintained so that it follows the development of the system and does not become a future obstacle.

The best for all parties is, of course, that the customer finds a system with such a high degree of flexibility that the customer reaches optimal flows without the need for customization. And in the choice between a standard system with high functionality but with lack of flexibility and a system with lack of functionality but with high flexibility, the choice may just as well land on the latter alternative. Flexibility is nowadays more valuable than “standard” to give the customer the opportunity to change and develop their business over time.

It is important to keep in mind that both “standard” and “flexibility” have their price, but from different perspectives and with different consequences as a result. Today, it is not the “customizations” themselves that are the problem for the customer, but the lack of flexibility that requires the customization.