How to live with ERP systems and thrive

David Jones

Teaching and Learning Innovation Officer

Faculty of Informatics and Communication

Central Queensland University

Abstract

In the late 1990s many Australian Universities went through the process of chosing,

acquiring and implementing Enterprise Resource Planning (ERP) Systems. This paper

offers one example of how the Faculty of Informatics and Communication (Infocom) at

Central Queensland University (CQU) has learned to live and thrive with CQU’s ERP

system. This has been achieved through the use of an emergent development

methodology to create a range of intermediary information systems that bridge the gap

between CQU’s ERP system and the requirements of Infocom’s staff and students. Using

specific examples the paper identifies a range of technical (bad technology, lack of

technical knowledge, requirements mismatch and limited integration support) and

organisational (system owner/user mismatch, organisational holes, organisational silos,

developer/user distance, system/structural inertia) factors that help create this gap. The

resulting intermediary information systems are used by hundreds of staff and thousands

of students, offer significant advantages and enable further innovation. The paper

suggests that the gap between institutional information systems and client requirements,

exists in most Universities.

Introduction

Over recent years the acquisition, implementation and use of Enterprise Resource

Planning (ERP) Systems has become a standard feature of most Australian Higher

Education institutions. To date most of the literature on ERP implementation in the

Australian Higher Education sector has focused on the early stages of the ERP lifecycle:

adoption decision, acquisition and implementation. This paper tells the story of how the

Faculty of Informatics and Communication (Infocom) at Central Queensland University

(CQU) has learnt to live (use and maintenance) and thrive (evolution) with CQU’s ERP

system.

ERP systems are “commercial software packages that enable the integration of

transaction-oriented data and business processes throughout an organization” (Markus,

Axline et al. 2001). ERP systems provide cross-organisation integration through

embedded business processes and are generally composed of several modules including

human resources, sales, finance (Esteves and Pastor 2001) and, in the case of

Universities, student administration. During the 1990s ERP systems were the de-facto

standard for replacement of legacy systems in large companies (Parr and Shanks 2000).

The impact of ERP systems is so broad, touching many aspects of an organizations

internal and external operations, that the successful implementation and use of these

systems are critical to organizational performance and survival (Markus, Axline et al.

2001). Indeed, the failure of some ERP system implementations has lead to

organizational bankruptcy (Davenport 1998; Markus and Tanis 2000).

In 1998, Central Queensland University issued a Request for Proposal (RFP) for the

provision of a new administrative information system (Central Queensland University

1998). As a result of a selection process, the PeopleSoft ERP was adopted and

implemented over a period of approximately three years. The final product consisted of

the complete student system and most of the finance modules, excluding Accounts

Receivable. While the original plan included the implementation of the Human Resource

Modules, this phase has been suspended indefinitely. The implementation went over

time by several months, was missing promised functionality and was over budget on

completion. Under the traditional success/failure models, this implementation would be

categorised as a failure (Standish Group 1995; Mahaney and Lederer 1999; Whittaker

1999).

This paper seeks to show that gaps exist between institutional information systems, like

ERP systems, and the needs of the members of the organization. It starts by providing a

brief introduction to Infocom, its web development team and the notion of institutional

information systems. The main section of this paper describes four of the numerous

information systems developed by the Infocom web team and uses these systems to

highlight the gap between the relevant institutional information systems and the factors

which create that gap. Lastly the paper briefly describes the process and technology used

to develop the Infocom intermediary information systems.

Infocom and Institutional Information Systems

While ERP systems are the generally the most expensive institutional information system

implemented by most institutions over recent years they are not alone. At most Australian

Universities there are other information systems filling organisational needs that an ERP

systems do not address. Course management systems (CMS), such as WebCT and

Blackboard, are usually the next most expensive and far-reaching example. Other

institutional information systems may include: timetable management software,

assignment tracking software, bookshop management software, library catalogue systems

and various infrastructure systems such as student and staff authentication. While the

title of this paper mentions ERP systems the basic premise of this paper is that a gap

exists between the functionality of all institutional information systems and the needs of

the staff and students.

The Faculty of Informatics and Communication (Infocom) is one of five faculties at CQU

