Performance Audit:

Pre-Implementation Review
of the ERP System

November 2005

City Auditor’s Office

City of Atlanta

File #05.02
 November 2005
CITY OF ATLANTA
City Auditor’s Office
Leslie Ward, City Auditor
Performance Audit:
Why We Did This Audit Pre-Implementation Review of
We included this topic in our 2005 audit the ERP System
plan because of the city’s past problems in
implementing information systems, notably What Is the City’s ERP System?
PeopleSoft in 1999. PeopleSoft was
heavily modified and lacked controls, which An Enterprise Resource Planning (ERP) system
created problems the city is still coping with integrates all departments and functions across an
today. This audit should help ensure that organization onto a single computer system that aims to
effective controls are part of the new ERP serve all users. The city is implementing an ERP system
system and the implementation process. to automate and integrate most of its business processes
and to produce and access current information quickly.
The planned completion date for the financial and
What We Found procurement portions of the ERP system is October 2006,
Creating 43 interfaces between the ERP followed by the human resources and payroll modules in
system and other applications is a major January 2007.
part of implementation. These systems
transfer data to other organizations or
What We Recommended
provide specialized functions that cannot
be done in the ERP system itself. Estimate the additional cost of system implementation at
the airport and add the cost to the ERP project budget.
Although the Department of Aviation
reported spending $12.1 million on an ERP Prepare written policies and procedures for all manual
system that was implemented only two and processes that will not be automated in the ERP system.
half years ago, the department will have to
discontinue using that system and interface Develop a formal plan for system access that user
its current information systems with the departments must follow when the ERP system is
new ERP system. The cost of the interface operational.
is not yet known.
Develop a formal, written data conversion plan that
The ERP system will not be able to defines clean data and specifies the source and
automate all city processes. As a result, destination of all data items being converted.
some processes will still be done manually
and will require additional controls. Prepare and test a disaster recovery plan for the ERP
system to ensure it is adequate before the system is
Data in current systems should be operational.
corrected before transfer to the ERP
system. In addition, the ERP system uses Streamline HR/Payroll practices to best configure the ERP
a single database, which makes having a system: a.) consolidate city employees into as few pay
disaster recovery plan an essential part of groups as possible; b.) strictly enforce the 90-day waiting
the transition to the new system. period for health benefits by eliminating the option of
employees’ paying the full cost; c.) analyze the fiscal
Streamlining HR/payroll processes will help impact of reducing or eliminating the 90-day waiting
the city to achieve the benefits of an ERP period; d.) process all taxable employee benefits through
system. payroll; e.) eliminate comp time for department heads and
other senior management staff; and f.) eliminate donated
For more information regarding this report, please
contact Gerald Schaefer at 404.330.6876 or leave. Draft changes to legislation or administrative
[email protected]. regulations as appropriate to accomplish these changes.
 CITY OF ATLANTA
LESLIE WARD City CITY AUDITOR’S OFFICE AUDIT COMMITTEE
Auditor 68 MITCHELL STREET SW, SUITE 12100 W. Wayne Woody, Chair
[email protected] ATLANTA, GEORGIA 30303-0312 Henry A. Kelly, Vice-Chair
(404) 330-6452 Fred Williams
FAX: (404) 658-6077 Mayor Shirley Franklin
Council President Lisa Borders

November 21, 2005

Honorable Mayor and Members of the City Council:

We undertook this review of the city’s new ERP system because system implementation efforts
of this magnitude are risky. The system represents a substantial investment of $22 million, the
city’s current business processes will undergo significant change as part of the process, and the
city has experienced problems in the past when implementing information systems.

Our focus in this pre-implementation review was to provide guidance to the city in establishing
proper controls before the ERP system is implemented. We provided guidance on how to
separate incompatible duties and responsibilities within the system and on establishing
appropriate access to the system. We also provided guidance on the importance of having a
sound data conversion plan and the value of having a disaster recovery plan before the ERP
system is implemented. Lastly, we recommended that the city change more HR/Payroll
processes to take full advantage of the ERP system implementation. We believe that these
changes will further enhance the city’s practices and help simplify the new ERP system.

We issued two memoranda to the steering committee and project team at key points during the
pre-implementation process. We made a number of recommendations to configure the system
to improve controls and to streamline or strengthen control over manual processes that will be
performed by the city after the ERP system is implemented. These memoranda, along with the
city’s responses to our recommendations, are included as appendices to the report. The
responses to these interim audit memos are encouraging. The city agrees in principle to most
of our recommendations. Management disagreed with two recommendations related to human
resources: to discontinue paying compensatory time to executive employees and to eliminate
donated leave. We continue to think these recommendations are good ideas and discuss them
more fully in our upcoming performance audit of city payroll practices.

The Audit Committee has reviewed this report and is releasing it in accordance with Article 2,
Chapter 6, of the City Charter. We appreciate the courtesy and cooperation of city staff and
consultants hired by the city for the ERP system implementation. The audit team for this
project included Lesia Johnson and Gerald Schaefer.

Leslie Ward Wayne Woody

City Auditor Audit Committee Chair
Pre-Implementation Review of the ERP System

Table of Contents
Introduction ................................................................................................................... 1
Background................................................................................................................. 1
Audit Objectives ..........................................................................................................
6
Scope and Methodology ...............................................................................................
7
Observations and Recommendations................................................................................ 9
Summary ....................................................................................................................
9
Some Current Systems and Manual Processes Will Remain in Place .............................. 11
Effective Controls Will Require Preventive Measures and Limits on System Access ......... 12
Data Transferred to the ERP System Must be Accurate and Reliable ............................. 16
Disaster Recovery Plan for New System is Critical ........................................................ 18
Additional HR/Payroll Process Changes Could Simplify New System .............................. 21
Consolidate City Employees into Fewer Groups ........................................................ 21
Eliminate Optional Payment for Early Health Benefits ............................................... 22
Include Taxable Employee Benefits in Payroll Process .............................................. 22
Eliminate Compensatory Time for High-Level Salaried Employees ............................. 23
Discontinue Donated Leave and Strengthen Controls Over Advanced Sick Leave........ 24
Recommendations ........................................................................................................ 27
Exhibits
Exhibit 1 ERP Program Organizational Structure ................................................. 5

Exhibit 2 ERP Implementation Phases ................................................................ 5

Exhibit 3 Systems to be Replaced by ERP ........................................................... 6

Exhibit 4 Framework for Separating Duties ......................................................... 15

Exhibit 5 Phases of Data Conversion Plan ........................................................... 18

Exhibit 6 City Pay Groups .................................................................................. 21

Appendices
Appendix 1 “Oracle To-Be Processes” Memorandum from City Auditor
to ERP Program Director, August 15, 2005 ........................................ 33
Appendix 2 “Oracle ERP Target Process Blueprint” Memorandum from
City Auditor to ERP Program Director, September 1, 2005 .................. 41
Appendix 3 Bibliography: ERP System Implementation and Controls ...................... 45

Appendix 4 Planned Modules for the ERP System .................................................... 47

