Packaged Software Implementation

There is a noticeable absence of literature relating to the success and failure of ‘pure’ packaged software implementation. However, as mentioned earlier, it is possible to examine the literature related to ERP packages and indeed much work on success and failure has been undertaken in this respect. Consequently, the discussion that follows is very much rooted in the ERP literature. However great care has been taken to exclude factors that are specific to the ERP application type and include factors that are appropriate to packaged software in general. A number of studies that offer frameworks for understanding the process of implementation of ERP packages are shown in Table 3.4.

In summary, these essentially begin with some form of needs analysis (comparable with the selection processes described in section 3.2). This is followed by other implementation activities such as the software configuration, business process change and the roll out of the application. A bedding in process follows as those in the organisation become accustomed to the new package and then it begins to be exploited as necessary. Moreover, there is a deluge of literature that aims to facilitate packaged software implementation, specifically in identifying factors which may contribute to success and failure. In the following sections, I discuss the contributions of these studies in relation to the general factors that can be drawn from them. However, as this study is concerned with the process of selection, the specific focus is upon how the factors are linked with this. Note that, at this stage, I make no attempt to critique the nature of the links made. I merely wish to highlight the conventional wisdom reported in the literature. I shall return to these issues in chapter 6, section 6.6.

Table 3.4: Typical Process Models of ERP Packaged Software Implementation

(Esteves and Pastor, 1999)

Selection Implementation Use and Maintenance

(Parr and Shanks, 2000) Project planning and software selection. Identification of modules for implementation through to installation.

Repair, extension and transformation. (Ross and Vitale, 2000)

Design Implementation Stabilisation Continuous improvement _{and transformation.} (Markus and Tanis, 2000)

Build case for purchase and selection of the software.

Configuration of the software and roll out to the organisation.

Transition from 'go live' to 'normal conditions'

Capture business benefits (if any) from the ERP system and plan the next steps for technology implementation.

3.7.1 User Involvement and Acceptance

The need for user involvement is probably the most widely reported factor that contributes to the success of packaged software implementation. This is seen as important in the belief that those who will interact with the package must have some input in order to determine functionality requirements and facilitate change processes (Gremillion, 1982; Markus and Tanis, 2000; Al-Mudimigh et al., 2001; Akkermans and van Helden, 2002). User/client acceptance is also included here. This is because if users are not involved in the process of selection, requirements may not be determined properly leading to inadequate product selection. There may also be resistance to change and lack of system acceptance (Gibson et al., 1999; Holland et al., 1999a; Holland and Light, 1999b).

3.7.2 Appropriate Business Process Change

This factor involves determining and performing the necessary changes in ways of work to conform with the standard processes embedded within a given package in order to maximise the reported benefits over custom development (Lucas et al., 1988; Holland and Light, 1999b; Markus and Tanis, 2000). As this is often a key goal, it would therefore be expected that the selection process would take into account this factor, and that those involved would aim to choose a package that most closely resembles their intended ways of working (whether this is currently similar to the existing ways of working is another matter).

3.7.3 Top Management Commitment

This factor is generally used to make that point that engaging senior management keeps the project moving, it may also involve the development of a good case for implementation (Avital and Vandenbosch, 2000; Al-Mudimigh et al., 2001; Akkermans and van Helden, 2002). In terms of packaged software selection, it has been demonstrated earlier that senior managers are most likely to make purchase decisions and it would therefore make sense for them to be enrolled in the process. Moreover, even if selection and implementation are seen as separate processes, implementation may prove difficult if ‘top management’ have not been involved in selecting the package.

3.7.4 Personnel Capabilities

Packaged software will require the recruitment, training and retention of staff to implement and use the package (Holland and Light, 1999b; Markus et al., 2000; Skok and Legge, 2001; Kraemmergaard and Rose, 2002). At the stage of selection,

this may involve internal and external staff in requirements gathering and product evaluation activities. The assumption here is that those involved in the selection process (whether users or external consultants) can assist in choosing the ‘right’ package only if they are of the right ‘calibre’. Moreover, as demonstrated earlier the package selected may have implications in respect of the availability of the personnel capabilities required to implement, operate and maintain the package.

3.7.5 Understanding of the Capabilities of the Package

Understanding the capabilities of the package is highlighted as being important throughout the process of implementation (Lucas et al., 1988; Markus and Tanis, 2000; Al-Mudimigh et al., 2001; Akkermans and van Helden, 2002). The implications for the selection process are that the package needs to be fully understood in order that the most suitable product is purchased. If the most suitable product is purchased, the belief is that this will facilitate implementation as acceptance is increased.

3.7.6 Appropriate Decisions Regarding Customisation and/or Configuration

Packaged software is usually selected on the basis that customisations will not be performed. However, sometimes customisation may be unavoidable (Lucas et al., 1988; McKeen et al., 2002; Holland and Light, 2003). Many packages also require configuration. Where this occurs, it is argued that implementation plans use configuration strategies to facilitate implementation. Plans may include the roll out of partial functionality, rather than full functionality, in ‘difficult’ implementation conditions or where a faster, simpler, implementation is desired (Holland and Light, 2003). The link between selection and implementation here is that, through the

selection activities, products may be assessed in terms of their need for customisation and/or the potential for implementing numerous configuration strategies.

3.7.7 Recognition of Legacy Information Systems

Even though packages are often implemented to standardise and attain best practices, the literature suggests that explicit recognition of the legacy information systems can facilitate implementation as this is the context for any new development(Lucas et al., 1988; Al-Mudimigh et al., 2001; Holland and Light, 2003). In terms of selection, knowing the ‘as is’ situation (part of requirements gathering) may assist those in organisations to appreciate the extent of change that may be brought about through implementation.

3.7.8 Sound assessment of User Requirements

Knowing the requirements for the package for implementation purposes is argued to be necessary in order to scope the project (Lucas et al., 1988; Gibson et al., 1999; Markus and Tanis, 2000). Clearly, changes in requirements during implementation could increase timescales and costs. A sound assessment of needs is, therefore, highlighted as important at the time of package selection.

3.7.9 Management of Change and Expectations

Finally, the implementation of packaged software is associated with varying degrees of change and it is argued that the expectations of organisational members need managing in this environment (Markus and Tanis, 2000; Akkermans and van

Helden, 2002). The selection process therefore links with implementation in this fashion via notions of user involvement and moderating the various sales pitches that might be made in order to obtain the package/package sale.

3.7.10 Summary

In summary, it is clear that, however implementation is characterised (either to include selection or treat it as a separate process), there are implications for those activities that arise from selection activities. Therefore, theories of packaged software selection need to take this into account but at present those that emulate the ideal model do not explicitly do so. As reported elsewhere:

“Our overall experience however suggests that far from being a “take it off the shelf, plug it in” experience, the installation of packaged software has hidden costs that only become apparent during implementation” (Lynch, 1984: 234).

Many of these ‘hidden costs’ can be traced back to the selection process, and before.