The common reasons for those in organizations adopting large configurable packaged software products are compelling. Problems with the existing software situation, the supposed predictability and perceived business benefits of packaged software, and various social influences, can lead to packages being preferred to custom approaches. Yet, for every reason, there is a potential associated problem that must be understood before an informed adoption decision can be made.
In terms of the existing software situation, packaged software is often perceived as solving problems of legacy information systems and having the ability to deal with applications backlogs, since it is supposedly well-structured, documented, supported, and maintained. However, treating packaged software as different from legacy information systems is flawed. For example, many ERP packages replaced heavily customized ‘legacy’ MRPII packages. Also, although the adoption of packaged software may help relieve existing problems, it may also introduce new ones. Since packaged software is pre-built, shorter implementation timeframes than those for custom development are expected. But products still must be built, as will the inevitable upgrades. Moreover, if those in an organization want to move in a direction not supported by the software, they must wait and hope the resulting product meets their needs. Importantly, since negotiations about the functionality of packages are conducted at the market level [4, 6], new releases may not meet requirements and a backlog may remain. Another problem of existing IT systems is that the skills and knowledge bases for these systems are often scarce. In contrast, from a development perspective, as packages are produced for a mass market, support for them tends to be more widely available than for custom-developed software, knowledge of which tends to be application-specific. From an end-user perspective, a broader population can increase opportunities for knowledge-sharing, and facilitate faster, more efficient deployment of packages. However, the more popular the package, the more difficult and costly it can become to access a knowledge and skills base for it, since at a certain level of popularity demand for skills outstrips supply. For example, the widely reported lack of SAP consultants in the late 1990s echoed the shortage of Assembly skills in the early 1990s. Additionally, problems of finding support also appear when a package’s popularity wanes.
Purchasing packaged software is also considered to bring with it a degree of predictability in terms of costs, reliability, and functionality. Clearly, the economies of scale that can be tapped into should make a license significantly cheaper than in-house creation of the same software. However, packaged software projects are not immune to the budget overspending often associated with custom development. The litigation following FoxMeyer’s expensive introduction of SAP software is just one reminder of the potential hazards. The major costs associated with packaged software are those incurred beyond the license fee. Implementation usually requires the use of costly consultants to undertake software configuration, customization and, usually, organizational change [5]. There is also the issue of support contracts for maintenance and upgrades. This can all be very unpredictable. The package itself is also perceived as predictable—a tried and tested solution—with reduced risks compared to custom development. Packages are proffered as designed and tested and as already in successful operation within other organizations, allowing for reference site visits by potential purchasers. But although a package may work well for those in one organization, it may not suit those in another. Moreover, there are doubts about the rigor of product development processes in the packaged software industry [2]. Indeed, suspicions about these processes are not easy to verify since they are opaque to those in most consumer organizations, so it is difficult to tell whether a package has been developed haphazardly. In any event, vendors are usually evaluated in terms of their products and sales pitches, rather than their development processes [3]. Software characteristics also influence the choice of whether to buy packaged software (for example, if a package already on the market seems to suit the intended purposes). The danger is that it may not be suitable for long; it is difficult for software producers to keep pace with changing industry requirements and to nuance their products for use by a range of customers. Consider the problems of some ERP adopters who had to wait for CRM components to be built by vendors.
It is difficult for software producers to keep pace with changing industry requirements and to nuance their products for use by a range of customers.
Some of the common perceived business benefits of package introduction include the freeing up of IS staff, standardization, and implementing change. On the first point, it is often assumed that package implementation can lead to reductions in the in-house development team, as fewer resources need to be directed to development and maintenance activities. However, although there may be no need for a large development work force, staff may be needed to perform and look after customizations and provide day-to-day onsite support. On the second point, those in organizations may strongly favor packaged software in the belief that standardization is beneficial. But standardization can lead to very different ways of working and increased transparency across organizations, which may be resisted by various individuals and groups. Finally, those in organizations are often pushed by consultants and vendors to change working patterns in concert with practices inscribed into the software. Not only are these seen as tried and tested, but also as embodying best practices. Because of these factors, many also select a package in order to force change. Package implementation may be used to justify unpopular reforms already planned. It is important the methods of working implied by a package are considered carefully, as they may be detrimental. For example, in one company I have worked with, the so-called best practices inscribed in a CRM product, although more efficient than the existing processes, would have depersonalized their touted unique selling point of personal customer contact had they been implemented.
Overcoming software problems, reducing risk in the development process, and effecting business improvements are common rationalizations for purchasing packaged software. Some of the most important reasons, however, arise from social influences such as sales activity and bravado. Sales activity is an often overlooked influence on package selection. Those in organizations may choose software following an approach by a vendor or intermediary, but some of the most effective selling occurs within and across consumer organizations. In a fairly typical example, at Metalica,1 the head of systems development and the chief trainer explained to the CEO the benefits of a proposed package and attempted to allay fears about the product and problems that may be encountered during implementation, such as migration and training issues [1]. Moreover, packages can rapidly generate bandwagons. If a package is perceived as successful then sign-ups can soar as those in consumer organizations want to be associated with that image; take SAP, for instance.
This review of the reasons for package purchase is not exhaustive: since every organization is unique, there is a multitude of reasons. As shown in the table here, it is apparent that the reasons for package adoption are contradictory. So-called ‘rational’ reasons for adoption can be taken to be reasons against this, depending on organizational circumstances. Therefore, while there are many benefits of packages, an awareness of the potential hazards of package adoption is necessary before an informed decision can be made.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment