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 issues a week to resolve and

therefore usually did not get past the Wrst or second one on the agenda”. In

other words, as the rollout of the system begins to highlight the variety of local

practices around departments and these cannot be reconciled within the

system, the sheer number of issues generated provides a problem for those

attempting to decide on the future direction of the university. As a result, most

of the issues have to be resolved within the project team on more technical

grounds,meaning the team had to deploy its own criteria while conWguring the

system. And, in many cases, this meant just accepting the default settings

(discussion with project administrator).

Here, then, is a Wrst example of how the status of the university is

distributed: because the committee cannot decide on the details of the system,

responsibility for resolving the decision is deferred and then pushed down to

the project team who, in turn, are unable to do anything other than shift the

decision onto the system itself. What implications does this distribution have

for the university? This question takes us onto a discussion of how the Big

Civic actually began to live with Enterprise, where we suggest that users

developed novel ways to live with the system’s biography.

Translating between two domains

The period following the implementation of Enterprise revealed the extent to

which the new system implied changes in established ways of doing things.

More speciWcally, this period provided insights about how Big Civic

assimilated the “tightening up of roles and procedures” required by

Enterprise’s default settings. As it turned out, university staff found such

assimilation quite “uncomfortable”.

We can say that the system has stretched out across the University – its

terminals, for instance, sit on the desks of several hundred support staffs and

managers across the institution. Yet, its actual integration into people’s

everyday practices has been more equivocal. For instance, many of those based

in the centralised administration departments reported that they “like”

Enterprise and that the system (and its defaults) had become part of their daily

work routines[5]. Nevertheless, for others, especially those in outlying academic

departments, the system has not had the immediate take-up that was initially

anticipated, and still remains “outside” of everyday practices. This was, in part,

a result of the incommensurability of the system with existing and entrenched

practices in departments. Some of the new processes put in place have been

described as “laborious”, “inXexible”, “inadequate” and the “source of much

frustration”[6]. One feature that has been subject to much change is

“procurement”.

Working-around standardised processes

The procurement of goods or services throughout the University ofWcially

commenced with the raising of a “purchase requisition” and this is then

authorised by pre-identiWed individuals. However, this process was often

Xexibly adapted within various departments; non-authorised staff often made

orders over the telephone, and the appropriate paperwork was raised much

later in the process. Under Enterprise this informal practice was proscribed, as

this was not the procurement procedure operating within the system.

Moreover, as a method of enforcing this proscription, the university’s major

suppliers had received written instructions informing of changes to

procurement policy, and that they were to supply goods and services only for

orders detailed on the appropriate paperwork and bearing a “unique order

number”, both of which were generated by Enterprise. The quote below is from

a focus group conducted with support staff directly affected by this aspect of

the implementation. Here, one member of the support staff is describing her

worries in relation to some of these new procedures:

Now when [Enterprise] comes in, the academics are going to have to conform to quite a lot of

rules and regulations that they don’t now. How on earth I am going to get my lot to do it, I do

not know. Whether the centre has realised this, and is just not telling us what they are going

to do about it, whether they are just going to trust to luck and hope that it works I just don’t

know. But, I am quite concerned about that. I mean it does create bad feeling if you are saying

to somebody: “Look you just can’t just make an order of the phone; I won’t pay for it if you do.

It must come through the ofWce, that’s the system” . . . And I can see that they are going to

start screaming, as soon as I say to them: “Sorry, you can’t do that anymore you have got to

do that now, that’s what the system is supposed to do”.

Indeed, while support staff have pushed through many of these new rules, in

many instances we also found many of the most inXexible processes were often

ignored or “worked-around”. In one instance, and we do not imagine this is the

only case, we observed how staff in one research centre developed “strategies”

to live with the new procedures. As in other departments, procurement

procedures here were often Xexibly adapted to deal with urgent problems, such

as the need for a travel ticket. Once Enterprise was implemented, this Xexibility

