Evaluating ERP Impact Through Soft Systems Methodology

Evaluating ERP Impact Through Soft Systems Methodology Adrien Presley Division of Business and Accountancy Truman State University Kirksville, MO 63501 Abstract Many companies are implementing Enterprise Resource Planning (ERP) systems in an effort to automate and integrate information and processes. While some ERP projects are successful, most implementations remain problematic. Projects take longer and cost more than expected, fail to yield anticipated results, or in worst case scenarios, are abandoned completely. While technical issues often arise, ERP systems face problems due to many complex and interacting organizational and social factors. This paper presents Soft Systems Methodology as a possible aid in identifying the value, impact, and barriers to ERP. SSM is a "soft" operations research tool designed to analyze and model complex systems that integrate technology with human and organizational systems.

Keywords ERP, Soft Systems Methodology, Organizational Change

1. Introduction Companies are changing the way in which they are acquiring software. The software industry is seeing a shift from inhouse, proprietary software development to the purchase and implementation of packaged, "off-the-shelf" software. An example of this shift can be seen in the market for Enterprise Resource Planning (ERP) software. The ERP market is one of the fasted growing segments of the software industry. Major players in the market include companies such as SAP AG, Baan, PeopleSoft and Oracle. It is estimated that 70 percent of Fortune 1000 companies already have or will implement ERP systems. Additionally, vendors and consultants are targeting smaller companies with scaled down versions of their systems. The ERP market, which was estimated at $15.7 billion in 1997, is expected to grow at a rate of 36% per year. In addition to the cost of the systems themselves, there is a significant consultancy market [1, 5]. The reported results from ERP implementations are mixed at best. While success stories such as Monsanto can be found, many companies have found their experiences with ERP to be unmitigated disasters. For example, FoxMeyer Drug sued its ERP vendor, claiming that the system was a major cause of its going into bankruptcy. Other companies such as Dell, Dow Chemical, and Applied Materials all abandoned their implementations, resulting in significant cost write-offs. Ninety percent of ERP projects are late or over budget [6]. The Standish Group reports that ERP projects are, on average, 178% over budget, took 2.5 times as long as planned, and yielded only 30% of promised benefits [8]. While ERP systems pose unarguably enormous technical requirements and challenges to the implementing company, literature suggests that the reasons for failure are not technical, but organizational, cultural and social in nature. A company implementing ERP must adopt its organization and processes to those required by the system. This change at the same time impacts and is constrained by the organization. If the organization and its employees are unwilling or unable to change, the ERP system is doomed to failure. In this paper, Peter Checkland's Soft Systems Methodology (SSM) is presented as a theoretical framework as an evaluation and planning tool for ERP implementation. SSM is a methodology specifically designed for analyzing and modeling hard to define and large complex systems that include human (soft) systems. After a review of ERP and SSM in the following section, the paper discusses the applicability of SSM for the difficult process of evaluating the impacts of ERP systems. It is argued that ERP implementations, with their dependence on organizational systems, fits within the domain of SSM and that SSM can provide a valuable framework for evaluation of ERP. The paper concludes with a discussion of possible future directions for the research.

2. Review of Literature ERP systems are well understood and have been described in detail in both practitioner and research literature. Rather

