ERP systems and the university as a “unique” organization

Neil Pollock

Management School, University of Edinburgh, Edinburgh, UK, and

James Cornford

Business School, University of Newcastle upon Tyne, Newcastle, UK

Keywords Universities, Standardization, Customization

Abstract Enterprise resource planning (ERP) systems are widely used by large corporations around the world. Recently, universities have turned to ERP as a means of replacing existing management and administration computer systems. This article provides analysis of the rollout of an ERP system in one particular institution in the UK, the particular focus being on how the development, implementation and use of both generic and university speciWc functionality is mediated and shaped by a fundamental and long standing tension within universities: this is the extent to which higher education institutions are organisations much like any other and the extent to which they are “unique”. The aim of this article is not to attempt to settle this issue of similarity/difference in one way or another. Rather, it seeks to illustrate the value of taking discussions of similarity relationships surrounding the university and other organisations as the topic of analysis. One way of working with these kinds of issues without resolving them is to consider their “distribution” and where ERP shifts the responsibility for their Wnal resolution. This is a novel and insightful way of understanding how ERP systems are refashioning the identity of universities. The article suggests, moreover, that ERP software is “accompanied”by such tensions in which ever site it is implemented. The research presented here is based on a participant observation study carried over the period of three years.

Similarity relationships

It is a truism that universities form one of the oldest established institutions in the western world – far older, for example, than the joint stock company or indeed the bureaucracy of the nation-state – and despite changes in form, function and fashion, the very latest universities retain some links, however tenuous, with their Medieval forebears. Equally, while bodies bearing the title university vary dramatically in terms of their structure, function and form, the very fact that they choose to label themselves as universities rather than any one of a number of other alternatives, suggests at least a desire to capture and share in that thousand year old tradition. On the one hand, then, it is tempting to see the university as something different or set apart from other organisations – as a unique institution in the modern world. Balderston (1995, p. 2), for instance, describes how historically, universities grew as a type of institution that was, and still is to some extent, “distinctive” with an “autonomous place in society and the right to choose its members, settle its aims, and operate in its own way”. On the other hand, it is also clear there are many similarities between universities and other organisations. As Lockwood (1985, p. 29) has put it, “universities as organisations face many problems common to most modern organisations”, including, for instance, the problems of co-ordinating resources, controlling costs, of stimulating and facilitating enterprise among staff, and so on. Thus, it might be argued, that since universities have problems common to a wide range of organisations, then the standard tools of contemporary organisational analysis and institutional management – including computer systems used by large corporations around the world, such as enterprise resource planning (ERP) systems – can be similarly applied in universities. Some have attempted to resolve this issue of differences/similarities in an interesting way. Lockwood (1985, pp. 31-32), for instance, argues that

universities are unique only to the extent they possess a certain combination of common characteristics which he lists as complexity of purpose, limited measurability of outputs, both autonomy and dependency from wider society, diffuse structure of authority and internal fragmentation. Whereas organisations in general might possess one or more of these characteristics or components, it is the particular combination of the components within universities that make universities “unique”. The aim of this article is not to attempt to settle this issue of similarity/difference in one way or another (as if that was at all possible), or try to offer a deWnitive account of the institutional identity and boundedness of the university. Rather, it seeks to highlight the value of taking the discussions of similarity relationships surrounding the university and other organisations as the object of study. One way of working with these kinds of issues without resolving them is to consider their “distribution” and where ERP shifts the responsibility for their Wnal resolution. In this article we present evidence from the implementation, and further development, of an ERP system within a British university (an institution we are calling “Big Civic”). Here the construction of similarity/difference occurred not simply

within the conWnes of the project team but was also the outcome of a set of relationships the university has with the system, its supplier, various internal departments, and other institutions involved in similar implementations. This is a novel and insightful way of understanding how ERP systems are refashioning the identity of universities. We argue, moreover, that ERP software is “accompanied” by such tensions in which ever setting it is implemented.

