1. INTRODUCTION

ERP systems are generic, packaged software systems that provide comprehensive functionality and business process integration across the firm (Davenport, 2000; Klaus et al., 2000). These enterprise-wide software systems offer significant potential benefits, as suggested by the growing scholarly literature that seeks to conceptualize and measure types of organizational outcomes, business impacts, and return on investment among ERP adopter firms (e.g. Hawking and Stein, 2004; Hitt et al., 2002; Hunton et al., 2003; Spathis and Constantinides, 2004; Staehr et al., 2002). However, the scholarly and trade literatures contain numerous accounts of the difficulties that firms face in justifying their decisions to implement integrated systems, in dealing with unanticipated side effects, and in learning to use these systems well enough to produce business value (see, for example, Gattiker and Goodhue, 2002; Granlund and Malmi, 2002; Hanseth et al., 2001 ; Kumar et al., 2003; and Oliver and Romm, 2002). The organizational learning curve is steep, and little is known about individual users' learning processes throughout the enterprise system adoption cycle. Unlike general computer skills, enterprise system user and management skills are not widely diffused in the working population. Firms express a great deal of frustration about the costs and modalities of learning to use ERP systems. Formal and informal training and learning processes are consistently identified as critical success factors in mastery of ERP systems (Amoako-Gyampah, 2004; Esteves and Pastor, 2001; Umble et al., 2003).

Interest in the use of information and communication technologies in business education has largely focused on applications of technology-mediated learning rather than on learning to use core business IT tools. Although private and public organizations incur significant costs in adopting enterprise-wide systems, they have not yet made strong enough or clear enough demands on educational establishments for the latter to routinely provide some level of ERP competence and understanding among their graduates. MIS students are sometimes exposed to ERP technology, but business students in other functional areas usually are not. When they are, they typically leam operational skills related to their functional area rather than acquire crossfunctional business process management understanding. Moreover, they are not provided an understanding of the larger set of management issues involved in adopting and exploiting enterprise-wide systems. ERP technology is relatively new to the business school curriculum. Bradford, Vijayaraman, and Chandra's (2003) survey of accounting and MIS professors (with responses primarily from U.S. universities) showed that 37 percent of 94 responding business schools had brought enterprise systems into their curricula, although fewer than one-third of these teach a complete enterprise system module or cross-functional business topics involving more than one module.

The question of how and why core business technologies should be integrated into the business curriculum, and which capabilities should persons other than information systems specialists acquire in respect of business technologies, has not been thoroughly addressed. Most employers of business school graduates do not seem to have yet made a connection between the very high learning costs that firms incur when adopting advanced information technologies, including ERP systems, and the degree of IT-based business tool competence and comprehension of their new employees. But many factors militate against the adoption of complex business technologies in university business schools for teaching and learning purposes. These include the multidisciplinary scope of enterprise system concepts that requires internal cross-disciplinary coordination in curriculum design and course delivery; the concern that keyboarding and laboratory activities not supplant acquisition of management theory and principles; the cost and considerable operational complexity of delivering labbased learning with enterprise software; and retaining faculty members with ERP experience (Becerra-Fernandez et al., 2000; Corbitt and Mensching, 2000)..

This article describes the design, delivery, and learning outcomes of a capstone course in enterprise integration for senior undergraduate e-business majors in the Faculty of Business at the University of New Brunswick. The course aimed to provide education to the young business manager regarding the process of adoption and exploitation of an enterprise system. In keeping with the philosophical orientation of our e-business program, the course was intended to be "business-centric" rather than technologyoriented. It contains two components: a management theory component based on readings and discussion, and a handson laboratory component in which students individually configure a firm.

The paper is organized as follows. In the next section we discuss the dimensions of organizational learning to use an ERP system and compare these with current approaches to ERP education and training. We then describe the syllabus of our Enterprise Integration course and discuss issues in the implementation of the course. Finally, we explore learning outcomes and students' reaction to the course. In the conclusion we offer several suggestions to those who seek to provide enterprise integration education to business students.

2. THE ERP LEARNING CURVE

