Abstract
This chapter addresses the problem of enterprise resource planning (ERP) implementation in Higher Education Institutions (HEI).
It attempts to contribute to the understanding of ERP implementations in this kind of organizations by identifying and analyzing the major factors that affect this type of projects. Special attention has been paid to contextual influence and to organizational factors. The conclusions of this work suggest that most problems in ERP implementation projects are not technological but may be attributed to organizational factors. The chapter describes an in-depth case study carried out at a HEI that implemented an ERP system in 2001. The case was studied as part of a grounded theory based research project whose aim was to develop a model for the implementation of ERP systems.
Introduction
In recent years, a growing number of HEIs worldwide are exploring the use of ERP systems as a means of supporting their organizational processes, while linking areas like financial, real estate, and staff management, management of students, and support of teaching and learning. This adoption of ERP systems by HEIs is bringing problems in ERP implementation projects that are specific to these types of organizations. Because HEIs comparatively have modest IT/IS resources and budgets, they expect to benefit largely from implementing off-the-shelf application products like ERP systems. They do not usually have the depth of experience or a constant availability of adequate expertise to be able to handle the in-house development of an enterprise-wide system.
The Essay on Systems Development/Project Management and Outsourcing
The purpose of this assignment is engage in a discussion regarding Systems Development, Project Management, and Outsourcing. The seven phases of the systems development life cycle will be described. Relationships between the systems development life cycle and software development methodologies will be detailed. The phases in the SDLC, including activities associated with planning, analysis, ...
This chapter reports the results of an in-depth case study carried out in the economics management area of a Spanish HEI that implemented an ERP system in 2001 by following a “big-bang” implementation approach. The big-bang approach is characterized by the “go live” of all implemented ERP modules at the same time.
The interpretive perspective adopted in our research reflects our aim for understanding the phenomenon of ERP implementation in a HEI within the full-fledged organizational context where it occurs. In order to keep the confidentiality of the research site and the people involved in this case study, we deliberately omitted the name of the institution and ERP product. The chapter is structured as follows. First we present the literature review on ERP. Then we describe the case study background. Next, we present the research methodology. Subsequently, we describe the findings. Finally, the conclusions and the implications for further research are outlined.
Prior Research on ERP
Aladwani (2001) stated the following:
Past ERP implementation research may be described as factor research, which involves identifying the factors or variables that are critical for implementing ERP successfully. Although factor research is valuable for advancing our understanding of ERP implementation success, it adopts a static view, which limits its adequacy in explaining the dynamics of the implementation process. (p. 267)
Aladwani (2001) and Robey, Ross, and Boudreau (2002) suggested a process research approach or a combination of factor and process approaches, in order to improve research in ERP topics. Using a process approach, ERP implementation may be conceived as sequences of discrete events that lead to outcomes of particular interest. Some studies focused on ERP impacts at organizational, technological, and business levels, business process reengineering, and organizational change management issues. However, the few studies developed so far are not enough to create a body of knowledge in the area. Case studies, not necessarily in-depth, constituted the largest category of articles. From the perspective of research methodology, Esteves and Pastor (2000) detected that in some of the referenced studies, there was a lack of explanation of the research methodology applied, lack of data to support the presented results, and lack of assumptions or hypotheses (in theoretical terms) for further studies. Furthermore, although some studies attempted to identify critical success factors for ERP implementations in general (e.g., Esteves & Pastor, 2000), and more specifically to HEI (Nielsen, 2002), there is a lack of research on the management of these critical success factors.
The Research paper on Business studies-intrapreneurship case study
Intrapreneurship Case Study of the Sony Corporation, according to Ken Kutaragi PlayStation Intrapreneur The story of the Intrapreneurial (corporate entrepreneurial) corporate struggles, determination and the ultimate creation of the very successful Sony PlayStation by persistent and driven intrapreneur Ken Kutaragi, who’s international Intrapreneurial Success story has now become one of the ...
In sum, as Robey, Ross and Boudreau (2002) mentioned, the research on ERP has been mostly descriptive. They pointed out that “little attention has been paid to developing a compelling theoretical explanation of ERP implementation, which is needed to explain contradictory findings and to allow generalization of findings to related phenomena” (p. 21).
Due to lack of theoretical foundations on the ERP domain, it seems appropriate to investigate ERP implementations by using grounded theory applied to data drawn from in-depth case studies.
Case Study
The Spanish HEI of our case study defines its mission in terms of quality teaching, research, and technology transfer. It was created in the 1970s, and it is composed of several academic schools and research institutes with more than 30,000 students and more than 2,000 teachers.
The HEI economics management area is composed of two general departments: the economics department and the technology transfer unit. There are also economics management personnel in each structural unit. Until 1999, both the economics department and technology transfer unit had their own legacy systems that were totally independent. The units (schools and institutes) were responsible for sending the accounting documents to the economics department or technology transfer unit, and these departments processed them in the respective legacy systems. Table 1 describes the different actions taken to improve information technology infrastructure in this HEI.
The Term Paper on Project Management For Information Systems
Abstract Information systems (IS) projects are vulnerable to resource cutbacks and the increasing complexity of systems and advances in information technology make finding the right personnel difficult and the associated development costs high. Good project management is essential for success. Some alignment methodologies include IBM's business systems planning (BSP), Robert Holland's strategic ...
This HEI followed a typical big-bang ERP implementation approach with a well-known European ERP package. The number of expected end users was around 220. The HEI implementation project followed the typical implementation phases: planning, design, realization, go live, and support. At the beginning of the project, it was estimated that some be-spoke development would be made to fulfill some special requirements.
This ERP project had a delay of 1 year in relation to the initial project plan. Based on a process research approach, we describe the main events and activities that may have caused this delay.
Research Methodology
As we believe that the understanding of ERP implementations cannot be achieved without considering the organizational context in which they occur, the main research method chosen was in-depth case study (Yin, 1994).
Furthermore, we opted for an interpretive research approach. Interpretive research does not predefine dependent or independent variables, and it attempts to explain phenomena through the meanings that people assign to them (Orlikowski & Baroudi, 1991).
We started the case study by defining a data collection plan. The main technique chosen for data collection was semistructured interviews. The HEI president (vice president at the time of the ERP implementation) and the ERP project manager were initially contacted in order to permit the study to be carried out and to collaborate in this research project. After permission was obtained, the project manager granted access to most of the documents produced during the project. Later, we asked to visit and interview them, as well as other people who played relevant roles (external consultants, project team members, key users, end users) during the ERP implementation project. Our first task was to analyze the documentation created during the ERP implementation project. This documentation helped us to understand the project background and to prepare the questions for the interviews. Later, data from interviews were triangulated with the documentation so far accumulated. In order to build theory from this case study, we decided to adopt the grounded theory method.
The Essay on IT Project Implementation Failures
Subsequent to a health care organization acquiring a new information system, is the system implementation process, the third of four stages in the systems development lifecycle. A significant amount of support and dedication is needed from senior executives and should take precedence within the organization. Adequate resources should be available to all individuals involved in the execution of the ...
Grounded theory is a general method developed by Glaser and Strauss (1967) for building theories that are grounded in data systematically gathered and analyzed. Strauss and Corbin (1990) explained the use of grounded theory:
A theory is inductively derived from the study of the phenomenon it represents. In Grounded Theory method one does not begin with a theory, and then prove it. Rather, one begins with an area of study and what is relevant to that area is allowed to emerge. (p. 23)
In our study, the coding process of all interviews and documentation allowed for major themes and categories to emerge. Then, we used the paradigm model proposed by Strauss and Corbin (1990) to relate these categories. Briefly, the paradigm model encompasses the following elements: causal conditions, phenomenon, context, intervening conditions, strategies and actions, and consequences.
A Grounded Model from ERP Implementation
In this section, we describe the specific paradigm model (Figure 1) that we developed by using grounded theory from the data collected from our case study.
Phenomenon
Strauss and Corbin (1990) stated that phenomena are “the central ideas in data represented as concepts” (p. 101).
According to their account, the purpose behind naming phenomena is to enable researchers to group similar events, happenings, and objects under a common heading or classification. The phenomenon in the paradigm model is represented by the central category (sometimes called the core category) that represents the main theme of the research. The phenomenon addressed in this study is the implementation of an ERP system in a HEI.
Causal Conditions
Based on the project documents and the interviews, we identified the following reasons to adopt the ERP system: legacy system obsolescence, complex and expensive maintenance process, Y2K problem and Euro conversion, and existence of an isolated legacy system for the technology transfer unit.
Environmental Context
By the time ERP implementation at our HEI took place (beginning in 1999), none of the Spanish universities were implementing ERP systems. However, most Spanish universities were thinking about improving their information systems, possibly through abandoning their legacy systems and migrating to ERP systems. Again, problems related to the Y2K problem and the new Euro currency were viewed as strong justifications for carrying out deep changes in information systems. At that time, ERP vendors started approaching the HEI market, and they began to offer ERP solutions adaptable to the HEI market.
The Essay on The Importance of A Project Management Office
Project management can be a tedious job especially if the personnel or department in charge is already loaded with tons of work. It may be hard to cope up with the schedule, time pressure, workload, and other factors. In line with this, the task of handling such tasks must be assigned to a specialized department known as Project Management Office. What is a Project Management Office? A Project ...
The Spanish government also started changing legal requirements and obligations in terms of financial reporting, especially with regard to budget control.
Organizational Context
The organizational culture of our studied HEI is characterized as a bureaucratic culture. According to Wallach (1983), bureaucratic cultures have clear lines of responsibility and authority and work is highly organized, compartmentalized, and systematic. The information and authority flows are hierarchical and based on control and power. Overall, bureaucratic companies tend to be mature, stable, and relatively cautious.
Our HEI possesses a culture in which most of the times, delays in decision making and expected results are explained in terms of “due to the process,” which refers to the high procedure orientation within this HEI. In this context, it was expected from top management that the ERP implementation would change the way things worked in the organization. However, there was the general perception that organizational culture would not allow for maximum benefits from the ERP system to be achieved, mainly due to the lack of power of some of the involved units.
Intervening Conditions
Because an adequate project manager role is one of the ERP implementation critical success factors, we describe this aspect in the next section actions and interaction strategies. The HEI started on the selection of the consulting company after the selection of the ERP system. The main arguments for selecting the consulting company were ERP vendor recommendation and experience with ERP implementation in the public sector. At the time of the implementation of the project, this consulting company lacked senior personnel in the ERP implementation area, a fact that was then unknown to the HEI.
The Business plan on Project Cycle Management
Chapter 3 introduces the Logical Framework Approach (LFA), explaining its role in project design with a simple project example. It explains how sustainability / quality factors can influence a project’s chances for success, and indicates the range of Where to tools that are available to take account of these factors. It also explains how you can find what? use the logframe matrix to develop ...
Action/Interaction Strategies
In the action and interaction strategies, we used as a priori categories the critical success factors from the unified model first proposed by Esteves and Pastor (2000) and shown in Table 2. Although some studies such as Nielsen (2002) tried to identify critical success factors specific for HEI projects, we opted for our generic model for ERP implementation projects.
Due to space limitations, in this chapter, we focus on the strategic and organizational perspectives within Table 2. The strategic perspective is related to the core competencies accomplishing the organization’s mission and long-term goals. The organizational perspective is related to concerns like organizational structure and culture and business processes. Next, we describe the findings according to each critical success factor within these perspectives.
Sustained Management Support
According to the interviewed stakeholders, in the case of the HEI, the continuous support of the top management was exercised specifically by the then vice president of the university. It was he who participated more actively in the ERP implementation process, mainly after the initial deviation regarding the first project plan. The vice president participated in almost all the meetings of the steering committee. He motivated the project team and contributed with his knowledge about the operation of the university, both at the general level and in terms of its financial management.
The vice president role was crucial as a mediator during some tensions arising from resistance to change. A member of the steering committee manifested that “a project of this type was not high priority for the university.” Initially, top management presented the ERP project like a project bounded for the economics management area; they did not look at it as a strategic project for the whole university.
Effective Organizational Change Management
According to the implementation consulting company, the change management process was in the charge of the HEI, because the HEI decided to assume this task instead of hiring it from the consulting company. In that sense, one of the vice president’s initiatives was to create three working groups: a group for analyzing functional economics management skills and competences, another group for planning training, and a third group for defining processes. The first two groups obtained useful results but not until after the go-live of the new ERP system. However, those groups did not establish adequate relationships between them. The third group did not conclude with results that could be used in the ERP implementation project, neither before go-live nor after. Some interviewees said there was lack of coordination among the three working groups, and that they should have begun their respective tasks before the beginning of the ERP implementation project, or at least in its beginnings.
On the most favorable side, the economics department presented optimistic expectations of the project, not because of the ERP system but because of the obsolescence of its own legacy system. According to some interviewees, they also had the opportunity of taking advantage of the ERP implementation project to carry out an internal reorganization of the unit. On the other hand, some of those unit managers who showed a rejection to the system from the beginning did it mainly for three reasons: they knew of some bad ERP experiences in nonacademic organizations; they were already sufficiently satisfied with the economics management functionality locally offered by their respective dedicated and isolated legacy systems; and they did not see justification for changing their local economics management processes. These three reasons were argued explicitly in the case of the technology transfer unit.
On the planning and materialization of the change management associated with the ERP project, widespread agreement exists about the convenience of having approached the change management analysis and preparation tasks before the beginning of the implementation project, instead of addressing them during the implementation, mainly in what refers to the integration and standardization of economics management criteria and information among units.
Good Project Scope Management
The interviewed stakeholders said that, in general, the project scope did not vary much along the ERP project. With enough flexibility, the project manager and the steering committee were agreed in their justifications to make some incorporations and changes in the implementation priorities of some functionalities and modules. For example, in the middle of the project, they decided to incorporate the inventory management module, which was not initially planned. Regarding the flexibility in project scope management, some stakeholders complained about the lack of documentation about the decisions taken and lack of justifications in terms of functionality to be implemented, incorporations of new functionality, priority changes, etc., which left these stakeholders with the impression of certain improvisations or decisions being made “on the run.”
Adequate Project Team Composition
With the exception of the software vendor role, the project team covered the rest of areas of interest along the whole project. However, the unanimous opinion, including that of the interviewed implementation consultants, is that the excessive turnover of the implementation consultants complicated the implementation process. With regard to the internal project team, almost all their members continued doing their full working functional activities in parallel with the ERP project. This factor complicated the progress of the project and diminished the satisfaction of team members. And, this factor is given as a justification for the little and poor cooperation of these members with the external implementation consultants.
Following the same line of previous IT/IS department outsourcing decisions, top management decided not to create an internal team of experts in the implemented ERP system; they decided to outsource the future ERP system maintenance. According to some interviewees, the transfer of knowledge to the external consultants should have been made through the IT/IS department personnel specialized in economics management and initially assigned to the project. These people knew extensively the needs of the economics management, the limitations of the existent legacy systems, and some of the limitations of the ERP systems. However, the IT/IS department totally avoided any implementation tasks from the beginning of the project, limiting its intervention to offering services related to the technological infrastructure. Several interviewed stakeholders, among them some from the IT/IS department, related such avoidance to the previous outsourcing of the IT/IS department to a new IT company owned by HEI, with a business model that was at odds with the maintenance of business applications. Some opinions pointed to an additional reason for such an attitude from the IT/ IS department: the incorporation of an external project manager for the ERP implementation project, in detriment to the internal leadership from the IT/IS department.
Some interviewees also complained about the insufficient representation of the units in the project team and the steering committee.
Comprehensive Business Reengineering
Before starting the ERP implementation, the steering committee commissioned a project team member to model the existent economics management processes, a task that he completed during the first phase of the implementation project. Then, redesigns of some economics management processes were made, still without considering the ERP system. Based on the generated documentation, the external consultants extended the analysis of processes before starting the system configuration phase. With this, they obtained the “as-is” analysis that already incorporated some improvements based on the use of the functionality of the ERP system.
According to most of the interviewees, after the as-is analysis, both the “to-be” synthesis (description of the redesigned processes) and the “gap-analysis” (description of the differences between the previous processes and the pursued ones) were made on the march for each economics management process approached and were immediately configured on the ERP system. This approach did not allow for the creation of a global transversal model of economics management that would include most of the processes analyzed before their configuration. In general, the ERP system was adapted to the existent processes rather than the other way around.
During the functional analysis phase, no method or modeling tool was used and the final model of economics management processes was not documented.
With regard to the tensions around the analysis and possible process changes, the case of the economics management processes associated with the technology transfer unit deserves special attention. In the steering committee, the people responsible for this unit often showed their strong rejection to changing their processes and their system.
Several interviewees think that in this aspect, a true abyss appeared between the philosophy of operation of the ERP standard for economics management and that of the technology transfer unit. Those practices were very well covered by its legacy system, but they were at odds with the new economics management rules. Interviewees pointed out the following reasons behind the technology transfer unit position: they were used to the autonomy of having their own legacy system; they feared possible loss of personnel, organizational autonomy, and power; and the technology transfer unit rejected the decentralization of part of their processes to the units and to the economics department.
The technology transfer unit case has been the topic of greatest conflict in the whole ERP implementation project in the HEI. After many meetings, debates, and tensions, the ERP implementation in the technology transfer unit has become a big set of bespoke developments around the ERP system, rather than an ERP configuration starting from the ERP standard. On the other hand, the current system has facilitated greater integration between the technology transfer unit and other units.
Adequate Project Sponsor Role
Officially, the figure of ERP project sponsor did not exist. However, there is overall agreement that the then HEI vice president acted as such. One of his crucial functions was to act as mediator. He helped to energize the activities of the team, to define objectives, and to reach small goals, and he contributed decisively to the resolution of the most conflicting situations. As the expert on the management model of the university, because he had lived the whole process of its creation, the vice president helped the people that represented central departments such as the economics department. The units were listened to and they worked together, working out consensus from some initially opposed ideas.
Adequate Project Manager Role
The project manager was hired after the selection of the ERP system, after the selection of the implementation consulting company, and after the creation of the initial project team. According to him, this circumstance already limited his initial performance. His external origin, on one hand, helped him to maintain neutral positions in relation to some organizational conflicts, but was, on the other hand, an initial inconvenience for understanding the organizational culture of the university. There is agreement among the interviewees about the convenience of incorporating somebody external to the organization to manage a project of this type.
A positive aspect of the project manager, commented on by various interviewees, was his open attitude to discussing and to solving conflicts, always trying to follow the legal mechanisms and the appropriate procedures for economics management. The main negative aspect indicated by most of the interviewees was his lack of previous experience in ERP implementations.
Some interviewees noted the lack of monitoring and formal control of the project transmitted by the project manager and the project team in some moments. The project manager and the consulting company did not adopt any implementation methodology, which is also behind the projected uncertainty.
User Involvement and Participation
The implication and wider participation of users refers, according to the interviewees, to the end users of economics department and technology transfer unit. According to the project documentation and the opinion of most of the interviewees, the levels of implication and participation of users from the units was low, probably because the project team and the steering committee did not involve them sufficiently. According to the then vice president, this situation was due to the limitation of budgetary resources that did not allow for the partial liberation of some users from their usual tasks, so that they could be devoted more to the project.
Although both the project team and the steering committee included representative members of the units, some opinions manifested that those people acted more personally than as representatives of the units. Some interviewees indicated that the units were asked for explicit opinions on several occasions, for example in the validation of the definition of the processes, but that the units did not respond to such demands.
Only at the end of the project, in the validation phase, were key users from the units involved and helped key users from the economics department to validate the resulting economics management model. Some economics department users commented that the conjunction of the following facts caused a lot of stress: late implication of the units, lack of time to assimilate the training of the new system, and the coincidence of the end of the year (and the related accounting procedures) with the training and testing activities.
Trust between Partners
Initially, during the ERP selection and the beginning of the implementation, there was a high level of trust between the HEI, the implementation consulting company, and the ERP vendor branch in Spain. Soon after, a crisis developed in the mutual trust for various reasons.
Regarding the initial relationship between the HEI and the implementation consulting company, most of the interviewees say that the HEI surely trusted excessively in the consulting company. This company at the beginning was sold with the mark or they were hung the medal of being the only consulting company with experience in such a type of ERP implementation in Spain. However, at the beginning, the consulting company omitted that their previous experience consisted in extensive customization and little configuration of the international standard maintained by the ERP vendor.
On the other hand, the ERP vendor in Spain openly referred initially to the HEI as its strategic partner for the HEI sector in Spain, and it committed to facilitating the Spanish standard of all the needed modules by the beginning of the implementation. This did not happen, and, in fact, the ERP vendor several times postponed the delivery of one key module, causing considerable delay in the beginning of the project. Such uncertainty on the delivery of the ERP system caused a lot of insecurity and stress in the implementation consulting company, and in the atmosphere transmitted to the rest of the project team and the steering committee. In some way, the HEI was aware that the consulting company was also suffering from the lack of commitment and collaboration of the ERP vendor. In fact, the ERP vendor was detaching itself gradually from the project, even ending up with one of its high-level commercial representatives manifesting that the project was no longer considered as “strategic” for his company.
Consequences
Business Process Reengineering (BPR)
Although BPR started in the design phase, its effective change occurred in the go-live phase. Parallel to the implementation of the ERP system, managers started changing the business processes while explaining them to the organization. The project team admits that this should have been done before the implementation, because some processes were obsolete or inadequate. Currently, during the postimplementation period and using the knowledge that the project team acquired, they are continuously improving processes by extending functionality through the current discovery of functionality in the ERP system.
The ERP system brought in new business processes and is helping in the reengineering of the old ones. As the project manager mentioned, the HEI does not have any distinctive economics management processes. Therefore, they would not have lost competitiveness by adopting the ERP best practices. On the contrary, the adoption of practices that the ERP provides helped to reengineer the existent business processes and simplified implementation and future maintenance efforts.
Change of Mentality
One of the most interesting consequences of this ERP implementation was the induced change of mentality. At the beginning, most of the users disagreed with the implementation of the system, but their attitudes reversed progressively after the go-live phase. Nowadays, they recognize that the ERP system is useful and that it has helped to improve the HEI processes. They think that more business analysis is still necessary, with managers demanding more people to improve the work. Some users were moved from their old functions, while others had intensive training. Now, only a few employees are still not using the system. Some of them are managers of small units that do not have enough economics management documents to justify one person being allocated to economics management tasks. The solution has been to create a special group in the economics department that manages all the economics management documents from the small units. Now, users are not afraid of changes. They are aware that the system is about continuously improving processes.
Lack of Internal ERP Knowledge
Following the same line of previous IT/IS department outsourcing decisions, top management decided not to create an internal team of experts in the implemented ERP system; they decided instead to outsource the future ERP system maintenance. Given the nature of the implementation carried out, this strategy is questioned by many stakeholders who consider the current situation as one of excessive dependence with regard to the implementation consulting company. HEI managers now know that they are totally dependent on the consulting company, and they are trying to change this in the near future.
Conclusions and Implications for Further Research
In this chapter, we attempted to provide a view of the ERP implementation process in an HEI. To the best of our knowledge, we present the first grounded theory model for ERP implementations in HEI. We think that the main conclusion of this study is the evidence that organizational and cultural issues have a strong impact in ERP implementation projects. In the particular case addressed in this study, if those issues had been taken into account during the planning phase, it is very likely that some problems would have been avoided or at least mitigated.
In our case study, the findings suggest that organizational culture and structure may have an influence on the management of critical success factors. These could be helpful in explaining some ERP project issues and, therefore, defining a strategy for ERP implementation. Research on critical success factor identification does not explain why some factors are more relevant in some organizations than others. Cultural issues can be responsible for this. The influence of culture has mainly focused on the IS solution and how it fits with the organizational culture or the cultural changes.
We believe that our study of the ERP implementation process is a valuable contribution to the literature, yet the generalizability of our propositions is limited due to the scope of the sample, only an in-depth case study. We would like to emphasize that this was an in-depth case study combined with grounded theory method that took more than a year of documentation analysis, interviewing, and data coding and analysis.