The ERP system we studied (let us call this system “Enterprise”) has a particularly “mature” biography (Pollock et al., 2003). Initially conceived according to a narrow set of assumptions about how organisations operate (it has its roots in manufacturing and material requirements planning (MRP) systems), Enterprise has been continually applied to new contexts (i.e. Wnancial services, public sector, healthcare and, now, higher education). In so doing, it has been expanded to include an ever-increasing range of organisational characteristics and functions (Parr and Shanks, 2000). These characteristics are embodied in the system as modules and ready made business process templates and, as is made clear in supplier brochures, are seen as being applicable to a wide variety of user organisations. In some senses, this might be thought of as the practical implementation of Lockwood’s (1985) view: . . . such systems are fundamentally based on the notion that organisations contain common elements and through combining the various modules or templates an organisation can create for itself its own “unique solution”, yet still have a fully supported computer system in which each individual component is “best of breed”. As we will see, this is not, or at least not for universities, the case.

Before presenting our empirical material, however, it will be useful to provide Wrst, some further background information ERP systems, second, the institution and the project underway, and, Wnally, a review of the theoretical notions and concepts that have informed this study, including a description of the identity of the university. Customising an ERP system, restructuring the university The acquisition of well-established, generic and corporate computer systems is increasingly common – and not just among universities. Firms and organisations, rather than commission and build bespoke systems and packages, are adapting general solutions to their local context (see Brady et al., 1992). Generic software packages, such as ERP systems, cover the fullest range of organisational activities and processes and are adopted with the aim of achieving substantial cost savings as well as improved access to “tried and tested” solutions, new releases, and an opportunity to update procedures and align them with perceived “best practice”. However, while organisations choose ERP packages because of their economic beneWts they are potentially a costly and high-risk strategy. First, whereas most early applications of IT were “discrete technologies” applied to speciWc or closely-related functions, ERP attempts to integrate and link together the whole range of functions across and organisation (Davenport, 2000). Second, because ERP systems are built with “generic users” in mind (see Bansler and Havn, 1996), systems seldom translate easily across boundaries, whether this is between organisations within the same sector, between industrial sectors or between public and private sector organisational forms (see Walsham, 2001; Ciborra, 2000). There is often a gulf between the system and the speciWc contexts, practices and requirements of particular user organisations. Among the many issues ERP systems raise, of particular concern to practitioners is the choice between conducting expensive “customisation” work on standard solutions or undergoing unwanted organisational change in adapting their practices to models of work and organizational process embedded in the software.

Customisation and the “power of default”

While proponents of ERP systems have argued that, in principle, such systems have “universal applicability” (see Lozinsky, 1998), there is a growing body of evidence to the contrary. Adopters often Wnd the assumptions embodied by these systems about the nature of organisations and the ways in which they operate run counter to existing structures and work practices. Davenport (1998), for instance, describes how one company had developed a practice of giving its most important customers preferential treatment, which included sometimes shipping them products that had already been allocated to other accounts. Under the new ERP system, however, it no longer had the Xexibility to process orders in this way (see also Walsham, 2001). The suppliers of these systems will, in truth, often acknowledge and try to accommodate organisational variety through the continued addition of new and sector speciWc modules (Scott and Kaindl, 2000). Moreover, many of the more local incompatibilities between the system and the organisation, from the vendor’s point of view, can be reconciled through customisation (Light, 2001). Indeed, these systems are marketed on the Xexibility of their modular design, as well as the ability to choose from hundreds of “business process templates”, and the tailorability of the various parameters and settings. A supplier brochure describes this in more detail: From a broad spectrum of functions and alternative business processes, you select the modules that you want to mould into an internally consistent organizational system for your company, depending on your speciWc requirements. . .We match its core processes to your needs by customizing additional applications, which we or our partners implement for you. Or your own IS staff can do the work simply and easily with the [Supplier SpeciWc] Development Workbench, which is an integral part of the [Enterprise] system.

A user organisation is thus supposed to be able to choose from the 800-plus ready-made business processes, some of which have already been speciWcally tailored to match certain sectors, and then to customise locally the resulting assemblage.

