Artur Caetano
email: artur.caetano@ist.utl.pt

Aurélio Assis
email: aurelio.assis@ist.utl.pt

José Borbinha
email: jose.borbinha@ist.utl.pt

José Tribolet
email: jose.tribolet@ist.utl.pt

An Application of the ψ-theory to the Analysis of Business Process Models *

Keywords: business process modelling, business transaction, ψ-theory, DEMO, BPMN

This paper presents a method to analyse the consistency and completeness of process models according to the principles of the ψ-theory and the underlying concept of business transaction. Transactions specify the collaborative behaviour between actors while services are being requested and provided. The method assesses the consistency of a process in terms of the business transactions that can be inferred from it. To do so, it takes as input a process model that is converted to a transactional model. The transactional model is then analysed and revised so that all transactions become consistent and complete according to the transactional pattern. This enables to identify the problems on the original process model and to prompt areas of improvement.

Introduction

Business process modelling techniques can be used to analyse and communicate inter-and intraorganizational business processes as well as to develop business support information systems [START_REF] Nuffel | Enhancing the Formal Foundations of BPMN by Enterprise Ontology[END_REF][START_REF] Dijkmana | Semantics and analysis of business process models in BPMN[END_REF][START_REF] Zimmermann | Analysis and Design Techniques for Service-Oriented Development and Integration[END_REF][START_REF] Sousa | Enterprise architecture modeling with the UML 2.0[END_REF][START_REF] Caetano | A Role-Based Enterprise Architecture Framework[END_REF]. The project reported in this paper is motivated by the need to analyse the consistency of business process models. This capability is lacking in process modelling techniques since their focus is on the constructs required to define the models and not on methods to assess the actual quality of the models. Moreover, the lack of semantics behind process modelling languages and the unclear specification of their constructs contributes to the design of ambiguous models [START_REF] Barjis | Automatic business process analysis and simulation based on DEMO[END_REF][START_REF] Recker | How Good is BPMN Really? Insights from Theory and Practice[END_REF]. An example of such ambiguity is the usage of natural language as the means to specify a process. These problems become evident when models or views need to be integrated or when the services to support a business process need to be consistently identified. On the other hand, methods to design business processes mainly focus on aligning business with technological concepts and do not prescribe the principles to design consistent business process [START_REF] Barjis | Automatic business process analysis and simulation based on DEMO[END_REF]. The combination of these factors creates the need to define techniques to design new business processes or to provide the means to analyse existing process models with the goal of continuously improving their consistency while responding to the stakeholder's needs.

To address this problem, this paper uses the principles set forth by the ψ-theory to analyse the consistency of business processes. We consider a process model to be consistent if its activities comply with the business transaction pattern. This pattern, which is part of the ψ-theory, defines communication steps that a requester and a producer perform while responding to a request. If a process complies with the transaction pattern then its specification describes who is responsible for the execution of its activities and why each activity is being performed. However, a business process can be consistent but still be missing activities required to fully produce the intended transactional results. This means that a complete process must not only be consistent but also specify all transactional activities. Thus, a process model that is both consistent and complete is a process that fully specifies an end-to-end collaboration pattern between a service requester and a service provider.

The next section of the paper introduces the ψ-theory along with the concept of business transaction. Section 3 describes the method to analyse business processes along with a running example. Finally, section 4 concludes the paper.

The ψ -theory

The ψ-theory (ψ is pronounced as PSI, standing for Performance in Social Interaction) is a theory about the ontological essence of organizations. It clarifies and explains the construction and operation of organizations. The operating principle of enterprises is that the employees, together with representatives of the customers and the suppliers, enter into and comply with commitments regarding the products that they cooperatively produce. This very basic understanding makes enterprises primarily social systems, of which the elements are human beings in their role of social individuals, bestowed with appropriate authority and bearing the corresponding responsibility. The ψ-theory is rooted in speech act theory [START_REF] Searle | Speech Acts: An Essay in the Philosophy of Language[END_REF], in social action theory [START_REF] Dignum | Communication Modelling: The Language/Action Perspective[END_REF][START_REF] Habermas | The theory of communicative action -reason and the rationalization of society[END_REF], and in information systems theory [START_REF] Langefors | Information System Theory[END_REF]. It is extensively discussed in [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF]. The ψ-theory provides an effective notion of Enterprise Ontology, defined as the fully implementation independent understanding of the essence of an enterprise's organization. The Design & Engineering Methodology for Organizations [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF] is a methodology for the engineering and implementation of organizations that is formally grounded on the ψ-theory . Some authors state that DEMO defines a robust enterprise engineering approach as it provides a formal yet simple conceptualization of an organization that can be used a point of departure for its implementation [START_REF] Nuffel | Enhancing the Formal Foundations of BPMN by Enterprise Ontology[END_REF][START_REF] Ettema | ArchiMate and DEMO -Mates to Date?[END_REF]. DEMO can also deliver models which can be formally assessed and executed on DEMO automata [START_REF] Nuffel | Translating Ontological Business Transactions into Evolvable Information Systems[END_REF]. DEMO can be used to assess existing BPMN models with the purpose of verifying their consistency [START_REF] Nuffel | Enhancing the Formal Foundations of BPMN by Enterprise Ontology[END_REF]. The main contribution is thus combining the representational capability of the BPMN standard with the formal correctness of the DEMO principles. However, DEMO ends where BPMN and other transformational business process modelling languages start. Thus, this paper proposes using DEMO to help constructing consistent and complete BPMN process models [START_REF] Omg | Business Process Model and Notation (BPMN)[END_REF]. The ψ-theory consists of four axioms [START_REF] Nuffel | Enhancing the Formal Foundations of BPMN by Enterprise Ontology[END_REF][START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF]. We briefly describe two of these axioms due to their significance to the method put forward in this paper.

The Operation Axiom

The operation axiom states that the operation of an enterprise results from the performance of actor roles. An actor role is an element of authority and responsibility which is fulfilled by a subject. A subject performs two kinds of acts: production acts (P-acts) and coordination acts (C-acts). By performing P-acts, subjects contribute to bringing about the function of the organization. By per-forming C-acts, the subjects enter into and comply with commitments regarding P-acts. So C-acts are the way in which cooperation between subjects is accomplished and made explicit. An actor role is defined as the authority to perform one particular kind of P-act. A subject in its fulfilling of an actor role is called an actor.

P-acts and C-acts produce results. The result of a production is a production fact (P-fact) and the result of coordination act is a coordination fact (C-fact). For instance, the action of packing an order (a material P-act) results in a package with the order items (the corresponding P-fact).

The Transaction Axiom

