ISSUES IN ACCOUNTING EDUCATION American Accounting Association

Vol. 26, No. 3 DOI: 10.2308/iace-50037

2011
pp. 507–520

North Carolina State University:

Implementing ERP Student Modules
Marianne Bradford
ABSTRACT: The purpose of this case is to describe the benefits and challenges of an
Enterprise Resource Planning (ERP) system at a higher education institution (HEI). The
case also focuses on IT risk and systems security issues inherent in an ERP system.
The case begins with the implementation of financials and HR modules at North Carolina
State University, a land-grant institution with 33,000 students. This background sets the
stage for the main focus of the case: the implementation of the ERP Student modules,
which required a major overhaul of information systems, including admissions, student
financials, and registration and records. Concluding the case is a recent dilemma facing
NCSU—the potential merging of ERP systems with The University of North Carolina at
Chapel Hill. Students have the opportunity to practice problem-solving skills with regards
to this dilemma, as well as offer their opinions on the strengths and weaknesses of the
Student implementations.
Keywords: ERP systems; higher education institution (HEI) information systems;
PeopleSoft; student information systems.

BACKGROUND

I
n 1995, North Carolina State University (NCSU) personnel could see the storm clouds
building. NCSU’s mainframe-based business systems were outdated (some were 20 years old),
did not integrate well with each other, could not support current or future functionality
requirements, and were difficult to make compliant with increasingly frequent regulatory changes.
Thus, in 1996, a cross-functional team made the decision to seek a vendor-supplied Enterprise
Resource Planning (ERP) system. This system needed to run on client-server technology, provide
real-time data access with integrated and easily extractable data, and enable a flexible and
extendable framework that could meet the University’s business requirements.
In March 1996, NCSU’s Chief Financial Officer and Chief Academic Officer formed a project
team comprised of Office of Information Technology (OIT) personnel and functional leads from
business offices across campus. They charged this team with the responsibility of developing a
request for proposal to ERP vendors for a system that would replace their Human Resources (HR)
system, NCSU’s most pressing need at the time.

Marianne Bradford is an Associate Professor at North Carolina State University.

I wish to thank the NCSU ERP project team for their time and willingness to share their experiences.

Published Online: August 2011

507
508 Bradford

In March 1997, based on a thorough review of each bidder’s proposal against the request for
proposal criteria, the project team unanimously recommended that NCSU purchase PeopleSoft’s
HR modules. As is common practice when negotiating ERP software, PeopleSoft offered a discount
on the Financials and Student (named Campus Solutions) modules, and so NCSU purchased these
as well. Implementation of the HR modules began in the summer of 1997. In October 1998, the
Accounts Receivable and General Ledger (GL) modules of Financials were released to a small
number of departments (see Exhibit 1 for the implementation timeline). In 1999, the campus-wide
rollout of the Financials and HR systems began. Purchasing went live in May, and Accounts
Payable and campus-wide GL and HR modules went live in July. Unfortunately, these modules
were not quite ready for the widespread use.
States Ron Reed, project team member and Enterprise Application Services Assistant Director,
Financial Systems, ‘‘We had no choice. Many people felt that these systems were crammed
down their throats, and they didn’t have an opportunity to provide feedback.’’
As soon as the systems went live, functionality and performance issues occurred.
‘‘HR and Financials were on fire,’’ said Gwen Hazlehurst, project team member and Director
of Enterprise Application Services. ‘‘Systems were crashing. We were struggling to plug the
dike. We didn’t do thorough software load testing, which resulted in serious performance
problems and system outages.’’
To further exacerbate the situation, training did not go as it should. With both Financials and
HR going live at the same time, a large number of users had to be trained. Since instructors and
teaching space were limited, training had to occur over a prolonged time period. The period of time
was so stretched out that users forgot much of their training by the time the systems were
implemented. Furthermore, the systems had changed noticeably between many of the training

EXHIBIT 1
Timeline of PeopleSoft Implementations/Upgrades at NCSU 1998–2009

Issues in Accounting Education

Volume 26, No. 3, 2011
North Carolina State University: Implementing ERP Student Modules 509