Appendix 5 Examples of Incompatible Duties .......................................................... 49

Appendix 6 Audit Response – ERP Steering Committee..................................... 51 - 53

Introduction

This pre-implementation review of the ERP system was conducted

pursuant to Chapter 6 of the Atlanta City Charter, which
establishes the City of Atlanta Audit Committee and the City
Auditor’s Office and outlines their primary duties.

This review, primarily prospective in nature, meets the definition

of a performance audit under government audit standards. A
performance audit is an objective, systematic examination of
evidence to independently assess the performance of an
organization, program, activity, or function. The purpose of a
performance audit is to provide information to improve public
accountability and facilitate decision-making. Performance audits
encompass a wide variety of objectives, including objectives
related to assessing program effectiveness and results; economy
and efficiency; internal control; compliance with legal or other
requirements; and objectives related to providing prospective
1
analyses, guidance, or summary information.

This audit was included in our office’s 2005 audit plan because of
past problems encountered by the city in implementing
information systems, most notably PeopleSoft. The city
experienced significant difficulty in implementing PeopleSoft in
1999. The system was heavily modified and lacks controls which
created problems the city is still coping with today. This audit was
done to review proposed processes and controls before the ERP
system is implemented. It will be followed by one or more reports
on the second phase of implementation during 2006 and 2007.

Background

What is an ERP system? An Enterprise Resource Planning

(ERP) system integrates an organization’s departments and
functions into a single computer system that aims to serve all
users. Through an ERP system, the city aims to automate and
integrate the majority of its business processes and produce and

1
Comptroller General of the United States, Government Auditing Standards, Washington, DC:
U.S. Government Accountability Office, 2003, p. 21.

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 access current information quickly. Currently, the city uses
several computer systems that are organized around departments
and rely heavily on manual processes and controls. An ERP
system, in contrast, is organized around business processes, using
a single system to record a transaction from beginning to end.
Several firms market ERP products. The city will implement
Oracle eBusiness Suite (Public Sector), version 11i.

A successfully implemented ERP system can benefit the

city. An ERP system can ease the exchange of data and facilitate
communication between city departments. The city’s current
information systems are not truly connected; at best, they merely
pass data from one to another. This process results in time
delays, data redundancy, and increased costs. The ERP project
manager identified the following benefits that the city should
realize from the new system:

• Reduce the timeframe and effort required to create financial

statements and reports.
• Move from a cash to accrual accounting method, which will
improve revenue recognition, and reduce consulting and
auditing fees needed to do cash to accrual conversion.
• Integrate financial planning and modeling tools to provide
immediate analytical capabilities.
• Improve information for contract compliance and auditing.
• Better analyze, manage, and track contracts.
• Better control discretionary spending, and reduce procurement
life cycle.
• Automate data at the department and employee level and
implement electronic personnel records.

The project manager estimated that an ERP system can save the
city about $18 million annually in reduced operating costs and
lower fees paid to outside consultants and auditors.

Successful implementation must address major risks.

Although the ERP system can provide considerable benefits to the
city, the process of implementing such a system can expose the
city to sizeable risks.

As with most technologies, ERP system implementations have had

notable difficulties in both private and public sectors. Federal
agencies and state governments have seen projects double in cost
and run years behind schedule. Other agencies have seen

2Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 2

 productivity decline, have been unable to close their books at
year’s end, or have been unable to pay employees and vendors on
time. Unsuccessful ERP implementations have forced companies
into costly shipping delays or even into bankruptcy.

Implementing an ERP system requires significant investment of

capital, time, and other resources from an organization. It has
been estimated that half of the issues in ERP system failures are
not technical, but are related to human and organizational
problems. Many of the failures can be attributed to inadequate
training and poor management of organizational changes.
As a result, the major implementation risks, listed below,
emphasize these factors:

• Not understanding the significance of an ERP system. Many

ERP projects are not successful because they are perceived as
IT initiatives and therefore do not have management’s support
necessary to guarantee success. The ERP system should be
viewed as a business project and have strong sponsorship and
ownership from all city departments.

• Not committing the right resources to the project. Many ERP

projects run into difficulty because the wrong people are
allocated from the organization. The city should assign staff
that have adequate knowledge about city operations, but
should also be creative and capable of challenging the status
quo when necessary.

• Not managing the change effectively. Successful change

management is one of the most important features in
determining the success of ERP projects. Effective change
management ensures that the city’s employees are ready,
willing, and able to embrace the new businesses processes
and systems. The city should provide training to staff that
explains the business objectives of the ERP project and the
new business processes, their new roles, and all aspects of the
system.

• Not managing benefits. Most ERP projects report in great

detail on the cost and time parameters of the project, but very
few actively report on benefits attainment. The city should
manage the ERP project to ensure that all of the benefits are
delivered.

3Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 3

 • Not embracing integration. Many organizations resist the level
of integration delivered and encouraged by ERP systems and
attempt to retain the existing organization structure. The city
should consider significant changes to its organization
structure and management roles to extract the maximum
benefits from an ERP system.

• Not planning for the end of the project. Many organizations

fail to consider the long-term implications of introducing an
ERP system until the end of the project, and consequently
they degrade the outcome of the project. The city needs to
consider how the ERP system will be supported in the long
term and which aspects, if any, will be outsourced.

The city’s implementation approach should be able to

address risks. The city has structured the ERP system
implementation in a way that should enable it to manage the
major risks. The project has the sponsorship of the mayor and
ownership by senior management through the project’s steering
committee. The implementation team includes city staff who are
knowledgeable about the processes being automated, as well as
consultants hired for their expertise in ERP systems. The project
also includes teams assigned to
change management and training,
as well as a group specializing in
the system’s technology. The City
also has hired a firm to provide
ongoing review and quality
assurance for the project. Exhibit 1
shows the organizational structure
of the project, known as the Atlanta Total Solution (CATS) Project
team.

With a budget of $22 million, the ERP system implementation

includes two major phases spanning about two years as shown in
Exhibit 2.

4Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 4

 EXHIBIT 1
ERP PROGRAM ORGANIZATIONAL STRUCTURE

Program Sponsor
Mayor
Chief Operating Officer (Chair)
Deputy Chief Operating Officer
Chief Information Officer
Steering Committee
Chief Financial Officer Members Quality Assurance
Chief Procurement Officer Independent Validation
City Attorney and Verification Team
Commissioner of Human Resources
City Auditing Team
IBM - Executive

Program Director

IBM Project Manager

Purchasing Change Human

Financial Technical
Team Management Resources/Payroll
Team Team
Team Team

EXHIBIT 2

ERP IMPLEMENTATION PHASES

Phase Time Period Description

I 4.4.05 to 9.15.05 Reviewing and revising current business proce

for the city to use with the ERP system.

II 9.1.05 to 3.30.07 Building and testing the ERP system and traini
staff on how to use it.

Source: CATS Project Plan

The city’s ERP system will include financial, procurement, and

human resource functions. These functions comprise 27 separate
modules listed in Appendix 4, and two additional modules are
under consideration. The planned completion date for the
financial and procurement portions of the system is

5Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 5

 October 16, 2006, followed by the HR/payroll modules on
January 1, 2007. After these “go live” dates, the consultants will
continue to provide support for three months to assist in the
transition.

The ERP system will replace many of the city’s current information
systems. (See Exhibit 3). Most of the outgoing systems are part
of MARS-G, the city’s current financial management software.

EXHIBIT 3

SYSTEMS TO BE REPLACED BY ERP

Information System Current Use

MARS-G Fixed Asset City assets

MARS-G General Ledger General ledger, grants, and projects

MARS-G Accounts Payable Accounts payable

MARS-G Purchasing Purchasing

MARS-G Buzz Budget and planning

MARS-G Financial Controller Encumbrances

MARS-G Budgetary Controls Budgetary controls

PeopleSoft Human resources records, payroll,

and benefits

FileMaker Pro Reports

QuickBooks Leases, lease billing, and receivables

Real Estate Database City land

Source: IBM’s Oracle ERP Target Process Blueprint

Audit Objectives

This report assesses and provides guidance on processes and

controls to be adopted in the ERP system implementation. The
report addresses the following questions:

• What plans are in place to connect the ERP system to other

city information systems?

6Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 6

 • What manual processes will remain if no further changes to
business practices are made?

• Do proposed processes for the new system provide effective

controls and ensure appropriate levels of access for system
users?

• How will the city confirm that the data transferred to the ERP
system is accurate and reliable?

• How will the city ensure continuity of business operations with

the new system in place?

• Could additional city business practices be streamlined in

conjunction with the ERP system implementation?

Scope and Methodology

This audit was conducted in accordance with generally accepted

government auditing standards. We conducted our field work
from July 2005 through September 2005. The audit covered
proposed business processes for the ERP system implementation.
The audit methods included:

• Interviewing city staff and consultants regarding the proposed

new processes.

• Reviewing the “to-be” processes as presented in “conference

room pilots” (CRPs) by the project team. A memorandum
summarizing this work was released on August 15, 2005 and
can be found in Appendix 1.

• Reviewing the CRP scenarios and scripts.

• Reviewing the ERP “target process blueprint” document. A

memorandum on this work was released on
September 1, 2005 and can be found in Appendix 2.

• Researching professional literature for information on best

practices in ERP system implementations and controls. A
bibliography of this literature can be found in Appendix 3.

7Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 7

 • Reviewing documentation related to Oracle security and
control.

• Reviewing similar work by auditors in other jurisdictions.

The audit staff for this project worked with the ERP
implementation team in an advisory capacity. They have not
participated in management decisions about control design or
other facets of system implementation. In all respects, their
participation has followed government audit standards for
independence.

8Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 8

Observations and Recommendations

Summary

What plans are in place to connect the ERP system to

other city information systems? The ERP system will replace
many of the city’s current information systems, but some existing
systems will still be needed. As a result, the ERP system
implementation will include 43 interfaces to connect the new
system and other applications. This includes incorporating a new
treasury application because the Oracle ERP component for
treasury did not meet the city’s needs. In addition, the airport
ERP system implemented in 2003 will be replaced at an additional
cost to the airport. The Department of Aviation reported spending
$12.1 million on its customized Oracle system, which cannot easily
be upgraded and incorporated into the new city system.

What manual processes will remain if no further changes

to business practices are made? The city wishes to avoid
substantial changes to the ERP system to fit all of its business
processes. As a result, several current processes will not be
automated by the new system. These processes will still be done
manually after the ERP system is implemented and therefore will
require additional controls outside of the system. Appendix 2 of
this report summarizes the highest-risk manual processes
identified during the pre-implementation phase, along with our
recommendations on controls.

Do proposed processes for the new system provide

effective controls and ensure appropriate levels of access
for system users? Previous audits done by our office have
identified inappropriate access to city systems, which increases
the risk of error and fraud. To reduce the risk, city employees
should have only the access needed to perform their duties.
Personnel authorized to access sensitive areas of the system
should be especially limited. Separating incompatible business
duties and responsibilities also is a critical access control. The city
should ensure that no employee is responsible for two or more of
the following functions for a single transaction: record keeping,
asset custody, authorization, and reconciliation.

9Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 9

 How will the city ensure that the data transferred to the
ERP system is accurate and reliable? Current city systems
have data integrity problems that should be corrected before
information is transferred to the ERP system. The city plans to
transfer data from 43 different databases to the new system,
making data accuracy and data conversion planning critical issues.
The city should ensure that data transferred to the ERP system is
accurate and reliable by creating a formal data conversion plan, a
definition of clean data (i.e. what constitutes acceptable data),
and written specifications for the source and destination of all
data items to be converted. Lastly, the conversion should be
tested to validate that the conversion was carried out as intended.

How will the city ensure continuity of business operations

with the new system? Since an ERP system uses a single
database for all of its applications, a failure in any part of the
system can affect all of its operations, making a disaster recovery
plan an essential part of the transition to the new system. The
Department of Information Technology, with help from an outside
firm, is beginning to create such a plan for the city’s information
systems. The city should continue with its disaster recovery
planning efforts and have a plan in place when the ERP system is
launched.

Could additional city business practices be streamlined in

conjunction with the ERP system implementation? The
city could make several changes in its HR/payroll processes that
would streamline operations and simplify some aspects of ERP
implementation. Our recommendations for process changes, most
of which come from our audit of the city’s payroll process, include
the following: consolidate city employees from six pay groups
into as few groups as possible, paid at the same frequency, to
simplify payroll operations; eliminate compensatory time off for
department heads and other senior management staff;
discontinue the practice of allowing employees to pay for health
benefits without the required 90-day waiting period which will
eliminate the need for additional controls; assess the fiscal impact
of reducing or eliminating the waiting period for health benefits;
eliminate donated leave which will require additional controls and
processes in the ERP system and strengthen controls over
advanced sick leave; and process reimbursed moving expenses,
which may include portions that are taxable, as well as any other
taxable employee benefits, through the payroll process so that
they are reported as income as required by the IRS.

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

Some Current Systems and Manual Processes Will Remain in
Place

Choices between modifying the Oracle ERP software and changing

city processes to fit the new software are a major factor in
decisions about how the new ERP system will be implemented.
The city’s goal is to limit modifications to the software as much as
possible, because such changes increase short-term costs and can
have long-term consequences. As a result, implementing the ERP
system will not only replace many of the city’s current information
systems, but will also require building interfaces to connect the
new system with other systems that remain, as well as developing
controls over the manual processes that will not be automated.

Connecting ERP and other systems is part of

implementation. Through the ERP system, the city can
eliminate many of its current information systems; however, there
will still be a need to connect the ERP system with some existing
systems. These connections are needed to transfer data between
the ERP system and other city systems for specific functions, or
between the city and other organizations. These transfers are
called interfaces and act as bridges between the applications and
the ERP system. Once the ERP system is implemented there will
be 43 interfaces between the system and other applications.
They include, for example, connections with the city’s new water
and sewer billing and customer information system, the city
employees’ credit union, and a new treasury application that
better meets the city’s needs than the ERP system’s treasury
component. Building these interfaces is a major part of the ERP
system implementation.