than going into exhaustive detail about technical details about ERP, this section will provide some background on these systems, focusing on details pertinent to the discussion to follow. It is assumed that the SSM is not as well known, so a brief background of the methodology and its applications are provided, again focusing on those factors most relevant to information systems in general, and ERP in particular. 2.1 ERP ERP systems are commercial software packages that promise seamless integration of all information flowing through a company [5]. They are designed to solve the fragmentation of information in large business organizations. In essence, they can be thought of as a company-wide information system that integrates all aspects of a business. ERP is a term used for the broad set of activities supported by application relational database system software that automates and integrates the “back office” functions where these functions are no longer standalone. Integrated ERP systems have one integrated, relational database for all data, with clear definitions of every data item shared across the enterprise. They are implemented as mainframe applications, or increasingly, on client server network architectures using graphical user interfaces. In addition to the information integration, ERP systems commonly provide templates for processes based on “best practice” [1, 5]. Companies adopt ERP for both technical and business reasons such as to improve IT architecture, accommodate business growth, improve business processes, and standardize business operations and procedures [10]. Many companies have achieved significant benefits from their systems. ERP implementations are extremely complex. The software itself is very complex and requires large investments of time, money, and expertise. Huge shortages of skilled and experienced workers are seen. Integration with and extracting data from legacy systems on heterogeneous systems can be extremely difficult. Technical challenges, though, are not the main reasons the systems fail [5, 10]. The biggest problems instead are business related. ERP systems impose their logic on an enterprise’s strategy, organization, and culture. Commercial ERP systems require that companies adopt their processes to those supported by the system. These processes are generic processes based on a set of assumptions about how companies operate in general. By forcing companies to adopt these processes, they push companies to generic business processes even when customized processes may be a source of competitive advantage. Additionally, the centralized control over information and standardization of processes can lead to more rigid and hierarchical organizational structures and cultures. The autonomy of individual business units may be lost as all units move to the standardized business models. Rather than the traditional approach of modifying software to meet the company, the cost and complexity of ERP systems requires that companies modify their processes and structure to meet the software. Davenport [5] states “companies that have the biggest problems – the kind of problems that can lead to outright disaster – are those that install enterprise systems without thinking through its full business implications.” Implementing ERP systems, then, should be a careful exercise in strategic thinking, information systems planning, and organizational design. 2.2 Soft Systems Methodology Soft Systems Methodology (SSM) was first introduced by Peter Checkland in 1981 in his book Systems Thinking, Systems Practice [3]. SSM has been grouped among the “soft” operations research tools, as opposed to the “hard” mathematical and decision models that have traditionally existed in the operations research field. It is a methodology for analyzing and modeling hard to define and complex systems that integrate technology (or hard) systems and human (soft) systems. A human system is defined as a collection of activities, in which people are purposefully engaged, and the relationships between these activities. Checkland proposes that the same methods used for engineering technology may not work as well for the more unpredictable and complex human side of the system. SSM addresses “fuzzy” problems that occur when objectives are unclear, multiple objectives exist, and where there may be several different perceptions of the problem. SSM recognizes that different individuals will have different perceptions of the situation and different preferable outcomes. It recognizes these differences and explicitly attempts to take these into account from the outset to ensure that the results of the analysis are acceptable to all parties concerned [3]. Use of an SSM approach does not attempt to define a single right method of action but, through an iterative process, defines an acceptable improved path of action. People who are involved in the methodology include not only actors within the designated system, but also clients and owners of the system. This is a very useful and important consideration, especially when involvement and buy-in of all potential customers is desirable.

SSM has been applied in many settings. Those related to the work being discussed here include Winter, et al. [11] who discuss the role of SSM in information systems development. They present what is referred to as the Information System/Information System Development Model which extends upon Checkland’s concept of the information system as actually consisting of two systems – a serving system (the computer-based system) and a served system (the actual organizational consisting of purposeful organizational activity). Chan and Choi [2] use SSM as a framework for business process reengineering, an organizational intervention resulting in fundamental changes to a company’s processes and structure similar to an ERP implementation. SSM is a seven-stage process in which users, analysts and designers incrementally define the problem, generate and evaluate alternatives, and choose an acceptable solution. The stages are 1) problem situation unstructured; 2) problem situation expressed; 3) root definitions of relevant systems; 4) conceptual models; 5) comparison of conceptual models with the real world; 6) feasible, desirable changes; and 7) action to improve. Stages 1, 2, 5, 6 and 7 can be regarded as “real world” phases, while stages 3 and 4 are considered to be systems thinking, or abstract phases, about the real world (see figure 1). In the interest of space, descriptions of these stages, tailored to ERP analysis, are presented in the next section.

1. Problem Situation Unstructured

7. Action to Improve

6. Feasible/ Desirable Changes

2. Problem Situation Expressed

5. Comparison of Conceptual Model with Real World

Real World Systems World 3. Root Definition

4. Conceptual Models

Figure 1. The Soft Systems Methodology