In spite of many improvements in usability in recent years, ERP systems are notoriously challenging to learn to use. ERP systems represent a significant extension of earlier information technology in terms of scale of organizational effects, transparency of intraorganizational transactions, and pervasiveness of the technology in the work environment, complicating adoption and mastery of the software. ERP system successes as well as failures can have large-scale organizational impacts (Hitt et al., 2002). Through cross-functional business process integration, ERP systems create transactional intraorganizational interdependencies such that every action has effects elsewhere in the organization (Kallinikos, 2004). Errors that in earlier systems were contained in localized environments propagate quickly in ERP systems along business processes and must be corrected before other workflows can take place. Misalignments of IT and organizational structure are difficult to identify and correct early enough to avoid costly rework at a later stage (Sia and Soh, 2002). The systems are complex and to many users they operate as black boxes. It is not simple for non-expert users to untangle configuration, data, and human errors, and this affects the efficiency of individual and organizational learning.

The most widely used frameworks for measuring information system adoption and use - the Technology Acceptance Model (Davis, 1989) and the Delone-McLean IS Success Model (1992) - assume that use of information systems is discretionary and that user satisfaction is a good predictor of IS success. However, in many ERP-enabled work environments, use of the system is mandatory. Employees may be more or less satisfied with the system or use the system more or less effectively, but they have to use it whether they are satisfied with it or not because they cannot accomplish their work without it. Explanations of business value creation via ERP systems must adapt prevailing models of IS system success to take into account worker, manager, and executive attitudes and competencies as users and the effects of degrees of individual and group user competence on system outcomes (Meta Group, 2003; Kraemmergaard and Rose, 2002).

The organizational aspects of ERP systems are notoriously more difficult to manage than implementation of the technology per se. ERP systems introduce massive changes into organizations (Hall, 2002). In general, low-skill jobs involving routine data manipulation are eliminated, while remaining jobs acquire greater degrees of responsibility and intensity, and require greater cognitive effort. Downsizing, delayering, downward delegation of responsibility for task completion with centralization of overall surveillance and control capability, and increased organizational clock speed are the most frequently mentioned consequences of enterprise systems for design of jobs and organization of work.

Enterprise system adoption can be described in terms of implementation or life cycle models in which the adopter progresses through "stages" of development (for example, Holland and Light, 2001) that are easily interpreted as steps of increasing firm-level capability in use of the software. Most of what is currently known about learning to use ERP systems encompasses the initial adoption process, which usually involves a loss of efficiency while the firm implements the software system and learns the new routines embedded in the software. Little is known of processes of post-implementation learning or "infusion" via extended use of ERP software in which users go beyond learned routines to develop improved ways of doing things (Sousa and Goodhue, 2003). ERP systems usually contain more than one pathway toward task completion. The discovery of these pathways is a source of sense of creativity and innovation among users, although ultimately workplace innovation with enterprise software tools appears to be constrained (Davis, 2004). Furthermore, the process of adoption and mastery of an ERP system involves a large and varying group of workers, technical staff, managers, and external service providers throughout the adoption lifecycle (Somers and Nelson, 2004). An impressive range of technical and organizational learnings must take place in the course of adoption and mastery of an ERP system. Stage and life cycle models can offer important insights into the ways that learning support services might be organized for ERP adopters.1 Some of the learning may be supported through formal training or education offerings but much of the learnings are embedded in individual or group experiences of learning-by-doing and informal or formal on-the-job learning support processes.

3. WHAT SHOULD ENTERPRISE INTEGRATION EDUCATION ENTAIL?

ERP systems pose a variety of significant learning challenges to adopter firms. What value can university-based business education involving enterprise systems contribute to acquisition of ERP capability in adopter organizations? Arguments in favour of bringing enterprise systems into the business curriculum point to the benefits of exposing business students to up-to-date business tools and a business process orientation, permitting learning about enterprise systems theory (i.e. management and benefits of enterprise-wide software systems), and the increased employability of students who have gained some familiarity with enterprise systems (Bradford et al., 2003; Gable and Rosemann, 1999; Guthrie and Guthrie, 2000; Richtermeyer and Bradford, 2003; seethamraju, 2002; Stewart and Rosemann, 2001). Faculty members benefit from enrichment of teaching and increased opportunities for professional development and research, and universities benefit from increased demand for graduates and opportunities to collaborate with the business community (ibid.). Our own challenge, described below, was to bring enterprise systems into a capstone undergraduate e-business course.