Airport ERP system will be replaced at additional cost.

The Department of Aviation implemented eight Oracle financial
and procurement modules plus three other software programs to
manage property, capital projects, and maintenance. According
to department staff, the Department of Aviation implemented its
ERP System in May 2003 at a cost of $12.1 million. This system,
however, is an older version of Oracle that has been customized
and, therefore, cannot easily be upgraded. These factors led the
airport to discontinue use of its current system and adopt the
city’s ERP system for financial management. The airport’s
specialized software also must be interfaced with the city’s new
system. As of September 2005, it is not clear how much it will

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 cost to interface these systems; however, it has been determined
that the costs will be paid with airport funds. It is clear, however,
that the airport’s previous expenditures on its Oracle
implementation will not correspondingly reduce the cost of the
current implementation.

Manual processes will require additional controls. Because

the city plans to minimize the degree of change to the ERP
system, the new system will not automate all current processes
used by the city. As a result, some processes will change, but
others will still be done manually.
Consequently, controls over such
The city’s goal processes will have to be enforced
is to adapt its outside the ERP system. Our review
processes to
of the target process blueprint
the new
system focused on these manual processes
and the controls that will be needed
(see Appendix 2).

The city has sound reasons for minimizing changes to the ERP
software. When such changes are made, it affects short-term
implementation costs because it requires programming services
that are costly. Further, Oracle may not support customized
software, so the risks of maintaining the system in the long term
would be borne more heavily by the city. When system upgrades
are needed, the programming changes would be required again.
In some cases, the system may have been modified too much for
an upgrade to be practical or even possible. The city has
experienced this problem with its PeopleSoft system and with the
Oracle system at the airport.

Effective Controls Will Require Preventive Measures and

Limits on System Access

The nature of ERP systems in general, as well as previous audit

findings on the city’s current systems, suggests that certain types
of controls should be emphasized in the city’s new system. First,
the controls built into the system must be used to prevent
problems before they occur, often by limiting the data the system
will accept and the operations the system will perform. Second,
employee access to the system must be carefully structured to

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 match their roles and to prevent individuals from having such
broad access that the risk of error and fraud is increased.

ERP Systems require different types of controls. In an ERP

system, controls shift from detecting to preventing problems.
Detective controls catch problems after they occur, whereas
preventive controls are designed to stop problems before they
occur. ERP systems entered into have preventive controls built
into their operations, many of which are lacking in the city’s
current systems. Additionally, the ERP system will rely more on
configuration settings, which control what can be processed by
the system. A common problem encountered during
implementation of an ERP system is eliminating traditional
controls without replacing them with other effective control
measures. The control recommendations in our memoranda on
Phase I (see Appendices 1 and 2) are aimed at avoiding this
problem.

Employee access to new system must be carefully

managed. High integration among the city’s business functions
allow increased access to data. The city needs to be careful that
the level of access given to employees is appropriate. A key
objective for securing the ERP system database is to ensure that
direct user rights to the database are as limited as practically
possible. Furthermore, security and controls to the database
should be built into the new ERP system rather than added after
the system goes live.

Previous audits identified inappropriate access to current

systems. The March 2004 audit, Payments to Deceased
Pensioners (pension audit) identified employees that had access
to too many functions. Employees, for example, had access to
master files, master file maintenance, and payroll. Such access
allows a single individual to create a master record for an
employee, change and update the employee’s information, and
authorize payments to the employee. A follow-up done on the
pension audit in March 2005 found that employees still had access
to too many functions.

The 2005 payroll audit also found employees processing payroll at

the department level who were performing incompatible job
functions. In various work locations, the same person maintained,
administered, and distributed payroll, and in one case, one person
both prepared and approved payroll. We also found a location

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 where the same person prepared and approved turnaround
documents, which are used to change an employee’s position,
pay, or status.

The city’s external auditors have found many cases of

inappropriate access as well, ranging from incompatible duties to
broad access for terminated employees and those whose jobs
have changed.

Access should be based on roles. Users should have only the

access needed to perform their duties. The roles that personnel
fulfill within an organization should be translated to system access
permissions necessary for them to perform their daily business
activities. When employees take on new responsibilities or
change positions within the organization, their access should be
changed to correspond to the level of access required for them to
perform their new job responsibilities.

Access to sensitive areas should be limited. In our review of

the to-be processes (see Appendix 1) that the city foresees using
when the ERP system is implemented, we identified several areas
that access should be limited, such as the ability to update the
chart of accounts, to make prior period adjustments to the
general ledger, and the ability to write-off accounts receivable.
Additionally, the city should restrict the following functions
(organized by module) to authorized personnel only.

General ledger module

• Access to the entry, import, definition, setup, and generation
of journal entries.
• The ability to reverse journal entries.
• Access to the Financial Statement Generator (FSG) report
definition and generation.
• The ability to open and close periods
• The ability to approve and post journal entries

Accounts Payable module

• Access to supplier master files.
• Access to invoices, accounting periods, credit/debit memos,
setup and distribution sets

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 Other modules
• Access to add, change, or delete the archive and purge
functionality.
• The ability to input, change, cancel, or release credit memos.
• The ability to input, change, or cancel goods received.

Lastly, access control processes should be in place to create,

change, and terminate user access. These processes should be
fully documented and continually refined throughout the ERP
system implementation.

Incompatible business functions should be separated.

Certain types of duties should be done by different employees as
a control measure to ensure appropriate data entry and to
prevent misuse of company resources. Consequently,
incompatible business duties and responsibilities should be
separated. This principal applies both to functions (i.e. what a
person can do) and to information (i.e. what a person can see).

Incompatible duties assigned to one employee increase the risk of

inaccurate or fraudulent transactions. To control this risk, no
employee should be responsible for more than one of the
following types of functions for a single type of transaction. (See
Exhibit 4.)

EXHIBIT 4
FRAMEWORK FOR SEPARATING DUTIES

Record Keeping Asset Custody

Creating and maintaining Access to or control of physical assets
department records

Authorization Reconciliation
Reviewing and approving transactions Assurance that transactions are proper

Source: Institute of Internal Auditors (Copyright 2004 Deloitte Development LLC)

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 Examples of the risks of combining these types of functions are
shown below:

Record Keeping and Asset Custody: An employee is responsible

for recording inventory and has access to the same inventory. A
risk exists that the employee can steal city inventory.

Record Keeping and Authorization: An employee has access to

set up a supplier in accounts payable and can authorize an invoice
for payment. A risk exists that the employee can pay themselves
with city funds.

Record Keeping and Reconciliation: An employee has the ability

to write off accounts receivable and is responsible for reviewing all
write-offs. A risk exists that the employee will write off debts that
should not be.

Asset Custody and Authorization: An employee is responsible for

a fleet of city vehicles and is responsible for performing a physical
count of the vehicles at year end. A risk exists that the employee
can steal a city-owned vehicle.