The transaction axiom states that C-acts and P-acts occur in a particular pattern and consists of an order followed by a result conversation. A conversation is a sequence of coordination acts between two actor roles required to achieve a result. A transaction evolves in three phases: the order phase (O-phase) where the request is made, the execution phase (E-phase) that produces the result, and the final result phase (R-phase) where the initiator is notified of the result. The actor role that starts the order conversation is the initiator or requestor. The role that executes the request, produces the fact and responds to the initiator is the executor or provider. The basic transaction pattern consists of the following steps: 1. Order phase 1.1. The initiator makes a request (rq) to the executor to produce a specific P-fact. This Pfact will be the result of the transaction. 1.2. The executor then promises (pm) the initiator that he agrees with the request and that he is committed to produce the result. Thus, the order phase defines the initial contract or commitment between the initiation and executor. 2. Execution phase: the executor produces the P-fact as promised. 3. Result phase 3.1. The executor states (st) to the initiator that the result is complete. 3.2. The initiator accepts (ac) the result, thus successfully ending the transaction. The basic transaction pattern assumes that all conversations have a successful outcome. DEMO also defines a standard transaction pattern that extends the basic pattern with four additional cancellation patterns. The standard transaction pattern is considered complete as it covers all possible communicative and rollback actions [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF].

The Analysis Method

This section describes an iterative method to analyse the consistency and completeness of business process models. A business process model is consistent if the order of its actions complies with the transactional axiom. A business process model is complete if all transactional pattern steps can be mapped to its activities. Therefore, a process that is consistent and complete specifies all the actions that are required to produce a specific result and does so according to the transactional axiom. Note that consistency applies to any level of detail of the process. Therefore, if a business process is functionally decomposed then each level must also comply with the transactional axiom.

Throughout this paper we will consider the input model to be a BPMN process diagram, although other transformational modelling techniques could be used [START_REF] Carlsen | Comprehensible Business Process Models for Process Improvement and Process Support[END_REF]. Thus, a process is specified as a flow of named activities that are performed by actors. The method comprises five steps. The first steps identify the production and coordination acts embedded in the input process model. The next steps assess the completeness and consistency of the process model according to the ψtheory axioms. The input process model can then be reviewed according to the assessment. This enables the process model to be incrementally analysed and reviewed. The remainder of this section describes these steps along with an example of application.

Analyse the input process model (step 1)

The method starts with a BPMN process model and produces a DEMO process structure diagram that abstracts the coordination and production acts depicted on the input model. The goal of the first step is to analyse the design artefacts used to represent the business process model. It analyses the activities and classifies them according to the operation axiom and distinction axiom. As a result each activity is classified as a production or coordination act (operation axiom) and also as a performa, informa, or forma speech act (distinction axiom). Furthermore, the operation axiom also discriminates the actor roles involved in the process. The result of this step is a traceable list that maps the coordination and production acts and actors to the original process model from where they were sourced.

Consider the following examples: an activity that sends an electronic message is classified as a coordination act since it involves communication between actors and as a forma act because it represents a source uttering a message to a recipient. An activity that archives that message is classified as forma but it is a production act because it is generating a new production fact (the archived message). An activity that counts the number of messages archived on a given date is a production act as it generates a new production fact (the message count) but it is classified as an informa speech act since it is computing a result.

Next, each performa coordination act is classified as a request, promise, state, accept coordination act according to the transaction pattern. Using the standard transaction pattern implies further identifying the decline, reject, stop, quit acts. . For instance, an activity Place Order is as a request coordination act as it is performed by the initiator to start a new transaction. The activity Receive Ordered Product is an accept coordination act as it indicates the initiator acknowledged and accepted the result of the transaction. Figure 1 depicts a business process represented in BPMN describing the selling of a product to a buyer. The buyer places an order to a seller who checks its validity. Then the seller sends an invoice to the buyer. After receiving the payment the seller sends the buyer the product. This process is intentionally being specified at a high level of functional detail and it excludes error conditions and compensation actions due to space limitations.

The application of step 1 classifies the activity Check Order as infological (informa) according to the distinction axiom. The remaining activities are ontological (performa) acts. The coordination acts are further classified according to the transaction axiom (e.g. Place Order is classified as T01/request and Receive Invoice as T02/promise). The result is shown in Figure 1.

Generate the DEMO models (step 2)

This step takes the classifications produced in step 1 and generates the corresponding DEMO process structure diagram. The classification of the coordination acts along with the control and data flow restrictions that are specified on the input process model are used to generate the DEMO process model. Step 2 of the bottom-up phase derives a DEMO process from the labelled business process model. The initial resulting model is shown in the left-hand side of Figure 2. It can be observed that this model is incomplete as several acts are missing.

Revise the DEMO models (step 3)

This step adds acts found to be missing during the previous step to the process model. These acts are the ontological acts that are not described explicitly in the input business process. The model is revised according to the transaction axiom so that each transaction goes through all the steps defined in the O-, E-, and R-phases. Next, the application of the composition axiom ensures that all of the transaction steps follow a logical sequence according to the pattern. The results of step 3 are process structure diagram (process model) and an actor-transaction diagram (construction model).

The result is the process model shown in in the right-hand side of Figure 2. This step has added the acts T01/pm, T01, T02 according to the transaction pattern. This revised model is now complete and consistent with the Ψ-theory axioms. The actor-transaction diagram (ATD) depicted in Figure 3 shows the actors responsible for initiating and executing a transaction. The buyer is responsible for initiating the transaction T01 (Order) which is executed by the seller (the executor role is depicted by a black diamond on the association end). Conversely, the seller initiates transaction T02 (Payment) which is executed by the buyer.

Revise the input process model (step 4)

This step performs a gap analysis that identifies the ontological acts in the revised DEMO model that are missing from the input business process model. Based on the results, the original BPMN process model is revised so that its activities match the missing ontological acts. The revised process becomes ψ-theory compliant, meaning it is now consistent with the transaction pattern and complete as it contains all transaction steps. This step identifies the missing activities on the original process model that derive from the missing acts. The revised process is depicted in Figure 4. The changes imply adding three activities, one for each missing ontological act: T01/promise, T01/execute and T02/execute. The name of these activities is actually irrelevant at this stage. The revised process is now consistent and complete with the ψ-theory axioms since all essential speech acts are explicit.

The missing promise act (T01/promise) means the seller is implicitly accepting the buyer's request. Such decision may either be a design decision or the result of an incomplete specification. In either case, such an implicit promise makes this model ambiguous because it is not clear when the order is actually being accepted by the seller. It may be the case that the seller commits to selling the product to the buyer immediately after checking the order. But it may also be the case that the seller is only committed to the transaction if he sends the invoice. This makes the responsibil-ity of the actors involved in the transaction to be ambiguous. For instance, if the buyer places an order and the seller does not send the invoice in a timely manner (e.g. as defined on a service-level agreement), the model does not make explicit if the seller was already committed to send the invoice or not. The revised process makes such decision clear.

