Docstoc

Aligning Financial Plan with Strategic Plan

Document Sample
Aligning Financial Plan with Strategic Plan Powered By Docstoc
					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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:55
posted:11/14/2010
language:English
pages:87
Description: Aligning Financial Plan with Strategic Plan document sample