Proceedings of ASBBS Volume 15 Number 1

The Accountants Role in an ERP Implementation

Sellani, Robert J.
Nova Southeastern University
sellani@nova.edu

ABSTRACT
ERP implementation failures continue, even at institutions that teach best practices. Arizona State
University’s payroll system implementation problems represent a risky approach to systems
implementation. Functional responsibility for Payroll typically resides in the Accounting organization,
yet it would appear implementation responsibility was the Information Technology department. Where
are the Accountants in this implementation? While not required to do business under Sarbanes-Oxley the
checks and balances described in Section 404 and the International Organization for Standardization
(ISO) 9000 quality standards would have gone a long to prevent the problems.

INTRODUCTON
Arizona State University recently experienced an example of how to not implement an ERP system.
According to the Wall Street Journal (WSJ, 2007), “roughly 3000 Arizona State employees have been
underpaid or unpaid since the school started using new software from Oracle Corp. to manage its
payroll”. Whether the mishap was preventable depends on how much effort was made on educating both
the user group and employees in the implementation process and to what extent sufficient internal
controls were in place during the migration and cut-over to minimize risk.

EVOLUTION OF MRP TO ERP SYSTEMS

Integrated systems became common in the early to mid 1980’s with the advent of Material Requirements
Planning (MRP), and Manufacturing Resource Planning (MRPII) software. These systems provided users

February 2008 1470

Proceedings of ASBBS Volume 15 Number 1

a common database and uniformity of process. Prior to these integrated packages, accountants had to rely
on everything from rolodex files to green-bar spreadsheets for any financial information and in some
cases, each department had their own separate database and operational procedures. Internal and external
auditors tended to focus on process flow, internal control mechanisms, valuation, and consistency, but not
the lack of an integrated system.

As the development of MRPII systems progressed, the interlinking continued with Distribution
Requirements Planning (DRP) and then Human Resource Management (HRM). Both additions are very
helpful in providing a company with an integrated system that “talked” to the other parts of the business.
In the mid 1990’s, the Internet provided yet another distribution channel with its own unique qualities and
processes. Software companies rapidly developed mechanisms for this new way of doing business and
firmly imbedded the logic with existing offerings.

Software suppliers such as SAP, Oracle and others continued to further develop and refine their software
solutions with the advent of Enterprise Resource Planning (ERP). ERP systems typically consist of the
following functional modules:

• Financial Accounting and Reporting

• Fixed Assets Management

• Cost Management

• Manufacturing, including MRP, Capacity Requirements Planning (CRP), Procurement, Inventory

Management, Bill of Materials, Shop Routings,

• Sales Order Management, including configuration management

• Human Resource Management

• Project Management

• Logistics and Distribution Management

All functional modules represent financial inter-relationships within the organization.

SYSTEMS IMPLEMENATION PRACTICES

Systems implementation theories vary but a commonly used approach is one nick-named the “big-bang”.
This approach can be efficient but not always effective and the tradeoff between disruption and
implementation problems can be a difficult choice. If users are not properly trained or have an inadequate
understanding of what problems to anticipate, implementation crises can emerge. The “Implement,
Adapt, and Grow” implementation philosophy Arizona State University employed parallels certain
aspects of the big-bang implementation theory.

February 2008 1471

Proceedings of ASBBS Volume 15 Number 1

The big bang theory can and often does work because it places a premium on using existing vanilla
software. This implies less effort is spent validating how the system performs certain repetitive
transactions as the transactional flow has already been proven through use in other organizations. Payroll
is a very repetitive transaction so it makes sense to use the system as designed with minimal
modifications, if any. Big bang also relies heavily on a very responsive team to quickly identify problems
and solve those problems with minimal disruption. The team’s job is generally to limit any significant
problems and rapidly stabilize the new system as it comes on line. These responsibilities would seem to
fall in line with Arizona State University’s “Adapt” portion of the implementation philosophy. The
“Grow” portion of the Arizona State University’s philosophy would occur shortly after stabilization when
the actual users become comfortable in using the system and begin to flex its full capability.