was no longer possible and this created problems. If the centre administrator

was unavailable, which often happened, the other staff did not have an

appropriate “login” or “user proWle”, and thus could not generate the

paperwork when it was required. To circumvent this, a copy of the Enterprise

order form was designed on a word-processor (available to print out at any time

by the remaining support staff) and this was adorned not with the Enterprise

order number but with what the staff called a “pseudo number” or “Secretarial

requisition number”. Tickets could thus be ordered and the correct paperwork

dealt with at a later date.

Janus-faced users

What does this tell us about what is going on? At one level, described here is a

practice known and well understood within the sociology of science and

technology and other allied disciplines – implementation would not be possible

without numerous ad hoc modiWcations (see Gasser, 1986; Trigg and Bodker,

1994; Star, 1995; Ciborra, 1999). This said, at another level such work-arounds

indicate the nature of Enterprise and its relationship to the university (see

Appadurai, 1992; Kopytoff, 1992). True, the system has been “fully”

implemented within the university, but for many people (i.e. the majority of

academic staff, for instance) many procedures have carried on as before.

Pivotal to this is the inter-mediation role undertaken by certain users, typically,

administrative staff working at the “interface” between old and new ways of

working. Under Enterprise, these staff have become “Janus faced” (see Latour,

1987), facing both the Enterprise system and their academic colleagues at the

same time[7]. As long as these workarounds are maintained, the departments,

for all the central university knows, are working according to the new

procedures, and, equally, as those out in departments see it, traditionalmethods

carry on much as before.

In summary, through the added work of maintaining a system that does not

reXect the department’s working practices, various users are obliged to

translate between, we might even say “perform”, their speciWc part of the

university to the system, and, simultaneously, translate the system back to

departments. These users, in other words, bear the burden of reconciling the

tension between universities as unique organisations and as generic

organisations – what we might describe as a process of pretending to live

with defaults. This leads us to ask the question Could it have all been

otherwise? Might not the university have found a better way to manage the

implementation or, indeed, procure software more suitable to its particular

setting? These questions take us onto the Wnal two empirical sections and

considerations of the building of the Campus management module.

Where do defaults come from?

Thus far we have looked at the system according to the way in which the

University is forced to implement and live with defaults, but as yet we have not

discussed in any detail where these defaults come from. The biography of

Enterprise systems, to recap, are based on the practices and processes of many

different organisations, and, because of this, they are often described as

embodying “best business practice”. One element that is not available within

Enterprise, however, is templates for one of the core functions of universities:

the management and administration of students. In recognition of this, the

suppliers are currently developing new functionality that can be integrated into

Enterprise, a module called “Campus management”, which will hold data about

student records. Big Civic, along with a number of other “pilot sites” from

around the world, were involved in the shaping of this new software.

The “self-service” student

What is interesting about the design of the student module is that it is

conceived around the idea that students are to move from being passive objects

of administration to becoming one of the main groups of “active users” (for

more details see Pollock, 2003). This draws on a model that the supplier refers

to as the “self-service” student:

For students, self-service functions improve the quality of information and ease the burden on

administrative staff. Instead of having to wait for appointments and documents in long lines

by the Wnancial aid and admissions ofWces, students will be able to access a wide variety of

services at Campus Management’s electronic kiosks (intranet) or from their residence hall via

the internet. Additional services will also be provided, for example, students can apply for

on-campus housing, request additional balances on their tuition, inquire about their current

academic standing and look-up facility changes for current classes – all over the intranet

(Supplier brochure).

This raises the following questions: if students are to be one of the system’s

primary groups of users, then, how did designers understand their role and

identity, as well as their relationship to the university and its staff? Moreover,

in conceptualising the student as a user, were they to assume that students had

the same competencies, needs and interests as, say, an employee working

within a commercial organisation, the typical user of the Enterprise system?

How, in other words, did they manage this difference between the typical users