classes and the go-live dates. The result was that a large number of users were unsure of how to use
the new systems at go-live. For the first time ever, NCSU faced major audit problems, which
threatened the University’s flexible spending authority (this authority provides NCSU with the
ability, within state laws and guidelines, to allocate spending the way it sees best [e.g., money
allocated for salaries could be redirected to purchase software]).
As the dust began to settle months later, there was a culling process within the project team.
‘‘Subject matter experts and OIT staff had their worlds flipped upside down,’’ said Connie
Reitfort, project team member and Assistant Director, Enterprise Application Services.
‘‘Creatures of habit didn’t survive in this new environment. People had to adapt quickly or
leave.’’
Also as a result of the upheaval, there was a significant turnover in many of the business offices
involved with the implementations. Each implementation had required dedicated personnel putting
in well over 60 hours a week for months before and after each go-live.
Adds Ron, ‘‘We realized that change management (the structured approach to transitioning
users) was crucial moving forward. We had dropped the ball this time around.’’
Nevertheless, the team had learned valuable lessons that would help them as they investigated
and later implemented the cornerstone of a higher education institution (HEI) ERP system: the
Student modules.

INVESTIGATING THE ERP SYSTEM’S STUDENT MODULES

In March 2000, as several ‘‘Big Ten’’ HEIs began to have significant problems with
PeopleSoft’s Student modules, the project team decided to delay implementation until the issues
were resolved and a web-enabled version was available.
‘‘The product was simply not ready and did not match what NCSU needed. We were looking at
it, and no other university had brought it up yet. We started down the path, but everyone else
was crashing and burning,’’ remarked Dr. Louis Hunt, Vice Provost and University Registrar.
Most users thought that NCSU’s student information system (SIS), a homegrown system
programmed in the 1980s, worked fine, thanks to a recently built web interface. However, the
systems behind those web pages were badly out of date.
As one OIT representative commented, ‘‘The front door looked good, but the plumbing was
bad. We couldn’t band-aid it anymore.’’
However, the decision to wait came at a cost. Since NCSU had already purchased the Student
modules, they were incurring annual maintenance costs even though they were not using them.
Furthermore, NCSU continued to support disjointed systems—Financials and HR in PeopleSoft,
and the SIS on a mainframe database. There were significant costs associated with supporting these
diverse infrastructures and systems. In addition, many OIT staff who supported the SIS were
retiring, and it would be extremely difficult to replace them with people who wanted to work with
outdated technology.
‘‘The IT environment was changing rapidly; everyone had gone to using a PC with a mouse,
and using green screens and function keys was clunky. We were doing serious screen scraping
on the mainframe (translating legacy functionality to new user interfaces so the legacy system
could still be used) and couldn’t respond fast enough to changes and requests for
functionality,’’ said Louis.

Issues in Accounting Education

Volume 26, No. 3, 2011
510 Bradford

In 2005, with the release of a more stable version of PeopleSoft’s Student modules, the NCSU
ERP project team felt the time was right to begin implementation. The latest version was not only
stable, but also was web-enabled and offered much of the functionality NCSU required. This
functionality included student self-service, student bills that looked like credit card bills, registration
that resembled an Amazon.com shopping cart, the ability to easily swap classes and enforce
prerequisites, improved edit checking, and tighter integration with the Financial and HR modules.
‘‘The system was established now, and we had the maturity as a team to take it on. We had
learned lessons from the Financials and HR implementations,’’ said Connie. ‘‘We had found
the sweet spot between bleeding edge (an early adoption of a version) and waiting too long for
a mature release. If you wait too long, you are at bleeding edge again. There’s pain in bleeding
edge and we didn’t want to be there. The system was ready, but more importantly, we were
ready.’’

PLANNING FOR THE ERP STUDENT MODULES

