If you have ever implemented an enterprise software, such as an ERP or WMS, then you know that at some point in the implementation process you will reach the limits of what can be configured. Then the somewhat daunting question of whether or not to customize must be addressed.
In this paper, we will look at the advantages and drawbacks of each software adaptation method. We will then propose how to use both in order to maximize your enterprise investment.
Configuration is the process of modifying the behaviour of an application by setting the parameters. For instance, defining FEFO manipulation of products in a WMS. Configuration, when simple, is usually inexpensive for the licensee to set up. Furthermore, because it was designed by the software editor, it tends to hold up well to upgrades.
There are, however, limitations to configuration. Firstly, you can only configure for logic that the software editor has conceived of. Configuration is generally available for industry specific best practices. If, however, the logic you want to implement is less common or very specific to a small industry, it is less likely that the configuration method will satisfy your requirements. Secondly, if the application offers too many configuration parameters for a single process, you could end up with some configuration settings that will trigger unexpected (and undesired) behaviors in the process logic.
Customisation is the process of modifying the behaviour of an application by either adding or modifying code within the application. This generally requires a new software build, however some applications allow the customised code to reside within the database. Customisation offers more flexibility to the licensee because it allows the modification of the application behavior in ways that were not anticipated by the software editor - a ‘Do it your way approach’. This is, therefore, the preferred method of adapting the system to industry or organization specific processes. This is good as long as the licensee’s processes are operationally optimal.
One drawback of customisation is that it can be more expensive to implement since it requires programming skills specific to the application. There is also the issue of dependency to consider. When a customisation relies on code that has been changed in a new version, it is highly possible that the customisation could break on software upgrades. This is why enterprise software upgrades require a lot of customisation maintenance. This makes upgrades costly, in some cases a sizable portion of the initial implementation cost. Customization will allow the owner to achieve a solid ROI. The cost of ownership over the long term, however, could be significantly higher than planned if and when upgrades are done.
But does this really have to be the case? Couldn’t it be possible to customise an application, yet go through painless software upgrades? Could the licensee keep its valued customisations intact, while at the same time enjoy the benefits of upgrading parts of the application that were not customised?
There is a way to do this: by protecting customisations and all their dependencies. If, for example, your enterprise application has data display pages and data modifying processes, you can protect customisations by simply creating a copy of each customised page or process. All redirections to the original version are re-linked to the new copy.
Let’s use a tree analogy. The roots of the tree represent the framework of the application, the trunk its core functions, and the branches are the processes and pages displaying application data. You want to allow customisation only on branches, thus producing only a local effect. Protecting a customised branch would be the equivalent of grafting the branch on the trunk or on its parent branch. The tree will continue to grow, other branches will evolve, some new ones will appear, and some branches might get trimmed. Your custom branch will always work as designed as long as backward compatibility is maintained.
If the original page or process gets modified in a software upgrade, the copy will remain intact. This avoids the painful process of code merging and conflict solving, which is the main reason why software upgrades are expensive to deploy on customised applications. At the same time, limiting the protection to customised pages and processes allows the licensee to benefit from software upgrades in other features of the application.
Software upgrades applied to heavily customised features rarely deliver value to end-users. You want to benefit from the bells and whistles of the new upgrade without touching what was already tailored for your operations. The real upgrade value for the licensee lies in the new features and in the generic features that did not require customisation.
The 80-20 Pareto principle applies. Instead of delivering 100% of software upgrade value at a tremendous cost, one can deliver 80% at a small fraction of the cost. Customizing your enterprise software can definitely deliver tremendous operational gains and value to your organization, and if done correctly, will allow for painless software upgrades.