of the Enterprise system and the student as a unique type of user. Indeed, was

there a difference[8]?

As part of the process of learning about students, a requirements analysis

phase was conducted. This entailed a series of visits to pilot universities where

key actors were interviewed and observed while carrying out their work. In

addition to this, hundreds of questionnaires were dispatched, asking more

speciWc questions about system access for those students based on campus,

what information was relevant to them, what they could and could not see, and

so on. In other words, in developing this new functionality there is a recognition

that universities are not, after all, like other organisations. And, in this sense, it

is not accurate to simply say that universities face problems common to other

organisations. Clearly, within the biography of the Enterprise system there is

no element to deal with the speciWc issue of students.

No default, however, is completely remade anew. Even though the suppliers

are in the process of designing and writing software for the new student

module, “new” is meant in a loose sense here. The module was in fact a

reworked version of the “Training and events management module”, a system

used to run internal training programmes within commercial organisations,

and the “Real estate module”. As such, Big Civic found many aspects of the

software incompatible with existing institutional structures, processes and the

characteristics and identities of actors. In one part of the system adapted for the

management of accommodation on campus, for instance, the student was in

effect conceived of as a special type of employee, one who was undertaking a

long-term training course and thus permanently renting a room. University

staff rejected this conceptualisation pointing out that it did not capture the

complexity of the student-university relationship; at some pilots, for instance,

students do not “rent” rooms but receive accommodation as part of wider aid

packages:

Until now the Real Estate module has always been referred to for student housing. This only

contains the functionality to “let” rooms (very commercial). For some universities this is not

enough. Student rooms are often part of student aid. A lot of extra activities have to be

organised in association with this (e.g. meals) (e-mail from a Belgium University involved in

piloting Campus Management).

Examples such as this led to tensions among prospective users, some of whom

described the system as simplistic and overly commercial. In terms of the

supplier’s understanding students are something of a “residual category” (see

Bowker and Star, 1999), in that they do not Wt any of the available templates.

On the one hand, there is an explicit recognition that universities are different:

they have components not found in other organisations (students). On the other

hand, there is also a feeling that, at a basic level there are lots of similarities,

that students are, or should be, or could be made to be, very much like the more

familiar (to the supplier) category of employee. More generally, we might say

that despite this recognition that students (and thus universities) are different,

they are, nevertheless, always being rolled back towards a default, i.e. the

biography of Enterprise appears to win through.

The dual requirements of local and global application

There is one more aspect that we wish to expand on here and this is how in the

initial stage of Campus management’s biography, the aim was to build a

module that met the dual requirements of local and general applicability. In

other words, the module was intended for Big Civic, the other pilot sites and, in

the near future, the idea was to market the package around the world to other

institutions. In order to do this, the supplier regularly tested the system with

the pilots and early adopters so as to ensure that all the needs of the

participating universities had been captured. For this testing, university

personnel would periodically travel to an arranged venue where they would sit

in a large classroom and work through test versions of the system. We

observed one such meeting (see Pollock et al. (2003) for a more detailed

discussion). Most of the session was devoted to demonstrations of new

software, with consultants asking for comments whether this or that aspect of

the system was appropriate to each institution. A second aim was to ascertain

the particular needs of each university and, if possible, to translate these into a

set of “common needs” or functionality that was relevant to all sites. Such a

process was extremely difWcult, however. From the discussion, it was clearly

evident that the pilot universities each had very different ways of doing things.

Indeed the participants were becoming increasingly frustrated by the supplier’s

attempts to understand each and every difference among all the universities

present and to reconcile these with the needs of the others present.

For the suppliers, such a process is useful as it allows the default to become

more robust and, thus, applicable to the widest variety of higher education

institutions. For the pilots, the process, while drawn out, appeared to be

similarly useful as it ensured that all of those present would be able to Wnd their

own unique solution within the standard module.

In a later stage, however, a process of closure begins to set in around the