In 2006, a cross-functional project team led by the Associate Dean of the Graduate School and
made up of subject matter experts, OIT staff (including Ron, Gwen, and Connie), and external
consultants began planning for implementation of the Student modules (see Exhibit 2 for
PeopleSoft Campus Solutions modules). Planning included establishing the scope of the project and
performing a fit-gap, a process that compares the ERP functionality to the company’s requirements.
The team also had to plan for building interfaces between the Student modules and systems that
would require data from the Student modules. They identified a total of 13 systems, including
University Dining, Student Housing, the NCSU Library, and Student Athletics, that required
student data. Many data elements in PeopleSoft would have different names, field sizes, and/or
coding schemes, and these changes would impact systems that need this data. The team also
developed a strategy for the rollout. They determined that it was best to implement the Student
modules in releases instead of all at once (i.e., Big Bang), as was done in the Financials and HR
implementations. Although the phased approach would drag the implementation out over a longer
period, the team determined it was a less risky approach. In addition to the rollout strategy, they
also had to plan the project around the academic calendar.
States Gwen, ‘‘In an academic environment, hitting project end dates is critical. Take
Registration. We knew that it would be imperative to go live with Registration in February, as
students register in March. A successful project plan should be transparent, but should also
allow for some slippage of task due dates without compromising major milestones and goals.
We had to estimate carefully and conservatively.’’

ERP STUDENT MODULE RELEASES

Release 1
In July 2007, Release 1 of the Student implementation, the Campus Community module, went
live. This module integrates demographic and biographic data for faculty, staff, and students (see
Exhibit 3 for comparison of biographical data screens between the SIS and the ERP system). In a
typical HEI legacy environment, it is possible that a person can have multiple identity records
across campus. For instance, at NCSU, of 7,000 graduate students, nearly 50 percent had HR
records and student records because they worked somewhere on campus.
‘‘We had to try to make sure everything matched up perfectly before going live with Campus
Community,’’ said Rick. ‘‘This included scrubbing 400,000þ people records. When it was done,
it was a thing of beauty. R&R and HR personnel realized that we are in one world now.’’

Issues in Accounting Education

Volume 26, No. 3, 2011
North Carolina State University: Implementing ERP Student Modules 511

EXHIBIT 2
PeopleSoft Student Modules and Integration Points with HR and Financials

Shaded modules were implemented as of Release 5. Academic Advisement partially implemented as of Release 5.

Release 2
In September 2007, the Admissions module went live, minus the web-based portion that
students fill out, which was housed in third-party applications. In this release, the team also decided
to overhaul the University portal, dubbed ‘‘MyPack,’’ to dovetail with the University homepage
facelift. From a project perspective, however, this revamping of the portal was ‘‘scope creep,’’ in
that it was not part of the initial project charter or project plan. Up until this point, the team had
guarded vigilantly against changes that would jeopardize the project delivery date (as this did by
two months), even if they would improve the project.
States Ron, ‘‘No plan is ever perfect and if you cannot or will not adjust your project to address
opportunities, you are destined to fail. The trick is knowing what to take on and what to push
back on. The portal was absolutely the right thing to do and the implementation benefited us
greatly, but strictly speaking, it was scope creep.’’
The team eased the transition to the portal by focusing heavily on campus-wide
communication. Words such as ‘‘new’’ or ‘‘change’’ were struck from the team’s vocabulary
because it ‘‘scared people.’’ The team set up kiosks all over campus to get the word out about the
ERP Student system and the new portal.

Issues in Accounting Education

Volume 26, No. 3, 2011
512 Bradford

EXHIBIT 3
Comparison of Biographical Data Screens between the SIS and PeopleSoft

Panel A: SIS
Panel B: PeopleSoft

Issues in Accounting Education

Volume 26, No. 3, 2011
North Carolina State University: Implementing ERP Student Modules 513

Adds Gwen, ‘‘If the campus doesn’t know what’s happening, and when, frustration will quickly
snowball. Once this frustration reaches a certain level, people will blame everything from
drought to world hunger on the new system. We learned that lesson from the early days—to
manage the change, the ‘soft stuff’ of the implementation.’’