3. SSM as Framework for ERP In this section the use of SSM as tool for analyzing the impact of ERP implementation is discussed. The structure of this section will roughly follow the steps or phases of the SSM, bringing in relevant discussion of factors required for an ERP analysis. SSM provides for a framework to analyze the many factors that must be considered. While economic analysis and the selection of a particular ERP vendor’s package could be considered, the intent is to provide a larger analysis of the ERP system by helping to identify organizational, social, and cultural aspects in addition to economic factors. The claim is not made that SSM by itself can identify and mitigate all impacts of ERP or that it is the only analysis tool required. Indeed, given the pervasiveness and magnitude of the effect that ERP has on an organization, no single tool, technique, or methodology can be expected to this. The framework being proposed here is one more tool for the organizing and guiding the analysis. 3.1 Stages 1 and 2: Problem Situation Unstructured and Expressed Stages 1 and 2 are most often combined in descriptions of the SSM. They represent the identification and representation of the problem situation in terms of a “rich picture.” A rich picture is a representation of the problem situation, typically presented in the form of an abstract drawing, which describes aspects of the system that are relevant to the problem definition. The identification of the problem situation may come from several sources including managers, employees, or users. For a company considering ERP, the first stage would involve first defining at a high level the organization and the

systems and processes currently in place to support to it. The current performance of the systems would then be evaluated. If the performance is not satisfactory, the weaknesses or inadequacies of the systems are identified. This stage can be crucial in that a case for ERP must be built. If potential users of the system do not feel the need to change, resistance may build up and involvement of users is often necessary for buy-in. It is important to realize that the analysts, managers, and users are all part of the situation – either as active participants or as someone able to exert control over the situation and will therefore bring their viewpoints and opinions into the analysis. The processes and information systems in place exert a major influence in the success of new systems and must be identified in this stage. For example, a thorough analysis of how processes are currently being carried out is needed. Another issue is the information systems currently in use. The identification and integration of legacy systems as a critical factor in ERP success is cited by several authors [1, 6, 8]. In the second stage, information about the problem situation is collected and sorted. Information to be collected includes structure of the organization, processes or transformations that are carried out, and issues that are expressed or felt by organizational members. This stage necessarily builds upon and, in many cases, is difficult to isolate from the first stage. There are many techniques available in this stage such as work observation, interviews, workshops, and group decision-making sessions. Presley, et al. [9] discuss some tools that can also aid in this elicitation such as QFD and Analytic Hierarchy Process. 3.2 Stages 3 and 4: Root Definitions of Relevant Systems and Conceptual Models In Stage 3 of SSM, a “root definition” of a system to address the themes developed in Stage 2 is developed. Many of the design requirements identified in Stage 2 begin to identify elements of the root definition. This stage refines and completes the identification of the elements. The root definition is expressed as a transformation process that takes some input, changes or transforms the entity, and produces a new form of the entity as an output. Basically the root definition is a succinct statement of the system that defines the system in terms of “a system to do X, by Y, in order to achieve Z”. In SSM, the mnemonic CATWOE is used to guide the development of the elements of the root definition: • Customer: people affected by the system, • Actor: people performing activities in the system, • Transformation: the transformation carried out by the system, • Weltanschauung: the “world-view” or viewpoints held of the system, • Owners: the person(s) with the authority to decide how (and if) the system will be carried, • Environment: the larger system within which the system under consideration exists and operates. Each root definition involves a certain view of the world. These worldviews must come from a variety of sources. The advantage of the CATWOE approach is the explicit identification of owners, customers and actors and their opinions of the organization and systems. ERP systems involve complex interaction of people, information, and processes. Its successful implementation depends on the involvement and cooperation of a diverse constituency of individuals and organizations. It should also be realized that the nature of an enterprise wide system such as ERP means that an Actor within on context may be a Customer in another. Again, the identification of roles and needs is critical. The owners (in this case top management who approves the system) are also important in that IT literature has clearly demonstrated that top management is critical for successful implementation of such systems. Another constituency whose role must be identified in this case is that of the consultant. The complexity of ERP systems means that most companies do not have the expertise internally to fully support an implementation. Consultants are often discussed as a critical success factor for ERP implementations [1, 6]. Stage 4 includes the construction of a conceptual model for the root definitions of Stage 3. Where the root definitions describe the “whats” of the situation, the conceptual models begin to define the “hows”. The conceptual model identifies what the system needs to accomplish. It identifies the activities in the system and their interactions. These activities, typically expressed using verbs, describe what has to happen for the system to meet the goals and aims defined in the root definition. Most often these conceptual models are expressed as models in a pictorial/flowchart form. All of the elements of the CATWOE mnemonic must be incorporated within the conceptual model for it to be complete. The models for many ERP systems are determined largely by the systems