extent to which each pilot could continue to shape the module. In contrast to the

search for common needs conducted during the workshops, each time a

university now makes a request the supplier rejects it on the grounds that it is

functionality that is needed by one university and therefore cannot be included

in the common system. Low Country University, for instance, reports in a series

of e-mails to the other pilots how:

We have the feeling that it’s becoming a strategy to try to label issues as “university speciWc

until proven differently”. Should it not be the other way around? Should [the supplier] not

search for generic concepts behind the speciWc situations at the different pilot universities?

Moreover, it had recently been announced by the supplier that there were to be

no more pilot workshops as they were becoming time consuming and not

wholly productive (see Pollock et al., 2003). Therefore, it was becoming

increasingly difWcult for the universities to prove their needs were not simply

speciWc to one university:

Now we have to prove that we are not the only one needing something, and that is not easy if

we don’t come together anymore in workshops.The basic concepts seem to be Wxed (based on

past roll-in?), and “sacred”. Everything that doesn’t Wt in is “speciWc”. An example of this is

timetables per programand per stage. This is labelled as “[Low Country University] speciWc

reporting issues”, although we see them also on the websites of [Big Civic] and [New Town

universities].

In order to prove their needs were more generally required, they begin to look

for commonalties with other universities by checking Web sites, holding

discussions during testing sessions, and so on. One strategy discussed by some

pilots was to negotiate individually with the supplier – but this presented some

further dangers. If the universities were to build Campus management around

their own speciWc needs, this would lead to difWculties in the future:

If from now on they only talk separately to each university and look for solutions for their

speciWc situation, my fear remains that we will all end up with separate products, and we can

start planning a “back to the standard” project after a couple of years.

In other words, they want a system that matches their current practices but at

the same time they increasingly became aware that ending up with a “separate

product” would be counterproductive. Would their customised version be

supported? Could they make use of later upgrades? The answer, they fear, is

probably “no”.

Here we see how the development of Campus management has pushed the

discussion of the identity of the university fromone where the issue was simply

the extent to which they were similar or different from other organisations, to

one where the question concerns the similarities among universities

themselves? In other words, the university formulated their needs with one

eye on their own institution and the other on the “standard product”. Indeed,

this gave rise to a new form of similarity relation where they recognise the need

to identify commonalties among the group of universities participating in the

development of the system.

Conclusions

It is clear that there are “fuzzy” or unclear boundaries between universities and

other kinds of organisations, and while it is widely accepted that they engage in

many of the same activities as others, they are still thought of as something a

“bit different”. Rather than try to put forward a deWnitive account of the

identity of the university, we have described how ERP systems create tensions

regarding this unique identity. The article has focused on how responsibility

for the resolution of this similarity relationship is distributed during attempts

to customise the system. Once we pay attention to these processes it is possible

to see how (and where) such issues are resolved. In particular, we have

emphasised the antagonistic as well as contingent nature of this process of

customisation – i.e. the extent to which their successful realisation of

differences and similarities depends on the struggles of various actor-networks

– using notions such as translation and biography.

Central to the whole process was the pro vice chancellor in charge of the

project, whose initial goals were to make the university less organisationally

speciWc through emphasising the similarities between the structures of

universities and multi-national companies, and through importing the best

business practices embodied within the system. As a result, there was thus a

general pressure for staff to rethink many of the existing procedures and

concepts according to new business process terms and Enterprise terminology,

even when such a process caused confusion and irritation.

While there was often recognition of the speciWcity of universities, this was

difWcult to realise and decisions regarding customisation were often deferred or

distributed. First, Enterprise threw up so many “demands for policy”, that

implementation decisions could never be properly discussed among the

overseeing committee, and they were thus pushed down to technical teams and

then onto the system itself. In other words, change (in the sense of this

realisation of the university’s identity) often occurred through a process of

default rather than choice. This suggests that university decision-making

