Published
Author
Most organisations today understand that as a customer, they should keep the number of customer-specific customisations low. This insight has come after many years of painful upgrades, where one of the causes of the problems was the customer's customisations. During the 1980s and 1990s, it was quite common for vendors of ERP systems to show a great willingness for customer customisations, and in some cases even encouraged customers to make unique customisations. This was a way to offer a system solution that was completely tailored to the customer's unique needs. However, after a few years, most customers realised that the long-term cost was very high as every upgrade became both complicated and expensive. Over time, these customer customisations became a direct obstacle to continuous business development.
What one should remember about "past" customisations is that customers often had several hundred customisations that were poorly documented and lacked traceability. The consequence was that the consultants who later worked on the upgrade had to work blindly and without knowledge of the logic embedded in the customisations. The result was chaotic, with many tests and emergency fixes when the upgrade was finally carried out. For some customers, the upgrade also meant that a number of functions were actually "downgraded" as they had to give up some features embedded in the customisations.
If we move to 2019 and look at how vendors act today, we can observe that most vendors try to persuade the customer to refrain from customisations. They advocate that the customer should use the system's standard processes and try, whenever possible, to adapt their processes to the system's flows. Adding the so-called public cloud systems, it is often not even possible to make customer-specific customisations as the source code is common to all customers.
Does the above mean that it is only beneficial to refrain from customer-specific customisations? To answer this question, one should define what is meant by "customisation". In the past, customisation meant making changes and additions to the system’s source code, which in the long term was detrimental both for the customer and the vendor. Over the last 15 years, however, we have seen that most ERP systems have significantly improved possibilities for "configuration", where the system’s processes and functions can be influenced to better support the customer’s unique needs. In some cases only by standard parameter settings, and in others through a combination of parameter settings and additional code via scripts (outside the source code) or standardised APIs. This should also be considered a form of customisation, but where the customer is not as tightly bound as when the source code is changed.
Customer-specific customisations by changing the source code should always be avoided. However, making customisations in the form of scripts outside the source code can be justified when the customer has unique needs. It is important to understand that the concept of a "standard system" means that the system is used by many customers, which is not the same as the system actually fitting all customers. There are indeed quite a few organisations that have become successful based on working differently compared to other organisations. In these cases, it is justified to find a system solution that embraces the customer's identity instead of forcing the customer to change their processes to become like their competitors.
Customer-specific customisations by changing the source code should always be avoided. However, making customisations in the form of scripts outside the source code can be justified when the customer has unique needs.
The basic principle should be to follow the system’s standard processes as far as possible but accept customisations where they can be justified commercially. But it is also important to think long-term and ensure that the customisation/addition is implemented and maintained so that it follows the system’s development and does not become a future obstacle.
Best for all parties is obviously that the customer finds a system with such a high degree of flexibility that they achieve optimal flows without the need for customisation. And when choosing between a standard system with high functionality but lacking flexibility and a system with limited functionality but high flexibility, the choice could well fall on the latter option. Flexibility is nowadays worth more than "standard" to give the customer the ability 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. It is not the "customisations" themselves that are the problem for the customer today, but the lack of flexibility that forces the customisations.