Asset Custody and Reconciliation: An employee collects cash

generated from parking tickets and then is responsible for
balancing his cash drawer at the end of the day. A risk exists that
the employee can take the city’s cash.

Authorization and Reconciliation: An employee has the authority

to authorize a payment from a city account and has the
responsibility of reconciling the bank account at the end of the
month. A risk exists that the employee can misappropriate city
funds.

A more detailed list of incompatible duties that should be

separated is provided as Appendix 5 of this report.

Data Transferred to the ERP System Must be Accurate and

Reliable

The city plans to transfer information from 43 different databases

to the ERP system. These data currently reside in MARS-G,
PeopleSoft, QuickBooks, Grants Management, and in various

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 billing systems. When data are moved from one location to
another and from one format to another, there is always a risk
that the data will be corrupted, that some will be lost, and that
data will be added unintentionally. It is vital that the data
converted to the ERP system are valid, pertinent, and in the
proper format.

Current systems have data integrity problems. ERP systems

require extensive interfaces and data conversions, which make the
importance of maintaining data integrity essential. If inaccurate
data is entered in one module of the ERP system then other
modules are exposed to the bad data. In previous audits, we
have found numerous data errors. Errors in the personnel and
payroll information in PeopleSoft, for example, included the
following:

• Employees with multiple employee identification numbers.

• Payments processed without a social security number or with
an obviously invalid social security number such as
999-99-9999.
• Employees with the same position number at the same time
for multiple pay periods.
• Employee records with obviously erroneous name changes.
Their names had been changed to the name of an
organization.
• Employee hire dates of January 1, 2000, the date of the city’s
conversion to PeopleSoft, instead of their actual hire date.
• Employee records with names, birth dates, gender, or other
information that did not match their social security numbers.

City is responsible for data conversion. The quality

assurance firm for the ERP implementation identified data
conversion planning as a high risk in September 2005. Data
conversion is the responsibility of city staff. The city expects to
have a data conversion plan finalized by November 2005. The
plan should provide for the following four phases, identify the
responsible parties, and establish deadlines for the work to be
done. The ERP Implementation Steering Committee should
monitor the implementation of the data conversion plan.

Data conversion provides an ideal opportunity to clean the data to

make sure that data is worth using in the future. The data
conversion process should consist of four phases, which are
described in Exhibit 5.

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 EXHIBIT 5
PHASES OF DATA CONVERSION PLAN

Phase 1: Planning - All data conversion work needs to be

planned. A formal plan must exist that comprehensively covers
all aspects of the conversion and makes a realistic estimate of
the time and resources needed.

Phase 2: Data Cleansing - A significant amount of time should

be budgeted for this manually intensive phase. A definition of
“clean data” must be established providing answers to the
following questions: Which fields must contain data items? Are
there any required relationships between different data items?
Are the data items’ values actually correct? A thorough analysis
is required to ensure that all “clean data” criteria are identified.
Old system documentation can assist in this process. Before
any cleansing takes place, a backup of the data should be
created, and a copy of the database should be used to avoid
potential data corruption. Errors found by automated checking
must be investigated and corrected manually. Lastly, the original
data must be updated as errors are discovered.

Phase 3: Conversion - The relationship between the old

database and the new ERP system should be properly defined.
Additionally, there should be written specifications of the source
and destination of all data items being converted, any data items
that are created by the process, and data items that will be
deleted. As with the data cleansing phase, the whole process
should be tested on copies of the database before the actual
conversion takes place.

Phase 4: Validation - Once all of the phases have been

completed, the database needs to be checked to ensure that the
conversion was carried out in the way it was intended. To
facilitate this validation, tests should have been created and
documented in advance during the planning phase.

Source: Alan Oliphant, “Data Conversion”, IT Audit, vol. 5, 11.01.02, pp. 2-5.

In addition to the converted data, the city should maintain the

historical data from its current systems that will not be transferred
to the ERP system. Keeping this historical data is important as it
may be the only record of past transactions and events. The city
should ensure that this data is kept in a secure location and is
accessible only to authorized personnel.

Disaster Recovery Plan for New System is Critical

ERP system components are interdependent and rely on a single

database. This makes a disaster recovery plan, which would

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 outline methods for continuing operations and recovering data in
the event of a major system interruption, especially important.
The city has begun developing a disaster recovery plan for its
information systems. This is a first step toward a more
comprehensive business continuity plan for all essential city
operations. Such a plan was recommended by the city’s external
auditors in their 2004 report on internal controls, a suggestion
with which we concur.

Single failure has major implications in ERP systems. An

ERP system is essentially a single-point-of-failure system as all
data is stored within one database. Since the entire system is
linked together, a failure in one part of the system affects the
other parts as well. Failures may result not only from disasters
such as fires, floods, or other causes of property damage, but also
from more mundane causes like hardware or software
malfunctions.

City has begun disaster recovery planning for information

systems. The Department of Information Technology, with help
from an outside firm, is in the process of creating a disaster
recovery plan for the information systems they support, which will
include the ERP system. The city should base its disaster recovery
strategy on two key parameters:

• How long can the organization afford to be without a

particular IT system?
• How much data can the organization afford to lose or recreate
after recovering the backup of systems and data?

In general, the shorter the data recovery time needed, the higher
the data recovery costs.

Data recovery options include (ranked in descending order from

the fastest recovery time and the highest cost of adoption):

• Hot site: An alternate facility which is fully equipped with the

resources needed to recover business processes almost
immediately. The location and size of a hot site should be
proportionate to the amount of equipment and resources
needed to ensure complete business recovery.
• Warm site: An alternate facility only partially equipped with
resources such as hardware, communications interfaces,
electricity, and environmental conditioning. Such a facility

1Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 1

 may enable an organization to resume business operations
within six to 12 hours following a disaster.
• Cold site: An alternate facility that offers only environmental
conditions, such as air conditioning and raised flooring. The
equipment and resources required for resuming critical
operations must be set up after a disaster has occurred. This
option may enable an organization to be operational within
two to four days following a disaster.

Business continuity planning should continue. Disaster

recovery for IT is one aspect of a business continuity plan.
Business continuity planning identifies alternate operational and
communications strategies for all critical city processes to use if
the city’s offices and facilities are shut down by natural disaster,
terrorism, or other adverse events. In their report on internal
controls for the 2004 financial audit, the city’s external auditors
identified the elements of a business continuity plan that go
beyond information systems. They include:

• Identification and prioritization of risks and controls;

• Operational impact analyses by process flow;
• Effective reaction strategies;
• Development of the continuity plan;
• Training of teams and other personnel;
• Plan testing;
• Plan maintenance procedures;
• Emergency response and evacuation procedures;
• Declaration procedures;
• Executive and employee notification procedures;
• Recovery resources and procedures for the mobilization of
employees and resources; and
• Employee responsibilities and action steps for emergency,
recovery, and restoration operations.

Previous external auditors for the city also have noted the lack of
business continuity planning. We recommend that the city
administration develop a long-term strategy to complete not only
a disaster recovery plan for the ERP and other IT systems, but a
comprehensive business continuity plan as well.

2Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 2

Additional HR/Payroll Process Changes Could Simplify New
System

The city could make changes in several HR/payroll processes that

would streamline these operations. We believe these changes in
business processes would aid in the city becoming more efficient
and add to the productivity gains that the city will realize when
the ERP system implementation is complete. A primary purpose
of the ERP system implementation is to improve processes and
adopt best practices.

These recommendations are based on results of a forthcoming

payroll audit. They are summarized here with emphasis on how
they would affect the ERP implementation.

Consolidate City Employees into Fewer Groups

Paying city employees is a labor-intensive operation that includes

duplicative manual and automated processes. To handle the
workload, city employees are paid on six different pay schedules
and at three different frequencies as seen in Exhibit 6.

EXHIBIT 6

CITY PAY GROUPS

PAY
FREQUENCY PAY DAY EMPLOYEES

Group 1 Biweekly Every other Wed Police

(alternates with group 3)

Group 2 Weekly Every Friday Sanitatio

Group 3 Biweekly Every other Wed General
(alternates with group 1)

Group 4 Biweekly Every other Fri General

(alternates with group 6)

Group 5 Monthly Last Friday City Cou

Group 6 Biweekly Every other Fri Fire
(alternates with group 4)

Source: City records

In a typical month, the city has eight pay days or a pay day every
Wednesday and Friday. Further complexity is added by paying
different employee groups at different intervals.

2Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 2

 The current system requires so much manual processing and data
entry that payrolls are staggered to spread out the workload for
central payroll staff. The use of the Kronos system for time and
attendance, coupled with the ERP system for payroll, should
eliminate most of the manual processes and duplicate data entry.
A single pay frequency and fewer pay dates should reduce the
work of configuring the new system. Paying all city employees on
the same frequency (either biweekly or semimonthly) and in fewer
pay groups should reduce administrative costs and free up payroll
staff to perform customer service and payroll-related accounting
functions.

Eliminate Optional Payment for Early Health Benefits

The city Code of Ordinances, section 2-850 specifies that city

officers and employees will become eligible for the group health
and dental benefits after 90 days of continuous service.
Employees can, however, elect to pay the full cost of coverage
and obtain health and dental insurance from the start of their
employment.

Our first memorandum on proposed ERP processes raised the

issue of verifying employee payment under this option and
otherwise enforcing the 90-day waiting period. We made
recommendations for system controls and manual controls over
the process (see Appendix 1). Even with different configuration of
the ERP system, assuring compliance with this requirement will
depend on manual processes and controls.

Because the Code of Ordinances does not provide for the option
of paying for health benefits to avoid the waiting period, we
believe the practice should be discontinued. This would simplify
process controls and system configuration. The finance
department also should analyze the fiscal impact of reducing or
eliminating the 90-day waiting period.

Include Taxable Employee Benefits in Payroll Process

The city’s current practice of paying certain employee fringe

benefits outside of the payroll process makes it difficult to ensure
that these payments are reported correctly to the IRS for tax
purposes. Our audit of the city’s tax reporting responsibilities is
still in progress. The audit is assessing the extent and

2Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 2

 consequences of noncompliance with IRS requirements for
reporting taxable fringe benefits, such as personal use of
automobiles, cell phones and other mobile devices, and moving
expense reimbursements. While we do not yet have the audit
results, the ERP implementation provides an opportunity now to
reduce the risk of future noncompliance. This can be
accomplished by handling these benefits and payments through
the payroll process, which differs from current practice.

The city’s method for reimbursing eligible employees for relocation

expenses, for example, creates a risk that taxable reimbursements
will not be reported as income to the employee and the IRS. The
HR administrative policy on relocation expenses allows
reimbursement of expenses that are not tax-deductible, such as
house-hunting trips and temporary living expenses. City payment
of these expenses is taxable income to the employee. The city
does not, however, issue the reimbursement through payroll, but
rather through accounts payable. As a result, the payment is not
automatically subject to tax withholding and reporting as required.

The payroll component of the ERP system should be configured to

record all taxable fringe benefits and to pay all taxable expense
reimbursements. This will ensure that such benefits and income
are reported correctly to the employee and to the IRS for income
tax purposes.

Eliminate Compensatory Time for High-Level Salaried

Employees

The city’s policies governing compensatory time off for salaried

employees have been inconsistent, confusing, and difficult to
administer. Salaried employees are exempt from the
requirements of the Fair Labor Standards Act (FLSA), which
regulates work hours and overtime pay for hourly employees, and
they are prohibited from receiving overtime pay by the city Code
of Ordinances. The FLSA states that salaried employees can be
expected to work more than 40 hours per week without additional
compensation. However the city code allows, but does not
require, compensatory time off for these employees. The current
HR administrative policies prohibit salaried employees at pay
grade 30 and above from accruing formal compensatory time but
allows them to track extra hours worked and take equivalent time
off at a later date.

2Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 2

 In the payroll audit, we found noncompliance with the
administrative policy and varying practices among departments
regarding compensatory time for salaried employees at all pay
grades. Some departments were keeping their own records of
compensatory time that vary considerably from the city’s official
payroll records, and they were allowed to use compensatory time
based on these informal records. We found other errors and
inconsistencies in payments to salaried employees for unused
compensatory time when they left city employment.

Giving salaried employees compensatory time does not violate the

FLSA. However in our inquiries about other cities’ practices, we
have found it unusual for department heads and other senior
management staff to receive compensatory time. In addition, the
practice of keeping informal records of compensatory time impairs
transparency and weakens accountability.

Policies governing compensatory time for salaried employees must

be clarified before the HR/payroll components of the ERP system
are configured. We recommend that the city Code of Ordinances
be revised to prohibit compensatory time for department heads
and other senior management staff to be defined, and that the HR
administrative policy be revised accordingly. Controls in the ERP
system should be established to prevent this group of employees
from earning or taking compensatory time off.

Discontinue Donated Leave and Strengthen Controls Over

Advanced Sick Leave

The city has had problems recording and controlling the use of
advanced sick leave and donated leave. Both are authorized in
the city Code of Ordinances for use by employees who, because
of protracted illness or serious injury, have used all of their earned
leave and still are unable to return to work.

Advanced sick leave essentially is a loan from the city. When the
employee returns to work, their earned vacation leave is deducted
until the advanced leave is paid back; if the employee leaves city
employment before all advanced leave is recovered, then the cost
of the leave is deducted from their final pay. Donated leave is
contributed by other employees, deducted from their leave
balances, and recorded in the leave balance of the recipient.
Leave that is donated but not used is forfeited.

2Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 2

 In the payroll audit, we found numerous violations of the
requirements for both advanced and donated leave. Advanced
sick leave was not consistently paid back through leave
deductions, and employees left the city without repaying
advanced leave and without deductions from their final pay.
Employees received more than the one year of donated leave
allowed by the city code, and some received donated leave when
they still had earned leave. Some employees were paid for leave
donated to them but not used when they left city employment.
Records of donated leave were missing or incomplete. Some
donated leave was not deducted from the leave balances of those
who donated it.

