Changes to software packages are expensive in every way. You could compare them to ice cream flavors. In the world of software packages, there is no better flavor than vanilla. In other words, changes to software packages often leave a bitter taste.

It is therefore suggested to adopt business processes supported by software packages. This is much more effective than making changes to software packages to adapt them to your organization.

Why are software changes so expensive?

As mentioned above, these modifications are expensive to develop and maintain later. In addition, they represent major risk factors for an implementation project. Why? Developing an application is already complex and expensive. It should never be implemented without a comprehensive cost and benefit analysis.

Software updates can also become very expensive. Indeed, during a transition to a new version, the changes made will have to be reviewed and adapted in order to be integrated into the new version. This is a costly operation that will delay the migration project schedule. It is also possible that the project team that initially developed the modification to the software package is no longer available and that the documentation can no longer be found.

Why shouldn't changes be made to the software packages?

There are also cases where changes to a software package are very significant. In some cases, the manufacturer may no longer be able to honor the contract for post-implantation support of its product. This is a fairly significant problem if the software package needs an update or maintenance.

Before making changes to a software package, it is therefore essential to fully understand all the costs associated with designing, maintaining, supporting, and possibly migrating the desired changes. An analysis of the benefits brought about by the change should also be produced.

What should I do if the software package needs to be modified?

Despite the costs, your software package may need a real change. Before developing a modification yourself, ask the manufacturer for information. Is it possible that the functionality in question could be delivered in the next version of the software package?

Another way to ensure that your modification works properly is to have it developed by the manufacturer of your software package. Ask them how much it would cost you to take care of this change once it is put into production. You may still decide to develop this modification yourself. In this case, ask the manufacturer how best to proceed and ask them to review your design.

Why were changes to software packages common 20 years ago? The answer is simple: the software packages offered fewer features and were less complex. Nowadays, these software packages have evolved a lot and generally support the most widespread and recognized business practices. So they are more complex.

An extension to the software package rather than a modification

However, some items are not considered to be changes to the software packages. Examples include interfaces, data conversion programs and reports. Interfaces are often essential in order to be able to integrate the software package with the other applications that support an organization. However, they are expensive to develop and test.

As a last resort, it is possible to develop an extension to a software package without risking compromising its integrity. An extension adds functionality without changing the software package. However, its creation must follow certain rules. First, under no circumstances should records be created directly in the software package database. If it is necessary to create one, it must be done using the interfaces provided by the manufacturer.

Remember to properly document any changes, extensions, interfaces, or development work that surrounds a software package. These documents will be gold mines. They will be used to support the production of the software package and the migration to the next version.

Finally, before making changes, remember why you first wanted to have a software package developed. Was it to avoid having to do development yourself? Did you want easy access to the new versions? Did you aim to take advantage of the best business practices offered by a software package? Changes to software packages may appear to be more economical in the short term. However, they will not simplify business processes in the medium and long term, or when a new version of the software package is available. It's a thoughtful thought.