processes Wnd it difWcult to resolve similarity relationships.

Second, the burden of resolving these conXicts is then passed onto the users.

The proliferation of work-arounds was one example of the distribution

processes underway as users attempted to bare the burden of reconciling the

universities idiosyncratic practices with the generic practices embodied within

the system. Third, where Enterprise could be customised, we found that this

was increasingly at the level of the sector. With the development of Campus

management a university’s speciWc needs would be incorporated only if they

could be proved to be common to the others involved in shaping the new

module. Also, there were concerns about ending up with a product that was too

far from the standard (and therefore unable to make use of the beneWts of

packages such as upgrades and the release of new functionality). The

universities, in other words, were increasingly forced to think as a

“community” or “sector” when identifying their needs. This has obvious

implications for organisational shaping (see below) as well as future

procurement strategies, where presumably the university will have to

negotiate and struggle both with suppliers and other higher education

institutions.

We have identiWed that if universities are to make the most of standardised

software they must learn to manage a number of complicated translation

processes. This concerns the biography and history of these systems and the

tendency to implement defaults (the “power of default”). The beneWts of the

biography approach is that it pays particular attention to the similarity

relationships that accompany ERP systems, and the way suppliers,

consultants, implementers etc., attempt to render the institutionally diverse

organisationally similar. Of course, we must add that these dynamics are

hardly unique to ERP or, for that matter, universities. Translating generic

software while avoiding translating organisations is a tension that many

implementation teams are attempting to manage (Pollock et al., 2003).

Moreover, the manner in which such tensions are framed and resolved can have

detrimental effects on institutions (i.e. in terms of unwanted organisational

change and the process Powell and DiMaggio (1991) have described as

institutional isomorphism). These are, to be sure, difWcult problems and not

ones that will go away. In summary, the process of adopting these forms of

systems will clearly highlight and refashion, the boundaries between

universities and other types of organisations, and what the university

understands its uniqueness to be. We wonder, to use the sentiments expressed

by one member of the implementation team excited by the future possibilities

that the system might offer, to what extent is Big Civic now beginning to think

its uniqueness is centred on the fact that it now has an Enterprise system[9].

Notes

1. For a useful discussion of actor network theory and the construction of identity, see Michael

(1996).

2. This discussion of “distribution” is drawn from research on the ambiguities surrounding

childhood (Lee, 1999) and the use of non-lethal weapons by the British police force (Rappert,

2001). The ideas presented in these papers are equally applicable to the tensions surrounding

the identity of the university.

3. In this respect the notion of biography shares some characteristics with Bruno Latour’s

(1999) concept of “chains of transformation”, where changes to the technology might be seen

as the actors leaving behind, and the selective carrying forward, of certain aspects of the

system biography. For more discussion of the biographies approach, see Pollock et al., 2003)

4. Hanseth and Braa (2000) make a similar point by arguing that ERP systems “create issues”

that have to be resolved.

5. This was one of the Wndings from an internal review of Enterprise commissioned by the

University’s management team.

6. These were Wndings from the same internal review.

7. Latour employs the notion of the Roman God “Janus” to describe the two faces of science and

technology: one where techno-science, to use his term, is depicted as a “black-box” where all

the uncertainty and controversies are hidden; the other where conXicts and tensions are

brought into the open. Scientists, he argue, continually switch between these two views.

8. For a discussion of the identity of students, see Silver and Silver (1997).

9. This was an observation from one project team meeting where the discussion centred on the

current review of the student ofWce, where the registrar (and others) were carrying out

research to compare themselves with the practices and procedures in student ofWces

elsewhere. For one member of the project team this seemed nonsensical: “What they are

doing is looking at other universities, but it will not be accurate becausewe have [Enterprise

and the Student Module] and no other [British] university has that – we are unique!”

References

Appadurai, A. (Ed.) (1992), The Social Life of Things: Commodities in Cultural Perspective,