themselves. Performing analysis of ERP systems includes extensive business process modeling and reengineering. Many ERP systems include their own process modeling languages. For example, SAP prescribes the use of a reference model and the Event Driven Process Chain (EPC) method to support its R/3 software [7]. In addition, most commercial ERP systems are based on relational database models, and so would require the development of extensive Entity Relationship Diagrams (ERD). ERP systems, like most information systems, are themselves models of an enterprise. The nature and scope of ERP systems make them exceedingly complex like the enterprises they model. While SSM does not prescribe any particular modeling approach it is important to consider the many aspects of an enterprise including processes, activities, organization, information, and resources. The need for multi-view models is discussed by a number of sources (see, for example [4, 7, 12]). Modeling an information system using traditional systems analysis and design methods also requires the development of several different models, which could include (depending on the method being used) data flow diagrams, entity relationship diagrams, state transition diagrams, information systems planning matrices, etc. Here the use of the root definitions and the CATWOE will help ensure (but certainly not guarantee) the consideration of relevant processes and entities. 3.3 Stages 5 and 6: Comparison of Conceptual Models with the Real World and Feasible, Desirable Changes In Stage 5, the conceptual model is compared with the “real world” system to highlight possible areas where changes are necessary. This conceptual model will identify where problems or deficiencies exist between what is happening (the 'rich' picture) and what is desirable (the 'root definition') as defined by the models. The process and other models developed in Stage 4 are of use here. In an ideal situation, the situation of stage 4 could be implemented through the ERP systems. In reality, however, if we are looking at an ERP system, the situation is not ideal in that changes are sometimes imposed. Most ERP systems by their nature use best practice templates that organizations must adopt. Implementing ERP often requires the reengineering of existing business processes to the templates of the ERP system being used. In Stage 6, changes to address the ‘disconnects’ or gaps between the conceptual model and the real world identified in Stage 5 are introduced and evaluated for feasibility. It will be necessary to compare and see which of these situations are possible. Among the decisions here might be whether to change the situation to suit the ERP system or to make changes to the software to match the situation. If different ERP systems are being considered, this stage presents a framework for organizing the analysis. The company could compare the ERP systems to identify which best fits the organization. Even if a particular system has been chosen, this stage allows for an analysis of how well the system addresses the disconnects and will help to identify modifications to the ideal. Alterations in may be required such as the changing of the way certain activities are accomplished, or could result in the identification of activities not currently performed in the real world. In the case of legacy systems, modifications or interfaces to these legacy systems could be identified. A critical output of this stage is the agreement on changes to be made – something which is facilitated through the use of the SSM. 3.4 Stage 7: Actions to Improve In stage 7 of the SSM, recommendations for change are implemented. For the ERP system, this is the implementation of the system itself with the accompanying organizational and process changes. The implementation of the system and associated changes will result in a modification of the problem situation. This new situation may lead to a new cycle of the methodology.

4. Applicability of SSM to ERP Several factors make SSM a viable framework for ERP analysis. The concept of the Human Activity System is at the core of SSM. Information systems are by their nature social systems consisting not only of software and hardware but also of people and procedures. This is especially true of a pervasive information system such as ERP. SSM was designed specifically to deal with the complexity of social systems. Bingi, et al. [1] state that ERP implementation is about people, not process or technology. SSM, with its emphasis and integration of the human aspect with technology clearly supports the types of organizational change required by ERP. The explicit consideration and involvement of customers and actors prescribed by SSM is especially important for the successful implementation of ERP. Attention must be paid to the purposeful action the information system is supporting and the meanings that make those actions meaningful & relevant. In analyzing ERP, there is a critical need to understand how actors conceptualize the situation. SSM is also has a focus on learning. Through the iterative