Release 3
The old system that performed student billing was not Y2K-compliant, so when ERP
Financials (which ran NCSU’s financials) was implemented back in 1998, the team made the
decision to move student billing to that system. This required that OIT customize Financials to
handle student account idiosyncrasies, including calculation of student tuition and invoicing and
settlement of student accounts.
In October 2007, the team implemented the Student Financials module for the latter part—
invoicing and settlement of student accounts. The most difficult part, tuition calculation, was left in
the SIS temporarily.
States the ERP Student project team lead and Assistant Dean of the Graduate School, Rick
Liston, ‘‘We were crossing a raging river. There’s danger in the river, and you need to find a
rock to stand on. Every stopping place had to be carefully thought out. This points to project
management, really. You’ve got to be careful but aggressive or you won’t get the thing done.’’
With Release 3 under their belt, momentum had built up and the team was feeling like a ‘‘real
team.’’
‘‘ERP implementations are both functional and technical projects. If both the functional and
technical people on the team aren’t fully engaged and working well together, the project will
almost certainly fail. All teams must see the implementation as a joint effort—everyone sinks or
swims together,’’ states Gwen.
To get the team ready for the next onslaught, Gwen took them off-campus for a day of team-
building exercises to further build relationships and to gear up for Release 4.

Release 4
Registration for summer 2009 was to occur in the ERP system. This meant that by February
2009, student registration (part of the Student Records module) must be live so students could
register in March (see Exhibit 2 for module integration). The first step, completed in summer 2008,
was to transfer the course catalog (e.g., classes, prerequisites) and classroom scheduling data (e.g.,
what sections of what class were to be offered, who was teaching what and where) from the SIS into
the ERP Student Records module. After a fit-gap of the classroom scheduling functionality in
Student Records, the team decided to continue to use their existing third-party-supplied classroom
scheduling system, Ad Astra. In addition to all this, the team had to write backwards conversion
programs to pull data from ERP Student Records back into the SIS once registration began. This
was important because some processes needed to run off the SIS for a while longer.
During the last two releases, testing was becoming increasingly standardized. Developers
would test small increments of functionality, known as unit testing, and then project team members
and super-users would perform functional testing, which tests processes from end to end to ensure
that screens look and act as expected and produce the expected results. Prior to the go-live of each
release, a final round of testing, customer acceptance testing, would commence, in which any and
all problems uncovered during the first two rounds were addressed and affected users would sign

Issues in Accounting Education

Volume 26, No. 3, 2011
514 Bradford

off. OIT also conducted automated performance testing, or load testing, in which they simulated
peak transaction volumes to ensure the system will perform as expected.
‘‘Many failed ERP system implementations can be traced back to poor or nonexistent load
testing,’’ explains Gwen. ‘‘NCSU did not have any load testing capabilities throughout the
Financials and HR implementations, and suffered serious performance problems and outages
as a result.’’
Furthermore, training had much improved over the early years. The team knew it was
important to speak to users in a language they could relate to. They also gave employees ‘‘JIT’’
training (as opposed to months before a go-live date), and used the train-the-trainer approach, in
which a department representative would receive training and subsequently train the rest of the
department.
States one project team member, ‘‘We picked trainers that we thought were interested and were
good at learning new systems. Sometimes we picked the most vocal people—the ones that
typically slam you. If you can convert them, you’ve really accomplished something.’’

Release 5
In February 2009, a relatively slow time of the year, the project team put the finishing touches
on the final release, Academic Advising (graduate portion only), and the remaining components of
the Student Records module. This required the conversion of approximately 825,000 enrollment
records, 40,000 transcripts, 66,000 photos, and 21,000 courses from the SIS into the ERP system.
Adds Rick, ‘‘We converted all permanent records in one weekend and gave business offices the
following week to clean up the data. We also sealed off the portal so no new data was coming
in. We had 30 years of development in the SIS. To convert to a relational database was
unbelievably difficult.’’ Adds a project team member, ‘‘It was a lot of work and a lot of stress.
I’d go home, eat dinner, and then turn on the computer again. It was a constant challenge not
to burn out.’’
The new Student Records functionality was a major improvement for faculty and students. For
instance, in the SIS, when faculty posted grades at the end of the semester, students had to wait for
R&R to run a batch job at night before they could see them. And Friday’s postings after 5:00 pm
could not be seen by students until the following Monday. Now, as soon as faculty post grades, they
are available to students. Students can now swap classes instead of dropping and adding and can
take advantage of the ‘‘wish list’’ and ‘‘wait list’’ functions for course schedules and adding classes.
Also included in this release was the ‘‘dreaded’’ tuition calculation piece, which had been
skipped in Release 3 due to complexity because of the multitude of inputs (23, to be exact) required
to compute student bills. There is a lot of pressure to get student bills correct. In addition to
students, parents and sponsors that pay tuition on behalf of students would quickly become aware
of widespread errors. And, due to the visibility of the University and the substantial investment
made in the ERP system, there was also interest from the state legislature—especially in view of the
previously noted problems experienced by several Big Ten schools.
‘‘It’s important to get it all right—tuition, refunds, financial aid, and schedule change
adjustments. You could spend a month testing one facet of the calculation, but if you miss one
nuance you could blow it up. As soon as the calculation is done, students can see their bills, so
it puts pressure on us to get it right the first time. We definitely didn’t want to end up on the
front page of the News and Observer!’’ exclaimed one team member.

