ERP software packages that manage and integrate business processes across organizational functions and locations cost millions of dollars 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 of ERP projects [4].
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 [1, 3]. As a result, organizations have had to choose among adapting to the new functionality, living with the shortfall, instituting workarounds, or customizing the package. ERP software, as a class of package software, also presents this problematic choice to organizations.
The problem is exacerbated because ERP implementation is more complex due to cross-module integration, data standardization, adoption of the underlying business model (“best practices”), compressed implementation schedule, and the involvement of a large number of stakeholders. The knowledge gap among implementation personnel is usually significant. Few organizational users understand the functionality of ERP enough to appreciate the implications of adoption. Similarly, few ERP consultants understand their clients’ business processes sufficiently to highlight all critical areas of mismatches.
Here, we survey the different types of misfits observed, the resolution strategies employed, and the related impacts on organizations. Our findings suggest the “misfit” issue may be worse in Asia because the business models underlying most ERP packages reflect European or U.S. industry practices. Procedures in Asian organizations are likely to be different, having evolved in a different cultural, economic, and regulatory context.
Context
In the mid-1990s, seven public hospitals in Singapore identified the need to replace their mainframe-based financial, administrative and patient management systems for a variety of reasons, but chiefly to resolve the Y2K problem. These hospitals are large, with between 800 to over 1,500 beds each. Together, the public sector hospitals account for 81% of total hospital beds in the country. Their independent selections pointed to the same ERP solution for financial, materials management, and inpatient management systems. Several hospitals have decided to retain their existing human resource/payroll and outpatient management systems. The implementation time frames vary across hospitals, but generally span from 1996 to the present.
We were invited by one of the hospitals to review their implementation process and to help them learn from their experience. This article presents early findings from a larger, ongoing study. The typology of misfits and examples are drawn from the review of implementation documents and supplemented by interviews with key project team members from one hospital. We systematically constructed the lists of ERP misfits observed and tracked them through to resolution.
Types of Misfits
Misfits arose either from company-specific, public sector-specific, or country-specific requirements that did not match the capabilities of the ERP package. Company-specific requirements reflect differences in the organizational structure, medical specialties offered, management styles and procedures that evolved over time in each hospital. Public sector-specific requirements revolve around reporting requirements to regulatory authorities, standard formulas and processes for government reimbursement to hospitals for services to patients, and standard civil service human resource practices. Country-specific factors are broader and focus on unique regulatory or social practices across nations or cultures. The impact of country-specific factors varies across functional modules. We found that in areas such as accounting and finance, where international accounting standards promulgate some degree of global standardization, there were fewer misfits. On the other hand, there were many more misfits for patient care systems, where practices vary more from country to country. In addition, the patient care modules are specialized industry modules, and are not as well integrated with the mainstream modules such as finance and materials management.
The observed misfits were clustered into three broad categories: data, process, and output, in line with a traditional software application perspective (see Table 1).
Data misfits arise from incompatibilities between organizational requirements and ERP package in terms of data format, or the relationships among entities as represented in the underlying data model. Resolving these misfits is cumbersome, since this requires changing the structure and relationship of the table objects, which are viewed as prohibitive core changes to the ERP packages. The examples noted in Table 1—the “unfeasibility” of expanding the first name field beyond 30 characters and assigning an external ID number as the key field for cross-module linkage are good illustrations of such misfits. From a user perspective: “it is hard to believe that something so sophisticated can’t handle a simple modification like that in reality.”
Functional misfits arise from incompatibilities between organizational requirements and ERP packages in terms of the processing procedures required. As shown in Table 1, three major types of functional misfits were noted: access, control, and operational. Access misfits occur when the access requirements needed to perform a task are not met. In such cases, further negotiation with the ERP vendor for additional user licenses may be necessary. Control misfits arise from missing validation procedures or checking routines. The missing procedures do not affect day-to-day operation but relate directly to the management’s risk tolerance level. Operational misfits occur when normal operational steps are missing or inappropriate, often due to the incompatibility of the embedded business model. One example is the billing and counter collection function. The Singapore health care financing philosophy is based on individual responsibility for health care costs, while community support and government subsidies help to keep health care affordable. This contrasts with the Western health care models, where much of health care is privately delivered, and government or insurance pays for health care services, with the individual bearing little out-of-pocket costs. Originating from such Western models, the billing and collection function of the ERP caters to complex claims submission processes and verification to insurance companies, but not over-the-counter or installment payments by individual patients.
Output misfits arise from incompatibilities between organizational requirements and the ERP package in terms of the presentation format and the information content of the output. By far, this is the most prevalent form of misfit noted. Presentation format misfit can generally be handled by having the reports customized using the ERP system’s report writer, or by having the users adapt to the package report format. Given the tight implementation timeline, however, the customization of report format had to be done by the systems integrator at additional cost. More significant is information content misfit, especially where the reports are simply not available from the system. One country-specific content element missing in most standard ERP patient management reports is the concept of “bed class.” Unlike the West where single-bedded rooms are common, local patients in public hospitals can choose from accommodation types ranging from one bed to six or more beds per room. The information is needed for claims processing because government subsidies increase as one moves from a two-bedded to multiple-bedded room. Overall, the local hospitals found that the number of reports required and not provided by the ERP system were numerous enough to warrant paying the ERP vendor to extract the necessary data into flat files for subsequent data manipulation and report generation by users. The hospitals decided they could not do without the reports as many were for government reporting and reimbursement, such as the report on patients by bed class. Others were needed for internal performance reporting.
Types of Resolution and Organizational Impacts
When a misfit occurs, a spectrum of resolution strategies can be deployed (see Figure 1). The resolution strategies trade off between the amount of organizational change and the amount of package customization required. We found that most resolutions require the users to work around within the alternatives offered by the package (for example, using an external ID field to capture a person’s national ID code). There is usually some compromise in functionality, either in terms of doing without system validation checks (control compromise), or having to go through more screens (lower productivity). Generally, we noted that changing package source code was avoided because of the cost involved and the difficulty of maintaining future upgrades. Even when customizations are needed to provide critical functionality, they are done without changing the source code, through the development of add-on modules that are plugged into the ERP system’s user exits. In general, such a strategy is likely to raise some problems during system testing, as the add-on modules may have some minor bugs, unlike the main ERP system. In addition, subsequent versions of the ERP software may not retain the same user exits, and this complicates the upgrade process. Another hospital that also has significant add-on customization has outsourced the entire ERP maintenance environment to the system integrator.
Despite the difficulties of dealing with unplanned misfits, the overall ERP experience across the hospitals has produced positive impacts as well. Besides being Y2K compliant now, the system has also accelerated some hospitals’ transition to activity-based costing, and is providing information on resource usage that was previously not available. One manager noted, “left to ourselves, we would probably have taken longer to move in this direction. But the ERP system forces us to jump in to reorientate ourselves to the concept of profit centers and learn about the specific cost and revenue of our products.” This additional information comes, however, at the cost of users having to deal with a much larger number of data input codes. The adoption of the ERP system has also increased the level of data standardization within the hospital, and has led at least one hospital to identify owners for each data table.
While it is still too early to see the full integration benefits of ERP, the implementation process has also been an opportunity for organizational learning. Large numbers of users were trained in order to deploy the system, largely through a “train the trainer” approach. There is now a greater awareness of IT, and how it affects their work, among hospital staff. Many key users were also involved in the implementation, and their experience has enabled them to be more effective in other subsequent systems implementation projects. More benefits are likely to surface as users adapt to the system and learn more about its functionality.
Lessons Learned
Our analysis of unanticipated misfits in ERP does not dispute the trend in ERP adoption. But as indicated by the misfit examples, there is a need to recognize the unique Asian context when adopting an ERP system, since the embedded business models typically reflect a bias toward Western practices. Specifically, the grounded categorization of misfit types suggests the specific data, functional, and output issues to focus on in the Asian context. Early identification of misfits provides a more accurate basis to budget for contingency funds and allows related change management issues to be adequately planned for. Resolution strategies can also be carefully thought through and are likely to be less reactive in nature.
More generally, we believe vendors need to spend more time explaining the embedded data requirements and processes to the organization. Organizations need to acquire more skills to ask and probe for such details. We were surprised to find that the reference models that espouse industry best practices are at too high a level for an effective assessment of how the ERP system would actually affect the organizational processes. As one hospital executive observed: “We needed to go down two or three levels.” The process-focus of an event-driven methodology tends to gloss over potential data issues. It is also difficult to find clear linkages between the analysis documents and the design documents. Moreover, effective misfit analysis requires both comprehensive understanding of the critical organizational processes (an analysis activity) and detailed knowledge of this very complex software (a design activity). There is thus the need to merge the traditional system development separation of the analysis and design phases for ERP implementation.
Fundamentally, the misfit analysis reveals the severity of the knowledge gap in ERP implementation. The three key parties to this process—key users, IS department personnel, and the ERP vendor—each has different and specific knowledge (organizational requirements, existing IT infrastructure, package functionality, respectively) that is difficult to transfer to one another. While frequent interaction and joint problem solving appear to be the logical way to bring the disparate knowledge together, the varied backgrounds and interests of the three parties make it difficult to achieve an integration of this knowledge. We suspect the stickier knowledge component in ERP implementation is organizational requirements and processes, given that much of this is tacit. Hippel [2] has suggested that where the information is sticky, the optimal strategy is to place the locus of problem-solving with the sticky source, in this case, the key users. Thus, the demand on users is not only to be competent in their business areas, but also to assimilate the package functionality in some depth. They must now consciously “get into the ERP software” [5] to evaluate the appropriateness of the new configured system or the alternatives adopted. Organizations can facilitate the knowledge acquisition process by budgeting for vendors to spend time educating key users about the system, by shifting the ERP focus training earlier in the implementation process, by planning for detailed data, functionality and output walk-throughs, and by selecting vendors with significant industry knowledge. Most importantly, users should realize that it is no longer sufficient for them to be passive functional experts as in the traditional system development projects: They have a much bigger role in ERP implementation.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment