Planning and Implementation of an ERP system in a University in USA: Some Insights and Guidelines C. Somarajan csomarajan@semo.edu Department of Accounting and Management Information Systems John R. Weber jrweber@semo.edu Information Technology Ken Surendran ksurendran@semo.edu Department of Computer Science Southeast Missouri State University, Cape Girardeau, MO 63703. Abstract This paper discusses the successful planning and implementation of an ERP system in an academic institution. Such an endeavor is a complex process involving technical, financial, organizational, and operational issues. The first two are hard issues that can be handled through standard approaches. However, the last two, being somewhat soft issues, require special approaches for ensuring success. The dynamics of these two soft aspects in academic institutions are somewhat different than those in business organizations. The authors, pooling their management and academic experiences in dealing with ERPs, discuss various approaches to handling both the hard and soft issues, especially the soft issues that are specific to academic institutions. They observed that the implementation of the Human Resource, Finance, Advancement modules went smoothly. However, a few glitches were encountered during the implementation of the Student module due to problems in data migration from the legacy system. Also, additional third party software products are being installed to meet the functionalities not offered in the ERP system. In the absence of established common standards and best practices for planning and implementation that are specific to academic institutions, this paper may be of use to the future ERP adopters in academia. Keywords: ERP planning in academia, organizational and operational issues 1. INTRODUCTION Unlike industry, not many universities took to ERP as a solution to their Y2K problems (King, 2002). The reason for this could range from the academic pride in extending the life of the plethora of legacy systems developed by many universities for managing different segments of the business to the low recognition of the transforming power of IT in academia. Some universities, who have the capability to maintain complex applications, prefer to extend and renew legacy systems instead of migrating to one of the well-known ERP systems. However, in many universities, the lack of integration of different functions and the diminishing support for those legacy systems force them to consider ERP alternatives. A survey in 2002 (King, 2002) indicated that the academic take up on ERP has been slow. While single location ERP implementations are common, a few, due to geographical dispersion, have implemented multi-campus institution-wide (Holland and Sullivan, 2005) and system-wide (Baker and Earnst, 2002) covering universities in a state system. A recent report indicated (CN&C 2008) that in 2007, thirty academic institutions opted for Jenzabar’s Total Campus Management, an ERP solution. Another report indicated that as of 2008, around 150 institutions in USA and Canada have opted for Oracle and PeopleSoft ERP solutions (CN&C, 2008a). Of late, some universities have opted to use ERP products by Datatel (CN&C, 2008b). The authors outline the details of the planning and selection of an ERP, and its implementation at their university. With over 140 years of history, this public, regional, and mostly undergraduate institution was using several legacy information systems to manage its affairs. In 2002, a final decision was made to adopt an ERP system that could offer integrated tools for both administration and operations. The details presented in this paper include the factors that led to the ERP consideration, feasibility study, request for proposal, vendor presentations, selection process, the instruments used (criteria and weighting) for evaluation, and the implementation – including plans, training, and review. In addition to these hard issues, the authors discuss approaches taken specifically for handling the operational and organizational issues encountered in the process. Since such issues may not be unique only to the authors’ university, this case study could be of some value to other institutions who are considering ERP solutions. 2. LEAD UP TO ERP The move to ERP at this university evolved around 2002. The initiative received undivided support from the IT Committee (ITC), a university level committee consisting of, in addition to the CIO, representatives from all colleges and functional units, which assists in strategic planning for the IT function and also oversees the realization of major IT initiatives such as ERP adoption. 2.1 Strategic Planning Recognizing the strategic significance of technology in sustaining the university’s growth, the various facets of Information Technology function were integrated in 2001 with its role defined through a vision statement: To be the regional leader for the appropriate deployment and effective assimilation of IT for supporting the delivery of world class educational service. ITC recommended replacing the legacy systems with an ERP system along with the necessary support structures within the next five years. In 2003, the university allocated a budget of $3 million for this initiative and recruited a suitable CIO - with considerable prior experience in introducing ERP in academia - to lead this project, which is a critical element in realizing the vision. In the following, the limitations of the legacy systems that led to the ERP initiative are highlighted. 2.2 Legacy Systems About half of the systems that were in use prior to the ERP implementation were written in-house and run on an IBM mainframe using mostly CICS DL/1. Later, SQL servers were added for data warehousing and as front-ends to provide access through the web. In addition, there were several major third party utility systems and other functional systems. The in-house systems included student management system (which catered for registration, financial aid, receivables, receipts, admission process, textbook rental, residence life, and parking), materials management system (including inventory, internal billing, master catalog, work orders, and facilities management), and several interface programs to link the different third party systems (such as financial system, HR and payroll, security systems, student advising system). Some of these third party software systems had their origins in other academic institutions like DARS (an advising system from Miami University), MUSIC (an editor from McGill University.), etc. Since most applications were home grown, there was tremendous maintenance workload. Over the years, users in the functional areas had developed (with support from IT services in some cases) several shadow systems to meet their changing requirements. The complexity of current systems is shown in Figure 1(Appendix 1). The shadow systems caused unique problems since they did not follow much of the standard IT practices. 2.3 Need for Replacement The mix of legacy systems catered to most of the requirements and there were equivalent systems for the student, human resource and finance modules offered in most ERP systems. Unlike the ERP systems, where the modules are integrated seamlessly, the integration in the legacy systems was managed through a host of interfaces. The maintenance of these interfaces was becoming harder and required ever increasing resources. The mushrooming of individual shadow systems indicated the lack of features and essential functionalities in the overall system portfolio. The rationale for replacement of the legacy systems with an ERP stemmed from the following: * Difficulties in maintaining the integration between the various legacy systems * Mushrooming shadow systems (that were not adequately supported) * Difficulties in scaling the legacy systems to meet the growth in operation * Difficulties in offering web based services * Difficulties in incorporating new technologies like GUI and web services with these mainframe based legacy systems 2.4 Feasibility Study In this sub-section, the authors discuss the steps ITC took for adequately addressing the technical, financial, operational, and schedule feasibilities. The budget provision for the complete project was $3 Million (based on cost estimates) that would be spent over a period of six years. This budget was meant to provide for all of the hardware, system software licenses, application software licenses, installation, training expenses, and annual maintenance as applicable. The project was justified more on the value perceived from improving the quality of service and less on concrete return on investment analysis. It was envisaged that the project cost would be recovered over the subsequent six years, when break even was expected to occur. In order to meet the steady growth in student enrolment and to enhance the integration between the legacy systems, there were two options: either enhance the existing system facilities (which did not scale well) through mainframe replacement within the next four years or consider a new integrated database solution to cope with the anticipated future growth. Since the costs of the two options were not very different from each other, the anticipated improvement in the quality of service, which an integrated system can offer, tilted the scale in favor of a new ERP. At the end of the project, the present hierarchical mainframe architecture would be phased out and replaced with a client-server architecture, which required less expensive system software and maintenance support. The technical team that was in place in 2004 was considered an asset for the new initiative as it is well placed to adjust to the new environment with suitable training. The associated change management for the base system implementation that was required for effectively realizing the value from ERP was part of the project. Training programs for various groups of users were included in the plan. In addition to user training, ensuring their involvement in all stages of the project was expected to reduce the project risks. The university was in a position to cope with the 2004-situation for two more years. This two-year time frame allowed for a meaningful schedule for all the project activities relating to a base ERP system implementation. The entire project duration was estimated at 30 months, from 1/1/2004 to 6/30/2006. 3. PLANNING FOR SUCCESS The planning in this case included all the activities for the pre-installation, installation, and post-installation. Having a competent technical team and a committed administration were helpful in planning the pre-installation activities. The planning for installation and post-installation activities was done in consultation with the vendor. Planning took into account the technical, financial, organizational and operational issues. The technical and financial issues were rather apparent and ITS used standard management processes for handling them. However, organizational and operational issues were mostly hidden and were usually handled under the broad category of change management, which often requires innovative approaches. Even though ERP systems are considered to embody best practices, it is important to take into account the operational (arising out of cultural differences) impacts on ERP implementation (Davison 2002). 3.1 Technical Planning The technical planning under pre-installation included preparing the request for proposal, adjudicating the submissions using established criteria, and vendor negotiations leading up to a partnership. It was important to look at the big picture at that stage even though the scope of the project was limited. (This was to ensure the integration of the future systems.) The big picture considered the infrastructure (such as a communication network) to enable successful deployment of the new system. Deficiencies were addressed and included as sub-projects. For instance, workstations in some of the functional units were replaced or upgraded. The campus had a communication network with adequate bandwidth for effective deployment of the newly integrated system. However, the upgrades to the computing network with standard equipment, operating systems and other system software to run the new ERP system were part of the project. The ERP did not replace all of the legacy systems. For instance the new ERP does not cater to the following processes: materials management, on-line student admission, residence hall management, classroom scheduling, and classroom resource management. Hence, plans were made to procure third party products alongside to supplement the new ERP system. Without getting suitable replacements for these functions, it would not be possible to phase out the mainframe. 3.1.1 Request for Proposal: Since the user community was not familiar with what features they could get from a client-server based ERP, it was decided to organize one-day product presentations on three different ERP products. Information Technology Services (ITS) collected broad requirements and expectations from all the major user groups (from executive, administration, faculty and students) and included them in the request for proposal (RFP). In all, nineteen action-teams contributed to the proposal preparation by providing their functional / unit’s needs and expectations. The project team studied four RFPs from other universities before writing the integrated RFP based on the users’ requirements and expectations. The final RFP had three major sections: Information about the university and its programs, functional requirements, and standards required for a state contact. The draft proposal was reviewed by ITC, which represents all the user groups. Of the 23 vendors in the ERP area, the final RFP was sent to twelve who were offering comprehensive products with the entire range of modules. Four vendors responded and three were invited to present their proposals. 3.1.2 Proposal presentation: Each of the three vendors was allocated three days on the campus to conduct several presentations to different groups of users. The entire university community was invited to attend sessions of their interests. At every session, written feedback from the participants was collected. The main issues considered in the feedback were the participant’s overall impression, perception on the strength of the product, observed areas of concern, and issues that needed further investigation. Users with personal contacts at reference sites were encouraged to gather additional information about the usefulness of the product and the vendor’s service levels. 3.1.3 Criteria for adjudication: Four major selection criteria were used for the vendor selection process. In the order of their importance (with weightings in parenthesis) they are: cost (40%), functional and technical capabilities (30%), experience, expertise and reliability of the vendor (20%), and proposed implementation and other services (10%). These weightings were decided with input from the president and the executive staff. Under cost, apart from itemized cost, the ownership costs for five and ten years were also considered. The product’s match with the functionality requirements from the nineteen teams received primary consideration under the functional and technical capabilities. In addition, issues like architectural match of the recommended hardware and platforms with those in ITS plans, user evaluations for the on-campus presentations, web access and portability capabilities were also considered. Under experience and expertise, references from universities of similar size were considered. In addition, audited financial statements and quality of product development also received due attention. Training, value added service, after-implementation support, and the overall implementation plan were considered under proposed implementation. 3.1.4 Contract negotiations: If the RFP is prepared carefully, there will be very little to negotiate after adjudication. However, issues like minor omissions in adherence to standards should be addressed at this stage. Usually, in projects of this magnitude, there will be a project manager assigned by the vendor. It is important to negotiate for a person who has the potential to adjust to the university’s culture and who can, in terms of skills, complement the local project manager. 3.2 Financial Planning Comprehensive financial planning is critical. Most state universities are presently facing severe financial challenges. For the author’s institution, a special fund was made available for this project. However, an advance was also made which will be recovered over the course of the next six years. Hence, a six-year financial plan was put into place. Nearly 75% of the recovery is to result from the savings due to phasing out of the mainframe. (This includes all maintenance and operational – including personnel – expenses related to mainframe.). The remaining savings needed result from the reduction in other campus-wide IT related operations. 3.3 Organizational Issues In universities, apart from the departmental level servers, there may be other centralized units that use IT extensively and even develop applications useful for the university community. Usually, these are found in the library services and the instructional support units. Even though some of these systems may interact with the intended ERP system, it is better to address their requirements separately. At present, the academic information (library) service uses an information retrieval system that links several of the universities in the state. The Center for Scholarship in Teaching and Learning (instructional support, CSTL) has a homemade on-line instructor suite with several features seen in products like Blackboard. This unit is trying to promote greater on-line instructional use within the university. Service units like library and instructional support are important stakeholders in the ERP project. In dealing with organizational issues, a stakeholder map may be helpful if there are too many such service units with extensive IT activity. People oriented aspects like the level of interest and degree of power within the organization factor into stakeholder maps (Fowler, 2003). In this project, the chosen ERP product is capable of interfacing (using open database connectivity available in the ERP) with the exiting systems. CSTL can choose one of the third-party on-line learning products for which the chosen ERP has an interface. The university’s electronic community portal (see Figure 2 in Appendix 2) shows how these units fit into the new system architecture. 3.4 Operational Issues The operational issues could best be planned by considering the major user groups. In a university set up, there are mainly three broad user groups: students, faculty and administrative staff. The needs of these groups should be addressed separately In the administrative group, there are users who, in spite of the not-so-friendly user interfaces, have gained proficiency in using the legacy system. Even though they see the value of the integrated system, they may be somewhat reluctant to move from their present comfort zones. In addition, some of them depend on homegrown shadow systems administrative staff. The needs of these groups should be addressed separately with which they are very comfortable. In order to get their buy-in, open forums were organized during the various product presentations to enhance their understanding of the new system in relation to what they were doing currently. However, when it came to training, each user group (including faculty) would be handled separately. During the various phases in the project, plans were in place to get inputs from these three groups independently. The plans included formation of two IT Connection groups (one for students and the other for the staff and faculty) to interact with ITS unit for channeling their web portal requirements and future changes. The other operation issue is concerned with the way in which future user requests are handled in the new system. When using legacy systems, the users made the core software change requests and ITS carried them out. In the new set up, a trained user acts on those requests directly by manipulating the rules tables without involving ITS. This approach adds to the user training effort. However, it reduces the overall workload for ITS. To make this work, besides periodic training, considerable persuasion and reassurance was foreseen to make the action-teams take on this additional responsibility. 3.5 Project phases The project has five major phases: define and plan (under planning), organize, control and close (under implementation). The activities for each of these five phases can be found in project management books for such COTS-based initiatives (Weiss 1992) with no in-house development. A timeline for the ERP project is shown in Figure 3 (Appendix 3). In this, the implementation schedules for the base system (all the five modules) are indicated. This covers the entire 30-month project. The post base-system implementation activities are discussed in the next section. 4. IMPLEMENTATION After going through the adjudication and evaluation process, the university chose SCT Banner from the short list. The system platform and network was put in place first and the application software was installed within a month. More time was spent in organizing and conducting the user training, in configuring the system to suit the organizational needs, and in populating the databases. 4.1 Project Plan The action-teams were formed and the necessary planning standards were disseminated to the teams. Using the usual work breakdown structure, each team identified the activities in its functional area and assigned suitable time estimates based on the guidelines. The information collected from the four universities on their actual plans and the experiences were helpful to the action teams. The project director reviewed all these functional plans, eliminated redundant activities, and prepared the final detailed implementation plans. 4.2 Data Conversion and Customization In a university that has been using legacy systems and third party products for several years, data conversion was a major issue. The data conversion exercise was made relatively painless since the chosen ERP had open database connectivity and the conversion responsibility was shared between ITS and the vendor. The arrangement was that ITS would give the required data in a format specified by the vendor. Based on these, the vendor provided software tools that populated the databases appropriately. Customization is perhaps the most difficult part to handle and ideally it should be kept to a minimum. In addition to the one time effort, customization may require additional expenditure due to future version changes in other interacting products or feature enhancements down the line. However, customization may be unavoidable if the university follows some unique operational philosophy in conducting its core activities. For instance, in some universities, the students may complete five courses in a semester learning one at a time (i.e., each course running for, say, three weeks), instead of working on all the five courses concurrently, a common method in most universities. In such cases, customization is critical, even though there is a price to pay. In general, modules such as student information, finance, and human resource are fairly standard across many universities since they are meant to address the operational rather than the strategic requirements. However, a savings here may increase the cost of change management. The rationale to be used is to review the business processes critically before deciding on customization issue. A plain vanilla approach (as discussed in Katz, 2002) was used in this ERP project with minimum customization. Hence, the plan included an activity for the teams to carry out their respective business process analysis that resulted in some change management issues. 4.3 Change management As an organization moves away from the mainframe to client-server architecture with an ERP to support its core processes, there will be a reduction in the number of operators and specialist programmers required to support the new system portfolio. In this project, opportunities were created, through careful planning, for those mainframe employees who had the potential for re-training in the ERP environment. Except for a few operators who opted for retirement, others stayed on. New positions were created for coordinating the nineteen user groups in the ERP set up. These user groups have greater responsibilities in co-managing their part of the system. The director for user services, who coordinated the action-teams in the project, continues to manage the IT Connection that links all the user groups. This director also coordinates the activities of trained functional support personnel who maintain their respective rules tables. 4.4 Training During implementation, representatives in the respective user areas experimented with the system and prepared training material for the end users. To enable this process, three system environments were created: testing, training and production. Users were given access to the production modules only after they had undergone appropriate training. The first training module was on system overview. Additional customized training on specific modules was provided to users depending on their needs. All the training programs were coordinated by IT services and the trainers were selected from specific functional units. 4.5 Implementation The base system (SCT Banner Release 6), consisting of all the five modules, was implemented by mid-2006. There were no budget overruns. This was possible because no customization – which normally leads to schedule issues – were planned in the preliminary implementation. However, ITS started gathering all the change requests from the various user groups and prioritizing them. At present, all the intended system modules are in use currently – accessed through both native Banner and the portal. In terms of implementation, the most difficult one was the Student Registration module and the longest one was Administration. Having mock registration was found to be useful. This revealed some of the logical errors in the data conversion process relating to course substitutions and course transfers. However, these did not hinder the continued use of the Banner system for completing the registration process. The necessary interfaces were developed for the systems in the Instructional Services to communicate with the ERP system. This interface development is an ongoing activity since new interfaces are needed whenever the ERP system is upgraded. At present a user can access al the different systems including library, instructional support using the same password. In 2007, migration to Release 7 was achieved. Migration to Release 8 is planned for Fall 2009. So far, no formal implementation review has taken place. However, presently all of the unfulfilled user requirements (changes and new features) in the various models are being addressed. All such activities were prioritized, depending on their significance and overall impact. ITS uses PL/SQL and C for generating customized reports that are not available in the Banner suite. Also under consideration are third party products not available in Banner such as Campus Parking, Facilities Management, and Textbook Rentals. 5. CONCLUSION With more and more universities intending to adopt ERP, the approaches presented above could be of use to the academic community. Employing outside consultants to carryout a feasibility study for implementing ERP is a common approach most universities follow. We strongly recommend this especially when there is no one with ERP project experience within the ITS function. However, the success rate will be higher if the university has access to a lead person who has managed at least one ERP implementation. Before starting the ERP initiative, it will be useful to have an audit of what systems are currently in use. This includes the systems managed by ITS and the shadow systems in different functional areas. It is important to identify the satellite IT centers (in particular, instruction support services) and recognize them as important stakeholders in the project. It pays to organize demos of ERP systems for the users in order to help them appreciate the potentials of ERP. Such demos help in preparing their requirements and expectations. The existing technical team should be treated an asset. The new environment should be built with their involvement. For a university, implicit in its decision to adopt ERP is the need to move towards a business process perspective (Fowler, 2003) for managing its operations. ERP brings in flatter and responsive structures along with decentralized control of information and standardization. Hence, unlike other IT projects, change management, organizational and operational issues require greater considerations in ERP initiatives. Change agents (such an action-teams in this project) are prerequisites for implementing changes in business processes. Open communication and information sharing can promote a common culture and encourage user involvement contributions. In this project, the technical team was kept motivated and the administration provided sustained support. Generally there are good procedures to support the hard aspects (finance and technical) of planning. But understanding the organizational and operational issues helps make the plans truly successful. As explained in section 3, all the significant stakeholders participated in the planning and the users were involved in all phases of the project. The implementation was fairly smooth with no back-tracking at any stage. There were no significant impediments other than minor irritations stemming from minor bugs in the system (for which SCT provided patches) and from data conversion (note the university has a few decades of data and the course catalog is a very dynamic instrument). The interfaces with instructional systems and other specialized systems could be an issue during Banner upgrades. However, having spent considerable resources on the instructional system, it is only prudent to use them for a few more years. As the demand for online courses builds up, it is possible that the current instructional system may not economically scale well. At that point, commercial instructional products that interface well with Banner might be considered. A main factor that is crucial in all such projects is the comprehensive support from the university administration for resources. The factors that contributed to the success of this project – in addition to the excellent support from the administration – include: comprehensive planning, support from the IT Committee, training and acceptance testing by functional units, reorganization of IT services to provide better services to functional units, creation of three environments (test, train, production), and closely involving functional units such as library, (nowadays called Information Commons) and instructional services 6. REFERENCES Baker, H. J., Ernst, D. J.,”California Dreaming’: How Planning, People, and Persistence Make Them Real,” presentation at EDUCAUSE 2002, Atlanta. http://www.educause.edu/librarydetailspage/666?id=edu0205 Computers, Networks & Communications (2008) “Jenzabar, Inc. Announces 2007 Sales Success with 30 Institutions of Higher Education Selecting New Total campus Management Solutions.,” Feb 18, 2008, pp 238. Computers, Networks & Communications (2008a) “CIBER, Inc Wins $3.6 Million Oracle Implementation Contract with Azusa Pacific University,” April 7, 2008, p. 531. Computers, Networks & Communications (2008b) “Rush University Selects Datatel Software Solutions to Bolster Student Service and Aid Enrollment,” April 14, 2008, p. 501. Davison, R. (2002) “Cultural Complications of ERP,” Communications of the ACM, Vol. 45, No. 7, pp. 109-111 Fowler, A. and Gilfillan, M. (2003) “A Framework for Stakeholder Integration in Higher Education Information Systems Projects,” Technology Analysis and Strategic Management, Vol. 15, No. 4, December, pp. 467-489. Holland, N. B. and Sullivan, L., “Enterprise- Wide System Implementations at Multicampus Institutions, Research Bulletin, ECAR, Vol. 2005, Issue 4, February 15, 2005, http://www.educause.edu/ir/library/pdf/ERB0504.pdf King, P. (2002) “The Promise and Perfor mance of Enterprise Systems in Higher Education,” Respondent Summary, EDUCAUSE Center for Applied Research (ECAR), http://www.educause.edu/ir/library/pdf/ecar_so/ers/ERS0204/ekf0204.pdf Katz, R. N., (2002) “Make Mine Vanilla,” EDUCAUSE review, November /December, p.68. Lightfoot, E. and Salaway, G., “A Different Kind of ERP: Extending and Renewing Legacy Systems,” Research Bulletin, ECAR, Vol. 2003, Issue 5, Mach 4 2003. http://www.educause.edu/librarydetailspage/666?id=ERB0305 Weiss, J. W. and Wysocki, R. R. (1992) 5- Phase Project Management: A Practical Planning and Implementation Guide, Addison-Wesley . Appendix 1: Figure 1. : Complexity of the Current systems Appendix 2 Figure 2. Revised University Electronic Portal Appendix 3: Figure 3: Time line for ERP Project (base system)