However, it is important to note that the revised process may not be ideal because there are usually several variations that are consistent and complete. Thus, the revised process primarily serves as a means to emphasize problem areas and to point the architects towards possible solutions. A definite solution can only be found after an iterative analysis and revision of the process model according to the overall architecture of the organization in such a way that it suits the needs of its stakeholders and the overall architectural alignment principles.

Results of application

This method was applied to the analysis of two core business processes at a large organization (+2000 employees) that handles legal and judicial procedures. This was done using a software tool that fully automates parts of the method and supports the remaining semi-automated parts. The two processes total approximately 500 activities and cross 10 inter-organizational boundaries and involve more than 60 actor roles. The activities of these processes were already modelled and were detailed up to 4 or 5 levels of depth. The method was applied to these processes and the results were discussed and validated with the stakeholders. The application of the method took 20 person-days and was performed by a team process modelling experts who analysed the processes and met regularly with groups of stakeholders from the organization. Note that the example presented on the previous section is similar to this case study except in terms of complexity and extent. The following results were observed. The original processes lacked 25% of production acts, meaning that the original processes included activities that were not explicitly producing any tangible results. The following observations apply to the missing coordination acts:  Missing 25% of request acts. Results are being produced without an explicit request being made and thus it is not possible to identify an accountable service initiator. This is particularly important in processes that are executed by multiple actors, especially inter-organizational actors.  Missing 50% of promise acts. Requests are implicitly confirmed, often without any governing contract. The service performer starts producing a result without agreeing with the initiator and thus it is not formally accountable for the production.  Missing 25% of state coordination acts. Production results are not explicitly communicated.

The implication is that is not clear whether the responsibility of checking the completion of a result lies on the initiator or on the executor.  Missing 40% of accept acts. Production results are not being accepted by the initiator. There is no formal acceptance and therefore the initiator does not confirm that the results comply with the request. Moreover, the executor cannot assess the quality of its results since there is no formal acceptance of the product.

Conclusions

This paper presents a method to analyse the consistency of a process model based on the ψ-theory.

A business transaction specifies a pattern that describes how actors collaborate. The method takes as input a process model that is converted to a transactional model. The transactional model is then revised so that all transactions comply with the ψ -theory axioms. Finally, the original process model is revised to become consistent and complete in the sense it expresses all transactional steps. The method was illustrated through the analysis and revision of a simple business process.

We have also used this method to analyse a set of detailed business processes comprising several hundred activities at a large public institution. The method identified a set of implicit and missing acts from the original processes and prompted their revision so that the areas of responsibility and the contracts between the organizational actors became clear. Nevertheless, the successful application of this method implies a sound understanding of the original process as well as working closely with its stakeholders so that it can be iteratively revised. This also means each step could end up be repeated several times until we get to the point where the input model satisfies the stakeholder's needs and is consistent and complete at the same time. Despite such shortcomings, such analysis will raise questions about the contents of the process models. The main question that tends to surface is about the actual meaning of the activities specified in the process model. Answering these questions contributes to reducing the ambiguity of the original specification and to clarifying implicit responsibilities. This means that a process model should clarify the areas of responsibility and the chain of accountability. We believe the method proposed in this paper is a contribution to this complex undertaking.

Figure 1 .

 1 Figure 1. Input business process model after application of steps 1.

Figure 2 .

 2 Figure 2. Incomplete process structure diagram after step 2 (left) and revised model after step 3 (right).

Figure 3 .

 3 Figure 3. Construction model.

Figure 4 .

 4 Figure 4. Identification of missing steps according to the transaction pattern (step 4).

* This work is partially supported by the EU-FP7 grant 269940, project TIMBUS, "Digital Preservation for Timeless Business Processes and Services".


Jyoti M Bhat
email: jyoti.bhat@iimb.ernet.in

Bhavya Shroff
email: bhavya.ps@iimb.ernet.in

Rajendra K Bandi
email: rbandi@iimb.ernet.in

User perceptions, motivations and implications on ERP usage: An Indian Higher Education Context

Keywords: Case study, Motivations, User perceptions, ERP implementation, Higher education

Globally ERP implementation in higher education (HE) sector has been increasing with universities under pressure to improve their performance and efficiency. Most of the studies related to ERP implementation in higher education are related to the factors which influence the success of ERP implementation or failures across various universities especially in the US and Australia. There is limited study of ERP implementation in HE institutes from a user perspective. Indian HE institutions have just started adopting ERP and there is no study available related to the Indian universities. In this paper we study the employee perceptions, motivations and use of ERP and the implications to the organization objectives. We study the ERP implementation in an Indian HE institute and provide a descriptive case study which can serve as a real life example for HE institutes in India and other developing countries planning to implement Enterprise Systems.

Introduction

Enterprise Resource Planning (ERP) is an integrated management tool in the form of software packages which are implemented in organizations to integrate all the existing organizational systems and functions [START_REF] Hellens | Qualitative case studies on implementation of enterprise wide systems[END_REF]. The implementation of ERP is one of the most pervasive change activities that organizations have brought in during the last decade. There are several factors on which the outcome of any technology implementation depends, including activities of decision makers and on how end users respond to those activities [START_REF] Lewis | Innovation modification during intra-organizational adoption[END_REF]. ERP systems have been introduced into higher education (HE) sector to improve and integrate the management and administration processes in student registration, human resources systems and financial processing [START_REF] Hellens | Qualitative case studies on implementation of enterprise wide systems[END_REF]. But in educational institutes the ERP system implementation has been problematic due to lack of ERP implementation expertise and IT resources [START_REF] Esteves | Enterprise resource planning system research: An annotated bibliography[END_REF].

Globally there has been an increase in ERP adoption in higher education institutions and the HE ERP market has shown rapid growth and consolidation in the recent years [START_REF] Gartner | Magic Quadrant for Higher Education Administrative Suites[END_REF]. While it is accepted that ERP in HE is different from implementing ERP in the corporate settings [START_REF] Pollock | ERP Systems and the University as a "unique" organisation[END_REF][START_REF] King | The promise and Performance of Enterprise Systems in Higher Education, Respondent Summary[END_REF], existing academic literature studying ERP implementation in HE is limited. Literature covers the drivers for ERP adoption in universities and HE sector such as modernization of systems, need for greater flexibility and usability, business process reengineering, integration of data and systems, risk avoidance and reduced maintenance [START_REF] King | The promise and Performance of Enterprise Systems in Higher Education, Respondent Summary[END_REF][START_REF] Oliver | ERP systems: the route to adoption[END_REF], and the issues with ERP implementation such as organizational issues related to decision-making process, management support, change management practices, project management issues, privacy & security issues and impact of organizational culture [START_REF] Hellens | Qualitative case studies on implementation of enterprise wide systems[END_REF][START_REF] Beekhuyzen | Organizational culture and enterprise resource planning (ERP) systems implementation[END_REF].