The most obvious learning need in adoption of an ERP system is for end users to acquire operational capability with the software. This is the focus of most vendor-supplied training courses: how to manipulate the software and perform transactions. Training usually consists of keyboarding exercises with progression to relatively clear-cut problem solving assignments. This is a necessary but not sufficient way to acquire competence as a user. The celebrated CIO Magazine cover story proclaiming that "ERP Training Stinks" (Wheatley, 2000) captures the feelings of many firms regarding the relative costs and benefits of ERP training. The problem is that operational training enables users to navigate in some areas of the system and execute tasks but provides no understanding of why the tasks are being performed. ERP training manuals focus on step by step instruction on task completion, not on business process logic (cf. Scott and Sugar, 2004). Employers consider that ERP training has limited value unless it enables the user to understand information flows and business processes (Wheatly, 2000). Without the ability to relate the operational task to a business process that connects various points in the firm in order to produce value, users have difficulty correcting errors or understanding how their own work affects others. Unfortunately, the literature on end-user training (reviewed by Niederman and Webster, 1998) says little about such process learning.

The distinction between ERP training and ERP education defines a division of labor between ERP software vendors and partners in the sphere of higher education. Universities or colleges may offer for-credit educational courses that use ERP as a platform, but they may not offer training courses leading to certification. This provision of the software licensing agreement protects an important revenue stream for vendors. The distinction between ERP training and education also allows universities to define their own educational product in terms of abstract, formal knowledge, as opposed to vocational training. However, the distinction between training and education as know-how versus knowwhy does not map easily onto enterprise systems curricula in universities, which display a wide range of learning methods and objectives and frequently include activities that are designed to convey operational know-how as well as management know-why. Training is often interpreted as development of technical skills (Mennel, 2002). Enterprise systems can be taught at a high level of abstraction; they can also be introduced into business curricula incrementally to provide different "levels of immersion" in the system (Guthrie and Guthrie, 2000). Finally, enterprise systems are objects of innovation in teaching methods, in matters of simulations for business process and process-oriented management learning, and in distance learning, and interuniversity collaboration (Antonucci and zur Muehlen, 2001; Noguira and Watson, 1999; Stewart et al., 2002; Shtub,2001),

As we discuss below, an important challenge to ERP education is to bridge the gap between microlevel skills acquisition processes and general comprehension of management theory and principles. This requires development of a midlevel learning framework that recontextualizes tasks and operations in terms of business processes and their management. If key individual ERP user competence is located at this level, then real-time, continuous e-learning support and learning programs delivered in the workplace (rather than classroom-based business education) may be the solution that industry chooses as it seeks to improve ERP learning efficiencies (see, e.g., Meta Group 2003). However, organizational ERP competence encompasses more than business process management capabilities. Stratman and Roth (2002) identify eight groups of competencies (strategic IT planning, executive commitment, project management, IT skills, business process skills, and ERP training, learning, and change readiness). ERP management education needs to provide managers opportunities to improve their capabilities in these areas.

The most widely accepted meaning of education is to develop understanding. Kallinikos' (1999) analysis of information systems using concepts from linguistics and semiotics provides a useful perspective on the cognitive challenges of working in organizations based on integrated software systems. Users need to develop comprehension in two areas: semantic comprehension and reference. Semantic comprehension refers to the problem of making sense of the symbols and strings of symbols of which the system is composed and with which the user interacts with the system. Software is a system of self-referential signs, symbols, and tokens, a kind of abstract language. The architecture of the system, its rules of operation, and its output statements are expressed in a multitude of symbols and signs that users must learn. The experience of ERP training can seem akin to memorizing a telephone book - a flood of details without reference to an evident organizing framework or logic. Novice users may find the graphical user interface (GUI), with its unfamiliar symbols and arrangement of records, challenging enough. Young users accustomed to videogames who imagine themselves to be quite proficient with interactive technologies are dismayed to find that business information systems have largely broken from the conventions of similarity and proximity of means for signifying. In other words, in contrast to computer media entertainment in which symbols are often graphical depictions of things and environments that they represent, the symbols used in the business system are primarily abstract, without intrinsic relationship or similarity of appearance or physical analogy to the things or environments that they stand for. In the case of SAP R/3, for example, users need to understand the organizational structure of the firm in terms of units called FI, MM, CO, PP, and SD, etc.; the structure of the master data in terms of a vocabulary of cost element groups, purchasing groups, controlling areas, etc.; the business rules in terms of a grammar of automatic postings, credits, tolerances, document numbering, and so forth; and the action of the system (transactions, processes, or workflows) in terms of sentences of specific linked sets of procedures such as converting a planned order to a production order, creating a sales order using an item proposal, or checking stock status. Users are in effect speaking an abstract language based on combinations of symbols, signs, and tokens. Enterprise system training acquaints new users with this language largely through exercises, whereas human language education would include a systematic mapping and dictionary of the symbols, tokens, signs, and conventions of the system, and an abstract treatment of rules of grammar. Without the aid of a dictionary, a structural map, and a grammar, learners of enterprise system symbols and signs concentrate on learning sequences of keystrokes.