Unsurprisingly, the reality of customising these systems is somewhat different. Pollock (n.d.), for instance, notes some of the problems that arise when there are ambiguities regarding which parts of a system can be modiWed and those parts that cannot, or there are “blurred” boundaries about the roles of designers and implementers (see Trigg and Bodker, 1994). Moreover, just as modifying the “wrong” parts of a system can lead to problems, so too can customising industry standard systems “too much” (Tierney and Williams, 1991; Brady et al., 1992; Hanseth and Braa, 2000). Heavy customisation can mean that a system is taken away from supplier standards, meaning it will be difWcult to make use of later upgrades or new system functionality, the reason why many systems are acquired in the Wrst place (see Light, 2001).

Unregulated and excessive local customisation is at one end of the scale. At the other end, lies the problem of systems not being tailored at all. There is, for example, growing evidence to suggest that because of the sheer number of organisational and technological discrepancies that arise during attempts to customise (see Hanseth and Braa, 2000; Ciborra, 2000;Walsham, 2001), and the complexity and time-consuming nature of each modiWcation, most adopters simply end up Wtting their organisation to the system rather than the other way around (Koch, 1999; Markus et al., 2000). It seems that rather than attempt to reconWgure each and every aspect of a standardised systems (the various templates, system parameters, authorisation proWles and so on), implementation teams simply accept those “default” features already embodied within the system – what one author has called the “power of default” (see Koch, 1999).

The university setting

Big Civic was a pioneer in its attempt to implement an ERP system both within

the UK and further aWeld (see Pollock, 2000). On its Web site for instance, it

describes how once it had completed the project, and installed the ERP Campus

Management module (see below), it would be the “Wrst in the world to have a

fully integrated university ERP solution”. The rationale for Big Civic

embarking on the project, as given by the pro vice chancellor in charge of the

implementation, was both to replace existing systems that were seen as

“limited” and to support a fundamental restructuring of the institution’s

information management as recommended by a consultancy study. Related to

this, it was also hoped that the new Enterprise system would encourage the

development of procedures and practices more commonly found in large

corporations, so called best business practice:

I think the reason why all the bigger universities are beginning to go towards [Enterprise], is

that it has come out of a multi-national environment where in essence what [multi-national

companies] are involved in doing is having highly decentralised structures where you’re

giving your line managers a lot of autonomy and responsibility within a framework of an

overall corporate entity; where the role of higher level managers is to have an oversight of the

business as a whole and take strategic decisions and so on (interview with Pro-Vice

Chancellor).

The project involves a wide range of actors, including the university’s

management and central administration, the software vendor itself, and a

number of third party consultancy companies. At the heart of Enterprise is a

large and complex relational database that will eventually contain information

on the status of staff, students, buildings, equipment, documents and Wnancial

transactions. The Enterprise system is produced by a large European software

producer and includes a number of modules dealing with particular functions

or aspects of the university, including Wnance, human resources, project

management and (eventually) student records. While the supplier had little

experience of working in a higher education setting, it had demonstrated an

intention to commit resources to re-developing its software for this new market,

which included the development of the “Campus management” module.

The distributon and resolution of university identity

As yet, few Wne-grained studies of the implications of ERP systems for

universities have been carried out (but see Scott and Wagner (in press) who

also employ an actor network approach). Cunningham et al. (1998) mention the

potential of ERP for reshaping organisational aspects, but do not present

empirical evidence to illustrate or substantiate such claims. Heiskanen et al.

(2000), by contrast, have conducted a detailed study of the use of software

packages but conclude that such industry standard systems are inappropriate

as universities as organisations are unique, particularly in terms of their

decision making processes:

It would seem that universities are fundamentally different from business organisations in

their decision making processes. Consequently the standard IS development strategies

developed for business may not be appropriate in institutions of higher education (Heiskanen

et al., 2000, p. 7).

While we do not necessarily disagree with this view, we suggest that the

signiWcance of these systems would be better appreciated and understood if we

were to resist viewing universities (or, for that matter, computer systems) as

stable entities or as having characteristics that are “given in the order of