Cambridge University Press, Cambridge.

Balderston, F. (1995), Managing Today’s University: Strategies for Viability, Change and

Excellence, Jossey-Bass Publishers, San Francisco, CA.

Bansler, J. and Havn, E. (1996), “Industrialised information systems development” CTI Working

Paper No. 22, Technical University of Denmark, Lyngby.

Bowker, G. and Star, S. (1999), Sorting Things Out: ClassiWcation and its Consequences, MIT

Press, Cambridge, MA.

Brady, T., Tierney, M. and Williams, R. (1992), “The commodiWcation of industry applications

software”, Industrial and Corporate Change, Vol. 1 No. 3, pp. 489-514.

Callon, M. (1986), “The sociology of an actor-network: the case of the electric vehicle”, in Callon,

M., Law, J. and Rip, A. (Eds), Mapping the Dynamics of Science and Technology, Macmillan

Press, London.

Ciborra, C. (1999), “Notes on improvisation and time in organisations”, Accounting, Management

and Information Technologies, Vol. 9, pp. 77-94.

Ciborra, C. (2000), From Control to Drift: The Dynamics of Corporate Information

Infrastructures, Oxford University Press, Oxford.

Cooper, R. and Law, J. (1995), “Organization: distal and proximal views”, Research in the

Sociology of Organizations, Vol. 13, pp. 237-74.

Cornford, J. (2000), “The virtual university is . . . the university made concrete”, Information,

Communication and Society, Vol. 3 No. 4, pp. 508-25.

Cornford, J. and Pollock, N. (2003), Putting The University Online: Information, Technology, &

Organisational Change, Open University Press, Milton Keynes.

Cunningham, S. et al. (1998), “New media and borderless education: a review of the convergence

between global media networks and higher education provision”, Australian Government,

Department of Employment, Education, Training and Youth Affairs, Evaluations and

Investigations Programme, Higher Education Division, available at:

www.deetya.gov.au/highered/eippubs/eip97-22/eip9722.pdf

Davenport, T. (1998), “Putting the enterprise into the enterprise system”, Harvard Business

Review, Vol. 76 No. 4, pp. 121-32.

Davenport, T. (2000), Mission Critical: Realising the Promise of Enterprise Systems, Harvard

Business School Press, Boston, MA.

Gasser, L. (1986), “The integration of computing and routine work”, ACMTransactions on OfWce

Information Systems, Vol. 4, pp. 205-25.

Hanseth, O. and Braa, K. (2000), “Technology as traitor: emergent SAP infrastructure in a global

organisation”, in Ciborra, C. (Ed.), From Control to Drift: The Dynamics of Corporate

Information Infrastructures, Oxford University Press, Oxford.

Heiskanen, A., Newman, M. and Simila, J. (2000), “The social dynamics of software

development”, Accounting, Management & Information Technologies, Vol. 10, pp. 1-32.

Koch, C. (1999), “SAP R\3 – an IT plague or the answer to the tailor’s dream?” working paper,

Institute for Technology and Social Science, Technical University of Denmark, Lyngby.

Kopytoff, I. (1992), “The cultural biography of things: commoditization as process”, in

Appadurai, A. (Ed.), The Social Life of Things: Commodities in Cultural Perspective,

Cambridge University Press, Cambridge.

Latour, B. (1987), Science in Action, Harvard University Press, Cambridge, MA.

Latour, B. (1988), The Pasteurization of France, Harvard University Press, Cambridge, MA.

Latour, B. (1999), Pandora’s Hope: Essays on the Reality of Science Studies, Harvard University

Press, Cambridge, MA.

Law, J. (1994), Organising Modernity, Blackwell, Oxford.

Lee, N. (1999), “The challenge of childhood: distribution of childhood’s ambiguity in adult

institutions”, Childhood, Vol. 6 No. 4, pp. 455-74.

