HOME · FORUMS · ABOUT · LINKS · CONTACT US  
ABOUT PEOPLESOFT
Home
What is PeopleSoft?
PeopleSoft Q & A
PeopleSoft&Oracle
Who is Larry Ellison?
PeopleSoft Modules
Oracle Modules
PeopleSoft 9
Project Fusion
 
TOOLS & TRAINING
Developer Tools
Consulting Tools
PeopleSoft Training
PeopleSoft Connect
Project Management
 
CONSULTING
Consulting Firms
Consulting Reviews
 
JOBS
PeopleSoft Jobs
Immigration (H1-B's)
 
OTHER LINKS
Forums
PeopleSoft News
Interviews
PS Gossip
Your Feedback
Friends of the Planet
Editors Blog
 

PSPlanetXpress
Newsletter

Please note that all fields followed by an asterisk must be filled in.

First Name*
E-mail Address*

Your e-mail address is secure. We will only use it to send you PeopleSoft-Planet related bulletins and information.

 
 

 

  How to live with ERP systems and thrive

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