Issues in Accounting Education

Volume 26, No. 3, 2011
North Carolina State University: Implementing ERP Student Modules 515

SYSTEM SECURITY
Due to the increased complexity and extended functionality of the Student modules, identity
and access management was overhauled, as well. The identity piece had been addressed in Release
1 as a part of Campus Community, but for the last ten months of the Student modules
implementation, the provisioning and de-provisioning of users in the systems (giving them access
to functionality or deleting that access) was addressed. During this time period, the OIT security
group assessed roles and permissions of 33,000 students and 9,000 faculty and staff in the legacy
business systems and re-provisioned these users into PeopleSoft. The first step was to map 30 years
of legacy user roles into new ERP system roles. During this process, it was discovered that many
people had segregation of duties violations in the previous legacy systems.
‘‘Many exceptions were found, and countless users had conflicting roles,’’ said Jack Foster,
member of the OIT security team and Enterprise Portal Administrator. ‘‘In addition, ERP
Student modules had new functionality, so we had to ask each department head who should
perform it. It was painful.’’
A second step involved an overhaul of the access management information system, which
was a homegrown system. Authorized personnel would enter a request online for OIT to review,
and the information was email-routed or printed out and delivered to various people for approval.
This process could take several weeks; meanwhile, the user was waiting for system access.
Because of these inefficiencies, the security team purchased a state of the art access management
package to automate security for the ERP system. With a click of the button they can approve or
deny access.
‘‘It used to be that if the last person in the approval process didn’t agree with the request, it got
killed and the process started all over again. Now, that doesn’t happen. The time it takes to
provision has decreased dramatically. Before, the average time was days and weeks; now, it’s
less than a day,’’ states Connie.
A third step was to link the new access management system to the ERP system. Now, any time
a student, faculty, or staff has a change in status (e.g., graduating, hiring, changing jobs), the ERP
system will automatically take the previous role(s) away and apply the new role(s). With regular
ERP upgrades, assessing security must be ongoing.
‘‘Every time we do an upgrade, we have to look at security and see if we need to provision a
new role or change someone’s access. We always need to make sure we have traceability; the
auditors ask for it. We have to be able to account for why people have a role and who
approved it,’’ said Connie.
Once a year, the OIT security team provides reports to Department Heads and College Deans
regarding access rights for employees. These reports must be reviewed and certified.

IT GOVERNANCE
Strong IT governance is critical to being able to complete an implementation or upgrade in a
timely manner. One area in which IT governance was initially lacking was allowing change
requests, including customizations (which entails adding program enhancements/rewriting code),
during the HR and Financials implementations. Customizations are not only time-consuming and
costly in an initial implementation, but also they continue to be a financial drain because future
upgrades will have to be ‘‘retrofit’’ with the customizations all over again, adding maintenance
costs.

Issues in Accounting Education

Volume 26, No. 3, 2011
516 Bradford

According to Gwen, ‘‘We didn’t really have a good idea of the number and magnitude of
customizations that had been developed for the original HR and Financials systems
implementations until we began planning for our first upgrades. We were dismayed at the
amount of time it took to retrofit all of the changes into the new releases of the systems (or at
least evaluate the need to continue them). From that point forward, we became much more
serious about formal governance processes.’’
Because of the desire to minimize change requests in the Student implementation, a Steering
Team comprised of directors of departments across campus was formed to authorize and prioritize
change requests. The Steering Team is also responsible for redirecting OIT resources to IT projects
of the highest value to the University as a whole. For example, during the Student Records
implementation, the Team reallocated 1,000 programming man-hours from other projects on
campus to the Records implementation.
‘‘This reallocation of resources slowed the progress on a number of projects on campus, but
ultimately contributed to the success of the Records implementation,’’ said Gwen.

