# Presentation: 672525

## HANDI 2000 ProjectAn Enterprise Resource Planning Project at Hanford

- By Dawn Adams
- December 3, 1998
- Fluor Daniel Hanford Project Director:
- Bob Gates
- Fluor Daniel Hanford Executive Sponsor:
- Ed Penn

## Agenda

- Overview of HANDI 2000 Project
- The HANDI 2000 system
- Challenges
- Lessons Learned
- Path Forward

## What is the HANDI 2000 Project?

**What is the HANDI 2000 Project?**

- HANDI 2000 is the umbrella project replacing many of the Hanford Site’s legacy computer systems with an integrated information system and redesigning the associated work processes.

## What We Implemented?

- PeopleSoft
- 	Human Resources 	Version 7.0		7/1/98
- 	Payroll			Version 7.0		9/22/98
- 	General Ledger	Version 7.0		10/1/98
- 	Project Costing	Version 7.0		10/1/98
- Indus PassPort
- 	Inventory		Version 6.0.2		10/1/98
- 	Contracts Mgmt	Version 6.0.2		10/1/98
- 	Purchasing		Version 6.0.2		10/1/98
- 	Acct’s Payable	Version 6.0.2		10/1/98

## Why Implement an Enterprise Resource Planning System?

- Provide an integrated database solution
- reduce multiple data entry
- reduce maintenance costs
- improve data integrity
- Adopt widely applied commercial work practices
- Help achieve Year 2000 compliance
- Contractually committed
- Position Fluor Daniel Hanford to meet changing technology and business conditions

**Notes:**
1) Meets one of the major objectives of the PHMC Management and Integration Plan, HNF-MP-001, Rev. 1 by integrating the major Hanford business processes and their supporting information systems - this will reduce multiple data entry and expensive maintenance of separate systems.
2)Streamline work processes, improve efficiency and fully utilize computer interfaces.  
3) Past- to reduce costs of expensive data storage, date fields were 2 digits, instead of 4. - Now 00 could mean 1900 instead of 2000.  Hanford addressing Year 2000 problem by targeting mission critical systems.
4) Contractually committed in the Project Management Hanford Contract 

## Additional Business Objectives

- Replace existing legacy finance and supply management systems to:
- Reduce risk of “crash”
- Improve the quality of information
- Reduce maintenance and operations costs
- Improve access to information

## Additional Business Objectives (cont’d)

- Implement use of actual cost vs. standard/average costing
- Establish account structure standardization
- Improve efficiency and effectiveness by integrating planning, budgeting and execution processes
- Reduce excessive number of general ledger accounts and level of detail

##  Legacy Systems

**FDS** - Financial Data System  Work Order Module  Indirect Allocations  Performance Module  Budget Module  Expense Master  Capital Master  General Ledger
**ECS** - Expense Commitment       System
**PIDS** - Purchasing Info Document System
**WIMS** - Warehouse Inventory Mgmt System
**HIP** - Hanford Inventory Program

**SCA** - Systems Contracting Administration
**EVC** - Electronic Vendor Catalog
**PRA** - Payment Requestor Administration
**GIC** - General Inventory Catalog
**GSH** - General Supplies History
**RPH** - Purchasing History
**APM** - Accounts Payable Module
**PSI** - Property Sampling Inventory
**HMID** - Hazardous Material Inventory Database
**WHR** - PHMC Payroll

## Integrated Systems

**IntegratedData**

- Indus **PassPort**
- Inventory
- Contract Mgmt
- Purchasing
- Accounts Payable
- MSDS

**PeopleSoft**
- Financials
- HR
- Payroll

- Primavera** P3**
- Planning
- Scheduling
- Budgeting

## Challenges Faced

- Less than 1 year to implement - Fast Track Project
- Implemented at fiscal year end
- No parallel testing
- Minimal contingency options
- Big Bang!
- Developing Project staffing

## Challenges Faced (cont’d)

- Updating field procedures
- Training
- Hanford cultural buy-in/resistance to change
- Desktop computer adequacy/available budget
- Technical resource attrition
- huge demand, low supply, high cost

## Lessons Learned - What didn’t go well

- The project schedule didn’t allow enough time to communicate, plan and develop customer buy-in support
- Unable to engage functional users to take ownership early in the project
- Lacked Senior Management leadership during BPI sessions
- Should have started financial BPIs sooner

## Lessons Learned - What didn’t go well (cont’d)

- Services acquisition process was cumbersome, should have had a service Basic Order agreement
- Formal communication program got a late start
- Underestimated overall project costs
- Too many business changes being implemented over a short time
- Impacts to all “feeder systems”

## Lessons Learned - What Went Well

- Early involvement with DOE-RL
- Strong unit testing led to minimal issues during integration testing
- Total system design configuration with all interfaces led to minimal issues during testing
- Teamwork between FDH, LMSI, Indus, Deloitte and Touche, and others

## Lessons Learned - What Went Well (cont’d)

- Hired vendors who specialized in implementation rather than selecting individual consultants.
- Change in organization provided leadership necessary for success (focused objectives and discipline)
- Formal communication program including           e-mails, newsletters, road shows and information phone line

## Lessons Learned - What Went Well (cont’d)

- Minimal gaps between software and business process requirements
- Daily Plan of the Day which kept issues visible
- Business Process Improvement (BPI) sessions were well planned and attended by representatives from the majority of the affected business functions

## Path Forward

- Stabilize System
- Continue Training
- Develop/enhance future system configuration strategy
- upgrades to current systems
- new product modules