Indian education institutions have started adopting IT for administration and teaching. ERP adoption in Indian HE has recently picked up and differs from that in universities in other countries on aspects like IT management capabilities of the HE institution, lack of IT exposure of the administrative staff, organizational structure, vendor experience, and implementation support in the Indian IT market. For instance, many of the senior administrative staff in educational institutions are not exposed to computer usage and introduction of ERP systems requires considerable training for the staff.

In this paper we study the ERP implementation in an Indian higher education institution. The focus of the study is on employee perceptions, motivations and use of ERP and the implication to the organizational goals. We first provide the theoretical background and the research question. Next, the case study is presented by providing details of the research method followed by an overview of the case study organization. We discuss the detailed case analysis along with the findings, followed by the conclusions.

Theoretical Background and Research Question

ERP systems were initially designed to support common organizational functions like payroll, human resource management, materials management, accounting, etc. As ERP was extended to new contexts like public sector, higher education, and services industry; new modules have been added to cater to the industry specific needs and operations [START_REF] Pollock | ERP Systems and the University as a "unique" organisation[END_REF]. In the context of HE, ERP systems provide a different set of administrative and academic functionalities like handling admissions of students (e.g. processing student application forms, candidate short-listing, fee processing), course enrollments, student data management (e.g., attendance tracking, grade information), course management (e.g. enrollment, feedback on courses), asset management(e.g., contracts, grants), library systems, financial systems, alumni management and research networks [START_REF] Pollock | ERP Systems and the University as a "unique" organisation[END_REF] [START_REF] Zornada | Implementing ERP in Higher Education Institutions[END_REF]. Hence the context of HE offers unique set of requirements and challenges for the ERP implementation.

The complexity and the wide ranging impact of ERP implementation make it an organizational change initiative rather than just a technology implementation effort. Hence, Hong and Kim [START_REF] Hong | The critical success factors for ERP implementation: an organizational fit perspective[END_REF] state organizational resistance to change as one of the critical success factors (CSF) for ERP implementation. User resistance to ERP and IS systems and strategies for managing them have been studied by various researchers [START_REF] Jiang | User resistance and strategies for promoting acceptance across system types[END_REF][START_REF] Shang | Managing User Resistance in Enterprise Systems Implementation[END_REF]. Studies capturing the difference in perception among decision makers and end users with respect to effective implementation activities are limited [START_REF] Gyampah | ERP implementation factors A comparison of managerial and end-user perspectives[END_REF]. As compared to corporates, educational institutes depend on boardroom consensus rather than managerial prerogative [START_REF] Gates | Evaluating the North American pilot for SAP's campus management system[END_REF] and a distributed authority structure [START_REF] Rabaa'i | Identifying Critical Success Factors of ERP Systems at the Higher Education Sector[END_REF]. McCredie and Updegrove [START_REF] Mccredie | Enterprise System Implementations: Lessons from the Trenches[END_REF], based on their experience in US institutions, highlight the need to develop decision-making frameworks in HE institutions specifically to assist ERP implementations, as consensus based decision making does not work in ERP projects. Other inefficiencies in ERP implementation due to HE organization structures are lack of communication among units, lack of transparency of responsibilities and business processes [START_REF] Sprenger | Cost-Benefit Analysis for the Selection, Migration, and Operationof a Campus Management System[END_REF]. The critical success factors [START_REF] Rabaa'i | Identifying Critical Success Factors of ERP Systems at the Higher Education Sector[END_REF][START_REF] Lechtchinskaia | Critical Success Factors for Adoption of Integrated Information Systems in Higher Education Institutions -A Meta-Analysis[END_REF] and factors leading to unsuccessful and ineffective ERP implementation in HE institutes [START_REF] Beekhuyzen | Organizational culture and enterprise resource planning (ERP) systems implementation[END_REF] have been discussed by researchers.

Siau and Messersmith [START_REF] Siau | Analyzing ERP Implementation at a Public University Using the Innovation Strategy Model[END_REF] highlight the need to focus on the end-users who hold the key to ERP implementation success, especially in public institutions. Through a qualitative content analysis, they find that during ERP implementation in HE, special attention needs to be paid to stakeholder participation, internal and external communication and business process reengineering. Their study also finds that motivating employees intrinsically is of great benefit to universities making significant organizational changes (like ERP implementation), especially when they cannot financially afford other motivational facilities. Abugabah and Sanzogni [START_REF] Abugabah | Enterprise Resource Planning (ERP) System in Higher Education: A literature Review and Implications[END_REF] provide a detailed literature survey of ERP implementation in HE and find that, while most studies of ERP focus on the technical issues or implementation processes, studies of user perspectives are less evident in literature. They point out the need to shift research attention to more important elements such as users, task and system and how these can increase the benefits of ERP. The behavioural intention of a user's acceptance of information system can be well defined by 'Technology Acceptance Model' (TAM) [START_REF] Davis | Perceived usefulness, perceived ease of use, and user acceptance of information technology[END_REF][START_REF] Venkatesh | A Theoretical Extension of the Technology Acceptance Model: Four Longitudinal Field Studies[END_REF]. According to TAM, the behavioural intention to accept any technology depends on two key beliefs, the perceived usefulness and the ease of use [START_REF] Davis | Perceived usefulness, perceived ease of use, and user acceptance of information technology[END_REF]. Perceived usefulness is an individual's subjective probability of how an information system application can enhance his or her job performance, whereas ease of use is the degree to which user feels the system to be free of effort.