The second area in which users need to develop comprehension is reference, meaning the thing or situation referred to by a symbol or sign. Enterprise systems are models of firms, and their components and transactions refer to real parts of firms and real business processes and transactions. However, in ERP systems, the software becomes the firm and supplants paper-based transactions. Because the software reproduces real business processes, a user with experience in a functional area of a firm can readily comprehend the business processes that have been embedded in the software. In other words, the user comprehends the references of the software. However, persons without such business experience cannot easily comprehend the references of the software, which to them represent an additional dimension of abstraction. This means that learners without relevant business experience will comprehend the referent business operations in terms of the software that mimics them.2

Decontextualization of decision frameworks and process automation of organizations represent not just cognitive challenges to workers, but also a major change in the ways that organizations behave that affects their management, routines, and learning processes (D'Adderio, 2003; Kallinikos, 2004; Strong et al., 2003; Tang et al., 2000). An understanding of the management issues raised by information-intensive work in decontextualized, processintegrated work environments is an important objective of future research.

4. A CAPSTONE UNDERGRADUATE ENTERPRISE INTEGRATION COURSE

Enterprise Integration was taught in 2004 as the capstone course in the "business-centric" e-business stream in UNBSJ's Faculty of Business. The business-centric curriculum for the e-business program was designed on the advice of industry partners who identified a need for graduates with hybrid competencies: individuals with business and people skills and with the ability to work in technical environments with technical people (Davis and Hajnal, 1998). In this program e-business majors take six required courses (Introduction to Electronic Commerce, Technology Fundamentals of Electronic Commerce, Industry Impact of Electronic Commerce, Marketing on the Internet, Policy and security Issues, and the capstone course: Organizations and Electronic Commerce). They also take two electives from a selection of several e-commerce courses: Frontiers of Electronic Commerce, Consumer Behaviour, Management of New Enterprise, Management of Online Business, Accounting Information Systems, and Management of Technology.

In previous years, the capstone course had focused on integrative case analysis, special topics in consumer behaviour, and workflow. Although UNBSJ had been a member of the SAP University Alliance since 1998 and several faculty members had received training, the usual factors dissuaded colleagues from using enterprise system software in the business curriculum. This situation changed in 2003 when the Dolphin Group's stand-alone enterprise integration course (Dolphin Group, 2002), associated training workshops, and remote hosting of the database and clients all became available to members of the SAP University Alliance.

We had previously taught undergraduate and MBA ebusiness courses with an enterprise integration focus. Our starting point in the design and delivery of the new capstone Enterprise Integration course was the observation, based on an extensive literature review and on field research with ERP-using organizations, that enterprise-wide systems are unusually complex business tools that cannot yield business without significant investment in time and energy on the part of adopter organizations. Our objective in this course was to prepare e-business graduates for ERP-enabled work environments as employees or managers by providing a conceptual framework and enough familiarity with an enterprise system to gain a sense of self-efficacy regarding use of the technology or management of users in a business environment, thereby improving learning efficiencies on the part of the adopter organization. Our Enterprise Integration course is designed to be a management-oriented course that follows the selection, implementation, and post-implementation cycle of enterprise system adoption. As a capstone course, Enterprise Integration completes our program's learning sequence by requiring the student to use previous learnings to address and solve business problems. The course has a management theory component and a lab component. In the theory component, the student learns how to manage the selection and deployment of ERP systems, with a focus on understanding the organizational processes and individual competencies required to take advantage of enterprise-wide software. The lab component seeks to expose students to the complexities of an ERP system by requiring them to configure their own company in an SAP R/3 environment. Overall, our Enterprise Integration course aims to provide a sound conceptual foundation regarding the adoption and effective use of ERP systems in firms; to provide examples so that the student may apply the concepts in real business situations; and to provide hands-on experience in configuring a firm with SAP R/3 software so that the student may understand and appreciate the modalities of achieving cross-functional software-based business process integration.

The course was team-taught in two sections to about twenty-five students. One of us took the lead on the management learning component and the other on the lab component. The course was delivered in three contact hours per week over a period of thirteen weeks. Ninety minutes were devoted to management theory and practice, and ninety minutes to hands-on laboratory learning on SAP R/3. We evaluated students' performance in three areas: completion of a take-home business case, completion of configuration exercises on SAP R/3, and completion of a learning log containing literature summaries and reflections on individual learning. The configuration exercises were completed twice: once in a learning environment and once in a testing environment. Students' performance in the lab was evaluated in terms of completion of assignments, not for functionality of the configuration. The learning logs were submitted weekly, and required the students to summarize their understanding of the issues presented in the week's readings, assess the relative importance of the information, present the learning challenges from the week's lab exercises, and submit questions.

The management learning component was designed to provide a conceptual framework about business process innovation and its supporting technologies, then address the sequence of management issues through the ERP adoption cycle. For this component we examined a number of textbooks but found none that provided the perspective and material we sought. Therefore, we assembled reading packages from scholarly and trade literature. Each week, students were required to complete a learning log in which readings were summarized and in which the student provided reflections on learnings in the lab and in the classroom. This component included a weekly lecture lasting about forty-five minutes, followed by a discussion in class. Table 1 shows the topics covered under the management component of our Enterprise Integration course. Students learned about the rationale for enterprise integration, the drivers and mechanisms of process innovation, how to build a business case for investment in enterprise systems, the software selection and vendor management process, project planning and organization, the implementation process and associated change management issues, the management of enterprise systems in the post-implementation phase, and decision making with enterprise systems.

The final evaluative component of the course was a business case in which students had to apply their knowledge to respond to a Request for Proposal from a company seeking to invest in an ERP system. Students were required to respond to a range of questions about likely costs of adoption of an enterprise system, benefits, other impacts on the adopter, and management and organization of the initiative. Three undergraduate Teaching Assistants were made available by the University. For these positions we recruited upper-level Electronic Commerce students with IT back-rounds and prepared them to serve as surrogate super-users in the labs. The TAs worked two or three weeks ahead in the lab exercises, and assisted the students as they moved through the exercises. The TAs proved to be a valuable contribution to the course management team. They were able to troubleshoot and solve many of the multitude of smaller problems that occurred, freeing the instructors to concentrate on course delivery and management of major issues.

5. DELIVERING THE LAB COMPONENT OF THE ENTERPRISE INTEGRATION COURSE

The lab component for the course offering was adapted from the Implementation of an Integrated Business Solution course developed by the Dolphin Group, an SAP Consulting and Education firm based in South Dakota (Dolphin Group, 2002), course developed by the Dolphin Group, an SAP Consulting and Education firm based in South Dakota (Dolphin Group, 2002). The Dolphin Group course is designed to introduce students to integrated business processes through the configuration of a small manufacturing firm. The course exposes students to business processes through a series of mini-lectures that are then reinforced with exercises in the SAP environment. The expected outcome of the lab course is that students learn the basics of business process integration by individually configuring a sporting goods company in SAP R/3.

The Dolphin Group offers this course to SAP University Alliance members, and encourages faculty members who have undergone the suggested training to incorporate it into their curriculum. Training involves a ten-day workshop exposing faculty participants to the course by having them work through the entire program as students, and a separate five-day workshop in which the configuration of the clients and servers required to run the course are reviewed. The format of the training helps to reinforce some of the anticipated student user issues as faculty members struggle with the interface, logic and nomenclature of the system.

The Dolphin course encompasses the Financial, Controlling, Materials Management, Production Planning and Sales and Distribution modules of SAP R/3. Time constraints, unanticipated down time of the hosted application, and a restructuring of the lab curriculum limited the Enterprise Integration course offering to the first four modules. Students in the course completed the configuration of the first four modules twice, once in a learning environment and once in order to be tested. This approach was not originally planned, but was incorporated into the course delivery as it became clear that students were slow to grasp relationships among the business processes they were setting up.

Throughout the semester, it became increasingly apparent that some of the most trying issues related to teaching the principles of ERP using the Dolphin SAP Implementation course arose at the operational level, involving the system as well as individual users. The operational issues can be broken down into four broad categories: set-up and teaching issues, hosting issues, software issues, and client level issues. Set-up and teaching issues concern the initial configuration of the student learning environments, as well as the teaching responsibilities that fell outside of the scope of routine undergraduate business education program delivery. Software issues encompass the challenges of teaching the SAP R/3 system. Hosting issues refer to the realities of running a lab-based course in an application server provider (ASP) environment. The client level issues are specific to the Dolphin course design in which students work on particular companies but are required to have access to corporate level settings. The first two sets of issues probably exist in most software laboratory teaching environments, while the latter two are specific to the lab component of the course.

The set-up requirements of the lab component were much more onerous than expected. The instructor must develop the student environment on the corresponding server. The initial set-up requires the configuration of two separate environments, one for demonstration purposes and the other for student work. In total, this amounts to fifty to eighty hours of work, depending on the instructor's knowledge of the system. The outcome of this set-up task is the creation of two master clients that can be copied each time the course is subsequently taught. Thus, the set-up time for future course offerings is lessened, but only as long as the same server and SAP R/3 versions are used. If either of these parameters changes then the entire process must be repeated in the new environment.

We severely underestimated the time required to troubleshoot the system throughout the course. Errors during setup would prevent students from successful completion of their exercises and would create problems during course delivery. Following configuration of the clients by an instructor, extensive testing must be carried and actual transactions performed. In our Enterprise Integration course the burden of testing was borne by the two instructors and the three TAs, who worked two to three weeks ahead of the rest of the class in the course exercises in order to identify configuration problems before the exercises were performed in the classroom. This rigorous pre-testing of the configuration immediately before use of the system in the lab environment was also necessary in order to identify and correct discrepancies between the laboratory exercises and the SAP interface and command structure. The exercises were designed for SAP R/3 4.6C and had to be adapted for the 4.6B environment used by the software hosting institution. This required tedious checking of nomenclature, operational sequence and exercise descriptions. Failure to identify such differences created confusion amongst the students, and resulted in an inordinate of amount of time expended to clarify the issue.

To encourage group learning among students we introduced a Frequently Asked Question (FAQ) discussion board on the course management website with subheadings for each group of exercises. Instructors and Teaching Assistants shared responsibility to monitor this board and reply to questions between 8 am and midnight seven days a week. A number of students also offered solutions to problems posted on the discussion board. With instructors' knowledge of the Dolphin course limited to around two hundred hours of experience, many questions from students about the system or other modules could not be answered. The only way to deal with this potentially stressful situation is to emphasize to the students that even SAP Jedi only know a small fraction of the system. This sets the stage for a collaborative learning environment.

Finally, although we were able to solve many problems that occurred, we frequently required recourse to the technical expertise of the original course designers from the Dolphin Group. Without this support we would have experienced significant difficulties.

Perhaps the most perplexing teaching challenge in the lab component involved the testing of the student knowledge of the system. In the final lab session, students were asked to complete various transaction-based exercises in their test environments, with the understanding that if properly configured, their companies would successfully generate the corresponding transaction numbers. This apparently reasonable means of testing students has drawbacks: how can instructors differentiate between student errors and a system error caused by faulty or corrupt data? The other concern with this assessment method is to determine whether it tested students' understanding of business processes or merely their ability to follow instructions in the configuration exercises. It appears that students with the most fully operational company configurations had a better grasp of the SAP R/3 system's functionality, but it is not clear how well students learned about the underlying business processes.

The second set of operational issues relates to the use of a hosted software solution. Use of an ASP provides many benefits because the host institution has far more technical expertise, infrastructure, and support services than we do. Our experience with applications hosting was much more positive than that reported by seethamraju (2002). However, the ASP arrangement poses some challenges. In the case of our Enterprise Integration course, the SAP R/3 system was hosted at a university approximately 500 kilometers away in a neighboring province. The relationship with the ASP was well established prior to the course, and remained cordial throughout. Nevertheless it became clear as the course progressed that a formal service level agreement (SLA) would have helped to identify accountability levels should problems occur. With an SLA in place, the customer can plan around expected server down time; understand the protocol for handling unexpected server delays; ensure that redundancy in data and system is in place; formalize access to the server; and count on established lines of communication.

Each of these issues arose at some point throughout the course. The semester schedules of the host institution differed from ours, and while the ASP school was on spring break, we required support that was not easily attained. Should the ASP reside in a different time zone this issue could be even more serious. Our difficulties were compounded by an act of nature in the form of a severe winter storm that caused a power surge on the host's server and corrupted some data. However it was not possible to restore a copy of our database because the server was shared with another university that did not experience the same problems. There was debate as to whether the problems resided locally or with the ASP. The ordeal caused many problems for the students and for the instructional team. The ultimate outcome was that some students were unable to complete their exercises in the learning client environment, and had to move directly into the testing client environment.

The last two sets of issues are related to the SAP R/3 system and to the design of the integration course itself. The software's user interface has improved substantially in the past several years, but it retains non-intuitive features and design inconsistencies. Even after sixty or seventy hours of experience on the system some students struggled with the interface. The exercises for the course were posted weekly to the course website, but questions regarding placement of data fields or transaction processes regularly arose. It would be possible to provide more detailed learning support in the form of full screen shots or simulations of each exercise, but this would be very time consuming to organize and it would remove the requirement that students learn the language of the system. Because of the disparate comfort levels of the students using the system, it was difficult to provide enough one-onone technical assistance during and between lab sessions. To alleviate some of this resource strain, the TAs ran supplemental lab sessions outside of normal class time.

The final set of operational issues relates specifically to the laboratory course design and access levels required for students in order to complete their exercises. The Dolphin course is designed in such a way that each student is assigned a code for one company to configure within the same client. This poses instructional problems because due to the types of configuration exercises undertaken, students need access to both their company and the overall client. This means that students, either knowingly or inadvertently, could destroy the work of others or the entire class. It also means that students can see the many elements of the configurations of other students and simply imitate them. It is often difficult to track the root cause of a change in a client-level setting. Further, some client level operations are so resource intensive that students must complete them one at a time, which is hardly efficient in a group laboratory setting.

6. LEARNING PROCESSES AND OUTCOMES

The literature on classroom-based ERP learning outcomes is still very small. Scott (1999) describes five theoretical learning models and discusses differences between industry ERP training methods and university-based ERP instruction. Nelson and Millet (2001) report students' selfdescribed levels of knowledge before and after a foundation course on ERP and business processes. Wagner, Majdawi, and Otto (2000) provide a summary of results of a study seeking to measure increases in students' understanding of cross-functional business processes following exposure to HR and other functional modules of an ERP system. seethamraju (2002) reports students' assessments of a graduate program in enterprise resource planning, showing some significant differences between domestic and international students. The most rigorous research to date on classroom-based ERP learning outcomes is provided Noguera and Watson (2004), who test the effects of learning styles and three instructional delivery methods (lectures with readings, lectures with hands-on transaction exercises, and lectures with simulated transactions) on students' performance, self-efficacy, and satisfaction. Noguera and Watson find no learning style effects and show that simulated system use with screen shots is as effective as hands-on experience on an ERP system in teaching business process concepts - a result that will certainly stimulate other assessments of the relative merits of lab-based ER education.

At the close of our Enterprise Integration course we administered an evaluation' questionnaire with twenty-one questions. This questionnaire measured students' previous ERP knowledge and experience, perceived utility of various features of the course, suggestions for improvement, and several perceived learning outcomes. We performed a hierarchical cluster analysis on these response data using Ward's method, which minimizes intracluster variances. A four-cluster solution was selected on the basis of an inspection of coefficients in the agglomeration schedule, supplemented by visual inspection of the dendogram. Table 2 shows the questionnaire items and the mean responses for each cluster. ANOVA tests were performed to identify significant differences in the group means, and post hoc tests identified significant differences between pairs of group means. Because some of the data did not display homogenous variance, we used Tamhane's T2 statistic in the post hoc tests. F scores and significance levels are shown in Table 2. The principal differences between the groups of students concern the degree of prior hands-on experience with ERP software (Q2); perceived utility of course reading material (Q5),management theory sessions (Q6). Learning logs (Q7), the contents of the course for employment purposes (Q8), perceived importance of group time in lab (Q10), perceived understanding of how ERP generates business value (Q18), and perceived ability to manage workers in an ERP-enabled work environment (Q21).

Students in Cluster 1 were quite positive about the learning experience. They had significantly less prior hands-on experience with ERP systems than students in clusters 3 or 4. They rated the lab elements and the management learning elements of the course equally highly, they found relatively high value in the course readings, and they expressed optimism that the course enhanced their employment prospects. These students seem most successful in relating the laboratory experience with the management component of the course.

Students in Cluster 2 found the laboratory exercises to be easy, but gave low scores to the management learning component. Their focus was primarily on the laboratory experience and they would have liked to have group learning experiences in the lab. Their rating of the utility of management readings was significantly lower than that of the other three groups. Although students in Cluster 2 expressed confidence in their ability to manage enterprise systems, they seem to have regarded themselves as potential users of ERP systems, not as potential managers.

Students in Cluster 3 had prior work experience in ERP environments. Therefore the laboratory experience was of relatively low interest to them. However, the management component was of great interest to these students. They were active and well prepared in the group discussions, and they showed the strongest performance in the business case analysis (data not shown).

Students in Cluster 4 responded positively to the laboratory and management learning components of the course, but expressed a lower sense of self-efficacy than the other students. They were not sure that they had gained skills and understanding that would be rewarded in the job market, and they seemed to feel that the course presented too much material to learn and that its pace was too fast. They expressed the need to spend more time in the lab.

Overall, students in clusters 1 and 3 seem to have benefited most from the dual management learning and laboratory components of the course, and they seem to have approached the course as a business management learning experience rather than as a software training experience. Students in clusters 1 and 3 accounted for around forty percent of the students in the course. Students in cluster 2 focused largely on completion of the laboratory exercises (but did not express significantly lower perceptions of self-efficacy on the outcome variables). Students in cluster 4 found both the laboratory and management components to be difficult and they expressed signicantly lower sense of efficacy than other groups in understanding ERP systems, in understanding how to product business value from these systems, and in ability to effectively manage workers in ERP environments.

7. CONCLUSIONS

The novelty of our course was its combination of a comprehensive management learning stream with a major hands-on lab component. The combination of hands-on lab learning on a live enterprise system and management learning via reading, discussions, and cases is potentially a very powerful combination in an enterprise integration course, but it is a challenge to balance the two components and to relate the lab learnings with the management learnings. This difficulty is magnified when students have diverse educational, employment, and cultural backgrounds.

The lab component was deemed by students to be useful although the actual learning outcomes sometimes varied from those originally anticipated. From a management learning perspective, students came to appreciate the complexities of mastering the enterprise system well enough to use it in a production environment. They also gained some insights related to managing software within an ASP relationship, and some of the system issues that can impact corporate performance. However, from the perspective of comprehension of business processes their knowledge gain appeared to be below expected levels. While students claimed in their learning logs that repeating the exercises helped them to understand the connection between the operations they performed and business processes they activated, many students still seemed to focus on completion of the exercises without understanding how these individual steps contributed to a bigger picture. Nevertheless the course was identified as a positive learning experience by most students.

It is operationally complex to introduce an enterprise system into a business course. To bring current business IT tools such as enterprise systems into the business curriculum, the tools either must be significantly modified for teaching purposes or space must be made in the curriculum for lab-based courses on live systems. In the latter case, universities will need to treat lab-based business courses the way they treat lab-based science and engineering courses in terms of instructors' course loads and perhaps also in terms of credits granted to students. The ease of adoption of enterprise systems in the management curriculum could be substantially increased if universities were able to purchase packages of teaching materials and services in the form of textbooks, enterprise software modified for teaching purposes, pre-populated and pre-configured clients, simulations of workflows and business processes, dictionaries of software nomenclature, teaching cases that illustrate management issues (including ones encountered in laboratory exercises), debugged lab assignments, and web-based technical assistance.

8. ACKNOWLEDGEMENTS

We are grateful to the University of New Brunswick - Saint John for its support and encouragement in the delivery of the course described in this article. The course is one outcome of research on "Enterprise Integration: Jobs and Work in the New Millenium," funded by SAP Americas, of which Davis is co-investigator. This support is gratefully acknowledged. Thanks also to the three anonymous reviewers for their useful comments on an earlier draft of this paper.