THE NEXT STEPS FOR NCSU

Fresh off the heels of the rollout of Student Records will be the implementation of the
undergraduate portion of Academic Advising and Financial Aid, and upgrades to the PeopleSoft
modules planned for early 2011.
To further complicate matters, beginning in 2008, North Carolina faced a major budget crisis
and had twice frozen state spending. Fifteen miles away in Chapel Hill, NCSU’s longtime rival,
The University of North Carolina at Chapel Hill (UNC-CH), was implementing their first-ever
ERP system. They had also chosen PeopleSoft (all other NC public universities used the Banner
ERP system). The new Vice Chancellors for Information Technology at each school, along with
the NC Board of Governors, were putting pressure on the two HEIs to reduce spending and find
ways to work together (see Exhibit 4 for Triangle-area newspaper announcement). For many, it
did not make sense to have separate PeopleSoft systems for two very similar schools a few miles
apart.
Projected and actual ERP-related expenses were exorbitant. NCSU had already spent over $31
million on ERP implementations and upgrades since 1998 ($11.6 million of that on the Student
modules), which consisted of software licenses (23 percent), hardware purchases (9 percent),
implementation consulting (38 percent), additional staffing costs and training (5 percent), recurring
software maintenance (22 percent), and recurring hardware maintenance (3 percent). UNC-CH’s
initial ERP implementation of Financials, HR, and Student was projected to run $75 million. NCSU
had years invested in PeopleSoft, while UNC-CH was just starting. But UNC-CH had deeper
pockets with the money to buy hardware, one thing lacking at NCSU under the current budget
crisis.
In June of 2009, ERP project teams from the two HEIs met to discuss sharing part, or all, of
their ERP systems. There were many obstacles to overcome before moving forward. For instance,
the two HEIs have different Charts of Accounts and would need to develop a common one that
would meet the needs of both institutions—a major task. Also, NCSU’s HR system is largely
customized, and in some areas the two universities use different payroll cycles. Student processes
are also likely dissimilar, although the teams were hesitant to divulge these to each other.
Sitting in an office looking back on a decade of ERP implementations and upgrades, Connie,
Ron, and Gwen reflected on the work they and the project team had accomplished. With all these
issues on the forefront, NCSU OIT staff had much to think about.

Issues in Accounting Education

Volume 26, No. 3, 2011
North Carolina State University: Implementing ERP Student Modules 517

EXHIBIT 4
Triangle Business Journal—NCSU and UNC-CH Potential ERP System Integration

Friday, May 22, 2009