For any implementation, end user satisfaction is an important measure of the success of the respective system [START_REF] Delone | Information systems success: the quest for the dependent variable[END_REF][START_REF] Wixom | A theoretical integration of user satisfaction and technology acceptance[END_REF]. The difference between the implementation perception of end user and management level employee is evident at all developmental stages as users have conflicting information requirements and end users do not have any power on system design [START_REF] Frantz | Perceptions of selected administrators regarding Enterprise Planning software implementation best practices, and the relationship between these perceptions and selected variables[END_REF]. It is very important for the decision makers that they ensure end user involvement in the system development process [START_REF] Lechtchinskaia | Critical Success Factors for Adoption of Integrated Information Systems in Higher Education Institutions -A Meta-Analysis[END_REF]. Several stakeholders involved in ERP implementation, including top management, project manager, team leaders, trainers, end user, consultants and vendors [START_REF] Gyampah | ERP implementation factors A comparison of managerial and end-user perspectives[END_REF] may have their own interests in ERP implementation [26].The absence of a shared understanding of project benefits may contribute to implementation difficulties. Also, ERP systems have the potential to dramatically alter jobs and business processes [START_REF] Morris | Job characteristics and job satisfaction: understanding the role of enterprise resource planning system implementation[END_REF].

Huang and Palvia [START_REF] Huang | ERP implementation issues in advanced and developing countries[END_REF] identify differences in the ERP implementation issues in advanced and developing countries. At the macro level, issues of ERP implementation in developing countries are infrastructure, economic growth, and government regulations; and at the organization level, low IT maturity, small size of firms, lack of process management and BPR experience. They find that in India and China, organizations lack a culture that regards computers as a pervasive way of doing business. Soh, Kein & Tay-Yap [START_REF] Soh | Cultural Fits and Misfits: Is ERP a Universal Solution?[END_REF] suggest that cultural 'misfit' i.e., gap between the functionality in the ERP package and the requirements of the adopting organizations may be higher in Asia because the business models and processes embedded in most ERP packages reflect European and U.S. industry practices. Studies exist which look at the modifications required to transfer and adapt ERP systems built for developed countries to the socio-organizational conditions of developing countries [START_REF] Jarvenpaa | An Information Company in Mexico: Extending the resource-based view of the firm to a developing country context[END_REF][START_REF] He | The ERP Challenge in China: A resource-based perspective[END_REF]. Plant and Willcocks [START_REF] Plant | Critical Success Factors in International ERP Implementations: A Case Research Approach[END_REF] extend the work related to the critical success factors of ERP by Somers & Nelson [START_REF] Somers | The Impact of Critical Success Factors across the Stages of Enterprise Resource Planning Implementations[END_REF] and find that the CSFs differ by country and context.

The literature review while highlighting the importance of user participation, their motivation and perceptions for the successful adoption of ERP, identifies the need for ERP studies from a user perspective. The existing research studies on CSF also bring out the differences in CSF priorities based on national and cultural issues.

Our research objective is to study the ERP implementation in the Indian HE scenario from a user perspective. The broad research question we are addressing is: Does the Indian HE context offer uniqueness for ERP implementation? The paper explores this in terms of administrative and management work practices, perceptions of the administrative and academic work-force about ERP, decision-making and change management.

Research Method