things” (in the manner of Lockwood (1985) or Heiskanen et al. (2000)). Instead,

we want to explore some of the processes that might generate these

characteristics – i.e. the identity of the university, its decision-making

processes and so on – as “effects”. Theoretically, this move has most famously

been explicated in the work of Norbert Elias, Michel Foucault, and, more

recently, in actor network theory, where it has been painstakingly shown how

the development of scientiWc, organisational and bureaucratic processes and

practices, simultaneously involved the development of scientiWc institutions

(Latour, 1988), organisations (Cooper and Law, 1994), and the “modern state”

(Bowker and Star, 1999)[1]. With this in mind, let us now turn our focus to the

identity of the university.

Where is the university?

The notion of “the university” is a notoriously slippery one. The traditional

university is conventionally, if mythically, thought of as a band of scholars

coming together in pursuit and dissemination of knowledge, governed by a

more or less collegiate model of organisation, based around a complex structure

of committees and with a high degree of individual and departmental

autonomy. In this sense “the university” as an institution tends to lack a clear

identity, primarily existing in the heads of people who constitute it and a

myriad of locally negotiated practices and interactions. The central social role

of the traditional university has been to provide a place-based “rite of passage”

for entry into middle class professions through its undergraduate, vocational

and extramural provision, together with the provision of ideas-driven

“academic” research. In institutional terms, it has thus been described as an

exemplar of a “loosely coupled system” (Weick, 1976) characterised by a lack of

clearly articulated policy and weak control over the implementation of policy

(McNay, 1995). The traditional university as an institution, we might say, often

appears to be only virtually present.

This ambiguity is apparent in the extent to which, as one moves around a

university, the institution of the university is always, to a greater or lesser

extent, “over there”. Thus for the academics in their departments, labs and

research centres, “the university” generally refers to the senior management

and, particularly, central administration. By the same token, for the senior

management and the administrators, “the university”which they are seeking to

govern, manage and administer is very clearly “out there” in the departments,

labs and research centres. Meanwhile, for the students, “the university” is seen

as being comprised of both of these groups, but once again somewhat distanced

and apart. “The university”, even for those who work or study within one, is

always “them” and never “us”. In many ways, this distancing is

understandable. For the academic, both status and job security are

dependent less on their current university and more on the “invisible

college” of academics in the same or cognate disciplines at other institutions.

For the institutional manager or administrator, progress depends on interaction

with a body which it is impossible to fully understand (for who can understand

the physicist, the economist and the literary theorist equally well). And for the

student, the duration of their sojourn in the university is typically still a fairly

short-lived prelude to something greater.

Our own solution to the problem of deWning the university is therefore not to

attempt a general deWnition acceptable to all, but rather to accept the complex

and multiple meanings of the term. Following Lee (1999) and Rappert (2001),

we argue that one way of working with such ambiguity without attempting to

resolve it is to attend to its “distribution” and to show where responsibility for

the resolution is located[2]. In this way, we are able to understand how, and

where, these differences and similarities are brought into being, in what

circumstances, and why. It is this that leads us to draw on actor network theory

and the notion of “biography” introduced below, which we think is useful in

explicating this distribution.

Translation and biographies

A number of terms and concepts are synonymous with the actor-network

approach, including viewing the world in terms of the emergence of competing

“actor-networks”, where various elements are brought together or “enrolled”

into an assemblage (Latour, 1987). We emphasise, for instance, how the

successful realisation of differences and similarities depends on the struggles of

actor-networks. By this we mean that similarity and difference between

institutions do not exist out there waiting to be found but depend on the two

things as being constructed or translated in such a way (see Pinch, 1993). As

part of this network building, there are continuous processes of multilateral

change or “translation”, where one actor will attempt to channel the goals of

others in new directions. And, in doing so, an actor will often Wnd her own route

re-directed when she encounters, for instance, a particular technological

“biography”.

The actor-network approach has fruitfully suggested that it is not only

human beings, but also “things” that can undertake the required work of

translation of interest necessary to build and sustain actor networks, and thus

non-humans should also attain the status of actors (Callon, 1986). In this sense,