process of analysis, more is learned about the situation. With the current emphasis on the learning organization, SSM provides a powerful framework for supporting and increasing organizational learning. This paper in no way means to imply that SSM by itself can result in or ensure successful ERP implementation. The complexity and pervasiveness of ERP requires the integration of many tools and methodologies. SSM cannot replace Structured Systems Analysis and Design Methodology (SSADM) and other IS development methodologies. Nor can it replace Business Process Reengineering (BPR) and other process analysis and design efforts required of enterprise integration systems such as ERP. It can, however, enrich SSADM and BPR, especially during information requirements determination. The nature of the ERP analysis also presents a challenge. It is probably unreasonable to think that a single SSM analysis can be conducted for an entire ERP project. It would be necessary to break the analysis into smaller, more manageable pieces, perhaps by different business processes or by modules of the ERP. This would, in fact, support the way many companies attempt to implement ERP – not as a single implementation but following a modular or phased approach. Here, the learning aspect of SSM could assist in identifying issues that could be used to improve the implementation of subsequent modules. SSM analysis is not a linear process – many iterations and refinements are required, and in fact, desirable. Also, it is acknowledged that modifications to the SSM method are necessary for a problem as complex as that of ERP implementation.

5. Conclusions ERP implementations are extremely complex and challenging. They are not mere exercises in software development but involve the redesign of processes, organizations, and information flow. Given the importance of considering human and other factors in the implementation, it is suggested that SSM can provide a powerful framework and represents another tool for assisting in this endeavor that is critical for the continued success and viability of many organizations.

References 1.

Bingi, P., Sharma, M.K. and Godia, J.K., 1999, “Critical Issues Affecting and ERP Implementation,” Information Systems Management, 16(3), 7-14. 2. Chan, S.L., and Choi, C.F., 1997, “A Conceptual and Analytic Framework for Business Process Reengineering,” International Journal of Production Economics, 50(2/3), 211-223. 3. Checkland, P., 1981, Systems Thinking, Systems Practice, John Wiley & Sons, London. 4. Curtis, B., Kellner, M. and Over, J., 1992, “Process Modeling,” Communications of the ACM 35(9), 75-90. 5. Davenport, T.A., 1998, "Putting the Enterprise into the Enterprise System," Harvard Business Review, 76(4), 121131. 6. Holland, C.P., and Light, B., 1999, “ A Critical Success Factors Model for ERP Implementation,” IEEE Software, 16(3): 30-36. 7. Kamath, M., Dalal, N.P., Kolarik, W.J., Chaugule, A. Sivaraman, E., and Lau, A.H., “Process-Modeling Techniques for Enterprise Analysis and Design: A Comparative Evaluation,” Proc. of the 2001 Industrial Engineering Research Conf., May 20-22, Dallas, Texas. 8. Krumbholz, M., Galliers, J., Coulianos, N., and Maiden, N.A.M., 2000, “Implementing Enterprise Resource Planning Packages in Different Corporate and National Cultures,” Journal of Information Technology, 15(4), 267279. 9. Presley, A.R. Sarkis, J., and Liles,D.H., 2000, "A Soft Systems Methodology Approach for Product and Process Innovation," IEEE Transactions on Engineering Management, 47(3), 379-392. 10. Somers, T.M. and Nelson, K.G., 1998, "Towards an Understanding of Enterprise Resource Planning implementations," Proc. of the Americas Conference on Information Systems, Baltimore, MD, 725-727. 11. Winter, M. C., Brown, D. H. and Checkland, P. B., 1995, “A Role for Soft Systems Methodology in Information Systems Development,” European Journal of Information Systems, 4(3), 130-142. 12. Zachman, J., 1987, “A Framework for Information Systems Architecture,” IBM Systems Journal, 26(3), 276-292.