The research method adopted is that of a case study. This qualitative method has been chosen since it helps investigate a contemporary situation within its real life context. The primary intent of the case study is to understand the perceptions and motivations of the staff and management about the ERP implementation in the Indian HE institution. A single descriptive case study was conducted of a leading business school in India. The single case study approach was used to provide a richer understanding of the situation and not to test any theory [START_REF] Yin | Case study research: Design and methods (3rd[END_REF]. As the study was to understand the employee perceptions and capture the contextual complexity, data was collected through semi-structured open-ended interviews rather than administering a questionnaire. The method helped to get the direct reports of attitudes and perceptions of the interviewees and achieve depth in the study.

The sampling method employed for the interviews was what Marshall and Rossman [START_REF] Marshall | Designing qualitative research[END_REF] classify as 'elite interviewing', "a specialized case of interviewing that focuses on a particular type of interviewee" (p: 94) "considered to be the influential, the prominent, and the well-informed people in an organization" (p: 83). While this method can give rise to 'elite bias', it has been ensured that the interviewees include those from various levels within the organization to 'represent various "voices"' [START_REF] Myers | The qualitative interview in IS research: Examining the craft[END_REF].The ERP Chairperson was the key informant who provided information regarding the goals and motivations of ERP implementation at the Institute, the product evaluation, selection, implementation approach, plan, progress and challenges in the ERP implementation. He also assisted the study by providing a list of key people involved in the ERP project and the primary users and units within the Institute. The choice of respondents was made by the researchers to ensure coverage across different units, roles and employment experience with the Institute. The ERP program manager, an independent consultant, responsible for the ERP implementation program was identified as another key informant. A phase-wise ERP implementation approach was being adopted in the Institute, with each phase covering different administrative departments and academic program offices. Administrative Officers (AO) and staff from different departments who were involved in the implementation were contacted for data collection. The interviews were conducted over three months from September 2011 to Nov 2011, around two years after the first phase of implementation. The researchers interviewed twelve interviewees involved in various roles of AO, admissions officer and staff at various program offices and functional departments. Each interview session lasted 90 to150 minutes. At least two researchers were present during each interview and notes were taken by two researchers to ensure completeness and data accuracy. The initial assumptions of the researchers that are based on theory and inputs from ERP Chairperson have been put to test by constant questioning of these assumptions during the interpretive analysis of transcripts.

Background

Established in the early 70s, the case organization -an Indian graduate business school (referred to as GBS in this paper), has since built on its base of highly accomplished faculty, world class infrastructure and motivated student body and is one of the premier institutes for management education and research. Currently the Institute offers four MBA equivalent programs, in addition to a doctoral program. All programs are highly rated and GBS alumni occupy senior managerial and academic positions across the globe. The other programs include Executive Education Programs (EEP), international programs jointly offered with foreign universities and courses for entrepreneurs and family businesses. In addition to the research conducted by the individual faculty members in the various Areas, GBS has 10 research centres focusing on different aspects of management and different sectors.

GBS being a quasi-government organization, has to adhere to many of the policies and directives from the Ministry of Human Resource Development (HRD) of Indian government pertaining to employees' recruitment and compensation, students' intake and registration, organization structure and processes. However, the Institute operations are handled independently within this broad framework. GBS is only a graduate business school and hence the administrative structure is different from that found in other typical universities. The Institute is headed by a Director, a position held for a specific period of time after which (s)he continues to be a faculty. The faculty members are entrusted with additional management and administrative responsibilities generally of 2-year duration. Some of the posts include Dean (Academic), Dean (Administration), and Chairperson of the respective Program, etc. Each program chairperson is assisted by an Administrative Officer, who also reports to the Chief Administrative Officer (CAO). The Institute's administration activities are handled by the various AOs along with the supervisors and other staff. GBS's organization can be viewed as being purely administrative (facility management, estate maintenance, travel etc.), academic administration (library, computer centre, placement cell) and purely academic (the programs, faculty research). An illustrative organizational chart is presented below.

Figure: Organization Structure of GBS

There are no formal job descriptions or roles and responsibilities defined within GBS. Between the three levels of officer, supervisor and staff, the tasks are distributed through consensus within the team. It is expected that the staff handle responsibilities ranging from day to day logistics, data entry, consolidation, answering queries, to other official work. The officers assist the Chairpersons in managing the programs and are involved in making decisions related to a program. They provide the necessary information and reports related to the program to the Director and the Board of Governors.

Many of the administrative staff have been with the Institute since the early days of the Institute and much longer than the faculty. Many of them have completed their terminal education decades back and have up-skilled themselves to handle the changes in day-to-day work. The administration processes were largely manual, using spread sheets and documents. There is very little formal documentation of these processes as they have evolved over time. Coupled with this, most of the staff is due to retire in the next few years taking with them the tacit knowledge and organizational know-how of the processes and the policies. GBS does not plan to replace the outgoing employees with new recruits, in line with the Ministry of HRD's prescriptions to reduce staff strength. GBS currently has about 2000 students, 200 staff, 30 interns and consultants, 85 contract employees and 120 faculty members. The Institute is comfortable with outsourcing and has outsourced most of the support services like housekeeping maintenance, catering, IT infrastructure support, etc.

IT at GBS (Graduate Business School)

GBS does not have an in-house IS team. All the IT infrastructure and support operations have been outsourced and are handled by the onsite IT vendor staff with supervision from the GBS IT Manager. Prior to ERP, most of the administration processes were islands of automation with some paper-based manual processes, creating a dependency on the specific individuals in terms of knowledge of work processes. Not every employee had access to desktop computers till a few years prior to ERP implementation. Usage of software applications was on a need basis and distributed across the departments. Finance and Accounts departments and Payroll used a popular desktop based third party package. Library had acquired a library management system; student registration was handled by another local software product. Spread sheets (MS-Excel) were used for storing, communicating and analyzing data in most departments and programs.

The processes for fee payment and obtaining clearances from the accounts departments, HR processes like leave and employee records management, were all handled manually. Student feedback collection and analysis, course scheduling, resource allocation etc., were all manual paper-based processes. The information on the utilization and availability of resources at a given point of time was not available easily.

has executive positions for various support functions like finance, administration, and personnel, but has not recognized the need for such a role for Information Systems (IS). Whenever any queries or decisions related to IS come up, the Institute management looks towards the faculty in the IS department for assistance. Hence when the ERP initiative was envisaged by the management, there was a significant handicap about who will lead the implementation team.

ERP Implementation Context

GBS's initial attempt at ERP was in 2006, when ERP in HE was just gaining traction with universities, and vendors were very actively increasing their product footprint into the HE areas. Though a contract was initiated with one of the leading ERP vendors, the project was abandoned due to organizational dynamics and lack of consensus on decisions related to product choice, budget, implementation approach, etc [START_REF] Mccredie | Enterprise System Implementations: Lessons from the Trenches[END_REF]. The current ERP implementation initiative was championed by the Dean (Administration) when he took charge in 2008 and he was supported by the Institute Director who had recently joined GBS. In line with the GBS's vision of being a world class institution providing world class infrastructure, using a process-centric approach, leveraging technology for optimal utilization of resources was one of the main drivers.

During the last decade the scale, scope and complexity of administration at GBS has increased tremendously with increase in student intake and introduction of new programs. Administrative complexity is in the form of number of programs and electives offered, scheduling of faculty lectures, management and co-ordination of the teaching infrastructure, managing student registration, fees, attendance, grades and feedback of increasing number of students across varied courses and programs. While the human bandwidth was being challenged, expectations from the Institute's board, students, applicants and other stakeholders were increasing continuously with respect to the services, productivity and responsiveness of the Institute.

An analysis of the HR system by the Dean in 2008 revealed that about 60% of the administrative workforce would retire in the next five years. Program Chairpersons and faculty have limited knowledge of the administrative processes. There were issues related to aging workforce, retention of organizational process knowledge and sustenance of administrative process improvements. GBS also realized that there were issues with documentation and standardization of procedures across the various programs. Organizational data was in silos and was highly person-dependent. Regular reporting was missing and hence there were no reports to look at if there was a need to understand any situation.

'Data was in islands'. -Dean (administration)

ERP Selection and Implementation Process

A team consisting of the Finance head, CAO and a few faculty members was formed for the ERP product evaluation and vendor selection. It was decided that the software provider should also handle the implementation. The current vendor was chosen based on the responses to the request for proposal sent to the leading ERP vendors in the HE space. The product evaluation exercise was very detailed. Process scripts were written for some of the key GBS processes using inputs from the program chairpersons and department heads and provided to the vendor. The vendor later provided a demo of the various features of the ERP software to GBS staff.

Collectively the groups agreed that ERP was good but nobody knew how it affected them. There was an 18 month lead time between the product decision and the actual signing of the contract as there were still some contemplations about the product. An implementation committee consisting of Finance head, ERP Chairperson (who is an IS faculty member), an external ERP consultant and vendor member was formed to oversee the implementation process. Neither the vendor's Indian team nor the GBS implementation committee had sufficient and relevant implementation experience. Added to this, there were issues with vendor's competencies to implement and readiness to start as this was their first HE ERP implementation in India. While the vendor has implementation expertise available globally, this being their first implementation in South Asia, there was very little implementation expertise in their Indian team. Once the implementation was initiated several other people-related issues came up like inability of users to attend training sessions due to their work load; resistance to double data entry (current system and ERP system) for data validation runs; hesitance to share knowledge.

The Dean recruited contract hires to handle the extra workload of double data entry. People motivated towards using ERP were roped in to maintain the implementation momentum. Regular status reporting and weekly meetings were conducted to induce peer pressure on the lagging departments. But there were no defined goals related to ERP implementation for departments and individuals. GBS adopted a phased ERP implementation approach and the first phase went live in December 2009 within 6 months of the initial training to the staff. While the implementation is currently being expanded to other units with more functionality, there are instances of user resistance visible across the Institute. Some of the staff who were identified as ERP friendly and early adopters say that the ERP is not very useful and they continue doing their work in Excel and upload data to ERP at the end.

Communication

Lack of communication regarding ERP implementation and progress is glaringly obvious in GBS. No formal communication mechanisms have been setup by the management. It is assumed that communication will flow down through the hierarchy and reporting channels. There has been no communication from the senior management in the Institute regarding the objectives of ERP, the challenges and issues which may come up during implementation and the support which will be provided to the staff. There was a mention of ERP in the fortnightly newsletter when it was first deployed. The weekly meetings conducted during the early stages of ERP implementation have also stopped. Almost all the people interviewed mentioned that they knew about ERP from their informal networks. This increased the ambiguity and misinformation related to ERP. "ERP implementation information was not communicated to the employees because strategically the team did not want oppositions from the time of implementation itself. Also how could most of the employees have helped apart from informing what they are doing?" -external ERP consultant

Analysis of the Case

The case analysis reveals many interesting details related to ERP implementation, some which are specific to the Indian context keeping the end user in perspective. We analyze the motivations, user perceptions and implications under the following broad categories: (1) Motivation for ERP adoption (2) User perceptions during ERP implementation (3) Changed job characteristics (4) Technical issues and decisions.

Motivation for ERP adoption

The motivation for GBS management for ERP adoption was driven by the then existing organizational context and external environment influences. The main drivers for ERP implementation were:

 Handle administration complexity by centralizing the administration processes across programs and automation of processes using ERP  Retention of organizational process knowledge and ensure continuity in efficiency improvements in administration  Meet the rising expectations from all stakeholders  Provide shared access to data for decision support Except for organizational knowledge retention which is unique to GBS, the other drivers are in common with most ERP implementations in HE [START_REF] King | The promise and Performance of Enterprise Systems in Higher Education, Respondent Summary[END_REF][START_REF] Oliver | ERP systems: the route to adoption[END_REF]. There was also the implicit goal of reducing the administrative staff by bringing in automation. This would be achieved by not replacing the staff who retire, rather than through downsizing, though this was not explicitly communicated to the employees Users have different motivations for adopting (or not adopting) ERP based on individual perceptions, attitudes and interests. "…. have used PeopleSoft in my previous organization and know that ERP will bring down my workload drastically. I am able to focus on other activities related to student affairs…" -Admin associate at a program office "….with my software background, I was open to ERP as I hoped it would automate most of the processes and reduce the data entry requirements…" -Admin staff at one of the programs which was the initial adopter of ERP "We have been told to implement ERP and so we will. … I have heard from my friends in other organizations that ERP will make my work easy..…." -Officer at one of the departments "…..I was interested to learn about this ERP and took the initiative to understand what it involved…" -Admin staff at one of the programs which was the initial adopter of ERP "….people were worried about layoffs, as they thought that bringing in a technology may lead to reduction in manpower. A few of the older employees were unwilling to accept the ERP as they did not want to learn…" -Supervisor at Finance Department These views reflect the influence of age, prior exposure to IT, benefits visualized from ERP, superior and peer influence, misinformation and insecurity. These factors have been identified by previous researchers when studying Theory of planned behavior (TPB), technology adoption behaviours and decisions in TAM [START_REF] Morris | Age differences in technology adoption decisions: implications for a changing work force[END_REF][START_REF] Janson | Information systems development and communicative action theory[END_REF][START_REF] De Jager | Communicating in times of change[END_REF].

User Perceptions during ERP Implementation

The implementation team opined that they took all efforts including custom building the functionality in some cases to ensure product suitability to GBS processes and thorough testing and parallel runs before going live.

But the staff feels that the system is not suited for their needs. "…This product is suited for US Universities. Indian Institutes are different. The vendor people can't understand our concepts…." "….You can't expect me to change myself to fit into the box you have provided; the ERP has to be customized to suit our processes…." "…Different programs have different validation requirements (for applications)and the ERP team does not understand this."

In addition to this perception of misfit between the ERP system and existing processes, the staff also perceives that they were not involved in the ERP selection and implementation process. "… for the initial implementation, the requirements were not obtained from the users." "…all our requirements were initially channeled through the ERP consultant to the vendor's development team. The consultant is not an ERP expert. Now with direct interaction we can see that our requirements are being considered…" " …They (Vendor) showed us some screens, but no one asked us how we process our forms…" "….I was not actively involved in requirements phase and there was no direct coordination between vendor and me" "Training was not done properly. …The training was provided after a long time"

In order to avoid personality clashes between the external consultant and AOs, the vendor's development staff started interacting directly with the GBS staff during the implementation phase. A positive outcome of this was that the initial perception of the staff related to lack of involvement in the process [START_REF] Mumford | Human values and the introduction of technological change[END_REF] was addressed to some extent by these interactions.

Changed Job Characteristics

With the introduction of ERP most of the junior staff within the Institute mentioned that their workload has reduced as many of the tasks are fully automated. They are younger and more open to ERP and experience higher job satisfaction since they can do more value adding work. They are now able to devote time to address students' issues, offer more services like manage student clubs, handle course bidding process etc., and focus on other administrative activities that were neglected before. Some of them believe that in future each program office would be able to operate with just two members (an Officer and an Associate). However, the perceptions of the officers differ in this aspect, they feel that the ERP system will not be able to handle the various complexities of the processes and that human intervention is required in many cases. This view of the officers may be because they perceive loss of power and autonomy due to loss of control on program level information and decision making, similar to what Markus [START_REF] Markus | Power, politics, and MIS implementation[END_REF] observed when centralized processes were implemented using information systems. With the new processes in ERP and easy access to integrated data for the decision making, the senior staff may feel their contribution to productivity is reduced [START_REF] Smith | Computerization and management: a study of conflict and change[END_REF]. There also seems to be a minor power struggle within the program offices. "…they view it as power moving to juniors working with ERP … but many of them are not willing to learn ERP as they are nearing retirement…" -Junior Staff With many of the employees retiring in the next few years, lack of job descriptions and the changes in tasks of the administrative staff due to ERP implementation, GBS can explore job (re)design considering its objective of optimal utilization of resources [START_REF] Morris | Job characteristics and job satisfaction: understanding the role of enterprise resource planning system implementation[END_REF]. Formal job definition is required as ERP mandates it due to access and control flows built in the system. There may be a clash between the informal reporting structures and responsibilities currently practiced and the formal reporting structure required by ERP.

Technical Issues and Decisions

At GBS the level of customization of the process in the ERP package was decided based on the department type: no customization for purely administrative functions; minimal customization for academic administration; and high customization for purely academic functions. Many of the users were not fully aware of the customization criteria as there was no communication on what they can expect. Hence the users assumed that the functionality offered by ERP would have procedures, formats and templates that they currently used. They expected the flexibility of reports and data access similar to what they were exposed to with spread sheets.

The ERP applications were designed by considering data security, control and data integrity. This meant that users would not be able to access data which was not relevant to them. The users were confused as to why data which was available in the system cannot be shared with them. Any data requirement other than what the standard reports offered, invited questions from the development team and had to go through an approval from the ERP committee, but no explicit policies related to data security and privacy were communicated. This was also a cause for user dissatisfaction since the system introduced control in every operation by standardizing procedures. Certain reports which were one-off type of reports were not available as standard reports which led to user perception that the reports are not flexible. Some of the ERP friendly users learnt that queries could be built to generate one-time reports. As most of the data collection was automated, the need for data access for the staff became redundant, but they were not able to appreciate the reasons. For e.g., employee leave records are automated and all leave history can be viewed by the employee. Personnel department does not need to maintain the paper forms of leave application; hence all personnel department members do not have access to employees' leave records. Some of the staff mentioned that analysis results provided by ERP do not match the manual process outputs. But on verification with the ERP committee it was found that the reason for mismatch was due to the shortcomings of the Excel based analysis. Some decisions which were taken by junior staff while working on Excel macros are issues which impact calculations, but were previously not obvious. For e.g., if a cell is left blank for a score, when taking the weighted average, should it be considered as not applicable or as zero? If taken as zero, which was usually the case in excel, it would change the mean and other parameters of the measure. Similar issues which were perceived as technical shortcomings or defects in the ERP were actually policy decisions consciously taken by the ERP committee team with approval from the Dean (Administration).

But other technical glitches and shortcomings added to the employee frustration. The initial screens were not user friendly as the focus of the ERP team was more on automating the process first and improving usability later. Due to the phased implementation approach some of the departments have only been doing data entry and have not seen the benefits of their efforts. Some complained that the system has not yet stabilized and goes offline sometimes creating doubts related to data storage. "…all my leave records are in the system. I do not know whether the data will be safe in ERP 30 years from now, when I retire. So I keep a paper based copy of all the records…" -a staff member from personnel department.

The training appears to have been focused on how to do data entry and not on using the ERP system for processing and task execution. "I was given training for 3 months on how to enter the data. But not on how I can see the reports or get information about the employee records."

Given the lack of IT awareness and limited exposure to IT systems and ERP, training from an end-user perspective may reduce many of the concerns and apprehensions of the staff with respect to ERP.

Discussion

The ERP implementation at GBS is currently on with a few functions and processes yet to be addressed. Hence maintaining positive perceptions and motivations towards ERP usage is critical for the ERP implementation. We find that most of the reasons for user resistance are linked to the perceptions built during the course of the ERP implementation process. Many of the users mentioned that their initial expectations of ERP which lead to their adoption of ERP, were not met and now they feel that ERP is not very useful. The reasons for employees' resistance which Jiang et al. [START_REF] Jiang | User resistance and strategies for promoting acceptance across system types[END_REF] summarize were visible in GBS -change in job content, loss of status, altered interpersonal relationships, loss of power, change in decision-making approach, uncertainty / unfamiliarity / misinformation and job insecurity.

As negative perceptions can spread through peer influences when there is no communication from senior management [START_REF] Morris | Age differences in technology adoption decisions: implications for a changing work force[END_REF], the ERP committee at GBS will have to adopt strategies to promote user acceptance and address the various perceptions and reasons for user resistance. Lectchinskaia et.al [START_REF] Lechtchinskaia | Critical Success Factors for Adoption of Integrated Information Systems in Higher Education Institutions -A Meta-Analysis[END_REF] identify stakeholder participation as the most important CSF among the 22 CSFs they have deduced from their meta-analysis of CSFs.

We discuss below some of the study findings which are unique to GBS and the Indian context and recommend practices for ERP implementation.  Implicit goals for ERP implementation affecting user perceptions: GBS motivation of handling the issues of aging workforce and knowledge retention through ERP implementation appears to be unique. GBS actions due to the implicit goal of reducing staff, evident through low communication to staff (about ERP rollout), hiring temporary staff for data entry, focus on functionality rather than usability, has an impact on user perceptions. GBS needs to evaluate the negative impact of these actions on its long-term goal.  Organization structure affecting the long-term perspective of ERP: Given the phased approach taken up by GBS, the 2-3 year tenure of the various senior management positions is affecting the long-term success of the ERP implementation. Specific goals and responsibility for the ERP adoption needs to be assigned to different roles in the organization.  Aging workforce issues hindering ERP implementation: The senior-user buy-in and participation may be minimal or absent as they perceive themselves as becoming redundant and having to re-skill themselves. GBS needs to address this issue as the goal of knowledge retention requires senior-users participation in the ERP implementation.

 The ERP product not a good 'fit' to the Indian HE context: When evaluating non-India based ERP package for the Indian HE institute, the product evaluation and vendor selection exercise has to include requirements related to cultural fit, terminology, language, etc.  Absence of in-house IS team creating conflicts: As there is no in-house IS group in GBS, the external ERP consultant holds an important position as the ERP implementation program manager. This is creating conflicts as the staff views him as a barrier to getting their requirements across to the development team.

Frequent communication and other interventions by GBS management will help reduce these conflicts and provide support to the program manager role.  User training needs to be customized to the level of awareness: Some employees feared loss of data and doubted correctness of data in ERP systems. The low IT maturity and computer awareness of the user demands that the user training address many aspects of ERP system. For e.g. training on data storage and accessibility to build users trust in the security and stability of the data within the system, extent of flexibility provided by ERP to the user, etc.  Lack of data related policies creating confusion: Users could not understand why there were not given access to certain data and reports. As ERP brings in the ability for data consolidation and aggregation across the organization, data access and control has to be explicitly defined and implemented in the system. Policies related to data security, data privacy and data usage should be defined and communicated to all users. BPR, change in organizational structure and responsibilities is usually identified as important CSFs for ERP, but data related policies have not been explicitly mentioned.

Conclusions

When an information system is introduced in an organization, 'one of the most fundamental results is that the system is either used or not used' [START_REF] Silver | The Information Technology Interaction Model: A Foundation for the MBA Core Course[END_REF]. The study revealed that there are variations in the level of ERP usage by the end-users. The study focused on the motivation that led to usage of the system, the perceptions and challenges that downplayed the intended usage of the system and differences in adoption by staff at various levels. Many of the findings in the study align with issues identified in other ERP implementations in higher education institutes globally. Some of the issues identified in the case study are due to specific characteristics of Indian HE institutes like absence of IT management capabilities in the HE institution, lack of IT exposure of the administrative staff, vendor experience & implementation support in the Indian IT market and HE organizational structure. The finding related to the need for defining explicit data related policies during ERP implementation is applicable in all scenarios and has not been discussed in prior literature.

The study also identified certain issues which are unique to the Indian context and provided inputs to handle them, and can serve as a real life example for other HE institutes in India. Additionally, many of the aspects related to Indian HE would be found in other developing country institutes and the findings can be applied to those contexts as well.