Overview of the F$M Project

The Financial Systems Modernization (F$M) Project will deliver integrated, streamlined, and improved financial service and information solutions built on a robust, new system foundation.

The project addresses the current financial systems (people, processes, and technology), to more effectively provide data, analytical tools, and services for research management needs. This multi-year, Lab-wide operations initiative supports of one of the Lab's Strategic Initiatives: Service Technologies for Science. The project is being managed by a multidisciplinary Project Team, sponsored and chartered by Lab Director Dr. Paul Alivisatos.

F$M implementation is split into two phases, Phase II-A and a potential Phase II-B. Implementation of Phase II-B would follow Phase II-A, and is contingent upon available funding.

F$M Phase II-A includes rebuilding the foundational Financial Data Architecture (FDA) to leverage delivered functionality in applications, and streamlining the following end-to-end processes: DOE and WFO (e.g. proposal to closeout), Buying and Paying (including Procurement), and an initial phase of reporting and decision support.

F$M Phase II-B continues streamlining efforts with the following processes: Effort, Travel & Conferences, Property Management, new Procurement functionalities, and additional reporting and decision support.

Benefits: Why are we doing it?

The benefits F$M will deliver to the Lab are captured in the below Value Proposition.

Value Proposition

The current financial application was developed in PeopleSoft in 1997, to meet DOE requirements, and was based on a model from Lawrence Livermore National Laboratory (LLNL). As a result of not being designed for Berkeley Lab’s needs:

  • Custom workarounds were built
  • Delivered software functionality was locked out by the customizations
  • Processes became contorted, complex, manual, duplicative

Improving our overall financial system (people, processes, and technology) will allow us to:

  • Address the Lab’s business needs
  • Streamline Processes
  • Leverage our information technology (IT) investments

See the graphical depiction of the Case for Change.

Scope: What Does it Cover?

Berkeley Lab’s current central financial system was built in Oracle PeopleSoft, an Enterprise Resources Planning (ERP) application. The F$M project involves re-engineering the Lab’s financial services and related processes, in concert with upgrading to the latest version of PeopleSoft. The Lab uses the Supply Chain Management (SCM) and Financial Management System (FMS) modules of PeopleSoft.

The F$M Project addresses all six OCFO Service Areas. These Service Areas will be covered in two phases, Phase II-A, and a potential Phase II-B (see Schedule). Implementation of Phase II-B is contingent upon the success of Phase II-A and available funding.

Service Areas

Schedule: When Will it Happen?

F$M encompasses the following Phases (We are currently in Phase II-A):

Phase Time Frame Status Activities
Phase I 02/01/2011 – 11/30/2012 Completed

Define the problem & recommend solutions

  • Define and analyze current system & needs
  • Scope potential solutions
  • Build a business case for implementation (Phase II)
  • Identify a Systems Integration partner
Phase II-A 01/07/2013 – 11/30/2014 CURRENT PHASE

Design and implement core financial services

  • Streamline end-to-end processes 
    • DOE and WFO (e.g. proposal to closeout)
    • Buying and Paying
  • Restructure Financial Data Architecture
  • Reporting
  • Re-implement PeopleSoft Finance version 9.2
Phase II-B 10/1/2014 – 11/30/2015 Potential Future Phase*

Continue streamlining efforts

  • Effort Accounting
  • Travel & Conferences
  • Property Management
  • New Procurement functions (e.g., e-Vendor & Contract Management)

*Implementation of Phase II-B is contingent upon the success of Phase II-A and available funding.

Tentative Schedule for Phase II-A:


Tentative Schedule for Phase II-A


The F$M Project is guided by the following principles to aid in decision-making. The F$M Team continually strives to find a balance among these principles; for example, between the need for standardization and the need for customization. In addition, the Team follows a sophisticated Project Governance Structure for decision-making, and a formal process for Stakeholder Engagement.

Governing Principles