Sei sulla pagina 1di 7

Proceedings of ASBBS

Volume 15 Number 1

The Accountants Role in an ERP Implementation

Sellani, Robert J. Nova Southeastern University

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


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


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


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), “…


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 “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 “…

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


the effectiveness of the

February 2008


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


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


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.


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,

ASU (2007). Arizona State University, “Regent’s Vanilla”, September 6, 2007, Independent CIO’s Report.

ASU (2007). Arizona State University, Adrian Sannier’s Response to the October 8, 2007 Wall Street Journal article critical of its implementation.

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,

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

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