Big bang has another arguably major strength or weakness, depending on the perspective. It can greatly
speed up the implementation process. Arizona State University’s claim the implementation took
approximately 18 month (ASU blog 9/03/07) does represent a very favorable result when compared to the
estimated 5-10 years (ASU blog 9/03/07). It would appear that Arizona State University implemented the
Payroll system using a version of the big-bang process and paid the price for the speedy effort. In systems
implementation, there will always be tradeoffs between implementation speed and control. The faster the
system is implemented, the quicker the organization begins to reap the new system benefits and the less
disruption to the organization. But, as time passes particularly past the two year mark, organizational
fatigue begins to set in. Key players may be reassigned or leave the organization, newer software versions
need to be updated, and the implementation begins to lose momentum and may ultimately be in trouble.

ROLE OF THE ACCOUNTING FUNCTION

What can or should the accounting organization have done to preempt the problems? Ownership and
implementation seems to have been placed in the hands of the university’s Information Technology
Officer. In reading all information posted at the Arizona State University Technology Officer website,
including all blog postings, the accounting function was never mentioned. This critical omission implies
the project is an IT responsibility instead of the Payroll function, typically under the Accounting
organizational responsibilities.

User driven implementations have a much better chance of success than IT driven implementations for
many reasons. In an ideal situation, the user recognizes the need for more accurate, timely and efficiently
obtained information which drives the request to IT for new systems. The new systems implementation
becomes the user responsibility with technical support from IT. Who knows better how to do payroll?
The people doing the job or the programmers, analysts, and consultants? A user driven implementation is
an ideal situation where the users step up and take responsibility for their job function but many times
this is not the case. Arizona State University was faced with outdated and inadequate systems driving the
need for an aggressive retrofit of the entire University. No easy task by anyone’s thought process.

Similar to eggs and bacon, where the chicken was involved but the pig was committed, it would appear
the Payroll function was involved, while the IT department was committed. All too often, computer

February 2008 1472

Proceedings of ASBBS Volume 15 Number 1

systems are viewed as an IT function when in reality business is really conducted by people using a
computer system. It is the computer that makes business more efficient and effective, but it is people who
make business possible!

In a blog statement posted on September 28, 2007 (ASU/UTO), Adrian Sannier attempted to set the
record straight regarding the Wall Street Journal article critical of ASU’s payroll system implementation.
There was no mention of the role Payroll had in the implementation, nor the Accounting function in
general. The CFO should have been intimately involved in the overall implementation from both a
financial perspective (cost containment) and operational perspective (ability to generate an accurate
payroll).

Arguably, this seeming lack of the Accounting function to be intimately involved may have contributed
to the problems. How involved was the Accounting function? Did the Accountants rely too heavily on IT
to insure data integrity? As the perception of IT technical competence increases in the eyes of the auditor,
he/she may rely more heavily on IT expertise (Brazel and Agoglia, 2005). According to
Allen, Hermanson, Kozloski, and Ramsay (2006), “…..information technology (IT) specialists
recognize more types of security risks related to enterprise resource planning (ERP) implementations than
financial auditors, yet financial auditors appear to be overconfident in their ability to recognize risks in IT
systems and often do not see a need to consult with IT specialists when facing clients with ERP systems.”
Hunton, Wright, and Wright (2004) discuss a number of control risks associated with ERP
implementations, including insufficient user training and education, data integrity problems during
conversion and lack of user buy-in. In addition, they further discuss the pressure of going “live” as soon
as conceivably possible, in order to begin maximizing system benefits as soon as possible. Ignoring or
making light of any of these potential implementation risks increase the chances of implementation
problems.

SARBANES-OXLEY MINDSET
An opportunity for Sarbanes-Oxley to shine emerges in its feared and often misunderstood Section 404.
If ASU adhered in spirit to section 404 requirements, the payroll meltdown would likely never have
occurred. Section 404 would have driven ASU to validate and prove the system accuracy related to the
new payroll system prior to implementation. According to metricstream.com “such computer systems
must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to
discern invalid or altered records”. Upon converting from the old system to the new, the validation
process would have identified the numerous problems encountered, signaling a red light to the project
implementation.