we want to capture something of the history or “biography” of these systems –

both what they bring with them and what this means for the new sets of users.

Appadurai (1992) and particularly Kopytoff (1992), writing from the

perspective of material culture, use the notion of biography to describe

established artefacts as they move around and are adapted and redeWned

according to the needs of each new place. As Kopytoff emphasises:

. . .what is signiWcant about the adoption of alien objects – as of alien ideas – is not the fact

that they are adopted, but the way they are culturally redeWned and put to use (Kopytoff,

1992, p. 67).

The biography of a car in Africa, to use the example given in Kopytoff’s (1992)

paper, reveals enormous amounts of information about “the relationship of the

seller to the buyer, the uses to which the car is regularly put, the identity of its

most frequent passengers and those who borrow it”, and so on. Crucially, all

these details would “reveal an entirely different biography from that of a

middle-class American or Navajo, or French peasant car” (Kopytoff, 1992, p.

67).

Through building on Appadurai’s (1992) and Kopytoff’s (1992) notion of

biography we attempt to highlight the “accumulated history” of an ERP system

and how this continues to inXuence the structures and practices of later

adopters. In the following discussion we identity how this occurs in at least

three ways: through its all encompassing nature, ERP overwhelms

implementation teams such that they have little option but to implement

“default” settings; such systems are not simply “put to use” but are, where

possible, continually adapted though this is something of a burden; and

because ERP suppliers’ look for commonalties as opposed to diversity in

organisations, systems are accompanied by tensions concerning similarities

and differences. The beneWts of a biographies approach, therefore, combined

with the actor-network perspective, is that it sensitises us to these tensions as

these artefacts move around (across national borders or the boundaries of

several industrial sectors) and are adapted and redeWned according to the needs

of each new setting. This echoes Williams (1997) who has criticised those

approaches that over emphasise the Xexibility of technology, as well as its

potential for re-adaptation to a new setting, without considering the role the

history of the artefact plays in current usage[3].

Methodology

We conducted ethnographic research over a three-year period at Big Civic, a

large red-brick university in the north of England and to a lesser extent at a

large ERP supplier. The study was part of a wider Economic & Social Research

Council study on virtual universities, where we were investigating the

implications of ICTs for the reshaping of universities (see Cornford and Pollock,

2003). From our point of view, the virtual university is not just a matter of

“distance” or “Xexible” teaching and learning systems. As we understood it, the

virtual university is also very much concerned with mundane projects such as

administration (Wnance, personnel, purchasing; estates, etc.); student

recruitment and alumni management; research networks; library systems;

and so on, and because of the way the virtual university extends across every

aspect of institutions, this has important implications for the very nature of the

university. Readings (1996), for instance, describes this, in broad terms, as a

transformation from the “cultural” to the “technological” university.

A further assumption throughout the conception of this project was that, as

ICT projects are introduced into the university system, their consequences are

the outcome of a complex process of negotiation, involving interactions within

a heterogeneous network of actors, artifacts, and systems. Our interest was in

understanding the micro level shaping of new technological systems and the

interactions between these and the wider processes of the university. In this

respect, right from the outset, we considered the design and implementation of

the ERP system to be concerned not only with narrow technical work (such as

the writing of computer code), but also the production of the very university. In

terms of “what” and “who” we looked at, we drew lessons again from the actor

network tradition. In terms of what should be studied, Latour (1987) has

famously advocated that technologies should be studied not as Wnished

artefacts but “in the making”, arguing that, by studying them in this way, the

“messiness” is still there for all to see. By messiness he means not only those

issues identiWed by the researcher but those that arise during the building and

implementation of ICT projects. We studied, therefore, projects as they were

actually being planned, built, and used. In terms of who we studied, Latour

(1987) has also argued that we should “follow the actors” whether they be

human or non-human. In this sense, our focus was directly on the ERP system.

During the research we employed a wide range of qualitative methods,

which included direct and participative observation of “strategy” and technical

meetings and user testing sessions. Within Big Civic, we observed the weekly

“Sponsors group” meetings where day-to-day technical and organisational

