Traditional business software – whether it concerns standard packages or customized development – has a number of problems. It is dependent on the...
From package to model supplier
Every company that uses packaged software, sooner or later, runs up against the same problem, namely that the supplier provides its package as ‘standard’. In itself this is not a problem if the customer leaves it like that, but unfortunately this ‘standard’ solution very rarely matches what the customer actually needs. All their additional requirements are subsequently included in customization, and then the misery begins…
Modifying or expanding packaged software with customization has the consequence that the software is no longer so easy to upgrade to new versions. Upgrading incures additional costs doe the customer or he must continue to use the old version. Not having any customization is usually also not an option.
This normally determines how satisfied the customer is with the package, and the additional work is of course an important source of revenue for the package supplier. In the long-term however this customization becomes an ever greater problem, upon which many IT projects have floundered.
One package for everybody?
A package supplier can resolve the customization problem by including the additional functionality and configuration possibilities in the standard. This leads however to an extremely extensive software package of which an individual customer only uses a small part. As a consequence the rest of the functionality must then be disabled on the basis of thousands of parameters with all kinds of dependencies. Moreover, along with the costs for this personalization it can have a negative effect on the performance of the software. In short, this is not a very good solution. Branch specific packages are also available as an option. These often result in higher customer satisfaction than the generic packages. This is primarily because of the size of the software. This only contains the functionality that is really necessary in a specific branch. This is indeed a good starting point, but at a given moment this software also runs up against problems as soon as a new technology is announced.
Dealing with new technology
For a package supplier it is often very difficult to convert a package to new technology. Think as an example about the step from DOS to Windows, to web technology or apps for tablets and smartphones. Within the software you also have to deal with all kinds of different programming languages and technologies that make the development even more complicated. If a package supplier also supplies customization to its customers, it just increases this problem. Because how does the supplier integrate all this customization into the new technology? This is the reason that they often already stipulate in a contract that the customer’s customization is not part of the standard upgrade to a new software version. This means that a customer must have the customization developed again or must remain with the old version of the package. Incidentally the maintenance costs associated with this last option often increase annually because the supplier wants to discourage the customer from continuing to use this outdated software.
Emergence of the model supplier
major advantage is that the supplier with a low-code model-driven version of its package never has to re-build its software and can even offer the customer customization without it becoming a dead-end street. A real win-win situation for both parties!