Section 404 of Sarbanes-Oxley specifically requires management to “…..assess the effectiveness of the
internal control structure and procedures for financial reporting as of the end of the company’s fiscal
year” (Beasley, M.S. and Elder, R.J., 2005). The application of effective internal control measures for
systems implementation then becomes an effective tool for controlling possible data integrity problems.
The more aggressive implementation approach used by ASU stressed “Implement” first, rather than a
more controlled and generally slower process. A more controlled process may have meant spending more

February 2008 1473

Proceedings of ASBBS Volume 15 Number 1

time to document, test, instruct, validate, and achieve user buy-in during the migration and phase-in
process. The belief is that a certain amount of some or all of the previous activities were done, but to a
level insufficient to mitigate risk. Adrian Sannier (ASU blog, 09/28/07) goes on to mention that
“extensive system testing” was done which identified defects and resources were brought to bear on the
problems. During this process, key risk factors needed to be identified and efforts made to mitigate risk or
accept the consequences for failure. If the Achilles heel for the payroll process was the web-based time
system, then under a 404 mindset, more time should have been given to this critical implementation
success factor.

The payroll process is fundamental for any large organization which can be complex, with many different
kinds of compensation plans. Software companies, such as People Soft, have spent enormous amounts of
time and money to assure their systems work as planned because of the potential disasters if the payroll
process is disrupted during an implementation. There are occasions where the software does not work as
advertised but these instances are rare. People problems typically rank high among reasons for systems
implementation difficulties. You can program a computer to do what you want, but programming people
is another matter. It can take a long time to achieve user buy-in and this one aspect can easily become the
big-bang’s Achilles hell.

ISO MINDSET
Another implementation control process is the use of International Organization for Standardization
(ISO) 9000 philosophy. ISO quality standards relate to products and services and how they meet
customer expectations. Consideration of reasonable quality standards in service delivery as outlined by
ISO would likely have resulted in a more controlled implementation process, with minimal to no errors
“The ISO 9000 family is among ISO's most widely known standards. ISO 9000 standards are concerned
with "quality management". This means what the organization does to fulfill”: (ISO website)

ƒ the customer's quality requirements, and

ƒ applicable regulatory requirements, while aiming to

ƒ enhance customer satisfaction, and

ƒ achieve continual improvement of its performance in pursuit of these objectives

Implementation under an ISO 9000 mindset would suggest in the case of Arizona State University, the
customer was really the employee, as Payroll’s “product” was a timely and accurate paycheck. In this
case, the customer has a direct role in the service – that of data entry via the web-based time system. This
example is similar to a company that changes their Order Entry system and the new system confuses the
staff to the point customer orders cannot be entered or are entered with errors.

February 2008 1474

Proceedings of ASBBS Volume 15 Number 1

IGNORING THE HUMAN FACTOR

Management responsible for significant systems changes cannot ignore the impact to human behavior.
Working in a University provides an opportunity to reflect on the significance of Arizona State
University’s web-based time system. Arizona State University hourly workers likely consist of a broad
variety of custodial, maintenance, and secretarial staff. Many of these employees could possibly not be
computer literate or are minimally comfortable using computers. The new system should have been pilot
tested using real workers and at a transactional volume sufficient to flush out problems. This level of
testing helps reduce the risk of problems and also helps achieve employee buy-in. The trade-off for better
control is increased implementation time.

IMPLEMENTATION SUCCESS OR FAILURE?