Light, B. (2001), “The maintenance implications of the customisation of ERP software”, Journal of

Software Maintenance and Evolution, Vol. 13, pp. 415-29.

Lockwood, G. (1985), “Universities as organizations”, in Lockwood, G. and Davies, J. (Eds),

Universities: The Management Challenge, NFER-Nelson Publishing, Windsor.

Lozinsky, S. (1998), Enterprise-Wide Software Solutions, Addison-Wesley, Reading, MA.

McNay, I. (1995), “From the collegial academy to corporate enterprise: the changing cultures of

universities”, in Schuller, T. (Ed.), The Changing University?, Open University

Press/SRHE, Buckingham, pp. 105-15.

Markus, M., Axline, S., Petrie, D. and Tanis, C. (2000), “Learning from adopters’ experienceswith

ERP”, Journal of Information Technology, Vol. 15, pp. 245-65.

Michael, M. (1996), Constructing Identities, Sage, London.

Parr, A. and Shanks, G. (2000), “A model of ERP project implementation”, Journal of Information

Technology, Vol. 15, pp. 289-303.

Pinch, T. (1993), “`Testing – one, two, three . . . testing’: towards a sociology of testing”, Science,

Technology, & Human Values, Vol. 18 No. 1, pp. 25-41.

Pollock, N. (2000), “The virtual university as timely and accurate information”, Information,

Communication & Society, Vol. 3 No. 3, pp. 349-65.

Pollock, N. (2003), “The `self-service’ student: building enterprise-wide system into universities”,

Prometheus, Vol. 21 No. 1, pp. 101-19.

Pollock, N. (n.d.), “Mis-using the software or the tension of work-arounds: how programmers

negotiate the use of a technology”, paper submitted to Science, Technology, & Human

Values.

Pollock, N., Williams, R. and Procter, R. (2003), “Fitting standard software packages to

non-standard organisation: the `biography’ of an enterprise-wide system”, Technology

Analysis & Strategic Management, Vol. 15 No. 3.

Powell, W. and DiMaggio, P. (Eds) (1991), The New Institutionalism in Organizational Analysis,

University of Chicago Press, Chicago, IL.

Rappert, B. (2001), “The distribution and resolution of the ambiguities of technology, or why

Bobby can’t spray”, Social Studies of Science, Vol. 31 No. 4, pp. 557-91.

Readings, B. (1996), The University in Ruins, Harvard University Press, Cambridge and London.

Scott, J. and Kaindl, L. (2000), “Enhancing functionality in an enterprise software package”,

Information & Management, Vol. 37, pp. 111-22.

Scott, S. and Wagner, E. (in press), “Networks, negotiations, and new times: the implementation

of enterprise resource planning into an academic administration”, Information and

Organization.

Silver, H. and Silver, P. (1997), Students: Changing Roles, Changing Lives, SRHE & Open

University Press, Milton Keynes.

Star, S.L. (Ed.) (1995), Ecologies of Knowledge: Work and Politics in Science and Technology, State

University of New York Press, New York, NY.

Tierney, M. and Williams, R. (1991), “Issues in the black-boxing of technologies”, Edinburgh

PICT Working Paper No. 22, Edinburgh University, Edinburgh.

Trigg, R. and Bodker, S. (1994), “From implementation to design: tailoring and the emergence of

systematization in CSCW”, Computer Supported Cooperative Work, Vol. 10, pp. 45-54.

Walsham, G. (2001), Making a World of Difference: IT in a Global Context, Wiley, Chichester.

Weick, K. (1976), “Educational organisations as loosely-coupled systems”, Administrative

Science Quarterly, Vol. 21, pp. 1-19.

Williams, R. (1997), “Universal solutions or local contingencies? Tensions and contradictions in

the mutual shaping of technology and work organization”, in McLoughlin, I. and Harris,

M. (Eds), Innovation, Organizational Change and Technology, ITB Press, London,

pp. 170-85.