decisions were made. The monthly “strategy group” meetings were observed

where issues more relevant to the future direction of the university were the

focus. Project away days, comprising mainly those technical and

administrative staff involved in the actual implementation of the project

were also attended.Within the ERP supplier one testing sessions was observed,

where technical teams and “end-users” from the various pilot and early adopter

sites gathered together to provide input and help shape the software. During

this session, and at a subsequent workshop we also met and talked with

programmers and analysts from the technology supplier as well as staff from

the other participating universities. We were also able to conduct a number of

individual and group-based semi-structured interviews, as well as more

informal discussions with members of the Big Civic technical team and user

community. A number of focus groups were also conducted with the users of

the system. Finally, supporting material, such as meeting notes, e-mail

exchanges and reports were also collected and analysed.

We now turn to Big Civic’s engagement with Enterprise, where we organise

our discussion around various aspects of the system’s biography. First, we

consider how the university (its hierarchy, senior management team, and

various committees) attempted to take customisation decisions. Our argument

here is that these systems complicate this process such that it is difWcult to

avoid implementing a system’s default settings (i.e. accumulated history).

Deferring decisions

When the chips are down and you’ve got to deliver, the collegiate model doesn’t work

(Enterprise Project Director).

When we conducted the Wrst part of our research, Big Civic was in the process

of implementing the Wnancial, human resource and project management

modules, prior to adopting the student management module. As already

mentioned, the implementation was being handled by a project team made up

of university staff and external consultants from small organisations

specialising in the implementation of Enterprise. On a number of occasions,

members of the team met with the “faculty support team” (members of central

departments, such as Wnance, attached to the faculty) and representatives of

academic departments where they were going to pilot the new system. We

directly observed some of these meetings.

During one of the sessions, the consultants had a set of “workXow process

diagrams”, which describe the proposed sequences of events by which tasks,

such as setting up a research account, raising a purchase order or issuing an

invoice, would take place within the new system. Each step of the process was

described in detailed Xow diagrams, indicating which parts of the process take

place “on the system” and which take place “off the system”, as well as

constraints on who can undertake which tasks. Each of the workXow process

diagrams is discussed with the departmental representatives and faculty team.

The aim of the session was to clarify the workXow processes, iron out any

problems which arise, and identify who does what.

As the meeting moves through the workXow diagrams a number of basic

rules of the system are made clear (for example, two separate logins are

required to complete each and every external transaction – the same “login”

cannot order and receive goods). At some points the workXow diagrams are

amended to better reXect the current practice (although this amendment tends

to happen more with “off system” events). At a number of points in the process

it becomes clear that there is more than one way, in current practice, in which a

particular step in the process was being handled. If the issue cannot be resolved

one way or another, the consultant leading the meeting identiWes the issue as “a

matter for policy”, a matter on which a deWnitive ruling must be given by the

university centrally.

What appears to be happening here, as the computer system is

rolled-out is a standardisation of working practices and roles. Moreover, as

Enterprise makes visible the variety of local practices and where these

cannot be reconciled with the system (and thus with each other), this goes

on to generate a constant Xow of “demands for policy”[4]. Indeed from later

interviews with members of the team we know that there were hundreds of

such requests for a central policy decision; these were logged by the team

in a database and passed onto the senior management to resolve. In

principle then, the process not only sees the “tightening up” of roles and

procedures but it also demands a tightening up of policy which will apply

not locally, but across the whole university. We might say that these

customisation procedures involve both the building of a university speciWc

system and the re-building of the university: the roll out of Enterprise is

requiring the simultaneous rollout of a new (and more standardised)

institution to host it (Cornford, 2000).

This “co-production” of system and university is a complex process,

however. As we found out in a later phase, these demands for policy were so

copious that many of the requests simply remained on the database without

senior management ever having the time to deal with them. The committee

overseeing the system roll-out (made up of a number of pro-vice chancellors,

the registrar, bursar, various deans, and senior administrators) met once a

week intending to resolve these demands but, as described by the project

administrator: “the Committee were getting 20 iss