The definition of a systems implementation failure is not always cut and dry. There are some different
ways to look at whether a systems implementation project was a success or failure. One approach that
was adopted by many organizations years ago is still valid today. That is the ABCD classification method
proposed by Thomas Wallace (1985). While the method relates specifically to MRPII implementations,
the logic translates easily to an ERP application. Companies that would be considered a Class A user,
have done their job well. The system is used as intended and the business relies on the output for decision
making. Data integrity is high and users are knowledgeable. Class B users have not quite gotten to using
the system as intended. There may be partial sections of Modules that have not been implemented and the
business is still in a learning mode. Data integrity problems may also continue to hamper full use of the
system. Class C users have implemented the software but are not yet successfully running the business
with it. Data integrity problems exist, users have not been properly trained or educated in the software’s
use, and data output is error prone and suspect. Class C users have “implemented” the software but the
business has not achieved any of the expected results. This is an implementation in trouble. In a Class D
implementation, it would not be unusual for the company to spend the same amount of money for
implementation as a Class A user, with the exception of money invested in educating the users. Class D
users have not achieved any significant results for their efforts. The lack of training and educating both
the users and constituents greatly affects the success or failure of a systems implementation.

Another approach suggests if the implementation is abandoned, then it is indeed a failure. Noting from
Arizona State University’s Technology Officer statements (ASU blog 09/06/07) there are a number of
examples of university systems implementation problems and outright implementation abandonments.
Although there were problems in the payroll portion of the implementation, Arizona State University did
not abandon the implementation so by this definition, the implementation was a success.

CONCLUSION
Was Arizona State University’s implementation a failure? By all accounts, it was a success. One small
portion of the ERP implementation did have a major short term problem, creating significant ill-will
among the hourly workers. Using Wallace’s approach to whether the Payroll system was a success, the
initial grade would have been a “C”. After significant manual intervention and further education and
refinement, the implementation would have been at the “B” level. The stated error rate was apparently

February 2008 1475

Proceedings of ASBBS Volume 15 Number 1

reduced from 6% under the old system to 4% under the new system. While a 33% decrease in the error
rate is significant, an error rate less than 1% is what might be considered acceptable. A 4% error rate
translates into almost 500 worker paychecks being incorrect each pay-period and that should not be
acceptable to anyone at Arizona State University. An error rate less than 1% would make them a Class A
user in many eyes.

REFERENCES
Allen, Robert D., Dana R. Hermanson, Thomas M. Kozloski, Robert J. Ramsay (2006). “Auditor
Risk Assessment: Insights from the Academic Literature”. Accounting Horizons, Volume 20,
Number 2, 157-177.

ASU (2007). Arizona State University, “How Deep Was the Hole”? Jenny. September 3, 2007,
https://uto.asu.edu/blog/2007/09/03/how-deep-was-the-hole/

ASU (2007). Arizona State University, “Regent’s Vanilla”, September 6, 2007, Independent
CIO’s Report. https://uto.asu.edu/blog/2007/09/06/regents-vanilla/

ASU (2007). Arizona State University, Adrian Sannier’s Response to the October 8, 2007 Wall
Street Journal article critical of its implementation. https://uto.asu.edu/blog/2007/09/28/wsj/

Beasley, Mark S. and Randall J. Elder (2005). “The Sarbanes-Oxley Act of 2002: Impacting the
Accounting Profession”. Pearson-Prentice Hall, Upper Saddle River, New Jersey.

Brazel, J. F., and C. P. Agoglia (2005). “An examination of auditor planning judgments in a
complex AIS environment: The moderating role of auditor AIS expertise”. Working paper, North
Carolina State University.

Hunton, J. E., A. M. Wright, and S. Wright (2004). “Are financial auditors overconfident in their
ability to assess risks associated with enterprise resource planning systems”? Journal of
Information Systems, Volume 18, Number 2, 7-28.

ISO. International Organization for Standardization, Quality Management,

www.iso.org/iso/iso_cafe_quality_management.htm

Metric Stream. Understanding, Experience, and Technology for Compliance. “Reducing the cost of Sox
compliance – learning from ISO 9000 implementation”. www.metricstream.com.

Wallace, Thomas F. (1985). “MRPII Making it Happen”. Oliver Wight Limited Publications, Inc., The
Book Press, Brattlesboro, Vermont.

WSJ (2007). Wall Street Journal, (Eastern Edition). New York, N.Y. “Software Implementation: Fix-It-
Later is a Bad Idea”, October 8, pg. A.17.

February 2008 1476