THE USE OF PACKAGES

For most business processes, there are now application packages that can be bought ‘off the shelf’. A bought-in financial package can handle sales order processing, purchase order processing, general ledger and much more. A human resources package includes recruitment management, payroll, training management, and so on. Many organisations have a strategy of using these ‘off-the-shelf’ application packages wherever possible, as this is normally seen as a relatively cheap option for delivering speedy business benefit.

Most application packages provide the functionality that the package designer thinks is appropriate for a broad range of businesses. The database underlying these packages is designed to support the functionality provided by the package. It is highly unlikely that the requirement to share data was taken into account when the package was being designed. In an environment where off-the-shelf application packages are used, it is, therefore, difficult to share data between systems. This is especially true if the organisation is to be supported by a mixture of bespoke systems and packaged systems or by packaged systems from different vendors. It is not unknown, however, for data not be shareable between packages or systems from the same vendor. If off-the-shelf application packages are to be used and there is to be data sharing, a ‘bespoke interface’ or a set of bespoke interfaces must be developed.

Where application packages are to be procured to support business requirements, there are a number of issues that need to be addressed from a data management perspective:

• Is a reliable conceptual data model or logical schema available for the package? If not, it will be impossible for the data management team to assess the difficulty of sharing data between this package and the rest of the enterprise’s systems before it is procured and implemented.

• Does the package match the functional and data requirements of the business? Business users easily identify if the package does or does not meet their functional and local data requirements but they are unlikely to consider any wider requirement to share data.

• How will the corporation handle the effects of the introduction by the vendor of new versions or releases of the package? New versions may introduce a requirement to reengineer interfaces.

The questions above are based on the assumption that the selected off-the-shelf package meets the business users’ requirements. Increasingly, however, packages are being bought that do not quite match the functional requirements – the designer of the package envisaged a slightly different set of processes and procedures for the business area to those in use within the organisation. This is a result of the application of the Pareto Law, also known as the 80:20 principle, to package requirements. This principle says that 20 per cent of the work that we do produces 80 per cent of our income. In the context of the procurement of software, this is taken to mean that 80 per cent of the functionality we need only requires 20 per cent of the total cost. Getting the extra 20 per cent of functionality, to give us everything we need, costs that extra 80 per cent. The assumption is, therefore, that to save money we accept a package that provides 80 per cent of the functionality we require and adapt our procedures and processes to match the product we have bought. This seldom works out in practice, but even if it did nobody seems to take into account the cost of changing the well-established business procedures and practices. The normal situation is that once the package has been bought we discover that the business is not prepared to change the way it works and the off-the-shelf package has to be ‘tailored’ to meet the full business functionality. There are substantial financial costs in implementing this tailoring. However, a package that has been tailored is no longer an off-the-shelf package; it is now a ‘bespoke’ product.

To use an off-the-shelf package within a federated system always requires the development of an interface so that the package’s data can be shared with other packages and systems and, probably, requires that the package’s functionality also has to be tailored to meet the existing business processes and procedures.

When the true costs of developing, maintaining and managing interfaces as well as the tailoring required by the business area are included in the cost–benefit analysis, off-the-shelf application packages often turn out to be a more expensive option than bespoke development. All of this is also true for enterprise resource planning packages, which were briefly discussed in Chapter 1.