and includes disciplines as diverse as Mathematics, Information Technology, Information

Systems/ECommerce Each faculty consists of a number of schools, is led by an

executive Dean and has reasonable freedom in its allocation of funds. CQU’s students

study via a number of different modes including:

• CQ Campus – traditional on-campus study at CQU’s Central Queensland campuses in

Rockhampton, Bundaberg, Gladstone, Mackay and Emerald.

• Distance Education/Flexible Learning – mostly print-based distance education

supplemented with online learning and a small number of residential schools.

• Australian International Campuses (AIC) – CQU’s “campuses in a building” in

Brisbane, the Gold Coast, Sydney and Melbourne servicing primarily full-fee paying

international students.

• Overseas ventures – a range of ventures in Hong Kong, Singapore, Malaysia, Fiji and

China.

Over recent years Infocom has taught about 30% of all CQU students. Table 1 provides

a summary of Infocom’s student/course enrolments in 2002.

Mode Student/Course Enrolments

Table 1 – Infocom 2002 student/course enrolments
CQ 2496 (13.62%)

Flex 3813 (20.81%)

Overseas 1835 (10.02%)

AIC 10178 (55.55%)

Total 18322

Since 1997 Infocom has had a small web team responsible for the development of

information systems, mostly web-based, designed to support Infocom’s complex

operations. That team has grown from a webmaster and a part-time developer (1997 to

2001) into a team with three permanent developers, 1 developer contracted until the end

of 2003 and a webmaster. The work described in this paper is based on the activities of

the Infocom web team.

Problems, Solutions and the Gaps

The basic premise of this paper is that there exists a gap between the functionality

provided by institutional information systems and the needs of students and staff. The

paper proposes that the development of intermediary information systems can help

overcome this gap and provide significant advantages. This section describes four of the

many intermediary information systems developed by the Infocom web team.

The examples discussed below are:

1. Web-based Student Records –provides staff with access to student records data

including course lists, student photos, and student enrolment details.

2. Timetable generator – a web application that allows a student or staff member to

generate a personal timetable.

3. Minimal course presence – the provision of a consistent minimal web site for every

course offered by Infocom independently of academic staff and as early as possible.

4. Informal Review of Grades (IROG) – web-based processing of student requests for an

informal review of a final grade.

Each example will include four common sections: requirement, CQU system, Infocom

System and Sources of the Gap.

Student Records

Requirement

Both academic and general staff need regular access to the data contained in the student

records system for a range of purposes including: checking enrolment and graduation

status, viewing student photos to match name and face, generation of CSV files for

storing assessment results, accessing student contact information and many more.

CQU System

CQU’s ERP implementation does provide both academic and general staff with access to

CQU’s student records system. However, this system suffers a number of problems

including:

• Time consuming.

As documented in the relevant user documentation the process for retrieving a single

course list involves a 26-step process requiring the use of two separate applications.

One application, a Microsoft Windows application, is used to request the class list

(report). A second application, a Web browser, is used to access the report

architecture and retrieve the list. The entire process is reported to take some staff

close to 20 minutes.

• Confusing and difficult.

The need to use two separate applications for a single task is confusing to many staff.

The process is made more difficult due to the requirement for staff to be aware of

various “codes” which are specific to the technology and not in normal everyday use.

One example of this is the use of four digit code to represent a particular term (see

explanation below). There are at least three other parts of this process that require

users to bridge a similar semantic distance.

Terms and the 4 digit term code.

CQU currently has five terms which are known by staff and student as: summer

(T1), autumn (T2), winter (T3), spring (T4) and spring/summer (T5). CQU’s

student record system uses a 4 digit code to indicate both year and term. The 4

digit code uses the format CYYT where

• C – is a single digit representing the century (1 – 1900, 2 – 2000).

• YY – are two digits representing the year.

• T – a single digit representing the term.

As a result, 2032 = Term 2, 2003. 1995 = Term 5, 1999.

• Geographic Restriction.

The Microsoft Windows client used in the first step can only be used from computers

located on the CQU network. This poses problems for CQU’s overseas commercial

partners and staff travelling outside CQU. Any new commercial ventures based

outside CQU’s network are unable to easily access CQU’s student records system.