The city should discontinue its donated leave program rather than
incorporate it into the ERP system implementation. Donated leave
requires manual processes that increase the risk of error and
abuse. Donations have to be tracked for each employee who
donates leave, and many employees may donate to a single
individual. Even with the new ERP system, donated leave would
still be processed by hand.

In addition, donated leave weakens individual responsibility for

use of leave, increases the city’s potential liability for unused
leave, and imposes the salary and lost productivity costs of long-
term absences on individual work units. The city’s pension plans
provide long-term disability coverage, and the city could explore
options for short-term disability coverage as well.

The ERP system can accommodate advanced sick leave more

easily and can build in constraints to reduce risk of error and
abuse. Added controls should include the following:

• Limit the amount of advanced sick leave granted per incident

and per lifetime for employees.
• Create fields in the ERP system to track advanced sick leave
and to keep the leave separate from other leave balances.
• Create fields in the ERP system to track the dollar amount of
advanced sick leave that is still owed by the employee.
• Allow employees to repay the amount of advanced leave with
deductions from either sick or vacation leave.
• Establish a limit on time the employee has to repay the leave.

2Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 2

26 Pre-Implementation Review of the ERP System
Recommendations

Our recommendations include three types of actions. First,

several recommended actions should be part of the ERP system
implementation. Second are actions that should run parallel to
the implementation, because they will support and complement
the system once it is operating. Finally, several recommended
actions should occur before the HR/Payroll components of the
system are implemented, because they call for legislative and
administrative policy decisions that will affect how the system is
configured.

All of our recommendations are directed to the ERP Steering

Committee because it is the administration’s governing body for
this project. The steering committee should make decisions about
all recommendations and monitor their implementation status,
while individual department heads should be charged with
initiating the recommended actions.

1. The ERP Steering Committee should include in the ERP project

budget the estimated additional cost of system
implementation at the airport. Once included, the actual costs
should be tracked against the budget in the same way as
other project costs.

2. The ERP Steering Committee should ensure that written

policies and procedures are prepared for all manual processes
that are not automated in the new system implementation.

3. The ERP Steering Committee should oversee development of a

formal plan for system access that user departments must
follow when the new system is operational. The plan should
be based on the following principles:
• Access to very sensitive resources is limited to a few
individuals.
• Employees are restricted from performing functions
beyond their responsibility.
• Information resources are classified according to their
criticality and sensitivity.

Pre-Implementation Review of the ERP 2

 • Policies and procedures are instituted for authorizing
access to information resources and documenting such
authorization.
• Emergency and temporary access authorization is
controlled.
• Employees are prohibited from performing two or more of
the following functions for a single type of transaction:
record-keeping, asset custody, authorization, and
reconciliation.

4. The ERP Steering Committee should oversee the data

conversion process to ensure that the data transferred to the
ERP system is accurate and reliable. The data conversion
process should be based on a formal data conversion plan, a
definition of clean data, and written specifications for the
source and destination of all data items being converted.
Further, the steering committee should ensure that the
conversion process is tested to validate that the conversion
was carried out in the way it was intended.

5. The ERP Steering Committee should ensure that the city has
an adequate disaster recovery plan for the ERP system and
that the plan has been tested before the ERP system is
operational.

6. The ERP Steering Committee should facilitate a decision

process about the following HR/Payroll policies and practices.
Policy changes should be completed before the HR/Payroll
components of the new system are configured.

a. Consolidate the city’s six pay groups into as few pay

groups as possible, and pay all city employees at the same
frequency.

b. Observe the 90-day waiting period for health benefits, and

discontinue the practice of providing earlier coverage to
employees who pay the full cost.

c. Analyze the fiscal impact of reducing or eliminating the

90-day waiting period for employees to receive health
benefits.

28 Pre-Implementation Review of the ERP System

 d. Include all taxable employee benefits and taxable
employee expense reimbursements in the payroll process
to ensure that they are reported to the IRS as required.

e. Propose legislation to eliminate compensatory time off for

department heads and other senior management staff to
be defined, and revise the HR administrative policy on
compensatory time for salaried employees accordingly.

f. Propose legislation to eliminate donated leave.

7. The ERP Steering Committee should ensure that controls for

advanced sick leave are included in the system
implementation and related administrative policies and
procedures, as listed on page 26 of this report.

Pre-Implementation Review of the ERP 2

30 Pre-Implementation Review of the ERP System
Appendices

Pre-Implementation Review of the ERP System 31

32 Pre-Implementation Review of the ERP System
 APPENDIX 1
“TO-BE PROCESSES” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

3Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 3

 APPENDIX 1 (Continued)
“TO-BE PROCESSES” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

3Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 3

 APPENDIX 1 (Continued)
“TO-BE PROCESSES” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

3Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 3

 APPENDIX 1 (Continued)
“TO-BE PROCESSES” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

3Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 3

 APPENDIX 1 (Continued)
“TO-BE PROCESSES” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

3Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 3

 APPENDIX 1 (Continued)
“TO-BE PROCESSES” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

3Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 3

 APPENDIX 1 (Continued)
“TO-BE PROCESSES” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

3Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 3

40 Pre-Implementation Review of the ERP System
 APPENDIX 2
“TARGET PROCESS BLUEPRINT” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

4Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 4

 APPENDIX 2 (Continued)
“TARGET PROCESS BLUEPRINT” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

4Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 4

 APPENDIX 2 (Continued)
“TARGET PROCESS BLUEPRINT” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

4Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 4

 APPENDIX 2 (Continued)
“TARGET PROCESS BLUEPRINT” MEMORANDUM FROM CITY AUDITOR
TO ERP PROGRAM DIRECTOR WITH RESPONSES

4Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 4

 APPENDIX 3

BIBLIOGRAPHY: ERP SYSTEM IMPLEMENTATION AND CONTROLS

“Auditing Governance in ERP Projects” S. Anantha Sayana. Volume 2, 2004. Information

Systems Control Journal.

“Auditing Security and Privacy in ERP Applications” S. Anantha Sayana. Volume 4, 2004.
Information Systems Control Journal.

“Business Continuity: A Business Survival Strategy.” Ken Doughty. Volume 1, 2002.

Information Systems Control Journal.

“Business Continuity Plan Testing: Considerations and Best Practices.” Brian Zawada.
Information Systems Audit and Control Association InfoBytes.

“Business Continuity Planning: Don’t Be Caught Off Guard.” Annie Cushing. Volume 27,
No.5, 2005. Auditwire.

“Considerations for Software Upgrades.” John Silltow. Volume 5, November 15, 2002.
IT Audit.

“Data Conversion.” Alan Oliphant. Volume 5, November 1, 2002. IT Audit.

“Data-recovery Plans Can Avert Disaster” Ira Gupta. Volume 7, November 1, 2004.
ITAudit.

“Disaster Recovery and Business Continuity Planning: Testing an Organization’s Plans.”

Yusafli F. Musaji. Volume 1, 2002. Information Systems Control Journal.