New UNC computer system comes to $75M
CHAPEL HILL—The University of North Carolina at Chapel Hill is testing the first phase of a new
administrative computer system costing $70 million to $75 million—one of the largest non-capital
projects in the school’s history.
UNC has spent the past two and a half years working to upgrade its more than 20-year-old mainframe
computer with PeopleSoft’s Web-based systems. University officials say the new system will ease the
processing of admissions, student records and financial aid applications and likely will save money
over the long run.
The first phase, which will handle undergraduate admissions, is set to go live in August. The university
chose PeopleSoft, which is a software brand owned by Oracle Corp., because of Oracle’s specialty
in developing software to manage university administrative systems.
The transition was necessary because the company that had developed UNC’s existing mainframe
system was no longer supporting it. ‘‘It got to the point that we were one of only two users left on
the planet,’’ says Larry Conrad, UNC’s vice chancellor for information technology.
Once the student records system, including transcripts and financial aid, is fully implemented, which
won’t occur until late 2010, Conrad says the university will start to replace its decades-old human
resources and financial systems.
The massive costs are due largely to the amount of data that need to be transferred from the dated
mainframe computer to the new system. Mark Hoit, vice chancellor for information technology at
North Carolina State University, says that over the years, as demands for new computer services
have developed, University IT personnel often wrote new programs and created new systems on the
mainframe to meet their needs.
That resulted in a hodgepodge of codes and services that needed to be realigned to work together in a new system.
NCSU completed its switch to PeopleSoft for student records earlier this year. It updated its financial
and HR systems in 1998, in preparation for the Y2K transition. UNC had been reluctant to update its
administrative systems. Not only is such a change costly, but it requires all administrators, faculty,
staff and students to be trained to use a new system, which can be a monumental challenge. At the
same time, the old systems, while dated, still worked.
Richard Katz, vice president of Educause, a nonprofit that works to advance the way universities use
their information technology systems, says administrative computer systems often aren’t replaced until
they truly have reached the end of their useable life. ‘‘It is really no different than deciding when to
replace your car,’’ he says. ‘‘You have many other ways to spend your money, but at some point
getting a new car becomes both urgent and important.’’
Once new systems are fully operating, Conrad and Hoit say universities will likely experience some
cost savings, though they are hard to quantify. For example, under the old systems, any tax law
changes would require a team of IT programmers to spend six months writing new programs to
manage the changes to the payroll system. With the new system, it will only take that team about
three weeks to install the PeopleSoft updates.
However, at the same time, demand for computing and network services has grown so much, the
departments are having to provide other services. Hoit also says he believes that with UNC adopting
PeopleSoft, UNC and NCSU will be able to work together to find ways to more efficiently manage
their IT systems. It shouldn’t be too much of a stretch—Hoit and Conrad already have a long-
standing working relationship. Hoit formerly ran the IT department at the University of Florida,
while Conrad was his counterpart at Florida State University.

Issues in Accounting Education

Volume 26, No. 3, 2011
518 Bradford

CASE LEARNING OBJECTIVES AND IMPLEMENTATION GUIDANCE

Overview
This teaching case details the implementation of ERP Student modules, which most students
are familiar with: students are recruited and advised; they register, drop and add classes, receive
bills, pay bills, and graduate. Upon reading this case, students should appreciate the roles they play
in ERP-supported student-centric processes, as well as the roles that staff and faculty play. For
instance, accounting staff will perform tuition calculation and receive student payments, and faculty
will post grades. Detailed interviews were conducted from 2009–2010 with key ERP project team
members, who have agreed to the use of their real names.

MOTIVATION
Presently, the ERP teaching cases available are geared toward the private sector. One of the key
differences between a HEI and a private sector company is that there is a broader set of stakeholders
in a HEI with very different needs. These stakeholders include faculty, staff, students, donors, and
sponsors, to name a few. An ERP system for HEI must be able to provide the information needed
for each of these sets of users in the format desired.
Additionally, unlike other published ERP teaching cases, this ERP case addresses the
intersection of ERP with information security, IT governance, and enterprise risk management
issues, topics with which accounting students should be familiar.

LEARNING OBJECTIVES
The primary learning objectives of this case are:
 Identify issues that can negatively and positively impact the success of an ERP
implementation;
 Examine how ERP can both increase and decrease risks in an enterprise;
 Recognize information security issues inherent in an ERP environment; and
 Explore ways in which NCSU and UNC-CH might share ERP systems and defend a chosen
solution.
These case learning objectives are significant because students will most likely experience an
ERP system implementation during their careers and should be aware of the types of issues
organizations face when undergoing such a massive business transformation. Furthermore,
enterprise risk and IT security are elements closely aligned with internal control, subjects with
which accounting students should be familiar. This case will bring a real-world perspective to their
textbook knowledge.

IMPLEMENTATION GUIDANCE
This case has been used in both undergraduate ( junior- and senior-level) and graduate ERP and
accounting information systems classes. It is rich in detail and provides a unique perspective on a
HEI ERP implementation. While ERP implementations can be quite technical, this case is written
such that students without previous knowledge of ERP systems should not have problems. Case
questions not only test students’ comprehension and knowledge of the case, but also apply their
knowledge to a novel situation (the potential merging of ERP systems between two HEIs) and new
topics (ERM).
Typically, a student group consisting of four students will present this case in class. Groups are
given 20–25 minutes to present the case in class, and time is allowed for a question-and-answer