• Platform restriction.

Users of alternate computing platforms (e.g. Apple, Linux etc) are generally unable to

use the Windows client. In addition, due to limitations in the Peoplesoft tools only a

certain limited range of Microsoft’s Windows operating systems are supported. As a

result decisions about new computing platforms is being restricted by a single

application.

• A step backwards.

The locally produced student records system replaced by Peoplesoft provided staff

with Web-based access to student records data. This system addressed all of the

above problems. In adopting Peoplesoft this functionality was lost and as a result

many staff perceive Peoplesoft as a step backwards.

Due to the above problems most academic staff do not make direct use of CQU’s student

records system. Any requirements for information from student records are sent to

support staff, employed by the faculties, who do use the student records system.

Infocom System

Since late 2001 Infocom has provided a Web-based interface to student records as part of

its staff portal, MyInfocom. The system provides quick and simple access to student and

course information that can be accessed from any location and any computer platform

where there is a Web-browser and an Internet connection.

The Infocom systems takes between 2 and 4 steps to generate a class list depending on

whether you are using the Infocom specific or the generic CQU version. This is because

the Infocom specific system is able to draw upon the Infocom teaching responsibilities

database to automatically show Infocom staff details about courses they are teaching.

There is no CQU database that tracks teaching responsibilities.

As Infocom’s staff portal MyInfocom also provides access to other information systems

including: online assignment submission and marking, results processing, minimal course

sites and informal review of grades. Use of MyInfocom, or MyCQU it’s Infocom

produced CQU cousin, requires little or no training. Experience has shown that the most

difficult step in using MyInfocom has been in learning how to download a CSV file form

the system and get it into Microsoft Excel.

In late 2002 Infocom produced MyCQU a version of MyInfocom without the Infocom

specific features. MyCQU was designed to be used by staff in faculties other than

Infocom.

Sources of the Gap

Contributing factors to the gap between the CQU system and the requirements of the

clients include:

• “Bad” technology.

CQU’s systems reliance on a client/server application demonstrates all the problems

of that approach including platform and geographic restrictions. In addition the design

of the client application is poorly done in that it requires staff to provide information

they don’t normally know and requires a significant number of steps and time. The

poor quality of this design is due in part to a lack of technical knowledge but the

largest factor is the restrictions placed by the nature of the technology.

• Technological inertia.

By 1999, and arguably much earlier, the IT development world had recognised the

limitations of the client/server model and the fact that Web-based systems addressed

these problems. However, due to the complexity of ERP systems, and the inertia that

brings, Peoplesoft was only starting to develop Web-based versions of their product at

the time of CQU’s ERP implementation. In addition, the complexity of implementing

the ERP at CQU means that there must be a long period of use of the client/server

system in order to recoup costs before migration to Peoplesoft’s web version.

• Organisational holes.

CQU currently does not have a central database that tracks which staff are teaching

which courses. Parts of CQU (e.g. Infocom) and some of CQU’s commercial

campuses, have filled this hole.

• Developer/User distance.

There exists a large geographic and organisational distance between the users and the

developers of the CQU system. This means that it is very difficult for the developers

to develop a true understanding of how their system is being used and whether or not

there are problems to fix. This distance has been increased by the negative feelings

amongst CQU staff about the ERP implementation and the resulting defensiveness of

the staff involved in the implementation and support of the CQU ERP system.

• Organisational inertia through band-aid solutions.

It was obvious to most CQU staff that there wasn’t going to be any quick solution to

the problems discussed above. As a result CQU staff developed alternate methods for

solving these problems. Infocom developed intermediary information systems. Other

sections of CQU allocated support staff the task of retrieving data from the student

records system in response to organisational needs. Once these workarounds began to

function they were accepted as part of normal operation and feedback to the

developers of the CQU system declined. This has led to the situation where the

developers believe that there are limited problems with the system and thus the

chances of future improvement are further reduced.

Personal Timetable

Requirement

At the start of each term both staff and students need to generate a personal timetable

which indicates the time and place of each of their classes.

CQU System

Due to differences in CQU’s organisational structure there is no single CQU timetabling

system. The timetable for CQU’s Central Queensland based campuses is currently

