Get documents about "Aligning Financial Plan with Strategic Plan
Description
Aligning Financial Plan with Strategic Plan document sample
Document Sample
California Department of Transportation
Integration Study
FINANCIAL S YSTEMS STRATEGIC PLAN
(DELIVERABLE #16)
100% Deliverable
March 17, 2004
Caltrans Integration Study Financial Systems Strategic Plan
CALTRANS I NTEGRATION STUDY
FINANCIAL S YSTEMS STRATEGIC PLAN
T ABLE OF CONTENTS
EXECUTIVE SUMMARY ........................................................................................................... I
Background .................................................................................................................................. i
The Plan ...................................................................................................................................... ii
Maintenance Projects ................................................................................................................. vi
Strategies for Success............................................................................................................... viii
Next Steps ................................................................................................................................... x
1.0 INTRODUCTION................................................................................................................... 1
1.1 The Caltrans Integration Study (CIS) ............................................................................. 1
1.2 Purpose of the Financial Systems Strategic Plan ............................................................ 3
1.3 Organization of The Plan ................................................................................................ 3
2.0 FINANCIAL SYSTEMS VISION FOR THE FUTURE..................................................... 5
2.1 Caltrans Integration Study Findings and Recommendations .......................................... 5
2.2 Guiding Principles........................................................................................................... 9
2.3 Assumptions and Constraints........................................................................................ 10
2.4 Implementation Approach............................................................................................. 12
2.5 Project Sequencing and Dependencies ......................................................................... 24
2.6 Data Conversion and Reporting on Historical Data ..................................................... 26
2.7 Impact on Existing Systems .......................................................................................... 29
2.8 Maintenance Projects .................................................................................................... 38
3.0 STRATEGIES FOR SUCCESS........................................................................................... 47
3.1 Integrated Systems Program Governance Strategy....................................................... 47
3.2 Organizational Change Management Strategy ............................................................. 53
3.3 Communication Strategy .............................................................................................. 56
3.4 Training Strategy........................................................................................................... 57
3.5 Program Management Strategy..................................................................................... 60
3.6 Procurement Strategy .................................................................................................... 61
3.7 Risk Management Strategy ........................................................................................... 64
4.0 NEXT STEPS ........................................................................................................................ 67
5.0 APPENDICES ....................................................................................................................... 68
Appendix A: Time-Frame Modeling Approach ...................................................................... 69
Appendix B: Implementation Task Plan .................................................................................. 71
March 17, 2004
Caltrans Integration Study Financial Systems Strategic Plan
EXECUT IVE SUMMARY
Background
This document, the Caltrans Integration Study (CIS) Financial Systems Strategic Pla n (the Plan)
represents the final deliverable of the Caltrans Integration Study (CIS). The CIS was undertaken
to develop an enterprise view of the California Department of Transportation’s (the
Department’s) financial data and processes and to resolve perceived financial overlap between
four proposed systems: Construction Management System (CMS), California Transportation
Infrastructure Funding System (CTIFS), Caltrans Land Management System (CLMS) and
Financial Management System (FMS).
To conduct the study, the CIS team first completed Best Practices containing a series of ―lessons
learned‖ based on interviews with state transportation departments who had completed or were
nearing completion of enterprise-wide financial system implementations. During the same period
the CIS Team published the Baseline Analysis built upon a review of existing Department
Business Process Reviews (BPR), Feasibility Study Reports (FSR) and interviews with over 160
system owners. The ―lessons learned‖, Department business processes and system information
resulted in high- level financial requirements and an enterprise financial data model; these
elements served as inputs for developing the Department’s financial conceptual architecture.
The Conceptual Architecture recommends that the Department implement a single enterprise-
wide integrated system to meet the Department’s financial systems requirements. This system—
which is referred to as the ―Integrated Financial Management System (IFMS)‖—includes the
functionality originally associated with CTIFS, CLMS and FMS, integrated with the
Department’s other non- financial systems. The Conceptual Architecture also recommends that
the Department:
Build CMS as a standalone system with an interface to IFMS, since most of the CMS
functionality is not financial in nature.
Implement an active Data Warehouse to support the Department’s financial reporting
requirements.
Provide interfaces between IFMS and other Department systems using industry standard
Enterprise Application Interface (EAI) software.
Interface 17 existing systems to the IFMS
Eliminate 122 existing systems whose functions will be duplicated by IFMS.
Move five specific reporting systems to the active Data Warehouse.
Exhibit 1 on the next page illustrates the Conceptual Architecture. Please refer to the Conceptual
Architecture for additional details on the ―To Be‖ state of the Department’s financial systems.
March 17, 2004 Page i
Caltrans Integration Study Financial Systems Strategic Plan
Exhibit 1 – Original Requested Systems were integrated into the Proposed Architecture
The Plan
This Plan serves as the roadmap for implementing the Conceptual Architecture. The Plan
proposes implementing the Conceptual Architecture through a series of projects sequenced
according to project priorities and dependencies. The completion of each project represents a
step towards implementing the ―To Be‖ state as defined in the Conceptual Architecture. As
each project is implemented, the Department’s existing systems with duplicate financial
functions will be retired, and the financial functions and data will be provided by the IFMS.
The Plan identifies individual component projects—rather than a single, large, project—for
several reasons. One significant reason is the State’s current budget situation. The approach
featured in the Plan allows the Department of Finance to approve smaller funding amounts for
March 17, 2004 Page ii
Caltrans Integration Study Financial Systems Strategic Plan
each individual project over the life of the Conceptual Architecture implementation effort, rather
than a single very large appropriation.
Since the Plan involves the coordinated delivery of multiple projects, resulting in an enterprise-
wide integrated system, this report will use the term ―program‖ when referring to these projects
collectively. The name of this group of projects is the Integrated Systems Program. Exhibit 2
presents the program’s projects, their dependencies, and their timeframes.
Exhibit 2 – Integrated Systems Program
D e l i v e r y T i m e l i n e
FY 1 FY 2 FY 3 FY 4 FY 5
Sponsoring
Project Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Organization
Infrastructure
Enterprise Software,
Enterprise Active Data Warehousing,
Enterprise Application Integration
Procurement
Enterprise / General Accounting
General Ledger, Accts Payable, Accts
Finance Receivable, Financial Reporting
District /
Project Reporting
Programs
Construction CMS
Accounting /
Fixed Assets
DPAC
Budgets Budget Prep
Purchase Requisition,
DPAC
Procurement, Inventory
Programming,
DPAC
Federal Resources, CTIFS
Purchase Requisition
Local Assistance
Project
PRSM
Management
Right of Way CLMS
L E G E N D
= Prepare FSR = FSR Approval = Project Startup = Rollout
= Update FSR = Procure = Design, Configure, Develop, and Test = Dependency
As the exhibit shows, each of the ten projects is divided into the phases listed in the above legend
(e.g., Prepare FSR, Update FSR). The activities and deliverables of each project are summarized
as follows:
Infrastructure Project – Encompasses all activities related to acquiring and establishing
the ERP and active Data Warehouse software, along with any required hardware. No
financial functions are available at the end of this project. Financial functions will be
implemented with each of the remaining projects.
March 17, 2004 Page iii
Caltrans Integration Study Financial Systems Strategic Plan
General Accounting Project – Provides General Accounting (G/L), Accounts
Receivable (A/R) and Accounts Payable (A/P) functionality to Department users and
lays the logical foundation for future projects. The Expenditure Authorization (EA) and
project splits and combines will be defined in terms of the new system.
Project Reporting Project – Provides the ability to establish and monitor a budget
against a particular project, as well as track and report the associated project activities
over the life of the project.
CMS Project – Construction management functions as defined in the CMS FSR will be
available to Department users.
Fixed Assets Project – The Department will be able to monitor and report on all
capitalized and non-capitalized property and equipment throughout the Department.
Budget Preparation Project – The Department will be able to perform trend
analysis/budget modeling functions, analyze the current or prior year budget and/or
actual information, manipulate the data and create and store various ―what if‖ scenarios
for operational and project related budgets.
Procurement and Inventory Project – Implementing this project will streamline
current procurement and inventory processes and improve productivity by utilizing
online requisitions, purchase orders/contracts and change orders, electronic catalogs,
automated workflow approvals and electronic commerce email.
CTIFS Project – This project will provide the Programming, Local Assistance and
Budgets Divisions with the ability to ―program‖ projects into STIP, SHOPP and
categorical programs; obtain and manage federal funds; and oversee projects constructed
by local agencies.
CLMS Project – This project will integrate functionality provided by earlier projects –
procurement, payables, receivables, budgeting, inventory, fixed assets – with the real
estate functionality provided by the ERP’s Real Estate module
Project dependencies are highlighted with red arrows in Exhibit 2 and indicate the earliest point
in the Plan that a project can begin. As shown in Exhibit 2 above, the Department should begin
preparing Feasibility Study Reports (FSRs) for each project (except PRSM, which already has an
approved FSR) at the earliest opportunity. Business requirements defined in each of the FSRs
will be incorporated into the first project, the Infrastructure Project, to ensure the chosen ERP
satisfies the full range of CTIFS, CLMS and FMS needs. The Project Reporting, Fixed Assets,
Budget Preparation, Procurement, CTIFS and CLMS projects contain the ―Update FSR‖
phase where their respective FSR’s are re-examined and possibly updated based upon the actual
software procured in the Infrastructure Project.
After the FSRs are complete, two projects – CMS and PRSM – can begin immediately because
their start-up is not dependent on any other system. However, CMS must be integrated with the
new IFMS when both CMS and the General Accounting component of IFMS become
operational, as indicated by the dependency between the General Accounting and CMS projects.
March 17, 2004 Page iv
Caltrans Integration Study Financial Systems Strategic Plan
PRSM must also be integrated with the IFMS when PRSM and the General Accounting and
Project Reporting components of IFMS become operational. The arrow between the Project
Reporting and PRSM projects illustrates this dependency.
The eight remaining projects (Infrastructure, General Accounting, Project Reporting, Fixed
Assets, Budget Preparation, Purchase Requisition, Procurement, Inventory, CTIFS, and CLMS)
all have dependencies that impact their sequencing. The sequencing and dependencies between
these projects are described below:
Since the Infrastructure Project will provide the hardware and software that will be
used in all of the remaining projects, it must proceed first.
The Gene ral Accounting project should commence after the primary implementation
tasks (design configure, develop, and test) of the Infrastructure Project are complete.
When implementing an integrated financial system, the General Ledger module is
typically the first ERP module to be implemented, as the other modules rely on the
baseline configuration, chart of accounts, organizational structure, reporting entities a nd
the redesigned expenditure authorization (EA).
Three projects – Project Reporting, Fixed Assets, and Budget Preparation – are
heavily dependent on the baseline configuration that will be implemented in the General
Accounting Project. As a result, these projects can commence after the primary
implementation tasks of the General Accounting project are complete. It is important to
note that these projects can be implemented in parallel, before, or after one another.
Exhibit 2 shows these projects in parallel, since this is the quickest approach for
completing the implementation.
In order for the Division of Accounting and the Division of Procurement and Contracts
(DPAC) to fully reap the benefits of an integrated financial and procurement system, the
Procurement Project (inventory and non- inventory) should be developed during the
same timeframe as the General Accounting Project, with the ―back-office‖ functions of
procurement rolled out to production at the same time as General Accounting Project.
The web based purchase requisition functions of the Procurement Project could be rolled
out at any point in time after the ―back-office‖ functions are in production.
The CTIFS Project, which includes Fund and Grants Management functionality, cannot
begin until the General Accounting and Project Accounting projects are implemented.
Similarly, the CLMS Project, which is the integration of Real Estate module with
Project Accounting, Procurement, Accounts Payable, Fixed Assets, and General Ledger,
cannot be implemented until the Project Accounting, General Accounting, Procurement,
and Fixed Assets functions are implemented.
The Plan identifies the current systems that will be replaced by the systems implemented in each
project. In addition, the Plan provides guidelines that the Department may follow to convert its
data and provide historical data reports.
March 17, 2004 Page v
Caltrans Integration Study Financial Systems Strategic Plan
It is important to reiterate that the Plan was developed to facilitate the implementation of the
Conceptual Architecture through the maximum of number of projects that could feasibly be
implemented. When the Department begins executing this plan, the Department may wish to
combine projects if it is cost effective to do so, and if the requisite resources are available.
Maintenance Projects
As Exhibit 3 illustrates, it will take the Department approximately five years to execute the Plan.
As a result, some enterprise-wide financial systems functionality will not be available for an
extended period of time. Because of this, certain business problems or ―pain points‖ need to be
addressed prior to a scheduled system replacement or ERP function being available. The CIS
Workgroup members have identified four project groups that would address business needs prior
to the Conceptual Architecture being fully implemented. Exhibit 3 identifies maintenance
projects that will address these issues.
Exhibit 3 – System Maintenance and Updates
D e l i v e r y T i m e l i n e
FY 1 FY 2 FY 3 FY 4 FY 5
Sponsoring
Organization
Project Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Infrastructure
Enterprise Software,
Enterprise Active Data Warehousing,
Enterprise Application Integration
Procurement
General Accounting
Enterprise / General Ledger, Accts Payable, Accts
Receivable, Financial Reporting
Finance
Acctg. Systems Maint. & Updates
District / Project Reporting
Programs
Reporting & Maintenance
Construction CMS
Accounting /
Fixed Assets
DPAC
Budgets Budget Prep
Purchase Requisition,
DPAC
Procurement, Inventory
Programming, CTIFS
DPAC
Federal Resources, Purchase Requisition
Local Programming
Maintenance
Project
PRSM
Management
CLMS
Right of Way
Maintenance
L E G E N D
= Prepare FSR = FSR Approval = Project Startup = Rollout
= Update FSR = Procure = Design, Configure, Develop, and Test = Dependency
March 17, 2004 Page vi
Caltrans Integration Study Financial Systems Strategic Plan
A description of the projects illustrated in Exhibit 3 is provided below.
General Accounting Systems Maintenance and Updates – The second project of the
Plan scheduled for implementation, the General Accounting Project, may not be
completed for two or more years. In the meantime, existing systems such as the Caltrans
Accounts Payable System (CAPS), Expenditure Authorization System/Capital Outlay
Monitoring System (EAS/COMS) and Accounts Receivable System (ARS) may cease to
function due to the limitations of their technical environments. Updates or maintenance
of these existing systems will ensure the Department is able to continue automated
document processing and transaction recording with CAPS; prepare, review and approve
Expenditure Authorizations (EA) and control expenditures at the project, program, and
appropriation levels with EAS/COMS; and process the Department’s accounts
receivables with ARS.
Project Reporting and Maintenance – Only after fully implementing the Conceptual
Architecture will financial reports be available for the entire project lifecycle. In the
meantime, the Department will continue to update and create project reports while
addressing project splits and combines and AB1012/SB45 reporting requirements.
Project reporting will be impacted by activities associated with the Plan as well as other
maintenance projects such as the CTIFS maintenance project listed below.
“CTIFS” Current Systems Maintenance and Updates – The dependencies between
the ERP modules requires that CTIFS functions be implemented after General
Accounting and Project Reporting functions are available. In the meantime,
enhancements and maintenance of the existing CTIPS, LP2000, and FADS systems will
address some current limitations and satisfy legislative requirements of SB45, TEA-21
and AB1012. These systems will be moved to Department standard platforms and
interfaced to more easily generate management and legislatively required reports.
Right of Way Current Systems Maintenance and Updates – The ideal
implementation sequence for the ERP modules requires that CLMS functions be
implemented as one of the last projects. In the meantime enhancements to existing
systems could provide Right of Way users with management data for both projects and
parcels and eliminate numerous shadow systems.
Each of these system owners faces the challenge of addressing c urrent business needs while
simultaneously considering the Conceptual Architecture and the Plan.
The relative importance of each of these projects has not been identified; only project ownership
and high- level project sequencing and durations have been reflected in the Exhibit 3 diagram.
March 17, 2004 Page vii
Caltrans Integration Study Financial Systems Strategic Plan
Strategies for Success
The Department must undertake a complex and lengthy effort in order to execute the Plan. The
Plan includes several strategies that may help the Department increase its ability to achieve a
successful implementation. Strategies for success include:
Integrated Systems Program Governance: Execution of the plan will require the
participation of many people from throughout the Department, along with vendor staff.
In order to effectively execute the plan, the CIS team recommends the governance
structure illustrated in Exhibit 4. This structure provides an enterprise-wide, program
level approach to implementing the projects. In this structure:
The Program Sponsor serves as the ultimate owner of the program of projects and
has the ability make decisions and implement policies across Divisions and
Districts
Exhibit 4 – Integrated Systems Program Governance Structure
Program Sponsor
Steering Committee
Program Director
Program Management Tem
Project 1 Project 2 Project 3 Project N
Department Project Department Project Department Project Department Project
Manager Manager Manager Manager
System Integrator Project System Integrator Project System Integrator Project System Integrator Project
Manager Manager Manager Manager
Project Team Project Team Project Team Project Team
(Department & Integrator) (Department & Integrator) (Department & Integrator) (Department & Integrator)
The Steering Committee consists of high- level project stakeholders who define
policies and ensure the availability of resources.
The Program Director oversees all individual projects and ensures that the decisions
and activities of the individual project teams are consistent across the entire
program.
The Program Management Team (PMT), which includes the Program Director and
the Department Project Managers on each individual project team, will be
March 17, 2004 Page viii
Caltrans Integration Study Financial Systems Strategic Plan
responsible for coordinating management activities across all projects to ensure
consistency across the projects.
The Department Project Managers will be responsible for the day-to-day
management of each project.
The System Integrator Project Managers will provide system function and technical
leadership and services throughout the implementation of each project of the
program.
The individual project teams, which will consist of Department and vendor project
managers and staff, will conduct the day-to-day activities of each project.
Organizational Change Management: The organizational change management
strategy includes the development of a change management plan to guide the Department
through the policy, business, and organizational changes that will take place during the
execution of the Plan. Components of the Organizational Change Management Plan
should include a Leadership Action Plan to identify the approaches and specific steps the
Department’s executives and managers should take to lead the Department through the
changes as they occur; a Communications Approach which links stakeho lders, critical
implementation issues, and key messages with the appropriate leader or staff person who
should communicate the message or information; and a Workforce Transition
Assessment to identify positions that may be impacted by the implementation and the
training required to prepare individuals for any changes in their jobs.
Communications: Based on the communications approach in the Organizational
Change Management Plan, the Department should develop a Communications Plan for
its program and associated projects. The plan should identify the messages to be
communicated, the appropriate messenger, and match the messenger with the right
audience and communication vehicle.
Training: The Plan recommends that the Department develop and execute a training
plan that provides the Department’s personnel with the training they need to do their jobs
and utilize the newly implemented systems.
Program Manage ment: The Plan recommends that the Department utilize a program
management approach to implement all of the projects in the Plan. Utilizing the
governance structure described above (with a Program Sponsor, Steering Committee,
Program Director and PMT), the Department should:
Establish processes and procedures which promote a structured and consistent
methodology for managing and conducting each of the projects in the Plan;
Institute effective decision making processes;
Establish processes to ensure consistency across all projects; and
Track and manage dependencies across all projects in the Plan.
Procurement: The procurement strategy recommends that the Department procure the
necessary software and hardware separately from the integration services. This
procurement strategy allows the Department to first procure software that meets the
functional requirements of all projects in the program. The Department would then
March 17, 2004 Page ix
Caltrans Integration Study Financial Systems Strategic Plan
procure integration services to implement the software on a project-by-project basis. This
procurement strategy requires control agency agreement that the Plan is sound. It also
requires all projects to begin FSR development soon, since all projects’ functional
requirements must be incorporated into the software procurement FSR.
Risk Management: The Plan recommends that Department use a program-wide,
industry standard approach to managing risks on projects. The Program Director and
PMT should develop a risk management plan which facilitates the management of risks
through:
Identifying and documenting risks;
Evaluating and prioritizing risks;
Reducing the likelihood and impact of risks; and,
Monitoring identified risks.
Next Steps
Upon approval of this Plan, the Department can commence with Plan execution. Recommend
―next steps‖ for beginning the execution of the Plan include:
Obtain control agency agreement on the Plan;
Assign individuals to the governance structure, including the Program Sponsor, Steering
Committee members, Program Director and Project Managers for each project;
Begin all FSRs in an effort to gather detailed enterprise business requirements; and,
Prepare the Department for change.
March 17, 2004 Page x
Caltrans Integration Study Financial Systems Strategic Plan
1.0 INT RODUCT ION
This Financial Systems Strategic Plan (Plan) represents the final deliverable of the Caltrans
Integration Study (CIS). The CIS was undertaken to provide the California Department of
Transportation with a plan to address enterprise-wide financial management systems needs and
improvement opportunities.
In the previous phase for the study, the CIS project produced the Conceptual Architecture, which
recommended a ―To Be‖ state of the Department’s financial systems. The Plan provides a
roadmap for implementing the Conceptual Architecture, discusses an implementation approach,
recommends specific projects that the Department should undertake to implement the
Conceptual Architecture, and suggests strategies for successfully managing the implementation
effort.
It is important to note that although this document is entitled the “Financial Systems Strategic
Plan”, it focuses on tactical projects and activities that the Department should undertake to
implement the Conceptual Architecture. The Conceptual Architecture provides the strategic
vision for the Plan.
1.1 The Caltrans Integration Study (CIS)
During calendar years 2000 and 2001, the Department submitted four feasibility study reports
(FSRs) that proposed the implementation of the following automated systems:
The Financial Management System (FMS), which would function as the Department’s
financial accounting system.
The Construction Management system (CMS), which would be used for managing the
Department’s construction contracts.
The California Transportation Infrastructure Funding System (CTIFS), which would
support the identification and management of transportation funding.
The Caltrans Land Management System (CLMS), which would be used to manage the
Department’s Right of Way.
After reviewing the FSRs, State control agencies determined that the four proposed systems
duplicated each other’s financial functions, and might also duplicate the financial functions of
other existing systems that were not scheduled to be replaced by the four proposed systems. If
implemented as proposed in the FSRs, the systems could result in redundant system
functionality, potentially create process inefficiencies, build silos of information, and add
complexity to integration and interface requirements. Consequently, control agencies did not
approve the submitted FSRs and all four of the projects were put on hold.
March 17, 2004 Page 1
Caltrans Integration Study Financial Systems Strategic Plan
In order to address this situation, the control agencies and the Department initiated the Caltrans
Integration Study (CIS). The objectives of the CIS are to:
Identify opportunities for improving the Department’s financial systems architecture by
improving the integration of the four proposed systems and an additional 144 systems
with financial functions.
Define a future ―To Be‖ financial system technology state for the Department – a
―conceptual architecture‖ – that addresses the enterprise-wide financial systems
architecture for the Department.
Identify how the financial functions of the four proposed systems and 144 additional
systems will be included in the ―To Be‖ state, along with any required integration and
interface requirements between systems.
Recommend a strategy for implementing the conceptual architecture, including the
identification of specific projects and the development of an overall implementation
approach.
In order to meet these objectives, the CIS was conducted in the following steps:
Best Practices / Lessons Learned – Identified best practices and lessons learned in
transportation financial management for incorporation into the Conceptual Architecture
and this Plan. The experiences of other organizations (e.g., the California Department of
Water Resources, the North Carolina Department of Transportation, and individuals at
the Virginia, Texas and Idaho Departments of Transpo rtation) allowed the CIS to
incorporate ―lessons learned‖, best practices, and other information from similar
successful projects into the recommendations of the CIS.
Identification of Existing Financial Information Systems – Identified the existing
systems and technology associated with the Department’s financial management
functions.
Baseline Analysis and High Level Entity Model of Proposed and Existing Financial
Information Systems – Describes the Department’s existing financial management
systems and analyzes identified financial functions and systems to determine functional
overlaps and duplication.
Data Model of the Department’s Financial Information – Developed a data model
that documents the financial data that the Department uses, whether that data is recorded
in current systems or must be manually researched, identified, and calculated. .
Conceptual Architecture / “To Be” State of the Department’s Financial Information
– Recommended a ―To Be‖ state for the Department’s financial systems, based on the
findings in the previous phases. In order to develop the conceptual architecture, the CIS
project performed a comprehensive analysis of business process reviews, feasibility
study reports, policy manuals, and other documentation that describes the financial
business processes and requirements of the Department.
Financial Systems Strategic Plan – Provides a roadmap for implementing the
Conceptual architecture.
March 17, 2004 Page 2
Caltrans Integration Study Financial Systems Strategic Plan
The primary deliverables produced for the CIS project are illustrated in the Exhibit 5 belo w.
Exhibit 5 – CIS Deliverables
Identify
Financial
Best Practice Existing Baseline Conceptual
Systems
Analysis Systems Analysis Architecture
Strategic Plan
Impacted
Summary Analy sis of List of Impacted Baseline Analy sis Of Four Conceptual
FinancialManagement Sy stems Proposed Sy stems & Architecture
Best Practices/Lessons ExistingSy stems, Strategic Plan
Learned High-lev elEntity Model
Each of the CIS project phases resulted in specific outcomes that provided the context and
content for the subsequent phases. This provided the Department with an enterprise-wide
perspective of its financial management systems and the foundation to define an enterprise-wide
strategy for implementing new financial management systems.
1.2 Purpose of the Financial Systems Strategic Plan
The purpose of Plan is to provide the Department with a roadmap for implementing the
Conceptual Architecture. The Plan presents a series of projects and their implementation tasks,
which are sequenced based on their relative priorities and dependencies. As illustrated below,
the completion of each project represents a step in transitioning the Department from the ―As Is‖
to the ―To Be‖ state as illustrated in the Conceptual Architecture.
Exhibit 6 – Transitioning From the “As I s” to the “To Be”
1.3 Organization of The Plan
The remainder of this document is organized as follows:
Chapter 2.0 – Financial Systems Vision for the Future: Based on the Conceptual
Architecture, the Plan outlines the steps the Department must complete to implement its
financial management systems vision. This section includes the following information in
support of this vision:
Caltrans Integration Study Findings and Recommendations
Guiding Principles
March 17, 2004 Page 3
Caltrans Integration Study Financial Systems Strategic Plan
Assumptions and Constraints
Implementation Approach
Project Sequencing and Dependencies
Data Conversion and Reporting on Historical Data
Impact on Existing Systems
Maintenance Projects
Chapter 3.0 – Strategies for Success: This section discusses strategies that will guide
the Department in implementing the conceptual architecture. These strategies include:
Integrated Systems Program Governance Strategy
Organizational Change Management Strategy
Communication Strategy
Training Strategy
Program Management Strategy
Procurement Strategy
Risk Management Strategy
Chapter 4.0 – Next Steps: This chapter identifies the initial steps the Department
should take to begin executing the Plan.
Appendices: The appendices include the following information:
Appendix A: Timeframe Modeling Approach
Appendix B: Implementation Task Plan
March 17, 2004 Page 4
Caltrans Integration Study Financial Systems Strategic Plan
2.0 F INA NCIAL SYSTEMS VISIO N F OR T HE F UT URE
This chapter discusses the strategies for realizing the ―To Be‖ recommendations and the steps
that Department should complete to implement the Conceptual Architecture recommendations.
2.1 Caltrans Integration Study Findings and Recommendations
As noted previously, the Plan has been developed to provide the Department with a roadmap for
implementing the ―To Be‖ state for the Department’s financial systems as described in the
Conceptual Architecture. Earlier phases of the CIS project documented the ―As Is‖ state of the
Department’s financial systems and provided an assessment of the functions of the four proposed
systems.
2.1.1 CALTRANS INTEGRATION STUDY FINDINGS
The findings from the CIS project include the following:
The four systems proposed in the previously submitted FSRs (FMS, CLMS, CTIFS and
CMS) contain duplicate functionality. Duplication also exists in the financial functions
of an additional 122 systems in the Department.
Internal and external stakeholders require more detailed and current financial information
than existing systems currently provide.
Over the last decade, there has been a dramatic increase in the development of automated
applications to address the limitations of existing legacy syste ms. These ―secondary‖
financial systems are used to manage resources, since the existing systems do not
provide information (i.e., allocation and expenditure information) in a timely manner and
at a level of detail required to meet Department needs.
The aging technology of existing financial information systems limits the Department’s
ability to adapt to changing business needs, especially the need for more detailed, real-
time financial data.
Systems developed to automate tasks rather than end-to-end processes have resulted in a
proliferation of narrowly focused systems that do not share data.
Specialized reporting systems have been developed to capture and report on data
contained in disparate systems.
Combined, these factors have adversely impacted the Department’s ability to effectively track,
manage, and report its finances. Please refer to the CIS’ Baseline Analysis and High-level Entity
Model for a detailed discussion of these findings.
2.1.2 CALTRANS INTEGRATION STUDY RECOMMENDATIONS
The Conceptual Architecture was developed to address the issues identified during the CIS
project. It focuses on the integration of the Department’s financial systems on an enterprise-
March 17, 2004 Page 5
Caltrans Integration Study Financial Systems Strategic Plan
wide basis (i.e., Department-wide, across division and district boundaries), eliminating the
redundancy of the four proposed systems and minimizing interfaces to other systems when
possible.
It is important to note the Conceptual Architecture developed during the CIS is intended to
depict one aspect (financial systems) of the Department’s overall enterprise-wide application
architecture. The financial systems have interfaces to other systems within the Department as
well.
Exhibit 7 compares the CIS proposed Conceptual Architecture to the architecture implied in the
FSRs for the four original systems.
Exhibit 7 – Original Requested Systems were integrated into the Proposed Architecture
March 17, 2004 Page 6
Caltrans Integration Study Financial Systems Strategic Plan
In order to implement the Conceptual Architecture, the CIS specifically recommends that the
Department:
Implement one enterprise-wide financial system (referred to as IFMS) that includes the
functionality of three of the four proposed systems (FMS, CLMS, CTIFS), using Tier 1
Enterprise Resource Planning (ERP) financial management software. An ERP is a large-
scale application that provides the enterprise-wide business functionality needed by large
organizations. An ERP vendor is often referred to as ―Tier 1‖ if they have a track record
of longevity, consistent performance, market leadership, and if their ERP applications
have breadth, depth and have been implemented across a wide range of industries. IFMS
is the term created during the CIS project to distinguish the scope of the financial
functionality included in the CIS project from that identified in the Department’s FMS
Alternative Procurement Business Justification (APBJ). The scope of the IFMS not only
includes the systems addressed by the FMS APBJ, but also numerous other existing
systems within the Department that include financial functionality.
Build CMS as a standalone system with an interface to the IFMS, since most of the CMS
functionality is not financial in nature
Implement an active Data Warehouse to support the Department’s financial reporting
requirements.
Implement an Enterprise Application Interface (EAI) to facilitate the sharing of required
data between the IFMS and other identified systems within the Department.
Eliminate 122 existing systems whose functions will be duplicated by the IFMS. For a
listing of these systems, refer to the Conceptual Architecture.
Move five specific reporting systems to the active data warehouse. Refer to the
Conceptual Architecture for details regarding the following five systems:
Earned Value Reporting System (EVRS)
Federal Projects Reporting System (FPRS)
Project Management Data Warehouse (PMDW)
Right of Way Management Information System (RWMIS)
Right of Way Management System (TPRC)
Interface 17 existing systems to the IFMS using the EAI software. Please refer to the
Conceptual Architecture for details on these systems.
2.1.3 CONCEPTUAL ARCHITECTURE D ETAILS
The following provides additional details on how the functionality of the four systems proposed
in the submitted FSRs are incorporated into the Conceptual Architecture.
Financial Manage ment System (FMS) – a majority of the required and desired FMS
functionality can be provided by the IFMS utilizing various integrated modules of a Tier
1 ERP, including Fixed Assets, Procurement, Inventory Management, Accounts Payable,
Accounts Receivable, Budget Preparation, Project/Grant Accounting, General Ledger,
March 17, 2004 Page 7
Caltrans Integration Study Financial Systems Strategic Plan
Labor Distribution, etc. To this end, the Conceptual Architecture recommends utilizing
a Tier 1 ERP to support the financial functionality of numerous existing systems
reviewed by the CIS team. For those Departmental systems that include financial
functionality in addition to specialized non- financial functionality, and therefore could
not be replaced by the implementation of the ERP, the Conceptual Architecture
recommends integration or interface(s) to exchange financial data with the IFMS.
CTIFS – the Conceptual Architecture incorporates the functions defined in the CTIFS
FSR into the IFMS. Programming, project implementation and funds management
functions will be provided in IFMS using the following Tier 1 ERP modules: Budget
Preparation, Fund Request, Project/Grant Accounting and General Ledger. The IFMS
will also provide local agencies, Metropolitan Planning Organizations (MPO) and
Regional Transportation Planning Authorities (RTPA) with web access to submit
candidate projects as part of the programming process.
CLMS – the Conceptual Architecture incorporates all the right of way processes and
data defined in the CLMS FSR into the IFMS. CLMS estimation, appraisal, parcel
acquisition, utility relocation, occupant relocation, property management, and excess
land sales functions would be provided by an ERP package that includes real estate
functionality as part of the solution. Additionally, CLMS project management
requirements for both projects and parcels will be satisfied by utilizing the proposed
Project Resource and Schedule Management System (PRSM), with such data available
in IFMS through an interface with PRSM.
CMS – In developing the Conceptual Architecture, a number of alternatives were
considered which could meet the CMS requirements. These alternatives ranged from
complete integration of CMS with IFMS to interfacing separate CMS and IFMS systems.
Given the significance and quantity of non- financial functionality in CMS, the
recommendation of the Conceptual Architecture is to develop or procure a standalone
system to meet CMS needs and provide an interface to the IFMS.
March 17, 2004 Page 8
Caltrans Integration Study Financial Systems Strategic Plan
2.2 Guiding Principles
The following Guiding Principles provided a framework for the development of the
recommendations detailed in the CIS deliverables. These principles were defined by the
Department’s Division Chiefs and helped set the direction of the overall CIS recommendations.
Exhibit 8 summarizes the Guiding Principles – please refer to the Conceptual Architecture for a
comprehensive listing of all of the guiding principles.
Exhibit 8 – Key CIS Guiding Principles
K EY CIS G UIDING PRINCIPLES
The Department’s mission critical activities (planning, project delivery,
maintenance and operations) are the primary drivers of its business –
consequently the Department’s financial system must support these activities.
Implementation of financial functionality (Budgeting, A/P, A/R, G/L, Procurement,
Inventory, Asset Management) should be based on how the function supports
and improves the Department’s mission critical activities (planning, project
delivery, maintenance and operations).
Appropriation control and fund accounting are critical Department business
functions.
It is appropriate to provide short-term fixes to existing systems to improve
access to information.
The “To Be” recommendations must support approaches other than a “big bang”
implementation
Detailed requirements, that define the desires of all stakeholders, must be
developed aft er the completion of the CIS.
Prior to implementation of an enterprise-wide financial system, the Department
must identify and implement a single project identifier methodology.
Resulting implementation efforts must adhere to Departmental stand ards.
The “To Be” recommendations rec ognize that some customization of packaged
solutions will be required – however, where customization is required, the
requirements must be well defined and reflect the desires of the stakeholders
To be successful, any resulting implementation effort will require executive
management leadership and commitment
March 17, 2004 Page 9
Caltrans Integration Study Financial Systems Strategic Plan
2.3 Assumptions and Constraints
In addition to the Guiding Principles, the Plan is based on certain assumptions and constraints
that have influenced the timing, dependencies, implementation approach and recommendations
of the Plan. The CIS recognizes that these assumptions may change as the Department’s needs
and environment change – should this occur, the Department might need to revise the Plan as
appropriate.
Conceptual Architecture – The Conceptual Architecture provides the framework for
what is being implemented and will impact the Department’s existing systems and
business processes. Deviations from the following assumptions would have the greatest
impact on the Plan. The assumptions include:
The Conceptual Architecture is driven by the Department’s business processes as
described in completed business process reviews, feasibility study reports, policy
manuals, and related documentation.
Standard enterprise resource planning (ERP) functions will be used wherever
possible. The Department will use the existing capabilities of the chosen ERP to the
extent possible and minimize customization.
ERP ―Best Practices‖ will be adopted as much as possible.
The ERP will be part of an enterprise-wide solution that interfaces with other
enterprise-wide systems, such as the Transportation Operations and Project Support
System (TOPSS), the Integrated Maintenance Management System (IMMS) and
Fleet Anywhere, through the EAI.
Projects defined in the Plan will receive approval, funding and sufficient resources
to fully implement the Conceptual Architecture.
Implementation Approach – Assumptions and constraints related to the how the plan
will be implemented increase the likelihood of the Plan’s approval and funding. The
assumptions include:
The Plan is based on the ―lessons learned‖, best practices, and information from
similar successful projects.
The Plan is structured to implement the CIS recommendations through a series of
multiple, independent projects. Each project has a specific scope and deliverables,
but is based on the overall CIS recommendations and Conceptual Architecture.
Different vendors could implement projects identified in the Plan. For example, a
vendor with deep accounting expertise may integrate the General Accounting
Project, whereas a vendor specializing in real estate implementations may integrate
the CLMS Project.
Project plans identified in this Plan exclude systems that were not in the original
CIS scope (BPMS, iBID) and activities related to Independent Project Oversight.
Project Sequencing and Dependencies – The Plan allows the department some
flexibility in determining when a project is undertaken. Project sequencing is constrained
March 17, 2004 Page 10
Caltrans Integration Study Financial Systems Strategic Plan
to some degree by the functional dependencies, and ―pain points‖ can be addressed prior
to the Conceptual Architecture being fully implemented. Assumptions and constraints
influencing project sequencing and dependencies include:
Project and activity sequencing is based upon the following factors:
Dependencies between required configuration and setup activities
Dependency upon master data (chart of accounts, Org ID, Vendor, etc.) being
available
Dependencies between required ERP functions
Expert judgment (from the CIS team)
Department defined priorities
Projects may be initiated on a sequential (waterfall) or parallel basis.
Project and activity durations are defined using a modeling approach detailed in
Appendix A.
A single project management system, PRSM, will provide project scheduling and
tracking functions and interface with IFMS to support project accounting functions.
On-going maintenance projects for the Department’s existing systems will address
pressing business needs until the existing system is replaced by the
recommendations of the Conceptual Architecture.
Strategies for Success – The Department must follow certain strategies to successfully
implement the CIS recommendations. These strategies are based upon industry best
practices specifically tailored to the Department. These assumptions include:
Success criteria will be identified, documented, reviewed, and agreed on by
Department management for each project, prior to any procurement activities
related to the project.
Sufficient technical and business resources will be available to implement the
Conceptual Architecture as identified in the Plan.
Project teams will include members from the Department’s business units. They
will be empowered to make business process, strategy, and policy changes as
needed in order to minimize required changes to the ERP’s standard processes, data
model, and code.
FSR development will commence as soon as possible.
FSRs for projects with no dependencies will be submitted first and the remaining
projects’ FSRs will be submitted based upon project dependencies and management
approval.
Network and Serve rs – Implementing the Conceptual Architecture will require changes
to the Department’s hardware and software. Regardless of these changes, current
performance standards must be met or exceeded. These assumptions include:
Network performance will remain at or above existing Department levels.
March 17, 2004 Page 11
Caltrans Integration Study Financial Systems Strategic Plan
Server performance will remain at or above existing Department levels.
System capacity planning will consider the Conceptual Architecture requirements.
2.4 Implementation Approach
The Plan documented in this report defines the recommended approach for moving from the
current state towards the desired or ―To Be‖ state recommended in the Conceptual Architecture
and the Integration Study Findings and Recommendations as summarized in Section 2.1.
The recommended approach for implementing the Conceptual Architecture is by business
function (e.g., General Ledger, Accounts Payable, Accounts Receivable, Fixed Assets, etc.),
based on a series of independent projects, each having a clearly defined scope and array of
functions to be delivered, utilizing a single ERP package. A number of factors were considered
in developing the recommended approach for implementing the Department’s new architecture,
including the guiding principles and assumptions developed as part of the Conceptual
Architecture.
Since the Plan involves the coordinated delivery of multiple projects, resulting in an enterprise-
wide integrated system, this report will use the term ―program‖ when referring to these projects
collectively. The name of this group of projects is the Integrated Systems Program.
The recommended implementation projects, illustrated in Exhibit 9 below, are discussed in detail
in the following paragraphs and include the following:
Infrastructure Project
General Accounting (GL, AR, AP) and Financial Reporting
Project Reporting
Construction Management System (CMS) Project
Fixed Assets Accounting Project
Budget Preparation Project
Procurement and Inventory Project
CTIFS Project
CLMS Project
This list of projects represents the largest feasible division of projects. The Plan, however,
recognizes that the Department could combine some of these projects, if desired. The
dependencies associated with these projects are described in Section 2.5 Project Sequencing and
Dependencies.
March 17, 2004 Page 12
Caltrans Integration Study Financial Systems Strategic Plan
Exhibit 9 – Integrated Systems Program
D e l i v e r y T i m e l i n e
FY 1 FY 2 FY 3 FY 4 FY 5
Sponsoring
Project Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Organization
Infrastructure
Enterprise Software,
Enterprise Active Data Warehousing,
Enterprise Application Integration
Procurement
Enterprise / General Accounting
General Ledger, Accts Payable, Accts
Finance Receivable, Financial Reporting
District /
Project Reporting
Programs
Construction CMS
Accounting /
Fixed Assets
DPAC
Budgets Budget Prep
Purchase Requisition,
DPAC
Procurement, Inventory
Programming,
DPAC
Federal Resources, CTIFS
Purchase Requisition
Local Assistance
Project
PRSM
Management
Right of Way CLMS
L E G E N D
= Prepare FSR = FSR Approval = Project Startup = Rollout
= Update FSR = Procure = Design, Configure, Develop, and Test = Dependency
The implementation strategy views each of these projects as discrete, stand-alone projects
supported by separate and unique project work plans. Each work plan, however, will include
standard package implementation project plan steps, such as:
Preparing the FSR
Updating FSR (if needed)
Submitting FSR to control agency for approval and funding
Vendor selection and procurement of software, hardware, and services
Project Start up, including refining the project plan with vendor/product specific tasks
Go/No Go review points
System Development (requirements validation, design, construction, configuration, d ata
conversion, data load, and testing)
Rollout/Go Live (production support, user training, transition into ongoing
maintenance/enhancements)
The Plan also recognizes that, during the interim time before the implementation and rollout of
the Plan’s projects, there may be a need to address ―pain points‖ by executing maintenance
March 17, 2004 Page 13
Caltrans Integration Study Financial Systems Strategic Plan
projects related to current systems to support day-to-day operations. Refer to Section 2.8
Maintenance Projects for a more detailed discussion of these projects. The reminder of this
section describes the implementation approach for each of the ten projects in the Plan.
2.4.1 INFRASTRUCTURE PROJECT
The Infrastructure Project encompasses all activities necessary to establish the technical
foundation needed to support the functions implemented by the remaining projects in the Plan.
These functions include, but are not limited to, financial accounting and procurement, funds
management, programming and land management. The key activities associated with the
Infrastructure Project include selection and procurement of software licenses and associated
hardware for the ERP, EAI, and active Data Warehouse. Although no specific functionality is
implemented during the course of this project, the remaining projects, as discussed below, rely
heavily on the availability of both hardware and software acquired and installed during the
Infrastructure Project.
The following tasks summarize the scope of the Infrastructure Project:
Develop FSR for Infrastructure based on the business and technical requirements of the
enterprise-wide financial system
Develop RFP for Infrastructure
Evaluate and select the ERP, active Data Warehouse, and middleware/EAI software
vendor/products
Select the hardware products and vendor(s)
Procure the required software and hardware
Procure the professional services required to install the infrastructure
Identify IT technical and infrastructure organizations, infrastructure support requirements
and code change management needs
Install the hardware, network equipment and communication links
Install the out-of-box ERP software to support training and development activities
Design, configure, and develop the EAI data exchange capabilities for project
environment and existing development systems
Install the active Data Warehouse software and link it with ERP software
Develop selected real time interfaces for each hardware platform
Provide technical training for IT, project team, and key management on hardware,
software, and infrastructure technology
For a more detailed list of tasks necessary to develop the FSR, procure the system, select the
vendor and implement the Infrastructure Project, refer to the Infrastructure Project Plan in
Appendix B of this deliverable. It is important to note that none of the existing systems will be
March 17, 2004 Page 14
Caltrans Integration Study Financial Systems Strategic Plan
replaced by the implementation of the Infrastructure Project. The phasing out of existing
systems will not occur until subsequent projects.
2.4.2 GENERAL ACCOUNTING PROJECT
The General Accounting Project encompasses all tasks necessary to implement the General
Ledger, Accounts Payable and Accounts Receivable functions of the IFMS, including the
procurement of staff and consultant services to assist in this effort.
This project represents the core financial functions of the IFMS, with the General Ledger being
the heart of the financial system that defines the account types and levels of information that can
be captured and reported upon. Implementation of this project represents the initial step towards
achieving a comprehensive, integrated, enterprise-wide solution for financial management
functions and operational functions. As a result, the Department will find itself with better
access to data and greater process efficiency, specifically related to its billing, cash management,
budget monitoring/control, and payable functions. As the remaining projects in the Plan are
implemented, each function will be integrated with the functions of the General Accounting
project.
The following tasks are included within the scope of the General Accounting Project:
Prepare FSR
Develop RFP for General Accounting implementation services (including additional
hardware and software licenses, if needed)
Select implementation vendor(s)
Update implementation work plan with vendor specific requirements
Design and map the ―To Be‖ Data Model to the ERP Data Model
Design the ―To Be‖ business processes based on ERP and industry best practices
Design the Project Accounting and Reporting Model
Design EA, Org Structure/Reporting/Legal entities
Design Data Archive and System Replacement details
Develop active Data Warehouse extracts for existing platforms (legacy extract
development)
Design and develop Enterprise Financial and Project Split and Combine reporting
utilizing data and structures of the ERP, and the Department’s systems, data mode l and
possible review of the EA structure. For more detail on EA and Project Split and
Combine, review the Conceptual Architecture, Section 8.2 High Level Data
Requirements of Integration and Interface.
Provide training for IT, project team and end users on the ERP, active Data Warehouse,
and EAI
March 17, 2004 Page 15
Caltrans Integration Study Financial Systems Strategic Plan
Implement ERP required functionality. The specific functionality to be implemented
during this project is identified in Exhibit 10 below:
Exhibit 10 – ERP Functionality to be impleme nted
ERP Functionality
General Ledger Establish and Maintain Chart of Accounts
Process Journal Entries
Allocate and Process Costs
Monitor and Control Budgets (including
Encumbrances)
Reconcile GL Accounts
Generat e GL Reports
Accounts Payable Establish and Maintain Vendor File
Encumbrance Trans action
Establish payment matching criteria
Integration with P rocurement
Process payments
Reconcile A/P Accounts
Generat e A/P Reports
Accounts Receivable Establish and Maintain Customers
Generat e Invoices
Process and Apply Receivables/Revenues
Collect Cash
Track A/R Status
Reconcile A/R Accounts
Generat e AR & Billing Reports
Convert existing GL, AR, and AP data from the legacy systems to the ERP and active
Data Warehouse
Develop reports to access historical data from the active Data Warehouse including
Enterprise Financial and Project Split/Combine reporting (SB45/AB1012) utilizing the
data and structures of the ERP.
Develop reports to access ERP enterprise data
Replace/remove existing systems—cut over from old systems to the ERP
A more detailed listing of the tasks necessary to develop the FSR, select the vendor and
implement the system are defined in the General Accounting Plan in Appendix B of this
deliverable. Once this project has been implemented, TRAMS as well as at least 65 other
accounting systems will be replaced, as described in the Conceptual Architecture, Section 2.7
Impact on Existing Systems in this document, and the General Accounting Project Plan included
Appendix B.
March 17, 2004 Page 16
Caltrans Integration Study Financial Systems Strategic Plan
2.4.3 PROJECT REPORTING PROJECT
The Project Reporting Project encompasses all tasks necessary to implement the Project and
Grant Accounting functions of the ERP, and reporting requirements of the active Data
Warehouse, including procurement of staff and consultant services to assist in this effort.
Implementation of this project will provide the Department with the ability to establish and
monitor a budget against a particular project as well as track and report the associated project
activities over the life of the project. Additionally, the Department would have the ability to
record, track, control, bill and report on activities affecting programs determined and funded by
external sponsoring organizations, such as local, state and federal entities.
The following tasks are included within the scope of the Project Reporting Project:
Prepare FSR for Project Reporting Project
Update FSR (if needed)
Develop RFP for Project Reporting implementation support
Select implementation vendor(s)
Update implementation work plan with vendor specific requirements
Create project ids, descriptions and project budget assignments
Configure necessary components to integrate Project Accounting with GL, AP and
Procurement functionalities
Implement project related labor cost validation and other project related expenses
Integrate Project Accounting with the project management tool (PRSM)
Create and update Work Breakdown Structure (WBS) and task dependencies (network)
from PRSM
Perform cost planning, including unit cost, cost elements and structure
Set up project evaluation/reporting and data needed for project evaluation
Convert existing data from legacy systems to the Project Accounting module
Archive (to active Data Warehouse or other storage media) any historical data for which
on- line, immediate access is not required.
Design and create project accounting related data extracts, transformation and load to the
active Data Warehouse
Design and create ODS and reporting cubes in the active Data Warehouse
Develop reports to access ERP enterprise data
Replace/remove existing systems—cut over from old systems to the ERP
A more detailed listing of the tasks necessary to this complete this project are defined in the
Project Accounting Project Plan in Appendix B of this deliverable. Once the Project Accounting
March 17, 2004 Page 17
Caltrans Integration Study Financial Systems Strategic Plan
functionality has been implemented, numerous Project Accounting Data Warehouses will be
replaced, as described in the Conceptual Architecture, as well as in Section 2.7 Impact on
Existing Systems in this document, and the Project Reporting Project Plan included Appendix B.
2.4.4 CMS PROJECT
The CMS project encompasses all tasks necessary to implement an application that supports the
Department’s construction management functions. These tasks include developing custom
construction management software, procuring supporting hardware and software, developing
interfaces or integrating with other Department systems, removing the existing construction
management system, as well as staff and consultant services.
As part of the General Accounting and Procurement and Inventory projects, a series of
development activities have been identified related to replacing the CMS system interfaces that
will have been developed between CMS and existing Department systems (e.g., TRAMS) as part
of the CMS Project. These interfaces will be replaced with interfaces to IFMS during the rollout
of the Accounts Payable and Contract functions in the IFMS.
2.4.5 FIXED ASSETS PROJECT
The Fixed Assets Project encompasses all tasks necessary for developing an FSR for
procurement of staff and consultant services to assist in the implementation of the Fixed Assets
functionality of the IFMS.
Implementation of this project will provide each of the Divisions with the ability to monitor and
report on all capitalized and non-capitalized property and equipment. More importantly, it will
provide the ability to capture and report on assets throughout the entire organization. The Fixed
Assets functions will be tightly integrated with the General Ledger, Procurement, and Accounts
Payable modules, which allow assets that meet the criteria for capitalization to be capitalized at
the time of payment. This will greatly benefit the Department by eliminating much of the
analysis and manual effort/duplicate data entry that is currently performed to capitalize an asset.
Tasks included with the scope of this project include:
Prepare FSR for Fixed Assets Project
Update FSR (if needed)
Develop RFP for Fixed Asset implementation support
Select implementation vendor(s)
Update implementation work plan with vendor specific requirements
Implement Fixed Assets module, which includes classifying, maintaining, controlling,
capitalizing, depreciating and disposing of assets
Replace existing asset management systems
Extract data from the ERP to the active Data Warehouse
March 17, 2004 Page 18
Caltrans Integration Study Financial Systems Strategic Plan
Report on assets (utilizing the ERP Enterprise Data and active Data Warehouse)
A more detailed listing of the tasks necessary to implement the Fixed Assets functionality is
defined in the Fixed Assets Project Plan in Appendix B of this deliverable. Once the Fixed Asset
functionality has been implemented, numerous stand-alone, asset tracking systems will be
replaced, as described in the Conceptual Architecture, as well as in Section 2.7 Impact on
Existing Systems in this document, and the Fixed Assets Project Plan included Appendix B.
2.4.6 B UDGET PREPARATION PROJECT
The Budget Preparation Project encompasses all tasks necessary for developing an FSR for
procurement of staff and consultant services to assist with the implementation of the budget
preparation/development functionality of the ERP, EAI and DW. The specific tasks necessary to
implement this functionality are defined in the Budget Preparation Project Plan in Appendix B of
this deliverable.
Implementation of the Budget Preparation Module will provide the Department with the ability
to perform trend analysis/budget modeling functions, analyzing the current or prior year budget
and/or actual information, manipulate the data and create and store various ―what if‖ scenarios
for operational and project related budgets.
Once the Budget Preparation functionality has been implemented, numerous existing budget
systems will be replaced, as described in the Conceptual Architecture and the Budget Preparation
Project Plan. It is important to note that the budget monitoring and control capabilities are
considered General Ledger functions and will be implemented and rolled out during the General
Accounting Project.
The following tasks are included within the scope of the Budget Preparation Project:
Prepare FSR for Budget Preparation Project
Update FSR (if needed)
Develop RFP for Budget Preparation implementation support
Select implementation vendor(s)
Update implementation work plan with vendor specific requirements
Convert existing budget data from legacy systems to the ERP Budget Preparation module
Archive (to active Data Warehouse or other means) any historical data for which on- line,
immediate access is not required.
Design and create budget related data extracts, transformation and load to the active Data
Warehouse
Design and create ODS and reporting cubes in the active Data Warehouse
Develop reports to access ERP enterprise data
Replace/remove existing systems—cut over from old systems to the ERP
March 17, 2004 Page 19
Caltrans Integration Study Financial Systems Strategic Plan
A more detailed listing of the tasks necessary to implement the Budget Preparation functionality
is defined in the Budget Preparation Project Plan in Appendix B of this deliverable. Once the
Budget Preparation functionality has been implemented, numerous stand-alone systems will be
replaced, as described in the Conceptual Architecture, as well as in Section 2.7 Impact on
Existing Systems in this document, and the Budget Preparation Project Plan included Appendix
B.
2.4.7 PROCUREMENT AND INVENTORY PROJECT
The Procurement and Inventory Project encompasses all tasks necessary for developing an FSR
for procurement of staff and consultant services to assist in the implementation of the
Procurement function, including decentralized web based requisition processing within the
Department. This project also includes the functions of processing and tracking supplies
inventory. It is important to note that tracking of parts/vehicles related to maintenance activities
and material movement is not within the scope of this project. These functions will continue to
be performed in Fleet Anywhere and IMMS with interfaces to/from the IFMS. In short, the
inventory management functions implemented as part of this project include all functions
necessary to run the HQ and District warehouses, including reordering supplies when they reach
a pre-defined level, but do not include any other material movement and material management
functions.
Implementation of this project streamlines the current procurement and inventory process and
improves productivity by utilizing functions such as online requisitions, purc hase
orders/contracts and change orders, electronic catalogs, automated workflow approvals,
electronic commerce email, automatic faxing, etc. The Procurement module will be tightly
integrated with the General Ledger and Accounts Payable modules to enable budget checking
and encumbrance accounting at the time of procurement, therefore eliminating much of the
redundant data entry currently performed in the Division of Accounting and Division of
Procurement and Contracts.
The following tasks are included within the scope of the Procurement and Inventory Project:
Prepare FSR for Procurement and Inventory Project
Update FSR (if needed)
Develop RFP for Procurement and Inventory implementation support
Select implementation vendor(s)
Update implementation work plan with vendor specific requirements
March 17, 2004 Page 20
Caltrans Integration Study Financial Systems Strategic Plan
Implement ERP modules for required functionality. The specific functionality to be
implemented during this project is identified below:
Exhibit 11 – ERP Functionality to be implemented
ERP Functionality
Procurement Determine Sourc e of Goods/Servic es
Bid/Proposal Processing
Decentralized requisition processing via the web
Processing Requests for Goods/Servic es
Integration with Accounting
Receive Goods/Services
Generat e Procurement/Purchasing Reports
Inventory Add (supplies) inventory
Distribute (s upplies) invent ory
Manage (supplies) inventory
Generat e Inventory Reports
Convert existing data from the legacy systems to the ERP and active Data Warehouse
Archive (to active Data Warehouse of other means) any historical procurement and
vendor related data for which on- line, immediate access is not required.
Develop reports to access historical data from the active Data Warehouse
Develop reports to access ERP enterprise data
Replace/remove existing systems—cut over from old systems to the ERP
A more detailed listing of the tasks necessary to develop the FSR, select the vendor and
implement the procurement and inventory functions are defined in Section 2.7 Impact on
Existing Systems and the Procurement and Inventory Project Plan in Appendix B of this
deliverable. Although these functions could be implemented as part of the General Accounting
Project, the recommended implementation plan reflects it as a discrete project that will be
implemented separate from General Accounting due to the large number of users impacted by its
implementation, and the widespread training effort that will be required to implement these
functions, particularly decentralized web-based requisition processing.
2.4.8 CTIFS PROJECT
The CTIFS Project encompasses all tasks necessary to develop an FSR for procuring staff and
consultant services to implement the CTIFS functionality within IFMS through the ERP, EAI
and the active Data Warehouse. Once the CTIFS functionality has been implemented using the
Fund/Grant Management functionality, EAI and active Data Warehouse, several systems
currently used by the Programming, Local Assistance and Budgets Divisions will be replaced as
described in the Conceptual Architecture, Section 2.7 Impact on Existing Systems in this
document and the CTIFS Project Plan in Appendix B of this deliverable.
The CTIFS Project will provide the Programming, Local Assistance and Budgets Divisions with
the ability to ―program‖ projects into STIP, SHOPP and categorical programs; obtain and
March 17, 2004 Page 21
Caltrans Integration Study Financial Systems Strategic Plan
manage federal funds; and oversee projects constructed by local agencies. The ERP functions to
support these requirements will be partially implemented with the General Accounting and
Project Reporting Projects, but will not be fully provided until the CTIFS Project implements the
ERP Funds/Grant Management functionality. The Divisions currently conduct their business
processes using several systems operating on different platforms, having differing levels of
integration and at times generating less than timely reports. The CTIFS Project will allow these
three Divisions to integrate their business processes using a single system to ―program‖ a project,
receive federal approval to proceed and federal funding, and provide SB45 and AB1012 reports
for local agencies. The ability to generate these legislatively required reports based on timely
data would allow the local agencies to effectively use their allocated funding, instead of risk
losing them to other local agencies or state projects.
The following tasks are included within the scope of the CTIFS Project:
Prepare FSR for CTIFS Project
Update FSR (if needed)
Develop RFP for CTIFS implementation support
Select implementation vendor(s)
Update implementation work plan with vendor specific requirements
Integrate Fund/Grant Management and ERP Project Accounting and Project Budget
Implement actual project WBS costs, impact on project budget, and allocated Fund/Grant
Convert CTIFS related data from existing Department systems to the ERP
Archive (to active Data Warehouse or other means) any historical data for which on- line,
immediate access is not required.
Design and create CTIFS related data extracts, transformation, and load to the active
Data Warehouse
Design and create ODS, and reporting Cubes in active Data Warehouse
Provide access to districts and local agencies thru Web to establish funding
request/application and capabilities to track and review status of each request
Replace/remove existing systems—cut over from old systems to the ERP
2.4.9 CLMS PROJECT
The CLMS Project encompasses all tasks necessary to develop an FSR for procuring staff and
consultant services to implement the CLMS functionality within IFMS through the ERP, EAI
and the active Data Warehouse. Once the CLMS functionality has been implemented, several
systems currently used by the Division of Right of Way will be replaced as described in the
Conceptual Architecture, Section 2.7 Impact on Existing Systems in this document and the
CLMS Project Plan in Appendix B of this deliverable.
March 17, 2004 Page 22
Caltrans Integration Study Financial Systems Strategic Plan
The CLMS Project will integrate functionality provided by earlier projects—procurement,
payables, receivables, budgeting, inventory, fixed assets—with the real estate functionality
provided by the ERP’s Real Estate module. Within this integrated environment, the Division of
Right of Way will be able to cost alternate routes for a transportation project based upon routes
passing through various parcels defined in the Real Estate module. Once a route has been
chosen, the Right of Way agents can then purchase the parcels previously defined relying on the
integration between the parcel in the Real Estate module and the seller in the procurement and
accounts payable modules. Right of Way will continue as landlord for many properties before
finally using the property for road construction or selling it as excess land. The Real Estate
module is specifically designed for managing tenants and properties, maintaining properties, and
selling the excess land. Currently these core business processes are supported by a variety of
systems integrated to varying degrees. Right of Way staff plays roles of appraiser, buyer, seller
and manager of a wide range of objects, including projects, parcels, properties, tenants and
disposal units.
After completing the CLMS project, Right of Way management and staff will perform their
activities within a single integrated system and be able to generate reports on this broad range of
objects. Current requests from the legislature for special reports result in ―fire drills‖ where
headquarters staff must request data from various systems owners at headquarters and in the
Districts. Once Right of Way is using a single integrated system, these requests will be easier to
satisfy.
The following tasks are included within the scope of the CLMS Project:
Prepare FSR
Update FSR (if needed)
Develop RFP for CLMS implementation support
Select implementation vendor(s)
Update implementation work plan with vendor specific requirements
Configure Real Estate functions based on Right of Way requirements
Convert CLMS related data from existing Right of Way systems to the ERP
Archive (to active Data Warehouse or other means) any historical CLMS data for which
on- line, immediate access is not required.
Design and creation of CLMS related data extracts, transformation, and load to the active
Data Warehouse
Design and create ODS, and reporting Cubes in active Data Warehouse
Replace/remove existing systems—cut over from old systems to the ERP
March 17, 2004 Page 23
Caltrans Integration Study Financial Systems Strategic Plan
2.4.10 PRSM
PRSM is an active project within the Department, b ut is not within the scope of the projects
defined in the Plan. The significance of the PRSM Project as it relates to the Plan involves
integrating and interfacing the project accounting functions of the ERP with PRSM scheduling
functionality. PRSM will also be needed to satisfy CLMS project management requirements.
As part of the Project Reporting Project, a series of development activities have been identified
related to interfaces that will be developed between PRSM and the Project Reporting Project.
2.5 Project Sequencing and Dependencies
The implementation strategy reflects the Infrastructure Project as a foundation project with all
other projects in the Plan dependent upon its implementation. The remaining projects rely
heavily on the installation of both hardware and software, tasks that occur during the
Infrastructure Project. As a result, the Infrastructure Project will start prior to any other project
(with the exception of CMS, which can start concurrently). It is important to note that the
Infrastructure FSR, which includes the procurement of all ERP software needed to support all of
the projects, relies on functional and technical requirements developed as part of the FSRs for the
all projects within the Plan. As a result, the Strategic Plan reflects tasks to prepare the FSRs
beginning simultaneously for each of these eight projects.
When implementing an integrated financial system, the General Ledger module is typically the
first ERP module to be implemented, as the other modules rely on the baseline configuration and
chart of accounts, organizational structure, reporting entities, and EA design set up. The General
Accounting Project, which includes implementation of the General Ledger functions, should
therefore be implemented right after the Infrastructure Project. In order to take advantage of the
integration proposed in the IFMS conceptual design, creation of purchase orders and the
associated encumbrance transactions, which are core accounting functions, should be considered
for inclusion in the General Accounting project or at a minimum, implemented during the same
timeframe as the General Accounting Project.
Many of the other implementation projects can be designed as waves, sequentially or in parallel
based on identified dependencies or lack thereof. For example, the Fixed Assets, Project
Reporting and Budget Preparation Projects can be implemented in parallel, before, or after one
another. All three of these projects, however, must be implemented as separate waves after the
Infrastructure and General Accounting Project because of their dependency on the General
Ledger and implementation of base configuration. The timing of the Project Reporting Project is
also dependent upon the implementation of the Project Management functionality (PRSM) and
its integration with the Project Reporting functionalities in the ERP.
In order for the Division of Accounting and the Division of Procurement and Contracts (DPAC)
to fully reap the benefits of an integrated financial and procurement system, the Procurement
(inventory and non- inventory) Project should be developed during the same timeframe as the
General Accounting Project with the ―back-office‖ functions of procurement rolled out to
production at the same time as General Accounting Project. The web based purchase requisition
functions of the Procurement Project could be rolled out at any point in time after the ―back-
March 17, 2004 Page 24
Caltrans Integration Study Financial Systems Strategic Plan
office‖ functionalities are in production. The timing of this implementation and rollout is
dependant upon the availability of the Department’s resources.
The CTIFS Project, which includes Fund and Grants Management functionality, cannot begin
until the General Accounting and Project Accounting projects are implemented. Similarly, the
CLMS Project, which is the integration of Real Estate module with Project Accounting,
Procurement, Accounts Payable, Fixed Assets, and General Ledger, cannot be implemented until
the Project Accounting, General Accounting, Procurement, and Fixed Assets functions are
implemented.
As previously stated, the Conceptual Architecture recommends developing/procuring an
operational Construction Management System (CMS), with interfaces to integrate with the
IFMS. Therefore, the implementation of CMS will not be dependent upon implementation of the
Infrastructure Project or any other project in the Plan, minimizing the impact upon project
delivery for CMS. Given the lack of dependencies relative to other projects, the strategic plan
has the CMS Project beginning concurrent to the Infrastructure Project. Since CMS may in
theory be delivered before General Accounting Project is completed, tasks have been included as
part of General Accounting delivery project plan to modify CMS interfaces and payment
processes to coincide with new IFMS capabilities.
March 17, 2004 Page 25
Caltrans Integration Study Financial Systems Strategic Plan
Exhibit 12 summarizes the recommended project implementation sequence for the projects
included in the Integrated Systems Program based on the dependencies noted above. Project
dependencies are highlighted with red arrows and indicate the earliest point in the Plan that a
project activity can begin.
Exhibit 12 – Integrated System s Program
D e l i v e r y T i m e l i n e
FY 1 FY 2 FY 3 FY 4 FY 5
Sponsoring
Project Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Organization
Infrastructure
Enterprise Software,
Enterprise Active Data Warehousing,
Enterprise Application Integration
Procurement
Enterprise / General Accounting
General Ledger, Accts Payable, Accts
Finance Receivable, Financial Reporting
District /
Project Reporting
Programs
Construction CMS
Accounting /
Fixed Assets
DPAC
Budgets Budget Prep
Purchase Requisition,
DPAC
Procurement, Inventory
Programming,
DPAC
Federal Resources, CTIFS
Purchase Requisition
Local Assistance
Project
PRSM
Management
Right of Way CLMS
L E G E N D
= Prepare FSR = FSR Approval = Project Startup = Rollout
= Update FSR = Procure = Design, Configure, Develop, and Test = Dependency
2.6 Data Conversion and Reporting on Historical Data
Data Conversion is one of the most critical steps in the implementation of Conceptual
Architecture and removal of candidate systems. There are multiple factors that should be
considered when determining whether the Department should utilize manual or automated means
for converting data from existing systems to the Conceptual Architecture. These factors include,
but are not limited to:
Volume of data to be converted. The smaller the volume of data that requires
conversion, the greater likelihood that it should be manually converted.
Level of programming effort required. In addition to requiring knowledge of the
database and application design (for source and destination), significant programming
effort may be needed to move data elements for a legacy data source to the new
architecture.
March 17, 2004 Page 26
Caltrans Integration Study Financial Systems Strategic Plan
Frequency with which the data will be changed during the course of the implementation.
Availability of Resources. The resources required for manual conversion, testing, and
training, would all be competing for the same resources.
Type of data/records that will be converted. In general there are six types of data from
legacy systems which will need to be converted into the new system:
In-process data/items/transactions, such as open purchase orders, and invoices,
which are not paid yet and checks not yet reconciled, etc. This type of data is
typically converted to the ERP database.
Recently completed transactional data, which may be needed for audit and reporting
purposes. Examples, include project related data, last year’s budget, last fiscal
month’s balances, payments or purchase orders to a particular vendor, etc. This type
of data is typically converted to the ERP database.
Master data such as organizations, chart of accounts, vendor information,
parts/catalog data, price, etc. This type of data is typically converted to the ERP
database.
Structural and event determination type data such as valid status codes to support
processes in the legacy procurement systems, document number ranges and
identification indicators, etc. This type of data is typically cross-referenced and
converted to the ERP database.
Historical transactional data, needed for day-to-day operation, such as inception to
date project information. This type of data is typically converted to the ERP
database as well as the active Data Warehouse for reporting.
Historical data, not needed for day-to-day operation, but required for audit or
legislatively required reporting, and trend analysis. This data is typically converted
to an active Data Warehouse. The active Data Warehouse facilitates reporting on
historical data that currently resides in one or more discrete systems.
Regardless of the method used to convert data, it is imperative that the data be evaluated and
cleansed before it is prepared for conversion. Data cleansing is a process of amending or
removing data in a database that is incorrect, incomplete, improperly formatted or duplicated.
Conversion could be achieved either by transforming value(s) of data within each converted
record, or by using cross-reference tables (also known as ―translators‖) and preserving the
original value of the data within the new system.
The recommended approach to data conversion starts with establishing a Data Conversion Policy
(DCP). Policies based on a detailed technical and business assessment will provide needed
guidelines and evaluation criteria, such as the volume, usage, and purpose of the data to help
determine ideal method of converting the data and the location where the data should be
preserved. A well written DCP will assist in answering questions such as should historical data
be extracted from legacy systems and moved to the IFMS transactional system (ERP), or moved
to an active Data Warehouse and used for historical or audit reporting, or merely saved on a
magnetic or optical media for storage and archive purposes.
March 17, 2004 Page 27
Caltrans Integration Study Financial Systems Strategic Plan
Once the conversion framework is in place, based on guidelines defined in the DCP, the
conversion tables and programs can then be constructed to convert the legacy data. During the
implementation of each project, it will be necessary to define the transactio n (source) system and
active Data Warehouse Extract Transformation and Load (ETL) process which will determine
the types of data, as well as the level of detail that should reside in the active Data Warehouse,
then map and update the reporting requirements to the out of the box (baseline) capabilities of
the software and identify the need for any enhancements or customization.
The timing of implementation and rollout (i.e., fiscal year end vs. end of the calendar year) may
also affect the types and methods of data that should be considered for conversion. It is best
practice to convert existing accounting data into a new system at the end of the fiscal year. This
approach will reduce risks and facilitate traceability of the financial data for audit purposes.
The following list represents the types of data that are most likely to be converted:
Vendor File(s)
Customer File(s)
Open purchase orders
Open requisitions
Accounts Receivable subsidiary balances
Chart of Accounts
General Ledger Accounts and Balances
Expenditure Authorization and related structural codes (Funds, Programs, Organizations)
Asset records
Parts inventory
Parts Price
Projects/Funding
Contracts
March 17, 2004 Page 28
Caltrans Integration Study Financial Systems Strategic Plan
2.7 Impact on Existing Systems
The following section defines the impact on existing systems as the functions associated with the
projects identified in the Plan are implemented and rolled out. Within each project plan the
systems are grouped as follows:
Replacement: Replace existing system, as its functionality is made available in IFMS.
For example, after the General Accounting Project is completed, accounts receivable
functionality will be available through IFMS. The current Accounts Receivable System
(ARS) would no longer be needed.
Interface & Integrate: Create a new interface between IFMS and systems that previously
interfaced with replaced systems. For example, the interface between TRAMS and
LPAMS would no longer exist after TRAMS is replaced. A new interface would be
required between IFMS and LPAMS.
Impacted Systems: Enhance retained systems to provide a particular functionality. For
example, TOPSS would require additional HR functionality currently provided by the
Automated 8 and PTAS systems, instead of providing this functionality in the ERP.
Intermediate Interface – Create interfaces between the ERP and existing systems that
have not been fully replaced. For example, intermediate interfaces between CMS and
TRAMS will be replaced when IFMS and the active Data Warehouse are implemented.
2.7.1 INFRASTRUCTURE PROJECT
None of the existing systems will be impacted or replaced by the implementation of the
―Infrastructure Project‖. The phasing out of existing systems will not occur until subsequent
projects. During this project, Enterprise Application Integration software will be installed and
physical connections between legacy nodes, ERP, and DW will be developed and tested.
2.7.2 GENERAL ACCOUNTING PROJECT
2.7.2.1 General Ledger
The General Ledger implementation will require integration and interfaces with the following
systems:
Fleet Anywhere (FA)
Integrated Maintenance Management System (IMMS)
Project Management Systems (PRSM)
Transportation Operation and Project Support System (TOPSS)
March 17, 2004 Page 29
Caltrans Integration Study Financial Systems Strategic Plan
During the roll out of the General Ledger the following systems will be replaced (removed from
operation):
Bridge Allocation Tracking System
Capital Outlay Support Overhead Assessment Rates (COSOAR)
Category 25 Reporting
Cost Allocation System
Division of Accounting Training Tracking
Encumbrance Refresh and Calculation System
Expenditure Authorization System/Capital Outlay Mo nitoring System (EAS/COMS)
GASB 34 Prospective Reporting System
Labor Distribution System (LDS)
Net Zero System (NZ)
Operating Expense Tracking (OET)
Overhead Assessment Reimbursement and Billing System (OAR)
Payroll Variance Distribution System
Rail Bonds/TCI Reporting System (RBR)
SB 45 Mainframe
Schedule 3 Reconciliation (SCH3)
Single Project Expenditure Authorization (SPEA)
Transportation Accounting System (TRAMS)
The following systems will not be removed, but will be impacted by this implementation and
will require additional development in the form of intermediate interfaces:
Local Programs Accounting and Management System (LPAMS)
EA Table from IFMS to LPAMS
Final Voucher and Purchase data from LPAMS to IFMS
Project Encumbered Amount and AP Transaction from LPAMS to IFMS
2.7.2.2 Accounts Payable
The Accounts Payable implementation will require integration and interfaces with the
Aeronautics Database System (ADS), Construction Management System (CMS), as well as a
tape interface with State Controller Office (SCO) system for claim schedules.
March 17, 2004 Page 30
Caltrans Integration Study Financial Systems Strategic Plan
During the Accounts Payable roll out, the following systems will be replaced (removed from
operation):
Accounts Payable Control Log System (CLS)
Active Vendor Listing (AVL)
American Express Billing System
Batch Query System (OAP Control Log)
Bulk Fuel Invoices Payment System (BFI)
CADb District 4 System (CADb)
CalCard Tracker Database
Caltrans Accounts Payable System (CAPS)
Contract Administration & Tracking System (CATS)
Contract Delegation Purchase Order System (CDPOS) – replacement of Vendor file
functions of this system should be in-sync with implementation of Procurement project.
Direct Transfer System (DTS)
Duplicate Payment Reporting System (DPRS)
Electronic Data Interchange (EDI)
Electronic Fund Transfer Database
Independent Contractor’s Reporting System
Interest Penalty System
No Warrant System (NOW)
Paper Utility Bills System (PUBS)
Personal Use of State Vehicles (PUSV)
PETS Special Handling (PSH)
Private Car Mileage System (Private Car Usage (PCU))
Progress Estimate Tracking System (PETS)
Purchase Card Accounting and Requisition System (PCARS)
Rental Rate Report
Reportable Payment System (RPS)
Revolving Fund System (RFS)
Right of Way Accounting Control Log
Right of Way Claim Log and Excess Lands Tracking System (CLELR)
March 17, 2004 Page 31
Caltrans Integration Study Financial Systems Strategic Plan
SCO Daily Direct Claims Paid System (DCP)
Service Contracts Automated Tracking System (SCATS)
Statewide Utility Billing System (SUBS)
TEC Reportable Payment Reporting System (TERP)
Telephone Billing Upload System (TBUS)
Transportation Accounting System (TRAMS)
Travel Reporting System
Since CMS detail design may not be completed at the time of the Accounts Payable
implementation, the impact of IFMS on existing Construction Management Systems (listed
below) and the number of interfaces could change and should be reviewed.
Construction Administration System (CAS)
Construction Contract Information System (CCIS)
Construction Contract Payments (WCCP)
Extra Work Billing (EWB)
Intermediate interfaces will be required for the following Right of Way Systems:
Integrated Right of Way System (IRWS) – AP functions will be replaced
Right of Way Utility Relocation System (RUMS) – current manual interface w/ TRAMS
A/P will be replaced w/ ERP interface
Right of Way Property Management System (RWPS) – provide vendor payments for
maintenance to the ERP
2.7.2.3 Accounts Receivable
The Accounts Receivable implementation will require integration and interfaces with the
following systems:
Fleet Anywhere (FA)
Integrated Maintenance Management System (IMMS)
Federal Financial Management Information System (FMIS)
During Accounts Receivable roll out, the following systems will be replaced (removed from
operation):
Accounts Receivable Reconciliation (ARR)
March 17, 2004 Page 32
Caltrans Integration Study Financial Systems Strategic Plan
Accounts Receivable System (ARS)
Automated Remittance Processing System (ARPS)
Completed Federal Project Inventory System (CFPIS)
Current Billing & Reporting System (CBARS)
Encroachment Permits Tracking System (EPTS)
Equipment Charge Statement Application (ECS)
Excess Land Interest Reporting (ELI)
Payroll Account Receivable & Reporting System (PARR)
Reimbursement PC Reporting System
Reimbursement Subsystem
Salary Advance Monitoring System (SAL)
Signals and Lighting Billing (SLB)
Student Assistance Tracking
Transportation Accounting System (TRAMS)
Travel Advance Monitoring System (TAMS)
Un-cleared FAE 8 Transactions (UNC)
Implementation of Accounts Receivable will impact following systems:
Right of Way systems
Right of Way Property Management System (RWPS) existing interfaces will be
modified to provide rental invoices to IFMS
Active Data Warehouse
Right of Way Management Information System (RWMIS)
Excess Land Sales
Parcels Acquired
Timesheet Data
Production & Workload Data
Air Space & Property Inventory
―EA, Certification date, Relocation Costs‖
―EA, Parcel, Location, Project data‖
Federal Projects Reporting System (FPRS)
Construction Payment data
Expenditure data
Financial Master data
Federal Aid Billing data
March 17, 2004 Page 33
Caltrans Integration Study Financial Systems Strategic Plan
2.7.3 PROJECT REPORTING PROJECT
Implementation of Project Reporting will require interfaces with:
Aeronautics Database System (ADS)
ECR
FMIS – note interface for billing Fed is created during General Accounting Project as
part of Accounts Receivable
OE Project Database
PRSM
Additionally, this project will replace existing Data Warehouses, such as:
Earned Value Reporting System (EVRS)
Project Management Data Warehouse (PMDW)
Impact of this project on following systems should be reviewed during implementation:
Expert Project Management (XPM)
Project Management and Control (PMCS)
RWMIS
TPRS
2.7.4 FIXED ASSETS PROJECT
The Fixed Assets implementation will require interfaces with Fleet Anywhere (FA). The roll out
of Fixed Assets functions will replace the following systems:
Asset Management Inventory (AMI)
District 32 Equipment System
Equipment Rental Rate Export System
Integrated Right of Way System (IRWS) – replacing Fixed Assets functions of IRWS
should be coordinated with implementation of CLMS Project.
Inventory Management System (pilot by D3 for use by Districts 1,2,3,8,5)
Land & Building System – Special Transactions
Nonexpendable Equipment Database System
Property Control Inventory System (SVI/PCMS)
Rental Rate System (RRS)
Surplus Sales
Tool and Computer Inventory System
Vehicle Usage Reporting System (URS)
March 17, 2004 Page 34
Caltrans Integration Study Financial Systems Strategic Plan
2.7.5 B UDGET PREPARATION PROJECT
The Budget Preparation implementation will require integration and interfaces with Fiscal
Database.
During the roll out of Budget Prep, Funds & Resources functions, the following systems will be
replaced (removed from operation):
Budget Allocation Tracking System (BAS)
Budget Monitoring System (BMS)
Expenditures Database
Capital Allocations Database
Electronic Equipment Budget Request System (EBR)
Engineering Cost Reporting System (ECR) – consider removal date with Project
Accounting rollout.
Highway Maintenance Tracking System – consider timing of removal with Project
Accounting and Interfaces with CTIPS
Traffic Operations Management Information System (TOMIS)
Implementation of this project will require TOPSS to be enhanced in order to provide the current
functions provided by Position Tracking Administration System (PTAS), and Automated 8.
2.7.6 PROCUREMENT AND INVENTORY PROJECT
2.7.6.1 Procurement
The Procurement implementation will require integration and interfaces with Fleet Anywhere
(FA), Engineering Bid system (iBID), and Construction Management System (CMS).
During the Procurement roll out, the following systems will be replaced (removed from
operation):
360 Log
Architecture & Engineering Database
Bid Unit Database
Contract Administration & Tracking System (CATS)
Contract Delegation Purchase Order System (CDPOS)
Contracts Status Tracking System (CSTS)
Drug-Free Certifications Database
March 17, 2004 Page 35
Caltrans Integration Study Financial Systems Strategic Plan
IT Procurement & OE Tracking System
During the implementation of this project, Integrated Right of Way System (IRWS) procurement
functions will be replaced, while other functions of this system will remain in production until
roll out of CLMS. Right of Way Property Management System (RWPS) will have an
intermediate interface to provide vendor payments to the ERP. The Electronic Equipment
Budget Request System (EBR), and Bid Opening System (BID) functions of iBID will need to
be reviewed for any impact.
2.7.6.2 Inventory
Implementation of Procurement for inventory and non-inventory items will require integration
and interfaces with Fleet Anywhere (FA) and Integrated Maintenance Management System
(IMMS).
During the roll out of the Inventory functions of the Procurement Project, the following systems
will be replaced (removed from operation):
Bill of Lading System
LREDP Log
Publications and Document Inventory System (PDIS)
Non-Expendable Equipment Inventory (ENEX, also referred to as SCOPE)
Service and Supply Material Management System (SVS)
STOCK
For this implementation, interfaces with the new Engineering System (iBID) will need to be
reviewed and designed. The following impacted systems will be reviewed to ensure the new
iBID and ERP systems will function with existing engineering systems such as:
Basic Engineering Estimating System (BEES)
Bid Opening System (BID)
Bridge Bid Analysis System (BBA)
Construction Unit Cost System (CUC)
March 17, 2004 Page 36
Caltrans Integration Study Financial Systems Strategic Plan
2.7.7 CTIFS PROJECT
The Fund/Grant Management (CTIFS) implementation will require interfaces with:
Aeronautics Database System (ADS)
Bridge Management System
FMIS (external to existing Caltrans environment)
IMMS for damage assessment forms
OE Project Database
PRSM for programmed projects
Transportation System Network (TSN)
CTIFS roll out will replace the following existing systems:
Authorizations Database
California Transportation Improvement Program System (CTIPS)
Federal Aid Data System (FADS)
Local Programs 2000 (LP2000)
Local Programs Accounting and Management System (LPAMS)
2.7.8 CLMS PROJECT
The CLMS implementation will require removal of the following existing Right of Way systems:
Right of Way Utility Relocation System (RUMS)
Right of Way Property Management System (RWPS)
Right of Way Excess Lands System (ELMS-TPRX)
Integrated Right of Way System (IRWS)
Development of CLMS will require integration of ERP project accounting with the new project
management system (PRSM). Also the two existing Right of Way Data Warehouses, the Right of
Way Management Information System (RWMIS) and the Right of Way Management System
(TPRC) will be removed and a new active Data Warehouse will be designed and released to
production.
2.7.9 ACTIVE DATA WAREHOUSE
Activities related to development and roll out of active Data Warehouse ETL and reporting are
identified and allocated to each functional project (General Accounting, Fixed Assets,
March 17, 2004 Page 37
Caltrans Integration Study Financial Systems Strategic Plan
Procurement, Project Reporting, CLMS, CTIFS, etc.). To summarize, active Data Warehouse
implementation at minimum will require replacement of:
Earned Value Reporting System (EVRS)
Project Management Data Warehouse
Project Management Data Warehouse (PMDW)
Right of Way Management Information System (RWMIS)
Right of Way Management System (TPRC)
Conversion of historical data and data archiving DW for historical reporting
Detail of active Data Warehouse interfaces and implementation considerations are listed in the
Conceptual Architecture, Section 7.3 Listing of Integration and Interface Requirements.
2.8 Maintenance Projects
Even with the aggressive schedule laid out in the Plan, some functions will not be available for
an extended period of time. Problems with funding and/or resources could extend the schedule
even further. Because of this, certain business problems or ―pain points‖ need to be addressed
prior to a scheduled system replacement or an ERP function being available. To address these
pain points the CIS Workgroup members have identified four project groups that would address
business needs prior to the Conceptual Architecture being fully implemented. These maintenance
and update activities are not part of the CIS-defined Conceptual Architecture, but merely
acknowledge certain issues could be addressed through the following:
General Accounting Current Systems Maintenance and Updates. The second project
scheduled for implementation, the General Accounting Project, may not be completed
for two or more years. In the meantime, existing systems such as CAPS, EAS/COMS
and ARS may cease to function due to the limitations of their technical environments.
Project Reporting and Maintenance. Only after implementing the Conceptual
Architecture will financial reports be available for the entire project lifecycle. In the
meantime, the Department will continue to update and create project reports while
addressing project splits and combines and AB1012/SB45 reporting requirements.
“CTIFS” Current Systems Maintenance and Updates. The ideal implementation
sequence for the ERP modules requires that CTIFS functions be implemented after
General Accounting and Project Reporting functions are implemented. In the meantime,
enhancements and maintenance of existing systems will address some current systems
limitations and satisfy legislative requirements of SB45, TEA-21 and AB1012.
Right of Way Current Systems Maintenance and Updates. The ideal implementation
sequence for the ERP modules requires that CLMS functions be implemented as one of
the last projects. In the meantime, enhancements to existing systems could address some
current systems limitations
March 17, 2004 Page 38
Caltrans Integration Study Financial Systems Strategic Plan
The challenge facing each of these system owners is to address current business needs while
simultaneously considering the Conceptual Architecture and the Plan. The following brief
descriptions define the possible maintenance and upd ate activities to be performed within the
Department’s delegated authority, problems to be addressed, and considerations related to the
Conceptual Architecture and the Plan.
The relative importance of each of these projects has not been identified; only project ownership
and high- level project sequencing and durations have been reflected in the following diagram.
Exhibit 13 – System Maintenance and Updates
D e l i v e r y T i m e l i n e
FY 1 FY 2 FY 3 FY 4 FY 5
Sponsoring
Organization
Project Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Infrastructure
Enterprise Software,
Enterprise Active Data Warehousing,
Enterprise Application Integration
Procurement
General Accounting
Enterprise / General Ledger, Accts Payable, Accts
Receivable, Financial Reporting
Finance
Acctg. Systems Maint. & Updates
District / Project Reporting
Programs
Reporting & Maintenance
Construction CMS
Accounting /
Fixed Assets
DPAC
Budgets Budget Prep
Purchase Requisition,
DPAC
Procurement, Inventory
Programming, CTIFS
DPAC
Federal Resources, Purchase Requisition
Local Programming
Maintenance
Project
PRSM
Management
CLMS
Right of Way
Maintenance
L E G E N D
= Prepare FSR = FSR Approval = Project Startup = Rollout
= Update FSR = Procure = Design, Configure, Develop, and Test = Dependency
2.8.1 GENERAL ACCOUNTING SYSTEMS MAINTENANCE AND U PDATES
Even though the Plan proposes implementing general accounting functionality first, a few
existing systems require maintenance or updates before their replacement by IFMS. Current
examples include the accounting systems CAPS, EAS/COMS and ARS. These systems are
grouped and included in the Plan as an independent project, General Accounting Systems
Maintenance and Updates.
March 17, 2004 Page 39
Caltrans Integration Study Financial Systems Strategic Plan
2.8.1.1 Caltrans Account Payable System (CAPS)
The main function of CAPS is to automate document processing and transaction recording that is
required to process and pay a portion of the bills incurred by the Department. The system
enables users to convert paper documents to electronic images that can be matched, routed,
retrieved, and processed electronically by both the Department and State Controller’s Office
(SCO) users.
CAPS is currently limited by its older 16-bit imaging technology, FileNet imaging software that
is no longer supported, and manual indexing as a result of optical character recognition
technology not being part of the system. These shortcomings can be addressed by employing
new 32-bit imaging technology, replacing the FileNet software with software from a leading
imaging software vendor, and selecting a combination of software and hardware that will
electronically index scanned document images.
Tier 1 ERPs integrate with the most widely used scanners and imaging software. A key CAPS
requirement is for the chosen scanner and imaging software to integrate with Tier 1 ERP’s, so
the system selected to replace CAPS will continue to be used after IFMS is implemented.
2.8.1.2 Expenditure Authorization System/Capital Outlay Monitoring System (EAS/COMS)
Two processes performed in TRAMS were replaced in 1989 by a single system, EAS/COMS,
written in Queo V, a language no longer supported. The Department recently lost its sole Queo V
programmer, posing a significant risk to the Department. This risk has prompted the Department
to consider transferring/porting the existing system to the supported Oracle platform. No new
functionality is planned.
The EAS system currently provides an electronic EA processing system to expedite the
preparation, review and approval of Expenditure Authorizations (EA). The system also provides
online capabilities to input, query, modify, delete, certify, post transactions, and communicate
EAs from unit to unit.
COMS monitors and controls expenditures at the project, program, and appropriation levels to
ensure the Department’s expenditures do not exceed departmental allocations or legislative
budgeted amounts. The system provides online entry of encumbrance transactions and
automated certification of funds.
Functionality associated with EAS and COMS would be available when the ERP’s General
Ledger is implemented, prompting the retirement of these systems.
2.8.1.3 Accounts Receivable System (ARS)
The Accounts Receivable Systems (ARS) faces the same risks as EAS/COMS. It is written in a
language no longer supported, Queo V, and the Department currently has no programmers
familiar with this language. ARS processes the majority of the Department’s accounts
receivables and also handles receivables summaries processed in other automated systems, such
as RWPS, SLB, PARR, and CBARS. Any problem with this system jeopardizes the
Department’s primary billing and receivables system. The Department must consider the costs of
March 17, 2004 Page 40
Caltrans Integration Study Financial Systems Strategic Plan
supporting the current system until it is replaced during the General Accounting Project versus
more costly system updates.
2.8.2 PROJECT REPORTING AND MAINTENANCE
After the Conceptual Architecture has been fully implemented, the complete project lifecycle,
including project budget and expenditures, will be available for reporting. Financial reports will
be available when a project is first defined with a high level cost estimate, when a project is
―programmed‖ with budget amounts divided into SB45 categories, when a project contract is
awarded, during construction, and when a project is eventually completed. In order for the
Conceptual Architecture to produce the full range of reports, key tasks must be completed that
span several projects included in the Plan. In the meantime, the Department has project financial
reporting issues that need to be addressed prior to the full Conceptual Architecture being
implemented. While addressing the most pressing needs, the Department should simultaneously
consider future projects included in the Plan and project tasks that could be partially addressed in
advance. The following section provides an overview of project reporting issues and how they
will be addressed by each project of the Plan, as well as the impact on project reporting as a
result of maintenance and update activities.
2.8.2.1 Project Reporting Issues and Solutions
To produce project financial reports, a few key issues must be addressed in terms of data and
business processes. These issues include project splits and combines, project fund splits and
legislative requirements such as SB45 and AB1012. The Plan addresses these project financial
reporting issues incrementally. The following narrative describes how these issues are being
addressed at each stage of the Plan.
During the General Accounting Project, project splits and combines will be addressed
conceptually and the impact on the ERP’s G/L, A/P and A/R modules and the active Data
Warehouse will be identified. At this point, project reports will be available by project but the
intricacies related to project funding and project relationships would be unavailable.
While project data may be recorded in the ERP’s core financial modules, not until the Project
Accounting module is implemented will project relationships be recorded and tracked. At this
point, the Department must have clearly defined business processes detailing when, how and
who can split or combine a project. The Project Accounting Project will also support so me
legislative reporting requirements. For example, SB45 reporting categories could be defined as
part of the WBS. The Project Accounting module could support project centric reporting, instead
of requiring the SB45 components be part of the organization’s chart of accounts. Future
legislatively required reporting categories could be implemented in a similar way.
Only after completing the Budget Prep and the CTIFS projects, and implementing Budget Prep
and Funds/Grant Accounting modules, will project- funding reports be available. At this point the
full complexity of project splits and combines and project funding will be addressed. The Project
Accounting Project enabled the Department to track project splits and combines and the split by
SB45 component. The Funds/Grant functionality will allow the Department to further track the
March 17, 2004 Page 41
Caltrans Integration Study Financial Systems Strategic Plan
split by STIP, IIP or RIP funding, as well as by federal funding. This Fund/Grant Accounting
module will also generate AB1012 reports.
2.8.2.2 Impact of Maintenance and Update Activities on Project Reporting
Many of the current project reporting problems can be attributed to multiple systems, each
having its own type of project identifier and each being limited to a portion of the project
lifecycle. After implementing the Conceptual Architecture there will be a single integrated
system containing information for each project’s entire lifecycle. In the meantime, any
maintenance or updates to existing systems should support the Conceptual Architecture by
following a standardized data model.
The General Accounting Project contains the task ―map project identifier (UTPI), splits and
combines, WBS and Activities data model to the vendor data model.‖ This task requires
comparison and resolution of any discrepancies between the Department’s detailed data models
and the vendor’s data models. Completing this task will ensure the Department will be able to
generate the necessary operational, management and legislatively required reports. However, for
this task to be completed the Department must have a detailed data model. This detailed data
model could be constructed in advance and serve as a basis for any interim system maintenance
or updates. Several system owners are already following this recommendation.
The Division of Transportation Programming, statewide Local Assistance Program and Budget’s
Office of Federal Resources plan to address their most pressing business needs by generating a
detailed data model for their subject area and applying it to any system maintenance or updates.
One of their stated objectives is to more easily generate AB1012 reports. AB1012 requires that
federal apportionments be tracked by region and that regions be informed when funds must be
either obligated or lost (―use it or lose it‖). The Local Assistance Program currently provides
apportionment balances to local agencies via the web, but the reports must be generated from
two systems incapable of interacting, LP2000 and FADS. Maintenance of these systems
identified in Section 2.8.3, based on a shared data model, would result in the AB1012 reports
being generated more easily.
The Division of Project Management has addressed the problems related to project splits and
combines, reporting by SB45 component and project funding. The Division has defined and
enforces clearly stated business processes for splitting or combining projects and tracking project
funding by SB45 component. The Division is capable of reporting on project planned vs. actual
costs and durations for the six SB45 categories: project approval and environme ntal
documentation; project development support; right-of-way support; right-of-way capital;
construction support; and construction capital. These reports are available to headquarters and
District staff. Project reporting will be improved when PRSM is imp lemented. Project reports
will be more accurate by eliminating time charges to incorrect projects, and as stated in the
PRSM FSR, PRSM will ―allow Districts to provide the project status on a timely basis and
provide better progress estimates to local agencies on their STIP projects.‖
Currently SB45 reporting for local agency projects constructed by the local agencies themselves
is provided by the Local Assistance Program systems. However, SB45 reports for local agency
projects constructed by the Department using local agency funds are not readily available. These
reporting issues could be addressed jointly by the Division of Transportation Programming,
March 17, 2004 Page 42
Caltrans Integration Study Financial Systems Strategic Plan
Division of Local Assistance, Budget’s Office of Federal Resources and the Division of Project
Management. This joint effort could begin by expanding the CTIFS data modeling effort to
include the data needs of the Division of Project Management. The result would be a detailed
data model describing projects from conception, through programming, and finally, co nstruction.
2.8.3 “CTIFS” EXISTING SYSTEMS MAINTENANCE AND U PDATES
The Division of Transportation Programming, statewide Local Assistance Program and Budget’s
Office of Federal Resources must address their most pressing business problems by updating
their existing CTIPS, LP2000 and FADS systems while awaiting the eventual IFMS
implementation. Recognizing that any system maintenance or updates should consider the
eventual CTIFS implementation, CTIFS stakeholders have identified one activity to support both
maintenance and the eventual CTIFS implementation—development of a detailed data model.
Upon completion of the detailed data model, any system maintenance or updates will be based
upon a detailed integrated data model that logically describes all entities and re lationships and
supports integrated business processes and data for the Division of Transportation Programming,
statewide Local Assistance Program and Budget’s Office of Federal Resources. The CTIFS
representatives also plan to conduct periodic CTIFS meetings to ensure any existing system
maintenance or updates consider CTIFS requirements and adhere to the CTIFS strategic
direction.
Project work plans for the ―CTIFS” Current Systems Maintenance & Updates (composed of
CTIPS, FADS and LP2000) will be created by the systems owners and are beyond the scope of
this document. However maintenance and update activities for each of the systems to be replaced
by CTIFS are described below.
2.8.3.1 California Transportation Improvement Program System (CTIPS)
CTIPS was created and deployed in 2000 to electronically integrate the various State and Federal
transportation programming documents. Collectively, these documents contain over 10,000
planned transportation improvement projects worth billions of dollars funded with state and/or
federal funds. Additionally, much significant legislation such as SB 45, TEA-21, and AB 1012
have imposed substantial requirements on how transportation programs should be conducted in
California. Working collaboratively with representatives fro m State, Federal, and regional
agencies, a handful of in- house Transportation Programming staff was able to put CTIPS into
production within one year of starting work. A business decision was made then to develop
CTIPS on FoxPro platform initially in order to achieve the functional requirement of deploying a
prototype integrated programming system within a very short time frame and with only limited
available resources. It was also determined that the FoxPro platform would provide an upgrade
path to the eventual development of CTIPS on Oracle platform. The next phase in this
incremental improvement is to migrate CTIPS to an Oracle Platform in order to facilitate better
interface and data exchange with FADS and LP2000. In the absence of the integrated syste m,
Division of Transportation Programming users must manually gather project award data from
LP2000 and obligation data from FADS. Converting CTIPS to an Oracle platform would
facilitate data exchange with the Oracle based LP2000. As detailed below, FADS owners plan to
update their system to an Oracle platform, which would again facilitate data exchange with
CTIPS.
March 17, 2004 Page 43
Caltrans Integration Study Financial Systems Strategic Plan
When updating CTIPS to an Oracle platform, system owners wish to retain the current CTIPS
functions, input screen look and feel, and access fo r external customers. Functionality currently
lacking in CTIPS would be provided by the updated system and includes modules for RTIP, ITIP
and Minor programs, as well as a standardized FTIP data upload/download process for MPOs.
2.8.3.2 Federal Aid Data System (FADS)
The Federal Aid Data System (FADS) provides the Department with the ability to create,
approve, and electronically transmit requests for obligation of federal funds to the Federal
Highway Administration’s Fiscal Management Information System (FMIS). In October 2001
the Federal Highway Administration converted FMIS to an Oracle platform and updated the
name to FMIS 4.0. The Office of Federal Resources has since created a Federal Aid Data System
(FADS) Strategic Plan detailing how the Department might better integrate with this new system,
automate several manual processes, and provide project reporting to the Department and Local
Agencies.
Converting FADS to an Oracle platform could remedy several problems. Many tracking and
reporting capabilities have been lost due to the incompatibility between FADS and FMIS 4.0. A
large number of Department staff are proficient with Oracle Forms and Reports and could
generate forms and reports as needed. Lastly, FADS is limited to a 25- line by 80-column
character based display; all fields must be hand keyed; and no online editing is available. With
Oracle Forms, data entry would be through a standard GUI and drop down lists and field edits
would be available.
In addition to addressing these immediate problems, migration to an Oracle platform would
allow FADS to integrate with other Department Oracle based systems, including LP2000 and
LPAMS. If the current FoxPro based CTIPS were also migrated to an Oracle platform as
mentioned above, further integration would be available to FADS and would address a portion of
the original CTIFS requirements.
2.8.3.3 Local Programs 2000 (LP2000)
LP2000 is the main database system for the Local Assistance Program. It was converted from
SLIMS and implemented in October 1999 in preparation for Y2K and at that time was mainly a
project implementation tool. The majority of Local Assistance programming is still occurring
outside of LP2000 in various independent FileMaker Pro databases.
Since the implementation of LP2000, several new statutory reporting and tracking requirements
(including AB1012) have been placed on the Department to provide local agencies and RTPAs
with federal fund balances to assist them in using their federal fund apportionments in a timely
manner, to comply with ―use it or lose it.‖ The State budget crisis in the last couple of years has
resulted in a ―funds management‖ approach to Federal Obligation Authority for Local Assistance
projects. These changes add more pressure to improving LP2000’s tracking and reporting
capability. These improvements and upgrades were included in the scope of the proposed CTIFS
system.
March 17, 2004 Page 44
Caltrans Integration Study Financial Systems Strategic Plan
LP2000 currently consists of two modules, Project Programming and Project Implementation.
The Project Programming module supports only two of thirteen programs; the remaining eleven
are supported by FileMaker Pro databases. LP2000 would be enhanced to support the additional
eleven programs and the FileMaker Pro databases would be retired. Another LP2000
shortcoming is that project information must be entered into the Project Programming Module
and then be re-entered into the Project Initiation Module. In an updated LP2000, the two
modules would be integrated, make data available to both modules and provide project history
and version tracking.
Redundant data is also entered into two systems at different times, due to the lack of integration
between LP2000 and FADS. After FADS is migrated to an Oracle database, data could be easily
exchanged between the two systems. This integration would support electronic authorizing
document transmission and facilitate federal apportionment and obligation authority (OA)
balance reporting as required by AB1012.
Another problem is that some programmed amounts are captured in CTIPS and LP2000. This
issue would be addressed after CTIPS is migrated to an Oracle database and would allow data to
be easily exchanged between the two systems. Additional benefits would include more accurate
reporting and the ability to forecast workload based upon projects programmed in CTIPS.
2.8.4 R IGHT OF WAY EXISTING SYSTEMS MAINTENANCE AND UPDATES
The CLMS Feasibility Study Report identified numerous deficiencies with the current Right of
Way systems and concluded that a new system, replacing all six existing systems, would be
required to address current problems. However, immediate operational needs cannot wait three
or more years until CLMS is implemented. The Division of Right of Way therefore intends to
address the most pressing problems by migrating one of the mainframe-based systems, IRWS, to
an Oracle platform.
Existing systems exhibit a number of immediate deficiencies that have led to a variety of ―home
grown‖ databases and spreadsheets used by Right of Way Agents to manage their work. While
these systems have fulfilled some of the most pressing needs, they have also resulted in
redundant, parallel systems and inconsistencies from manager to manager, sometimes within the
same office. Ironically one of these systems has been successfully implemented and could serve
as a model for the Integrated Right of Way System (IRWS) replacement.
A system used in the Southern Right of Way Region and in District 10, the ―SOP report‖, utilizes
approximately three-dozen fields and provides reports currently unavailable in IRWS.
Consideration was given to simply implementing this system, but this was rejected due the
system being on a non standard platform and missing data elements. Instead of rolling the
existing FoxPro database out statewide, the Division of Right of Way proposes using the
program as model for a new Oracle database containing existing ―SOP report‖ fields and
additional financial fields. This new system would provide immediate benefits such as data from
the SOP report (in those districts already using it) could be rolled into the new database, the
proven format and output would be familiar to those already using the SOP report, and statewide
reports will be much easier to prepare, generally without the Districts needing to respond to
Headquarters requests for information.
March 17, 2004 Page 45
Caltrans Integration Study Financial Systems Strategic Plan
The Division of Right of Way proposes developing the system through a partnership between
existing Department IT and Right of Way personnel. The new system would replace most of the
functionality of the Integrated Right of Way System (IRWS), would have a web front end, and
would retain existing interfaces with RWPS, RWMIS and TPRC. Parcels created and tracked in
the new system would become the rental ―properties‖ in RWPS. Prior to any construction an
internal feasibility study report would be developed.
In addition to the immediate benefits, the enhanced system would prepare the Division of Right
of Way for the eventual ERP implementation by standardizing business processes and data
requirements. Plans to standardize and centralize training on the new system could also support
training users on the future ERP.
March 17, 2004 Page 46
Caltrans Integration Study Financial Systems Strategic Plan
3.0 ST RAT EGIES F OR S UCCESS
Implementation of the Conceptual Architecture will require consistent effort from the
Department and its employees over many years. This section of the Plan describes strategies for
successfully implementing the Conceptual Architecture and completing the Integrated Systems
Program. The strategies are:
Integrated Systems Program Governance Strategy
Organizational Change Management Strategy
Communication Strategy
Training Strategy
Program Management Strategy
Procurement Strategy
Risk Management Strategy
3.1 Integrated Systems Program Governance Strategy
The implementation of the Conceptual Architecture will require the participation of many
people. In order to effectively organize the people to successfully complete the program, the CIS
team recommends a governance structure similar to the organization chart presented on the next
page. This governance structure focuses on the needs of the program as a whole. The governance
structures of individual projects will be based on the needs of each project.
The program governance structure is not intended to replicate any existing Department
organization structure. Each role in the program governance structure acts as an agent of change
within the Department. The assignment of Department management and staff to fill the program
governance roles should be based on their ability to facilitate change, not based on their current
roles and responsibilities within the Department.
For instance, the governance chart in Exhibit 14, on the next page, includes a Steering
Committee. While the Department has a policy that all IT projects be overseen by the ITMC, the
ITMC is not the appropriate body to be the Steering Committee. The Steering Committee may
include some members who are also on the ITMC, but the Steering Committee will meet solely
to provide guidance to the implementation of the Conceptual Architecture and will not discuss
other Department IT projects or issues.
Similarly, the Department has an existing policy that all IT project managers come from the
PPMD project manager pool. However, it is very important that the Department Project
Managers assigned to each project in the program be business managers from the impacted
stakeholder business units rather than IT managers. The participation of IT is also important to
the success of the program, but the business manager should guide its participation.
March 17, 2004 Page 47
Caltrans Integration Study Financial Systems Strategic Plan
Exhibit 14 – Integrated System s Program Governance Structure
Program Sponsor
Steering Committee
Program Director
Program Management
Team
Project 1 Project 2 Project 3 Project N
Department Project Department Project Department Project Department Project
Manager Manager Manager Manager
System Integrator Project System Integrator Project System Integrator Project System Integrator Project
Manager Manager Manager Manager
Project Team Project Team Project Team Project Team
(Department & Integrator) (Department & Integrator) (Department & Integrator) (Department & Integrator)
Information Technology Services Team
Program Administration Team
Communication Management Team
Training Management Team
It will be very important to maintain a balance between the business aspects and technical
aspects of the program. The program is being implemented in order to provide business users
with a tool to meet business needs, so the participation of business/functional staff is imperative.
However, the tool chosen to meet the business needs is a technology tool, so the involvement of
technology staff is also important.
The Virginia Department of Transportation experienced a difficult ERP implementation.
Business staff, without the involvement of the IT Division, primarily ran the VDOT project. The
VDOT Project Manager stated that one of the lessons learned was the need for technology staff
to be full partners in the project. However, too much focus on technology can result in a system
that does not meet business users’ needs. It is very important that the Department successfully
balance the business and technology aspects of the Integrated Systems Program.
March 17, 2004 Page 48
Caltrans Integration Study Financial Systems Strategic Plan
The narrative below discusses the suggested roles and responsibilities for key project participants
throughout the program.
Program Sponsor—Directly communicates the Department’s long-term vision, and the
program’s place in achieving that vision. The Program Sponsor:
Is the ultimate owner of the program and has decision-making power in the
fulfillment of the primary responsibilities, as outlined for the Steering Committee
Members
Has the authority to make decisions and implement policies across Divisions and
Districts
Maintains the final authority to set priorities, approve scope, and settle
organization-wide issues
Promotes the program throughout the organization. Where conflict exists in the
completion of these responsibilities, the Program Sponsor is empowered to
negotiate and promote a solution.
Steering Committee—The participation and overall support of Department management
is required throughout the program. This will require a Steering Committee comprised of
Department management representing the key stakeholders of all projects. The Steering
Committee should consist of high- level stakeholders who can make decisions and
implement policies within Divisions and Districts. The Steering Committee will also
have a Chairperson who coordinates the activities of the Steering Committee.
As stated in the introduction to this section, the Steering Committee will not be the
ITMC, although members of the ITMC may sit on the Steering Committee. The Steering
Committee will provide guidance for the implementation of the Conceptual Architecture
and will not discuss other Department IT projects, policies or issues.
The role of the Steering Committee will include:
Providing program sponsorship—The Steering Committee will work with the
Sponsor, Program Director, Department Project Managers and System Integrators
to bring enterprise focus to the program, and resolve any issues that arise during the
projects.
Defining policy and guidelines—The implementation of systems with the breadth of
the Conceptual Architecture will require many policy decisions. The Steering
Committee will work to develop consensus and resolve policy, cross- functional
scope and directional issues in a timely manner in order to ensure that the project
schedule is not adversely affected.
Ensuring availability of resources—The Steering Committee will ensure that the
required personnel are available to the project for necessary tasks in adequate
timeframes.
Ensuring long-term business requirements are met—The Steering Committee will
ensure that the implementation of the overall program meets the Department’s
business requirements.
March 17, 2004 Page 49
Caltrans Integration Study Financial Systems Strategic Plan
Approving Go/No-Go decisions—The Steering Committee will decide if a
particular project should proceed as planned based on information provided by the
Program Management Team, Program Director and Project Managers.
Approving project plan variances—The Steering Committee will approve project
variances in a timely and complete manner. The Steering Committee will also
approve any variance mitigation plans created by the Project Managers, Program
Management Team, and Program Director.
Approving deliverables—The Steering Committee will approve project deliverables
in a timely and complete manner.
Department Program Director—The Department will require a full time Program
Director to oversee all projects throughout the duration of the program. The Program
Director and the Program Management Team will maintain consistency across the
projects. The Program Director should be someone with experience implementing
enterprise-wide systems. Due to the recommended implementation strategy, there may
be a different system integrator for each project; the Program Director will be
responsible for ensuring the System Integrator Project Managers work together. The
Program Director will forward deliverables to the Steering Committee for approval.
Program Management Team—The Program Management Team (PMT) includes the
Program Director and the individual Department Project Managers for each project. The
PMT will be responsible for coordinating management activities across all projects, as
well as the project support teams (IT Services, Communication, Training, and
Administration). While each project has its own project administration needs, the PMT
will maintain consistency across all projects. Responsibilities of the PMT should
specifically include:
Gathering information necessary for go/no-go decisions and providing that
information to the Steering Committee
Reviewing project deliverables in a timely and complete manner
Assisting in business process re-engineering
Assisting in change management
Identifying, prioritizing and tracking program, organization, and system risks
Development of data, process, and integration standards
Department Project Managers—Department Project Managers should be business
managers selected from the impacted business units. Responsibilities of the Department
Project Managers should specifically include:
Overall accountability for creation, maintenance and execution of the project plan,
project charter and project organization
Setting and changing overall project scope and focus, in consultation with the
Program Director, Steering Committee and Program Sponsor
Working with the System Integrator Project Managers to manage the project
Manage Department Project Teams
March 17, 2004 Page 50
Caltrans Integration Study Financial Systems Strategic Plan
Maintaining project budget
Publishing project status
Identifying and establishing resource requirements for each project
Successful completion of activities throughout the project—tracking plan vs. actual
Ensuring that all participants (internal and external) perform their roles
Determining project variances and developing variance mitigation plans for
presentation to the PMT and Steering Committee
Escalating project- and policy-related issues to the Program Director, Steering
Committee and Program Sponsor
System Integrator Project Manager(s)—The System Integrator Project Manager will
provide system function and technical leadership and services throughout the
implementation of each project of the program. The System Integrator Project Manager
will be primarily responsible for leading a team of contract resources to complete the
design, development and construction of the project.
Project Team(s)—The project team will be composed of both Department staff as well as
contractor staff.
Department Team Members—The project will require a core project team including
functional and technical experts from Department staff to support the completion of
the project. All team members must possess the appropriate functional and
technical skills required to complete the assigned tasks. The number of team
members and their time commitments will vary throughout the project. The
following functions may be needed:
Functional team leader for each major function
Functional specialists to participate in functional workshops, analysis activities,
business process redesign activities, data conversion and user testing
Programming support to assist in the completion of conversion/interface
programming
Programming support for the completion of expanded reporting
System, network, and database administration support
System Integrator Team Members—Each system integrator will provide a System
Integrator Project Team, under the leadership of the System Integrator Project
Manager. The System Integrator Project Team will be responsible for design and
implementation of the project. Team members will provide all functional and
technical knowledge required to work with the products, platforms and
development tools utilized throughout the project as well as provide training in
accordance with the training plan developed by the Training Management Team.
March 17, 2004 Page 51
Caltrans Integration Study Financial Systems Strategic Plan
Information Technology Services Team—Each project will require IT services. The IT
Services Team reports directly to the PMT and provides IT services across all projects in
the program. IT services includes such functions as:
Hardware and operating system support
System software (ERP, EAI, DW) support
Database administration
Security administration
Network administration
Application engineering/development/customization
Help desk support
Program Administration Team—The Program Administration Team reports directly to
the PMT and consists of the administrative staff necessary to support the PMT and the
Project Director.
Communication Management Team—The Communication Management Team reports
directly to the PMT and performs the communication function throughout all projects in
the program. Communication management is discussed in more detail in the
communication strategy below. The responsibilities of the Communication Management
Team include:
Creating and publishing project’s communication strategy and plan
Coordinating communication events, both internal and external to the project teams
Serving as an active communication advisor to the team leads
Maintaining project website
Training Management Team—The Training Management Team reports directly to the
PMT and coordinates training throughout all projects in the program. Training is
discussed in more detail in the training strategy below. The responsibilities of the
Training Management Team include:
Creating and publishing project’s training strategy and plan (tasks and resources)
Coordinating all training events, both internal and external
Evaluating, identifying, facilitating, proposing and managing use of selected
method of training (vendor classes, computer-based training, on-site training
classes, etc)
Serving as an active training advisor to the team leads
In the event of consolidation of Department network, hardware and operating system support
into the Teale Data Center, the data center would be included in project decisions involving
technical infrastructure. The data center will not have a formal role in the program governance
structure. The Department should negotiate with the data center as a customer negotiates with its
service provider, escalating issues through the existing organizational structure as needed.
March 17, 2004 Page 52
Caltrans Integration Study Financial Systems Strategic Plan
3.2 Organizational Change Management Strategy
Most organizations value their old ways, have entrenched knowledge and skills, established
policies and procedures, and traditional power bases of authority. The fact that the
implementation of the Conceptual Architecture will affect and replace legacy systems built and
customized by Department personnel over the years will make this change personal. A brilliantly
planned technical solution will not succeed if the right amount of organizational buy-in and
preparation are not present.
Change management is a critical component of any successful project, and is especially so for an
enterprise IT project. The implementation of the Conceptual Architecture will affect every
organizational unit in the Department in some way, and impac t every staff level in the
Department differently. The change management process is critical to successfully transitioning
Department employees to ready and willing users of new business systems and must take into
account the different perspectives within the Department. Change management enables the
executive leadership and other stakeholders within the Department to proactively assess and
prepare the organization for the changes in technology and job responsibilities that will impact
all levels of staff.
The most important part of change management is getting all of the stakeholders involved as
soon as possible—long before project implementation begins. The CIS project has begun this
process with the development of the Integration Work Group, consisting o f interested
stakeholders from across the Divisions and Districts. The Work Group has participated in the
CIS project since it started, and has provided support and comments in guiding the direction of
the project.
Now that the CIS project is coming to an end, the momentum that has been gained should
continue. The Program Steering Committee should be constituted to ensure that stakeholders
have representation throughout the program. The members of the Integration Work Group who
were project managers for their proposed systems should continue to meet as the new Program
Management Team. The Department must take change seriously by committing time, money,
and resources to the change process. The only way to ensure the successful implementation of an
enterprise solution is by the full participation of the enterprise.
In order to manage change in an orderly fashion, the PMT should develop and implement a
Change Management Plan. The plan should include the following activities:
Define Stakeholders—Identify the people who can affect the success of the program and
their stance, position or concern with the program. Stakeholders should be identified
broadly in an attempt to catalog all those impacted by the program. The criteria for those
to be included in the assessment should be based on a variety of criteria, such as:
Project Team management
Division and District management including impacted management staff
March 17, 2004 Page 53
Caltrans Integration Study Financial Systems Strategic Plan
A limited sample of staff users, including users expressing both positive and
negative views of the program
A selection of information technology staff involved with the program, including
data center staff
The intention is to include individuals who represent those who will be most impacted by
the program, as well as those who have differing perspectives o f the program.
Organizational Assessment—Identify the issues for which stakeholders express concern
and that may affect the program’s success. Issues can be identified using various
structured tools: interviews, focus groups, surveys, comment boxes, etc. The
stakeholders’ issues, concerns and potential reactions are then consolidated. The
assessment may also include previous history of change efforts or other issues that
should be taken into consideration during the implementation. The Define Stakeholders
and Organizational Assessment tasks should be updated periodically over the life of the
program.
Identify and Manage Critical Implementation Issues—The results of the Organizational
Assessment is used to identify the critical implementation issues for the program. These
are the issues that could compromise the success of the implementation if not mitigated.
The Program Sponsor and Steering Committee should be made aware of these issues and
participate in the prioritization of the issues. The PMT should the n develop mitigation
strategies based on the prioritized list. As the mitigation strategies are implemented, the
PMT should review and assess the effectiveness of the mitigation activities in resolving
the critical implementation issues. Critical implementation issues should be revised
periodically over the life of the project.
Develop Leadership Action Strategy—Once Critical Implementation issues are
developed, it will be necessary to foster agreement among program leadership and
primary stakeholders (such as Division and District managers) on how to address them.
The Leadership Action Strategy is a plan that assists leaders in preparing their areas for
deployment. These leaders must agree on direction and key messages. In the case of a
deadlock, they must agree on constraints to the collaborative process and a strong
fallback position.
The purpose of this task is to develop or refine the leadership strategy and provide
program leaders with decision- making, problem solving and employee involvement
strategies. This task provides the link between the critical implementation issues and
techniques for finding solutions to them. Program leaders, including the Program
Sponsor and Steering Committee members, should be involved in the development of
action plans and identify intervention methods for both groups and individuals.
Develop Communications Plan—Visible, consistent and periodic demonstrations of
support for the project will increase the probability of a successful implementation. This
strategy includes linking stakeholders, critical implementation issues, and key messages
with the appropriate leader or staff person and identifying the appropriate method for
disseminating the information. The Communication Strategy is described in more detail
in Section 3.3, below.
March 17, 2004 Page 54
Caltrans Integration Study Financial Systems Strategic Plan
Perform Workforce Transition Assessment—Early in the life of each project, an initial
assessment of the implementation impact for that project should be performed, focusing
on the skills required to operate the new system by both business users and technology
support staff. The objective of the Workforce Transition Assessment is to perform an
analysis of the organizations and jobs affected by the ERP implementation. The
assessment compares the current organizational structure to the future organizational
structure, identifies positions that are affected by the change, and highlights the critical
changes between the old and new jobs.
The assessment will require working both with staff who understand the existing
positions and the project team members that are designing the new processes and
technology environments. This work is intended to identify the training required by each
impacted position. The assessment should group positions and categorize skills into areas
such as: business knowledge, technology and tools, soft skills (management/analysis)
and application-related skills.
March 17, 2004 Page 55
Caltrans Integration Study Financial Systems Strategic Plan
3.3 Communication Strategy
Communication needs to be timed and orchestrated and must be continuous across all projects.
To that end, the Department will need to develop a communication plan for the program and its
associated projects. This plan should identify the message to be communicated, the appropriate
messenger, and match the messenger up with the right audience and communication vehicle. The
following table illustrates the typical relationship between messenger, audience and vehicle.
Exhibit 15 – Communication Relationships
Messenger Audience Communication Vehicle Setting
Program Sponsor Organization leaders, Presentations, Brochures, Policy luncheons
Program Management Sponsor Cue Card
Team, and Project Teams
Steering Committee Targeted Organization Presentations and hands - Face-to-face and program
Leaders, Office Directors, on sponsorship (face-to- status meetings
and Program Management face)
Team
Program Management Staff, project teams, and Presentations, Team meetings
Team press demonstrations, website,
newsletters, and press
releases
Project Teams Users Presentations, Team and individual
demonstrations, website, meetings
newsletters, bulletins, e-
mail, videos
The North Carolina Department of Transportation recognized the importance of communication
when they implemented their ERP. According to the project manager, NCDOT started the
communication process early, before people really cared about the future system. In addition to
hosting a project website and sending newsletters, the team started taking road shows to the
various districts to describe the project. The road shows included meetings with engineers
describing job roles and responsibilities as well as screen shots of what the future system would
look like.
The communication plan developed for the California Department of Motor Vehicle’s ERP
implementation included the following information:
Target Audience—The target audience of the communication plan is the program
stakeholders, with a focus on those most directly impacted by each project; although an
additional audience is the groups within the Department that are indirectly affected by
the program.
Desired Outcomes—The desired outcomes are what the communication team is
communicating for. Each message should pull stakeholders closer to the desired
outcomes.
Effectiveness Assessment—The effectiveness of the communication management effort
should be evaluated. Effectiveness may be measured through surveys or questionnaires
administered to stakeholders occasionally during the project.
March 17, 2004 Page 56
Caltrans Integration Study Financial Systems Strategic Plan
Roles and Responsibilities—The communication plan defines the roles and
responsibilities of each party involved in executing the plan.
Tools—The communication plan identifies several different tools available for
presenting information and the way those tools should be used. For example:
Facilitated meetings to focus on specific problem resolution, as needed
Periodic meetings led by key project staff to present information
Focus groups used to gather feedback or opinions from stakeholders
Formal presentations at key points in the project to announce a new phase or release
general information
Informal presentations (brown bag, show & tell) to educate or inform on specific
aspects of the project, to inform users and keep momentum
Broadcast email to distribute information broadly and quickly, to be used sparingly,
in scenarios where immediate attention is required
Newsletter with articles that address employee concerns, such as project goals,
significant milestones, upcoming activities, project contacts, and frequently asked
questions
Web site as a repository of information about the project
Communication matrix that identifies key messages, the target audience, and the
messenger to address the issues. The matrix should be updated regularly to reflect
current issues and in response to the project status.
3.4 Training Strategy
While training investments typically amount to a small percentage of total project costs, well-
trained employees are necessary for a successful system rollout. A bad training plan is a waste of
valuable time and resources, whereas a good training plan will improve job performance and
provide the employee a measure of confidence using the new system.
Training is important not only to provide end users with the information they need to use the new
system, but also to enable knowledge transfer from the system integrator to Department staff.
Eventually, the system integrator will complete its roll on the project; the Department will be
dependant upon the information imparted to its users and support staff for continued successful
use of the system.
The training delivered to the Department is developed specifically for the targeted audience. The
classic training audiences are:
Management—The primary goal of management training is to raise the awareness of and
gain top- level support for the system. A major area of focus for implementation
planning is to obtain management commitment, a key factor to achieving success in a
new system. Because of the demands imposed on management time, overview- level
training, which focuses on the integration of previously independent activities, is
March 17, 2004 Page 57
Caltrans Integration Study Financial Systems Strategic Plan
appropriate for managers. This allows management to understand the impact of the new
system and use this knowledge for planning and control.
Direct Users—The purpose of the training process for the user group is to make the
participants effective and efficient users of the system and to reduce resistance to change.
An alternative to conducting sessions for each organizational unit is to present training
along functional lines based on the modules. Therefore, personnel with common
interests will be trained together.
Indirect Users—Indirect users are an important part of the implementation process, since
a large portion of this group functions as backup for the direct users or are outsiders
obtaining information. Indirect users should be invited to participate in the general
primary training.
Technical Training—These sessions focus on training the technical personnel who will
have responsibility for maintenance and operation of the new system. Applications
training will be provided during the initial training program. Site technical personnel
should then apply what they learned by supporting the maintenance and operation of the
system through the requirements confirmation and acceptance testing activities.
There are many training approaches available. The Department will likely choose some training
approaches over others. The table on the following page, Exhibit 16, describes the advantages
and disadvantages of some training approaches.
March 17, 2004 Page 58
Caltrans Integration Study Financial Systems Strategic Plan
Exhibit 16 – Training Approach Advantage s and Di sadvantages
Training Approach Advantages Disadvantages
Training Method
Computer-Based Has longer shelf life Higher initial development cost
Training Enables Self Direct/Self Paced Requires technical intervention for
(CBT, Web-Enabled) Training updating
More cost effective o ver time
Enhances “Ease of use, promotes
use” approach, allows user to select
training times that fit their schedule
Allows for larger curriculum, wider
range of topics available to students.
Traditional Has higher immediate retention rate Requires extensive scheduling
Classroom for material covered and logistics
Approach Allows for ease of update or Has added cost of building and
“changing on the fly” maintaining (or renting)
classrooms
Training Materials
Standard Less cost Content (clients, costs, processes,
Vendor-Supplied No (or little) development required etc.) not recognized by student
Training Materials Available “off the shelf” Cannot show relationship to any
Is complete, tested and approved as legacy or bolt-on systems
functionally representative of the
version in use
Custom Training Promotes learning through student More costly
Materials recognition of content Must be maintained in a library
Has uses beyond training in the environment
creation or documentation of
standards for certification
Uniquely documents client’s
processes, including bolt-ons and
legacy systems
Trainers
Vendor-Supplied Puts experienced, trained Higher cost
Trainers professionals in front of users Investment has no residual value;
Allows for greater flexibility in the when vendor supplied trainers
range of material for presentation complete classes they leave the
Can be freely substituted across a Department
wide variety of instructional modules
Most vendor-supplied trainers are
knowledgeable in several areas
Are a vailable for “Go Live” on site
support to assist former students
through first days of system use
Train-the-Trainer Remains with the Department after Trainer “in training” must be freed
(Department initial implementation for new hire, from most usual job
employees are trained new version and remedial training responsibilities
to be Trainers) needs A high percentage of Trainers,
Promotes a “one team” approach and once trained, take new skills into
attitude to project and on-going highly competitive job market
operation. Sometimes requires union
oversight to insure adherence to
contract
March 17, 2004 Page 59
Caltrans Integration Study Financial Systems Strategic Plan
Training Approach Advantages Disadvantages
Training Location
Vendor-Supplied Designed, built and configured for More costly
Facilities training purposes Adds element of travel expense to
Off-site locations support and cost
promote the learning experience
Department-Supplied Less cost after initial investment Limited training facilities available
Training Location for future training or other Time and cost to build facilities
Facilities gatherings Use, beyond initial
On-site training location promotes implementation, is limited
more ad hoc or as necessary training
Without the right training at the right time, users will be unable to properly use the system,
fueling frustration and user errors, and negatively affecting success. For the Idaho Transportation
Department’s ERP implementation, the training provided to users occurred too early in the
project. As a result, ITD stated that when the system went live, people had forgotten what they
had learned and had difficulty using the new system.
In addition to formal training, the Trainers may be available during rollout to help answer user
questions during the first days or weeks of use. As an example, the NCDOT hired 67
experienced ERP users to handhold its users for two months after go- live.
3.5 Program Management Strategy
The Department has implemented many information technology projects over the years, many of
them of significant size, cost, and visibility. IT Project Managers have historically used a variety
of project management methodologies to manage their projects. Recently, the Department
formalized its project management methodology in the Information Technology Project
Management Methodology (ITPMM), which it plans to roll out to the Department at large. This
section of the report does not intend to reiterate the project management methodology adopted by
the Department; instead, it will focus on the unique aspects of managing the overall program.
Effective Decision-Making—Since the program consists of multiple projects, decision-
making needs to be coordinated between projects. Decisions made by one project may
have unintended consequences for other projects. The PMT will need to ensure that all
project managers coordinate their decisions where appropriate.
Enterprise Solution—Implementing the Conceptual Architecture will result in an
enterprise solution, which entails an enterprise impact. Whereas many of the
Department’s previous IT projects have impacted only one Division or District, the
Integrated Systems Program will impact the entire Department. Therefore it is critical
that the Program Director engage the PMT, including all project managers, over the
course of all projects.
Consistency Across Projects—Since the program will be implemented through a series
of projects over many years, consistency within the program will be important.
Consistency will be maintained by the continuing involvement of the Program Sponsor,
Steering Committee, Program Director and PMT. These program participants will gain
March 17, 2004 Page 60
Caltrans Integration Study Financial Systems Strategic Plan
and retain knowledge of the program as it progresses. The polic ies and procedures
instituted by the PMT will also be maintained across projects.
Documentation of the project will also be important. Future projects will be dependent
upon the information documented in the earlier projects. Since project staff will change
from project to project, effective documentation is critical.
Project Dependencies—All of the projects in the program are interdependent. The
Program Director and PMT will need to keep track of these dependencies across
projects, as individual project managers may not have the high- level view of the entire
program. The PMT should create and own the master integrated project schedules.
Planning for Future Projects—While individual project managers will be focused on the
needs of their individual projects, the Program Director and the Program Management
Team will need to focus on the needs of all projects and plan accordingly. For example,
all projects will require the development of a chart of accounts in the General
Accounting project. The PMT will need to ensure that the chart of accounts meets the
needs of all projects that follow.
3.6 Procurement Strategy
The Department’s procurement strategy for implementing the Conceptual Architecture must take
into account control agency approval and available funding over the life of the program. Given
the current budgetary environment, the Plan recommends dividing the ERP implementation into
multiple projects. This implementation strategy requires a corresponding procurement strategy,
which is described below.
The Department first must get buy- in from the Department of Finance and Department of
General Services that this unique implementation, consisting of all projects in the program, is
sound in concept. The program has been divided into multiple projects specifically to facilitate
control agency agreement. These smaller projects provide the control agencies with the ability to
approve smaller funding amounts, as funding becomes available over the life of the program.
3.6.1 C ONTROL AGENCY AGREEMENT
The need for control agency agreement on the Conceptual Architecture program concept stems
from the fact that the best solution for the enterprise may not be the best solution for any
particular business function. For example, any business function, if broken down small enough,
can be managed with paper and pencil; however, taken in aggregate, it is clearly better to manage
the Department’s financial information using technology than pencil and paper. Agreement from
control agencies on the program concept provides the Department with assurance that the
benefits that can be achieved by an integrated enterprise system will be worth the pain of
postponing the implementation of stovepipe systems (as defined in the original four feasibility
studies). If the control agencies do not agree to the program concept, Divisions and Districts with
needs that could otherwise be met by the implementation of the Conceptual Architecture will
surely investigate and promote other non- integrated solutions.
March 17, 2004 Page 61
Caltrans Integration Study Financial Systems Strategic Plan
Agreement from the control agencies on the program concept does not automatically approve the
individual projects in the program. Each project, with the exception of the software procurement
project, must be able to stand on its own, with benefits to the Department that justify its costs. To
this end, each project will still be required to complete a feasibility study that must be approved
by DOF.
3.6.2 PROCURE SOFTWARE AND HARDWARE FIRST
Usually, RFP’s are issued that request software, hardware and integration services. However, this
procurement strategy recommends separating the software and hardware procurement from the
integration services procurement.
This procurement strategy requires that the functional requirements for all other projects in the
program be combined for the software and hardware procure ment project. To facilitate this, all
projects must develop their FSRs at the same time, as shown in the project timeline in Figure 2.0.
The functional requirements identified in each project’s FSRs will be incorporated into the FSR
for the software procurement project. Integration requirements for systems outside the ERP
should also be incorporated into the master functional requirements list.
A Request for Proposal for a software suite will then be issued based on the combined functional
requirements of the program. The Department would then select a software suite based on its
ability to most closely meet the functional requirements without customization. The selection
process would also include vendor discussions and product demonstrations.
This procurement strategy is not unique—it is the same strategy currently being followed by the
State Controller’s Office (SCO) in its procurement and implementation of a human
resources/payroll system. The SCO has received agreement from DOF on the strategy, although
funding has not been approved. The Bay Area Rapid Transit District (BART) is also following
this strategy. BART has already procured software that meets its financial, human resources,
payroll, and logistics needs. BART is currently procuring the integration services necessary to
implement the already purchased software.
One of the points of negotiation with the software vendor should be the incorporation of
Department-specific customizations into the base software product. The Department’s needs
would then be met in all future upgrades of the product. The software vendor may be more
willing to do this if the customization will be needed by other transportation/government
organizations.
3.6.3 PROCURE IMPLEMENTATION SERVICES
After selecting the software suite, the Department would then procure integration services for
each project separately. Each project would update its FSR based on the software package
selected. Any projects whose functional requirements are not met by the selected software
package may proceed in the development of a FSR for a different technology solution.
As each project receives control agency approval, the Department would issue a RFP for the
integration services for that project. The Department should include Business Process
March 17, 2004 Page 62
Caltrans Integration Study Financial Systems Strategic Plan
Reengineering (BPR) services in its system integration contract to facilitate changing business
processes and minimize customization of the software. The Department would evaluate the
system integrators’ expertise with the software, prior implementation efforts, and ability to meet
the Department’s requirements.
3.6.4 ADVANTAGES & DISADVANTAGES
This procurement strategy has the following advantages:
Funding requirements are spread over time, without committing the Department to fully
funding the entire program
Each project, with the exception of the initial software procurement, must stand on its
own and justify its business case
Provides DOF the opportunity to approve the costs on a project-by-project basis, without
the disruption caused by phase-by-phase project approvals
Software vendors will be forced to compete directly against each other, rather than as
part of a larger contract
System integration vendors will be forced to compete directly against each other, rather
than aligning themselves with a software vendor
Lessens risks associated with larger, single procurements for the software and system
integrator
Identifying the software that best meets the state’s requirements allows significant cost
containment since the number of modifications made to the software will be minimized
Provides opportunities for ―Go / No Go‖ decisions. For example, if the selected software
does not meet the needs of a stakeholder, that information can be incorporated into the
feasibility study for a subsequent project and an alternative solution selected
Software procured can be paid for on a per-seat or per- module basis, depending upon
negotiations with the vendor. Payments can be tied directly to projects’ scopes and
schedules. This will space out the funding requirements over time, as the Department
will not need to pay for functionality or seats until they are needed
Hardware procured can be paid for as hardware is actually delivered and put into service.
Payments can be tied directly to projects’ scopes and schedules. This will space out the
funding requirements over time, as the Department will not need to pay for hardware
until it is used
Licensing cost of the selected enterprise software (to be used for all projects in the
program) is likely to be less expensive than if software was procured on a project-by-
project or function-by- function basis
March 17, 2004 Page 63
Caltrans Integration Study Financial Systems Strategic Plan
In addition to the advantages, there are some disadvantages associated with this procurement
strategy:
Some dependencies between projects require that earlier projects be implemented. If the
earlier projects do not receive approval, subsequent projects may be cancelled or search
for an alternate solution
Additional procurement overhead will be required at both the Department and DGS to
manage multiple procurements
Additional project management overhead will be required to manage multiple
interrelated projects
Projects that cannot justify their business case cannot ride the coattails of other projects
DOF may consider this procurement strategy to be splitting up a single project into
smaller sub-projects in order to avoid fiscal or procedural controls and reporting
requirements, contrary to SAM Sections 6730 and 4819.34. However, the separate
projects within the program merely represent the fact that resources are severely
constrained and that required functionality must be implemented as funding becomes
available. As each individual project is completed, the system will continue to function
even if subsequent projects are delayed or cancelled.
3.7 Risk Management Strategy
Every technology project carries some element of risk—it is common that progress deviates from
the plan at some point in the project lifecycle. There are many types of risk that might affect a
particular project, including: organization-related risks, technological risks, risks due to the size
and complexity of the project, risks in personnel acquisition and retention, and risks in achieving
user acceptance of the system. In order to facilitate the successful completion of the program, the
PMT will need to implement a strategy for mitigating the risks that may impact the project.
The following table lists the risks that have already been identified and the mitigating factors that
were incorporated into this Plan:
Exhibit 17 – Ri sk Mitigation Factors
Risk Mitigating Factor
Risk of not receiving funding Mitigated by the way the program is broken into
projects
Risk of loss of momentum Mitigated by the use of the same governance
structure overseeing all projects
Risk of inter-project incompatibility Mitigated by the Program Director and PMT
structure
Risk of not having all interested stakeholders Mitigated by the Project Manager for each
involved project coming from the impacted Division
Resistance of stakeholders and users Mitigated by the Communication Plan
March 17, 2004 Page 64
Caltrans Integration Study Financial Systems Strategic Plan
The Program Director and Program Management Team will need to develop a risk management
plan in order to mitigate the likelihood and impact of risks occurring on the program. The risk
management plan should provide guidance for managing both program risks, which would be
managed by the PMT, and project risks, which would be managed by the project managers. An
effective risk management plan consists of the following activities:
Identifying and prioritizing risks
Reducing the likelihood and impact of risks
Monitoring identified risks
3.7.1 IDENTIFYING AND PRIORITIZING RISKS
Identification of risks should be a priority for the PMT. All personnel involved with the program
should be encouraged to identify any risks they feel put the program at risk. Risk identification
should be an agenda item at team meetings, and team members should be reminded of the
importance of early recognition of risks. Risks may come to light informally in hallway
conversations, as well as through e- mails, or even a suggestion box.
The PMT needs to document the identified risks in a single location. If the PMT develops a
program website as part of its Communication Plan, the website is an excellent location for a risk
management website. As personnel identify risks, they can enter them into the website risk
database. The PMT can then use the same website to prioritize and manage the mitigation of the
risks. If the PMT does not use a web-based risk management database, a simple spreadsheet or
table can be used.
After the risks have been identified, the risks must be prioritized in order to determine which
risks receive the benefit of scarce program resources. The PMT should choose a standard method
for prioritizing risk, which can be extremely subjective. One method for objectively prioritizing
risk is to calculate priority based on the probability the risk would occur (1 to 100 percent) and
the impact the risk would have if it occurred (on a scale of 1 to 5). The total score achieved by
multiplying these two numbers can be used to prioritize the risk, with the highest scores
prioritized first and receiving the greatest resources to mitigate them.
3.7.2 R EDUCING THE LIKELIHOOD AND IMPACTS OF RISKS
Once the risks are prioritized, the PMT can take steps to mitigate the risks. Each risk should be
assigned to a specific individual to take action. Two types of action can be taken: preventive
actions and contingency actions.
Preventive action involves modifying the project environment to minimize the identified risk.
When potential risk situations are identified, alternative courses of action should be evaluated to
determine if the undesirable outcome could be avoided at a reasonable cost. The relative cost of
the preventive actions should be determined and incorporated into the risk prevention plan. The
Program Director should present the risk prevention plan to the Steering Committee for approval
if the costs and/or impacts are significant.
March 17, 2004 Page 65
Caltrans Integration Study Financial Systems Strategic Plan
Contingency actions provide a buffer to address an unanticipated event. A contingency plan will
be developed for contingency actions that address significant risk areas where preventive action
is either unavailable or the cost of prevention is prohibitive. The Program Director must ensure
that the contingency plan is realistic. The cost required to implement the identified actions
should then be estimated.
3.7.3 MONITORING IDENTIFIED R ISKS
Once actions have been taken to mitigate the risks, the risks need to be monitored to verify that
the actions have had the desired effect. The PMT should review risks regularly during the system
implementation period. The Department should also require regular status updates from its
system integration vendors, including risk factors, options, and related mitigation plans. The
PMT should also regularly report to the Steering Committee on risk factors, along with options
and related implementation plans to minimize each risk factor.
March 17, 2004 Page 66
Caltrans Integration Study Financial Systems Strategic Plan
4.0 NEXT ST EPS
The CIS project has developed a great deal of momentum over the past year; this momentum
should not be lost. Within the next few months the Department should undertake the following
steps on the path to implementing the Conceptual Architecture:
Assign leadership roles in governance structure—The leadership of the program should
be identified as soon as possible. These positions include:
The Program Sponsor should be someone within the Department that has the
authority to make decisions and implement policies across Divisions and Districts
and can successfully negotiate data center services.
The Steering Committee should consist of high- level stakeholders who can make
decisions and implement policies within Divisions and Districts.
The Steering Committee Chairperson should be someone who has the ability to
provide leadership to the Steering Committee.
The Program Director should be someone with experience implementing enterprise-
wide systems.
Assign Department Project Managers for all projects—The project managers should be
people with knowledge of the business areas that will be impacted by the projects to
which they are assigned. Project managers should be assigned as soon as possible, since
the implementation schedule assumes that Feasibility Study Reports for each of the
projects must begin by the start of the fiscal year.
Start development of the Feasibility Study Reports—The procurement strategy requires
that the software requirements for each project be incorporated into the Infrastructure
Project FSR’s software requirements. Therefore, the assigned project managers must
begin development of all FSRs in order not to delay the first project.
Begin implementing procurement strategy—The first step in the procurement strategy is
gaining agreement from control agencies on the program outlined in Section 2. The
Department may also begin strategizing how and when to pay for hardware, software,
and implementation services.
Begin change management activities—The first step in change management is the
development of the change management plan. As described in the Change Management
Strategy above, the plan outlines the tasks involved in identifying change issues and their
mitigation strategies. Once developed, the Department should begin executing the
Change Management Plan. There are change management activities applicable to each
stage of project implementation, including the FSR development stage.
March 17, 2004 Page 67
Caltrans Integration Study Financial Systems Strategic Plan
5.0 APPENDICES
These appendices include additional information that expands upon the information presented
above. These appendices are:
Appendix A: Time-Frame Modeling Approach
Appendix B: Implementation Task Plan
March 17, 2004 Page 68
Caltrans Integration Study Financial Systems Strategic Plan
Appendix A: Time-Frame Modeling Approach
To identify the duration of each project, the team used the following ―Time-Frame Modeling
Approach‖:
Defined and standardized the major Work Breakdown Structure (WBS) at the highest
level for all projects.
Estimated the range of durations for each major WBS activities for a Small, Medium,
and Large size projects. (Table A)
Ranked each identified project using ―Large‖, ―Medium‖, and ―Small‖. Project ranking
is related to each project’s complexity, number of users, required configuration activities,
and estimated level of customization. (Table B).
Using information from Tables A and B, on the following page, the Team assigned
duration to each of the project’s WBS. The Team adjusted the duration for each project
based on specific WBS requirements. For example, while the Implementation of
Procurement Project was ranked ―Small‖ in size, the WBS related to Rollout activities
was identified as ―Large‖ due to a large number of users being trained and time required
to roll out the processes.
Results of the above process were documented for each project and reviewed with the
Departments project management and project leads. The Department’s staff inputs and
adjustments were incorporated to derive the final duration of each project.
March 17, 2004 Page 69
Caltrans Integration Study Financial Systems Strategic Plan
Table A – WBS Duration
Duration in months
Major WBS Small Medium Large
1. Plan, prepare FSR 2-3 4-8 9-12
2. Update FSR 1-2 1-3 1-4
3. Obtain approval 1-2 1-3 1-3
4. Vendor Selections and Procurement 4-6 4-12 5-18
5. Project Startup - Verify and update
implementation plans with selected Vendor(s) 0.5 0.5-1.5 1-3
6. System Development (including Test &
Acceptance) 1-3 4 - 12 13 – 36
7. Rollout 0.5-1 1-3 2-4
Table B – Project Ranking
Impacts
Project Complexity # of Users Configuration Customization
Infrastructure S S S S
General Accounting L M L L
Fixed Assets S S S S
Budget Preparation S S S S
Project Reporting L L M S
CTIFS L M S M
CLMS M S M M
Purcha se Requisition S L S S
CMS L M N/A L
March 17, 2004 Page 70
Caltrans Integration Study Financial Systems Strategic Plan
Appendix B: Implementation Task Plan
The tasks associated with completing each of the Plan projects are listed in the attached
Microsoft Project Plans (PDF files). These projects include:
Infrastructure Project
General Accounting Project
Project Reporting Project
Construction Management System Project
Fixed Assets Accounting Project
Budget Preparation Project
Procurement and Inventory Project
California Transportation Infrastructure Funding System (CTIFS) Project
Caltrans Land Management System (CLMS) Project
The following tasks descriptions and notes are provided to assist the reader when reviewing the
detailed Microsoft Project Plans.
MASTER PLAN
The Master Plan is a rolled up Microsoft project document, which consolidates the individual
projects into one plan. The Master Plan will assist in visualizing sequence and relationships
between projects. The Master Plan will not only allow project team members to view all projects
in summary form, but also allow users to drill down to individual projects. This plan is structured
to follow each individual project’s start and end date, their internal milestones, task dependencies
and control points.
INDIVIDUAL PROJECTS
All projects are structured to include the following major activities:
Planning and Preparing the Feasibility Study Report (FSR)
Updating the FSR
Submitting the FSR for control agency review and approval
Vendor selection and procurement activities
Project Startup
Requirement Definition and Validation
Go/No Go Review
System Development
Rollout into production
March 17, 2004 Page 71
Caltrans Integration Study Financial Systems Strategic Plan
While each one of the nine major activities contains a timeline, the detail tasks defined for each
of the lower level tasks do not include start date, end date, resource, or duration information.
Lower level tasks are not serialized and could be run in parallel unless dependenc ies to specific
task(s) are identified in the ―Predecessors‖ column of the project plan.
It should be noted that detail tasks are listed as a set of guidelines and are based on the CIS
team’s recommendations or selected strategies, which are proposed for implementing the
Conceptual Architecture at the Department. Detailed task lists could change in duration and
sequencing based on the selected ERP product and the project implementation approach adopted
at each stage by the Department and selected vendor(s).
Planning and Preparing Feasibility Study Report (FSR)
During the FSR planning and preparing phase of each project, the FSR team members
will be identified as well as the project objectives, goals, and success criteria. The
specific dates for completion of project milestones will be identified, agreed upon, and
documented. Targeted levels of participation and support from each group within the
Department will be documented and agreed upon. The FSR Team will prepare the FSR
document(s), which will include a project plan that includes a detail task list and
timeline. The FSR will also include functional and technical requirements, as well as
post-implementation support, authorization, security requirements; development
standards upgrade requirements and strategies. The Team will also define the system
landscape strategy, project budget for hardware, telecommunication, software licenses,
training, traveling, contract/professional services, required internal resources (including
salary and benefits), any required Data Center services, and cost of facilities needed by
the implementation team. The FSR team will prepare and document the infrastructure
plan, system sizing, and software needed to support defined infrastructure activities and
system architecture.
Upon completion, the FSR will be disseminated for review and approval within the
Department. If the project requires additional funding, a Budget Change Proposal (BCP)
will be prepared. After the FSR is updated and finalized, it will be compiled for
submission to control agencies (for those projects that are planned to go forward right
away).
Updating the FSR
The Strategic Plan calls for each individual project plan to start working on preparing
FSRs as soon as possible, but in most cases FSRs will not be sub mitted to Finance for
approval and funding until ―Infrastructure‖ and ―General Accounting‖ projects are
submitted and funding is approved. To ensure FSR documents are up to date and they
reflect the latest changes to the Department’s requirements, ―Updating FSR‖ task is
added to all project plans except ―Infrastructure‖, ―General Accounting‖, and ―CMS‖
projects.
March 17, 2004 Page 72
Caltrans Integration Study Financial Systems Strategic Plan
Submit FSR for approval and funding to Agency and Finance
This task is added to each project in order to document the time spent on submitting FSR
documents to control agencies, and related communications, which will result in FSR
approval and promised funding.
Vendor Selection and Procurement activities
Vendor(s) selection will require the project team to develop a Request For Proposal
(RFP) document, and obtain internal and control agency approval to release RFP
documents to vendors. The FSR Team will be working closely with DPAC and DGS to
conduct the pre-bid conferences/confidential discussions, compile and evaluate the
proposals received, and respond to questions from vendors. Vendors will conduct
product demonstrations. The FSR Team will review and evaluate final proposals from
each vendor. DPAC will issue intent to award based on the FSR Team’s evaluation and
ranking of the vendors.
The contract will be prepared and signed, completing the vendor selection and
procurement process.
Project Startup
This section of the project plan lists tasks required to begin a project and work with the
vendor to verify and update the implementation plan details. This section also includes
tasks and activities specific to the selected product, services, and vendor’s
implementation methodology.
The major activities in this area include reviewing, validating, and updating the detailed
implementation plan with the vendor, updating the work plan and task duration, and
updating the start and end date for each task.
The plan for project resource and organization will be created based on the project plan
and project needs. The roles and responsibilities for each member of the project team
(vendor and the Departments resources) will be identified, documented and published.
The Issue Resolution, communication, and project status reporting (internal and external)
processes will be defined and documented.
The project governance, management standards, procedures, training, and plans for
quality assurance will be created and published. Strategies for support, rollout, upgrades,
and security will be documented.
The organizational change strategy will be drafted and the change charter and team will
be created. Agreements on the change team charter will be obtained from the Department
Executives, Management, Project Sponsor, and members of the Project Change Team.
March 17, 2004 Page 73
Caltrans Integration Study Financial Systems Strategic Plan
Refinements will be made based on the vendor’s input to the infrastructure plan, system
sizing, and system architecture. A Project Kickoff meeting will be conducted to initiate
the team building efforts.
Go/No Go Review
Before starting system development activities for each project, the management team
will conduct a Go/No Go review for the development phase of the project. The main
purpose of this control point is to provide an opportunity for adjusting the proposed
Conceptual Architecture implementation strategy based on any changes to project
dependencies, project sequencing, software vendor or implementer.
System Development
The system development section of each project differs depending on the project
objectives. The development efforts are less in the Infrastructure project, while they are
more prevalent for General Accounting and other projects. The following activities will
be undertaken during System Development:
Training will be provided to project team members (both business and IT).
Infrastructure will be put in place or refined. The Enterprise Application Integration
(EAI) layer will be configured and tested to allow connectivity between the new
systems (ERP & active Data Warehouse) and remaining systems. The Department
will complete the enterprise data and process model and the results will b e used for
configuring the ERP and active Data Warehouse systems.
The data policy will be established to identify development tasks needed for data
cleanup, data retention, and data archiving.
The data and reporting requirements for the active Data Warehouse will be defined
and developed. Legacy Data Warehouse systems will be reviewed and their services
will be moved into the new active Data Warehouse. The System Interface
Agreement (SIA) will be developed for interfaces and Legacy extracts. User
interfaces/screens, menu, and reports will be developed for DW users, and test
points will be identified, scripted, and planned for execution.
The ERP system will be configured based on documented requirements, and
approved business processes. Detail design will take place for development of
interfaces, integration points, and data conversion/load into ERP. Modifications to
remaining systems (if needed) will be identified and developed. Security
requirements will be identified, documented, and access will be configured for ERP
and DW users.
The Test/Quality Assurance plans, which were developed in the previous steps, will
be implemented during this phase. Activities such as setting up QA environments,
migration of configuration and code, identifying testing require ments, developing
test scripts, testing data loads, as well as, performing unit, integration, system, and
performance testing, will be scheduled and performed. .
March 17, 2004 Page 74
Caltrans Integration Study Financial Systems Strategic Plan
The result of QA testing and Production Rehearsal/Dry Run will be reviewed for
acceptance and obtaining Go/No Go for release to production and initiating the
production rollout processes.
Rollout
Production rollout activities are identified and separated from system development to
establish one last control point (Go/No Go) for each project in relation to the overall the
Plan. The project team and the Department management will evaluate the readiness of
each project in relation to readiness of the Division for accepting and adopting a new
system and processes. The rollout process includes preparing the production system,
loading approved configuration and codes, loading/converting production data,
establishing support/help desk processes, completing end user training, and enforcing
change management processes in production.
(See attached PDF file for Project Plans)
March 17, 2004 Page 75
Related docs
