Software package modifications: a very costly habit

Modifying software packages is expensive in every respect. You could compare them to ice cream flavours: in the world of software packages, there is no better flavour than vanilla. In other words, modifications often leave a bitter aftertaste.

We therefore suggest adopting the business processes supported by the software packages, an approach that is much more efficient than forcing the software to fit your organization through modifications.

Why are software package modifications so expensive?

Because they are costly three times over: during development, during maintenance, and then with every software update, where they must be reviewed and adapted to the new version. They also represent major risk factors for an implementation project. No modification should be implemented without a complete cost-benefit analysis.

When moving to a new version, any modifications made must be reviewed and adapted. This is a costly operation that delays the migration project timeline. It is also very possible that the team that originally developed the modification is no longer available and that the documentation is nowhere to be found.

In extreme cases, excessive modifications can even prevent the manufacturer from honouring its support contract: a serious issue if the software package requires an update or maintenance.

In the world of software packages, there is no better flavour than vanilla.

What should you check before modifying a software package?

All costs related to the design, maintenance, support, and eventual migration of the modification, as well as the actual benefits it provides. These change requests are, in fact, one of the main causes of overruns in ERP project budgets.

If the need persists, check with the manufacturer first: the functionality might be included in the next version of the software package. You can also ask them to develop the modification, or at the very least, to review your design and provide a quote for supporting it once the modification is in production.

Why were modifications common 20 years ago? Software packages offered fewer features and were less complex. Today, they generally support the most common and recognized business practices.

What is the difference between a modification and an extension?

An extension adds functionality without touching the core of the software package, whereas a modification alters the product itself. Some elements are not considered modifications: interfaces, data conversion programs, and reports. Interfaces are often essential for integrating the software package with the organization's other applications, even if they remain costly to develop and test.

However, creating an extension must follow certain rules. First, you should never create records directly in the software package's database: if it is necessary to create them, you must use the interfaces provided by the manufacturer.

Don't forget to document all modifications, extensions, and interfaces. These documents are gold mines: they support the software package's production and the migration to the next version.

Before making modifications, remember the reasons that led you to choose a software package: to avoid custom development, to easily access new versions, and to benefit from best business practices. Modifications may seem economical in the short term; they will not simplify your processes in the medium or long term, nor will they simplify the transition to the next version. It is something to think about carefully.

Frequently asked questions

What is a "vanilla" approach to software package implementation?

It is implementing the software package without modification, by adopting the standard business processes it supports. This approach reduces development and maintenance costs, simplifies updates, and preserves the manufacturer's support contract.

Why do modifications complicate updates?

With every new version of the software package, modifications must be reviewed, adapted, and retested. The operation is costly and delays migration, especially if the original team is no longer available or if documentation is missing.

What are the alternatives to modifying a software package?

Four options: adopt the software's standard process, wait for the feature in a future release, have the vendor develop the modification, or create an extension that adds the functionality without compromising the product's integrity.