managed using a commercial timetabling package. The timetable at CQU’s commercial

campuses in Sydney and Melbourne use a locally produced Web application based on

Access databases. CQU’s other commercial campuses, Brisbane, the Gold Coast and

Fiji, along with its commercial partners in Singapore and Hong Kong use other locally

specific methods, often based on Excel spreadsheets.

The Sydney and Melbourne campuses make timetabling data available via a simple webbased

application that allows students to select individual courses and view the time,

place and staff member involved.

Timetabling information at CQU’s Central Queensland campuses is made available as

static HTML pages (http://www.cqu.edu.au/studinfo/admin/timetabline/) divided by

campus and then by faculty. The web page for each faculty at each campus lists the

details of all the classes for all the courses offered by that faculty at that campus in the

given term. To generate a personal timetable it is necessary to know which faculty owns

the course, navigate to the appropriate page, manually search amongst all of the courses

for those of interest and manually transpose that to a personal form. The pages are also

printed out and placed onto noticeboards by the various faculties. Many students make

special trips out to the campus before the start of term to gather timetable details.

Problems with the CQU systems include:

• No single source.

Depending on their mode of study students must know to go to different places.

• No integration with student records.

So the system has no knowledge of each student’s enrolment details and thus can’t

provide a personal timetable. Instead the student is forced into a manual process.

• Absence of teaching responsibilities database.

As mentioned above there is no central database which tracks which staff teach which

course. Even if one were present the current CQ timetabling commercial system

would be unable to use that data to generate a personal timetable for staff.

• Requirement for additional knowledge.

Many students, especially first years, do not understand the notion of faculties let

alone know which faculty owns a specific course. The current CQ system requires

students to know this information in order for them to generate their timetable.

• Time consuming.

The manual search and transpose steps make this process quite time consuming and

error prone.

Infocom System

The Infocom timetable generator (http://www.infocom.cqu.edu.au/Timetable/) provides

two different methods for generating a personal timetable.

1. Manual Selection.

After choosing their campus users can select courses from the list of courses at

that campus and hit submit to see a weekly timetable.

2. Automatic Selection.

Selecting the link “Generate My Timetable” and entering their username and

password will show staff or students a personalised timetable based on the

enrolment or teaching responsibilities.

The Infocom system can generate timetables for students at all of CQU’s Central

Queensland campuses and CQU’s Sydney and Melbourne campuses. It does this by

extracting the data from the web pages and databases of these other systems, placing

them into a single database and combining them with data in CQU’s student records

system and Infocom’s teaching responsibilities database.

The Infocom Timetable Generator was first made available in 2001 and supported only

the Rockhampton campus and manual selection of courses. The system was used over

3000 times in 2001. In 2002, due to workloads and changes in data formats used by the

central timetabling pages the system was not actively supported. It was used 321 times.

Support for all campuses and the automatic selection method was implemented in mid-

2003. It has been used over 1500+ times up until July 27, 2003.

Sources of the Gap

Contributing factors to the gap between the CQU system and the requirements of the

clients include:

• Mismatch between system owner and users.

The system owner of the CQ timetabling system is CQU’s student administration

division. Their major timetabling role is managing the allocation of space and time.

Distributing this information to staff and students is a secondary smaller task of less

importance. As a result the choice and use of the supporting information system is

driven more by the requirements of the management role than the distribution role.

• Organisational Silos.

Contrary to CQU’s “one University” approach there is significant distance between

CQU’s commercial and CQ campuses. There is even distance between the two

largest commercial campuses, Sydney and Melbourne, and their smaller cousins at

Brisbane and the Gold Coast.

• Organisational Holes.

There is no central software developer allocated to helping support divisions like

student adminstration support and implement systems like timetabling (unless they

hire their own). Instead most rely solely on the features of commercial packages that

are known for their inability to integrate with other systems..

• “Bad” technology.

The software used on the CQ campuses is not designed to integrate with other

software and offers limited support for the distribution of timetabling information.

The system used at the commercial campuses is based on infrastructure that does not

scale well.

Minimal Course Presence

Requirement

Students, both potential and current, spend time looking for information about the courses

offered by an institution. Traditionally this has been through marketing brochures and

handbooks. With the advent of the web many students seek this information through

course websites. A minimal course web presence for all courses allows students to seek

information about courses they may wish to undertake. To be of significant use such a

minimal course presence has to be available as early as possible and contain as much

information as possible. The Infocom minimal course presence also serves as the

foundation on which more complex and specific online teaching activities activities is

constructed. This includes support for both student learning and course management

tasks.

CQU System

CQU, like many other Universities, has adopted commercial course management systems

(CMS) to enable and support the provision of online teaching and learning. CQU’s

history with CMSes includes a trial with Topclass, adoption and use of WebCT (1999-

2003) and the adoption and use of Blackboard (2004-).

CMSes are designed and generally used by individual or small teams of academics and

support staff developing individual courses in isolation of others. CMSes are generally

not designed or used to support the automated generation of a minimal course presence

for all courses. For example, towards the end of 2003 there were 141 existing WebCT

courses that were to be converted to Blackboard. During 2003 CQU offered close to

1000 courses. Just over 10% of CQU courses had a course website.

For sometime two of CQU’s faculties, Business and Law (insert url) and Infocom

(http://www.infocom.cqu.edu.au/Courses/), have offered a minimal course presence for

their courses. Since late 2002 there have been discussions at various CQU committees

and working groups about the need for a minimal course presence for all CQU courses.

There has been no visible progress.

Infocom System

Infocom has provided a minimal course presence and supported online teaching and

learning since 1997 using its locally produced system, Webfuse (Jones and Buchanan

1996; Jones 1999). Webfuse is a term used to describe the technology and processes

underlying all of the Infocom web team’s development. Webfuse was originally

developed specifically for the support of online teaching and learning but has since

incorporated a range of features beyond that original scope.

In mid-2001 the Infocom minimal course presence was significantly expanded due to

previous experience and the adoption of Peoplesoft. The current minimal course

presence draws on information from a range of sources including: CQU’s student records

database, CQU’s online handbook, bookshop databases, databases from CQU’s

commercial partners, course profiles and a range of Infocom databases.

The minimal course presence is generated by an information systems that is given the

term and year and automatically generates the minimal course presence for all courses

offered in that term. The minimal course presence is initially created a number of months

before the start of term and slowly upgraded as additional information about courses is

made available. For example, course profile documents usually become available at

specific times prior to the start of term. As they become available the minimal course

presence is updated to include links to the course profiles.

From mid-2001 to mid-2003 the minimal course presence used a consistent structure and

appearance (http://www.infocom.cqu.edu.au/Courses/2003/T2/COIT11133). In mid-

2003 support was added to allow the customisation of the structure and appearance of a

minimal course site (http://www.infocom.cqu.edu.au/Courses/2003/T3/COMM11009).

However, there is still a core set of features and content that are required of a minimal

course site.

Teaching staff are able to extend the minimal course presence through a range of tools

operating within the minimal course sites or they can create and maintain a completely

different course website using a technology of their choice. These “real course sites” are

linked to from the minimal course presence. Of the staff who chose to move outside of

the minimal course presence a small number use CQU’s central CMS (WebCT or

Blackboard) while most (usually staff teaching in Infocom’s multimedia degree) generate

their own course website using their favourite web development tool.

Table ? provides a summary of course site usage since 2001 including the total number of

minimal course sites and the number of real course sites. Requests indicate the number

of web requests made of the course sites, both minimal and real, in that year. Updates

indicate the number of times a staff member has updated one of the pages on a minimal

course site. Staff indicates the number of different staff who have performed the updates.

Users indicate the number of users who have logged into the minimal course sites. It

should be noted that by default a login is required for only a small part of each minimal

course site.

2001 2002 2003 *

Contributing factors to the gap between the CQU system and the requirements of the

clients include:

• Differing requirements.

At CQU, the use of CMSes is generally driven by academic and support staff who are

primarily interested in tailoring the use of online teaching and learning to the specific

needs of individual courses for the term the course is offered. The requirement for a

minimal course web presence is to provide a fairly consistent, guaranteed minimum

course website for all courses as early before the start of term as possible.

• Organisational silos.

The information used to construct the Infocom minimal course presence comes from a

huge range of different parts of the organization. Gaining access to that data has been

a difficult, time-consuming, and as yet, unfinished task. Success in this task has often

owed more to ad hoc, personal contacts than official University structure and

committees.

• Organisational holes.

Responsibility for implementing a minimal course presence doesn’t really fit well

within the existing CQU structures. Courses belong to faculties and are delivered by

academics who have significant freedom with how they perform this task. The

responsibility for assisting with online delivery is primarily the role of the Division of

Teaching and Learning Services (DTLS). DTLS is set up to respond to requests for

assistance from individual academic staff rather than generate websites for all

courses. Most faculties do not have the resources to generate a minimal course

presence. Most academics are more interested in their individual courses than having

a minimal default approach.

Informal Review of Grades

Requirements

The release of final course results invariably generates anguish and questions amongst

students who are unhappy with their results. Within Infocom these students can request

an informal review of grade (IROG). An IROG usually involves the course coordinator

performing an additional check of the result, changing the grade if necessary or providing

additional information to the student about their result. In the two main terms of 2002

(Autumn and Winter) Infocom processed 809 requests for an IROG.

CQU System

The traditional CQU system for handling IROG requests is a paper-based process. With

CQU’s geographically dispersed, multi-campus operation this can be somewhat

problematic. For example, a student at the Melbourne campus will visit a staff member

to discuss a result. If the student is still unhappy a form is filled out expressing the

student’s concern. The form is then sent, either by fax or post, to CQU’s Rockhampton

campus. At this stage Infocom support staff forward the form onto the appropriate

academic staff member who may be at another of CQU’s campuses. On receiving the

request the academic staff member considers the request and responds by filling out the

form and returning the form. At this stage the form reverses it journey until it finally

reaches the Melbourne campus staff member who contacts the student.

As a largely manual process this process is slow and prone to human error. This creates

further disquiet for an often already anxious student.

The Infocom System

In July 2003, three weeks before IROGs would commence for CQU’s first major term in

2003, Teaching and Learning support staff approached the Infocom web team with

interest in developing a web-based process for handling IROG requests for CQU’s

autumn term from CQU’s commercial campuses. The following Infocom IROG system

was designed, implemented and tested within the 3 week period and was available on

time.

The online IROG process starts with a student visiting a staff member at a commercial

campus to discuss their results. If the student is still unhappy after this discussion an

IROG request is generated. To do this the staff member: logs into MyInfocom, enters the

student number, views the student’s enrolment details, clicks the “Request IROG” link

for the appropriate course, fills in the web-based form and hits the submit button.

When the IROG request form is submitted an email is sent to the academic staff

member(s) responsible for this course and also to the IROG support team. The IROG

support term receive copies of the emails so they can observe the process and take steps if

there are problems. The email includes the detail of the IROG request and a link to a web

page that academic staff can use to respond to the request. Responding to a request

involves: clicking on the link, reading the request, choosing whether there grade stands

or a new grade is awarded, filling out a rationale for the response and submitting the

form.

When the form is submitted an email is sent to both the staff member who originally

requested the IROG and the IROG support team. The email includes a link to a web page

that details the response. The commercial campus staff member will click on the link,

view the response, click on a “student version” link, print out the student version and

provide it to the student. The student version of the response includes the student’s postal

address so that it can be easily printed, placed in envelopes and mailed.

Commercial campus staff, academic staff and the IROG support team all have access to

web pages that summarise the details of all the IROG requests that are of interest.

Commercial campus staff can view all the IROGs for their campus. Academic staff can

view the IROGs for the course offerings for which they are responsible and the IROG

support team can view all the IROGs.

Statistic Value

Contributing factors to the gap between the CQU system and the requirements of the

clients include:

• Organisational Hole.

CQU’s student record system is designed primarily to serve the needs of CQU’s

student administration support division. This division is mainly interested in what

happens to students at the beginning (getting them enrolled, making sure they pay

their money etc) and the end of a term (getting their final grade). There is little or no

support for what happens during a term. IROGs are an example of a requirement that

slips through the hole.

• Developer/user distance.

The IROG support team within Infocom were responsible for identifying the original

need for a web-based IROG process. The organisational distance between that IROG

support team and the developers of CQU’s ERP system is quite large (the geographic

distance is one floor). The developers were not aware of this requirement. Making

them aware would have required: raising the issue at a users group, waiting for the

issue to become important enough to be scheduled, having a functional analyst being

the requirements gathering process, have a developer scope the requirements, wait for

a decision as to whether or not it was feasible, have it implemented, probably as a trial

process.

• “Bad” technology.

In this context the technology used by CQU’s ERP developers does not offer a good

match for this requirement. The technology is difficult to use (e.g. generating a

course list example above), not web-based and is closely tied to existing business

processes which do not include support for the IROG process.

• Missing pre-requisites.

The Infocom IROG system built on the existing MyInfocom structure and more

importantly the familiarity of staff with that system. MyInfocom was a pre-requisite

for this development and a similar system is not available to the rest of CQU.

How was it done

To succeed and add value to an organization it is believed that the development

methodology use for its information systems must match the requirements of the

organization. However, the aims and assumptions of traditional information systems

development methodologies, the production of systems with long periods of stable

operation, are ill suited to an emergent organization and will create long term problems

(Jones 2000).

Underlying the approach described here is a belief that a modern Australian University is,

or at least needs to be, an emergent organization. In emergent organizations, every

feature of the organization, culture, meaning, social relationships, decision processes and

so on, are continually changing as a product of constant social negotiation and consensus

building (Truex and Klein 1999). The rapid development of technology and global

markets contributes to a need for constant change where organizations are no longer

stable and must continuously adapt to their shifting environments (Truex and Klein

1999). In Australian Higher Education the shifting environment is contributed to by such

factors as changes in government policy, increasing commercial pressure, changing

nature of knowledge and disciplines and changing client needs.

Many of the staff employed at Universities (e.g. academics, instructional designers,

technical staff and managers) are knowledge workers with a considerable amount of

autonomy. The commitment and motivation of these individuals are a critical success

factor in the implementation of any information system. These staff can and will resist

the imposition of new technology and changes to routine. Additionally, the existing

organizational structures within which these staff operate can hinder convergent

development (Jones, Stewart et al. 1999).

The information systems developed by the Infocom web team are implemented within a

platform that goes by the label Webfuse (Jones and Buchanan 1996; McCormack and

Jones 1997; Jones 1999). Webfuse began life in 1996 as a tool to aid solely in the

delivery of web-based teaching and learning. In the time since then it has evolved into a

collection of technologies used to deliver the collection of web-based information

systems described above.

A brief technical overview of the components and characteristics of Webfuse include:

• Apache web server (http://www.apache.org/).

Apache continues to be used primarily because of the ability to modify the operation

of Apache using Perl.

• Perl programming language (http://www.perl.com/).

Initially chosen because it was one of the few general purpose web development

languages Perl continues to be used because of its extremely flexible nature and

CPAN (http://search.cpan.org). CPAN is a central repository which is used to

distribute the large amount of freely available software contributed by Perl

programmers through out the world.

• Various external information systems and software.

Webfuse is intended to be, where possible, a wrapper around existing information

systems. The Infocom Timetable Generator described above wraps around CQU’s

existing timetable information systems. The web-based discussion forum provided by

Webfuse wraps around YaBB, an open-source discussion forum. Where possible we

do not write software.

• A consistent development metaphor.

A frequent criticism of Perl is the variety and freedom the language provides. A

fundamental tenet of the Perl ethos is TIMTOWTDI: There Is More Than One Way

To Do It. This can cause problems with teams of developers doing it all their own

way. Webfuse has a consistent metaphor for development of web-based applications

that is used by all developers.

• Over 570 classes.

Webfuse uses an object-oriented development approach and consequently since 1996

we have developed over 570 separate classes to provide higher level services. Most

of these services are CQU specific. For example, the following code excerpt will

retrieve a list of all the Infocom courses offered in a particular term along with the

number of students in those courses.

use strict;

use Webfuse::lib::People::InfocomCourses;

my $courses = People::InfocomCourses->new(

PERIOD => “t3”, YEAR => 2003 );

• A disciplined development methodology.

An emphasis on code reuse, flexibility, closeness to the user, a test-driven coding

style and various other practices provides the foundation for a development

methodology which allows agile development of information systems.

A defining characteristic of the approach used within the Infocom web team has been its

reliance on emergent or agile development practices. Some detail about how and why we

have used agile development methodologies can be found in other publications (Jones

2000; Jones, Gregor et al. 2003; Jones, Lynch et al. 2003).

Conclusions

This paper has shown that it is fairly common for a gap to exist between the institutional

information systems at Central Queensland Univeristy (CQU) and the needs of the

students and staff of the Faculty of Informatics and Communication (Infocom). It has

shown how the Infocom web team has developed a range of intermediary information

systems to bridge that gap and offer significant advantage to Infocom. These

intermediary information systems have not only allowed Infocom to live with its

institutional systems they have enabled Infocom to thrive. The paper has briefly

discussed the processes and technology used to develop these information systems.

The paper identified a range of issues that help create the gap between user needs and the

functionality provide by institutional information systems. These include, but are not

limited to: “bad” technology, organizational holes, organizational silos, missing prerequisites,

developer/user distance, distance between system owner and users, a

preference for band-aid solutions, and organizational and technological inertia. It is

suggested that these factors are not unique to CQU and do exist in other Universities. As

a result other Universities may find the Infocom approach interesting.

References

Davenport, T. H. (1998). "Putting the Enterprise into the Enterprise System." Harvard

Business Review 76(4): 121-131.

Esteves, J. and J. Pastor (2001). "Enterprise Resource Planning Systems Research: An

Annotated Bibliography." Communications of the Association for Information

Systems 7(8).

Jones, D. (1999). Webfuse: An Integrated, Eclectic Web Authoring Tool. Proceedings of

EdMedia'99, World Conference on Educational Multimedia, Hypermedia &

Telecommunications, Seattle, Association for the Advancement of Computing in

Education.

Jones, D. (2000). Emergent Development and the Virtual University. Learning'2000,

Roanoke, Virginia.

Jones, D. and R. Buchanan (1996). The Design of an Integrated Online Learning

Environment. Proceedings of ASCILITE'96, Adealiade.

Jones, D., S. Gregor, et al. (2003). An Information Systems Design Theory for Webbased

Education. Submitted to WBE Syposium at CATE'2003.

Jones, D., T. Lynch, et al. (2003). Emergent Development of Web-based Education.

Proceedings of Informing Science + IT Education, Pori, Finland.

Jones, D., S. Stewart, et al. (1999). Patterns: Using Proven Experience to Develop Online

Learning. Proceedings of ASCILITE'99, Brisbane, QUT.

Mahaney, R. C. and A. L. Lederer (1999). Runaway information systems projects and

escalating commitment. Special Interest Group on Computer Personnel Research

Annual Conference, New Orleans, Lousiana, USA, ACM Press.

Markus, M. L., S. Axline, et al. (2001). Learning From Adopters' Experiences with ERP:

Problems Encountered and Success Achieved. Enterprise Systems: ERP

Implementation and Effectiveness. Willcocks.

Markus, M. L. and C. Tanis (2000). The Enterprise Systems Experience -- From

Adoption to Success. Framing the Domains of IT Research: Glimpsing the Future

Through the Past. R. W. Zmud. Cincinnati, OH, Pinnaflex Educational Resources:

173-207.

McCormack, C. and D. Jones (1997). Building a Web-Based Education System. New

York, John Wiley & Sons.

Oliver, D. and C. Romm (2002). ERP Systems in Universities: Rationale Advanced for

their Adoption. Enterprise Resource Planning: Global Opportunties and

Challenges. L. Hossain, M. Rashid and J. D. Patrick, Idea Group Publishing.

Parr, A. and G. Shanks (2000). A Taxonomy of ERP Implementation Approaches. 33rd

Hawaii International Conference on System Sciences (HICSS), Maui, Hawaii.

Standish Group (1995). The CHAOS report, The Standish Group International.

Truex, D. and B. Klein (1999). "Growing Systems in Emergent Organizations."

Communications of the ACM 42(8): 117-123.

Whittaker, B. (1999). "What went wrong? Unsuccessful information technology

projects." Information Management & Computer Security 7(1): 23-30.