“Enterprise Resource Planning: Can it be risky?-Part 1” Akhilesh Tuteja. Volume 3, May

1, 2000. ITAudit.

Enterprise Software Implementation for Auditors. Deloitte Development LLC. 2004.

“Guide to Enterprise Management: The Electronic Decision-Maker.” Ellen Perlman. July

2000. Governing.

“Implementation of ERP Systems: Accounting and Auditing Implications” Benjamin Bae

and Paul Ashcroft. Volume 5, 2005. Information Systems Control Journal.

IS Standards, Guidelines and Procedures for Auditing and Control Professionals.

Information Systems Audit and Control Association. 2005.

4Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 4

 APPENDIX 3 (Continued)

BIBLIOGRAPHY: ERP SYSTEM IMPLEMENTATION AND CONTROLS

“Manager’s Guide to Enterprise Resource Planning (ERP) Systems” Les Pang. Volume 4,
2001. Information Systems Control Journal.

Oracle Database Security, Audit and Control Features. IT Governance Institute. 2004.

Security, Audit and Control Features Oracle Applications: A Technical and Risk
Management Reference Guide. IT Governance Institute. 2003.

“Risk and Governance Issues for ERP Enterprise Applications.” Stephen Addison. Volume
4, 2001. Information Systems Control Journal.

Security, Audit and Control Features Oracle Applications: Audit Programs and Internal
Control Questionnaires. Information Systems Audit and Control Association.

“Segregation of Duties in ERP” Susan S. Lightle. Volume 6, December 1, 2003.

ITAudit.

“The Auditor’s Role in Reviewing Business Continuity Planning.” Ravi Muthukrishnan.

Volume 4, 2005. Information Systems Control Journal.

“The ERPworks: Recoding the guts of an enterprise can bring a city or state to the brink
of failure, fatigue and notoriety.” Ellen Perlamn. May 2005. Governing.

“The Importance of Business Continuity Planning.” Nagarajan Nagarajan. Volume 5,

November 1, 2002. IT Audit.

“The Six Deadly ERP Sins.” White Paper. Manoeuvre Pty. Ltd. October 2001.

4Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 4

 APPENDIX 4

PLANNED MODULES FOR THE ERP SYSTEM

Financial Modules
1. Oracle Public Sector General Ledger
2. Oracle Public Sector Accounts Payable
3. Oracle iExpense
4. Oracle Public Sector Accounts Receivable
5. Oracle iReceivables
6. Oracle Fixed Assets
7. Oracle Property Manager
8. Oracle Cash Management
9. Oracle Project Accounting
10. Oracle Grants Accounting
11. Oracle Financials Intelligence
12. Oracle Public Sector Budgeting
13. Oracle Collections
Procurement Modules
14. Oracle Public Sector Purchasing
15. Oracle iProcurement
16. Contracts Management
17. Oracle Sourcing
18. Oracle iSupplier Portal
19. Oracle Purchasing Intelligence
Human Resources Modules
20. Oracle Human Resources Management System
21. Oracle iRecruitment
22. Oracle Payroll
23. Oracle Advanced Benefits
24. Oracle Training Administration
25. Oracle Self-Service HR
26. Oracle HR Intelligence
27. Oracle Labor Distribution
Other Modules Under Consideration
Oracle Internal Controls Manager
Oracle Grants Proposal

4Pre-Implementation Review of the ERP Pre-Implementation Review of the ERP 4

48 Pre-Implementation Review of the ERP System
 APPENDIX 5

EXAMPLES OF INCOMPATIBLE DUTIES

Separate this function From this function

Ability to create and change purchase Ability to process payments
orders
Ability to create and change purchase Ability to create or change vendors
orders
Ability to maintain asset master data Ability to run and review depreciation
expense
Ability to create and change general ledger Ability to generate journal entries or other
accounts financial transactions
Ability to create and change deliveries All other order processing activities
Ability to create and change purchase Credit management activities
orders
Ability to authorize payments Ability to change bank information
Ability to create a purchase order Ability to receive goods
Ability to create or change employee Ability to process payroll
master data
Ability to create and change customer Ability to approve & process collections
master records
Ability to maintain customer credit limits Ability to approve & process collections
Ability to approve & process collections Ability to issue goods
Ability to record revenues Responsible for reconciling bank accounts
Ability to close accounts (period closings) Ability to post journal entries

Pre-Implementation Review of the ERP 4

50 Pre-Implementation Review of the ERP System
 APPENDIX 6
AUDIT RESPONSE – ERP STEERING COMMITTEE

Pre-Implementation Review of the ERP 5

52 Pre-Implementation Review of the ERP System
 APPENDIX 6 (Continued)
AUDIT RESPONSE – ERP STEERING COMMITTEE

ERP Steering Committee Performance Audit Response

Recommendation Resp. Acceptance Response Implementation Date

1 Include Airport cost and track actuals PMO Agree Will report ongoing cost 1-Nov-05
2 Prepare policies and procedures for manual PMO Agree Will update during development of Training 15-Sep-06
processes that are not automated materials
3 Development of Formal System Access Plan PMO Agree Will develop using IBM System Profile & Role 15-Sep-06
and Responsibility Matrix deliverable
4 Data Conversion Process Management PMO Agree Ongoing management including testing starting 15-Nov-05
15 Nov 2005 after development of IBM's Data
Conversion Strategy
5 Adequate ERP Disaster Recovery Plan PMO/DIT Agree Disaster Recovery Plan included in Infrastructure 15-Aug-06
Plan, City to have full DR Plan in Nov 2005 and
Test ERP in UAT in Aug 2006.

6 Facilitate HR/Payroll Decisions

a. Consolidate the city's six pay groups into as few Finance Agree a. Plan is to move to (2) Pay Groups Sworn and TBD
pay groups as possible Non Sworn employees.
b. Include all taxable employee benefits and taxable Finance Agree b. Will be done as a part of the HR/Payroll Jul-06
employee expense reimbursements in the payroll starting with design, testing and implementation
process process
c. Observe the 90-day waiting period for health Finance Agree c. No exceptions to the 90-day period will be TBD
benefits, and discontinue the practice of providing allowed
earlier coverage to employees who pay the full cost

d. Analyze the fiscal impact of reducing or eliminating Finance Agree d. We will assess the impact to the Budget. TBD
the 90-day waiting period for employees to receive
health benefits
e. Propose Legislation to eliminate compensatory HR Disagree e. Compensatory time will be accounted for as No Action Required
time off for Dept. Heads and Senior Management outlined in the City Code.

f. Propose Legislation to Eliminate Donated Leave HR Disagree f. Management supports the donation of leave No Action Required
between employees for catastrophic cases. Will
be better managed in Oracle.
7 Include controls for Advanced Sick Leave in the HR Agree Will be done as a part of the HR/Benefits starting Jul-06
system with design, testing and implementation process.
Will decide with Finance on whether to eliminate
advance sick leave.

Pre-Implementation Review of the ERP System 53

54 Pre-Implementation Review of the ERP System