Issues in Accounting Education

Volume 26, No. 3, 2011
North Carolina State University: Implementing ERP Student Modules 519

session at the end. Presentation requirements include coverage of the main points in the case and a
discussion of the case questions at the end of the case, plus an additional question from the teaching
notes. The remainder of the class is required to turn in a two-page case write-up, so that I am sure
the students not presenting the case have, in fact, read the case, and there is sufficient and
interesting discussion following the case presentation.
Another approach is to discuss the answers to the case questions in class. I generally allow an
hour of class time to do this. I either lead the class discussion or act as a passive observer while a
group leads the discussion. Students are incentivized to take part in this discussion for participation
points. For instance, in role-playing question 2, one team could assume the role of NCSU personnel
on the joint planning committee, while one team could assume the role of UNC-CH personnel.
Teams could take turns debating the prudence in sharing ERP systems and what, if anything, should
be shared. Teams will no doubt understand how much organizational learning has taken place at
NCSU regarding PeopleSoft and what challenges must be overcome if the project is to be seen as a
win-win by both schools.

CLASSROOM EFFICACY
The author has used this case for four semesters in both undergraduate and graduate ERP
courses. Undergraduate students are typically accounting majors who are concentrating in
information systems and have already taken accounting information systems. Graduate students are
typically in the M.B.A. or Master of Accounting programs. Many of the graduate students and some
of the undergraduate students have previous work experience, but few have knowledge or
experience with ERP systems.
To assess classroom efficacy, the author administered an anonymous survey to both
undergraduate and graduate students (n = 81) who had read the case for class. The web-based
survey consisted of four questions focused on the objectives of the case, with a fifth question
assessing students’ perceptions of the case’s contribution to their overall learning of ERP in a
university setting. The questions were measured on a five-point Likert-type scale with the following
responses: Strongly disagree = 1, disagree = 2, neutral = 3, agree = 4, strongly agree = 5.
Survey questions and responses are as follows:
1. The NCSU case helped me better understand educational ERP functionality.
2. The NCSU case helped me better understand how a large-scale ERP system is rolled out
for an educational institution.
3. The NCSU case helped me better understand logical access security issues that must be
considered in rolling out an ERP system in an educational environment.
4. The NCSU case helped me better understand what type of interfaces must be supported
between ERP and other systems in an educational environment.
5. The NCSU case contributed to my overall learning of ERP in an educational environment.
‘‘The Distribution of Responses’’ graph shows the distribution of responses. Means are
calculated below:
NCSU Learning 1: 4.60/5
NCSU Learning 2: 4.84/5
NCSU Learning 3: 4.14/5
NCSU Learning 4: 4.09/5
NCSU Learning 5: 4.61/5
Qualitative feedback was also solicited from the students. Consistently, students liked the
‘‘easy to understand’’ language and the ‘‘real-life situation’’ they could ‘‘relate to.’’ Some key quotes
are:

Issues in Accounting Education

Volume 26, No. 3, 2011
520 Bradford

 The language used made it easy to understand for those without an IT background.
 I liked how the case incorporated what we have learned in class to real activities that we
come in contact with almost every day.
 I liked that there were a lot of quotes and interviews from people that had to implement the
system.
 One thing I liked most about the case is that it details how time-consuming and costly an
ERP system implementation is. If the planning step does not go well, it will be a huge mess
later.

TEACHING NOTES
Teaching Notes are available only to full-member subscribers to Issues in Accounting
Education through the American Accounting Association’s electronic publications system at http://
aaapubs.org/. Full-member subscribers should use their usernames and passwords for entry into the
system where the Teaching Notes can be reviewed and printed. Please do not make the Teaching
Notes available to students or post them on websites.
If you are a full member of AAA with a subscription to Issues in Accounting Education and
have any trouble accessing this material, then please contact the AAA headquarters office at info@
aaahq.org or (941) 921-7747.

Issues in Accounting Education

Volume 26, No. 3, 2011
Copyright of Issues in Accounting Education is the property of American Accounting Association and its
content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's
express written permission. However, users may print, download, or email articles for individual use.