Introduction

ERPs – software packages that manage and integrate business processes across organizational functions and locations – cost millions to buy, several times as much to implement, and necessitate disruptive organizational change. While some companies have enjoyed significant gains, others have had to scale back their projects and accept minimal benefits, or even abandon implementation (Marcus and Tanis, 2000).

Historically, a common problem when adopting package software has been the issue of ‘misfits’, that is, the gaps between the functionality offered by the package and that required by the adopting organization (Davis, 1988; Lucas, Walton, and Ginzberg, 1988). As a result, organizations have had to choose among adapting to the new functionality, living with the shortfall, instituting workarounds, or customizing the package. ERPs, as a class of package software, also present this problematic choice to organizations.

Even though there are many built-in switches that one can manipulate to customize the software, smooth alignment of the software functionality to business requirements is still far from ideal as many of these issues have to be dealt with at the application architecture level. AeroGroup, for example, has dropped the Apparel Footwear Solution of SAP/R3 because of its inability to model the uniqueness and complexities of the footwear business. Similarly, the failure of Fox Meyer could also be partially attributed to the adoption of an ERP system that was designed more for manufacturers rather than wholesale distributors.