information technology volume 3 â€“ capitalized software

Application No.: Exhibit No.: SCE-05, Vol. 3

Ch. I-VI Witnesses: E. Antillon

K. Cini T. Felix J. Foulk S. Hemphill K. Pickrahn M. Pinter S. Tessema R. Worden

(U 338-E)

2009 General Rate Case

Information Technology Volume 3 – Capitalized Software

Before the

Public Utilities Commission of the State of California Rosemead, California

November 2007

Volume Summary

• IT is requesting $283 million of capitalized software expenditures for the forecast period

2007-2011.

• Operating software is an essential component necessary to operate each of the three

major SCE computing environments: Mainframe, UNIX, and Non-UNIX.

• The Software Asset Management (SAM) process for SCE’s computer software business

applications proactively manages the portfolio of applications, such that decisions to

replace or upgrade specific software applications are based on sound analysis and

prioritization.

• Information Security requests are for requirements to protect critical SCE systems and

sensitive information from cyber attacks.

• To meet the growing regulatory requirements that have recently been mandated and in

anticipation of the increased complexity associated with new markets and regulatory

requirements, IT is supporting several capitalized software projects including NERC CIP,

MRTU, etc.

• PPBU’s Capitalized Software projects include projects to expand capabilities and/or

replace systems that are being discontinued, including its energy trading and risk

management system and systems that will support the business unit's required activities

for net energy metering and distributed generation projects, plus regulatory mandates and

initiatives, including, the CAISO’s Market Redesign and Technology Upgrade (MRTU),

the CPUC’s Resource Adequacy program, Greenhouse Gas legislation and regulatory

requirements, and demand response programs.

• TDBU’s Capitalized Software projects will enhance or replace SCE’s current systems

and processes for electrical asset mapping and field tools supporting a mobile workforce.

SCE-05: Information Technology Volume 3 - Capitalized Software

Table Of Contents Section Page Witness

-i-

I. OPERATING SOFTWARE.......................................................................................1 J. Foulk

A. Operating Software ................................................................................1

1. Background................................................................................1

2. Business Requirements ..............................................................2

3. Recorded And Forecast Expenditures........................................3

a) Mainframe Operating Software .....................................5

(1) Basis For Expenditures ......................................6

(2) Recorded And Forecast Expenditures................8

b) UNIX Operating Software ...........................................10

(1) Basis For Expenditures ....................................10

(2) Recorded And Forecast Expenditures..............14

c) Non-UNIX Operating Software...................................17

(1) Basis For Expenditures ....................................18

(2) Recorded And Forecast Expenditures..............20

4. Conclusion ...............................................................................24

II. SOFTWARE ASSET MANAGEMENT ................................................................26 M. Pinter

A. Introduction..........................................................................................26

B. Our 2009-2011 Software Asset Management Request Excludes Projects Within The Scope Of Enterprise Resource Planning ...............................................................................26

C. Software Asset Management Of Applications Outside ERP Footprint...............................................................................................27

1. Overview Of Software Asset Management .............................27

2. Software Asset Management Mitigates Risk...........................30


Table Of Contents (Continued) Section Page Witness

-ii-

a) Risks.............................................................................31

(1) Technology Obsolescence ...............................32

(2) Vendor Obsolescence.......................................32

(3) Business Obsolescence ....................................33

b) Risk Summary..............................................................34

3. Software Asset Management Process ......................................37

a) SAM Governance.........................................................38

b) Portfolio Optimization Analysis Process .....................39

c) Project Assessment, Alignment And Ranking ........................................................................40

d) Prioritization And Fund Allocation .............................41

e) Forecast Development .................................................41

D. Recorded And Forecast Cost Analysis ................................................42

E. Proposed Software Asset Management Projects..................................44

1. Customer Data Acquisition System.........................................45

a) Background..................................................................45

b) Problem Statement .......................................................45

c) Recommended Approach.............................................46

d) Funding Requirements .................................................46

2. Field Services System..............................................................46

a) Background..................................................................47





-iii-


3. Real Time Energy Metering System........................................48

a) Background..................................................................48




4. Energy Cost Simulation Tool...................................................50

a) Background..................................................................50




5. Meter Reading System.............................................................51

a) Background..................................................................51




6. Complex Metering Services.....................................................53

a) Background..................................................................53




7. Usage Measurement System....................................................55

a) Background..................................................................55



-iv-




8. Wholesale Energy System .......................................................57

a) Background..................................................................57




9. Generation Management System .............................................59

a) Background..................................................................59




10. Electronic Data Interchange.....................................................61

a) Background..................................................................61




11. Geographical Information Application System Major Upgrade .........................................................................63

a) Background..................................................................63





-v-


12. Law Matter Management System ............................................65

a) Background..................................................................65




13. Outage Management System – Upgrade To Version 5.0.............................................................................................66

a) Background..................................................................66



14. GE Smallworld – Upgrade To Version 4.1..............................68

a) Background..................................................................68




15. TDBU Mobile Systems............................................................69

a) Background..................................................................70




16. Ledger Accounting System......................................................72

a) Background..................................................................72



-vi-

b) Problem Statement And Recommended Approach......................................................................72

c) Funding Requirements .................................................73

F. Our Forecast Is Reasonable .................................................................73

G. Avoided Software Expenditures Resulting From Enterprise Resource Planning ...............................................................................74

H. Conclusion ...........................................................................................76

III. NEW CAPABILITIES...........................................................................................78 R. Worden

A. Regulatory Policy & Affairs (RP&A) .................................................78

1. O&M Workpaper Database (RP&A).......................................78

a) Introduction..................................................................78

b) Description of the Previous Database ..........................78

(1) Problems with the Previous Database..............80

c) Description of the New Database ................................82

(1) Cost Estimate & Reasonableness of the New Database ............................................83

IV. EXPANDED CAPABILITIES..............................................................................85

A. Power Procurement Business Unit (PPBU).........................................85

1. PPBU Cost Estimation Methodology ......................................85 K. Pickrahn

2. Net Energy Metering Project (NEM) (PPBU) .........................87 S. Hemphill

a) Introduction..................................................................87

b) Background..................................................................88

(1) Net Energy Metering Requirements ................88

(2) The Net Energy Metering Project ....................88



-vii-

c) Vendor Selection Process ............................................90

d) Project Costs and Schedule..........................................90

3. Distributed Generation Project (PPBU)...................................91

a) Introduction..................................................................91

b) Background..................................................................91

(1) Distributed Generation Requirements..............91

(2) The Distributed Generation Project .................92

c) Vendor Selection Process ............................................93

d) Project Costs and Schedule..........................................93

4. Entegrate (PPBU).....................................................................94 K. Pickrahn

a) Introduction..................................................................94

b) Background..................................................................95

(1) PPBU Business Functions Supported by Entegrate .....................................................95

(2) The Entegrate Program ....................................96

c) Project Benefits............................................................96

d) Vendor Selection Process ............................................97

e) Project Costs and Schedule..........................................98

B. Transmission and Distribution Business Unit (TDBU) .......................99 E. Antillon

1. Comprehensive TDBU Geographic Information System....................................................................................100

a) Description of a Comprehensive Mapping Information System....................................................103

(1) Links Between Mapping Information and Employee Safety .....................................104



-viii-

(2) Links Between Mapping Information and Public Safety ...........................................105

(3) Links Between Mapping Information and Compliance .............................................105

(4) Links Between Mapping Data and Reliability.......................................................107

b) Description Of TDBU’s Current Systems .................109

c) Shortcomings Associated With TDBU’s Existing Mapping Systems, And How A Comprehensive Mapping System Will Help Overcome The Shortcomings ....................................111

d) Implementing a Comprehensive TDBU Mapping System Project Will Provide Additional Functionality to Existing Tools, Improving Safety, Reliability, and Compatibility .............................................................116

e) Project Description and Schedule ..............................118

(1) Overview........................................................118

(2) Phase 1 – 3, Planning and Design, 2009................................................................120

(3) Phases 4 - 5: Build and Implement Initial Three Regions, 2010 – 2011................121

(4) Deliverables ...................................................121

(5) Mapping Pilot Solution ..................................122

f) Project Costs ..............................................................123

g) Conclusion .................................................................124

2. TDBU Consolidated Mobile Solution ...................................125

a) Description of CMS ...................................................127



-ix-

b) Consolidated Mobile Solution – TDBU Management Priorities ...............................................129

(1) Importance of Consolidated Mobile Solution for Safety .........................................129

(2) Importance of CMS for Reliability ................130

(3) Importance of CMS for Compliance..............131

c) Description of Deficiencies with TDBU’s Current Process for Managing Field Work................131

(1) Overview........................................................131

(2) Examples of Current Problem Areas .............133

d) Project Description, Schedule, and Costs ..................136

e) Conclusion .................................................................138

C. Customer Service Business Unit (CSBU)..........................................138 T. Felix

1. Bill Redesign Project (BRP) ..................................................138

a) Introduction................................................................138

(1) Overview........................................................139

(2) Project Expenditures ......................................140

(3) Vendor Selection Process ..............................141

(4) Description Of The BRP Capitalized Software Expenditures ...................................141

(5) Test Year O&M Expenses .............................142

(6) Project Benefits And Avoided Cost...............144

(7) Project Implementation..................................144

(8) Summary ........................................................145

V. TECHNOLOGY AND RISK MANAGEMENT..................................................146 S. Tessema



-x-

A. Information Security ..........................................................................146

1. Background............................................................................146

2. Business Requirements ..........................................................147

a) Recorded And Forecast Expenditures........................151

b) Perimeter Defense Expenditures................................152

c) Interior Defense Program...........................................154

d) Data Protection Expenditures ....................................157

3. Analysis..................................................................................158

a) Alternatives Considered.............................................159

4. Conclusion .............................................................................159

B. Business Continuity Planning Systems..............................................160

1. Background............................................................................160


3. Recorded And Forecast Expenditures....................................163

4. Alternative Considered ..........................................................164

5. Conclusion .............................................................................165

C. Enterprise Technology Services ........................................................165

1. Background............................................................................165


a) Integrated Information Sharing Services ...................167

b) Obsolete Wireless Access Gateway Replacement...............................................................169

3. Recorded And Forecast Expenditures....................................170



-xi-

4. ERP Benefits..........................................................................171

5. Conclusion .............................................................................172

VI. REGULATORY MANDATES AND INITIATIVES.........................................174 S. Tessema

A. NERC CIP Compliance .....................................................................174

1. Background............................................................................174

a) Purpose.......................................................................175

b) Scope..........................................................................175

c) Request Summary ......................................................177


a) Detailed NERC Mandated Business Requirements .............................................................177

b) Program Approach .....................................................180

3. Recorded and Forecast Expenditures.....................................181

a) Summary of Capital Expenditures .............................181

4. Conclusion .............................................................................189

B. Power Procurement Business Unit (PPBU).......................................190

1. MRTU Release 1 Project (PPBU)..........................................190 K. Cini

a) Introduction................................................................190

b) Background................................................................192

(1) MRTU Overview ...........................................192

(2) The MRTU Release 1 Project ........................194

(3) Operations and Settlements............................195

c) Project Costs and Schedule........................................209



-xii-

2. MRTU Release 1A Project (PPBU).......................................210

a) Introduction................................................................210

b) The MRTU Release 1A Project .................................210

c) Vendor Selection Process ..........................................211

d) Projects Costs and Schedule ......................................211

3. MRTU Release 2 Project (PPBU)..........................................212

a) Introduction................................................................212

b) The MRTU Release 2 Project ....................................214


d) Project Costs and Schedule........................................215

4. Energy Procurement and Energy Planning Tools Project (PPBU).......................................................................216

a) Introduction................................................................216

b) The Energy Procurement and Energy Planning Tools Project...............................................217



(1) Energy Procurement Tools ............................219

(2) Energy Planning Tools...................................220

5. Capacity Position Register and RA Registry Compliance Process (PPBU) .................................................222

a) Introduction................................................................222

b) The Capacity Position Ledger and RA Registry Compliance Project .....................................223




-xiii-


6. Resource Adequacy Capacity Market Project (PPBU)...................................................................................225

a) Introduction................................................................225

b) Background................................................................225

(1) PPBU’s Role in RA Compliance ...................225

(2) The RA Capacity Market Project...................226



7. Tolling Automation Project (PPBU)......................................228 K. Pickrahn

a) Introduction................................................................228

b) Background................................................................229

(1) Tolling Contracts Settlement Activities ........................................................229

(2) The Tolling Automation Project ....................230



8. Greenhouse Gas Project (PPBU) ...........................................234 K. Cini

a) Introduction................................................................234

b) PPBU’s GHG Role ....................................................235

(1) The Greenhouse Gas Project..........................235



9. Demand Response Project (PPBU)........................................240



-xiv-

a) Introduction................................................................240

b) How Demand Response Impacts PPBU ....................241

c) The Demand Response Project ..................................242

d) Vendor Selection Process ..........................................243

e) Project Costs and Schedule........................................243

Appendix A Witness Qualifications

SCE-05: IT Volume 3 - Capitalized Software

List Of Figures Figure Page

-xv-

Figure I-1 Operating Software Expenditures 2002-2006 Recorded And 2007-2011

Forecast (Nominal $000) .......................................................................................................... 4

Figure I-2 Mainframe Operating Software Expenditures 2002-2006 Recorded And 2007-

2011 Forecast (Nominal $000).................................................................................................. 6

Figure I-3 IBM Mainframe Server/Processing Growth (MIPS) 2002-2006 Recorded And

2007–2011 Forecast................................................................................................................. 7

Figure I-4 UNIX Operating Software Expenditures 2002-2006 Recorded And 2007-2011

Forecast (Nominal $000) ........................................................................................................ 10

Figure I-5 Non-UNIX Operating Software Expenditures 2002-2006 Recorded And 2007-

2011 Forecast (Nominal $000)................................................................................................ 18

Figure I-6 ERP Benefits 2013 – 2016 Forecast (Nominal $000) ....................................................... 24

Figure II-7 SAM Operating Model ............................................................................................... 38

Figure II-8 The SAM Calendar..................................................................................................... 42

Figure II-9 Software Asset Management 2007-2011 Forecast (Nominal $000) .................................. 43

Figure II-10 ERP Avoided Software Expenditures 2005-2009 (Nominal $000) ................................. 75

Figure II-11 Practical Approach For Replacing Legacy Applications In ERP Footprint

(Nominal $000) ..................................................................................................................... 76

Figure III-12 SCE GRC Revenue Requirement Process .................................................................. 80

Figure V-13 Risk Management – Information Security Total Threats To SCE................................. 148

Figure V-14 Identified Security Vulnerabilities............................................................................ 149

Figure V-15 Perimeter Defense Program Expenditures 2002–2006 Recorded And 2007-

2011 Forecast (Nominal $000).............................................................................................. 152

Figure V-16 Interior Defense Program Expenditures 2002–2006 Recorded And 2007-



List Of Figures (Continued) Figure Page

-xvi-

Figure V-17 Data Protection Program Expenditures 2002–2006 Recorded And 2007–


Figure V-18 Business Continuity Planning Systems Expenditures 2002–2006 Recorded

And 2007–2011 Forecast (Nominal $000) .............................................................................. 163

Figure V-19 Enterprise Technology Services Expenditures 2002–2006 Recorded And

2007–2011 Forecast (Nominal $000) ..................................................................................... 170

Figure V-20 Enterprise Decision Support Infrastructure (EDSI) ERP Benefits (Nominal

$000) ................................................................................................................................. 172

Figure VI-21 NERC Cyber Vulnerability Assessment Scope ......................................................... 176

Figure VI-22 NERC CIP Cyber Security Standards Eight Standards / 41 Requirements ................... 179

Figure VI-23 NERC Implementation Approach ........................................................................... 181

Figure VI-24 NERC CIP Budget Item Expenditures 2002-2006 Recorded And 2007-2011

Forecast (Nominal $000) ...................................................................................................... 182

Figure VI-25 NERC – CIP Implementation Hierarchy .................................................................. 183

Figure VI-26 Major Milestones For Compliance Project ............................................................... 188


List Of Tables Table Page

-xvii-

Table I-1 Operating Software Expenditures By Category Recorded 2002-2006 And

Forecast 2007-2011 (Nominal $000) ......................................................................................... 5

Table I-2 UNIX Operating Software Expenditures By Category 2002-2006 Recorded and

2007-2011 Forecast (Nominal $000) ....................................................................................... 14

Table I-3 Non-UNIX Operating Software Expenditures 2002-2006 Recorded And 2007-

2011 Forecast (Nominal $000)................................................................................................ 20

Table II-4 Applications Not In The ERP Footprint Subject To Category Of Risk............................... 34

Table II-5 Number Of Applications Not In The ERP Footprint At Risk By Application

Age...................................................................................................................................... 35

Table II-6 Estimated Project Expenditures for 2007-2011 (Nominal $000)........................................ 44

Table II-7 Customer Data Acquisition System ............................................................................... 45

Table II-8 Field Services System .................................................................................................. 46

Table II-9 Real Time Energy Metering System .............................................................................. 48

Table II-10 Energy Cost Simulation Tool ...................................................................................... 50

Table II-11 Meter Reading System ............................................................................................... 51

Table II-12 Complex Metering Services ........................................................................................ 53

Table II-13 Usage Measurement System ....................................................................................... 55

Table II-14 Wholesale Energy System .......................................................................................... 57

Table II-15 Generation Management System ................................................................................. 59

Table II-16 Electronic Data Interchange ........................................................................................ 61

Table II-17 GIAS Major Upgrade ................................................................................................. 63

Table II-18 Law Matter Management System ................................................................................ 65

Table II-19 Outage Management System....................................................................................... 66

Table II-20 GE Smallworld Upgrade............................................................................................. 68

Table II-21 TDBU Mobile Systems .............................................................................................. 69


List Of Tables (Continued) Table Page

-xviii-

Table II-22 Ledger Accounting System ......................................................................................... 72

Table III-23 GRC Workpaper Database......................................................................................... 84

Table IV-24 Net Energy Metering Project 2009-2010 Forecast Capital Expenditure .......................... 91

Table IV-25 Distributed Generation Project 2009-2010 Forecast Capital Expenditure ........................ 94

Table IV-26 Entegrate Project 2007 Forecast Capital Expenditure ................................................... 98

Table IV-27 GIS Capital Expenditures (2007-2011) ..................................................................... 124

Table IV-28 CMS Capital Expenditures ...................................................................................... 136

Table IV-29 Project Expenditures In Millions .............................................................................. 141

Table IV-30 BRP Increased Ongoing O&M Costs 2006 $ millions ................................................ 143

Table IV-31 Avoided Bill Insert Printing O&M Costs 2006 $ millions ........................................... 144

Table IV-32 BRP Milestones and Completion Dates .................................................................... 145

Table V-33 Perimeter Defense Solutions And Forecasted Expenditures (Nominal $000) .................. 153

Table V-34 Interior Defense Solutions And Forecast Expenditures (Nominal $000)......................... 156

Table V-35 Data Protection Security Solutions Forecast Expenditures (Nominal $000) .................... 158

Table VI-36 Capital Expenditures By CIP Mandate (Nominal $000s)............................................. 189

Table VI-37 MRTU Release 1 Project 2007-2008 Forecast Capital Expenditure.............................. 209

Table VI-38 MRTU Release 1A Project 2007-2008 Forecast Capital Expenditure ........................... 212

Table VI-39 MRTU Release 2 Project 2008-2010 Forecast Capital Expenditure.............................. 216

Table VI-40 Energy Procurement and Energy Planning Tools Project 2007-2009 Forecast

Capital Expenditure ............................................................................................................. 222

Table VI-41 Capacity Position Register and RA Registry Compliance Project 2009

Forecast Capital Expenditure ................................................................................................ 224

Table VI-42 Resource Adequacy Capacity Market Project 2009 Forecast Capital

Expenditure ........................................................................................................................ 228

Table VI-43 Tolling Automation Project 2008 Forecast Capital Expenditure................................... 234


List Of Tables (Continued) Table Page

-xix-

Table VI-44 Greenhouse Gas Project 2009-2010 Forecast Capital Expenditure ............................... 240

Table VI-45 Demand Response Project 2009 Forecast Capital Expenditure .................................... 244

1

I. 1

OPERATING SOFTWARE 2

A. Operating Software 3

1. Background 4

The purpose of this testimony is to describe SCE’s operating software needs for 2007-5

2011. 6

Operating software is an essential component necessary to operate each of the three 7

major SCE computing environments: Mainframe, UNIX, and Non-UNIX.1 Each of these environments 8

consist of computer processors, data storage devices, and printing devices, that rely on proprietary 9

computer software known as operating software to monitor, manage, and control these computing 10

environments.2 11

Operating software provides several necessary capabilities. First, operating software 12

improves management and utilization of IT assets. Operating software tools monitor and manage the 13

use of computer assets such as computer memory and processors, data storage, and output peripherals. 14

Examples include software used to monitor CPU utilization or to collect software inventory on UNIX 15

and Non-UNIX servers. Second, operating software enhances control over computer applications and 16

databases, which is increasingly important as we rely more on computer systems to support routine 17

business operations. An example is software used to control anti-virus distribution and assure 18

conformity with security settings on Non-UNIX servers and personal computers. Third, operating 19

software simplifies and improves SCE business processes within the computer systems environment. 20

To ensure the appropriate level of ongoing vendor support and maintenance, SCE’s 21

policy requires that all operating software is no more than one version behind the latest version so that 22

this essential software remains supported by the vendor. Unsupported software increases the risk of 23

application outages due to inability to correct software failures, resulting in risk to the computing 24

1 See SCE-5, Volume 3, Software Asset Management, for discussion on the need to keep business application software

current. 2 Operating software differs from application software that is used to support business functions and transactions.

2

environment and business applications. Moreover, unsupported software creates unacceptable security 1

risks as the vendor is no longer keeping pace with the latest security threats. 2

The past generation of operating software historically allowed SCE to focus on the 3

management and control of assets specific to the different operating environments, i.e., mainframe, 4

UNIX, and Non-UNIX. While this served the needs of the organization in the past, a new class of 5

operating software is commercially available that allows SCE to manage computing assets across and 6

independent of specific platforms. This new breed of operating software facilitates higher utilization of 7

computing resources, provides more flexibility, and improves reliability. As SCE updates and replaces 8

its older operating software, we will obtain the benefits of these new enhancements and advances. This 9

class of software products is a significant part of projected operating software expenditures for the 10

forecast period 2007 through 2011. 11

These capabilities provide improvements in the way we allocate computing and storage 12

resources.3 The new capabilities include: 13

• Capacity load balancing which allows greater data flow. 14

• Disaster recovery-enabling automated failover capability. 15

• Enhanced automation of server provisioning. 16

One method of controlling operating software costs is through the negotiation of 17

corporate license agreements to maximize quantity discounts. In our forecast period, we will be 18

renegotiating some of our major operating software enterprise agreements to meet these objectives. 19

Vigilance in adhering to the terms and conditions of these agreements enables us to better track 20

software license compliance, and thereby enhance asset management. 21

2. Business Requirements 22

Business requirements for operating software are dictated by the number, type, and size 23

of computing hardware components maintained by SCE. Business requirements can be classified into 24

three groups: 25 3 The hardware improvements that will be obtained as a result of these additional capabilities have been incorporated into

our forecasts for hardware asset management of our computing environments.

3

• Capacity Driven- necessary to add additional software licenses 1

incrementally as growth occurs and service levels warrant. 2

• New Capability – necessary to support new, planned capabilities that will 3

be implemented and will require support. 4

• Vendor Specified – necessary to keep SCE in compliance with vendor 5

software licensing, support and security requirements at a level consistent 6

with business needs. 7

The costs associated with operating software have risen over the past several years.4 8

While mainframe operating software maintenance costs have consistently been in the range of 10-20 9

percent of software acquisition per year, the costs for the UNIX and Non-UNIX operating software have 10

now begun to approximate this range as well. Increases are typically driven by factors similar to the 11

requirements categories outlined above, i.e., by usage (number of seats/users), transaction volume, 12

server processor capacity and costs for enhanced capability. An additional factor putting upward 13

pressure on costs is the ongoing consolidation of vendors through mergers and acquisitions.5 As the 14

ERP Project is implemented, we will ensure that ERP’s operating environment is consistent with 15

existing standards for the non-ERP computing services infrastructure. This standard infrastructure will 16

utilize existing hardware and software (i.e., standard toolsets) more efficiently to mitigate incremental 17

costs. 18

3. Recorded And Forecast Expenditures 19

SCE plans to expend $63.4 million on Operating Software for the period 2007-2011. The 20

Figure I-1 below depicts our 2002-2006 recorded and 2007-2011 forecast expenditures for this budget 21

item. These expenditures do not include the San Onofre Generating Station capital expenditures.6 22

4 See Workpaper entitled “Five Business Application Software Maintenance Trends to Watch in 2007 and Beyond,”

Gartner publication ID G00146672. 5 See Workpaper entitled “Management Update: How to Protect Yourself If Your Software Vendor Is Acquired.” 6 See SCE-2, Volume 3, Generation - SONGS capital for additional details.

4

Figure I-1 Operating Software Expenditures

2002-2006 Recorded And 2007-2011 Forecast (Nominal $000)

$0.0

$5,000.0

$10,000.0

$15,000.0

$20,000.0

$25,000.0

$30,000.0

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Amount $6,281.5 $13,444.7 $22,681.8 $20,280.3 $8,175.3 $7,712.5 $10,261.3 $13,005.5 $24,647.4 $7,758.1

Recorded Forecast

5

The following Table I-1 details our 2002-2006 recorded and 2007-2011 forecast 1

expenditures for the operating software by category. 2

Table I-1 Operating Software Expenditures By Category Recorded 2002-2006 And Forecast 2007-2011

(Nominal $000) 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Mainframe Operating software & Middleware $5,247.0 $7,315.5 $3,676.8 $2,474.5 $2,946.8 $3,995.2 $3,695.2 $900.0 $900.0 $900.0UNIX Operating Software & Middleware $1,034.5 $3,508.6 $10,252.6 $9,997.5 $4,525.9 $3,420.0 $0.0 $2,688.5 $6,259.8 $822.7

It Resource Optimization (ITRO) - Dynamic Server Provisioning/TPM $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $1,251.0 $1,250.0 $500.0 $0.0Enterprise Configuration Management Tool/Processes $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $1,500.0 $0.0 $0.0Lotus Notes Upgrade ( Work Space Integration) $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $8,857.8 $0.0Non-UNIX Operating Software & Middleware $0.0 $2,620.6 $8,752.4 $7,808.3 $702.6 $297.3 $5,315.1 $1,167.0 $2,629.8 $535.4Microsoft Enterprise Agreement - vista, Windows $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $5,500.0 $5,500.0 $5,500.0

Total $6,281.5 $13,444.7 $22,681.8 $20,280.3 $8,175.3 $7,712.5 $10,261.3 $13,005.5 $24,647.4 $7,758.1

ForecastRecorded

SCE spent a total of $70.9 million from 2002 through 2006 on operating software for our 3

mainframe, UNIX and Non-UNIX servers. During this period, we converted our systems to another 4

operating software vendor that allowed us to avoid $14.5 million in expenditures. Additional details of 5

this decision are discussed below. 6

The 2002 through 2006 recorded expenditures were based on computing resource usage 7

driven by customer growth, significant changes in the capabilities of operating software, and the need to 8

only use vendor-supported versions of the software. Projected expenditures for the forecast period 2007 9

through 2011 are $63.4 million. 10

a) Mainframe Operating Software 11

As shown in Figure I-2 below, SCE plans to expend $10.4 million on operating 12

software for mainframe servers during the forecast period 2007-2011. This figure depicts our recorded 13

and forecast expenditures for the mainframe server operating software. 14

6

Figure I-2 Mainframe Operating Software Expenditures 2002-2006 Recorded And 2007-2011 Forecast

(Nominal $000)

$0.0

$1,000.0

$2,000.0

$3,000.0

$4,000.0

$5,000.0

$6,000.0

$7,000.0

$8,000.0

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Amount $5,247.0 $7,315.0 $3,676.8 $2,474.5 $2,946.8 $3,995.2 $3,695.2 $900.0 $900.0 $900.0

Recorded Forecast

(1) Basis For Expenditures 1

Operating software expenditures in this area consists of three major 2

categories: upgrades to the IBM mainframe operating software, upgrades to our license agreement with 3

BMC Software, Inc., and upgrades to software provided by independent software vendors (ISV). All of 4

these expenditures are based on either growth in internal needs, significant changes in the capabilities of 5

operating software, or to ensure we are using vendor-supported products. 6

(a) IBM Operating Software7 7

The cost of the IBM operating system software is based on the size 8

of the computer systems on that it operates. Size is measured by the number of computer instructions 9

that can be performed in one second.8 Usage of the IBM mainframe continues to increase with growth 10

in computer applications such as the Customer Service System (CSS) and Human Resource Systems, 11

7 See Workpaper entitled “Computing Services Operating Software.” 8 Commonly referred to as “millions of instructions per second,” or MIPS.

7

along with routine reporting, data analysis and other requirements until these systems are replaced by 1

ERP. Figure I-3 below depicts the total number of millions of instructions per second (MIPS) recorded 2

and percentage growth per year at SCE for the period 2002-2006, as well as the projected growth for the 3

period 2007-2011. This increase is attributable to increased customer service transaction volume and 4

growth of the supporting databases.9 5

Figure I-3 IBM Mainframe Server/Processing Growth (MIPS)

2002-2006 Recorded And 2007–2011 Forecast

3,000

3,500

4,000

4,500

5,000

5,500

6,000

6,500

7,000

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

MIPS

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011MIPS 3,798 4,050 4,050 4,050 4,345 4,490 5,091 5,672 5,946 6,212Percentage Growth 7.4% 6.6% 0.0% 0.0% 7.3% 3.3% 13.4% 11.4% 4.8% 4.5%

Recorded Forecast

SCE will incur additional operating software license expenditures 6

as IBM mainframe server processing capacity is increased. This is necessitated by the nature of IBM 7

software licensing agreements and the subsequent availability of support and assistance. IBM operating 8

system software tools consist of many individual products that assist us in managing the mainframe 9

computer environment.10 10

9 See charts in Workpapers entitled “Total Transaction Count per Workload by Month” and “Total CPU Seconds per

Workload by Month.” 10 See Workpaper entitled “Computing Services Operating Software.”

8

(b) BMC Operating Software Tools 1

In 1999, after an evaluation of vendor products, SCE selected 2

BMC Software as part of our Software Cost Containment Program. BMC provides important operating 3

software tools that allow us to efficiently manage the operations of our IBM mainframe servers. These 4

operating software tools allow SCE to produce trend analyses as well as monitor and automate various 5

operational activities.11 6

(c) Independent Software Vendors12 7

We also purchase operating software from other independent 8

software vendors (ISV) to support the operations of the IBM mainframe server. These ISV products 9

provide us with additional required functionalities that the two major vendors mentioned above do not 10

fulfill, so that we can meet all of our computing environment requirements. 11

(2) Recorded And Forecast Expenditures 12

The recorded and forecast expenditures for mainframe operating software 13

are indicated in Figure I-2 above. 14

In 2002, expenditures were $5.2 million due to the purchase of additional 15

ISV product licenses resulting from continued growth in IBM mainframe server processing capacity. 16

In 2003, SCE net operating software expenditures increased by $2.1 17

million, for a total of $7.3 million. Included in this total was an additional $2.7 million for various IBM 18

operating software products converting and replacing many Computer Associates products that, due to 19

anticipated price increases, would have become very expensive to maintain. By not renewing these 20

products, ISV license costs decreased by $3.2 million. This product replacement resulted in a five-year 21

cost avoidance of $14.5 million.13 The total cost for IBM operating software products will be paid over 22

a five-year period, from 2003 through 2007. In addition, we renewed our three-year license with BMC 23

Software at a cost of $2.6 million. 24 11 Id. 12 See Workpaper entitled “Computing Services 2007 Software Maintenance Projection.” 13 See Workpaper entitled “Software Cost Containment Program.”

9

In 2004 and 2005, we expended a total of $6.2 million as installment 1

payments for IBM and ISV operating software acquired in 2003, as indicated above. 2

In 2006, SCE expended $2.3 million as installment payments for IBM and 3

ISV operating software acquired in 2003, as well as operating software licenses to accommodate the 4

purchase of additional mainframe and data and disk storage capacity to accommodate growth in CSS 5

production and related data warehousing activities. In addition, we expended $600,000 in 2006 to 6

acquire newer versions of BMC software used to monitor and control various operational aspects of the 7

mainframe. 8

In 2007, SCE forecasts to expend $4.0 million for incremental increases in 9

license fees.14 Of this amount, $1.0 million constitutes another installment payment for the IBM 10

replacement products mentioned above. The remaining $3.0 million is based on anticipated incremental 11

increases in mainframe central processor capacity to accommodate customer base growth and billing 12

related activities for Customer Service System (CSS).15 13

In 2008, SCE forecasts to expend $3.7 million for incremental increase in 14

license fees. Of this amount, $1.0 million is for the last installment for the IBM replacement products 15

mentioned above. The remaining $2.7 million is based on anticipated incremental increases in 16

mainframe central processor capacity to accommodate customer base growth and billing related 17

activities for CSS. 18

In 2009-2011, SCE forecasts to expend $2.7 million for incremental 19

increase in license fees based on anticipated incremental increases in mainframe central processor 20

capacity to accommodate customer base growth and billing related activities for CSS. These additional 21

mainframe costs are anticipated to be eliminated when ERP Release 4 is implemented in 2013. 22

14 See Workpaper entitled “Mainframe Operating Software & Middleware.” 15 See charts in Workpapers entitled “Total Transaction Count per Workload by Month” and “Total CPU Seconds per

Workload by Month.”

10

b) UNIX Operating Software 1

SCE plans to expend $26.5 million on UNIX server operating software during the 2

forecast period 2007-2011. Figure I-4 below depicts our 2002-2006 recorded and 2007-2011 forecast 3

expenditures for this budget item. These expenditures include UNIX operating system software and 4

operating software tools. 5

Figure I-4 UNIX Operating Software Expenditures


$0.0

$2,000.0

$4,000.0

$6,000.0

$8,000.0

$10,000.0

$12,000.0

$14,000.0

$16,000.0

$18,000.0

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Amount $1,034.5 $3,508.6 $10,252.6 $9,997.5 $4,525.9 $3,420.0 $1,251.0 $5,438.5 $15,617.6 $822.7

Recorded Forecast


UNIX Server operating software expenditures consists of the following 7

major items: (a) IBM operating software products including an upgrade of the AIX UNIX operating 8

software and the purchase of Tivoli Configuration Manager;16 (b) replacement of our messaging and 9

calendaring system; (c) refresh of UNIX-based operating software; and (d) critical operating software 10

that support the enterprise platform services. The UNIX server environment is used to support critical 11

business processes such as the dispatching of repair crews, tracking and isolating of power service 12 16 See Workpaper entitled “IBM Tivoli Configuration Manager.”

11

failures, managing customer trouble calls, and monitoring automated power distribution devices. These 1

processes are essential for SCE to maintain safe and reliable electric service for our customers.17 2

(a) IBM Operating Software Upgrade (AIX) 3

SCE uses AIX as the underlying operating system software for the 4

UNIX computing environment. Our Enterprise Architecture principles require us to be no more than 5

one version behind the latest version in order to ensure we have continuous vendor support for this 6

essential software.18 7

In 2005, we acquired and installed Tivoli Configuration Manager, 8

which maintains automated records of our UNIX and Non-UNIX inventory that simplifies the record 9

keeping process and help ensure that we are in compliance with software vendor contracts for UNIX and 10

Non-UNIX based software tools. This mitigates unexpected costs and associated penalties due to 11

license non-compliance. 12

(b) Oracle Database 13

Oracle is a Relational Database Management System19 (RDBMS) 14

that is used by many critical SCE business applications. Oracle is our standard software for database 15

applications run on the UNIX platform. Oracle is used by a number of our critical applications. Oracle 16

is also used as a critical data store for SCE’s Enterprise Application Integration (EAI) technology, 17

Vitria. Due to the Data Center Optimization (DCO) program, Oracle subsystems were consolidated, that 18

allowed us to redeploy Oracle processor licenses for incremental growth in the current Oracle 19

applications and some new Oracle applications. In addition to DCO, the processor increases that we 20

have realized with the newer UNIX processors, have and will continue to allow SCE some redeployment 21

17 See SCE-5, Volume 2, Mainframe/UNIX Hardware, for discussion on UNIX servers. 18 Refer to Principle 6 in the Workpaper entitled “Enterprise Architecture Principles Extract for Southern California

Edison.” 19 A relational database management system is a program that lets you create, update, and administer a relational database.

Most commercial RDBMS's use the Structured Query Language (SQL) to access the database, although SQL was invented after the development of the relational model and is not necessary for its use. A relational database is a collection of data items organized as a set of formally described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables.

12

of Oracle licenses. New business applications will justify the purchase of new Oracle licenses as part of 1

their business cases. The ERP system will potentially slow the growth of Oracle business applications. 2

Any Oracle license growth will need to be justified as part of new application project costs. 3

(c) IBM Lotus Notes 4

Lotus Notes is considered a critical system to SCE because it is the 5

main electronic communication vehicle used by most employees to conduct their daily business. Key 6

computer applications supported by Lotus Notes include the Rate Case Management System, 7

Performance Planning System, Security Access Verification System, Grid Log, IT Operations Center 8

Daily Log, and others. Overall, there are approximately 1,400 individual Lotus collaborative services. 9

IBM issues periodic Lotus releases for various reasons. These 10

releases must be tested to ensure SCE’s latest Lotus release retains its internal integrity and remains 11

compatible with other SCE operating software products and systems. Lotus integrity and compatibility 12

cannot be sustained unless SCE remains current with version upgrades made available by IBM that 13

provide for “bug” fixes and required enhancements. SCE upgrades to major Lotus releases every 12-24 14

months. 15

SCE expects to spend approximately $8.9 million in 2010 to 16

purchase and install new technology to refresh its enterprise electronic messaging and collaboration 17

infrastructure. Because the maintenance of Lotus Notes will have been expired by 2010, these 18

expenditures are required to replace our messaging and collaborative infrastructure. In addition, the 19

need to integrate closely with the ERP/UNIX environment makes 2010 the logical time to replace these 20

infrastructure assets. This will enable SCE to streamline the integration of messaging and collaboration 21

functions with SCE’s core business applications. 22

The transition to the new infrastructure will require compatibility 23

testing because our existing messaging and collaboration environment, currently Lotus Notes, supports 24

many infrastructure services at SCE. Some of the areas that will require integration are: 25

• Identity management deployment used for consistent data 26

lookup, processing and reporting. 27

13

• Access to e-mail, calendar and instant messaging through a 1

standard corporate portal. 2

• Timely access to email and calendars through wireless 3

connections by field representatives. 4

• Enterprise document management system. 5

• Voice Over IP (VoIP) in order to facilitate access to e-mail 6

from the telephone. 7

In 2009, we will initiate strategic planning for the refresh of SCE’s 8

electronic messaging and collaboration infrastructure. SCE plans to complete all testing and resolve any 9

compatibility issues associated with the refresh of this infrastructure during this year. In 2010, we will 10

implement the rollout company-wide, that includes installation on enterprise production servers, 11

employee personal computers, and necessary employee training. 12

(d) Enterprise Platform Services Operating Software Refresh 13

In 2003, SCE took steps to refresh the operating software for the 14

UNIX computing environments in order to simplify and improve SCE business processes within the 15

computer systems environment. Functional capabilities that were refreshed during 2003-2006 in the 16

operating software environment include the following: 17

• Identity management - Several operating software 18

products have been acquired and implemented: 19

o that provide tools to manage user access and 20

identities, 21

o serve as the security and identity data repository for 22

newly-developed and deployed Web applications, 23

o that provide access to SCE’s applications based on 24

predefined rights for the different users, and 25

o connect to the identity data from other sources of 26

personnel identification throughout the company. 27

14

• Application Integration - Application integration has been 1

implemented through a series of changes to our current 2

methods. Several operating software products were 3

installed that provide for: 4

o inter-application communication, 5

o store the business rules for the process and 6

application interaction and characteristics of the 7

data being shared, and 8

o interface with SCE’s applications and infrastructure. 9


The following Table I-2 details SCE’s 2002-2006 recorded and 2006-2011 11

forecast expenditures for UNIX operating software by category. 12

Table I-2 UNIX Operating Software Expenditures By Category

2002-2006 Recorded and 2007-2011 Forecast (Nominal $000)

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

UNIX Operating Software & Middleware $1,034.5 $3,508.6 $10,252.6 $9,997.5 $4,525.9 $3,420.0 $0.0 $2,688.5 $6,259.8 $822.7IT Resource Optimization (ITRO) - Dynamic Server Provisioning/TPM $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $1,251.0 $1,250.0 $500.0 $0.0

Enterprise Configuration Management Tool/Processes $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $1,500.0 $0.0 $0.0Lotus Notes Upgrade (Work Space Integration) $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $8,857.8 $0.0

Total $1,034.5 $3,508.6 $10,252.6 $9,997.5 $4,525.9 $3,420.0 $1,251.0 $5,438.5 $15,617.6 $822.7

ForecastRecorded

SCE plans to expend $26.5 million on UNIX server operating software 13

during the forecast period 2007-2011.20 The table above depicts our 2002-2006 recorded and 2007-2011 14

forecast expenditures for this budget item. These expenditures include UNIX operating system 15

software, licensed from IBM, and operating software tools from independent software vendors. 16

In 2002, SCE spent $1.0 million for UNIX operating software. This 17

included a one time licensing fee to Sybase of $700,000, and $300,000 for Oracle license costs. 18

20 See Workpaper entitled “UNIX Operating Software & Middleware.”

15

In 2003, SCE spent $3.5 million for operating software licenses. A new 1

multi-year IBM license agreement accounted for $1.2 million, and another $2.3 million was spent to 2

convert our Oracle licenses to processor based licenses21 that provided for an unlimited number of users. 3

We eliminated previous restrictions of customers using it to access Oracle based systems from the 4

Internet. Oracle accommodated additional company-wide demand, such as providing our customers’ 5

access to the Rotating Outage Notification System and supporting SCE’s Energy Supply and 6

Management department. 7

In 2004, SCE spent $10.3 million on operating software, with $1.4 million 8

for additional licenses for Oracle database and $8.9 million for 1,000 user licenses of identity 9

management software, a five-year warranty and labor for its implementation, along with Vitria 10

integration software and implementation. As discussed earlier, Oracle is a critical database product used 11

to store and retrieve enterprise data on the UNIX platform. Additional licenses were acquired to 12

accommodate new applications and growth in existing applications. 13

In 2005, SCE spent $10.0 million, of which $1.7 million was spent to 14

acquire and implement Tivoli Configuration Manager software to enable SCE to assist in gathering 15

inventory of hardware components and applications residing on the UNIX servers. In addition, $2.0 16

million was spent to acquire a new version of the Vitria integration software. Additionally, we spent 17

$6.3 million for another 14,000 user licenses of identity management software, a five-year warranty and 18

labor for its implementation to provide these services for all SCE employees. 19

In 2006, SCE spent $4.5 million for storage management software, 20

additional database licenses and IBM Websphere licenses. Of this amount, $600,000 was spent on CA 21

BrightStor to allow SCE to monitor and analyze disk storage usage, produce trend analyses, identify 22

user-specific data storage usage for charge-back purposes, and monitor automated error logs to assess 23

failures in data base backups and the allocation of disk storage. Another $800,000 was spent to upgrade 24 21 The processor based licensing agreement, also referred to as an enterprise license represents the purchase of an unlimited

user license that does not depend on the number of users of each application. This allows for an unlimited number of applications to use the Relational Database Management software. However the cost for the license is based on the number of processor used versus number of users.

16

the Oracle licenses for our development environment. No additional Oracle licenses were required for 1

the production environment due to Data Center Optimization Program efforts in consolidating the 2

environment. Additionally, we spent $3.1 million for continued implementation of identity management 3

and enterprise application integration. 4

In 2007, SCE expects to spend $3.4 million for expanding the identity 5

management software licenses to 25,000 users with five-year warranty and continued implementation of 6

identity management. This includes coverage for all employees, and extends to SCE contractors and 7

retirees that need to access SCE systems. 8

In 2008, SCE expects to spend $1.3 million for licenses and 9

implementation of Tivoli Provisioning Manager (TPM).22 TPM will allow SCE to automate 10

provisioning, configuration and maintenance of physical and virtual servers, operating systems, 11

middleware, applications, storage and network devices acting as routers, switches, firewalls, and load 12

balancers. This will enable us to meet shorter response times in the implementation of new systems. 13

In 2009, SCE will spend $1.3 million for TPM to enable SCE to acquire 14

additional licenses for continued expansion. SCE will spend another $1.5 million to acquire and 15

implement configuration management database software licenses and begin the implementation of 16

enterprise configuration management in support of IT asset management.23 This is consistent with 17

industry practices, as defined by the IT Infrastructure Library. In addition, SCE will spend $2.7 million 18

for identity management licenses with five-year warranty and continued implementation for this service 19

to expand use to our customers and business partners to allow access to SCE internal systems from the 20

internet in a secure manner. 21

In 2010, SCE will spend $15.6 million on UNIX operating software. Of 22

this, $8.9 million is for a new version of messaging and collaboration infrastructure software, as 23

22 See Workpaper entitled “IBM Tivoli Provisioning Manager” for a description of the product. 23 For IT Infrastructure Library best practices regarding implementation of a Configuration Management Database, see

Workpaper entitled “ITIL and the CMDB: Better Service Management Equals Greater Business Value” published by the Enterprise Leadership Organization.

17

discussed in the IBM Lotus section above. If this upgrade is delayed, there would be an associated 1

significant increase in operation and maintenance costs. SCE also plans to spend $2.2 million for 2

additional Vitria licenses. This is driven by an increase in UNIX based applications that require a higher 3

level of integration with each other. In addition, we expect to spend $4.1 million for more identity 4

management licenses with five-year warranty. Of this, $1.4 million is for the refresh of licenses for 5

identity management operating software that were purchased in 2005. The remaining $2.7 million is for 6

licenses to enable expansion of service.24 The continued implementation of this service will allow us to 7

further expand to our customers and business partners needing access to SCE internal systems, along 8

with refresh of related operating software for enterprise platform services. Lastly, $500,000 will be 9

required to complete initial implementation of TPM. 10

In 2011, SCE will spend $822,700 on UNIX operating software for the 11

growth and use of additional software licenses for enterprise platform services. 12

c) Non-UNIX Operating Software 13

SCE plans to expend $26.4 million on Non-UNIX operating software during the 14

forecast period 2007-2011. Figure I-5 below depicts our 2002-2006 recorded and 2007-2011 forecast 15

expenditures for this budget item. These expenditures include Microsoft operating system software and 16

other operating software tools. 17

24 See Workpaper entitled “Draft Quote: Offering Type – Passport Advantage.”

18

Figure I-5 Non-UNIX Operating Software Expenditures 2002-2006 Recorded And 2007-2011 Forecast

(Nominal $000)

$0.0$1,000.0$2,000.0$3,000.0$4,000.0$5,000.0$6,000.0$7,000.0$8,000.0$9,000.0

$10,000.0

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Amount $0.0 $2,620.6 $8,752.4 $7,808.3 $702.6 $297.3 $5,315.1 $6,667.0 $8,129.8 $6,035.4

Recorded Forecast


Non-UNIX Operating software expenditures consist of the following 2

items: (a) upgrades to the IBM operating software; (b) upgrades to Microsoft operating software; (c) 3

upgrades to ISV software; (d) refresh of other Non-UNIX operating software; and (e) critical operating 4

software that support the enterprise platform services. The Non-UNIX server environment supports key 5

business processes that include communications and data sharing (through the use of electronic mail and 6

“web” based applications), tracking of customer call volumes used to plan for the staffing of customer 7

service representatives, computer applications that support Energy Procurement, the system used for 8

collecting and aggregating meter wage data, and others. 9

(a) IBM Licenses 10

SCE acquired a series of products from IBM for managing the 11

Non-UNIX server environment. These include Tivoli Storage Manager (TSM) for managing the backup 12

19

of personal computer data and server databases, as well as a refresh of our IBM Lotus Notes 1

collaborative software. 2

(b) Microsoft Enterprise License 3

Beginning in 2008, SCE will renew our enterprise license 4

agreement to continue to obtain volume discounts. In 2006, the decision was made to not renew the 5

existing Microsoft Enterprise Agreement. This was due to the upgrade schedule of the products covered 6

by this agreement. We use Microsoft software products25 to support the Non-UNIX server and personal 7

computer environments, of that there would not be a new release of some of these products until late 8

2007 or 2008. Non-UNIX server products include the Microsoft Enterprise server operating system 9

software and the Microsoft SQL server database tool. The Microsoft Enterprise server operating system 10

software allows us to control the daily operations of all Non-UNIX servers. The personal computer 11

products include new operating system and office tool suite. Although personal computers are not 12

considered Non-UNIX hardware, we have included these products here because they will be included in 13

the same enterprise license agreement. 14

(c) Independent Software Vendor Software Upgrades 15

SCE employs a number of ISV tools in the Non-UNIX server 16

computing environment. We acquired operating software to manage our shared disk storage (called 17

Storage Area Network software), that enabled SCE to maximize disk storage utilization by doubling the 18

effective utilization from 2002 to 2006. We also acquired Isogon’s SoftAudit that enabled SCE to audit 19

servers to ensure we are in compliance with software vendor contracts. These vendor contracts have 20

significant penalties for failure to monitor the deployment and usage of their products. 21

(d) Enterprise Platform Services Operating Software Refresh 22

In 2003, SCE took steps to refresh the operating software for the 23

Non-UNIX computing environments in order to simplify and improve SCE business processes within 24

25 See Workpaper entitled “List of Microsoft Products.”

20

the computer systems environment. Functional capabilities that were refreshed during 2003-2006 in the 1

operating software environment include the following: 2

• Enterprise portal - The Portal operating software was 3

implemented using a series of operating software products 4

used to store and manage portal information, host the 5

portal, and create and publish content to the portal. 6

• Integrated development environment - SCE 7

implemented various software products as part of the 8

integrated development environment. The software was 9

installed for the purpose of analysis, design, development, 10

testing and migration of application systems. Software was 11

also purchased for the purpose of configuration 12

management, to hold and share software components and 13

for the purpose of running Java based application 14

components at run time. 15


The following Table I-3 details SCE’s expenditures for Non-UNIX 17

operating software by category for the years 2002-2011. In the period 2002-2006, SCE recorded 18

expenditures of $19.9 million. SCE plans expenditures of $26.4 million for the forecast years 2007-19

2011.26 20

Table I-3 Non-UNIX Operating Software Expenditures 2002-2006 Recorded And 2007-2011 Forecast

(Nominal $000)

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Non-UNIX Operating Software & Middleware $0.0 $2,620.6 $8,752.4 $7,808.3 $702.6 $297.3 $1,815.1 $1,167.0 $2,629.8 $535.4Microsoft Enterprise Agreement - Server $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $3,500.0 $0.0 $0.0 $0.0Microsoft Enterprise Agreement - Vista, Windows $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $0.0 $5,500.0 $5,500.0 $5,500.0

Total $0.0 $2,620.6 $8,752.4 $7,808.3 $702.6 $297.3 $5,315.1 $6,667.0 $8,129.8 $6,035.4

Recorded Forecast

26 See Workpaper entitled “Non-UNIX Operating Software & Middleware.”

21

In 2003, SCE incurred $1.1 million in license fees for Tivoli Storage 1

Manager from IBM to implement data recovery for our Windows personal computers and $1.0 million 2

in capital expenditures for the first year of a multi-year contract with Microsoft for Non-UNIX operating 3

software licenses. Prior to 2003, Non-UNIX operating software would have been included in the cost of 4

Non-UNIX hardware. SCE also spent $465,000 on ISV software to help with disk sharing among Non-5

UNIX servers to increase disk storage utilization. 6

In 2004, SCE spent $2.4 million to acquire Isogon’s SoftAudit and a 7

second year of a Microsoft multi-year contract to refresh of all our Non-UNIX operating systems. SCE 8

also spent $6.3 million to purchase Plumtree software with a five-year warranty, Microsoft content 9

management software with a five-year warranty, and associated labor for implementation of an 10

enterprise portal. In addition, we acquired additional Non-UNIX operating software licenses in order to 11

service the additional servers required to accommodate application growth.27 12

In 2005, SCE spent $4.4 million that included the last of the Microsoft 13

multi-year contract cost for refreshing all of the Non-UNIX server operating systems. In addition, we 14

refreshed Lotus Notes collaborative software with a newer version that contained additional messaging 15

and calendaring enhancements. SCE also spent $3.4 million for acquiring IBM’s Rational software with 16

five years of warranty for managing all software development activities, Logidex software with five 17

years of warranty to store and manage software components and the labor costs associated with 18

implementation of this operating software. 19

In 2006, SCE spent a total $702,600 for Non-UNIX operating software. 20

This included $420,000 for CA BrightStor operating software that enabled us to manage disk storage 21

allowing us to improve disk space storage utilization. SCE also spent $282,600 for Microsoft’s System 22

Management Server operating software that enabled us to manage and control the distribution and 23

application of operating software patches. 24

27 Refer to SCE-5, Volume 2, Non-UNIX Hardware.

22

In 2007, SCE will spend $297,300 on operating software for Non-UNIX. 1

This will include $100,000 for additional Microsoft SQL Server database licenses to accommodate 2

application growth for non- ERP systems. An additional $197,300 will be spent for IBM Tivoli 3

Provisioning Manager to enable us to dynamically allocate Non-UNIX computing and network 4

resources for business applications.28 5

In 2008, SCE will spend $5.3 million, of that $3.5 million is to renew our 6

Microsoft Enterprise Agreement for Non-UNIX software to cover license and warranty cost.29 We also 7

plan to spend $650,000 to further enhance our ability to track software installed on Non-UNIX servers 8

to ensure software license compliance and $325,000 on a software tool to improve server configuration 9

management. In addition, SCE plans to spend $300,000 on an operating software product to manage 10

computer application program code for SCE.com and $300,000 to further enhance Web monitoring and 11

debugging tools, due to SCE’s increased dependence on web applications. SCE’s current Web 12

monitoring and debugging tools are technologically obsolete and need to be enhanced with the latest 13

technologies that include individual transaction monitoring and playback, real-time transaction response 14

time statistics, and component level health measurement. Last, SCE plans to spend $230,000 to procure 15

additional licenses for SQL Server Database and Tivoli Storage Manager, due to an increase in the 16

number of Non-UNIX servers needed to support new non-ERP applications. 17

In 2009 through 2011, SCE plans an expenditure of $5.5 million per year, 18

for a Microsoft Enterprise agreement to provide software for 19,00030 personal computers. Although 19

personal computers are not considered Non-UNIX hardware, we have included this expenditure here 20

because the same agreement listed in the 2008 forecast will also address the software for these 21

computers. This software will include: 22

• Microsoft Office Suite, the new Vista operating system. 23

28 See Workpaper “IBM Tivoli Provisioning Manager” for a description of the software. 29 Refer to discussion on Microsoft Enterprise Agreement above in Basis for Expenditures. 30 Refer to SCE-5, Volume 2, PCs Desktop/Laptop Refresh and Ruggedized Laptops regarding standardization of our

desktops and laptops.

23

• Client Access Licenses, required to allow personal computers to 1

communicate with a Microsoft server. 2

• Microsoft Developer Network, a subscription package whereby 3

developers have access and and are licensed to use any required 4

Microsoft software in their development efforts. 5

We will spend $1.2 million in 2009 and $2.2 million in 2010, as well as 6

$535,400 in 2011 for critical application support tools to improve monitoring, debugging, and 7

availability management capabilities. 8

In 2010, SCE will expend $452,500 to refresh the operating software for 9

enterprise platform services. 10

(a) ERP Benefits 11

The following summary of Operating Software costs reflects the 12

expenditures (2013 and going forward) that would be incurred in this area if the ERP system were not to 13

be implemented. 14

24

Figure I-6 ERP Benefits

2013 – 2016 Forecast (Nominal $000)

$0.0

$200.0

$400.0

$600.0

$800.0

$1,000.0

$1,200.0

$1,400.0

$1,600.0

$1,800.0

2013 2014 2015 2016

E R P A voided E xpenditures 2013 2014 2015 2016

M ainfram e O perating Softw are & M iddlew are - C SS R eplacem ent D eferral to 2013

$1 ,554.4 $855.5 $855.5 $1,553.4

The Mainframe Operating Software expenditures previously 1

planned for during the 2005 annual budgeting process, totaling $5.0 million, were for the acquisition of 2

additional automation and monitoring tools to maintain the effective utilization of mainframe computer 3

resources. The ERP system is expected to replace this mainframe environment as the ERP applications 4

will be rolled out in the UNIX environment associated with the Release 4 deployment in 2013. As a 5

result of ERP, we will avoided incurring these expenditures. 6

4. Conclusion 7

Operating Software provides several necessary capabilities. First, operating software 8

improves management and utilization of IT assets. Second, operating software enhances control over 9

computer applications and databases that is increasingly important as we rely more and more on 10

25

computer systems to support routine business operations. Third, such software is becoming more 1

indispensable as our technology environment grows more complex – operating software and related 2

tools help us mange this environment by automating some of the necessary governance functions. This 3

type of software is used on all the three major SCE computing environments, namely mainframe, UNIX, 4

and Non-UNIX environments. The expenditures requested here are based on the need to better manage 5

computing resources as they grow in size and complexity, while mitigating the ongoing potential risk to 6

critical business functions due to technology obsolescence. In addition, the implementation of these 7

tools will enable us to mitigate incremental increases in operations and management cost. 8

26

II. 1

SOFTWARE ASSET MANAGEMENT 2

A. Introduction 3

The purpose of this chapter is to describe our Software Asset Management (SAM) process for 4

SCE’s computer software business applications.31 Although we have always managed our portfolio of 5

applications, the SAM process was formalized in 2004 to ensure that our portfolio of software assets are 6

managed in a proactive and integrated way, such that decisions to replace or upgrade specific software 7

applications are based on consistently sound analysis and prioritization. The SAM process proactively 8

manages SCE’s existing portfolio of software applications in a more predictable manner to mitigate risks 9

due to security problems and failure as a result of technology obsolescence. 10

SAM introduces a systematic and disciplined approach for the continuous assessment and 11

remediation of aging software applications, including replacement and retirement when appropriate, 12

while minimizing business risk. The primary objectives of SAM are to: (1) reduce business risk by 13

ensuring the application portfolio has the appropriate technology updates needed to mitigate information 14

security exposures, and (2) reduce business risk resulting in application failures resulting from outdated 15

or unsupported vendor technology. 16

B. Our 2009-2011 Software Asset Management Request Excludes Projects Within The Scope 17

Of Enterprise Resource Planning 18

The SAM Capitalized Software testimony for the 2006 GRC justified replacing a portion of the 19

aging application portfolio with updated applications in furtherance of the SAM objectives.32 The vast 20

majority of the applications identified in the 2006 GRC as candidate software projects to be upgraded or 21

replaced have been subsumed within SCE’s ERP Project.33 Based on the systems needs, the ERP 22

Project represents SCE’s deliberate and prudent prioritization of the 2006 GRC SAM funding. 23

31 The terms computer software, systems, and applications are used interchangeably in this testimony. 32 Refer to 2006 GRC, Exhibit 59, SCE-5, Volume 3, Software Asset Management, pp. 154-246. 33 See SCE-9 ERP for additional details. As noted in this Exhibit, the scope of ERP covers the SAM software projects

identified in our 2006 GRC, as well as additional processes and applications.

27

Although the ERP Project will replace approximately 50 percent of the existing application portfolio, the 1

remaining applications must continue to be proactively managed to mitigate business risk from security 2

and application failures. Thus, this SAM testimony concerns the remaining applications and proposed 3

candidate software projects from 2007 through 2011. This request for SAM funding will include the 4

remediation of applications that are considered outside of the ERP system capability based on the 5

blueprinting work from the ERP Project34 and will not be replaced through the current ERP Footprint. 6

However, this does not preclude SCE from using components of the ERP system in the future to create 7

new applications to replace the legacy applications that are outside of the current ERP Project 8

functionality. 9

C. Software Asset Management Of Applications Outside ERP Footprint 10

1. Overview Of Software Asset Management 11

In this testimony, we address the projected systems obsolescence that will expose SCE to 12

significant risks if not remedied. Our SAM process manages our software assets as a portfolio, instead 13

of one-by-one, such that decisions to replace or upgrade specific obsolete software applications are 14

based on sound analysis and prioritization across the entire portfolio. The SAM process proactively 15

manages SCE’s existing application portfolio35 in a predictable manner to mitigate security risks and the 16

risk of failure as a result of technology obsolescence. Our long-term SAM vision, approach, and 17

methodology are consistent with good business practices for technology and software assets.36 18

SCE’s application portfolio affects nearly all aspects of utility operations. Our software 19

applications are an integral part of our business operations, and are necessary to deliver service to our 20

4.8 million customers. These software applications are as valuable and vital to utility operations as 21

many of SCE’s more tangible utility assets such as poles and transformers. 22 34 See SCE-9 ERP for details regarding the scope of applications being replaced as part of the Enterprise Resource Planning

(ERP) Project. 35 The term “application portfolio” is used to refer to all of our business application software systems. 36 See Workpaper entitled “Gartner-Key Issues for Platform and Application Modernization, 2007.” See also “IT Portfolio

Management Step-by-Step” by Bryan Maizlish and Robert Handler, John Wiley & Sons, Inc. 2005. See also, Corporate Executive Board - Application Executive Council, “Edison International: Continuous Applications Portfolio Fortification.”

28

As with most enterprises, our software application portfolio has grown in size and 1

complexity. The major drivers for SCE’s changes have been responding to new regulatory 2

requirements, integrating enterprise-level business processes end-to-end, and implementing new 3

technology capabilities. Our current application portfolio has grown to 630 applications and the 4

complexity as a measure of the number of function points,37 has increased as we enhance or replace 5

older applications, or implement new applications in response to business needs. Our portfolio includes 6

applications that span 18 programming languages used to create applications, nine operating systems 7

needed to run applications, and 15 database platforms used to store information. They are maintained in 8

over 35 application environments to provide services tailored to the various applications. 9

Such diverse and disparate technologies in these systems require costly integration points 10

where the different applications are linked to facilitate sharing of the information across business units. 11

SCE’s integrated ERP system will help mitigate the need for complex integration points for the 12

approximately 316 applications within the ERP footprint. The complexity of integration, however, still 13

exists for the remaining applications that are not part of the integrated ERP system. Our SAM approach 14

focuses directly on managing our existing investment as a portfolio of software assets.38 The proposed 15

SAM approach will also leverage the standardized integration capabilities to be provided through 16

Enterprise Technology Services (ETS) to enable information sharing as part of application 17

remediation.39 The SAM projects will also require the Integrated Test Environment (ITE) for 18

integration testing for applications with data interfaces to ERP applications and application in major 19

programs such as MRTU.40 20

37 First made public by Allan Albrecht of IBM in 1979, the FPA technique quantifies the functions contained within

software in terms meaningful to the software users. For additional reference, please see the International Function Point Users Group website: http://www.ifpug.org/.

38 For additional details about the stages of portfolio management, see “IT Portfolio Management Step-by-Step” by Bryan Maizlish and Robert Handler, John Wiley & Sons, Inc., 2005, pp. 42-46.

39 See SCE-5, Volume 3, Enterprise Technology Services for additional details. 40 See SCE-5, Volume 3, Integrated Test Environment for additional details.

29

Software assets suffer from the same phenomenon of age-related degradation as do many 1

of our assets such as poles, wires and transformers. The age of software assets is a key driver for 2

technology obsolescence due to Moore’s Law, which states that computers double in speed every 24 3

months.41 This has a profound effect upon application technology, as application technology can 4

exploit the faster computers by building software applications that utilize the increased computing 5

capacity. However, such advances also make the older applications in the portfolio more obsolete and 6

unable to keep up with the computer advancements. These technological advances also make an aging 7

portfolio more vulnerable to security risks or failure to operate because software vendors limit their 8

support and patch updates to their more recent product versions that are more compatible with the newer 9

technologies. 10

Technology obsolescence has varying degrees of risk associated with it. An application 11

that is not critical to the business or can be easily and quickly remediated would be considered “low 12

risk.” An obsolete application that poses an immediate security threat to the entire enterprise would be 13

considered “high risk.” All risk of obsolescence is ranked in importance by its potential cost to the 14

business (i.e., what is the cost and impact to the business of application failure). However, technology 15

obsolescence and the risks associated with information security exposures are closely related. Obsolete 16

technology no longer supported by the vendor will not receive the latest software updates and patches 17

that are required to stay current, mitigating exposures to things like computer viruses and system 18

weaknesses that can be exploited by computer hackers. 19

Approximately 60 percent of our applications have varying degrees of obsolescence due 20

to technology or vendor support issues, or as a result of the inability for the existing applications to meet 21

changing business needs. Generally, older applications are more obsolete. Presently, more than 12 22

percent of the applications outside the ERP Footprint are more than 10 years old, and the situation will 23

only get worse if not addressed. Within the next five years, more than 70 percent of the applications in 24

41 In 1965, Intel co-founder Gordon Moore noted, what is now popularly known as Moore's Law, that the number of

transistors on a chip doubles about every two years and that the chip speed is proportional to the number of transistors, regardless of what they do. See Workpaper entitled “Moore’s Law.”

30

SCE’s portfolio outside of the ERP Footprint would age to 10 years or older if there was no SAM 1

process to replace obsolete or imminently-obsolete applications (see Table II-5). Older applications are 2

more susceptible to obsolescence due to technology changes and discontinued vendor support, which 3

leads to greater risks of failure. Continued modification of older applications makes them more complex 4

and further introduces greater chance for error. The risk of losing service due to failure or security flaws 5

is the primary concern of our SAM process. Through the systematic replacement and optimization42 of 6

these older assets, over time we will reduce the obsolescence risks associated with older assets. 7

2. Software Asset Management Mitigates Risk 8

The overall goal of Software Asset Management is to maintain the current level of system 9

availability, usability and reliability required to support the needs of our customers and comply with our 10

regulatory mandates. Absent a disciplined and regular process to manage the portfolio, these critical 11

conditions will deteriorate and create increasing levels of risk. Our approach takes maximum advantage 12

of advances in information technology, as well as improvements in vendor offerings, while taking into 13

consideration the aggregate age and performance risk profile of our existing portfolio. 14

Obsolescence of older software applications is a primary driver of risk. As the 15

computing environment changes over time, software technology for a particular application may become 16

obsolete and may further affect other applications that depend on that application through complex 17

interfaces. Although age is only one indicator, it provides the first level of screening to identify areas at 18

risk within the SAM framework. For example, we are currently running older versions of computer 19

software that are no longer supported by their respective vendors. If new security flaws are discovered 20

in the vendor software and guaranteed patches are not available, we have no ability to upgrade our 21

software to mitigate the potential threat. This security risk is unacceptable and jeopardizes critical 22

systems necessary to operate the business. 23

The SAM process reduces business risk by ensuring the application portfolio has the 24

appropriate technology updates needed to mitigate information security exposures. This approach also 25 42 “Optimization” refers to the enhancement or modification of an application to resolve any technical or business

deficiencies, which would extend the life of that application.

31

reduces business risk by ensuring the applications within the portfolio do not rely on out-dated or 1

unsupported technology, which can lead to application failure. 2

a) Risks 3

Software systems and applications have become critical to nearly all parts of 4

SCE’s business. The loss of the support provided by software systems would have a direct, immediate 5

and significant impact on SCE’s operations. Although not directly part of the ERP system, should these 6

applications fail, they could have a direct impact on the applications within the ERP system. Specific 7

examples of system failures that would directly impact our day-to-day operations include failures to any 8

of the applications outside of the ERP Project scope that interface with our customer service, work 9

management, or dispatch applications, which would remove our ability to perform scheduled “turn-ons” 10

and “turn-offs” of energy services to our customers (e.g., the Outage Management System). Another 11

example would be failures in our power bidding or energy purchasing systems, which would impede our 12

ability to effectively acquire or trade energy on behalf of our customers (e.g., Energy Purchasing System 13

EPS-A). 14

A way of quantifying the risk is from a cost-avoidance perspective relative to the 15

financial impact to the company for a situation where an application fails because of technology 16

obsolescence. A loss of service can result in significant cost impacts to all parts of the company. For 17

example, when our Transmission and Distribution Business Unit (TDBU) loses critical systems (such as 18

the Outage Management System) for one day, it results in significant scheduling delays with significant 19

additional cost to the company because of resulting overtime costs. Similarly, in the event that our Call 20

Center systems were down, we would have to revert back to manual processes which would greatly 21

impact our customers with longer wait times on the phone. 22

Although age of the application portfolio is often discussed as a significant 23

indicator of risk, the more important consequential indicator we must analyze is the risk associated with 24

not being able to maintain or support a particular application (or group of applications) that deliver a 25

specific service to our business units, customers, regulators or our shareholders. With regard to 26

technology and vendor-related obsolescence, there is a direct relationship between age and risk. Major 27

32

software vendors, such as IBM and Microsoft, publish their software support lifecycles for software 1

availability and end-of-support dates.43 For example, to estimate the earliest possible end-of-support 2

date for an IBM software version or release, IBM recommends that its customers add three years to the 3

general availability date and then use the next April or September, whichever comes first. In addition, 4

industry practice advises staying within two versions of the currently-available product in order to 5

ensure support from the vendor and to evaluate upgrade opportunities every 18-to-24 months.44 Using 6

these guidelines, it is more than likely that, on average, the software vendor will cease providing support 7

after two versions, or approximately six years. For this reason, the SAM process focuses on applications 8

in the portfolio that are six years or older as potential candidates for replacement or optimization. 9

(1) Technology Obsolescence 10

Technology obsolescence results when the underlying technology that an 11

application uses is identified by the vendors to be phased out (no longer approved for use). The reasons 12

for the obsolescence include, but are not limited to: 13

• Security reasons (e.g., security flaws); 14

• Unstable technology platform (e.g., unreliability);45 and 15

• Operating system changes (e.g., obsolescence resulting in 16

applications not compatible with a new operating system). 17

(2) Vendor Obsolescence 18

Vendor obsolescence results when a Commercial-Off-The-Shelf (COTS) 19

application is no longer supported by the vendor, including version obsolescence. The reasons for 20

vendor obsolescence include, but are not limited to: 21

• SCE must keep pace with vendor software upgrades to COTS 22

packages in order to receive security and/or technology 23

43 See IBM Software Support Lifecycle at http://www-306.ibm.com/software/support/lifecycle/ or Microsoft support

Lifecycle Index at http://support.microsoft.com/gp/lifeselectindex for software end of support information. 44 See Workpaper entitled Gartner Research “Justifying Business Application Software Maintenance Fees,” June 21, 2004. 45 Windows 95 is one example of an unstable technology platform.

33

capability upgrades, which will guarantee support when vendor 1

software bugs are encountered (e.g., installing the COTS 2

version that is compatible with technology upgrades for the 3

Oracle Relational Database Management System are required 4

in the COTS maintenance contract);46 5

• The vendor no longer supports a specific technology (e.g., 6

Windows NT 4.0); 47 7

• The vendor changes technologies to a platform that SCE does 8

not support. 9

(3) Business Obsolescence 10

In order to effectively manage the overall workload, business 11

obsolescence is used as a tie breaker in deciding project priority when comparing one application to 12

another that have equal technology and vendor obsolescence. Business fit problems or obsolescence 13

occurs when the application no longer adequately supports the business function for which it was 14

initially built or purchased, because: 15

• New business requirements make the current application 16

obsolete; 17

• Formerly self-contained business processes (within individual 18

business units) are now required to cross enterprise business 19

processes (e.g., procurement to settlement). This has resulted 20

in multiple hand-offs, which cause data integrity and 21

synchronization problems; or 22

46 Periodic major releases from Oracle are required by the manufacturer in order to guarantee support. 47 Windows NT 4.0 operating system from Microsoft is no longer supported nor has security patches. See Workpaper

entitled “Microsoft Support Lifecycle.”

34

• External entities require specific levels of technology for 1

secure and reliable interfaces (e.g., the California Independent 2

System Operator’s interfaces with SCE’s systems). 3

b) Risk Summary 4

Table II-4

Applications Not In The ERP Footprint Subject To Category Of Risk

Total Number of Applications Not in ERP Vendor Technology Business Fit Total

Corporate Center 42 2 10 2 14CSBU 25 13 8 4 25GBU 29 2 5 1 8HR 16 2 6 0 8Operation Support 16 7 8 1 16OTHER 88 9 23 5 37PPBU 19 2 2 2 6TDBU 74 18 38 5 61

Totals 309 55 100 20 175Percentage 18% 32% 7% 57%

Number of Applications at Risk by CategoryBusiness Unit

As can be seen from the above table, our detailed analysis identified a number of 5

risk factors that are directly associated with the approximately 300 applications that are not in the ERP 6

Footprint. Several of the applications necessarily have more than one risk assigned to them. For 7

example, the “Wholesale Energy System” within PPBU (installed in 1996) is considered to be obsolete 8

both in terms of technology and in terms of a “business integration/business fit” perspective. The 9

application poses a major risk if it fails to operate because it manages, tracks and processes Qualified 10

Facilities payments, contract compliances, and contract documents. Thus, this is considered to be a 11

high-risk application because its function is critical and the existing software is older and obsolete, 12

posing higher risk of failure. 13

A closer analysis of our applications (as outlined in the Table II-5 below) 14

demonstrates that 57 percent of our total application portfolio outside of the ERP Footprint requires 15

attention due to some form of obsolescence. The data in this table show that our risk of obsolescence 16

increases as applications age. The analysis shows that almost two-thirds of the application portfolio 17

outside of the ERP Footprint is six to fifteen years old, which is also where the majority of obsolete 18

35

applications exist (128 of the 176 obsolete applications). Although not all risks are equal or imply 1

imminent failure, the overall trends must be addressed proactively. By acting before we allow the 2

applications or groups of applications within the portfolio to age to the point where they actually fail, we 3

will prevent the type of large system “emergencies” that require massive infusion of time, effort, and 4

funding to solve. 5

Table II-5

Number Of Applications Not In The ERP Footprint At Risk By Application Age

Business Unit < 6 Years 6-10 Years 11-15 Years > 15 Years TotalsFunction Point

CountCorporate Center 24 12 4 2 42 30,615CSBU 10 10 3 2 25 15,493GBU 3 20 6 0 29 71,082HR 6 9 1 0 16 3,730Operations Support 4 11 0 1 16 5,348PPBU 6 81 0 1 88 42,994TDBU 9 9 1 0 19 73,158OTHER 33 25 9 7 74 46,582

Age Totals 95 177 24 13 309 289,002Age Percentage 31% 57% 8% 4% 100%

Number of Obsolete Applications within Age Group

37 112 16 11 176Percent of Obsolete Applications within each Age Group

39% 63% 67% 85% 57%

Applications Sorted by Age Group

The risks of not maintaining an active Software Asset Management program are 6

significant. If we were to manage our software portfolio without proactive replacement or refreshment, 7

that failure to act timely would lead to significantly-increased risk of security and application failure due 8

to: (a) the continuing growth and integration of our software portfolio; (b) the aging of legacy48 9

applications outside the ERP Footprint (approximately 300 applications not being replaced by ERP); (c) 10

increased security concerns; and (d) a dynamic regulatory environment with ever-changing requirements 11

that often necessitate IT solutions to comply. 12

Foregoing Software Asset Management would lead to a decline in service to the 13

business units that directly provide service to our customers. This decrease in support will occur as 14

48 The term “legacy” refers to a large, older system that is difficult and expensive to maintain and modify.

36

custom-developed application solutions take longer to put in place (due to the complex requirements 1

needed to accommodate non-compatible obsolete technologies) and errors in data become more 2

prevalent due to the complexity. No matter how much testing is done, a small enhancement to an aging 3

system may have negative impacts to other applications connected to that system because the older 4

applications rely on outdated technology that is inherently more difficult to integrate with newer 5

technology. 6

In recent years, we have faced undue delays in implementing technology solutions 7

simply because our older technologies were not compatible with the newer technologies we were trying 8

to implement. For example, in 2004 SCE needed to upgrade the load survey tool with additional 9

information from our customer service system. Our then-current software did not have the capability to 10

provide this information in a reliable and automated fashion. We had to upgrade the underlying 11

information-sharing software to implement the new load survey application. This significantly 12

increased the effort and cost, because we were forced to create manual workarounds that satisfied the 13

business need in a timely manner, while waiting for the delayed implementation of the new system. 14

As indicated above, 12 percent of these applications are more than 10 years old, 15

and this figure will climb to more than 70 percent over the next five years. In many instances, the 16

original business rules on which the systems were based have changed and new rules have evolved since 17

the original design. Further, 57 percent of our applications outside of the ERP Footprint are facing some 18

form of obsolescence. The additional effort to maintain aging applications tends to divert the attention 19

of SCE IT experts that are needed to bring new applications on-line to support emerging business 20

problems (e.g., mandated programs to support new and urgent regulatory and security requirements). 21

As applications age and do not keep pace with technological advances, an 22

additional risk is created as the knowledge about our older applications and their interfaces to other 23

applications often lies with SCE employees approaching retirement. Once these employees (and 24

knowledge) leave SCE, it will be much more difficult and expensive to prudently manage these 25

applications. Although our IT staffing model is flexible and we have the ability to acquire additional 26

technical services, we have limited access to staff with in-depth knowledge of our business. It requires 27

37

significant lead-time to develop IT staff with business knowledge sufficient to draw on as “subject 1

matter experts.” 2

Moving toward greater use of commercial software packages to replace obsolete 3

systems will assist in alleviating this knowledge gap and mitigating the age-bubble issues of retiring 4

subject matter experts. Using COTS applications leverages the power of these packages and transfers 5

much of the security and reliability responsibilities to vendors. Unlike custom applications developed 6

in-house, software maintenance and improvements for COTS applications are driven by all licenses of 7

the software instead of borne merely by SCE. As with any large enterprise, SCE can only effectively 8

manage a certain magnitude of change (within a set timeframe) and still run the day-to-day business. 9

The systematic ongoing activity of a Software Asset Management process helps to plan, prioritize, and 10

spread out the necessary changes over time. 11

Finally, it is essential that SCE possess the capability to interact with applications 12

used by our customers and suppliers. SCE can use the technology and business offerings provided by 13

major customers and suppliers – such as “just-in-time” inventory management and electricity 14

procurement and sales. In addition, SCE must comply with various regulatory requirements to make 15

information readily available to the public. For example, a recent FERC regulation (FERC 2004 16

Standards of Conduct) mandates that we possess up-to-date information and allow public access to 17

certain information detailing the separation of information between transmission and power-purchasing 18

organizations. 19

3. Software Asset Management Process 20

The SAM process identifies three primary application portfolio remediation49 actions that 21

can be used depending on the state of obsolescence. These three types of remediation include, in order 22

of priority or importance: 23

• Optimization – enhancing the application or group of applications to more 24

effectively support the current processes. 25

49 Whenever we refer to application “remediation” or “refresh” we mean optimization, replacement, or retirement.

38

• Replacement – replacing the application or group of applications when 1

optimization is no longer cost-effective. 2

• Retirement – eliminating the application or group of applications at the end 3

of their useful lives. 4

SAM consists of five primary activities and governance which are illustrated in the SAM 5

Operating Model as shown below in Figure II-7. Additional details of the activity sub-processes are 6

found in the accompanying workpapers.50 7

Figure II-7 SAM Operating Model

1 2 3 4 5

The SAM Operating Model consists of a central Governance activity and five core 8

processes, summarized briefly below: 9

a) SAM Governance 10

SCE management assures an overall validation and oversight of the SAM project 11

selection, prioritization, and funding processes. “Governance” addresses the operational and decision 12

making requirements for the different roles that are part of the SAM execution process. SAM 13

governance includes: (1) developing and managing controls to identify, prioritize, and approve software 14

asset portfolio remediation initiatives, and (2) coordinating and managing the portfolio remediation 15

selection process. 16

50 See detailed processes in Workpapers entitled “SAM Operations Manual March 2006.”

39

b) Portfolio Optimization Analysis Process 1

The application portfolio is analyzed on an annual basis using our well-defined 2

technical obsolescence criteria to determine the opportunities for application portfolio optimization, 3

replacement, or retirement. The technical criteria include application age, application size, and the use 4

of obsolete technologies. Technology obsolescence is defined as all types of purchased software that is 5

no longer supported by the vendor,51 including version obsolescence. The SAM processes remediate 6

purchased applications that are no longer vendor-supported and custom applications that rely upon 7

obsolete systems software (e.g., operating systems, code generation tools, etc.). 8

As part of this annual process, the business units that use these applications in the 9

course of their operations are responsible for analyzing the applications for business obsolescence by 10

generating a business fit score for each application within their portfolio. 11

A combined team from IT and the business units analyzes all the information and 12

generates lists of the most urgent and critical of the obsolete applications or group of applications within 13

the portfolio. The portfolio technology obsolescence metric is the leading indicator of portfolio 14

performance.52 Technology obsolescence is given priority over business obsolescence because of the 15

risk of failure. A sorted list of potential SAM projects is created for each business unit that is based 16

upon the ranking the combined business and technical obsolescent criteria scores from high to low. The 17

SAM Core Team53 combines all business unit lists into a single enterprise list as input to the 18

Assessment and Alignment Process. Because this analysis is conducted annually, all changes to the 19

application portfolio, regardless of source, will be analyzed. 20

51 “Vendor Support” is defined as the timeframe from a product’s general availability to the published date that a vendor

will no longer support their product by providing advice and/or providing corrections and patches to the software code. 52 The application technology obsolescence is scored in four areas by the business units. See the technology assessment

model in the Workpapers entitled “Edison International: Continuous Applications Portfolio Fortification.” 53 The SAM Core Team is the senior group of IT professionals responsible for the SAM program.

40

c) Project Assessment, Alignment And Ranking 1

The proposed SAM projects are assessed and then ranked in relation to all the 2

other proposed work that would affect the application portfolio to ensure that SAM goals are met, 3

whether as stand-alone SAM projects or by business unit or enterprise initiatives. 4

In this process, the SAM Core Team conducts an assessment of all external (i.e., 5

not generated by the SAM Core Team) projects and initiatives for potential SAM impacts. For example, 6

a business unit may be proposing a new software system that could either be for new capabilities or to 7

replace an older system that no longer meets the business needs. The assessment process will help 8

identify the latter category to evaluate such projects against projects identified by the SAM Portfolio 9

Optimization Analysis. The team then aligns the external (business unit) list with the internally-10

developed list by comparing the degree to which each project advances the SAM goals. This ensures 11

that IT uses the SAM funding and resources in the most effective manner. The output of the Assessment 12

and Alignment Process is a single list of potential SAM projects containing both internally-generated 13

projects as well as those identified by the business units. This list is then ready for the next step called 14

ranking. 15

In the ranking activity, the SAM Core Team scores the potential SAM projects 16

from the Assessment and Alignment Process using the SAM Scoring Model.54 This includes both the 17

SAM projects identified in the Portfolio Optimization Analysis phase and those enterprise and business 18

unit projects identified in the Assessment and Alignment Process that remediate portfolio obsolescence. 19

After all projects are scored, the results are summarized into a central list using the SAM Ranking 20

tool.55 Subsequently, the SAM Core Team, in collaboration with the business unit, evaluates the list of 21

projects using the score obtained in the previous activity to validate and correct any errors. The output 22

of this activity is a ranked list of potential projects. 23

54 The SAM Scoring Model is a template spreadsheet that assigns weights to SAM criteria to determine a relative ranking

for projects. A sample of the model is in Appendix A2 of the accompanying Workpapers entitled “SAM Operations Manual March 2006.”

55 The SAM Ranking tool is a spreadsheet application. A sample of the tool input screen can be found in Appendix A3 of the accompanying Workpapers entitled “SAM Operations Manual March 2006.”

41

d) Prioritization And Fund Allocation 1

Ranked projects are prioritized by the IT Software Development and Maintenance 2

Senior Leadership56 and reviewed by the IT Solutions Delivery Team57 to assign project resources, 3

allocate SAM funding from the annual operating plan, and schedule the projects. 4

e) Forecast Development 5

Every year, a five-year forecast (both costs and categories of projects) are 6

generated for planned SAM activities as part of the regular budgeting process. 7

The Software Asset Management process integrates with the existing planning 8

cycles at SCE that can be seen in Figure II-8 below. The output of the SAM Forecast Development 9

Process (Capital forecast and list of potential applications or group of applications) then becomes part of 10

the annual IT operating plan. This is the last step in process as shown in Figure II-8. 11

56 Consists of the IT Software Development & Maintenance General Managers and Director. 57 IT Solutions Delivery provides the project management responsible for resource assignment.

42

Figure II-8 The SAM Calendar

SAM integrates into the various planning and budgeting cycles of both IT and the other business units.

Note: While all cycles are for the plan year, i.e. the next calendar year, the Quarterly SAM Review Cycle is for the current year.

QTR 1 QTR 2 QTR 3 QTR 4

QUARTERLY SAM REVIEW CYCLE

Assessment and Alignment

Project Ranking

PO Analysis

BU PLANNING CYCLE

IT OPERATING PLAN CYCLE

IT ROADMAP CYCLE

Forecast Development

Prioritization & Fund Allocation

SAM integrates into the various planning and budgeting cycles of both IT and the other business units.





Project Ranking

PO Analysis

BU PLANNING CYCLE


IT ROADMAP CYCLE







Project Ranking

PO Analysis

BU PLANNING CYCLE


IT ROADMAP CYCLE






Project Ranking

PO Analysis

BU PLANNING CYCLE


IT ROADMAP CYCLE

BU PLANNING CYCLE


IT ROADMAP CYCLE



SAM ANNUAL PLANNING PROCESS

SAM ANNUAL PLANNING PROCESS

D. Recorded And Forecast Cost Analysis 1

The 2006 GRC Testimony for Software Asset Management established the capital funding for 2

replacing a portion of the current SCE application portfolio. The total 2006 GRC capital approved for 3

SAM was $170.993 million. The 2006 GRC authorized capital funding for SAM was used in the 4

Enterprise Resource Planning (ERP) replacement of significant portion of the SCE application portfolio. 5

The ERP recorded and forecast capital is covered in SCE-9, Volume 1, Chapter 2. 6

We forecast SAM expenditures of $70.920 million during the years 2007 through 2011. (See 7

Figure II-9 below.) These expenditures are to replace a total of 16 aging and obsolete applications, as 8

described in detail in Section D below. 9

43

Figure II-9 Software Asset Management

2007-2011 Forecast (Nominal $000)

$0.0

$5,000.0

$10,000.0

$15,000.0

$20,000.0

$25,000.0

$30,000.0

$35,000.0

$40,000.0

2007 2008 2009 2010 2011

2007 2008 2009 2010 2011

Amount $8,920.0 $8,500.0 $7,000.0 $34,000.0 $12,500.0

Forecast

For 2006 through 2008, SCE assigned the authorized SAM capital from the 2006 GRC to 1

partially fund the ERP Project which, in an integrated fashion, is replacing all of the major obsolete 2

systems identified in the 2006 SAM testimony.58 During the years 2007 and 2008 minimal 3

replacements will be made independently for SAM outside the ERP Project, as resources and funding 4

have been reprioritized to focus on the ERP Project. As discussed in the 2009 GRC testimony for ERP, 5

we anticipate that the last rollout planned in this GRC for the ERP system will occur in 2009. As such, 6

additional subject matter experts will become available to begin necessary replacement or optimization 7

of the remaining obsolete applications not replaced by the ERP system. Starting in 2009, there is an 8

increase in SAM projects as ERP Release 3 occurs in 2009. Additionally, SAM projects are proposed 9

for 2010, as ERP Releases 0 through 3 will have been completed by 2009. For 2011, the SAM 10 58 See SCE-9 ERP for additional details.

44

expenditures are lower than 2010 in anticipation of a major ERP system version upgrade that will occur 1

in 2011 and 2012 and ERP Release 4 will be deployed in 2013.59 2

E. Proposed Software Asset Management Projects 3

Between 2007-2011, we have selected 16 well-defined specific applications for replacement or 4

optimization based on the criteria established in our SAM process described in Section II-B above. Our 5

thorough review of the entire portfolio prioritized that these are the applications in most critical need of 6

being refreshed by 2011. These projects proposed to replace, refresh, or optimize are summarized in the 7

Table II-6 below, along with their forecast capital costs. We then provide a more detailed description of 8

each proposed SAM project, including a description of the application, the problem with the existing 9

application, the proposed solution, and the forecast cost of the project. 10

Table II-6

Estimated Project Expenditures for 2007-2011

(Nominal $000) Business Unit and Project Name 2007 2008 2009 2010 2011 Total

CSBUCustomer Data Acquisition System $3,400.0 $3,400.0Field Services System $2,050.0 $2,050.0Real Time Energy Metering System $3,100.0 $3,100.0Energy Cost Simulation Tool $3,200.0 $3,200.0Meter Reading System $5,120.0 $5,120.0Complex Metering Services $1,900.0 $1,900.0

PPBUUsage Measurement System $2,500.0 $800.0 $3,300.0Wholesale Energy System $5,000.0 $8,000.0 $13,000.0Generation Management System $1,500.0 $1,500.0

OS and CCElectronic Data Interchange (EDI) $3,000.0 $3,000.0GIAS Major Upgrade $1,930.0 $1,930.0Law Matter Management System $2,600.0 $2,600.0

TDBUOutage Management System Upgrade $8,920.0 $8,920.0GE Smallworld Mapping System Upgrade $8,500.0 $8,500.0TDBU Mobile Systems $7,500.0 $7,500.0Ledger Accounting System $1,900.0 $1,900.0

Totals $8,920.0 $8,500.0 $7,000.0 $34,000.0 $12,500.0 $70,920.0

59 See SCE-9 ERP for ERP testimony on the proposed upgrade.

45

1. Customer Data Acquisition System 1

Table II-7

Customer Data Acquisition System

Project Name Customer Data Acquisition SystemBusiness Unit Portfolio CSBUApplication Age 16 yearsIn Service Date 1991Estimated Costs $3.40 million

a) Background 2

Customer Data Acquisition System (CDAS) performs data collection, validation, 3

usage calculation, and data delivery services for all billing accounts employing interval data metering, 4

including meters read by external Meter Data Management Agent (MDMA) system which cannot be 5

performed by the ERP system. The MDMA mainframe application manages the interface between the 6

billing systems and the SCE MDMA Client Server. For Direct Access (DA) accounts where SCE is the 7

MDMA, this application gathers DA billing usage data, translates it to the California Metering Exchange 8

Protocol (CMEP) formats and passes this formatted usage data to the SCE MDMA Client Server for 9

later retrieval by the customer’s Energy Service Provider. For DA accounts where SCE is not the 10

MDMA, this application receives cumulative usage data from the SCE MDMA Client Server and posts 11

it to billing. 12

b) Problem Statement 13

The database technology of the CDAS application will lose vendor support in 14

2007,60 and its underlying architecture depends upon this database design which has a limited capacity 15

on the number of accounts. As the number of accounts with interval meters continues to grow, we will 16

exceed the capability of the system as the obsolete technology was not designed to support a larger 17

number accounts. Many of the energy efficiency and demand management programs depend on SCE’s 18

60 See Workpaper entitled “IBM Software Support Lifecycle” that lists, for example, the DB2 Administration Tool for z/OS

where IBM withdraws support on September 30, 2007.

46

ability to service very large volumes of data and CDAS will become more obsolete as new customer 1

accounts are added to the system. 2

c) Recommended Approach 3

CDAS will need to be redesigned and implemented in a software technology 4

capable of handling larger volumes of data for SCE’s accounts. In addition, this redesign will leverage 5

the standard interface technology created by ERP instead of the numerous interfaces currently 6

supported. In addition the replaced system will be rewritten to run on SCE’s standard UNIX platform 7

and using a supported computer language. The current CDAS implementation runs on a combination of 8

special purpose UNIX platform and mainframe. 9

d) Funding Requirements 10

Funding needs for Customer Data Acquisition System are expected to be $3.4 11

million.61 The estimates are based on expanding the size of the current system using the historical 12

implementation costs and taking advantage of newer technologies such as those provided by Enterprise 13

Technology Services. Historical implementation for CDAS was approximately $2.83 million and the 14

new expansion is estimated to cost 20 percent more, as a result of designs that can accommodate future 15

expansion, for a total of $3.40 million. 16

2. Field Services System 17

Table II-8 Field Services System

Project Name Field Services SystemBusiness Unit Portfolio CSBUApplication Age 17 yearsIn Service Date 1990Estimated Costs $2.05 million

61 See Workpaper entitled “Forecast Expenditures Customer Data Acquisition System.”

47

a) Background 1

The Field Services System delivers field service requests generated by various 2

sources to hand-held computers used by field services representatives. The most common types of 3

requests are Turn-On and Turn-Off requests and Collection Orders. When an SCE call center 4

representative receives a request from a customer for service, the phone representative creates an order 5

in the Customer Service System, which is sent to Field Order Dispatch. Field Order Dispatch then 6

dispatches the orders to the correct Programmable Workstation in the field. The Programmable 7

Workstation determines the priorities of the orders and downloads them to the individual hand-held 8

computers. The field service representative records the results of the requests in the hand-held computer 9

and the information is uploaded to the Programmable Workstation at the end of each day. The 10

completed orders are sent back to the mainframe for processing. In addition, Field Services includes a 11

Wireless Dispatch function that dynamically sends orders to Field Service personnel and subsequently 12

processes their results back to the initiating process and other subscribing processes. 13

The CSBU Field Services System application runs from the Operational Datamart 14

database capturing time and creating time sheets for 300-400 field services representative (FSR) in 15

various districts. The information captured is based on the time reported when the FSRs go en route on 16

an order until the representative completes an order. A daily time sheet is created and summarized by 17

orders time accounting and accessing the Automated Timesheet System to get the individual start time 18

of the representative. 19


The current Field Services System uses a COTS package from Ventyx called 21

Advantex 5.4 and the vendor plans to stop support by the end of 2007. Moreover, this special edition 22

was customized by Ventyx to meet SCE’s special requirements. The end of general support and the lack 23

of support for the unique customization put this application at risk of failure, affecting almost 400 field 24

services representatives dealing directly with SCE customers on fulfilling orders. In addition, one of the 25

database systems used by Field Services System is the IBM DB2 v7, which will lose vendor support in 26

2007. 27

48


With these problems, we recommend upgrading the current system to Venytx’s 2

Service Suite 8.0. This will allow SCE to avoid custom changes and allow the application to be 3

supported for a longer period of time. A small customized portion of the Field Services System 4

application will also need revisions in order to upgrade the Venytx software from Advantex 5.4 to 5

Service Suite 8.0. 6


Funding needs for the Field Services System refresh are expected to be $2.05 8

million.62 The estimate is based upon acquiring the latest version of the COTS package and the original 9

effort to implement the system based on SCE’s current technology standards. Historical implementation 10

for the Field Services System was approximately $1.90 million, which is in line with our forecast that 11

the application rewrite and addition of the new Venytx software is estimated to cost $2.05 million. 12

3. Real Time Energy Metering System 13

Table II-9

Real Time Energy Metering System

Project Name Real Time Energy Metering SystemBusiness Unit Portfolio CSBUApplication Age 6 yearsIn Service Date 2001Estimated Costs $3.10 million

a) Background 14

The Real Time Energy Metering (RTEM) system is an automated data collection 15

for meters fitted with pager, modem, or Netcom radio. The RTEM system reads meters daily and passes 16

billing data to CDAS for validation and usage calculation. It also delivers data to Energy Analytics for 17

end-use customer viewing of usage data. It is also used for Dynamic Load Profiles data that are sent to 18

62 See Workpaper entitled “Forecast Expenditures Field Services System.”

49

CDAS and passed through to SCE’s Regulatory and Affairs Department for their essential load profile 1

analysis for DA customers. 2


RTEM software cannot support the expected demand for new interval data meters 4

for commercial and industrial customers. Based on service level agreement records, we know that the 5

RTEM system currently is not meeting service expectations used by PPBU to schedule QF generation. 6

Current RTEM system capacity is in the range of 15,000 accounts and we are almost at that capacity 7

today. Many of the current and emerging demand response and load management programs depend on 8

SCE’s ability to measure and bill usage in intervals, rather than the monthly cumulative measurement 9

currently required to bill most customers. The technology was not designed to support a larger number 10

of accounts that will need to be serviced. In addition, one of the database systems used by the RTEM 11

system is the IBM DB2 v7, which will lose vendor support in 2007, and several of the computer 12

languages used to code RTEM are no longer supported by the vendor and thus, are likewise obsolete. 13


RTEM will need to be replaced by a system capable of handling interval data in 15

the range of 25,000 accounts initially and then adding an additional account increase of 10 percent per 16

year. The new system will also need to collect and report real-time hourly, quarter hourly, and demand 17

bidding requirements for the current demand response and load management programs. The current 18

technology will not support the expected growth in RTEM customers. 19


Funding needs for the system are expected to be $3.1 million.63 The estimate is 21

based the historical implementation cost for the RTEM system, which was $6.4 million and our 22

capability to leverage the functionality of the current system while modernizing the coding language and 23

database. 24

63 See Workpaper entitled “Forecast Expenditures Real Time Energy Metering System.”

50

4. Energy Cost Simulation Tool 1

Table II-10

Energy Cost Simulation Tool

Project Name Energy Cost Simulation ToolBusiness Unit Portfolio CSBUApplication Age 15 yearsIn Service Date 1992Estimated Costs $3.20 million

a) Background 2

This project involves the technology remediation of the application Energy Cost 3

Simulation (EnCost). Energy Cost Simulation Tool (EnCost) is a custom rate analysis program for 4

Southern California Edison. The EnCost program enables the user to quickly and accurately perform 5

rate comparisons on customer service accounts. Starting with the customer’s current usage, an EnCost 6

user can compare other rate schedules to see which would be most beneficial for a customer account. 7


There are two main drivers for replacing EnCost: (1) currently EnCost represents 9

a secondary billing calculation engine whose technology has to keep up with the main billing system, 10

and (2) the data source that Encost uses to capture usage and other facts about the customer’s account 11

will be decommissioned due to ERP replacing the obsolete systems interfaced with EnCost. Whenever 12

it is necessary to make any rate adjustment or add a new rate in the primary billing system, it must also 13

be done in EnCost. This represents duplicate effort and also risks that the EnCost billing calculations 14

will not be synchronized with the actual billing system. The remediation of EnCost includes replacing 15

the current system technology to be compatible with the ERP system. In addition, one of the database 16

systems used by the EnCost system is the IBM DB2 v7, which will lose vendor support in 2007. 17


We propose to rewrite EnCost on a software platform compatible with ERP and 19

using the ERP billing engine as opposed to a “duplicate” bill calculation engine as it exists today. 20

Although our preference is to use COTS wherever possible, the bill calculation requirements in 21

51

California are very specialized and are not easy to implement in a vendor package because of the 1

continuous need for bill customization. We plan to leverage the standard interface technology created 2

by ERP instead of the numerous interfaces currently supported in order to maintain synchronization with 3

the customer data. 4


Funding needs for replacing the Energy Cost Simulation Tool are expected to be 6

$3.2 million.64 Based on our knowledge of the application and what the historical costs were to 7

implement, we believe this forecast is reasonable. 8

5. Meter Reading System 9

Table II-11

Meter Reading System

Project Name Meter Reading SystemBusiness Unit Portfolio CSBUApplication Age 12 yearsIn Service Date 1995Estimated Costs $5.12 million

a) Background 10

The Meter Reading System is designed to schedule meter reader routes and 11

populate the handheld with data for meter visits. This system generates Meter Visits and Meter Visit 12

Exchanges in the Customer Service System Database for each meter scheduled. The Meter Visit is 13

generated for each meter and the Meter Visits Exchange is generated for each dial set. The Meter Visits 14

and the Meter Visits Exchanges are populated with data from the Meter Read Posting (MRP) System. 15

Meter Reading serves as the primary usage collection point and initiator of all bill 16

stream processing. Meter Reading System Support is responsible for the processing of routine meter 17

reads for over 4.8 million accounts monthly. 18

64 See Workpaper entitled “Forecast Expenditures Energy Cost Simulation Tool.”

52

Meter reading data is generated from the CSS database on a daily basis and 1

downloaded to Premier Plus (a UNIX-based meter reading system from ITRON). Premier Plus supports 2

the reading of both simple and complex meter types by either hand-held computer devices or various 3

Automated Meter Reading technologies. The results of the meter reading process are uploaded to the 4

mainframe and posted to the CSS database. 5


The meter reading sequencing and routing subsystems, used to determine the 7

order in which meters are read, were built using the development tool Cross-System Product (CSP) that 8

is no longer supported or maintained by IBM. The Meter Reading system is one of the older software 9

systems in the CSBU application portfolio. The risk of failure will increase because the CSP-built 10

application does not have a migration path when we must upgrade its database from the IBM DB2 v7 to 11

v8. The COBOL compiler needed for the IBM DB v8 upgrade does not support the CSP product. 12


We propose to rewrite the meter reading sequencing and routing function by 14

changing the obsolete system from the mainframe implementation to a server based UNIX operating 15

system and provides interval data meter capability integration by leveraging Enterprise Technology 16

Services. 17


We estimate the Meter Reading System replacement to cost $5.12 million.65 The 19

project estimation costs are based on the complexity and size of the Meter Reading system, which is a 20

medium-sized system with 3,912 function points, and database that will need to be converted to a UNIX 21

platform, with technology redundancy and using Enterprise Technology System wherever possible to 22

provide seamless integration with the ERP system. 23

65 See Workpaper entitled “Forecast Expenditures Meter Reading System.”

53

6. Complex Metering Services 1

Table II-12 Complex Metering Services

Project Name Complex Metering ServicesBusiness Unit Portfolio CSBUApplication Age 17 yearsIn Service Date 1990Estimated Costs $1.90 million

a) Background 2

Three interrelated systems are used to test meters, read, design, and install 3

complex metering. 4

First, the Field Automated Test System (FATS) automatically loads pending 5

meter tests, generated revenue metering field work requests, routes pending tests to the right meter 6

technician, guides the meter technician through the meter test as they perform it, stores the test results 7

electronically and lastly, notifies SCE technical and management personnel of the test results. An 8

installed electric meter can undergo a variety of tests such as installation, routine, customer complaint, 9

Public Utilities Commission inquiry, SCE request, or special test. Read results for special billing 10

accounts are automatically sent to CDAS. In addition, timesheet information on each meter test is 11

captured and forwarded to timesheet clerks daily. 12

Second, the Electrical Metering Services Tracking System (EMST) tracks 13

requests for Metering Engineers to provide engineering information for new Metering Installations. The 14

requests can be associated to either the Installed Service or the Metering Device. The completed 15

Engineering Sheet including technical installation data is entered into this system. 16

Third, the EMS Web Reporting (EMSWR) system is an SCE Intranet application 17

that allows users to search for and retrieve information pertaining to FATS and EMST information. The 18

EMS Reports are pre-established-canned reports grouped into three categories: Management, 19

Engineering and Supervisor reports. Data from pertinent CSS tables is replicated every night from 20

production and passed onto a separate server to prevent negative impact on the production databases. 21

54

This reporting mechanism helps the user evaluate current performance and establish service level goals 1

based on their ability to measure the most important metering information. 2


The suite of complex metering service applications has several problems. EMST 4

and FATS software were written in a now obsolete software language, Delphi 7. Delphi 7 is no longer 5

supported by the vendor, which exposes SCE to risks of system failures. Moreover Delphi 7 software 6

developers are difficult to find and hire because it is no longer used. Many of the current demand 7

response and load management programs and those proposed for the future depend on SCE’s ability to 8

install and test complex meters collecting bill usage in intervals, rather than the monthly cumulative 9

measurement currently required to bill most customers. 10


We propose to rewrite the complex metering service applications using current 12

SCE software standards by utilizing COTS packages, where feasible, that could be integrated to 13

combine the benefits and functionality of the FATS, EMST and EMSWR applications. The current 14

planned ERP package does not support this functionality, but it may be possible to use some special 15

business rule based components of the ERP package to support the web reporting functionality. 16


We forecast the Complex Metering Services applications to be $1.90 million.66 18

The project estimation is based on the historical cost for implementing the capitalized software for the 19

three original systems. 20

66 See Workpaper entitled “Forecast Expenditures Complex Metering Services.”

55

7. Usage Measurement System 1

Table II-13

Usage Measurement System

Project Name Usage Measurement SystemBusiness Unit Portfolio PPBUApplication Age 9 yearsIn Service Date 1998Estimated Costs $3.30 million

a) Background 2

SCE is mandated to report hourly consumption for all its retail customers to the 3

California Independent System Operator (ISO). The Power Procurement Business Unit’s (PPBU) 4

Business Process and Technology Integration Group is responsible for reporting this information to the 5

ISO. PPBU currently has a process and the custom-developed Usage Measurement System (UMS) to 6

aggregate Settlement Quality Meter Data (SQMD) and report it to the ISO each business day. 7

UMS will need to be replaced by a system capable of handling interval data and 8

customer growth for new accounts. Currently, UMS has approximately 100,000 accounts which will 9

continue to grow, and the UMS technology is limited by the number of accounts it can service and will 10

not meet our projected needs. SCE is in the midst of an enterprise-wide systems replacement project 11

with ERP. The ERP Project will result in the replacement and decommissioning of other information 12

systems (Customer Service System (CSS) and Customer Revenue Reporting Information System). SCE 13

also proposes to replace its CDAS system. PPBU relies on these systems either directly or indirectly for 14

data that is used to calculate SQMD. 15


The decommissioning, change or replacement of these information systems will 17

require significant changes to PPBU’s usage aggregation and reporting processes. The current 18

technology and design of UMS will not support the demands of the new systems. SCE requirement to 19

submit Settlement Quality Meter Data (SQMD) to the ISO for the cumulative and interval metered 20

services for each hour of every trade day cannot be supported with the existing systems if they fail. The 21

56

ISO uses this information, along with SQMD from other entities within California, to calculate SCE’s 1

energy charges, imbalance energy, unaccounted for energy as well as other administrative charges. In 2

order to continue meeting regulatory requirements defined by the ISO and the California Public Utility 3

Commission (CPUC), it is imperative that meter usage data processed for the creation of SQMD is 4

timely, accurate, and complete. This is a case where the regulations have rendered the existing system, 5

which was based on what was needed in the past, obsolete going forward. In order to do meet the 6

regulations, PPBU needs to replace the out-of-date software technology with reliable technology that 7

can support the new system demands. The current system is written in a Sybase-PowerBuilder Pro 8

version that is no longer supported and requires to be rewritten with a new database management 9

system. 10


We forecast that $3.3 million will be for the cost of this project.67 Of the total, 12

$2.5 million will be required in 2008 and 2009 to enhance the current UMS system in order to provide 13

additional functionality for the system and build required interfaces to acquire data from new sources. 14

The additional $0.8 million will be required in 2010 and 2011 to further enhance the UMS system and 15

interfaces to acquire aggregated consumption for meters from Meter Data Management System 16

(MDMS) instead of CSS. This change will be necessary because MDMS will be the source for SCE 17

meter reads after the MDMS implementation is complete and will render the current UMS system 18

obsolete. 19


We forecast the Usage Measurement Aggregation System replacement to be 21

$3.30 million. The estimates are based on SCE’s historical capitalized software costs needed to build 22

and enhance the current UMS system, plus anticipating the new interface requirements. The current 23

application was developed by SCE as a custom system and the estimates are based on using this 24

67 See Workpaper entitled “Forecast Expenditures Usage Measurement System.”

57

approach again, but utilizing the Enterprise Technology Systems integration technology, and where 1

possible, components from the ERP system. 2

8. Wholesale Energy System 3

Table II-14

Wholesale Energy System

Project Name Wholesale Energy SystemBusiness Unit Portfolio PPBUApplication Age 11 yearsIn Service Date 1996Estimated Costs $13.00 million

a) Background 4

The Wholesale Energy System (WES) is currently used by two SCE business 5

units, the Transmission Distribution Business Unit (TDBU) and PPBU. TDBU uses WES to administer 6

approximately 120 interconnection contracts. The Renewable and Alternative Power (RAP) 7

organization in PPBU uses WES to administer about 250 power purchase contracts. WES is an UNIX-8

WINDOWS client server application written in very old computer language versions of C++ and Visual 9

Basic. IT uses an obsolete and unsupported database from Sybase with an obsolete unsupported 10

document management system from FileNet. The technology used in the WES software has not been 11

upgraded in over 10 years, and should be replaced and rebuilt to remove the obsolete technology. 12

The major functions provided by WES include: contract payment management, 13

document management, workflow management, and regulatory reporting. WES was originally designed 14

to manage Qualifying Facility (QF) contracts, but new business processes now require enhanced 15

functionality to process new and renewed purchased power contracts with more complex terms and 16

conditions. 17


The new Contract terms require payment and settlement functions that are tied to 19

ISO operations and settlements. The contracting terms now include the following: processing for 20

forecast, scheduled and metered kWh; multi-settlement intervals per hour (10-minute intervals); ISO 21

58

Settlement transaction adjustments; payments adjustments based on ISO prices; annual energy delivery 1

target monitoring. Based on its current state, WES is unable to adequately meet new requirements from 2

both a technology and business fit perspective. 3

RAP is currently responsible for managing 220 QF contracts; and 25 Eligible 4

Renewable Resource contracts (of which 4 are currently operating). RAP is aggressively negotiating 5

contracts with renewable resources in order to meet legislative renewable portfolio standard goals by 6

2010. Due to the current market structure, these contracts are far more complex than the original 7

contracts that are currently administered by RAP. 8

In addition, legislative proposals to increase the Renewable Portfolio Standard 9

goals could greatly increase the number of such contracts.68 WES needs to be technologically improved 10

if SCE is to successfully manage the new contracts. 11


WES should be replaced with updated technology and enhanced capabilities to 13

support the new RAP contracts. The new system must also be able to integrate with the Entegrate69 14

system and potentially with SAP to manage new payment and settlement functions that are tied to ISO 15

operations and settlements. This will require considerable development in new business rules that were 16

not required when WES was originally developed. In addition, WES uses a document management 17

system call FileNet that is no longer supported by the vendor. We are proposing replacing this sub-18

system and integrating with the document and records management system used in the new ERP system. 19


WES was developed at a cost of $8.5 million by Perot Systems and implemented 21

in phases from 1996 to 1998. Starting in 2001, WES was further enhanced and modified through a 22

series of in-house IT projects. The estimated replacement cost to update the technology and integrate 23

68 Futhermore, AB94 has been introduced in the California Legislature. If enacted, this legislation would increase the RPS

to 33 percent by 2020. See SCE-8, Volume 1, for further information. 69 SunGard’s Entegrate is an energy trading and risk management platform and integrated set of functional components that

helps energy companies to more efficiently energy, process transactions, manage risk, and optimize operational and financial decisions.

59

with the new systems is expected to be $13.00 million.70 This estimate is based on an estimate from 1

Perot Systems if they were to do the project again based on what they learned from the first time they 2

implemented WES. 3

9. Generation Management System 4

Table II-15

Generation Management System

Project Name Generation Management SystemBusiness Unit Portfolio PPBUApplication Age 4 yearsIn Service Date 2003Estimated Costs $1.50 million

a) Background 5

The Generation Management System (GMS) was developed and implemented in 6

2003 to enable SCE’s Energy Supply and Management personnel to more accurately determine SCE’s 7

net energy position throughout each operating day, thereby improving the opportunity to lower energy 8

costs to its customers. 9

GMS supports SCE’s goal to minimize costs to its customers by providing real-10

time information for QF power production and enabling SCE to update hour-ahead schedules as needed 11

for generation deviations from planned schedules. GMS’ functionality allows PPBU Operations 12

personnel to perform and monitor the following: Automated Generation Control (AGC); telemetered 13

data; schedules from the Power Bidding and Settlements (PBS) system; dynamic schedules information; 14

ISO scheduling information; energy trader information; real time data from various locations; calculate 15

net short positions; and adjust hour-ahead schedules based on generation status. 16

The implementation of GMS has allowed ES&M personnel to monitor the 17

performance of generating units and to adjust ISO hour-ahead schedules, thereby reducing both negative 18

and positive energy deviations (i.e., uninstructed energy) in the ISO’s real-time energy market. This 19 70 See Workpaper entitled “Forecast Expenditures Wholesale Energy System.”

60

reduction has, in turn, resulted in reductions in ISO charges for imbalance (uninstructed) energy, as well 1

as charges for ancillary services and grid management. 2


Each operating day, through its day-ahead and hour-ahead transactions, PPBU 4

attempts to minimize SCE’s residual net short and residual net long positions in the ISO’s real-time 5

market to avoid ISO charges for energy imbalances (i.e., the difference between energy scheduled and 6

actual energy needed in real time to serve customer load). This requires PPBU to have reliable access to 7

real-time system data used in assisting PPBU personnel who schedule energy with the ISO. A 8

technology-related failure due to obsolescence would jeopardize PPBU ability to schedule energy with 9

the ISO. The system operates in real-time, responding immediately to market fluctuations and if it were 10

to stop functioning, the ability to capture market changes would be lost. SCE would then have to 11

perform these real-time functions manually. 12

GMS is a custom solution built around various software packages as a system 13

from Invensys, PLC (provider of specialized software solutions to the utility industry). GMS requires 14

application upgrades for InTouch v9.5 (human-machine interface) software that is already running as a 15

patched version and considered obsolete. GMS also needs to upgrade Active Factory v9.1 (trending and 16

analysis software) in conjunction with the InTouch upgrade. Finally, the software product LiveData 17

ICCP v5 (used to record and transmit data to other control points in process control networks) for has 18

several known information security vulnerabilities that can crash the server due to exploited buffer 19

overflow vulnerabilities. This security exposure must be removed. 20


All these applications have to be upgraded together because GMS is an integrated 22

solution of applications. We are recommending technology upgrades to GMS that require the 23

replacement of the existing system. However, the configuration of the replacement project will be 24

affected by the changes to system interfaces that will result from the ISO’s Market Redesign and 25

Technology Upgrade project. This may require addition interfaces. We plan to leverage the ETS 26

capabilities to simplify the potential data interfaces. The current system uses a software package from 27

61

Invensys and is capable of retrieving telemetered data, Qualified Facility 15-minute meter data, and 1

power bidding and settlement hourly data. The trending and forecasting tools to assist in generation 2

management and decision support software will be included in the upgraded design. This is a complex 3

system that requires redundant design. 4


SCE forecasts the Generation Management System are expected to be $1.50 6

million.71 The project estimation is based on the historical cost for the capitalized software for 7

implementing GMS in 2003 using a COTS package with modifications. Based on this information the 8

estimate is reasonable and achievable. 9

10. Electronic Data Interchange 10

Table II-16

Electronic Data Interchange

Project Name Electronic Data Interchange (EDI)Business Unit Portfolio Operations SupportApplication Age 18 yearsIn Service Date 1989Estimated Costs $3.00 million

a) Background 11

Electronic Data Interchange (EDI) is a mainframe translation application that, on 12

the outbound side, accepts files from various applications (e.g., Materials Management System for 13

Purchase Order/Invoice) and formats them into EDI format before sending them out to a Value Added 14

Network (VAN).72 On the inbound side, it takes EDI files from the VAN, reformats them and passes 15

them along to various applications. 16

This project involves the hardware, software and interfaces replacement of the 17

Electronic Data Interchange (EDI) translation functionality. Currently, the EDI translator at SCE is 18 71 See Workpaper entitled “Forecast Expenditures Generation Management System.” 72 A Value Added Network is a privately owned, or proprietary, network that generally provides specialized services, such

as electronic data interchange services or access to a particular database.

62

mainframe-based and was installed in the early 1990s. SCE is moving most enterprise applications to a 1

distributed computing environment. Our existing EDI translator has a distributed upgrade path and the 2

vendor is urging SCE to migrate off of the mainframe since all new features and tools are being 3

delivered in the distributed product. No new updates are being applied to the mainframe software by the 4

vendor. Our existing EDI software was last updated for the Y2K issues (in 1999). SCE’s EDI program 5

supports several business functions with EDI translation and transmission services including; supply 6

chain purchase orders; supplier invoices; and ISO support. 7


SCE’s Material Management Systems are being replaced and the mainframe 9

computing environment and the current software vendor has discontinued upgrades to their mainframe 10

product. ERP Releases 0 through 3 applications that will use EDI services will be migrated to a 11

distributed environment by early 2009. As a result, if we leave EDI translation on the mainframe 12

platform after ERP Releases 0 through 3 deployment, we will bear increased support costs and potential 13

loss of functionality within the application, which would negatively impact supply chain operations, ISO 14

transactions and overall customer support services. 15


Moving the EDI software to the distributed platform will simplify our EDI 17

processing, provide updated translation capabilities, and add to our data translation and mapping 18

capabilities. We plan to use the existing EDI translation software while implementing ERP Releases 0 19

through 3 system applications through early 2009. But once that is completed, the EDI software will be 20

changed-out to better align with the ERP platform and the new processes the ERP will bring. The 21

existing mainframe software, provided by Sterling Commerce, does have an established distributed 22

replacement product and migration path. It would be our recommendation to leverage that product and 23

our existing relationship to move to the replacement product (GenTran Integration Suite). The existing 24

software and vendor has served us well and the new product would provide an upgraded set of 25

standards-based EDI tools operating in a new and supported environment. 26

63


This project is anticipated for 2009, and will replace the existing EDI translation 2

software, related hardware, and communication interfaces required to provide EDI translation and 3

transmission services to our internal and external trading partners. Based on our knowledge of the 4

application and the existing services we provide, we believe the cost of a solution to be $3.0 million.73 5

This estimate is based on the original project cost to implement EDI plus various enhancements to the 6

base system and taking into account the use of newer technologies that also include software licensing. 7

11. Geographical Information Application System Major Upgrade 8

Table II-17

GIAS Major Upgrade

Project Name GIAS Major UpgradeBusiness Unit Portfolio Corporate CenterApplication Age 7 yearsIn Service Date 2000Estimated Costs $1.93 million

a) Background 9

There are two primary Geographical Information Systems at SCE, ESRI and GE 10

Smallworld. Both have important, but different functions. GE Smallworld allows us to focus on utility 11

applications and graphical depictions (mostly maps) of TDBU specific information in a manner that is 12

essential to TDBU operational processes. ESRI publishes its protocol, which allows companies to 13

develop and sell environmental and other public-purpose information, such as demographics or street 14

maps, which can be used by SCE in their maps. The information written in ESRI format is typically 15

more generic and is sold to a cross-section of industries. CSBU, Corporate Real Estate, RP&A, and 16

Edison Carrier Solutions use tools provided by ESRI for displaying, manipulating, and analyzing the 17

data. 18

73 See Workpaper entitled “Forecast Expenditures Electronic Data Interchange (EDI).”

64


The applications portfolio developed over a period of time runs on an obsolete 2

version of the ESRI suite product called Arc/Info and uses a proprietary computer language AML that 3

requires running on a UNIX platform. The development platform of choice for the ESRI vendor is now 4

Microsoft Windows. All new enhancements to the software are no longer available on the UNIX 5

platform. The vendor ESRI has decided to focus their development efforts using the Microsoft Visual 6

Basic and “.net” environments rather than continue dual development work in both the Microsoft and 7

UNIX environments. Vendor support for AML is being reduced and is expected to be phased out. 8

There are also known defects that the vendor is slow to address or is not addressing. 9

This vulnerability exposes company operations to system failure. This is a risk, 10

which could affect availability of these systems during critical work phases. Such failures could also 11

impact our customers and internal business functions. 12


SCE plans to upgrade applications to the current version of ESRI suite by 2010 in 14

a phased manner. In making this upgrade to the current version, the platform can be upgraded to a 15

combination of Windows Servers and Windows XP Pro desktop and laptop computers (current 16

supported SCE standard for Windows), the known defects will be corrected, and ongoing maintenance 17

costs should be reduced because SCE will no longer require customized vendor support. 18


The Graphical Information Application System’s Major Upgrade is expected to be 20

$1.93 million.74 The estimated cost is based on the changes needed to upgrade the current system from 21

a UNIX operating system environment to Windows and the size of database. We consider this option to 22

be a low risk conversion of technologies that will take advantage of the Windows platforms. The cost is 23

based on replacing the core system used by several applications which will allow the system 24

replacement to be done for less cost and makes ongoing maintenance much easier. 25

74 See Workpaper entitled “Forecast Expenditures GIAS Major Upgrade.”

65

12. Law Matter Management System 1

Table II-18 Law Matter Management System

Project Name Law Matter Management System Business Unit Portfolio Corporate Center

Application Age 17 years

In Service Date 1990

Estimated Costs $2.60 million in 2011

a) Background 2

The Corporate LawPack (CLP) software is the Legal Matter Management system 3

for SCE’s Law Department originally marketed by CompInfo. Corporate LawPack functions as the 4

comprehensive matter management system for legal matters. This system is used by Law Department 5

staff to manage the day to day complexities involved in managing legal matters. The CLP system tracks 6

matter type, practice area, in-house staffing, internal clients, parties, invoicing, opposing counsel, 7

budgeting, court venue/dockets, outside counsel, outside counsel rates, specialities, accounting 8

allocations, document retention, file locations, matter narratives, and IP related data. Corporate Law 9

Pack went into service for SCE’s Law Department in 1990. In the late 1990s, LawPack’s vendor, was 10

purchased by Hummingbird Ltd., who later stopped selling CLP. Official vendor support for Corporate 11

LawPack ended in January 2002. 12


System updates and maintenance releases are no longer available because the 14

Corporate Law Pack system is no longer supported by the vendor. Upgrades to the underlying software 15

and operating system (Microsoft SQL and Windows) have been deferred to mitigate risk of breaking the 16

application since CLP was removed from support. Additional risk will be introduced when the 17

Microsoft SQL Server 2000 product is removed from general support in April 2008. Beyond the 18

technical obsolescence, customization of CLP has been done using a vendor-supplied toolkit. Recovery 19

from any system outage or “crash” presents risk of a prolonged system outage to recover the custom 20

developed components. 21

66


Our plan is to replace Corporate Law Pack with a new Matter Management 2

System because there is no software upgrade path offered by the Hummingbird vendor. Currently, 3

through industry research, there does not appear to be a clear front runner in the Matter Management 4

software market. Leading candidates for this system replacement include Mitratech, LT Online’s 5

LawTrac, Bridgeway, and CorpraSoft/Data Cert. 6


Funding needs for Law Matter Management System are expected to be $2.60 8

million for 2011.75 The estimates are based on the project costs for implementing, customizing and 9

enhancing the current system compared to comparable COTS packages now available, in order to 10

provide industry-standard, updated functionality. 11

13. Outage Management System – Upgrade To Version 5.0 12

Table II-19

Outage Management System

Project Name Outage Management SystemBusiness Unit Portfolio TDBUApplication Age 4 yearsIn Service Date 2003Estimated Costs $8.92 million

a) Background 13

The TDBU Outage Management System (OMS) is a critical, system used by the 14

TDBU Grid Operations Department to monitor and operate SCE’s distribution network. The system 15

provides critical information for the identification and restoration of service outages. Without this 16

system, the amount of time required to restore service for our customers would increase dramatically. 17

Its first major upgrade was completed in 2003; however, the underlying technology for OMS is an 18

obsolete vendor software technology developed by CGI Utility Solutions called CGI version 2.05. The 19

75 See Workpaper entitled “Forecast Expenditures Law Matter Management System.”

67

vendor’s current version, however, is CGI 5.0. We understand that SCE is the last CGI client still using 1

version 2.05, as it is now several generations out of date. In addition, the software can only run on an 2

obsolete Windows 2000 platform that does not meet SCE’s current IT standards,76 due to security flaws 3

and the need for redundant computing equipment. In addition, there are known defects in the existing 4

version of OMS that cannot be repaired unless the newer version of CGI is installed. These problems 5

will continue to exist and only worsen as the application ages. 6


Because the OMS application has become obsolete, does not have vendor support, 8

and has known defects that must be repaired, this application experiences frequent maintenance-related 9

outages, which negatively impact operations and service restoration, interfaced systems, and users’ 10

productivity. These impacts are not acceptable for such a critical system. 11

This exposes the company to system failure risk, which could result in significant 12

delay in SCE’s ability to restore load daily (two times longer), during storm (three times longer), or 13

during a disaster (five times longer). Such failures to recover from major disturbances in a timely 14

fashion would result in cost increases due to overtime labor costs as a result of crew scheduling delays. 15

Such failures could also impact our customers. 16


SCE plans to upgrade to the current version of OMS (CGI OMC v5.0) in 2007. In 18

making this upgrade to the current version, the platform can be upgraded to Windows XP Pro (currently 19

supported SCE standard for Windows), known defects will be corrected, and SCE will no longer require 20

customized vendor support at a premium. The cost for OMS is $8.92 million.77 Project estimations are 21

based on the scope and modifications of the 2001 OMS enhancement work that implemented the current 22

system and takes into account the additional enhancements to the current system. 23

76 SCE IT standards are governed by IT Enterprise Architecture to ensure systems compatibility and reliability. 77 See Workpaper entitled “Forecast Expenditures Outage Management System.”

68

14. GE Smallworld – Upgrade To Version 4.1 1

Table II-20

GE Smallworld Upgrade

Project Name GE Smallworld Upgrade (T&D Asset Mapping)Business Unit Portfolio TDBUApplication Age 4 yearsIn Service Date 2003Estimated Costs $8.50 million

a) Background 2

There are two primary Geographical Information Systems (GIS) at SCE, ESRI 3

and GE Smallworld. Both have important but different functions. GE Smallworld allows us to focus on 4

utility applications and graphical depictions (mostly maps) of Transmission and Distribution Business 5

Unit (TDBU) specific information in a manner that is essential to TDBU operational processes. ESRI 6

publishes its protocol which allows companies to develop and sell environmental and other public-7

purpose information, such as demographics or street maps that can be used by SCE in their maps. GE 8

Smallworld is a geographical information system tool used by TDBU Grid Operations for creating, 9

maintaining and analyzing SCE’s distribution network model, as well as maintaining street lighting 10

electric circuits and maps. A GIS is a system captures, stores, analyzes and manages data and associated 11

information that are spatially referenced to the earth. GIS tool allows users to search and analyze the 12

spatial information, edit data, maps, and present the results of all these operations in graphical form. 13

SCE applications utilizing GIS information including OMS (Outage Management System), Field Tools, 14

and Street Lights Inventory – are highly dependent on GE Smallworld for providing circuit related 15

information and maps for SCE’s entire distribution network. The current version of this software is 16

version 4.1, whereas SCE uses version 3.0. The version 3.0 is no longer supported by the vendor, and 17

SCE’s other available GIS tool, ESRI, does not provide required electrical connectivity data. 18

69


GE Smallworld application experiences frequent maintenance related outages 2

related to unsupported obsolete software that impact operations (e.g., power restoration), field crew 3

productivity, and interfaced applications. 4

The GE Smallworld GIS application operates in conjunction with outage 5

management and field tools and when the GIS system fails it results in significant work delays when 6

restoring power. During normal operations this can result in taking up to twice as long for the crews to 7

perform work, even worse during storms where the work impact could be three times as long to restore 8

power and up to five times the delay during a disaster. 9


SCE plans to upgrade to the current version of GE Smallworld (GE Smallworld v. 11

4.1). In making the upgrade, SCE will be able significantly reduce the unplanned GIS application 12

maintenance outages. Utilizing a supported version will also simplify the maintenance of interfaces by 13

eliminating customized interface coding because the solutions are available from the vendor. 14


The forecast for GE Smallworld is $8.5 million.78 Project estimations are based 16

on the cost of similar installations and upgrade work, along with the size and configuration of the current 17

system. 18

15. TDBU Mobile Systems 19

Table II-21

TDBU Mobile Systems

Project Name TDBU Mobile SystemsBusiness Unit Portfolio TDBUApplication Age 6 yearsIn Service Date 2001Estimated Costs $7.50 million

78 See Workpaper entitled “Forecast Expenditures GE Smallworld Mapping System Upgrade.”

70

a) Background 1

The TDBU Mobile Systems currently consists of closely-related field tool 2

systems originally implemented from 1999 through early 2003. These systems are Transmission Field 3

Tool (TFT), eMobile Suite, eMobile PLUS, and the Substation Data Collection and Reporting System. 4

The following section gives information on the current TDBU Mobile Systems that have technology 5

obsolescence and must be upgraded or replaced. 6

The Transmission Field Tool (TFT) implemented in 2001 to support the TDBU 7

transmission patrolmen and wash crews and works in conjunction with TDBU Work Management 8

System. The crews use “ruggedized” laptop computers with WLAN (Wireless Local Area Network) 9

capability for mobile access to information when in SCE facilities. The TFT application allows for the 10

creation and performance of work requests for circuit patrols, transmission line wash crews, and 11

transmission switch inspections that is essential to the daily work and crew safety. TFT is capable of 12

interfacing to handheld GPS (Global Positioning System) to record latitude and longitude position for 13

structures, access to information manuals and work order/work request information. This allows access 14

to equipment records for circuits, switches, underground vaults and information for manual intervention 15

required for the installation and/or removal of assets. 16

The eMobile suite of application tools was implemented in 2001 and currently 17

used in TDBU by 180 Troublemen and 30 apparatus technicians using “ruggedized” laptop computers 18

with LAN capability. In 2003, this technology was expanded to another 400 users with another 19

application called eMobile PLUS. In the field this technology allows the crews to access circuit maps, 20

street maps and equipment manuals from their laptop computers. The E-Mobile Suite of applications is 21

used by the Troublemen to perform circuit patrols, creation and performance of Work Requests that are 22

loaded into the Work Management System and also to initiate Meter Orders from the field. 23

The TDBU application called Substation Data Collection and Reporting System 24

(SDCRS) was implemented in 1999. SDCRS provides substation operators capability to record 25

equipment readings or equipment conditions when they perform inspection or regular rounds at each 26

71

substation. SDCRS provides reports and generate e-mails to maintenance crews in addition to updating 1

the Work Management System with circuit breaker and transmission information. 2


The new Distribution Inspection and Maintenance Initiative that is planned for 4

2008 will require changes to all three field tools to replace technology obsolescence in order to ensure 5

reliable operation on a 24-hour per day basis. The technology obsolescence restricts GIS viewer 6

capability needed for access to asset information, electrical connectivity models, asset location 7

information, and driving directions, in addition to wireless WAN capability for real time work 8

assignments, status and completion notifications. The technology obsolescence limits capability to 9

perform and record all types of work and not just maintenance and inspection that can then be leveraged 10

to extend usage to Substation and Transmission field personnel that currently are not using a tool. 11


The recommended approach is to consolidate all existing field tool applications 13

into one application supported by a single vendor. The plan is to purchase a COTS package that will 14

provide a stable, user-friendly and reliable platform to support current and future users. The system will 15

also have robust synchronization capabilities for future integration with other systems such as SAP, 16

Smallworld, and Clicksoft. We expect vendor and technology research to begin in 2007 and vendor 17

selection to be completed in 2008. Detailed business requirements are expected to be finalized by early 18

2009 and the project is planed to be completed in 2010. 19


SCE’s forecast for the TDBU Mobile System is $7.5 million.79 The expected 21

capital requirement is based on historical cost to implement the original systems associated 22

enhancements that comprise the TDBU Mobile System. 23

79 See Workpaper entitled “Forecast Expenditures TDBU Mobile Systems.”

72

16. Ledger Accounting System 1

Table II-22

Ledger Accounting System

Project Name Ledger Accounting SystemBusiness Unit Portfolio TDBUApplication Age 12 yearsIn Service Date 1995Estimated Costs $1.90 million

a) Background 2

The Ledger Accounting System (LAS) is used for tracking non-energy charges 3

such as Refundable Work Orders, Collectible Orders, Sales Orders and Miscellaneous Orders which is 4

beyond the capability of the ERP system. The LAS application provides a means by which the Ledger 5

Support personnel post, balance, and reconcile non-energy records. 6

The system performs several complicated operations for revenue collection 7

critical to TDBU and comes under the key control standards for SOX (Sarbanes Oxley Act). The LAS 8

implementation supports contract management and provides pertinent project information. This allows 9

the source of information and the management of Distribution Line Extension contracts in a single 10

system. The system tracks information for total advances paid, annual revenue and meters used in 11

calculations, total refunds issued, applicable transfer voucher data affecting open balances, calculated 12

defect bill amounts, and calculated monthly ownership changes. The system utilizes specific tariff rules 13

to calculate refunds, deficit billings and ownership changes for each Developer contract that go into the 14

work orders. In addition, LAS is used as a pass-through for non-refundable cash receipts and for cash 15

receipts recording to corporate financial system. 16

b) Problem Statement And Recommended Approach 17

The technology used as the base of the application is outdated with limited 18

support. As described above, the functionality of LAS is highly customized due to our tariff 19

requirements and will not be replaced by the ERP system. We need to replace the LAS’s application 20

code to reduce the risk of failure. We expect to complete this project in 2010 by rewriting the 21

73

application in a standardized computer language. Replacing the existing LAS functionality in 2010 will 1

also improve the reliability and SOX compliance for revenue reporting. 2

c) Funding Requirements 3

The cost for Ledger Accounting System is $1.9 million.80 The estimate is based 4

upon the application calculation and tariff complexity and the total number of user screens. 5

F. Our Forecast Is Reasonable 6

As noted above, our capital requests for the individual SAM projects are based on individual 7

estimates of the cost necessary to replace the specific application with a new application having similar 8

or better functionality. Our estimates are validated by a review of our historical spending on past 9

capitalized software projects using function point analysis Throughout the IT industry, function point 10

analysis serves as an industry-standard method of determining the size, complexity and cost of 11

implementing portfolios of applications.81 Function point analysis takes into consideration numerous 12

factors, such as the number of inputs into a system, the number of outputs, and the number of 13

connections to other applications. When considering application portfolios that exceed 100,000 function 14

points, like that of SCE (see Table II-22 above), it is possible to derive the average new development 15

cost per function point. Depending on the industry, the average for new development of an application 16

is $2,654 per function point and can vary from $2,142 to $4,973 per function point.82 In a similar 17

manner, SCE can estimate the average implementation cost per function point based on the historical 18

implementation cost of similar software projects completed from 2000 through 2006. Based on this 19

analysis, the average implementation cost is $2,321 per function point.83 Thus, SCE’s average 20

implementation cost per function point is well within the industry limits. Using SCE’s historical 21

implementation cost per function point of $2,321, the SAM forecast would be in excess of $90 million. 22

80 See Workpaper entitled “Forecast Expenditures Ledger Accounting System.” 81 See IFPUG, International Function Point User Group who maintains the Function Point Counting Practices Manual, the

recognized industry standard for Function Point Analysis. 82 See Workpaper entitled “Applied Software Measurement-Capers-Jones,” p. 228. 83 See Workpaper entitled “IT CRT Projects 2000–2006 Application Cost per Function Point.”

74

SCE’s Software Asset Management forecast expenditures take into account additional details 1

from our Subject Matter Experts that are not embedded in the function point analysis. Our estimates 2

provide a reasonable basis of the cost to replace these systems and are less than our average historical 3

implementation costs for comparable systems. Our forecast is based upon our best understanding of 4

what it will take to refresh or reduce these obsolete systems, which is validated by a historical function 5

point analysis. 6

G. Avoided Software Expenditures Resulting From Enterprise Resource Planning 7

The purpose of this testimony is to demonstrate that replacing legacy applications under our pre-8

ERP approach versus consolidating functionality into an integrated ERP system substantiates the 9

avoided software expenditures of $254.4 million included in the ERP business case. The items related 10

to CSS were originally estimated in the 2006-2009 timeframe as part of the 2005 annual budgeting 11

process. These replacements were shifted to the 2013 to 2016 timeframe as a result of the ERP Release 12

4 deployment in 2013. The ERP cost effectiveness analysis only includes Avoided Software 13

Expenditures identified in the 2005 annual budgeting process because of the challenges of estimating 14

system replacements for over 300 applications. Figure II-10 below displays the 2005 to 2009 amounts 15

included SCE’s ERP business case. These amounts were based on: (1) the approved 2006 GRC capital 16

initially intended for implementing the related Software Asset Management projects from 2004 through 17

2008, (2) the approved 2006 GRC capital for upgrading the PeopleSoft Human Capital Management 18

System, and (3) the original estimates for Software Asset Management and the PeopleSoft Human 19

Capital Management System for 2009 now being replaced by ERP. In the 2006 GRC SAM testimony, 20

we estimated that approximately 100 legacy applications would be replaced or upgraded during the 21

2004-2008 period. The current ERP Project now estimates that approximately 300 applications 22

supported by IT will be replaced by the ERP System.84 As described above, a function point analysis 23

can be used to derive the average implementation cost per function point. Using the SAM methodology, 24

based on the age of the applications and the function point count, coupled with our historical 25

84 See Workpapers entitled “SCE Application Portfolio Analysis.”

75

implementation cost per function point we can approximate the cost SCE would have incurred if it chose 1

to replace approximately 300 applications independent of an ERP system. 2

Figure II-10 ERP Avoided Software Expenditures 2005-2009

(Nominal $000)

$0

$20,000

$40,000

$60,000

2005 2006 2007 2008 2009

ERP Avoided Software Expenditures 2005 2006 2007 2008 2009 Total

PeopleSoft Upgrade $4,300.0 $4,500.0 $5,500.0 $4,000.0 $5,500.0 $23,800.0SAM $20,500.0 $41,800.0 $47,400.0 $54,000.0 $55,500.0 $219,200.0

CSS Replacement Deferred to 2013 ($5,400.0) ($12,000.0) ($12,000.0) ($10,000.0) ($10,000.0) ($49,400.0)

Total $19,400.0 $34,300.0 $40,900.0 $48,000.0 $51,000.0 $193,600.0

Our analysis includes the capital expenditures approved in the 2006 GRC funding for SAM 3

($170.933 million) and the PeopleSoft system upgrades ($20.3 million) plus those applications now 4

being replaced by ERP that were not included in the original 2006 GRC testimony. In total, our 5

approximation is based on replacing roughly 300 applications included in the ERP footprint over the 6

2005 to 2020 time period. The analysis period is aligned to the last year of the ERP business case. 7

Also, SCE could not have independently replaced these applications over a short time period due to 8

available resources and how much work can be performed. This approach assumes that the more aged 9

and critical applications would be replaced before the younger applications, which is consistent with the 10

76

SAM methodology included in this testimony for the applications that are not in the ERP footprint. This 1

approach shows that the total estimated replacement expenditures would be approximately $794 million 2

by 2020. Figure II-11 below shows the approximated avoided software expenditures if SCE chose to 3

replace the roughly 300 applications under its pre-ERP approach through 2020. Figure II-11 also 4

includes the replacement costs over ten years after the initial replacement expenditures. Each 5

replacement would have a useful life between five and ten years, so for the purposes of this analysis, we 6

used the more conservative ten-year useful life and Figure II-11 shows replacement costs every ten 7

years. Our analysis demonstrates that the avoided software expenditures of $254.4 million included in 8

the ERP business case are based on a conservative approach. 9

Figure II-11 Practical Approach For Replacing Legacy Applications In ERP Footprint

(Nominal $000)

$0

$10,000

$20,000

$30,000

$40,000

$50,000

$60,000

$70,000

2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020

Year 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020Expenditure

Totals Per Year $0 $25,548 $46,375 $42,430 $48,836 $50,297 $51,023 $55,555 $48,163 $47,634 $47,209 $52,664 $62,364 $57,463 $56,771 $50,297 $51,023Replacement

Total $793,652

H. Conclusion 10

Our software applications are an integral part of our business operations and are necessary to 11

deliver service to our 4.8 million customers. The majority of applications identified as part of SAM in 12

the 2006 GRC are being replaced as part of the Enterprise Resource Planning (ERP) Project, which is 13

currently underway. For this 2009 GRC, the request for SAM funding will include the remediation of 14

applications that are considered outside of the ERP capability and will not be replaced through the 15

current ERP Project. These software applications are vital for to utility operations just like SCE’s more 16

77

tangible utility assets such as poles and transformers. Currently, our software assets suffer from the 1

same phenomenon of age-related degradation as do many of our more tangible assets. As we have 2

described, over 12 percent of our applications are more than 10 years old, and approximately 60 percent 3

of our applications have varying degrees of obsolescence due to technology or vendor support issues, or 4

to insufficient to lack of alignment with our changing business needs. Older applications are more 5

susceptible to obsolescence due to technology changes and discontinued vendor support, which 6

ultimately leads to risk of failure. Continued modification of older applications makes them more 7

complex and difficult to maintain, and further introduces greater chance for errors. We began the formal 8

SAM process in 2004 and must continue on an ongoing basis to ensure that our software assets are 9

managed diligently to minimize the business risk associated with obsolescence. 10

78

III. 1

NEW CAPABILITIES 2

A. Regulatory Policy & Affairs (RP&A) 3

1. O&M Workpaper Database (RP&A) 4

a) Introduction 5

This chapter describes SCE’s new GRC Operations and Maintenance (O&M) 6

Expense Workpaper Database. The O&M Workpaper database is necessary for the preparation of 7

SCE’s general rate cases, various compliance requirements, and the corporate budgeting process. 8

General Rate Cases (GRCs) are prepared and litigated according to the Commission’s Rate Case Plan. 9

The Commission’s Rate Case Plan (D.89-01-040), contains the Standard Requirement List of 10

Documentation Supporting a Notice of Intent (NOI) in Appendix B, which states on page B-22: 11

Include at least 5 years of recorded data for each FERC account used in the 12 development of the test year revenues and revenue requirement. Where 13 subaccounts and/or other than FERC accounts are used to develop test year 14 values, include at least five years of recorded data supporting those values 15 also. All data for expenses shall be stated in recorded dollars and dollars 16 inflation adjusted to a constant base year. The format shall be mutually 17 agreed to by the utility and DRA project managers. 18

Although SCE’s previous GRC O&M expense database had the capacity to meet 19

the minimum requirement, it had reached its content limit. We would have had to delete older data to 20

make room for new data before filing the 2009 GRC. Moreover, the limited functionality and 21

accessibility of the previous database created unnecessary burdens and bottlenecks for employees 22

assigned to general rate case O&M expense forecasts. 23

b) Description of the Previous Database 24

For the 2003 and 2006 GRCs, SCE used a Microsoft Access database. Access is 25

part of the Microsoft Office System, the basic interface objects – menus, toolbars, dialog boxes – work 26

the same as other Microsoft Office Applications. MS Access is a relational database where data is 27

stored as a number of tables. These tables consist of records and each record contains a number of fields 28

for data. MS Access allows the user to create forms and reports. A form shows one record in a user-29

designed format and allows the user to step through records one at a time. A report shows selected 30

79

records in a user-designed format, possibly grouped into sections with different kinds of totals 1

(including sum, minimum, maximum, average). There are also facilities to use links between tables that 2

share a common field and to filter records according to certain criteria or search for particular field 3

values. 4

Our GRC MS Access database was a desktop-based tool, built to aggregate and 5

produce standardized workpapers. All data was centrally stored and controlled for analysis and 6

managed by SCE’s Regulatory Policy and Affairs (RP&A) department. Once RP&A received the 7

FERC Form 1 data containing company expenses recorded in approximately 100 FERC accounts, the 8

data was divided into more than 450 GRC accounts within the MS Access Application. RP&A would 9

then print a hard copy of the data by GRC account and hand it off to each company business unit. The 10

business unit employees would then work on their GRC workpaper packages and return those hard copy 11

revisions to RP&A for processing in the Access application. Once the changes were manually entered 12

into the system and adjustments made to the data, RP&A would then print a revised hard copy of the 13

GRC workpapers for business units to check for accuracy. This cycle would be repeated a number of 14

times at each stage leading up to the NOI and the Application. The forecast O&M data was then loaded 15

into SCE’s Results of Operations Model. Eventually, the database would contain five years of recorded 16

expenses, plus a Test Year forecast (see Figure III-12). 17

80

Figure III-12 SCE GRC Revenue Requirement Process

Results of

Operations

O&M Forecast

Capital Tax

50-100 Users

O&M Database (400 Accounts - 5 years Recorded & Forecast)

FERC Form 1 (GRC Source Data

- 100 Accounts)

SCE’s General Ledger

(1) Problems with the Previous Database 1

Under the MS Access application, no more than one user at a time could 2

edit the database. For each general rate case, as we approached tendering the NOI and Application the 3

workload for RP&A became immense. Each business unit submitted several hundred pages of 4

workpapers to be distributed among a handful of RP&A employees for processing. It required a number 5

of employees to work through the night and resulted in significant amounts of overtime, creating a work 6

environment that was simply not sustainable. Meanwhile, the GRC witnesses and their staffs had to 7

wait for their data to be manually updated each time before they could continue their analysis and refine 8

their GRC Test Year forecasts. With internal deadlines fast approaching, SCE business units and RP&A 9

81

employees were constantly working under increasing amounts of pressure. The employees who ran the 1

Results of Operations (RO) model also had to print the workpapers, which are extremely voluminous. 2

This process repeatedly jeopardized the timely filing of SCE’s rate cases and the logistical challenge 3

was going to be more problematic for this 2009 GRC and beyond. Increasing numbers of SCE 4

employees are relocating to satellite facilities away from the corporate headquarters in Rosemead.85 5

These relocated employees need the ability to access their data from disparate locations to contribute 6

their parts of the general rate case. Because general rate cases are now a permanent fixture in the 7

company, we need to have a system in place that is sustainable from one case to the next and can 8

accommodate the employee dispersion. 9

In addition, ongoing compliance requirements argue in favor of preserving 10

the basis of the GRC forecast. For example, in SCE’s Test Year 2003 GRC, Assigned Commissioner 11

Wood issued a white paper authored by the Energy Division. This white paper used historical data some 12

ten years old, but unfortunately relied upon unadjusted FERC Form 1 data. It took SCE a great deal of 13

effort to develop accurate analysis to respond to the conclusions and order to file supplemental 14

testimony. It would be unfortunate if SCE were forced to delete GRC quality recorded and authorized 15

expense data because we had outgrown the MS Access database, only to have a similar request 16

presented to the company in the future. 17

While it would be easier to present a more summary-level presentation of 18

our forecast, SCE ultimately bears the burden of proof to demonstrate that our forecasts are reasonable. 19

SCE records electric expenses in approximately 100 FERC Accounts but forecasts the GRC in more 20

than 450 sub-accounts. We have concluded that this additional level of detail in our testimony and 21

O&M expense workpapers improves the quality of our evidentiary showing in general rate cases. I have 22

discussed the possibility of filing a more summary-level general rate case with the DRA – perhaps by 23

FERC Account alone. However, DRA has expressed a preference for the more detailed presentation of 24

SCE’s cases, and with that in mind we expect to continue to file future GRCs with the 450 or so 25

85 See SCE 10, Volume 1 for a detailed description of the necessary location of employees in regional facilities.

82

accounts. In addition, at least one Intervenor has expressed its appreciation for the organization of 1

SCE’s O&M expense workpapers. We believe there is great value in presenting a case that is clearly 2

understood by all Parties, and Commission decision-makers, so that the litigation can focus on the merits 3

of SCE’s request. 4

To successfully file future GRC applications, we needed a more robust 5

database that would have the ability to store more than five years of historical data, allow simultaneous 6

access by multiple users to edit and print their workpapers, and enhance the O&M Workpaper 7

preparation process by generating timely reports with accurate data. To comply with CPUC standards, 8

while preserving preceding case data, SCE created a database that now has the capacity to meet these 9

requirements. 10

c) Description of the New Database 11

The rate case team consulted with SCE’s Information Technology (IT) 12

department and developed the new O&M Workpaper Database, which is a Visual Basic Application for 13

use on the web. This database is a multi-user application that allows employees throughout the 14

company to simultaneously adjust and analyze data while producing consistent standardized workpapers 15

and providing enhanced functionality. 16

This new database has the capacity to retain 20 years’ of historical data, allowing 17

users to run reports on data from previous GRCs. This database also has an automated back-up feature 18

and disaster recovery capabilities to protect the data. 19

With the new database, SCE employees working on the GRC in regional facilities 20

are now able to access their data from these remote locations using the web, which allows them to 21

develop and refine their parts of the case without having to repeatedly travel to SCE’s corporate 22

headquarters in Rosemead. 23

Each user now has access to input their own data and adjustments directly and 24

business units are no longer dependent on RP&A to revise data and workpapers. This improvement 25

eliminates delays and enables the business unit employees to perform real-time analysis and reporting. 26

Testimony reports, which were previously developed individually by each business unit, are now 27

83

standardized. Users can directly filter, print and export data to Microsoft Excel for additional analysis. 1

Users also have the ability to import data from external sources. 2

Additional controls, security and approval processes have been built into the new 3

system to ensure centralized control while decentralizing data access. This capability minimizes 4

potential errors when developing SCE’s O&M expense for the Results of Operations model. When 5

users are set up to use the system, they may only access data for which they are directly responsible. 6

The home screen allows the user to navigate easily to make recorded year adjustments, future year 7

adjustments, Test Year forecast, and print reports and workpapers. The users can make changes and 8

adjustments to their data and then submit those changes for approval to GRC Case Management. The 9

system then validates the data to ensure its integrity. Only approved changes are incorporated into the 10

workpapers. If a user is not ready to submit their changes for approval, they can save them as a draft 11

and run various scenarios without affecting data that has already been approved. Once changes are 12

approved, they are added to the GRC Results of Operations. Those changes become immediately 13

available to the users so they can continue to analyze that data, eliminating the need to wait for RP&A to 14

input and process the data, print a hard copy and send out the revised workpapers. This database also 15

has a “Notes and Updates” section allowing RP&A to communicate deadlines and monitor status to all 16

employees accessing the system. 17

(1) Cost Estimate & Reasonableness of the New Database 18

Because of the unique design requirements of this database – widely 19

accessible to multiple employees, support of SCE’s Results of Operations model – we could not 20

continue to use the Microsoft Access software, or any other “off the shelf” application. We enlisted 21

SCE’s IT department to manage and build the new application. Also, we retained the Utility Consulting 22

Group (UCG), the architects of our Commission-mandated Results of Operations forecasting model. 23

This model is used by both SCE and Commission personnel when developing and authorizing revenue 24

requirements. UCG was asked to plan the new database, provide quality control during its development 25

and complete testing of the new application. UCG, together with SCE personnel, developed the 26

business requirements for the developers to use when building the application. Next, they prepared 27

84

more than 100 test scripts for the application to ensure the application performed as intended, before 1

being made available to employees. They subjected the application to hundreds of hours of rigorous 2

testing and developed modifications to the database when they observed problems. While this quality-3

control overlay undeniably added to the final cost of the Application, we felt the need to confirm the 4

accuracy of the Application to be worth the incremental expenditures. 5

SCE’s IT department selected Infosys Corporation to develop the 6

application, with some programmers located in SCE facilities for coordination, but the majority of work 7

performed offshore. Table III-23, below displays the comparative hourly rate of programmers in 8

California compared to offshore. SCE customers realize the benefit of such cost-saving steps. Also, the 9

cost of this application is further corroborated by a comparison of historic costs to build other SCE 10

applications, as measured by cost-per-function point.86 SCE’s historic average cost-per-function point is 11

$2,321. At my request, SCE’s IT department calculated the number of function points in the GRC 12

Workpaper Database, on an as-built basis. The analysis revealed that the database is comprised of 1,007 13

function points. When multiplied times SCE’s historic average of $2,32187 per function point, the 14

expected cost would be $2.337 million, only 8 percent less than the actual as-built cost. In my 15

judgment, the cost of the GRC workpaper database should be found reasonable for cost recovery. 16

Table III-23 GRC Workpaper Database

Cost Description

Avg. Labor Rate Employees Hrs Cost Employees Hrs

Recorded & Forecast

Cost Total $SCE IT - Labor 65.00$ 11 3,342 217,233$ 13 2,304 149,748$ 366,981$ Onshore Contract - Labor 75.00$ 3 849 63,672$ 8 1,273 95,508$ 159,180$ Offshore Contract - Labor 39.00$ 25 15,259 595,110$ 16 10,173 396,740$ 991,850$ Software Licenses 9,800$ 8,000$ 17,800$ Hardware -$ 49,900$ UCG Costs - Labor 794,338$ 235,758$ 1,030,096$

Total 39 19,450 1,680,153$ 37 13,750 935,654$ 2,565,907$

2006 2007

86 Function Point Analysis (FPA) as a measure recognized by the International Organization for Standardization (ISO) to

quantify the functional size of an information system. The functional size reflects the amount of functionality that is relevant to and recognized by the user in the business. It is independent of the technology used to implement the system. Function Point Analysis expresses the functional size of an information system in a number of function points. See SCE-5, Volume 3, Part 1, for further discussion of Function Point Analysis.

87 See SCE-5, Vol. 3, Software Asset Management (SAM).

85

IV. 1

EXPANDED CAPABILITIES 2

A. Power Procurement Business Unit (PPBU) 3

1. PPBU Cost Estimation Methodology 4

The Power Procurement Business Unit (PPBU) has used a high-level estimation 5

methodology to develop its forecast of its capital costs associated with its projects that are undergoing 6

substantial development beginning in 2007 and beyond, as indicated in the discussion of those projects 7

below. This methodology includes looking back several years at PPBU projects of sufficient scale to be 8

comparable to the identified capital projects. These projects will be categorized using the following 9

categories: 10

• Simple Commercial-off-the-Shelf (COTS) Product 11

• Medium Complexity COTS Product 12

• High Complexity COTS Product 13

• Simple Development 14

• Medium Complexity Development 15

• High Complexity Development 16

Complexity is defined by the functionality of the application being purchased or 17

developed as well as by the integration points and data being transferred between systems. 18

The workpapers to this Exhibit provide a full description of PPBU’s methodology for 19

determining the range of costs associated with each generic COTS product (and each customized 20

development product), and the types of systems upon which the generic cost estimates are based.88 As 21

explained in PPBU’s workpapers, for each generic COTS product, estimates for incremental hardware 22

costs are made based on the number of servers estimated to be required for application development, 23

testing and production. Additional estimates are made for the software licensing cost, database licensing 24

cost, vendor implementation and support cost, information technology implementation support cost, 25 88 See PPBU Workpapers to this Exhibit, in the Section entitled “Forecasting Methodology,” for a description of the range

of costs determined for each generic project type.

86

business unit implementation support cost, and integration and customization cost. The magnitudes of 1

the estimates are based on the projected complexity level of the COTS product. 2

For the customized development projects, the project will include the following life cycle 3

activities:89 4

• Requirements gathering 5

• High-level planning 6

• Prototype development 7

• User review and analysis of prototype development 8

• Detailed design 9

• Development 10

• Testing 11

• Training 12

• Implementation 13

A high complexity development project would take approximately one year to complete. 14

A medium complexity development project would take approximately six months to complete. A 15

simple development project is defined as a project that would take approximately three months to 16

complete. For each generic development-type project, estimates are made for incremental hardware 17

costs, database licensing cost, information technology implementation support cost, business unit 18

implementation support cost, and integration cost. 19

As described in the discussion of the individual capitalized software projects below, each 20

capitalized project was mapped to a generic category or combination of generic categories based on the 21

project’s perceived complexity and whether PPBU anticipates that a COTS product will be available to 22

meet the particular requirements. Based on any key differences between the generic category and the 23

particulars of a proposed project, adjustments were made to the estimates. These adjustments, described 24

in the workpapers for each project, are based on PPBU’s current understanding of: (1) the complexity of 25

89 See Workpapers to this Exhibit, in the section entitled “Forecasting Methodology.”

87

the initiative, (2) the likelihood of leveraging an existing product, (3) the integration points, (4) the type 1

of data transferred amongst systems, (5) the volume of data transferred, (6) the data validation required 2

through the transfer, and (7) the transfer intervals required. 3

Because many of the projects are driven by anticipated regulatory requirements that have 4

not been fully defined or specified (if at all) at the time of this filing, it is necessary to make high-level 5

assumptions in order to forecast project costs. As the requirements for the projects discussed below are 6

better defined by regulatory agencies over time, the assumptions and associated forecasts may need to be 7

updated to reflect the actual requirements and SCE will make this information available as deemed 8

appropriate by the CPUC. 9

2. Net Energy Metering Project (NEM) (PPBU) 10

a) Introduction 11

Currently the Renewable and Alternative Power (RAP) department of PPBU uses 12

a Microsoft Access database to track information on SCE customers and the renewable energy projects 13

that are installed under the Net Energy Metering (NEM) tariffs. Solar photovoltaic (PV), wind, dairy 14

biogas, and fuel cell systems are all eligible for NEM; however, the great majority of systems installed 15

are PV. The NEM database, which includes specialized workstation software, is the tool by which RAP 16

manages the review and approval of requests to interconnect NEM projects with the SCE electric 17

system. The functionalities of the database include searches, queries and production of reports on NEM 18

activity for internal clients and regulatory requirements. 19

This project will convert RAP’s Access database system into a more secure and 20

robust information technology platform. The NEM system is also expected to need upgrading to support 21

the California Solar Initiative (CSI), a 10-year long program managed by the CPUC to offer incentives 22

for the installation of solar power. All PV projects which receive CSI funding must go through the RAP 23

department’s interconnection approval process. To effectively administer the CSI in SCE’s service area, 24

as well as to effectively respond to customer queries, SCE’s Customer Service Business Unit (CSBU) 25

call center representatives will require access to NEM data in greater volumes than RAP’s current 26

Access database can accommodate. 27

88

b) Background 1

(1) Net Energy Metering Requirements 2

The NEM project is required to allow SCE (through RAP) to meet the 3

statutory 30-day time limit for approving NEM applications.90 RAP personnel must also be able to 4

effectively process a large volume of customer applications for service under the NEM tariff, and to 5

safely integrate dispersed rooftop solar systems into the SCE electric distribution system. The NEM 6

project will allow SCE to meet the service needs and expectations of utility customers who have made 7

the significant investment required to install solar systems at their homes and businesses. 8

As part of Governor Schwarzenegger's $3.3 billion, Million Solar Roofs 9

Program, California has set a goal to create 3,000 MW of new, solar-produced electricity by 2017. The 10

CPUC, through the CSI, will manage a $400 million program over the next decade to offer incentives 11

for existing residential homes and existing and new commercial, industrial, and agricultural properties to 12

install and operate solar power technology. The CSI is projected to increase the number of NEM 13

applications.91 The ability of RAP to process the increased volume of applications will have a direct 14

bearing on the success of the CSI. If SCE customers respond fully to CSI funding availability, in the 15

next 10 years several hundred more megawatts of solar power will be interconnected – which is multiple 16

times the current total connection of 52 MW. 17

(2) The Net Energy Metering Project 18

RAP tracks 30 parameters of customer information, solar system 19

specifications and installing contractor information for each PV project. In addition to using the NEM 20

Access database to support the new project review function, RAP frequently utilizes the existing project 21

data to process a new interconnection agreement when the existing customer moves out and a new 22

customer moves in. 23

90 See Cal. Pub. Util. Code § 2827. 91 See Exhibit SCE-08, Vol. 3 (PPBU Renewable and Alternative Power), Chp. I, Section C.6.

89

This project will convert the capabilities embodied in the current system 1

into a more secure and robust information technology platform. It will provide greater access to 2

simultaneous users in order for CSBU call center representatives to access the system as they respond to 3

NEM requests due to the CSI – something that cannot be accommodated by the current Access-based 4

system. This ability to access the system will also allow the call center representatives to effectively 5

respond to customer queries on CSI and NEM. 6

Another critical part of the Net Energy Metering program is advising and 7

updating SCE customers and their installing contractors on the status of the interconnection and 8

approval process for their projects. This is currently accomplished by responding to telephone and e-9

mail queries. If solar power development in SCE’s service area expands to the degree envisioned by the 10

CSI, the sustainability of this labor-intensive process is doubtful. This project will provide this aspect of 11

service to solar customers by adopting a Web-based system to allow customers to track the 12

interconnection approval status of solar projects on-line. This will increase the efficiency and 13

effectiveness of the service, and will likely result in greater customer satisfaction with the service. 14

In addition to the need to provide access to a substantially greater amount 15

of simultaneous users, it is anticipated that at current rates of new PV project interconnection, the sheer 16

number of project files may cause the existing database to reach its limits of functionality within the 17

next one to three years, requiring that the NEM database be migrated to a different platform. 18

Based on the requirements outlined above, this project will convert the 19

existing Microsoft Access database-based application to an Oracle database with .NET web-based front-20

end user interface and back-end reporting capability. The application would also be converted from a 21

single-user system to a multi-user system. Finally, there would be an interface to the SAP suite of 22

system products, i.e., the Enterprise Resource Planning (ERP) product for SCE that is currently 23

undergoing implementation, in order to manage the billing requirements of NEM customers.92 24

92 See Exhibit SCE-09 for a description of SCE’s ERP Project.

90

c) Vendor Selection Process 1

Once the specifications for the project solution have been developed, PPBU will 2

determine if it needs the assistance of outside vendors to complete the project. If it does, the vendors 3

will be evaluated based on the following criteria: 4

• The ability of the vendor to meet business requirements now and in the 5

foreseeable future; 6

• The vendor’s presence in the software marketplace; 7

• General and technical requirements; and 8

• Cost competitiveness. 9

d) Project Costs and Schedule 10

This system requires the following main functionality: Customer Information 11

(e.g., name, generation type, capacity); Work Flow Management (interconnection process); Document 12

Management (contracts and engineering specifications); Work Management (tracking interconnection 13

costs) and Reporting. There will need to be the capability to handle the anticipated number of NEM 14

Customers; and allowance for CSBU call center representatives to access the NEM Customer 15

information. The requirements are fairly generic and thus PPBU anticipates that COTS products will be 16

available to meet these requirements. Based on the anticipated function points associated with the NEM 17

requirements, it is anticipated that the project will be of medium complexity. The primary drivers of 18

complexity in this project include: (1) multiple users accessing the system; (2) work flow processing; 19

and (3) need for customized reporting. The total cost of this project, including a requirement for 20

redundancy (a second backup database) and failover capability (a mechanism to automatically access the 21

backup database if the primary database fails), is estimated to be $3,437,500.93 PPBU expects that this 22

project will be implemented in 2009 and 2010. 23

93 The specific calculations resulting in this forecast are provided in the Workpapers accompanying this Exhibit.

91

Table IV-24 Net Energy Metering Project

2009-2010 Forecast Capital Expenditure

Year Forecast Capital Expenditure

2009 $2,200,500

2010 $1,237,000

Total $3,437,500

3. Distributed Generation Project (PPBU) 1

a) Introduction 2

The Customer Generation section of the RAP department uses a Microsoft Access 3

database to track information on SCE customers and the distributed generation (DG) projects that SCE 4

customers install under the provisions of SCE’s Tariff Rule 21. The DG projects that are interconnected 5

to SCE’s electric system employ a wide range of technologies (both renewable and non-renewable), and 6

vary in size from small pre-engineered “package” generating systems smaller than 100 kW to large 7

industrial-scale cogeneration projects of 50 MW or larger. 8

RAP’s existing DG database, which includes specialized workstation software, 9

lacks versatility as a management tool for inter-departmental work flow. It also cannot track RAP’s 10

review of QF repower (for renewable generators) interconnections, engineering time and labor costs, 11

and generator location with enough precision to match this information to the distribution circuit 12

mapping of SCE’s Transmission and Distribution Business Unit (TDBU). When the current database 13

for the NEM program is migrated to a new stand-alone platform, or incorporated into SAP, as discussed 14

in Section H of this chapter, the DG database would remain as an unsupported system in RAP. For 15

these reasons, RAP plans to upgrade the DG database and associated applications. 16

b) Background 17

(1) Distributed Generation Requirements 18

Except as described below, DG projects that are interconnected to SCE’s 19

electric system under Rule 21 generally serve on-site customer load, with any power exports to the SCE 20

92

system confined to brief, uncompensated occasional exports. RAP coordinates and manages SCE’s 1

review and approval of requests to interconnect DG systems.94 RAP is also responsible for preparing 2

and executing agreements for engineering studies, interconnection, and construction of new DG 3

facilities.95 4

The evolution of the California electricity business and regulatory 5

environment has resulted in the need for RAP to review and approve interconnection of new categories 6

of projects that export power to the grid on a continuous basis. As QF projects constructed in the 1980s 7

and 1990s reach the end of their contracts, and SCE finds that its customers benefit from new power 8

purchase contracts, RAP works with QF power producers who are “repowering” their projects with new 9

generating units to allow them to be interconnected to the SCE electric system (as DG projects). During 10

2006, the CPUC ordered the expansion of the availability of Net Energy Metering for renewable 11

generation installed in combination with non-renewable DG projects.96 These orders have created the 12

need for SCE to review and approve special interconnection and metering schemes to allow tariff 13

administration for these “combined technology” projects. Lastly, AB 1969 requires utilities to purchase 14

power from a new category of renewable generation, installed by water treatment agencies, that will be 15

capable of exporting surplus power to the utility grid.97 For all of these projects, RAP performs the 16

same management and coordination role as it does for non-exporting DG. 17

(2) The Distributed Generation Project 18

RAP’s current DG database and its associated applications are used by 19

RAP to track approximately 40 different parameters of customer information, generating facility 20

specifications, and milestones for review, approval, and collection of both review fees and facilities 21

charges for each project in the database. RAP’s DG database conversion project will convert the 22

capabilities embodied in the current system into a more secure, robust and supported information 23

94 See Exhibit SCE-08, Vol. 3 (PPBU Renewable and Alternative Power), Chp. I, Section C.6. 95 See id. 96 See D.04-03-017 and D.05-08-013. 97 See Exhibit SCE-08, Vol. 3 (PPBU Renewable and Alternative Power), Chp. I, Sections B.4. and C.6.

93

technology platform. The new database has the functionality to track RAP’s review of QF repower 1

interconnections, engineering time and labor costs, and generator location with enough precision to be 2

matched to TDBU distribution circuit mapping. 3

An improved database and associated applications would allow more 4

efficient preparation of regulatory reports regarding utility costs incurred in reviewing DG 5

interconnections, and provide greater usefulness to TDBU in its efforts to assess grid impact of DG, 6

especially as the number of generators (and “penetration” of DG on the grid) increases. Finally, 7

incorporation of inter-departmental workflow management capability for use in QF repower reviews 8

will directly support the Company’s on-going efforts to procure renewable energy on behalf of its 9

customers. 10

Based on the requirements outlined above, this project will convert the 11

existing Microsoft Access database-based application to an Oracle database with .NET web-based front-12

end user interface and back-end reporting capability. There would be an interface to the SAP suite of 13

system products, in order to manage the billing requirements for DG customers. 14


RAP will determine if it needs the assistance of outside vendors to complete the 16

project. If it does, the vendors will be evaluated based on the following criteria: 17







This system has requirements similar to the NEM project, and could be a module 24

within the COTS selected for that system. This system requires the following main functionality: 25

Customer Information, Work Flow Management, Document Management, Work Management and 26

Reporting. The main difference between the DG system and the NEM system is that the number of DG 27

94

projects that the system will need to be able to handle will be much less than the number of NEM 1

projects that the NEM system will need to handle. The DG project (like the NEM project discussed in 2

Section H) will be a medium complexity COTS project. Since the project records customer information 3

that is critical to retrieve on demand, there are requirements for redundancy and failover capability. This 4

project is estimated to cost $2,012,500. PPBU anticipates that the project will be implemented between 5

2009 and 2010.98 6

Table IV-25 Distributed Generation Project



2009 $1,300,500

2010 $712,000

Total $2,012,500

4. Entegrate (PPBU) 7

a) Introduction 8

The Entegrate project is an ongoing project to implement a required upgrade for 9

PPBU’s SunGard Nucleus energy trading and risk management (ETRM) product. The project is 10

expected to be completed in 2007. The new Entegrate product will provide additional functionality and 11

improved interfacing capability to support the evolving demands of the energy market as well as the 12

CAISO’s market design changes resulting from its Market Redesign and Technology Upgrade (MRTU) 13

initiative that have been identified to date. 14

Entegrate is necessary for continued Energy Supply and Management (ES&M) 15

trading operations. The current vendor, SunGard, will discontinue maintenance of the Nucleus product 16

line in the future. Entegrate will be aligned with the vendor’s stated strategic direction for future 17


95

product development, thus ensuring that Entegrate will continue to receive the vendor’s support for on-1

going product improvement. 2

The technology platform of Entegrate will also ease implementation of future 3

technology enhancements required to meet the evolving PPBU business requirements driven by energy 4

market demands, new CAISO market design rules, and new negotiated power procurement contracts 5

that will have expanded and complex provisions for settlement and payments. This platform, combined 6

with associated vendor-developed and maintained interface products, will enable PPBU to develop cost-7

effective solutions to meet new business requirements for energy trading and risk management and 8

reduce maintenance costs. 9

b) Background 10

The installation of SunGard Nucleus, the current ETRM system, was necessitated 11

by SCE’s return to energy procurement in January 2003. Following the base installation, SCE 12

incorporated a number of enhancements to the core system to accommodate unique business needs 13

arising from SCE’s energy trading practices. The base operating practices incorporated in the SunGard 14

Nucleus system conformed to SCE’s Commission approved Procurement Plan. For example, the 15

practices included regulatory authorizations for SCE’s energy-related transactions as well as limitations 16

on various trading and hedging activities. Over time, select procurement limitations have been relaxed. 17

This resulted in PPBU modifying the Nucleus system to enhance system functionality. 18

(1) PPBU Business Functions Supported by Entegrate 19

The specific business functions supported by Entegrate include: 20

• Administration of contract-related data required to support trading, 21

risk management, settlement and invoicing tasks, 22

• Capture and management of contracts and power, transmission, gas, 23

transportation and financial trades made with counterparties, 24

• Reporting of a wide range of risk management issues, e.g., physical 25

positions per commodity, mark-to-market evaluations and credit and 26

collateral margin management, 27

96

• Determination and confirmation of invoice amounts (receivables) and 1

payment obligations for all business transactions with counterparties, 2

and 3

• Business and financial reporting, including periodic corporate 4

reporting and responding to data requests from regulatory agencies and 5

other external entities. 6

(2) The Entegrate Program 7

The work to implement Entegrate as the new ETRM will be substantially 8

completed in 2007. 9

Immediately after the base migration effort from Nucleus to Entegrate is 10

completed, additional functionality to support PPBU’s new business functions associated with 11

management of emissions trading will be installed. As MRTU market design and related business rules 12

continue to evolve, additional functionality will be required of the Entegrate system. Additional 13

requirements will develop by 2009 to support potential CAISO and CPUC-mandated changes, such as 14

accelerated payments protocols, Virtual Bidding, and capacity markets. In addition, integration efforts 15

with other newly-installed software will be driven by MRTU and future market designs. 16

Enhanced system support for emissions trading will also be an on-going 17

effort, as PPBU continues to identify optimal methods and strategies for managing SCE’s SO2 emissions 18

credits, Renewable Energy Credits, and in the future GHG emissions credits, for the benefit of SCE’s 19

customers. With respect to integration with the SAP suite of system products (the Enterprise Resource 20

Planning product for SCE that is currently being implemented), PPBU anticipates that, at a minimum, 21

Entegrate will need to be integrated into the corporate financial application(s) of SAP. 22

c) Project Benefits 23

PPBU will use Entegrate to manage the purchases of various energy products and 24

services necessary to ensure adequate power is available for SCE’s customers. These products and 25

services include: power trades, gas purchases, spot purchases of power transmission line services for 26

specified periods, and gas pipeline transportation and storage services. 27

97

Under certain circumstances, SCE may have an excess supply of power available 1

as compared to its forecasted load for a given period. In these cases, PPBU determines the amount of 2

surplus power that can safely be sold (to offset power procurement and generation costs) while still 3

meeting SCE customers’ load. These sales transactions will be captured and managed in Entegrate to 4

support applicable risk management, settlement, payment, and other financial management business 5

functions. 6

PPBU conducts various financial transactions as cost containment measures, e.g., 7

exchange options, futures, swaps and swing swaps. The capture, management and continuous valuation 8

of these transactions are essential to ensure effective hedging strategies are executed. Entegrate will 9

support all of these aspects of financial trades. 10

Lastly, SCE has emission credits based on historical ownership of various power 11

plants. These credits are corporate assets that will be leveraged for the benefit of SCE customers. These 12

credits may be traded for financial considerations or applied to the operation of power plants providing 13

energy for SCE’s customers. PPBU management of these emissions credits entails multiple business 14

functions, e.g., valuation, spot sales, longer-term use arrangements with counterparties, application to 15

generating plants and extensive reporting. Entegrate will provide the platform for managing these 16

business functions. 17

d) Vendor Selection Process 18

PPBU needed to upgrade the current Nucleus ETRM in order to provide 19

additional functionality and improved interfacing capability to support the evolving demands of the 20

energy market and MRTU design changes. PPBU could not modify Nucleus to accommodate the 21

changes given that the original vendor, SunGard, will discontinue maintenance and support of Nucleus 22

in the near future. For a new ETRM, PPBU had to consider whether to continue to utilize a SunGard 23

product or go with an ETRM application from another vendor. PPBU selected the new SunGard 24

product Entegrate based on the following reasons: 25

• The ability of Entegrate to meet current and potential future requirements for 26

PPBU energy trading and risk management, 27

98

• Vendor’s commitment to support Entegrate in response to MRTU, and 1

• Vendor’s knowledge of SCE based on past working experience. 2

e) Project Costs and Schedule 3

The work to implement Entegrate as the new ETRM will be substantially 4

completed in 2007. PPBU anticipates that it will incur $1,700,000 of capital expenditure in 2007 to 5

complete the implementation and make the system operational. The activities to be accomplished 6

during this time will include: 7

• Complete deployment of production hardware and software, 8

• Data migration from Nucleus to Entegrate, 9

• Systems stress testing, 10

• Testing and validation of operations and reports, and 11

• Entegrate “Go Live” on August 30, 2007. 12

Table IV-26 Entegrate Project

2007 Forecast Capital Expenditure

Cost Type 2007 Forecast Expenditure

SCE IT Implementation & Integration $220,000

Contractor Implementation & Integration $290,000

Business Unit Implementation & Testing $40,000

Vendor Customization and Consulting $650,000

Hardware/Software $500,000

Total $1,700,000

99

B. Transmission and Distribution Business Unit (TDBU) 1

SCE’s Transmission and Distribution Business Unit (TDBU) work consists of engineering, 2

design, new construction, replacement, maintenance, and operations of approximately 3,200,000 3

electrical assets across 50,000 square miles of territory. These electrical assets include large and small 4

substations and transmission and distribution circuits that provide for the safe and reliable delivery of 5

power from generating stations to 4.8 million residential, commercial, and industrial customers.99 6

In conducting its work, TDBU follows management principles that establish the highest 7

priorities for public and employee safety, service reliability, and compliance with laws and regulation. 8

In Exhibit SCE-03, TDBU is asking the Commission to approve $555.1 million (constant 2006 dollars) 9

in O&M Expenses (for Test Year 2009) and $10.9 billion (nominal dollars) in Capital Expenditures 10

(cumulative from 2007 to 2011) to meet these and other management priorities - including current safety 11

performance, avoidance of serious degradation of service reliability, and fulfillment of maintenance and 12

inspection obligations.100 13

A key enabler for the success of these efforts will be TDBU’s information technology systems 14

that support its core work. Most of the Information Technology in support of TDBU’s primary work 15

processes (engineering, design, construction, and maintenance) resides outside SCE’s company-wide 16

ERP project101 in either “bolt-on” systems (i.e., those software applications that exist outside ERP and 17

are interfaced or share information with ERP) or the ongoing maintenance and enhancement of legacy 18

systems. This testimony discusses two software-related projects to substantially enhance or replace 19

SCE’s current systems and processes in the areas of electrical asset mapping and field tools supporting a 20

mobile workforce. As a result, TDBU is proposing individual projects to address the needs in each area, 21

with a funding request of $8.63 million (constant 2006 dollars) in O&M expenses for Test Year 2009, 22

and $38.95 million in Capital expenditures over the rate case cycle. Operational Technology -projects 23 99 See SCE-03, Volume 1, Section A Part 2, for detailed information on the extent of TDBU’s network, and on TDBU

management priorities. 100 See SCE-03, Volume 1, Section C. 101 “ERP” stands for Enterprise Resource Planning, for which SAP is the primary application, supplemented by two “Bolt-

Ons,” a Scheduling Tool (Click), and a Graphical Design Tool (Vendor selection underway). See Exhibit SCE-09.

100

affecting system operations are being addressed by the Energy Management System (EMS), the 1

Centralized Remedial Action Scheme (C-RAS), Distribution Automation, Distribution Control and 2

Management System (DCMS), Data Beyond SCADA, Phasor Measurement and Grid Stability Control 3

System, and Critical Substation Video Surveillance testimonies and are presented in Exhibit SCE-03, 4

Volume 03, Chapter 5. 5

The following sections of this Volume contain separate discussions covering mapping and 6

supporting a mobile workforce. Both sections contain an introduction and are divided into five parts, 7

presenting (i) a description of the desired technology in each area, and the importance of that technology 8

to safety, reliability, and compliance, (ii) a description of the current technology, (iii) a discussion of the 9

gaps between the desired technology and the current system, and of how the new technology will close 10

the gaps, (iv) a description of how the proposed applications will improve existing tools, enhancing 11

safety, reliability, and compliance, and (v) a description of the individual project approaches, schedules, 12

costs, and a plan to quantify safety, reliability, compliance, and productivity (if applicable) benefits for 13

inclusion in subsequent rate case cycles. 14

1. Comprehensive TDBU Geographic Information System 15

SCE’s Transmission and Distribution Business Unit (TDBU), other business units within 16

the Company and organizations outside of SCE (various Federal, State, county and city entities, fire and 17

police departments, emergency response organizations and contractors) rely upon or request data-rich 18

maps maintained by TDBU. In various forms, these maps show the physical location of SCE’s electrical 19

assets together with relevant information about those assets and the surrounding geography. These 20

multiple layers of data allow the user to visually survey SCE’s transmission and distribution network 21

and all related information together in one place and in as much detail as is needed. Such information 22

generally falls into four broad categories: (i) geographic location (latitude and longitude), (ii) site 23

specific information (e.g., physical characteristics of the geographic location, local ordinances affecting 24

work practices, or SCE’s property rights at the asset location), (iii) physical characteristics of the asset 25

(e.g., height of pole, conductor type and size, construction design, or transformer size and voltage class) 26

and, (iv) electrical connectivity data (e.g., whether a circuit is energized or not or amount of electrical 27

101

load being carried by the asset). Each of the above listed categories provides vital information for 1

ensuring employee and public safety, compliance with state and federal regulations, and electrical 2

service reliability. 3

Currently, TDBU has multiple mapping processes and systems for gathering, storing, and 4

displaying vital asset data. These include Distribution Facility Inventory Maps (FIMs), Transmission 5

FIMs, Substation maps, Circuit maps, Streetlight Maps, and Line Clearing maps. Each of these systems 6

uses a different method of projection for converting a three-dimensional physical location to a two-7

dimensional map display. Additionally, each of these systems relies upon a different street and public 8

structure landbase.102 Further, these systems are based on different software applications (e.g., circuit 9

and streetlight maps on GE Smallworld GIS, transmission and distribution FIMs on Autodesk’s 10

AutoCAD, line clearing maps on Microsoft Access) or are relegated to paper records (e.g., substation 11

maps). These disparate mapping systems and processes create operational challenges that may 12

negatively affect safety and reliability performance. 13

By having multiple unrelated mapping systems, retrieving needed data is complex and 14

can result in extracting information that does not give the full detail required to perform the work safely 15

and keep our electrical system reliable. Likewise, when new information is provided on paper from the 16

field to the department responsible for updates, it increases the potential for translation errors and 17

significant quality assurance (QA) efforts are undertaken to minimize such errors. These delays in 18

recording map changes means that at any point in time, some number of maps will be out of date thereby 19

making the map inconsistent with the actual configuration of the electrical system. As will be discussed 20

further, this reality has the potential to place SCE employees, emergency responders, and the general 21

public at risk of injury, and extends the time needed for restoration/recovery in the event of an 22

unplanned outage. Today’s mostly paper-based system for recording and entering changes to the 23

mapping system is limited by the need to physically move documents from the field to a service center, 24

102 The street and public structure landbase is a mapping backdrop on which the assets are placed such as Thomas Brothers

or Delorme.

102

from a service center to the central mapping office, and within the central mapping office to the actual 1

transcriber. 2

Currently, SCE has no single system in place today that is individually capable of 3

managing the data that TDBU requires to adequately meet all of its needs. As will be discussed further 4

in this testimony, the disparate systems and methods create inaccuracies and timing issues that can affect 5

employee and public safety, electric system reliability, and compliance. 6

The problems created by the disparate systems are compounded by the pressures resulting 7

from the growth in new customers and electrical load demand, infrastructure replacement and asset-8

maintenance programs. As a result, TDBU needs to implement a single comprehensive GIS-based 9

mapping system to incorporate all of this information and make it readily available to those who need it 10

so as to ensure that the limitations of these disparate systems are resolved and do not become an 11

impediment to SCE’s infrastructure replacement and load growth related work. 12

The testimony is organized as follows: First, we will describe a comprehensive GIS-13

based mapping system and show the critical links between mapping information and safety, compliance 14

and reliability. Second, we will describe TDBU’s current mapping systems, the type of information 15

being collected, and ways in which the information is used. Third, we will outline information gaps and 16

data quality issues resulting from TDBU’s current systems, with specific examples, and show how a 17

comprehensive GIS-based mapping system will help resolve those issues. Fourth, we will describe how 18

installing a Comprehensive TDBU Mapping System will enable additional functionality in existing tools 19

thereby enhancing reliability. Fifth, we provide a description of the proposed project – including 20

sections on both the pilot and the long-term solution. 21

The funding of the TDBU capital of $21.45 million is being requested within this 22

testimony. The funding of $1.3 (constant 2006 dollars) million for IT O&M Test Year costs is being 23

requested in IT’s testimony in Exhibit SCE-05, Volume 2. The funding of $5.77 million (constant 2006 24

dollars) for the TDBU O&M Test Year costs is being requested in TDBU’s testimony in Exhibit SCE-25

03, Volume 2. 26

103

SCE will provide information regarding the proposed project costs, schedule, and our 1

plans to put in place metrics to determine the safety, reliability, compliance, and productivity or capacity 2

benefits associated with the comprehensive mapping system in preparation for the subsequent rate case 3

cycle. 4

a) Description of a Comprehensive Mapping Information System 5

As it relates to an electric utility, a modern mapping system consists of two 6

elements: first, a computer-based geographic mapping software application (commonly known as a 7

Geographic Information System, or GIS) that allows the user to selectively overlay information about a 8

utility’s electrical system assets on a graphically displayed map or print-out; and second, the work 9

processes required to effectively operate the mapping system and maintain comprehensive asset data. A 10

Comprehensive Mapping System contains four primary categories of vital information about an asset: 11

• Geographic Location: the point on the earth where the asset is located, based 12

on latitude and longitude, along with surrounding geography 13

• Site-specific conditions: information about the site, such as sandy or hard 14

soil, maritime exposure, sloped ground or flat, congested city area, restricted 15

access, high fire area, permit requirements, rights-of-way requirements and 16

conditions, and noise or traffic restrictions on time of day work may be 17

performed 18

• Physical characteristics of the asset: information about the asset, such as pole 19

vintage and class, pole height, framing, conductor type and size, transformer 20

class and size 21

• Electrical Connectivity: The electrical network of which an asset forms a part 22

(beginning with a Major Substation, over Transmission Lines to Distribution 23

Substations, over Distribution Primary and Secondary Circuits, to individual 24

residential, commercial, or industrial customers) 25

A GIS-based Comprehensive Mapping System allows the user to input or retrieve 26

these key pieces of information about an asset by selecting a symbol or “icon” of that asset directly on 27

104

an electronic map. For example, an end-user can determine the location of individual poles on a specific 1

66kV sub-transmission line, together with the original date of installation of each pole and line span, the 2

height of the wires off the ground (both at the pole and at the point of greatest “sag”), and any 3

maintenance work that has been done to the pole line or specific pole. The user can also obtain the 4

electrical connectivity information that shows the substation and generating stations that supply power 5

to the line, the amount of load being carried on the line, as well as the distribution substations, circuits 6

and transformers that ultimately deliver the power. This feature provides critical electrical load and 7

phasing103 information needed for reliability or restoration efforts by many SCE employees, including 8

system operators, schedulers, dispatchers, system engineers, service planners, troublemen, senior 9

patrolmen, transmission crews and distribution crews.104 10

(1) Links Between Mapping Information and Employee Safety 11

With accurate maps and asset information, as described above, 12

supervisors, schedulers, and dispatchers can better assure a safer work environment when dispatching 13

crews to a work location. Under a comprehensive GIS-based mapping system, they will have real-time 14

knowledge of exact crew location, the circuitry on which those crews are working and the electrical 15

conditions of those circuits. They will also have visibility to the relationship between each crew and job 16

and other crews and jobs in progress, including contractors. 17

There are numerous safety benefits resulting from access to 18

comprehensive mapping information. Supervisors, schedulers, and dispatchers will have visibility of all 19

crews (SCE and contractor crews) affected by a planned outage or switching program, and ensure that 20

103 Transmission lines and primary distribution lines have three phases (A, B, and C). It is important for reliability reasons

to know how the load is served from each of the three phases. For example, if any one phase carries a disproportionate load, this overload or out of balance situation may cause power quality or reliability issues. Likewise, if a customer is served by the A phase and an outage is planned, it is important to know which crews are working on that phase to ensure that re-energizing the circuit and restoring power can be done timely as well as provide timely information to customers connected to that phase regarding the outage (reliability).

104 For example, it provides system operators with the impact on load and network performance if a given switch is opened, alerts schedulers to all crews working on a circuit involved in a planned outage, gives system planning engineers the ability to determine how growth in demand would exceed existing load limits, enables service planners the ability to assess the impact on system performance if service expansion is designed in one manner versus another, and enables crews to know the electrical conditions around the specific area where they are working.

105

all crews working on that circuit are safe prior to re-energizing. SCE has an extensive verification 1

process in place to ensure that work is complete and that crews are safely clear prior to re-energizing 2

circuitry. The added visibility and improved display associated with the comprehensive mapping system 3

will enhance the existing process without adding to the existing work process. Additionally, they will 4

know the exact location to send crews for night work in high-crime or remote locations, or for work 5

during adverse conditions (fire, heat, rain, and windstorms), reducing the time crews spend searching for 6

the correct location, and thus reducing the crews’ exposure to unnecessary risk. The mapping system 7

can also display digital photography of the asset and site location, which enables supervisors, 8

schedulers, and dispatchers, as well as their electrical and trouble crews, to understand the nature of the 9

work, site conditions, and potential problem areas prior to traveling to site. This will give them the 10

ability to understand the risks prior to crews arriving at the job site, and thus the ability to thoroughly 11

prepare, including selection of appropriate safety equipment and tools. 12

(2) Links Between Mapping Information and Public Safety 13

Beyond employee safety, comprehensive and accurate mapping data will 14

help reduce the risk of third parties coming in contact with energized lines. Comprehensive map 15

information enables SCE to provide contractors with information about underground locations before 16

they dig, and provide municipalities and other emergency responders with exact locations of SCE 17

electrical assets, including whether energized or not, and provide knowledge of hazardous conditions at 18

the site. By providing up-to-date information, SCE assures that emergency responders can proceed with 19

their missions without delay.105 20

(3) Links Between Mapping Information and Compliance 21

(a) Inspections 22

All of SCE’s overhead distribution assets are detailed inspected 23

once every five years and underground distribution assets every three years as described by Witness 24

Stark in Exhibit SCE-03, Volume 2. An up-to-date, comprehensive GIS-based mapping system, 25 105 See Workpaper entitled “To the Rescue: GIS in New York City on Sept. 11” for a general discussion of links between

mapping information and public safety.

106

showing exact geographic locations of all assets, would ensure that inspectors can locate the specific 1

asset they are seeking. Upon locating and inspecting the specific assets, the inspection would be able to 2

readily and accurately make changes to asset records if corrections to such records must be made. 3

Having accurate and more detailed asset information is especially important for underground assets, 4

which are not readily visible.106 In the event that an asset’s location has been entered incorrectly, the 5

error can be easily rectified by inspectors entering correct coordinates, without manual data entry, using 6

their Field Tool.107 7

A comprehensive mapping system will provide TDBU 8

management with real-time visibility and reporting capability of completed inspections to-date, 9

displayed on a geographic map by service district, region, or territory.108 These maps will show 10

geographically the inspection status of all the assets located within that territory, and provide easy 11

retrieval of the results from completed inspections. For example, problems found with the asset, or 12

changes in asset information, such as geographical location, physical site conditions, or physical asset 13

conditions can be viewed or modified accordingly. Moreover, the maps will house such vital data as 14

digital photographs of problems found by inspectors, ensuring correct repairs. Simultaneously, the maps 15

will provide visibility and detailed information on inspections left to be completed during the current 16

inspection cycle (by district, region, or territory). 17

(b) Maintenance 18

A comprehensive mapping system will also detail the location and 19

nature of all required maintenance work for a specified time period (week, month, quarter, year, or 20

longer), whether part of a preventive maintenance program or resulting from inspections as just 21

described. The mapping system will be able to display this information by geography, from a section as 22 106 See Workpaper entitled “Gartner – Even Utilities With GIS Are Lost Without Digital Asset Management” for a general

discussion of the value of mapping information in the compliance arena. 107 Field Tools are generally laptops, PDAs, or Automated Vehicle Locators used by personnel working in the field. See

Transmission and Distribution Business Unit Consolidated Mobile Solution testimony in this volume. 108 SCE’s 50,000 mile territory and 4.8 million customers are divided into 7 urban and 1 rural region, which currently

encompass 24 urban and 10 rural districts; within Test Year GRC 2009, two new districts will be opened (Wildomar and Porterville), bringing the urban total to 26.

107

small as a land-lot, up to district and regional aggregations. It will show work on a completed basis 1

versus planned, and display remaining work scheduled for the specified time period. For the remaining 2

work, the maps will denote the priority status and due date for that work, and show whether the work 3

has been scheduled or is still pending. Based on this information, the mapping system will also assure 4

TDBU’s management personnel that all mandated work at a location and its immediate vicinity is 5

accomplished before a crew leaves. Once work has been completed, details of the activities performed 6

will be captured and available for reporting. 7

(c) Line Clearing 8

Line Clearing (vegetation management) contains both an 9

inspection phase, to determine which sections of overhead conductor is exposed to excessive botanical 10

growth, and a maintenance phase, to actually trim back the growth. As with other forms of TDBU 11

inspections, there is a need for mapping information that shows geographic location of the conductor 12

assets, contains and displays inspection schedules by geography and due date, displays which inspection 13

routes have been completed and which remain to be done, and captures and displays inspection results, 14

including need and priority for trimming. The crews which actually perform the clearing activities will 15

use the inspection data to create mapping information for their own needs: maintenance schedules by 16

geography and priority, displays of what work has been accomplished and what remains to be done 17

(including a data and reporting repository for the work that has been accomplished, of what was done 18

and on what date). 19

In addition, in a comprehensive GIS-based mapping system, any 20

changes in geographic location, site conditions, or physical conditions of the asset, noted by Line 21

Clearing inspectors or maintenance crews, can be captured and made visible to all TDBU mapping 22

users. 23

(4) Links Between Mapping Data and Reliability 24

A comprehensive mapping system, providing robust asset and site 25

information as described above, is a fundamental tool in assuring service reliability in three ways: first, 26

by assuring that designs for new capital work do not negatively impact primary circuitry; second, by 27

108

improving responsiveness to trouble calls and timing of service restoration after unplanned outages; and, 1

third, by enhancing SCE’s asset management program (for example, preventative maintenance 2

schedules, repair prioritization, and repair versus replace decisions). 3

With regard to the impact of new designs on existing circuitry, a 4

comprehensive mapping system will enable engineers and planners to use their Graphical Design Tool 5

(GDT)109 to auto-calculate the impact of the electrical components chosen for the design on the primary 6

circuitry. That is enabled by GDT’s electronic access to the real-time connectivity information 7

contained in the mapping system, and allowing it to factor electrical load and circuitry information into 8

all of its calculations. In the absence of this automated validation, the engineer and planner must 9

assemble data from several sources and perform the calculations manually. Whenever manual 10

calculations are done for validation there is a chance for error. Having a single source from which to 11

extract data and automating the validation calculations makes this process consistent and repeatable 12

across all engineers and planners. The automatic validation provided by the comprehensive GIS-based 13

mapping system will ensure that correct materials are chosen for the specific design and validate that the 14

design, once installed, will not cause problems upstream or downstream on the circuit. 15

In the area of responsiveness and service restoration, in the event of a 16

service interruption, the mapping system will provide distribution system operators a complete picture of 17

the grid and all circuits, including: (i) the energized electrical equipment (power transformers, 18

transformers, conductors, switches, circuit breakers, capacitor banks, automatic recloser devices), (ii) the 19

electrical service runs between the primary and secondary lines and the customer and (iii) the non-20

energized electrical equipment (poles, underground vaults, conduit). Reported problems in any of these 21

areas can be immediately located. In conjunction with a Field Tool, the mapping system also contains 22

information showing the geographic work locations of troublemen and crews, and can thus identify the 23

closest available troublemen (or electrical crews, if needed for substantial repairs) for dispatch to the 24

problem site, thereby reducing response time. 25

109 See Footnote 102; the Graphical Design Tool is a Bolt-On to ERP.

109

As discussed previously, a comprehensive GIS-based mapping system will 1

have the capability to store and display digital photography of the assets and site. In the event of 2

equipment failure, pictures which are stored on the mapping system help dispatchers understand what 3

the troublemen will encounter when they reach the jobsite. In the case of damage where troublemen are 4

first responders and electrical crews will be called out to perform the main repair, the troublemen can 5

take digital pictures of the actual damage and, using a Field Tool, attach the pictures to the asset’s file 6

within the mapping system. The pictures can then be viewed by the dispatcher, helping them determine 7

the electrical crew skills needed for the particular job, and enabling the selected crew to determine what 8

materials will be needed before the crew leaves the service center. This ability to match skill sets and 9

material to the job in advance would shorten the time required for the restoration of power. 10

In asset management, the asset files within the mapping system will 11

contain a comprehensive record of the asset, including asset age, current condition, inspection dates and 12

results of inspections, preventive maintenance records, repair records, along with key electrical 13

connectivity data such as the circuit to which the asset belongs, criticality of that circuit to the network, 14

and (if the asset is an energized electrical component), normal load, and peak load. Access to such data 15

will help asset managers adjust preventive maintenance schedules, prioritize components and circuits for 16

repair (based on criticality to service reliability), and make economically-sound repair or replace 17

decisions (based on asset age and prior repairs). 18

b) Description Of TDBU’s Current Systems 19

In Section A, Part 1 and Part 2a, this testimony described four broad categories of 20

mapping information that are needed for TDBU’s work: geographic location, site-specific information, 21

physical information about the asset, and electrical connectivity. Today, TDBU has multiple mapping 22

technologies to provide needed information: Distribution Facility Inventory Maps (FIMs), Transmission 23

FIMs, Substation Maps, Circuit Maps, Streetlight Maps, and Line Clearing Maps.110 Each of these 24

multiple mapping technologies contain only limited portions of information from the four categories, 25

110 See Workpapers for examples of maps.

110

and even when taken together they do not supply the complete set of data needed.111 In addition, they 1

are based on separate software programs, databases, or manual records which are incompatible and thus 2

cannot integrate easily. Finally, the land bases, which are the street and public structure maps that form 3

a backdrop to SCE maps (e.g., Thomas Brothers or Delorme), differ among the various systems. A brief 4

description of each follows: 5

FIM: FIMs (Transmission and Distribution) cover the approximately 6

3,200,000112 TDBU physical assets in SCE’s service territory and are contained within 145,991113 7

separate and distinct maps. The two FIM systems utilize AutoDesk’s AutoCAD software application, 8

and display energized electrical assets (transformers, conductor, switches), non-electrical assets (poles, 9

vaults), and service lines (from the secondary circuitry to the point of customer service). The locations 10

are plotted using mathematical graphing techniques (i.e., “x” and “y” coordinates), rather than basing 11

them on real geographic or geospatial coordinates (longitude and latitude). Only limited information is 12

contained within FIMs about the physical nature of the asset (for example, pole age and class, pole 13

height, framing are not included), and no information is maintained on site conditions or connectivity. 14

Circuit Maps and Streetlight Maps: Both circuit maps and streetlight maps utilize 15

GE Smallworld’s GIS application; however, they use different land-bases and contain different assets. 16

Circuit maps contain only the energized electrical components of TDBU’s circuitry, and exclude non-17

energized assets such as poles or vaults, which oftentimes are the basis for identifying the energized 18

electrical assets (i.e., the pole’s identification is easily visible at the street level and can be used to 19

identify the transformer or capacitor bank attached to the pole). In addition, circuit maps do not show 20

the individual service lines between the secondary circuit and the point of customer service. Circuit 21

maps do show electrical connectivity, which means that the relationship between any asset and the 22

circuit or grid of which it is a part is traceable, and that actual real-time information on the load being 23 111 SCE may have O&M savings with regard to maintaining one mapping system, as opposed to multiple mapping systems,

once the initial resource-intensive transition period is complete. SCE will provide information regarding such productivity or capacity benefits, if any, in the subsequent rate case cycle.

112 Asset count from SCE TDBU Field Systems Support group, current as of June 28, 2007. 113 FIM count from SCE TDBU FIM department, current as of June 4, 2007.

111

carried by the asset or circuit is readily available. Streetlight maps show only SCE-owned streetlights. 1

Both mapping systems provide only limited information on the physical condition of the asset, and no 2

information on site conditions. 3

Line Clearing Maps: SCE’s Vegetation Management department uses a 4

Microsoft Access database combined with paper maps including FIMs, circuit maps, and streetlight 5

maps. 6

Substation Maps: Substation maps are a mixture of AutoCAD and hand-drawn 7

sketches or drawings, essentially providing an overhead view of a substation’s physical layout. They do 8

not show geographic relationships between the substation and what surrounds it, nor do they show 9

electrical connectivity between the substation and the grid or circuits it supports. They contain little, if 10

any, digital information about the asset or the site. 11

c) Shortcomings Associated With TDBU’s Existing Mapping Systems, And How A 12

Comprehensive Mapping System Will Help Overcome The Shortcomings 13

The multiple mapping systems just described result in two broad sets of issues: 14

(i) data gaps (insufficient data) between what is needed for safety and service reliability and what is 15

available; and (ii) data quality concerns such as outdated and inconsistent data which negatively impact 16

safe and reliable operations. A comprehensive GIS-based mapping system will resolve these issues by 17

supplying a single source of asset data that contains geographic location, site-specific conditions, 18

physical asset characteristics, and electrical connectivity. 19

In the area of data gaps, the current mapping systems individually do not provide 20

TDBU with the information needed to effectively conduct its business at current and anticipated 21

workload levels. Each mapping system lacks certain elements of vital asset data, whether that is 22

accurate geographic location, site conditions, physical information about the asset, or electrical 23

connectivity. Even if all existing TDBU mapping systems today could be consolidated (which they 24

cannot), the resulting system would still provide insufficient data. Without essential data embedded in 25

the map, the user must manually search for the information from multiple sources and files. In an 26

emergency situation, such as a vault fire, or where a power line has fallen on an occupied car, the 27

112

additional time required114 may subject employees, emergency responders, and the public to a risk of 1

serious injury. Reliability is affected as well, since service in these cases has usually been interrupted, 2

and the prolonged time spent in obtaining the needed information can result in delays to response and 3

restoration. A comprehensive GIS-based mapping system will remedy these pain points by containing 4

and supplying all pertinent information about the asset. 5

In the area of data quality, the technologies of the multiple mapping systems vary 6

significantly, causing the maps and the location of assets on those maps, as well the limited asset data 7

contained within them, to be inconsistent. For example, because of the different methods of calculating 8

location, mathematical (“x” and “y” graphing coordinates) versus geographic (latitude and longitude), 9

and because of the different land bases, a FIM and a circuit map may show the same asset as being in 10

different locations. A comprehensive GIS-based mapping system will reconcile these differences by 11

utilizing a single technology that contains all information in one database. 12

In addition, the process of keeping the maps up-to-date is based on transcribing 13

information by hand to and from pieces of paper, and moving that paper between the field, service 14

center, and mapping office. This creates the possibility of transcription errors, as well as loss of 15

documents, which in turn impacts the quality of the data on the maps. Finally, because the paper-based 16

map maintenance processes contain handoffs between departments, this causes a delay in recording 17

changes reflecting updates made in the field into the mapping system. As a result, there will always be 18

some number of maps that contain out-of-date information. A comprehensive GIS-based mapping 19

system prevents this by enabling automatic updates of information directly from a field employee by 20

entering information from a global positioning system device (GPS), handheld, or mobile Field Tool. 21

The mapping system then records the changes instantaneously without further intervention. 22

Solving these data gaps and data quality issues will have a tangible impact on 23

employee and public safety, as well as service reliability. The following are specific examples of the 24 114 Because so much information has to be aggregated from different sources to provide all relevant information on a single

asset, this process takes approximately 30 minutes (based on interviews with mapping department staff); whereas, with a comprehensive GIS-based mapping system, all the relevant data would be available almost instantaneously through the pressing of a couple of computer keystrokes.

113

wide range of problems resulting from the current state of SCE’s mapping systems, and solutions 1

provided by the comprehensive GIS-based mapping system: 2

Underground Emergencies (Vault Fire): Today, when a troubleman or crew 3

responds to a vault fire, one of their first activities is to determine which circuits are in the structure. 4

This information is required in order for the system operators to de-energize the circuits or, at a 5

minimum, block automatic circuit re-closers (a “blocked” re-closer prevents a circuit from re-energizing 6

automatically) to prevent risk of serious injury to the emergency responders and the public. 7

Because the troubleman or crew cannot look inside the burning vault for 8

equipment numbers, they cannot determine what electrical assets are in the vault. Without the 9

equipment number, the troubleman or crew cannot perform a laptop search for the electrical assets on 10

the circuit maps. Unfortunately, circuit maps do not contain non-electrical assets, such as vaults, so they 11

cannot simply find the circuits by locating the vault. However, the troublemen or crew can locate the 12

closest circuit to the burning vault and display a circuit map. A limitation of circuit maps is that a circuit 13

map only shows the connection point of other circuits and the troublemen or crew would have to look on 14

multiple maps and then triangle, using multiple maps to determine all of the circuits that run through the 15

structure. Because they are not aware of the number of circuits, the troublemen and crews would be at 16

risk if they were to enter the vault with only part of the circuits de-energized, thus increasing the 17

potential for contact with energized lines and the risk of serious injury or death. In the event the 18

troubleman or crew has sufficient local knowledge to suspect there may be more than one circuit within 19

the burning vault, they have two options: First, they can call into a system operator and ask them to 20

manually trace every circuit out of the substations in the area to see which ones traverse through the 21

structure in question. This requires a call back to the troubleman and can take up to 30 minutes.115 22

Delay at such a critical stage of an emergency may allow the fire to spread. 23

Alternatively, the field personnel can do some tracing on their own. The 24

troubleman or crew would need to search for the nearest structure (asset) number on the circuit map to 25

115 Based on interviews with multiple troublemen.

114

search for the correct FIM map number. To search the FIM map for that structure number the field 1

personnel must hand-trace their way to the vault. In so doing, they can determine how many primary 2

circuits are contained in the structure, but, again, the FIMs do not contain circuit names. The 3

troubleman or crew still cannot tell the system operator which circuits to de-energize, requiring that the 4

troubleman or crew perform a visual search of the FIM map for adjacent electrical assets and their 5

associated structure numbers. Using this information, they return to the circuit map to find the other 6

local circuits by structure number. 7

In addition to the safety risks just described, there is a negative impact on 8

reliability. The longer the delay for the circuits to be de-energized and for the firemen to contain the 9

fire, the longer the delay for service restoration as the damaged equipment cannot be repaired until the 10

fire has been extinguished. 11

In contrast, with a comprehensive GIS-based mapping system containing all 12

energized and non-energized electrical assets, along with their locations, site specific conditions, 13

characteristics, and connectivity, the troubleman or crew would have located the circuits immediately 14

from the location of the manhole. The circuits would have been quickly de-energized, allowing fire 15

crews to perform their work and for SCE to restore service. 16

Accidental Dig-Ins (Underground Service Alert – USA – Network): Currently, 17

because of the varying technologies and limited information contained in TDBU’s mapping system, 18

TDBU is unable to directly share information with the Underground Service Alert116 (USA) network in 19

compatible digital formats. As a result, updates to the USA North and USA South databases are 20

performed manually, outside of TDBU’s map maintenance processes. Once new underground work is 21

completed in the field and new USA grids are affected, the information regarding the work is sent to 22

USA, informing the agency of the change. USA then will visit and mark the work area before other 23

utilities or contractors attempt to dig. Typically, there is a time delay between the time the work is 24

116 Underground Service Alert (USA) is also known as Dig Alert. Dig Alert is a one-call notification center that supports all

of Southern California. Dig Alert was created in order to, among other things, avoid accidentally hitting underground lines (electric, gas, water, etc.).

115

completed and the information is manually sent to USA. This delay subjects other utilities and 1

contractors, who may dig prior to the time the site is marked, to the safety risk and reliability impacts 2

described previously. In contrast, with a GIS-based comprehensive GIS-based mapping system, TDBU 3

would notify USA electronically upon completion of new underground circuitry, providing all 4

information required to activate new USA grids. 5

Environmental Impact: If a crew responds during a windstorm to poles down in a 6

remote location, they may be unaware that they were disturbing the habitat of an endangered species or 7

otherwise sensitive area and did not take the required precautions to minimize impact. This may cause 8

TDBU to be out of compliance with state and federal environmental regulations. With a comprehensive 9

GIS-based mapping system, environmental maps would be a layer to which TDBU has access. When 10

the responding crew opened their circuit map, they would have seen that it was inside the shaded 11

boundary of the endangered species or otherwise sensitive area, and taken steps to avoid habitat damage. 12

Vegetation Management: Currently, trees under or near SCE’s energized 13

electrical assets are manually listed and kept in an Microsoft Access database, along with some 14

information on those trees in need of clearing. The data contained does not provide precise information 15

on geographical location, nor does it contain site-specific or tree-specific conditions. For example, it 16

does not identify newly planted or maturing trees that may be close to energized conductors. GIS is an 17

ideal platform for the maintenance of tree locations, growth patterns, and maintenance activities. As 18

with electrical assets, additional site-specific information can be added such as land owners and 19

endangered plant and animal species. The result will be fewer outages caused by botanical growth, 20

thereby maintaining reliability. 21

Paved-Over Structure Entrance: When streets, roads or sidewalks are worked on 22

or repaved, there is a possibility that the SCE structures (underground vault, manhole, or handhole) will 23

be paved over and the cable or equipment will not be readily accessible in the case of routine switching, 24

maintenance, or an emergency. In the case of a circuit interruption or third party contact, the responding 25

troubleman or crew will not be able to locate the structure or equipment in order to isolate the circuit or 26

de-energize the equipment. Moreover, while in the process of isolating and re-energizing the circuit, the 27

116

troubleman or crew could be re-energizing the damaged cable or equipment inside the structure 1

numerous times. This exposes the general public to the risk of injury and impacts reliability if the cable, 2

equipment or structure fails catastrophically. With a Comprehensive Mapping System in place, using 3

their GPS device, the responding troubleman or crew could quickly locate the exact location of the 4

structure entrance and remove the asphalt or concrete covering the entrance and proceed to fix the 5

problem in a safe and timely manner. 6

As evidenced in the wide-ranging examples set forth above, numerous 7

opportunities exist to leverage geospatial and geographic information systems (GIS) to maintain an 8

electric utility’s safety and reliability performance. Just as the cellular phone has become commonplace 9

(to the point that one cannot imagine being without one), many other utilities have found the necessity to 10

implement a fully enabled GIS-based mapping systems.117 As such, GIS-based mapping systems have 11

become an essential foundation to providing safe and reliable electric service to customers. 12

d) Implementing a Comprehensive TDBU Mapping System Project Will Provide 13

Additional Functionality to Existing Tools, Improving Safety, Reliability, and 14

Compatibility 15

By resolving the problems caused by existing mapping systems, the 16

comprehensive GIS-based mapping system will also enhance the capabilities of other software 17

applications. For example, the Graphical Design Tool118 (GDT) will initially rely on FIM maps and the 18

information they contain as the foundation for creating planners’ designs. As discussed previously, 19

FIMs contain very limited site and asset information, are often inaccurate as to precise geographic 20

location of assets, lack certain asset information (such as pole or conductor height), and carry no 21

electrical connectivity data. Because of these data gaps and data quality issues with the design’s basic 22

building block (the FIM), the resulting design is subject to error unless repeated field visits are made to 23

verify the “as-built” conditions in the field. 24

117 See Workpaper entitled “Utilities Employing GIS Technology.” 118 See SCE-09, “Bolt-Ons.”

117

However, the GDT is pre-configured to take advantage of a comprehensive GIS-1

based mapping system, by importing GIS-based maps, to provide planners and engineers complete 2

mapping and asset information in the four categories of geographic location, site-specific conditions, 3

physical asset characteristics, and electrical connectivity system. Once the comprehensive GIS-based 4

mapping system is in place, the GDT will enable planners and engineers to (i) automatically import 5

circuit and asset information directly into the GDT from the GIS system in a form and symbology that’s 6

recognized by the GDT, (ii) automatically perform complete electrical calculations (for example, voltage 7

drop and flicker caused by the addition of new service) and structural calculations (for example, wind-8

loading of poles); (iii) automatically select the correct class and size of components (transformer, 9

conductor, pole), if desired by the engineer or planner; (iv) enable the GDT to validate that a planner’s 10

design will not create problems upstream or downstream on the circuit (as previously discussed under 11

reliability); (v) have immediate access to all pertinent site specific and physical asset characteristics 12

needed (for example, property rights, soil conditions, slope of the land, climate zone, environmental 13

concerns, local ordinances restricting work times, traffic conditions, CalTrans requirements); and (vi) 14

automatically “clean” customer-provided maps for use in the design (for example, stripping unneeded 15

information from the map, validating geographic coordinates, and converting customer symbols to SCE 16

standard symbols). 17

These six capabilities, enabled by the GDT and the comprehensive GIS-based 18

mapping system will improve the accuracy of planners’ designs, resulting in improved performance and 19

reliability of the new or modified assets being designed. 20

In addition, the GDT and the comprehensive GIS-based mapping system provide 21

visibility to all users of proposed new construction or proposed modifications to existing construction, 22

created by planners and engineers. This visibility helps workers and system operators make informed 23

decisions about their work. As discussed above, it will enable workers to understand the impact of new 24

construction on existing and other planned facilities, and enable system operators to isolate and repair 25

the equipment in the event of problems. This will impact both worker safety and service reliability. 26

118

e) Project Description and Schedule 1

(1) Overview 2

The Comprehensive TDBU Mapping System project consists of four basic 3

phases: (i) high-level design for a TDBU-wide mapping system, associated mapping processes, and 4

interfaces with work processes making use of mapping information (e.g., service planning, system 5

planning); (ii) development of detailed blueprints for data file design, for creation of required data 6

characteristics, and for configuration of the comprehensive system; (iii) development of detailed 7

processes for future mapping as well as for ongoing updating and maintenance of asset data and the GIS 8

system; and (iv) phased construction and implementation of the comprehensive GIS-based mapping 9

system and the supporting processes just discussed. 10

The fourth phase will be highly resource-intensive, and the speed with 11

which SCE can complete the entire project will be constrained by the amount of available human 12

resources. Accordingly, during this rate-case cycle, we plan to complete work and put into service a 13

comprehensive TDBU GIS (including electrical connectivity) for all assets in three (of seven) TDBU 14

Regions.119 This will provide a representative sample of the diversity of assets and conditions across our 15

entire service territory. The costs discussed in this testimony cover the aforementioned work. 16

SCE is approaching the project on a regional basis because our 17

administrative geography aligns with our electrical network divisions, called “A” Banks, each of which 18

consists of a major substation, subordinate substations (“B” Banks), transmission lines, distribution 19

circuitry, and individual services. A region will contain one or more “A” Banks, and “A” Bank 20

networks do not cross regional boundaries (they are entirely contained within a single region). Thus, by 21

approaching the project on a region-by-region basis, we will ensure that complete electrical connectivity 22

is enabled from substation to meter, for all the assets within the region. This allows both system 23

planners and service planners to make full use of the comprehensive GIS-based mapping system within 24 119 TDBU’s territory is broken into seven regions: San Joaquin Region, Highland Region, Desert Region, Metro East

Region, Metro West Region, North Coast Region, Orange Region, and San Jacinto Region. See Workpapers for map display. The three regions GIS is targeting during this rate case cycle are Metro West Region, San Joaquin Region, and San Jacinto Region.

119

their region, irrespective of what is happening outside their region, and enables mapping organizational 1

and process changes to be implemented when the region is completed. In this way, the comprehensive 2

GIS-based mapping system will be in use and useful for the three deployed regions before the end of 3

2011. 4

The remaining Regions will be scheduled to be completed subsequent to 5

this rate case cycle. Refined estimates of levels of effort, duration of time, costs, and any associated 6

productivity or capacity benefits will be developed, based on the work accomplished in the pilot and the 7

first three regions, and provided in testimony during a later GRC filing. 8

Because a number of years are required for implementation of a 9

comprehensive GIS-based mapping system in all regions, there is an advantage in performing a pilot 10

rollout (the “Mapping Pilot” as described further below) in order to deliver some of the anticipated 11

improvements and test certain aspects of functionality prior to completion of our comprehensive GIS-12

based mapping system. The primary opportunity for accomplishing this pilot lies in making some 13

advanced mapping capabilities available to the Graphical Design Tool in 2009, based on taking the 14

information from an existing circuit map, which is already in GIS format, and overlaying it with existing 15

FIM data, currently in CAD format. This will enable a planner to see the entire landscape of a proposed 16

work site on the GDT screen, including both structures and circuits, and place the asset and conductor 17

symbols for the desired design on top of the consolidated backdrop. This does not provide most of the 18

benefits of the comprehensive GIS-based mapping system,120 and as a result, this pilot solution is not a 19

viable long-term substitute. However, it will help simplify the design process, and bring in more critical 20

asset information than currently available. It will reduce planner and design errors, and thus increase 21

service reliability by minimizing negative upstream impacts of the design on primary circuitry. 22

120 There are a number of drawbacks which prevent the pilot from being a substitute for the comprehensive system. For

example: (a) the land-bases (Thomas Brothers Maps, Municipal Plats, etc.) used by the circuit maps and FIMS will still be different, causing structures in one to appear in unlikely locations in the other (such as mid-street); and (b) where FIMS lack vital asset data, the deficiency in “intelligence” will still be present.

120

(2) Phase 1 – 3, Planning and Design, 2009 1

The first three phases of the of the comprehensive GIS-based mapping 2

system project – (1) high-level design, (2) blueprinting, and (3) detailed process design – will include 3

planning, analysis, and process engineering work. These phases will consist of the following activities 4

which are scheduled to be completed during 2009: 5

• Validation that the current limited TDBU GIS platform (GE Smallworld 6

4.1) is the desired platform for the Comprehensive TDBU GIS-based 7

Mapping System project121, 8

• Development of geographic asset record architecture, including required 9

geospatial coordinates for each asset record, and common symbols to be 10

used for all map icons 11

• Determination and implementation of a common landbase (Thomas 12

Brothers, Navteq, Municipal, etc.) for all Mapping applications 13

• Development of a process and a set of operational procedures for the 14

fourth phase of the project (to populate required data characteristics for all 15

assets, and to convert or re-create FIMs and other TDBU asset maps in the 16

chosen GIS platform 17

• Development of a process and a set of operational procedures for TDBU 18

to use after project completion so that all new asset changes are recorded 19

in the single GIS platform 20

• Creation of final architecture for, and implementation of, a TDBU 21

Mapping interface with ERP (GIS with SAP and the GDT and Click Bolt-22

Ons) 23

121 TDBU is upgrading from GE Smallworld 3.0 to 4.1 in 2007 – 2008. See SCE-03, Vol. 3, Parts 1-8 for additional details.

Both duration and costs for the Comprehensive TDBU GIS-based Mapping System Project assume using the existing platform for all new GIS applications; no estimate is included for an overall change in platform.

121

• Creation of a blueprint to interface the TDBU Mapping platform with 1

other GIS platforms used by other business units within SCE 2

• Re-engineering of the mapping process throughout TDBU, including: 3

process and organizational changes required, operational procedures, and 4

roles and responsibilities; determination of training requirements and 5

implementation schedule 6

• Creation and implementation of a governance process for ownership of the 7

geographical elements of asset master data throughout SCE 8

• Proof that the proposed approach of conversion is feasible by conducting a 9

pilot in a portion of one region 10

(3) Phases 4 - 5: Build and Implement Initial Three Regions, 2010 – 2011 11

Once the first phases of the project are completed in 2009, construction 12

and deployment of the project will begin in 2010. The primary activity for this phase of the project will 13

be (a) building the Comprehensive TDBU GIS-based Mapping System by developing the geographic, 14

site-specific, asset-condition, and electrical connectivity data specified during the planning and design 15

steps, for that portion of the 3,200,000 assets contained in the three selected regions and (b) using the 16

“production” process and operational procedures developed in Steps 1 and 2 to build that information 17

into a comprehensive GIS database. 18

The GIS “production” process will be scheduled and implemented so that 19

entire geographic blocks are completed before beginning to build the system in another area. For 20

example, all locations and assets within a region’s “A” Bank will be completed before another “A” Bank 21

or region is begun. Because the work assignments of many users of the Mapping System are contained 22

entirely within one region, completion of a given region makes the system immediately useful to all 23

users located within that geography. 24

(4) Deliverables 25

When a region is completed, the comprehensive GIS-based mapping 26

system for TDBU, for that area, will include: 27

122

• A Mapping system that covers all assets, and provides GIS capabilities 1

to all TDBU users who work in, or cover, the area 2

• Critical information (e.g., geospatial coordinates, site conditions, 3

physical asset conditions, regulatory and electrical connectivity) 4

collected, recorded, and made instantly retrievable for all structures in 5

the SCE electrical system 6

• Common landbase for all Mapping applications 7

• Integration of the TDBU Mapping application with SAP, the Graphical 8

Design Tool and the Click scheduling tool 9

• Ability to provide TDBU Mapping information to GIS users outside of 10

TDBU 11

• Process, procedures, organizational structure, governance, staffing, 12

training requirements and control metrics for all mapping functions 13

within TDBU, and for maintenance of the new Mapping System on an 14

ongoing basis 15

• Region-specific metrics to measure the benefits associated with the 16

comprehensive mapping system, including, but not limited to, 17

improvement in safety, reliability, compliance, and productivity or 18

work capacity. 19

(5) Mapping Pilot Solution 20

The Mapping Pilot will create a software application (called a “data 21

manager”) that enables an overlay of existing FIM information on top of existing circuit maps that can 22

be used by the TDBU Graphical Design Tool. The Mapping Pilot will enable planners, engineers and 23

designers to see all currently available geographic and location-specific information, in a graphical 24

format, as the background on the GDT for new electrical systems capital work, modifications to the 25

existing system, or repairs to the existing system. Because of problems described previously, such as 26

the different land bases between FIMs and Circuit Maps, the new data may contain inaccuracies and the 27

123

pilot will allow us to correct these prior to our comprehensive deployment. Moreover, the pilot will not 1

provide the full range of information discussed earlier, needed for safety, reliability, and compliance. 2

However, the pilot will allow us to test some of the GIS capabilities and will provide planners and 3

engineers with better information that will reduce design errors, and reduce the negative upstream 4

impact design problems can have on primary circuitry. 5

The Mapping Pilot is anticipated to begin and be completed in 2009, 6

making the “data manager” available for use by the GDT beginning in late 2009 or early 2010. It will 7

be available to all users of the Graphical Design Tool until additional capabilities of the comprehensive 8

GIS-based mapping system are completed in the user’s region. Thus, at the end of the 2009 Rate Case 9

cycle, it is anticipated that employees from four of seven regions will still be utilizing the pilots 10

capabilities. 11

f) Project Costs 12

Our planning and due diligence in preparation for the implementation of the 13

Comprehensive TDBU GIS-based Mapping System is a work in progress at the date of submission of 14

this testimony, due to the timing of the filing of SCE’s NOI. We will be preparing the detailed and 15

specific technical system requirements and a detailed Request for Proposal (RFP). We anticipate a 16

rigorous vendor selection process that will not be completed until the second quarter of 2009. 17

Based upon our best information to date, SCE plans to expend $21.45 million in 18

capital over the period 2007-2011 for this implementation.122 During Phases 1-3, SCE estimates it will 19

spend $15.20 million in capital on high-level design, blueprinting, and the detailed process design. 20

During Phases 4-5, SCE estimates it will spend $6.25 million in capital on construction and deployment 21

of the project. 22

Table IV-27 GIS Capital Expenditures below provides a cost breakdown of the 23

expenditures SCE plans to make during this rate case cycle. The funding of $1.30 million (constant 24

2006 dollars) for the IT O&M Test Year costs is being requested in IT’s testimony in Exhibit SCE-5, 25

122 See Workpaper entitled “Comprehensive TDBU GIS Cost Detail.”

124

Volume 2. The funding of $5.77 million (constant 2006 dollars) for the TDBU O&M Test Year costs is 1

being requested in TDBU’s testimony in Exhibit SCE-3, Volume 2. 2

Table IV-27 GIS Capital Expenditures (2007-2011)

2007 2008 2009 2010 2011 Total

Capital $0.00M $0.00M $15.20M $6.25M $0.00M $21.45M

Our preliminary expenditure estimates for this project were determined by the 3

following processes and methods: (i) high-level discussions with other utilities regarding their GIS 4

implementations which included projects’ scope and costs; (ii) communication with vendors regarding 5

site licensing fees, general scope of project and project costs including costs to import and convert 6

SCE’s current mapping information to standard GIS format; and (iii) consulted internal SCE subject 7

matter experts with previous experience with projects of similar scope and objectives.123 8

The Comprehensive TDBU GIS-based Mapping System will be administered 9

using project management process and practices and will include SCE management oversight and 10

review. SCE will be developing a business case and project implementation plan. 11

g) Conclusion 12

TDBU employees need complete and accurate information about the electrical 13

system assets they design, construct, operate, inspect, and maintain, in order to meet the Business Unit’s 14

safety, compliance, and reliability obligations. This information includes geographic location, site-15

specific conditions, physical asset characteristics, and electrical connectivity, and is typically embedded 16

in electronic mapping systems. 17

TDBU currently employs several mapping systems, with differing technologies, 18

processes, and land bases. This causes data inconsistencies and inaccuracies, and lengthy delays in 19

capturing and recording map changes. These delays cause some portion of TDBU’s maps to be out of 20

date at any point in time, which subjects crews to potential safety risks, and causes delays in service 21

123 See Workpaper entitled “GIS Due Diligence.”

125

restoration. In addition, neither the individual mapping systems nor the sum of all the systems together 1

contain the full set of needed information. This leaves significant gaps between information required to 2

meet objectives and information available on the existing systems. 3

To resolve the data quality issues and close the gaps, TDBU will build and 4

implement a comprehensive GIS-based mapping system that will consolidate and complete the full 5

range of needed asset information in one application, with one technology, one land base, a consistent 6

mapping process, and a single mapping organization. It will also introduce a streamlined, automated 7

process for maintaining map changes. Finally, it will integrate the Mapping System data with SAP and 8

its GDT and Scheduling Bolt-Ons, so that users of any of these tools will have access to required 9

information. 10

This work will start in 2009, and will be in use and useful for three of seven 11

TDBU regions by the end of 2011. 12

2. TDBU Consolidated Mobile Solution 13

Most of TDBU’s Distribution, Transmission, and Substation work is performed by 14

employees in the field (e.g., overhead, underground, and circuit inspectors, transmission, distribution 15

and substation construction and maintenance crews and troublemen), using information that comes 16

either from physical (paper) documents or from electronic computer files downloaded onto laptops in 17

the office (e.g., inspection schedules, trouble orders, work orders, maps). These field employees in 18

return provide information back to the office when they have completed their assignments (e.g., time 19

keeping, inspection results, missing or incorrect asset information, work order accounting, field-20

generated work orders for additional work required), again either by paper documentation, or by 21

physically returning their laptops to the office to connect directly with the back office systems. As such, 22

transferring information between field workers and the office is not fully automated which can lead to 23

delays and errors. It is anticipated that more fully automating the transfer of information between field 24

workers and back-office systems will help reduce the time and effort required to keep such systems 25

current, thereby maintaining productivity. The productivity benefits (either in the form of increased 26

126

work capacity or effort reduction) will be quantified as a part of the CMS project and included in the 1

subsequent General Rate Case. 2

In situations where information is moved by paper documents, the paper system can 3

cause delays in the interchange of data between the field and computer systems which would cause such 4

information to be inconsistent with actual conditions in the field. For example, critical circuit map data 5

may be out of synch with tabular data by at least a day based upon the frequency of the users’ updates. 6

In addition, the time required for field crew members to manually write down detailed information about 7

electrical assets limits the amount of critical data that will be recorded by field crews, further reducing 8

the ability for maps to portray actual field conditions. 9

The other current method of information sharing available to a limited segment of field 10

personnel is through the use of field tools. Among this subset of field employees, only a portion of the 11

types of work performed by these field personnel is processed through the use of their field tools (e.g., 12

distribution maintenance work requests are routed through field tools, but distribution capital work is 13

not). In addition, each of the types of work that today is shared electronically requires a separate 14

software application, depending on the type of field tool deployed. Finally, for the limited personnel 15

and applications currently covered, information entered on the field tool cannot be transferred to the 16

office database until that employee has arrived back at the office, and connects their laptop directly to a 17

local area network (i.e., current field tools connect to the SCE network via a local area network at 18

service centers and substations instead of accessing SCE’s systems wirelessly). As a result, the 19

information transfer process from laptop to back office system does not happen in real-time. While 20

some problems inherent in paper processes, such as transcription errors, are resolved by current field 21

tools, there continue to be limitations in the type of work processed by the field tools and issues related 22

to the lack of real-time connectivity. 23

TDBU proposes to resolve these issues by improving and expanding the use of the 24

mobile technology available to its many field employees, through the Consolidated Mobile Solution 25

(CMS) project. When complete, the CMS project will increase the TDBU mobile user base to include 26

nearly all TDBU field personnel responsible for activities mentioned above. In the process, the CMS 27

127

project will have consolidated the numerous existing mobile platforms into a single vendor supported 1

application, and added or enhanced the functionality in, among other things, the areas of network 2

connectivity, work management, material ordering, mapping, and timekeeping. 3

The testimony is organized as follows: First, we provide a description of CMS project. 4

Second, we will describe TDBU’s Management Priorities as they relate to CMS, together with CMS’s 5

importance to safety, reliability, and compliance. Third, we outline deficiencies in TDBU’s current 6

process for managing field work, providing examples. Fourth, we provide a description of the proposed 7

project approach, schedule and estimated costs. 8

TDBU’s estimated cost for this project during 2009-2011 is $17.5 million in capital and 9

$1.57 million in O&M (constant 2006 dollars) for Test Year 2009.124 Because this application’s in-10

service date is not until 2011, the plan is to determine what operational benefits are associated with CMS 11

and present the estimated productivity benefits, if any, in the next GRC cycle. 12

a) Description of CMS 13

In this Testimony, “Consolidated Mobile Solution” or “CMS” refers to a 14

collection of: (i) remote field tool hardware (e.g., laptops, vehicle mounts, GPS devices, antennas, power 15

supplies, network cards, and printers) known as field tools, (ii) a mobile software application, and (iii) 16

the required infrastructure (communications network and interfaces). 17

The first of these, the actual field tools, consists mainly of “ruggedized” portable 18

laptop computers capable of withstanding the rigors of field work environments, and for some users, 19

personal digital assistants (PDAs). Typically, each independently operating field crew or individual will 20

have one of these devices. In addition, each independently operating unit will carry peripherals that 21

interface with the portable computer, including digital and thermal cameras, portable printers, GPS 22

devices and other data collection devices, as may be needed in the course of their particular line of work. 23

The second component of CMS is the mobile software application to be installed 24

on the portable laptops and other field tools, to enable them to function as remote devices. That 25

124 See TDBU’s O&M Testimony in Exhibit SCE 03, Volume 2, Part 3.

128

software application will consist of a single, vendor-supported application, used by all field users and 1

configured based on user type and profile, and type of field work to be performed. The mobile 2

application software is highly configurable to support different end-users and their required 3

functionality. The mobile software application will have: (i) wireless, real-time dispatch capability for 4

construction, maintenance and inspection orders and for trouble calls, (ii) the ability to input and update 5

work order closure information, (iii) timekeeping entry, (iv) material ordering capability, (v) a 6

geographic information system based interface enabling (a) display of assets, work and work locations, 7

and location of GPS-enabled vehicles, against a comprehensive mapping backdrop, for the purposes of 8

self-tracking and monitoring by schedulers and dispatchers, and (b) immediate modifications to asset 9

attributes (including location, site-specific conditions, and asset characteristics), including information 10

regarding discrepancies between what is recorded in documentation versus what is found in the field,125 11

and (vi) remote access to reference information, such as regulatory and construction standards, 12

Operation and Maintenance Manuals, operating bulletins, training videos, safety vignettes, and 3rd party 13

services such as dig alerts. The field tool will be capable of accessing the necessary information 14

remotely and in real-time through the wireless network and, as such, will not require that significant 15

amounts of information be stored on the end-user’s field tool. This design allows the field tools to 16

remain up-to-date by accessing the latest relevant information in one central location - whereas today’s 17

field tools receive their updates via an overnight “batch” process. The third component includes SCE’s 18

infrastructure of telecommunications networks, servers, databases, and system interfaces that are 19

required to actually “pass” information between the mobile application and supporting office systems 20

such as SAP, the TDBU Comprehensive Mapping System (previously described in this volume) and 21

TDBU’s Outage Management System (OMS). 22

125 See Comprehensive TDBU Geographic Information System testimony in this Volume.

129

b) Consolidated Mobile Solution – TDBU Management Priorities 1

This section describes how the CMS will help TDBU improve public and 2

employee safety, reliability and compliance. In addition to the descriptions below, specific examples are 3

provided later in this testimony. 4

(1) Importance of Consolidated Mobile Solution for Safety 5

In conjunction with a comprehensive mapping system,126 CMS will 6

enhance employee safety by providing field personnel the ability to access real-time circuit and 7

equipment status and other essential information. Field personnel will also have an improved ability to 8

know the location of their work relative to work being performed by other crews and troublemen. CMS 9

will be able to display the vast information made available by the comprehensive mapping system in real 10

time. Collectively, this information allows field personnel working on the same circuit to confirm their 11

assumptions regarding circuit status before they commence work. In addition, office personnel will 12

know at all times where the field personnel are located so as to coordinate emergency responses or to 13

identify the exact location of a crew or troubleman vehicle in the event those field workers experience a 14

safety incident or are unresponsive. Other situations concerning crew safety result from storm crews 15

working in desolate areas under challenging conditions, or from one-person crews assigned to the field 16

for routine and emergency work. In the former case, field personnel working away from their home 17

work location may be only vaguely familiar with their surroundings, and may not know all the street 18

names or are unable to convey their exact location. Mitigating this, CMS can be enabled to rapidly 19

respond to emergencies in the field with on-board panic buttons and Automatic Vehicle Location (AVL) 20

capabilities. In the case of the one-person crew, if an unexpected problem occurs, the only person on 21

scene may not be able to clearly communicate. Immediate notification to the office regarding 22

emergency conditions in the field, and exact location of an at-risk employee(s), may reduce the time it 23

takes for emergency assistance to respond. AVL capabilities will allow dispatchers to direct crews or 24

troublemen that are closest to an incident (e.g., wire down, car hitting pole) posing a hazard to the 25

126 Id.

130

general public. This AVL capability coupled with CMS’s self-tracking features will also allow the crew 1

or troublemen to identify the quickest route to the hazard. 2

(2) Importance of CMS for Reliability 3

CMS provides TDBU with an additional tool to provide reliable service to 4

customers in two important ways: first, by improving responsiveness to trouble calls, and second by 5

reducing the duration of time required for service restoration after unplanned outages. 6

In the area of responsiveness, in the event of a service interruption, CMS, 7

in conjunction with the comprehensive mapping system (see section B of this volume) will provide 8

distribution system operators a complete picture of the grid and all circuits and information showing the 9

geographical work locations of troublemen and crews. It can thus identify the closest available 10

troublemen (or electric crews, if needed for substantial repairs) for dispatch to the problem site, thereby 11

potentially reducing response time to some extent. 12

A comprehensive GIS-based mapping system will have the capability to 13

store and display digital photography of the assets and site, and will display the photographs on 14

employees’ field tools. In the event of equipment failure, pictures which are stored on the mapping 15

system help both dispatchers and troublemen understand what the troublemen will encounter when they 16

reach the site. This will help the troublemen prepare in advance for required activities. In the case of 17

damage where troublemen are first responders and distribution construction and maintenance crews will 18

be called out to perform the main repair, dispatchers will know the closest distribution construction and 19

maintenance crews to the trouble site. In addition, the troubleman can take digital pictures of the actual 20

damage and, using a field tool, attach the pictures to the asset’s file within the mapping system. The 21

pictures can then be viewed both by the dispatcher in the office, helping him or her determine the 22

electrical crew skills needed for the particular job, and by the selected electrical crew using their field 23

tool. This enables the selected crew to determine what materials will be needed before they leave for the 24

trouble site, order it on their field tool, and have it delivered to them when they arrive at the jobsite. 25

This ability to match location, skill sets and material to the job in advance could shorten, to some extent, 26

the time required for the restoration of power. 27

131

(3) Importance of CMS for Compliance 1

CMS will provide TDBU with a tool to help maintain compliance 2

reporting for specific types of work. Inspection and circuit data will come directly from the field 3

without manual intervention and will be validated upon user entry by our back-end office systems to 4

help ensure accuracy and completeness. This application will also include inspection functions not 5

currently covered by TDBU’s limited field tools and will also consolidate all inspection data, such as 6

pole inspections, in one place. In that way, management can tell at a glance what work has been 7

accomplished, what remains to be done, and thus make appropriate decisions about deploying inspection 8

resources. Mobile solutions supports the capturing, transmitting, receiving and reviewing of digital 9

photography of worksites and infractions, helping to ensure accurate inspections of work performed, 10

necessary corrective actions and its related compliance reporting. Also, the ability to provide timely 11

electronic updates to reference material such as CPUC General Order (GO) 95 and GO 165 while 12

employees are in the field ensures all mobile users have the latest manuals and will provide consistent 13

information across all users. 14

c) Description of Deficiencies with TDBU’s Current Process for Managing Field 15

Work 16

(1) Overview 17

As discussed briefly in the introduction, TDBU’s current process for managing 18

field work is handled through a combination of electronic means using limited field tools and paper-19

based processes. 20

In TDBU’s Distribution department, field tool user groups are currently (i) 21

overhead detailed and underground inspectors, (ii) distribution construction crews responsible for 22

maintenance requirements determined by inspections and construction work, and (iii) troublemen who 23

are responsible for responding to trouble calls from customers, circuit interruptions and all emergencies, 24

as well as planned switching programs. In TDBU’s Transmission department, existing field tools are 25

used by patrolmen to perform and record inspections. In TDBU’s Substation department, field tools are 26

used today by system operators to collect equipment reads, and substation inspections. These employees 27

132

represent only a portion of TDBU field employees who could make use of a field tool. In addition 1

limited functionality in current field tools prevents current users from performing all their work 2

electronically (e.g., emergency orders and planned switching programs for troublemen, and construction 3

work for distribution construction and maintenance crews). None of today’s field tools are able to use 4

wireless wide-area networks (W-WAN) to access SCE’s system. Instead, the field tools must be 5

physically connected to the SCE computer system either via a hard-wired local area network (LAN) 6

while “docked” in the office or a wireless access point within an SCE office facility or substation in 7

order to connect and download information needed for work to be performed in the field. Upon 8

returning from the field, all data input by field personnel must be uploaded by the same process. When 9

first implemented, this architecture was necessary because of reliability and data-transfer limitations of 10

the regional wireless voice and data networks. The existing architecture’s reliance on the LAN causes 11

two problems. First, since field personnel could be working in different geographic areas on a daily 12

basis, work orders, together with map and structure data for the entire SCE network must be downloaded 13

on a daily basis (in an overnight “batch” process) before the laptop is disconnected to ensure that the 14

end-user has the latest information regardless of their work location. The significant amount of data that 15

must be downloaded to laptops each evening so as to accurately represent SCE’s vast electrical network 16

strains both hardware and software capabilities. Further complicating this process is the fact that 17

numerous end-users do not return to their home-base overnight (thereby missing a download of 18

information) or they get called out on emergency (potentially getting a partial download of information) 19

or the end-user encounters some sort of technical difficulty because of the sheer volume of data transfer. 20

Even if the daily update occurs without issue, any intra-day asset or system changes will not be reflected 21

on the asset record or maps viewed by the crews or troublemen. Furthermore, during storms or other 22

severe conditions (when system conditions are in a state of flux and up-to-date information is most 23

crucial) when users are working overtime, several days may go by before the users are able to visit an 24

SCE facility and update their laptops. As a result, work progress, electrical equipment, and electrical 25

system changes, entered by crews working on a given circuit, may not be known by other crews working 26

on that circuit before they begin performing their work. 27

133

Another area of difficulty arises from the incompatible platforms currently 1

in use by different groups. Today, there are four separate “Mobile” applications in use by TDBU field 2

personnel: one for troublemen (eMobile Suite), one for distribution inspection and maintenance crews 3

(eMobile Plus), one for transmission patrolmen (Transmission Field Tool), and one for substation 4

operators (Substation Data Collection tool). These platforms are not interchangeable, requiring 5

specialized knowledge for use or technical support. Beyond the technical challenges associated with 6

multiple software platforms, these four applications provide only a portion of TDBU’s needs. For 7

example, they do not provide for real-time dispatching of new assignments to troublemen, patrolmen, or 8

crews, they do not allow crews to transmit work status or work order closure information back to the 9

office (including timekeeping and material usage), and they only allow limited changes to existing maps 10

when errors are noted or improvements are made in the field. 11

Finally, even for those field personnel that are equipped with field tools, 12

much of the information needed still has to be input and transcribed on paper systems. These paper 13

systems create delays and may be prone to transcription errors that result in data reliability issues. In 14

this case, the work completion data described previously is written by hand in the field and provided to 15

the work center by physical transportation. This process is slow, causing computer databases to be out 16

of synch with actual field conditions. There is also a risk of the paper document being lost during 17

transport. There is no immediate validation of either the field employee’s information or the office 18

worker’s input, to alert field or office employees of potential problems. 19

(2) Examples of Current Problem Areas 20

Today, field crews do not have access to the real-time status of the 21

distribution network. As discussed more fully in the comprehensive mapping system testimony, crews 22

cannot see any abnormal conditions or switching that is currently in progress while using their field 23

tools. As a result, crews often have to rely on verbal communications with a system operator to provide 24

the current status of a circuit. In a situation such as a group of failed distribution circuits leading away 25

from a substation (this is often referred to as a “getaway”), many other downstream circuits become de-26

energized. The process of troubleshooting the affected circuits requires the system operator to work 27

134

with the troublemen to open and then close numerous switches to isolate the problem and restore service 1

to our customers. These temporary changes to the circuits’ “normal” conditions require extensive 2

temporary modifications to numerous circuit maps. As a result, crews often have to travel to the central 3

switching center to mark-up paper maps in order to get a full understanding of the circuit conditions 4

before any switching can be performed. 5

With CMS’s real-time data access the crews would be able to view the 6

actual conditions on a circuit and any notes stating special hazards or switching instructions. 7

Additionally, as the field personnel perform switching work to the distribution circuits, they would input 8

this information using CMS. The distribution system network information would then be automatically 9

updated within CMS and accessible to all users, showing the actual, real-time circuit status. All of the 10

above enhance safety and help maintain reliability and restoration of service. 11

The following example comes from an actual incident where a vehicle 12

collided with a pole causing a wire to fall.127 13

Recently, a troubleman responded to a 911 call indicating a vehicle had hit 14

a utility pole, causing the conductor to break and fall to the ground. Upon arriving at the accident site, 15

the troubleman visually assessed the situation and determined that the conductor was on the ground in a 16

brushy area. A small brush fire had started and the line appeared to be energized. A number of people 17

had gathered to witness the accident, and the troubleman asked that everybody stay clear of the 18

conductor while he arranged to have the line de-energized. 19

The troubleman contacted the system operator to determine if any circuits 20

had been tripped. The system operator responded that he did not receive any alarms that indicated 21

circuit tripping. The troubleman then requested that the system operator locate pole switch (PS) number 22

2204 on the Outage Management System (OMS), because the pole switch would isolate the problem. 23

The system operator responded that he had located PS 2204 on the Nicklin 24

12kV circuit. The troubleman’s laptop showed PS 2204 on the Casmalia 12kV circuit. The troubleman 25

127 See Workpaper entitled “YS070553_casmaliaNicklin.”

135

and system operator determined that neither of their displays indicated an abnormal status on either 1

circuit. The troubleman and system operator then discussed the fact that PS 2204 showed up on 2

different circuits, but system operator noted that he had just returned to work, and that maybe there had 3

been some system changes, but did not know if any prior switching had taken place to transfer a portion 4

of the Casmalia circuit to the Nicklin circuit. 5

The troubleman then asked another troubleman who normally works in the 6

area if he had knowledge of whether the Nicklin circuit was now feeding PS 2204. The second 7

troubleman felt that the Casmalia circuit probably fed PS 2204, and stated that he had been switching on 8

the Casmalia circuit the week before and that the Casmalia circuit fed PS 2204 at that time. Because he 9

was driving on the freeway at the time, the second troubleman was unable to check his notes. 10

After talking to the second troubleman, the first troubleman was sure the 11

Casmalia circuit fed PS 2204 and requested that the system operator open the Casmalia circuit breaker. 12

However, he was incorrect. The Casmalia circuit breaker was opened, and after testing the line, the 13

troubleman reported to the system operator that the line was still energized. The system operator then 14

closed the Casmalia circuit breaker, reenergizing the circuit and then opened the Nicklin circuit breaker, 15

de-energizing that circuit. 16

The confusion about the circuits resulted in the loss of valuable time and 17

the wrong circuit being de-energized while the troubleman and system operator attempted to ascertain 18

which circuit fed the affected pole switch. The prolonged outage affects system reliability and increases 19

the general public’s and SCE’s employees’ exposure to hazardous conditions. 20

If TDBU had a consolidated set of mobile tools in place at the time of this 21

incident, in conjunction with a comprehensive mapping system, the system operator and the troubleman 22

would have been looking at the same, current circuit maps, reflecting accurate information regarding the 23

status of the Casmalia and Nicklin circuits. Further, the amount of time it took to restore service could 24

have been shortened. 25

136

d) Project Description, Schedule, and Costs 1

The TDBU Consolidated Mobile Solution project consists of four major 2

objectives: (i) acquisition of a new software application combining SCE’s current field tool applications 3

into one single application to support the implementation of consolidated mobile capabilities, (ii) 4

configure SCE’s back-end office systems to provide real-time information between laptops and the 5

office, (iii) configure the mobile application to enable new functionality , such as work order processing 6

(i.e., construction, trouble orders, etc.), time sheets, graphics (GIS mapping, design, etc.), and (iv) 7

purchasing sufficient additional field tools in order to equip new users (e.g., substation testmen, 8

construction contractors, intrusive pole inspectors, etc.) within TDBU. 9

Based upon our best information to date, SCE’s estimated cost for TDBU’s 10

portion of this project during 2009-2011 is approximately $17.5 million in capital128 and $1.57 million 11

for Test Year O&M costs. Table IV-28 below summarizes TDBU’s annual estimated capital costs. The 12

funding of $1.57 million for the associated TDBU O&M costs over the period 2009-2011 is being 13

requested in the testimony in Exhibit SCE-03, Volume 2. 14

Table IV-28 CMS Capital Expenditures

2007 2008 2009 2010 2011 Total

Capital $0.00M $0.00M $3.85M $10.65M $3.00M $17.50M

Our preliminary expenditure estimates for this project were determined by the 15

following processes and methods: (i) a discussion with other utilities around their mobile tool 16

implementation scope and approach; (ii) communication with vendor regarding site licensing fees, 17

project scope and project costs; and (iii) consultation with internal SCE subject matter experts in the 18

implementation of other SCE projects of similar scope and objectives.129 19

128 The first objective (acquisition of software application) will be funded through SCE’s Information Technology Business

Unit’s budget, at an estimated additional cost of $7.5 million bringing the total cost of the project to $25.0 million. See “TDBU Mobile Systems” testimony in this volume. See Workpaper entitled “TDBU Consolidated Mobile Cost Detail.”

129 See Workpaper entitled “Mobile Tools Due Diligence.”

137

SCE plans to implement the Consolidated Mobile Solution in a five phase 1

approach. Phase 1 includes project analysis and planning. During this phase, the “to-be” state of 2

TDBU’s work management processes will be established and business requirements will be defined. 3

The project’s cost, scope, and the timeline will be determined. Finally, product vendor selection will be 4

undertaken via a competitive request for proposal process. This phase is scheduled to begin in the first 5

quarter of 2009 and be completed by the third quarter of 2009. 6

Phase 2, a design phase, consists of finalizing business requirements and project 7

costs, scope and activities, culminating in the purchase of the software application. This phase is 8

scheduled to begin in the third quarter of 2009 and be completed during the fourth quarter of 2009. 9

Total capital expenditure for this design phase is estimated to be $11.35 million, which includes $3.85 10

million discussed in this Volume. 11

Phase 3 includes software development and configuration activities. It consists of 12

configuring the system, application, and interface, and integrating the system with existing SCE systems 13

along with purchasing all required hardware (field tools). This phase is scheduled to begin in the first 14

quarter of 2010 and be completed during the third quarter of 2010. Total capital expenditure for this 15

phase is estimated to be $8.65 million. 16

Phase 4 includes factory acceptance testing, system integration testing and 17

software acceptance testing, which consists of a setting up the actual hardware and software that will be 18

used at SCE’s facilities and running a full set of test scripts to ensure every system component performs 19

as specified. Training materials and a user training program will also be developed. This phase is 20

scheduled to begin in the fourth quarter of 2010 and be completed during the first quarter of 2011. Total 21

capital expenditure for this phase is estimated to be $2.50 million. 22

Phase 5 is deployment of the TDBU Consolidated Mobile Solution to the end-23

users. During this phase, hardware and software will be installed and configured, and the end-users will 24

receive the required training. This phase is scheduled for the second quarter of 2011. Total capital 25

expenditure for this phase is estimated to be $2.50 million. 26

138

e) Conclusion 1

Although great strides have been taken within TDBU to make its enterprise 2

systems available to field personnel, many employees remain outside of the “field tool” network, and 3

system functionality still remains unavailable to a number of field personnel. As a result of this 4

electronic “disconnection”, field personnel doing assigned work are physically disconnected from the 5

computer systems that generate and prioritize work for them, provide them with the information they 6

may need to accomplish their work, or convey information from them back to employees in the office. 7

The TDBU Consolidated Mobile Solution will allow field personnel, system operators, and office 8

workers to share real-time information so as to enhance safety and compliance and maintain reliability. 9

C. Customer Service Business Unit (CSBU) 10

1. Bill Redesign Project (BRP) 11

a) Introduction 12

On January 25, 2007, the Commission issued Resolution E-4053 approving 13

Advice Letter 2058-E to implement a redesigned bill format for our various Energy Statements and 14

collection/disconnection notices. Resolution E-4053 also adopted our proposal to offer customers an 15

optional simplified bill format which omits certain billing component detail only upon the customer’s 16

request.130 These redesigned bill formats are consistent with the Commission’s policies that direct the 17

utilities to develop more customer-friendly bill formats.131 18

In this proceeding, the Bill Redesign Project (BRP) is a capitalized software 19

project required to implement our redesigned bill format as authorized by Resolution E-4053. The BRP 20

capitalized software project will be fully implemented by the fourth quarter of 2007 at a forecast total 21

expenditure of $1.8 million for 2007. 22

130 Energy Division approved our compliance Advice Letter on May 4, 2007 which approved all of the redesigned bill

formats. 131 See for example, Decision No. (D.) 05-11-009.

139

(1) Overview 1

This section presents the need and costs for the BRP project. First, we 2

describe the need for a redesigned customer bill and the customer benefits that will occur once the 3

redesigned bill is implemented as directed by the Commission in Resolution E-4053. This section 4

provides the basis for understanding the need for the BRP project and the value provided for our 5

customers. 6

(a) Need For Redesigned Bill 7

As the Commission recognized in Resolution E-4053, since 1997, 8

our bill format has grown in complexity as a result of expanded requirements under the California Public 9

Utilities Code and Commission decisions.132 These provisions imposed requirements on SCE and the 10

other electric utilities to separately identify and define rate components on the bill in order to provide 11

information that the Legislature and the Commission determined would be helpful in a restructured 12

electricity market. Further complicating the bill are Commission-mandated bill requirements issued in 13

response to the energy crisis of 2000-2001, which required additional rate components be displayed on 14

the bill including rate components to recover the Department of Water Resources (DWR) bond and 15

power contract costs. The result is a bill that became increasingly difficult for our customers to 16

comprehend. 17

Given the complexity of the bill and Commission directives to 18

make the bill more customer friendly, on November 11, 2006, we filed Advice Letter 2058-E seeking: 19

• Approval of the redesigned bill formats 20

• Approval of the customer optional simplified bill format 21

• Withdrawal of forms no longer in use 22

(b) Redesigned Bill Format Structure 23

On January 25, 2007, the Commission issued Resolution E-4053 24

approving SCE’s request to redesign its bill. The redesigned bill format for an average residential 25

132 Resolution E-4053.

140

customer will run on three sheets, without a bill insert.133 The redesigned bill format will be printed on 1

both front and back sides of three sheets of 8½” x 11” paper using the duplex printing method. This 2

eliminates the need for preprinted information on the back of each page and will allow for the terms and 3

conditions to be more tailored to each customer class. In the redesigned format, all detailed billing 4

information will continue to be included on the bill. 5

The redesigned bill eliminates the need for a separate bill insert, as 6

bill insert information will be included on a dedicated third sheet of the bill, referred to as the “onsert” 7

page. The onsert page provides customers with program, service, legal, regulatory, and customer and 8

business connection information. Additionally, this section enables customers to easily take action on 9

various programs and services by periodically including applications that can be filled out and returned 10

with the payment stub. Finally, the onsert page eliminates the need for separate bill inserts, which 11

customer research shows are less likely to be read than information provided in an onsert format. 12

(2) Project Expenditures 13

The BRP capitalized software project covers the software programming 14

required to implement the redesigned bill formats as authorized by Resolution E-4053. Software 15

programming is essential as the new bill formats must be programmed into SCE’s current Customer 16

Service System in order to present the billing information in the redesigned bill format adopted by the 17

Commission. The specific capitalized software expenditures are discussed in the sections that follow. 18

Two additional printers needed for the redesigned bill format were 19

acquired at the end of 2006 at a cost of $3.639 million. The printers and related printing equipment will 20

be placed in service with the implementation of the BRP in November 2007. The cost of hardware such 21

as the two printers is not included in the BRP capitalized software costs. 22

The redesigned bill will result in an additional net increase of $1.546 23

million for ongoing O&M expenses in the Test Year. O&M expenses are forecast to increase by $2.460 24

133 SCE’s current bill format for an average residential customer runs on two sheets. The current bill is printed on 6½”x 11”

bill stock using the simplex printing method with preprinted information on the back of the bill stock. An insert normally accompanies the bill and is printed on a single page of 3-fold paper with four to six panels.

141

million and will be reduced by the avoided bill insert printing costs of $0.914 million. These operating 1

costs and the avoided bill insert costs are discussed below. 2

(3) Vendor Selection Process 3

We used two outside vendors to perform the software programming for 4

this project. Our IT department has pre-selected and approved information systems Service Deliverables 5

Support (SDS) vendors. The SDS vendors were evaluated for this project based upon the following 6

criteria: 7

1. The ability to meet business requirements now and in the 8


2. General and technical requirements; and 10

3. Cost. 11

We selected two SDS vendors to perform the planning, analysis, design, 12

construction, test, and implementation phases of the project. We awarded the work based on the 13

vendors’ expertise, experience, and cost. 14

(4) Description Of The BRP Capitalized Software Expenditures 15

The forecast capitalized software expenditures of $1.8 million for the BRP 16

project are comprised of software, infrastructure/facility, and hardware configuration. These 17

expenditures are shown in the following table. 18

Table IV-29 Project Expenditures

In Millions Description Amount

Software $1.226 Infrastructure/Facility $0.539 Hardware Configuration $0.035

Total $1.800

(a) Software 19

The forecast expenditure of $1.226 million for this category covers 20

all areas of application development such as planning, analysis, design, construction, testing, and 21

142

implementation of the programming necessary to print the redesigned bill information. Vendor support 1

services are also required to facilitate new hardware/software installation and programming, which is not 2

maintained nor supported internally. In addition, project and project management support (staffing) is 3

needed for every area of the project life cycle in order to ensure quality control, subject matter expertise, 4

documentation, and program overview. 5

(b) Infrastructure / Facility 6

Modifications to the existing infrastructure/facility are needed to 7

handle the increased printing capacity now required because the bill insert information will be printed as 8

part of the bill (bill onsert). The forecast expenditure of $0.539 million includes additional power 9

supply, additional air conditioning to accommodate the added heat loads of the new printing equipment, 10

and a central vacuum system with dust collection capabilities. 11

(c) Hardware Configuration 12

This category of expenditures is necessary so the new printers and 13

inserters will operate effectively. The forecast expenditure of $35,000 includes installation and 14

configuration management, and non-recurring support labor for the printers and inserters, and related 15

equipment. It also includes additional equipment required in the Accounts Receivable Department that 16

will handle the incoming payment coupons and payments. 17

(5) Test Year O&M Expenses 18

The BRP’s additional printing operations will increase O&M expenses by 19

$1.546 million and are included in the forecast of IT Customer Service O&M Expenses in FERC 20

Accounts 920 and 921. The total increase in printing operating and maintenance costs of $2.460 million 21

has been reduced by the avoided external bill insert printing costs of $0.914 million. We discuss the 22

increased printing operations and maintenance costs in this section and the avoided external bill insert 23

costs of $0.914 million in the following section. 24

The BRP increased O&M expenses are comprised of operating costs, 25

forms and envelopes, maintenance fees, and Accounts Receivable support. These costs are show in the 26

following table. 27

143

Table IV-30 BRP Increased Ongoing O&M Costs

2006 $ millions ITEM COST FERC Account

Operating costs: • Toner/Developer • Printer usage • 10 FTEs

$0.701 $0.331 $0.470

921 921 920

Forms and Envelopes $0.835 921 Maintenance fees $0.079 921 Accounts Receivable support $0.044 920

Sub total $2.460 Less: Avoided external insert printing cost ($0.914) 920, 905.900

Increased Printing O&M Expenses $1.546

(a) Operating Costs 1

The redesigned bill required additional printing capacity to 2

produce the additional page of onsert information. To accomplish this, we added additional printing 3

equipment at our Irvine Operations Center facility. An additional ten FTEs are required to staff the new 4

bill production operations to produce all of the bills and onserts (previously inserts) for our customers. 5

Non-labor operating costs are comprised of toner/developer and printer usage. The larger bill stock 6

(8½”x11”), an additional page for the onsert, and printing bill and onsert information on both sides of 7

the bill requires more toner/developer and printer use. 8

(b) Forms and Envelopes 9

The additional cost for forms and envelopes is necessary because 10

the new bill statement will be printed on both sides of three pages of 8½-by-11 inch paper. The previous 11

bill stock was smaller and typically ran on two pages. Envelope cost increases because of the increased 12

paper size necessary to include the reformatted bill and insert information. 13

(c) Maintenance Fees and Accounts Recievable Cost 14

Maintenance fees are incurred on a per page basis for the printers. 15

With the addition of the bill onsert page, one additional page per bill will be generated resulting in 16

increased maintenance fees forecast at $79,000. Accounts Receivable costs of $44,000 are attributed to 17

144

additional staff in support of new payment stub process and longer processing time. The change in 1

paper size adds processing time to the remittance process resulting in degradation in output. Thus, 2

additional personnel are needed to maintain service level performance. 3

(6) Project Benefits And Avoided Cost 4

As discussed earlier, the BRP capitalized software project is necessary to 5

complete the programming in the Customer Service System so that the redesigned bill can be produced 6

in the format authorized by Resolution E-4053. Once this capitalized software project is complete and 7

the redesigned bill format implemented, our customers will realize significant benefits from a bill that is 8

easier to understand and useful information to help manage their energy use. 9

The BRP project will reduce O&M expenses for external bill insert 10

printing costs incurred by Corporate Communications, Law Department and CSBU organizations along 11

with non-GRC activities and programs including PGC, Demand Response, and low income programs. 12

The external bill insert printing cost will no longer be incurred and as the bill inserts will be replaced 13

with bill onserts. To address the avoided external bill insert printing costs, the Last Recorded Year of 14

external bill insert printing cost of $0.914 million have been removed from the increased incremental 15

O&M cost to result in a net O&M increase of $1.546 million ($2.460 million - $0.914 million). The 16

recorded external bill insert printing costs for 2006 is shown in the following table. 17

Table IV-31 Avoided Bill Insert Printing O&M Costs

2006 $ millions Organization FERC Account 2006

Corporate Communications 920 $0.567 Law Department 920 $0.299 CSBU 905.900 $0.048

Total Avoided Bill Insert Printing O&M Costs

$0.914

(7) Project Implementation 18

The BRP project is scheduled for completion during the fourth quarter of 19

2007. The BRP project is reviewed on a regular basis at project status meetings for adherence with 20

145

budget, schedule and technical objectives. We use standard project management tools and techniques to 1

manage this project. The BRP project is being implemented under the following schedule: 2

Table IV-32 BRP Milestones and Completion Dates

Milestone Completion Date Planning November 2006

Analysis December 2006

Design March 2007

Construction & Unit Test September 2007

Systems Test, Regression Test & Acceptance November 2007

Implementation November 2007

Post Implementation January 2008

The BRP project is currently on schedule and on budget. 3

(8) Summary 4

The overall impact of this project is positive from several important 5

perspectives. BRP provides customers with required bill information along with other information about 6

customer programs we offer. The successful completion of this project will improve our customers’ 7

understanding of their energy use and provide them with useful information to make good energy use 8

decisions. 9

146

V. 1

TECHNOLOGY AND RISK MANAGEMENT 2

A. Information Security 3

1. Background 4

Information Security covers requirements to protect critical SCE systems and sensitive 5

information from cyber attacks. SCE’s Information Security requirements have three primary areas of 6

focus: 7

• Perimeter Defense 8

Protecting SCE information and systems from external attacks 9

• Interior Defense 10

Protecting SCE information and systems from internal attacks 11

• Data Protection 12

Implementing data protection and information assurance capabilities 13

SCE’s computer network is segregated into two major parts: (1) the Administrative 14

Network, and (2) the Control Systems Network. The two networks are linked only via specific and 15

controlled access points, but are otherwise physically separate. The Control Systems Network is used 16

by our electric power grid operations, whereas the Administrative Network supports all other 17

applications. This segregation follows industry best practices to prevent security incidents in either 18

network from affecting or impacting the other. Advances in technology, especially those related to 19

wireless communications and internet telephony, are requiring us to revisit the design and control of 20

how these networks can link to each other. Security issues arising from such access control of the two 21

networks are addressed separately in this project.134 This project addresses the security expenditures to 22

protect the Administrative Network and its linkages to the Control Systems Network. The specific 23

requirements to support NERC/CIP cyber security standards are covered elsewhere in this exhibit.135 24

134 These two networks are addressed separately by: SCE-5, Volume 3, Information Security and SCE-5 Volume 3 NERC

CIP Compliance. 135 See SCE-5, Volume 3, NERC CIP Compliance.

147

With a growing number of security threats, the need for Information Security activities 1

has increased substantially, which will require additional investment to protect our critical information 2

systems. The increasing level of Information Security activity is a result of a number of factors, 3

including: 4

• The ever-increasing level of cyber security threats faced by SCE. 5

• The need to replace obsolete equipment that is no longer supported or effective. 6

• The increasing level of regulatory-compliance requirements. 7

• Ever-increasing reliance of SCE business operations on emerging technologies, 8

such as mobile and wireless communications. 9

• Enhanced collaboration of SCE with business partners and external entities and 10

their associated security requirements. 11

• The growing need to strengthen internal controls and the availability of new 12

security technologies. 13

• Historically less funding on these areas compared to industry peers. 14


As with many other utilities and companies, SCE is facing more frequent and more 16

destructive cyber threats, while simultaneously being required to comply with a growing number of 17

regulations impacting information security. 18

SCE experienced an average of nearly 14 million cyber threats per month in 2006.136 The 19

annual level of cyber threats for 2006 was nearly 167 million attacks, which represents an approximate 20

1,500 percent increase over 2003, as shown in Figure V-13 below: 21

136 See Workpaper entitled “Cyber Attacks Targeting SCE By Year.”

148

Figure V-13 Risk Management – Information Security

Total Threats To SCE

020,000,00040,000,00060,000,00080,000,000

100,000,000120,000,000140,000,000160,000,000180,000,000

2003 2004 2005 2006

2003 2004 2005 2006

Total 10,605,138 44,205,857 63,131,000 166,950,410

Included in these attacks are computer viruses, hackers targeting our network gateways, 1

and malicious emails embedded with phishing scams, viruses, and other exploits. 2

Additionally, the number of vulnerabilities, announced by major technology vendors such 3

as Microsoft and Cisco, has increased by 800 percent since 2000,137 as shown in Figure V-14 below: 4

137 See Workpaper entitled “CERT Statistics for security vulnerabilities tracked per year.”

149

Figure V-14 Identified Security Vulnerabilities

01,0002,0003,0004,0005,0006,0007,0008,0009,000

2000 2001 2002 2003 2004 2005 2006

2000 2001 2002 2003 2004 2005 2006

Amount 1,090 2,437 4,129 3,784 3,780 5,990 8,064

Beyond defending SCE’s information systems against such threats, SCE also faces 1

increased regulatory requirements, many of which have significant impact on information security 2

activities. In addition to compliance with existing regulatory demands, such as HIPPA, Sarbanes Oxley 3

Act, and California Senate Bill 1386, SCE must also comply with emerging regulatory requirements 4

such as NERC CIP and the Payment Card Industry Data Security Standards,138 which will be required 5

for SCE customers to pay their bills using major credit cards. Failure to comply with such regulations 6

would impact our customers. Additionally, security experts predict that information security regulatory 7

requirements will continue to increase in the next few years.139 8

SCE, more than ever, is relying on emerging technologies such as wireless-enabled 9

laptops for field personnel and PDAs (Personal Digital Assistant) for mobile professionals. These 10

138 See Workpapers entitled “Payment Card Industry Compliance Analysis” and “Payment Card Industry (PCI) Data

Security Standards.” 139 See Workpaper entitled “The 2006 Planning Guidance for Compliance: Risk-Orientation, Standardization and

Automation.”

150

emerging technologies improve customer service and productivity, but introduce potential 1

vulnerabilities that need to be mitigated. 2

Likewise, SCE has increased our collaboration with vendors, business partners, and 3

external agencies. This collaboration requires setting up network connections with entities such as the 4

California Independent System Operator, outside engineering firms, and offshore business partners. 5

This external collaboration requires a well-designed and executed security infrastructure to protect 6

sensitive information, while still allowing the flow of information needed for the business transaction 7

with these partners. 8

To date, SCE has been able to secure our IT systems and data, while keeping costs well 9

below industry standards. SCE’s Information Security expenditure, which is 0.78 percent of total IT 10

costs, is substantially lower that the industry standard of three percent.140 In order to continue to 11

adequately secure our IT systems and assets with the increasing threats, however, SCE needs to expand 12

our security infrastructure. 13

In meeting our information security challenges, we have three primary areas of focus: 14

• Perimeter Defense: The objective of the Perimeter Defense program is to 15

protect SCE from external threats from the Internet. SCE is under continuous 16

cyber attack,141 and the attack methods, exploits, and capabilities are 17

constantly evolving as new types of attacks are discovered. Such attacks 18

include computer viruses, worms, phishing,142 and spyware, any of which 19

could cause significant damage to SCE’s information systems if successful. 20

• Interior Defense: The objective of the Interior Defense program is to identify, 21

separate, and manage access to corporate information by SCE employees, 22

contractors, third-party business partners (including offshore partners), and 23

140 See Workpaper entitled “Information Risk Budget and Organizational Benchmarks – 2006 Survey Results.” 141 See Workpaper entitled “2006 Threat Metrics by Month.” 142 See Workpaper entitled “Reduce Spam by Using E-Mail Authentication Technology” for definition of “phishing.”

151

other entities.143 The segregation of internal IT infrastructure will prevent 1

outages and unintentional errors from impacting critical operations such as 2

financial, customer service, and supply chain. 3

• Data Protection: The objective of the Data Protection program is to protect 4

SCE customers, employees, contractors, and other personnel from identity 5

theft,144 as well as to protect confidential SCE information residing on all 6

computing devices from unauthorized use, distribution, reproduction, 7

alteration, or destruction.145 8

a) Recorded And Forecast Expenditures 9

We developed the expenditure forecasts in this section based on the following 10

approach: 11

• Identify vendors and products that best match our requirements. 12

• Request cost estimates from multiple vendors offering similar products 13

to compare costs. 14

• Estimate implementation costs based on leading information security 15

industry experts’ assessments and recommendations. 16

• Take the least-cost approach if upgrading existing products is a cost-17

effective option. 18

143 See Workpaper entitled “Interior Defense Analogy.” 144 See Workpaper entitled “Federal Trade Commission, “Identity Theft Victim Complaint Data, Figures and Trends in

California.” California is the 3rd highest state per capita for identity theft. 145 See Workpaper entitled, “Organizations Must Employ Effective Data Security Strategies.”

152

b) Perimeter Defense Expenditures 1

Figure V-15 Perimeter Defense Program Expenditures

2002–2006 Recorded And 2007-2011 Forecast (Nominal $000)

Amount

$0.00

$500.00

$1,000.00

$1,500.00

$2,000.00

$2,500.00

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

Amount $492.30 $1,212.20 $504.90 $1,396.50 $1,219.80 $949.00 $1,043.00 $1,647.30 $1,916.30 $1,500.00

Recorded Forecast

The scope of the Perimeter Defense program (also called Internet Security) 2

includes the implementation and replacement of security monitoring, alerting, and defense management 3

capabilities at various network perimeters. 4

The requested funds are needed to implement the following Perimeter Defense 5

solutions,146 described in Table V-33: 6

146 See Workpaper entitled “Perimeter Defense Forecast Detail” for additional spend analysis.

153

Table V-33 Perimeter Defense Solutions And Forecasted Expenditures

(Nominal $000) Description of Solution Forecast

1 Implement and replace cyber security controls that centralize security alerts, logs, and analysis, including event correlation tools, and tools to identify, analyze, alert, and report security incidents.

$1,287.0

2 Implement preventative security controls with intelligence to automatically respond and defend the perimeter, including third-party network connections, and automated security controls and enterprise-wide vulnerability detection tools to identify and mitigate potential weaknesses in SCE’s IT infrastructure.

$3,170.3

3 Install and consolidate secure access gateways to external networks and systems, including wireless systems: deployment of security third-party network connections (e.g. virtual private networks and other control tools), consolidate the network channels to enable more efficient monitoring, analysis, and response to suspect activity from third-party business partners.

$1,153.3

4 Implement additional anti-virus products for control and prevention to guard against new and evolving threats and malicious intrusions such as spam, spyware, and phising attacks.

$60.0

5 Install security controls to prevent the unauthorized export of confidential data from internal sources, such as export of confidential data from SCE internal email, instant messaging and other communication technologies.

$820.0

6 Install application layer protection against web-based cyber attacks targeting SCE websites and internet-based services.

$565.0

Total $7,055.6

154

c) Interior Defense Program 1

Figure V-16 Interior Defense Program Expenditures

2002–2006 Recorded And 2007-2011 Forecast (Nominal $000)

$0.0

$1,000.0

$2,000.0

$3,000.0

$4,000.0

$5,000.0

$6,000.0

2007 2008 2009 2010 2011

2007 2008 2009 2010 2011Amount $510.0 $2,550.0 $5,075.0 $4,075.0 $2,575.0

Forecast

The objective of the new Interior Defense program is to implement security 2

controls, processes, and capabilities to protect SCE from potential threats originating from within SCE, 3

entering through third-party partner networks, or from on-site contractors. 4

Having concentrated our past information security investments almost entirely on 5

perimeter defense, SCE now requires a concerted effort to shore up our interior defenses in the face of 6

the following: 7

• Security breaches are increasingly reported from “insiders” in the 8

industry.147 9

• Insiders who are familiar with the company’s computer systems, 10

networks, and data could cause more damage than others.148 11

• Technology for interior defense is becoming more available and mature in 12

the market place. 13

147 See Workpaper entitled “Insider Attack Are a Thorny Problem,” and “Ignoring the Insider Threat.” 148 Id.

155

Industry experts forecast that 60 percent of security breach incident costs are 1

financially or politically motivated, and that most of the losses will be caused by insiders such as 2

employees, contractors, and third-party business partners.149 Additionally, compliance and regulatory 3

requirements for a specific scope such as financial, customer, and medical systems require that those 4

systems be segregated from other IT systems. 5

SCE can better manage, control, monitor and mitigate security threats, risks and 6

vulnerabilities by segregating IT infrastructure that support critical business operations. These 7

segregated networks will be separated so that billing data, for example, is located in one “zone” while 8

operational data is located in another “zone.” By compartmentalizing data into multiple zones, SCE will 9

be able to apply the correct level of protection to each zone. In addition, we will deploy computer 10

forensics tools with advanced monitoring capabilities to allow our information security experts to 11

quickly diagnose, trace, and stop internal security breaches. 12

The requested expenditures are needed to implement the following Interior 13

Defense security solutions150 set forth in Table V-34: 14

149 Id. 150 See Workpaper entitled “Interior Defense Forecast Detail” for additional spend analysis.”

156

Table V-34 Interior Defense Solutions And Forecast Expenditures


1 Implement internal network controls to protect sensitive applications and infrastructure, including sub networks for SCE internal applications and systems., i.e. financial systems and customer databases.

$700.0

2 Implement proper levels of access controls, monitoring, alerting capabilities, and authentication controls to protect applications and databases.

$2,000.0

3 Deploy secure remote access solutions that allow employees, consultants, and contractors to access only the right kind of information, including access controls for remote and third-party laptop access to SCE applications, systems and networks.

$1,950.0

4 Secure communications between SCE internal applications, systems and networks with external entities, including centralized enterprise-wide encryption and access control system for communication between applications, systems, and networks between SCE and third-parties.

$4,400.0

5 Implement advanced computer forensic tools to diagnose, trace, and track sources of interior vulnerabilities, identify, analyze, and report of suspect activity including inappropriate web browsing, email, or unauthorized access requests.

$180.0

6 Implement tools to provide auditability, traceability, and reporting capabilities on access controls, including capabilities to record and store security control activities, configuration changes, exceptions, and alerts.

$4,735.0

7 Implement reporting capabilities to demonstrate compliance with existing (SOX, SB1386, HIPPA) and new regulatory mandates, including reporting, documentation, and audit oversight for regulatory requirements.

$820.0

Total $14,785.0

157

d) Data Protection Expenditures 1

Figure V-17 Data Protection Program Expenditures

2002–2006 Recorded And 2007–2011 Forecast (Nominal $000)

$0.0

$500.0

$1,000.0

$1,500.0

$2,000.0

$2,500.0

$3,000.0

$3,500.0

$4,000.0

2007 2008 2009 2010 2011

2007 2008 2009 2010 2011Amount $500.0 $1,500.0 $3,345.0 $3,600.0 $3,000.0

Forecast

The objective of the new Data Protection security program is to protect SCE 2

confidential data, including SCE customer and employee personal information.151 Ensuring that 3

sensitive and confidential data are protected from loss and unauthorized use is becoming increasingly 4

critical to SCE as a result of the following: 5

• Customer, employee, and credit card data are being processed online. 6

• Increased regulation, oversight, and scrutiny on securing confidential data 7

against malice.152 8

• Increasing collaboration with onshore and offshore vendors that require 9

sharing data over network connections. 10

• Proliferation and increasing sophistication of data theft criminal activities and 11

a growing market for the stolen data.153 12

151 See Workpaper entitled “Insider Attack Are a Thorny Problem,” and “Ignoring the Insider Threat.” 152 See Workpaper entitled “Utility Regulators Need to Protect the Public’s Financial Information.” 153 See Workpaper entitled “How Does the Hacker Economy Work?”

158

The requested funds are needed to implement the Data Protection security 1

solutions154 described in Table V-35 2

Table V-35 Data Protection Security Solutions Forecast Expenditures


1 Implement tools to ensure the protection of confidential and personally identifiable information and data during creation, acquisition, storage, transmission, maintenance, and destruction.

$2,030.0

2 Deploy encryption and other security controls to protect confidential data on laptops, desktops, and other devices including Blackberry and PDA’s.

$3,230.0

3 Implement security controls for confidential data that is used by SCE’s business partners and other third-party entities, including extending data protection to third parties utilizing encryption key exchange, access control tools, and audit requirements.

$2,055.0

4 Implement security controls required for compliance with Payment Card Industry Data Security Standards (PCI DSS).

$4,270.0

5 Implement controls, monitoring, blocking, alert/reporting capabilities to prevent, detect, and block unauthorized use and transport of confidential data.

$360.0

Total $11,945.0

3. Analysis 3

The expenditures in period of 2002-2006 built a solid security foundation to protect 4

SCE’s critical information systems. Our Information Security department was able to deploy automated 5

network defenses at the Internet, Extranet, and other cyber gateways. Additionally, anti-virus tools and 6

capabilities were centralized and more efficiently managed. As a result of these and other security 7

controls, SCE has successfully defended the network from cyber attacks launched from outside, 8

preventing major disruption to business operations, despite the significant increase in the level of cyber 9

threats we have faced. 10

However, the tools that were deployed for perimeter defense are reaching obsolescence 11

and need to be replaced with up-to-date solutions that can keep up with more advanced, complex, and 12

damaging threats. 13

In addition, we need to strengthen our internal controls and data protection capability to 14

keep up with regulatory demands and threats from the inside. SCE’s growing collaboration with 15

154 See Workpaper entitled “Data Protection Forecast Detail” for additional spend analysis.”

159

business partners, reliance on contractors, and enhanced use of mobile and wireless devices makes the 1

strengthening of internal controls and data protection a very high priority. 2

As security controls have improved, so have the sophistication of cyber attacks. SCE 3

must continue to be vigilant and proactive to prevent security incidents from disrupting business 4

operations while allowing employees, business partners and other entities access to SCE over the 5

Internet and other cyber gateways. 6

a) Alternatives Considered 7

An alternative to these programs is to rely on current security controls to protect 8

against future cyber threats. This alternative is unacceptable because it will insufficiently address 9

existing and new requirements that will be essential to defend our systems against evolving cyber 10

threats. Therefore, given the choices, SCE recommends to pursue the full funding needed to shore up 11

perimeter defense, interior defense, and data protection to be equipped to adequately address the 12

increasing frequency and sophistication of information security threats. Anything less will put SCE’s 13

systems and operations at risk. Another alternative considered was to reduce the scope of the programs 14

to exclude the Data Protection Program. This alternative is rejected because it will not provide the 15

needed data protection such as data encryption or unauthorized data access monitoring and blocking for 16

our confidential and sensitive data. 17

4. Conclusion 18

Increased funding is critical to enable SCE to continue to prevent cyber attacks from 19

impacting our business and electric power operations. While the proposed programs costs have 20

increased from prior spending levels, the forecast expenditures are necessary to replace obsolete security 21

controls, comply with regulatory requirements, and mitigate evolving and new cyber threats. 22

Additionally, the Information Security 2006 recorded capital and O&M expenditure represents 0.78 23

percent of total IT costs, which is well below the three percent for the electric utility industry in general. 24

Without these expenditures, SCE will not be able to protect its critical assets from cyber threats, meet 25

compliance requirements, or prevent disruptions to business operations. 26

160

B. Business Continuity Planning Systems 1

1. Background 2

The IT Business Continuity Planning group is responsible for SCE’s Business Continuity 3

program and works collaboratively with SCE business units to develop and update enterprise strategies 4

and priorities for emergency response and recovery. This group conducts periodic facilitated Business 5

Impact Analyses with SCE business units to identify and update critical business processes and their 6

technology dependencies, the risks associated with various event scenarios, and their impact on SCE 7

business units and IT’s ability to continue operations.155 The scenarios in the impact analyses include: 8

• Natural events such as earthquake, fire, flooding, heat wave, or pandemics. 9

• Events caused by human actions such as terrorism, civil unrest, computer sabotage, 10

cyber attacks, or human errors. 11

• Technology and operational events such as cascading systems failure, loss of power, 12

or unexpected network outage. 13

As a result of the facilitated Business Impact Analyses,156 SCE updates its existing 14

emergency response and disaster recovery plans and develops new plans as needed. These plans cover 15

the necessary processes, procedures, facilities, equipment, and technologies157 that will enable SCE to 16

continue operations during and after a disastrous event. 17

Additionally, the Business Continuity Planning group participates in annual corporate-18

wide emergency response exercises. These exercises include IT disaster recovery tests on the required 19

processes, procedures, priorities, and resources to enable the resumption of critical business activities. 20

The funding requirements for Business Continuity Planning do not overlap with the funding needed for 21

155 See Workpaper entitled “Guide to Business Continuity Management.” Available online at

http://www.knowledgeleader.com/knowledgeleader/content.nsf/web+content/businesscontinuitymanagementguidetobusinesscontinuitymanagement!opendocument.

156 See Workpaper entitled “Best Practices for Conducting a Business Impact Analysis.” 157 See SCE-5, Volume 2, Disaster Recovery Hardware for additional details.

161

IT Disaster Recovery158 that is, the former covers only the needed system replacements for enterprise-1

wide Business Continuity Planning, Crisis Management, and Crisis Communications. The funding 2

forecast for IT Disaster Recovery is to refresh aged equipment, as well as acquire additional equipment 3

to strengthen system recovery capabilities.159 4


Our recent corporate emergency response exercise has demonstrated that to effectively 6

respond to an emergency event, we need more robust vendor-supported systems. In particular, the 7

emergency response exercises performed with SCE’s existing systems exposed deficiencies in SCE’s 8

ability to sustain operations during a disaster. These deficiencies are primarily attributable to the 9

limitations of the current systems, which utilize obsolete technology, receive no vendor support, and are 10

connected by manual procedures which are susceptible to failing during a true crisis. Continued reliance 11

on these obsolete and unsupported systems will impede SCE’s ability to communicate timely outage 12

information to customers, regulators, and the general public. Furthermore, these systems restrict SCE’s 13

ability to quickly and effectively resume normal operations in power delivery and customer service after 14

a disaster event, such as a major earthquake or pandemic outbreak. 15

Specifically, SCE needs to implement two systems to strengthen the business continuity 16

capabilities of the company: 17

• Enterprise-wide Business Continuity Planning system. 18

• Enterprise-wide Crisis Management system. 19

An enterprise-wide business continuity planning system will provide a set of tools and a 20

central repository for business continuity plans, including business impact analyses, risk assessments, 21

facility-based evacuation and disaster recovery plans. This system will contain the needed information 22

on systems, people, equipment, and office space that are required to support essential business functions. 23

158 See SCE-5, Volume 2, Disaster Recovery Hardware. IT Operations is responsible for the implementation of IT disaster

recovery plans. 159 See Workpaper entitled “Business Continuity Planning Software: Technology Overview.” See also IT Disaster

Recovery Testimony in SCE-5, Volume 3, for additional details.

162

Additionally, the system will provide the procedures to resume business operations and recover system 1

capabilities in a major disaster. In centralizing these tools and capabilities into a single system, we 2

expect to increase our business continuity capabilities over the current methodology, which includes the 3

use of separate and disjointed tools tied together by manual procedures. Relying on manual procedures, 4

especially during an emergency, significantly increases our vulnerability to human error and delay. The 5

new system will have an appropriate level of redundancy to remain available and accessible in the event 6

of a disaster. 7

An enterprise-wide crisis management system provides the capability for large and 8

dispersed teams to coordinate their activities and provide minute-by-minute information to stakeholders 9

on the status of recovery efforts during an emergency or disastrous event. The system that has been in 10

use since 2001 was custom-built for SCE and is no longer supported by the vendor. Therefore, any 11

necessary changes involve expensive software development efforts. This system was originally 12

designed for a small team of emergency planners and lacks the robust features that allow large and 13

dispersed teams to coordinate recovery efforts and to provide real-time recovery status to the command 14

center. At the time this system was developed, there were very few such crisis management tools 15

available in the marketplace. Today, these tools with the required capabilities are more widely available 16

and supported by well-established vendors. The existing system needs to be replaced with a robust 17

supported product which can serve the entire enterprise. 18

These systems will provide SCE with more robust supporting technology to plan and 19

manage the recovery of critical business applications and functions in the event of a disaster such as 20

major earthquake or fire.160 21

In addition, backup capabilities are now essential for SCE Operator Services that provide 22

critical communications during a crisis. We leverage SCE Operator Services as a crisis communications 23

center during crisis situations and major emergencies. Both human operators and the interactive voice 24

response system play an important role to ensure urgent communications are facilitated during crisis 25 160 See Workpapers entitled “Automated Emergency Notification Will Speed Disaster Recovery,” and “Business Continuity

Planning Software: Technology Overview.”

163

situations. There is no backup arrangement for this Service today, which could result in unavailability 1

during times of most critical need. Therefore, an alternate work center for this Service is required with 2

backup equipment to come on-line if the primary service location or equipment becomes disabled in the 3

event of a disaster. 4


Figure V-18 Business Continuity Planning Systems Expenditures

2002–2006 Recorded And 2007–2011 Forecast (Nominal $000)

$0.0

$200.0

$400.0

$600.0

$800.0

$1,000.0

$1,200.0

$1,400.0

2007 2008 2009 2010 2011

2007 2008 2009 2010 2011Amount $1,000.0 $500.0 $102.0 $1,154.0 $154.0

Forecast

SCE plans expenditures of $2.91 million on Business Continuity Planning, Crisis 6

Management and alternate Crisis Communication systems for the period 2007-2011.161 There were no 7

recorded capital costs for the period 2002-2006. The forecast is to replace obsolete and unsupported 8

systems for business continuity planning and crisis management, including the needed software, 9

hardware, and communication links, to establish an alternate Crisis Communications work center with 10

the needed system and equipment. These expenditures do not include IT Disaster Recovery costs.162 11

We plan to evaluate, select, and deploy the needed systems while adhering to SCE’s project 12

management methodology. 13

161 See Workpaper entitled “Business Continuity Planning Cost Analysis.” 162 See SCE-5, Volume 2, Disaster Recovery Hardware for additional details.

164

The development of these capabilities will be performed under a new program which will 1

adhere to SCE project management methodology and IT Core Processes. The scope of the program will 2

encompass all planning, analysis, design, construction, and deployment activities. Estimated 3

expenditures for the components of the program are: 4

• Business continuity planning system $1.2 million 5

• Crisis management system $1.3 million 6

• Crisis communications work center $0.41 million 7

The program will commence in the year 2007, with the assessment of detailed business 8

needs for both business continuity planning and crisis communications capabilities. Vendor products 9

will be evaluated, selected, and purchased in 2007 as part of the project engineering activities. During 10

2008, the program will progress to the detailed design and development phase, during which the vendor 11

products will be configured and integrated with other key SCE systems. Testing of the products will be 12

completed during 2008, and a pilot will be conducted in 2009 with selected business units. In 2010, 13

rollout of the complete enterprise will be conducted, business continuity planning will be deployed first 14

and crisis communications will follow, with all deployment to be completed by 2010. 15

Design of the alternate Crisis Communications work center is expected to begin in 2008, 16

with construction and activation to be completed by 2010. The strategy will be to allocate work and 17

resources across a primary site and alternate site, such that the alternate site is always active and capable 18

of assuming all communications load. The alternate site will be located within existing SCE facilities 19

and will be equipped with the hardware and communication lines sufficient to handle forecasted crisis 20

communications load. Additional capacity will be added to accommodate growth in 2011. 21

4. Alternative Considered 22

An alternative considered was to continue the use of existing tools and capabilities. 23

However, because of the obsolescence of the tools and their limited capabilities, it was concluded that 24

this alternative was untenable. In the post 9/11 and Katrina environment, regulators and customers 25

demand that companies make adequate preparations for business continuity after disastrous events. SCE 26

cannot meet this demand with its existing capabilities. 27

165

Many of SCE’s veteran employees are expected to retire in the next five years. If their 1

institutional knowledge and experience in emergency response and recovery activities were to be lost 2

when they retire, SCE’s ability to respond to emergency events would be severely compromised. Their 3

knowledge must be systematically captured in a standard and centralized repository that can be shared 4

across SCE. 5

Failure to replace the existing obsolete and unsupported systems will threaten SCE’s 6

ability to respond to disastrous events, to communicate timely outage information, and to resume normal 7

operations in power delivery and customer service quickly and effectively. 8

5. Conclusion 9

We need to strengthen SCE’s business continuity planning and disaster recovery 10

capabilities with the replacement of the obsolete supporting systems. More than ever before, we realize 11

that business continuity planning and crisis management need to be conducted at an enterprise level due 12

to the cascading effect that a failure of any one system may have to all the other connected systems. 13

Business continuity plans must be available and shared across SCE to enable the coordination that is 14

critical to recovery from a disastrous event. These systems will facilitate this coordination and solve 15

some of the shortcomings of the current protocols and systems. 16

C. Enterprise Technology Services 17

1. Background 18

Enterprise Technology Services provides for installation of technology that facilitates 19

integration and information flow between different systems and business functions, and replacement of 20

our wireless access gateway, which has become obsolete due to withdrawal of support from the vendor. 21

The wireless access gateway replacement is included here because it is an integral component of the 22

services needed to support the seamless flow of data over wired or wireless networks. 23

Within the next five years, portions of SCE’s aging application portfolio will be replaced 24

by commercial off-the-shelf software packages, which include the following significant applications: 25

• Enterprise Resource Planning (ERP) for business and backoffice applications. 26

166

• Market Redesign and Technology Upgrade (MRTU) for energy supply 1

applications. 2

• Energy Management System (EMS) for grid control and management 3

applications. 4

In addition, other applications such as Geographical Information System (GIS), Outage 5

Management System (OMS), and other applications systems will need to be interoperable to allow for 6

the seamless exchange of information among these applications. 7

As these aging applications are replaced, the information sharing capabilities that existed 8

previously will also need to be replaced. SCE’s core utility operations depend on the seamless sharing 9

of information among the different classes of applications to complete business transactions. Examples 10

include: 11

• Service orders dispatched to field crews based on information stored in back-12

office systems. 13

• Maintenance orders sent to field crews based on information from Geographical 14

Information System (GIS) and back-office systems. 15

• Exchange of market information with the California Independent System 16

Operator. 17

In this operating environment, the need for sharing information seamlessly among 18

application systems requires real-time or near real-time access, which requires up-to-date integration 19

infrastructure technologies. Enterprise Technology Services provides the architectural components and 20

infrastructure to enable this essential information access capability. 21

Since 2003, our wireless access gateway has been in operation delivering data, messages, 22

and alerts via a variety of wireless networks to our field crews, service personnel, and mobile 23

professionals. This gateway is no longer supported by the vendor and will need to be replaced with a 24

supported product. In addition, the current system does not meet our needs in terms of integration and 25

information flow between different systems and business functions. 26

167


a) Integrated Information Sharing Services 2

A traditional method of sharing information or data between applications is to 3

build point-to-point integration that delivers data in bulk at a predetermined time. This method will not 4

meet the growing need for timely information to support our utility operations because the data cannot 5

be accessed in real-time or near real-time. This method also copies data in many applications, which in 6

turn requires more storage space and the need to synchronize multiple copies over time, as updates are 7

made to the original source of the data. 8

With advances in technology, a more efficient and timely method to share 9

information has emerged.163 This allows applications to use a pre-built set of integration functions or 10

services164 to facilitate the sharing of information among different applications. The required 11

capabilities of these integration services include: 12

• Pre-built services for different classes of applications and different 13

integration patterns. 14

• Ability to integrate with Security Access Controls. 15

• Ability to deliver timely information where and when it is needed. 16

• Ability to deliver the correct information without creating copies. 17

This integrated information sharing infrastructure will have the following 18

features: 19

• A directory component to allow the addition or removal of inter-20

application information flow specifications; 21

• A rules-engine to govern the information flow among applications; 22

• A metrics gathering and reporting mechanism to provide performance 23

data on the information sharing service. 24

163 See Workpaper entitled “Introduction to Service-Oriented Architecture.” 164 See Workpaper entitled “Introduction to Service-Oriented Architecture.” Services are defined as re-usable computer

programs that can be used by different applications, without being part of any particular application.

168

Allowing information to flow among applications without creating and storing 1

multiple copies will better ensure the consistency and validity of the information. Security Access 2

Controls integration will ensure the applications are authorized to access the shared information. 3

Ensuring that the correct amount of timely information is delivered when needed will avoid flooding the 4

pipelines through which the information travels. In addition, the use of pre-built services will allow us 5

to reuse existing code rather than redeveloping165 the application in response to changed business 6

requirements or regulatory mandates. 7

The Software Asset Management (SAM) process has identified a prioritized set of 8

application systems needing remediation due to obsolescence.166 Enterprise Technology Services will 9

provide the standardized architectural components to be used by these application systems to facilitate 10

the seamless sharing of information with other applications, including SAP, which is the primary 11

application of the ERP system. Development of information sharing services will facilitate the 12

remediation of these applications, as well as the development of any other application integration 13

capabilities. 14

An alternative to using an integrated structure is to develop custom code (i.e., point-15

to-point solutions) for the sharing of information among the applications, each of which will need to 16

know the technical details ranging from the format of the information required to where it is stored. 17

However, this alternative is not cost effective from either a one-time or on-going cost perspective. The 18

SAM process has identified over 300 SCE applications which are outside the SAP footprint. Of these, 19

over 70 percent will be at least ten years of age within five years and may be candidates for remediation. 20

Given the number of applications and the complexity of the interfaces represented by these applications, 21

an architectural solution is needed to simplify and standardize the integration approach. Point-to-point 22

solutions will inherently entail needless re-invention and will introduce uniqueness to each individual 23

interface, resulting in higher costs for development and maintenance. Furthermore, point-to-point 24

165 See Workpaper entitled “Integration Architecture Capability Case Model.” Available online at

http://www.llnl.gov/tid/lof/documents/pdf./307008.pdf. 166 See SCE-5, Volume 3, Software Asset Management, for the applications to be covered.

169

solutions lack the flexibility and adaptability to accommodate changing business needs in a timely and 1

cost-effective manner. 2

The use of an integrated information sharing infrastructure will improve business 3

integration and enhance information integrity. This approach will necessitate the replacement of our 4

existing wireless access gateway with new and more robust technology to facilitate the seamless flow of 5

data over wired and wireless networks. 6

b) Obsolete Wireless Access Gateway Replacement 7

The replacement of the existing wireless access gateway will include hardware 8

and software components. As part of our data delivery services infrastructure, the updated wireless 9

access gateway must include the: 10

• Ability to connect back-office applications with any device. 11

• Ability to deliver data to fit different types and sizes of device displays. 12

• Ability to work with a variety of networks including different types of 13

wireless networks. 14

• Ability to compress data to allow transport over low bandwidth circuits. 15

• Ability to encrypt data to ensure secure flow of information. 16

• Guaranteed delivery of messages and alerts to ensure crew efficiency and 17

safety. 18

• Flexibility to accommodate projected volume growth for the next three to 19

five years. 20

In addition, fail-over capabilities are also required to minimize interruption of 21

service as a result of equipment failure or an outage. 22

The replacement of the wireless gateway is an essential component to enable 23

delivery of real-time information to mobile professionals and field workers wherever and whenever it is 24

needed. 25

170


Figure V-19 Enterprise Technology Services Expenditures 2002–2006 Recorded And 2007–2011 Forecast

(Nominal $000)

$0.0

$1,000.0

$2,000.0

$3,000.0

$4,000.0

$5,000.0

$6,000.0

2007 2008 2009 2010 2011

2007 2008 2009 2010 2011Amount $1,000.0 $2,400.0 $4,976.0 $5,257.0 $2,336.0

Forecast

For the period 2007-2011, we plan expenditures of $15.97 million to install an integrated 2

information sharing infrastructure and replace our obsolete and unsupported wireless access gateway.167 3

This infrastructure includes hardware and software for the different classes of applications that are being 4

replaced across SCE. 5

The development of these capabilities will be performed under a new program which will 6

adhere to SCE project management methodology and IT Core Processes. The scope of the program will 7

encompass all planning, analysis, design, construction, and deployment activities. Estimated 8

expenditures for the components of the program are: 9

• Information sharing infrastructure $12.3 million 10

• Wireless access gateway $ 3.7 million 11

The estimate for the information sharing infrastructure is comprised of $3 million in 12

hardware costs, $4.3 million in software costs, and $5 million in labor and contractor costs. The 13

167 See Workpaper entitled “Enterprise Technology Services Cost Analysis.”

171

estimate for the wireless access gateway is based upon the assumption that the replacement hardware 1

will cost $1.1 million, software will cost $1.3 million, labor and contract will cost $1.3 million. 2

The program will commence in the year 2007, with the assessment of detailed business 3

needs for both information sharing and wireless access capabilities. Vendor products will be evaluated 4

and selected as part of the project engineering activities. Final product purchase decisions will entail 5

proof-of-concept demonstration of the products with key SCE applications. During 2008-2009, the 6

program will progress to the detailed design and development phase, during which the vendor products 7

will be configured and integrated with key SCE systems. Testing and implementation of integration 8

capabilities will be planned over several releases from 2009–2011, in order to address the highest 9

priority application classes as quickly as possible. Deployment of the information sharing infrastructure 10

is planned for completion by 2011. 11

Design of the new wireless access gateway will begin in 2008, with construction and 12

activation to be completed by 2010. 13

4. ERP Benefits 14

The following Figure V-20 reflects the expenditures which would have been incurred in 15

this area in the absence of ERP Project. 16

172

Figure V-20 Enterprise Decision Support Infrastructure (EDSI)

ERP Benefits (Nominal $000)

$0.0

$1,000.0

$2,000.0

$3,000.0

$4,000.0

$5,000.0

$6,000.0

$7,000.0

$8,000.0

2006 2007 2008 2009 2010 2011

Recorded2006 2007 2008 2009 2010 2011

EDSI $6,700.0 $6,000.0 $2,700.0 $800.0 $0.0 $0.0

Forecast

The expenditures for 2006 through 2009, totaling $16.2 million, were planned for the 1

implementation of the Enterprise Decision Support Infrastructure (EDSI) project. The intent of EDSI 2

was to provide a standardized infrastructure to support the replacement of Decision Support System 3

(DSS) that will provide the ability to access and analyze large volumes of data to support business 4

operations. The ERP system contains the infrastructure and functionality that EDSI was designed to 5

provide. Therefore, the EDSI project was not implemented. 6

5. Conclusion 7

As SCE replaces many aging applications over the next five years, the information 8

sharing capabilities that exist among them will also need to be replaced. Using an integrated 9

information sharing infrastructure will allow applications to share the right amount of information with 10

minimal configuration at the lowest cost possible, instead of developing and maintaining custom code as 11

in point-to-point solutions. This solution will improve both solution delivery time and costs. Our aging 12

173

and unsupported wireless access gateway must also be replaced with a robust, vendor-supported 1

product. This wireless gateway is essential to providing a reliable source of information to SCE field 2

crews and mobile professionals who depend on that information to provide high-quality customer 3

service. 4

174

VI. 1

REGULATORY MANDATES AND INITIATIVES 2

A. NERC CIP Compliance 3

1. Background 4

The vulnerability of electric utility operations to accidental or malicious disruption has 5

been the subject of significant concern for several years. These concerns were intensified, first, after the 6

widespread blackout in the western United States in 1997; and then, after the tragic events of September 7

11, 2001; and the unprecedented blackout in 2003 in the Northeast and portions of the Midwest. These 8

events spurred the Federal Energy Regulatory Commission (FERC) to develop actionable mandates for 9

enhancing security over bulk electricity operations.168 These mandates apply to all users, owners, and 10

operators of the bulk power system and primarily involve generation and transmission infrastructure. 11

In addition to this governmental mandate for increased security, the rapid evolution of 12

information technologies in the intervening years and the widespread adoption of the internet as the de 13

facto medium of choice for data communications, including Voice over Internet Protocol 14

communications, have added another layer of urgency to this need for mitigating vulnerabilities inherent 15

in the design, construction and operations of the country’s bulk electric system. 16

In the wake of 9/11 and the 2003 blackout, the Critical Infrastructure Protection (CIP) 17

Standards mandated were issued by the North American Electric Reliability Corporation (NERC)169 to 18

protect the electric system.170 NERC has specified two dates to demonstrate progressive stages of 19

168 See Workpaper entitled “United States of America Federal Energy Regulatory Commission 18 CFR Part 40, Docket No.

RM06-16-000” relating to Mandatory Reliability Standards for the Bulk Power System.” (Excerpt referring to approval of reliability standards developed by the North American Electric Reliability Council, certification of the Electric Reliability Organization and recommendations arising from the investigation of the 2003 northeast blackout.) Workpaper also includes instructions on obtaining full document from www.ferc.gov.

169 The North American Electric Reliability Corporation is a wholly owned subsidiary of the North American Electric Reliability Council, and which has been certified as the Electric Reliability Organization. NERC’s mission is to improve the security and reliability of the bulk electric system in North America.

170 See Workpaper entitled “NERC adopts permanent Cyber Security Standards.”

175

compliance with the new standards: the first compliance date is June 30, 2009,171 and the second is June 1

30, 2010.172 2

The “cyber security” requirements contained within these Critical Infrastructure 3

Protection mandates specifically require the utilities to ensure secure operations of the information and 4

communication technology components – hardware, software and networks – that support the operation 5

of the nation’s bulk electricity system.173 Unlike previous NERC-driven reliability improvement efforts, 6

these mandates are not merely suggested actions, but instead, include penalties of up to $1,000,000 per 7

incident per day for non compliance.174 8

a) Purpose 9

The Purpose of this request for funding is to develop and implement systems and 10

processes necessary to ensure that SCE is able to comply with NERC’s mandated set of Cyber Security 11

Critical Infrastructure Protection standards by the required deadlines.175 As this is a governmental-12

mandated requirement that institutes changes to our current security protocols, SCE must develop the 13

systems and procedures that will be necessary for compliance within the regulated timeframes. 14

b) Scope 15

The scope of the NERC CIP requirements is broad. Specific to Critical Cyber 16

Assets, these requirements touch a wide range of bulk electric utility operations and also require detailed 17

review and assessment down to the individual application and device level within an electronic security 18

171 Compliant, as defined by NERC, is the entity meets the full intent of the requirements and is beginning to maintain

required “data,” “documents,” “documentation,” “logs,” and “records.” Refer to the NERC Implementation Plan located at ftp://www.nerc.com/pub/sys/all_updl/standards/sar/Revised_Implementation_Plan_CIP-002-009.pdf.

172 Auditably Compliant, as defined by NERC, is that the entity meets the full intent of the requirement and can demonstrate compliance to an auditor, including 12-calendar-months of auditable “data, documents, documentation, logs and records.”

173 SCE’s computer network is segregated into 2 major parts: The Administrative Network and the Control Systems Network. This testimony applies to the Control Systems Network.

174 See Workpapers entitled “FERC’s Implementation of EPAct 2005’s Reliability Provisions,” and “NERC Appendix 4B: Sanction guidelines, effective January 18, 2007.”

175 See Workpaper entitled “CIP Definitions”. Additional detail on NERC CIP Standard Requirements may be obtained from http://www.nerc.com/~filez/standards/Reliability_Standards.html.

176

perimeter. An electronic security perimeter refers to the logical border surrounding a network to which 1

Critical Cyber Assets are connected and for which access is controlled. 2

Figure VI-21 NERC Cyber Vulnerability Assessment Scope

The scope of the NERC CIP regulations include: 3

• Equipment and or facilities such as SCE Control Centers, Transmission 4

Substations, Generation Facilities (excluding Nuclear Facilities176), 5

System Restoration Applications, Load Shedding Applications, and 6

Special Protection Systems. 7

• All SCE personnel that support, maintain, or manage the in scope assets, 8

who must be trained and adhere to the controls as mandated by NERC. 9

• Other Critical Assets and Critical Cyber Assets including electronic, 10

physical, systems, reporting, and recovery plans, documentation, control 11

and management processes. 12 176 The NERC mandates specifically exclude facilities regulated by the US Nuclear Regulatory Commission. See

Workpaper entitled “CIP definitions” or at http://www.nerc.com/~filez/standards/Reliability_Standards.html.

177

To avoid duplication or overlap, this request covers only requirements over and 1

above SCE’s regular Information Security needs.177 2

In terms of timing, compliance with all CIP Standards must be in place by June 3

2009. By June 2010, SCE must be able to produce 12-months’ of auditable data. 4

SCE has completed a high-level evaluation178 of the existing processes and 5

procedures to help estimate project tasks, resource requirements and project timing. The results of this 6

evaluation are detailed in subsequent sections. 7

c) Request Summary 8

This request is our best estimate of how SCE’s cyber assets need to be enhanced, 9

supplemented or replaced to meet compliance with the NERC mandated requirements that are more 10

stringent than SCE’s existing industry-standard protocols. 11

The program implementation plan has been developed in accordance with 12

established technical and program management processes currently in use at SCE. SCE will leverage 13

other initiatives that are underway or in operation as they are identified during program planning and 14

implementation. The program approach is designed to ensure that SCE is able to meet the proposed 15

compliance dates. The proposed analysis will focus on identifying those SCE cyber assets or related 16

processes that need modification or redesign to bring them into compliance. As referred to earlier, the 17

analysis will also identify gaps in SCE’s current cyber security portfolio that need to be remediated with 18

new capabilities or assets per the CIP mandates. 19


In the following sections, we outline the CIP mandates and requirements, followed by an 21

overview of SCE’s program plan for achieving compliance. Together, these form the basis of the effort 22

estimates developed for this program. 23

a) Detailed NERC Mandated Business Requirements 24

177 See SCE-5, Volume 3, Information Security and SCE-3, Volume 3, TDBU Capital. 178 See Workpaper entitled “SCE – BES Cyber Security - Preliminary Requirements”. The evaluation referenced here

encompasses both this preliminary assessment as well as follow on assessments of individual facilities or processes.

178

Each of the NERC CIP standards not only describes specific activities or 1

assessments to be completed for compliance, but also identifies a set of measures or metrics by which 2

compliance of each standard may be measured. Figure VI-22 below outlines the various areas covered 3

by each CIP mandate. More detailed descriptions of the CIP mandate requirements are provided in the 4

workpapers.179 5

179 CIP definitions provided at http://www.nerc.com/~filez/standards/Reliability_Standards.html.

179

Figure VI-22 NERC CIP Cyber Security Standards Eight Standards / 41 Requirements

CIP 002 CIP 003 CIP 004 CIP 005 CIP 006 CIP 007 CIP 008 CIP 009

CRITICAL CYBER ASSETS

SECURITY MANAGEMENT

CONTROLSPERSONNEL

AND TRAININGELECTRONIC

SECURITYPHYSICAL SECURITY

SYSTEMS SECURITY

MANAGEMENT

INCIDENT REPORTING

AND RESPONSE PLANNING

RECOVERY PLANS FOR

CCA

CRITICAL ASSETS CYBER SECURITY POLICY

AWARENESS ELECTRONIC SECURITY PERIMETER

PLAN TEST PROCEDURES CYBER SECURITY INCIDENT RESPONSE PLAN

RECOVERY PLANS

CRITICAL CYBER ASSETS

LEADERSHIP TRAINING ELECTRONIC ACCESS CONTROLS

PHYSICAL ACCESS CONTROLS

PORTS AND SERVICES

DOCUMENTATION EXERCISES

ANNUAL REVIEW EXCEPTIONS PERSONNEL RISK ASSESSMENT

MONITORING ELECTRONIC ACCESS

MONITORING PHYSICAL ACCESS

SECURITY PATCH MANAGEMENT

CHANGE CONTROL

ANNUAL APPROVAL

INFORMATION PROTECTION

ACCESS CYBER VULNERABILITY ASSESSMENT

LOGGING PHYSICAL ACCESS

MALICIOUS SOFTWARE PREVENTION

BACKUP AND RESTORE

ACCESS CONTROL DOCUMENTATION ACCESS LOG RETENTION

ACCOUNT MANAGEMENT

TESTING BACKUP MEDIA

CHANGE CONTROL MAINTENANCE AND TESTING

SECURITY STATUS MONITORING

DISPOSAL OR REDEPLOYMENT

CYBER VULNERABILITY ASSESSMENT

DOCUMENTATION

180

b) Program Approach 1

The program will utilize cross functional teams from SCE’s Transmission & 2

Distribution, Operations Support, Information Technology, Generation, and Power Procurement 3

Business Units to ensure the appropriate stakeholders, staffing resources, and management is included in 4

the compliance activities.180 All SCE personnel that support, maintain, or manage the in-scope assets 5

must be trained and adhere to the controls as mandated by NERC. 6

In addition, this program focuses on developing and implementing new or 7

enhanced business processes and systems as well as organizational roles and responsibilities to manage 8

and sustain compliance within SCE.181 An illustration of the implementation approach is presented in 9

Figure VI-23. 10

180 See Workpaper entitled “SCE NERC CIP Program Organization Structure”. The breadth and reach of the NERC CIP

mandates require significant program and project management resources as well as utility operating department subject matter experts and management personnel.

181 See Workpaper entitled “SCE NERC CIP Compliance – Roles and Responsibilities.” Significant new roles and tasks are identified during the program implementation stages through 2010, as well as ongoing roles during that period and going forward. These roles span all affected SCE departments – e.g., IT, TDBU and PPD. See also, Workpaper entitled “High level CIP Inter and Intra Relationships.” Program management as well as the roles and responsibilities are made more difficult by the interconnected nature of the CIP mandate performance requirements.

181

Figure VI-23 NERC Implementation Approach

Identify BES

Critical AssetsNon CA

Critical Cyber Assets (CCA)Non CCA

Risk Based Assessment

Gather existing Data

Gap Analysis Recommendations

Policies,ProcessProcedures

RemediationPlans

DeficienciesNon-Compliants

Physical SecurityElectronic Sys PerimeterSystems – Access CntlsIncident ReportingDisasters and RecoveryProcess & ControlsPersonnel RisksTraining

Projects

AuditsFixesChanges

CompletedFixes

Pass Results

Findings

Program Management Planning – Communication - Change Management - Financial Management - Tracking & Reporting - Vendor management - Implementation Oversight - Regulatory Alignment

NERC Implementation Approach

Known Gaps & Recommendations

Substations Access CntlPhysical Access CntlBackup & Recovery Crisis ManagementElectronic Perimeter Monitoring

Q1’07 Q2’07 Q3’07 2008-2010

*BES – Bulk Electricity System 1

3. Recorded and Forecast Expenditures 2

a) Summary of Capital Expenditures 3

With this new regulatory mandate only recently being enacted, we have not 4

recorded costs in 2002-2006 towards this project. Figure VI-24 presents a summary of the capital 5

expenditures being proposed for this project. 6

182

Figure VI-24 NERC CIP Budget Item Expenditures


$0.0

$1,000.0

$2,000.0

$3,000.0

$4,000.0

$5,000.0

$6,000.0

2007 2008 2009 2010 2011

2007 2008 2009 2010 2011Amount $3,123.0 $5,644.0 $2,880.0 $2,880.0 $1,200.0

Forecast

SCE currently employs sound Cyber Security182 practices at facilities and 1

equipment served by its control system network183 consistent with prevailing industry practice. 2

However, an initial high-level evaluation of the existing processes and procedures demonstrated that 3

even with SCE’s planned information security investments, SCE needs to address numerous gaps to 4

comply with NERC CIP Standards, which impose higher and more stringent requirements. Figure VI-5

25 below illustrates this schematically. For example, the NERC mandates require development, 6

monitoring and oversight of a separate and specific list of critical cyber assets that impact the bulk 7

electric system – current information security related expenditures and activities do not include this; the 8

mandates similarly requires an annual vulnerability assessment to be conducted (and the results 9

documented in an auditable database) of the electronic security perimeter(s) surrounding the critical 10

182 As used here Cyber Security refers to the full range of activities and systems addressed by the CIP mandates 002 through

009. 183 SCE’s computer network is segregated into two major parts: The Administrative Network and the Control Systems

Network. This testimony applies to the Control Systems Network.

183

cyber assets – an activity which is not a part of the routine information security activities; the mandates’ 1

requirements to log and document facility and system access as well as of incident reports similarly 2

specify data capture and retention time needs that are significantly more than current practice. The 3

NERC mandates also impose significantly more complex documentation requirements that can only be 4

met reliably through a greater degree of automation and technical integration.184 5

Figure VI-25 NERC – CIP Implementation Hierarchy

NERC – CIPHeightened Security

For Critical Cyber Assets

Enhanced Perimeter Defense

Internal Defense

DataProtection

Current Information Security Capabilities

Our initial assessment of capability gaps has revealed a number of areas in which 6

SCE will need to make modifications to our existing Cyber Security protocols in order to comply with 7

the mandates. Briefly, those areas needing modification are as follows: 8

• CIP – 002: Cyber Assets – Need to create a sustainable, risk-based 9

process to identify critical cyber assets associated with critical assets. This 10

process needs to be repeatable, well documented, and auditable. The CIP 11

mandates are comprehensive in scope; i.e., encompass all assets relating to 12

the reliable and safe operation of the Bulk Electric System, making this a 13

significant effort. The initial identification, documentation and condition 14

184 See Workpaper entitled “NERC CIP 002-009 Cyber Security Standard Action Item List.” The spreadsheet provides a

summary view of some of the major new document creation, maintenance, management and archival needs dictated by the NERC mandates.

184

archival of what the critical cyber assets are, as well as establishing the 1

process and tools necessary to accurately capture and report on this 2

information will form the basis upon which future analyses and 3

assessments will be made. 4

• CIP – 003: Security Management and Controls – Need to enhance 5

current SCE security management controls and associated documentation 6

to address the specific requirements of CIP for information classification, 7

policy formulation, exception handling, and change control for all the 8

assets in scope. Such activities will include developing a system security 9

plan that documents operational procedures, network topology diagrams, 10

floor plans of relevant computing centers and equipment layouts, data 11

classification schemes and implementing a change control and 12

configuration management process for adding, modifying, replacing or 13

removing Critical Cyber Asset hardware or Software. A key 14

implementation task will be the design, selection and implementation of a 15

data repository to securely collect, retain and manage data regarding all 16

critical cyber assets. 17

• CIP – 005: Electronic Security Perimeter - Need to further strengthen 18

access controls to all access points within the Electronic Security 19

Perimeter(s), which is a logical border surrounding a network to which 20

Critical Cyber Assets are connected and for which access is controlled. A 21

detailed analysis of the critical cyber assets must be conducted to 22

determine the location of the electronic security perimeters. Access 23

control and monitoring of the electronic security perimeter needs to be 24

defined and implemented. In addition, there is a need to conduct annual 25

vulnerability assessments specifically focused on the Electronic Security 26

Perimeter(s). Enhancement activities encompass tools and processes 27

185

required to conduct and document vulnerability assessments, monitoring 1

electronic access, access controls, intrusion prevention and related tasks. 2

• CIP – 006: Physical Security – Enhance and strengthen the technical and 3

procedural controls and auditability of physical security and physical 4

access controls of all facilities in scope. Much or all of the data related to 5

access logs needs to be retained for extended periods of time in readily 6

accessible and “secure” archives, above and beyond our current practices. 7

In addition, a maintenance and testing program and results documentation 8

system to ensure that all components of the physical security system work 9

as intended needs to be developed and implemented. Mitigating these 10

various gaps requires significantly increasing the use of automated access 11

control devices, including entry and exit data logging systems. Further, 12

additional security systems such as video surveillance systems with image 13

capture and archival capability, will have to be evaluated and implemented 14

as necessary to meet requirements for traceability of unauthorized entry 15

attempts. 16

• CIP – 007: Systems Security Management – Need to define, document 17

and implement methods, processes and procedures for securing systems 18

determined to be Critical Cyber Assets as well as non-critical cyber assets 19

within Electronic Security Perimeters. This includes establishment of 20

systems and processes for device management, security patch 21

management, malicious software prevention, account management and 22

status monitoring. 23

• CIP – 009: Recovery Plans for Critical Assets – Need to implement and 24

document recovery plan(s) for Critical Cyber Assets that follow 25

established business continuity and disaster recovery techniques and 26

practices. These include processes and procedures for the backup and 27

186

storage of information required to successfully restore critical assets. The 1

tasks will also include plans and processes to test recovery plans as well as 2

the backup media and equipment annually to ensure their proper working 3

condition. Finally, the CIP also requires proper change control and 4

configuration management processes to be in place related to the disaster 5

recovery elements. 6

SCE has been successful overall in keeping its IT “cyber assets” secure185 and in 7

its prudent disaster recovery and business continuity practices.186 However, compliance with the NERC 8

CIP mandates requires us to significantly elevate the need for greater organizational capability in this 9

area. 10

The project, its tasks and the necessary resource commitments have been designed 11

to meet the NERC imposed schedule and are not otherwise driven by other internal SCE priorities. They 12

have also been developed to minimize duplication, and to leverage existing capabilities and/or other 13

related efforts currently underway. A significant portion of the project activities focus on: 14

• Identification of Critical Assets, Critical Cyber Assets and the 15

establishment of the Electronic Security Perimeter. 16

• A comprehensive gap analysis to identify current capability status and the 17

requirements to bring this capability into full compliance. 18

• Remediation efforts or implementation of specific new capabilities to 19

bring SCE practices and assets into compliance. 20

• Institutionalizing the overall program capabilities and practices to enable 21

compliance on an ongoing and routine operational basis. 22

185 See SCE-5, Volume 3, Information Security for additional details. 186 See SCE-5, Volume 2, Disaster Recovery Hardware and SCE-5, Volume 3, Business Continuity Planning Systems for

additional details.

187

These activities will result in the development and implementation of various 1

systems, tools, and devices, as well as the related operating processes and procedures necessary to 2

enable SCE to comply with the NERC mandates. 3

In support of the above approach, a detailed implementation strategy and 4

implementation plan has been developed to ensure the gaps are resolved in time to meet the June 2009 5

and June 2010 NERC compliance dates.187 The anticipated timing for completion of the first 18-6

months’ major project milestones by quarter is shown in Figure VI-26 below. Remediation planning 7

and testing activities will be conducted in mid-2008 to ensure that all aspects of the compliance program 8

are in place by June 2009. SCE will then be in position, by the June 2010 compliance date, to collect the 9

necessary data and report performance on all of the CIP Standards using the NERC proposed metrics 10

and supported by 12 months’ of auditable data. 11

187 See Workpaper entitled “SCE - NERC CIP Program Major Deliverables” for a detailed view of the proposed

deliverables by calendar quarter.

188

Figure VI-26 Major Milestones For Compliance Project

Table VI-36 below shows planned expenditures by specific CIP mandate. Where 1

possible, these estimates were developed based on SCE experience with similar projects in the past. In 2

cases where SCE did not have such cost data or involved the purchase of specific hardware or 3

commercial off-the-shelf software components, the costs were developed based on vendor estimates.188 4

188 Where appropriate, vendor estimates were obtained from multiple vendors and or with assistance from SCE IT Vendor

management negotiated amounts based on pre existing agreements (contractor or non labor services, for example).

189

Table VI-36 Capital Expenditures By CIP Mandate

(Nominal $000s) NERC CIP # Description 2007 2008 2009 2010 2011 CIP Expenditure TotalsCIP 002 Asset Identification $413.0 $413.0CIP 003 Security Management $406.0 $406.0CIP 005 Electronic Security Perimeters $500.0 $1,000.0 $282.0 $1,782.0CIP 006 Physical Security $627.0 $3,000.0 $1,100.0 $600.0 $750.0 $6,077.0CIP 007 Systems Security Management $1,000.0 $1,234.0 $1,100.0 $1,000.0 $200.0 $4,534.0CIP 009 Recovery Planning $177.0 $410.0 $398.0 $1,280.0 $250.0 $2,515.0Annual Expenditure Totals $3,123.0 $5,644.0 $2,880.0 $2,880.0 $1,200.0 $15,727.0

These estimates are based on several important assumptions, including: 1

• There will be no significant changes to the NERC requirements beyond 2

those in effect at the submittal of the NOI that would materially impact the 3

program. 4

• There will be no additional licensing cost for Document Management or 5

Configuration Management tools, based on the assumption that the project 6

will leverage the use of existing SCE tools and methodologies. 7

• Physical Security estimates do not include real estate and related facility 8

costs. 9

4. Conclusion 10

The Critical Infrastructure Protection (CIP) Standards recently mandated by NERC 11

specify two dates to demonstrate progressive stages of compliance. By June 2009, all people, process 12

and technology mechanisms to ensure compliance must be developed and implemented. By June 2010, 13

SCE must be able to provide 12 months’ of auditable data. 14

SCE’s security practices, encompassing many of the areas described by the CIP 15

mandates, have historically followed prudent industry practices. As noted above, we are seeking to 16

enhance our overall information security defenses to protect our systems against growing security 17

threats. The NERC mandates, however, for certain areas, require even higher, more rigorous standards 18

of performance, suitable for protecting critical infrastructure cyber assets in a more adversarial and 19

malevolent environment. 20

190

This submission requests approval for $15.7 million in new, incremental capital funding 1

during the period 2007 – 2011, to allow SCE to develop and implement new systems, tools, physical 2

security hardware and related business processes, policies and training programs to improve the 3

management of SCE’s Critical Cyber Assets and ensure compliance with the standards mandated by 4

NERC. 5

The NERC CIP mandates are new and still evolving – few utilities, especially of the size 6

and scale of SCE, have completed a full implementation and audit cycle. We believe our estimates of 7

required work and costs are accurate and reasonable, are based on the best available information, follow 8

SCE’s established project costing and estimation processes, and minimize duplication by leveraging 9

existing and planned capabilities. 10

B. Power Procurement Business Unit (PPBU) 11

1. MRTU Release 1 Project (PPBU) 12

a) Introduction 13

The CAISO’s MRTU initiative will impact many PPBU systems, as well as 14

require significant adjustments to business processes and related business operational tasks. The 15

principal PPBU departments that will be affected in daily operations are the Energy Supply and 16

Management (ES&M) and Power Procurement Finance (PPF) departments. The Market Strategy and 17

Resource Planning (MS&RP) department will also be affected by MRTU with respect to the scope of its 18

market analyses.189 19

As discussed in more detail below, there are multiple PPBU business functions 20

and sub-functional areas that will be affected by the market design changes and new protocols resulting 21

from MRTU. The list of functions includes: 22

Planning: 23

• Demand Forecasting 24

189 Due to the current uncertainties surrounding the scope of MRTU and the anticipated actions to be taken by the CAISO

and FERC in 2007 and 2008 to clarify and identify MRTU requirements, SCE’s Application for this General Rate Case includes a request to update its forecasts relating to MRTU during the update phase of this proceeding.

191

• Price Forecasting 1

• Resource Portfolio Optimization – Short-Term and Long-Term Plans 2

• Transmission Management – Congestion Revenue Rights (CRRs) 3

• Market Monitoring and Analysis 4

Trading: 5

• Day-Ahead Power Trading & Bid Optimization 6

• Real-Time Power Trading 7

• Gas Procurement 8

Operations: 9

• Pre-Scheduling 10

• Real-Time Energy Management 11

• Outage Management 12

Finance: 13

• CAISO Settlements and Allocations 14

• Counterparty Settlements 15

• Accounting – Receivables and Payables 16

• Reporting 17

The market design changes for MRTU are so significant that they necessitate a 18

wholesale change in PPBU’s key applications and tools required to support these business functions. 19

The current installed applications were designed, built, and maintained to support the current CAISO 20

market rules and protocols. With one exception noted below, these applications and tools cannot be 21

modified to sufficiently accommodate the new comprehensive market design described below. Thus, 22

major projects are required to secure and install new applications that conform to MRTU market 23

requirements. In addition, changes in business processes, development of data management systems and 24

the associated training for PPBU personnel will be required to enable SCE “readiness” to participate in 25

post-implementation MRTU operations. 26

192

b) Background 1

(1) MRTU Overview 2

In February 2006, the CAISO submitted tariffs to FERC to implement the 3

redesign and upgrade of the wholesale energy market across CAISO’s Controlled Grid, known as 4

MRTU.190 The programs under the MRTU initiative are designed to implement the following: 5

• Market improvements to assure grid reliability and more efficient and 6

cost-effective use of resources, and 7

• Technology upgrades to strengthen the entire CAISO computer 8

backbone. 9

The redesigned California energy market under MRTU will include the 10

following new features, among others, which are not part of the current CAISO real-time only market: 11

• An Integrated Forward Market (IFM) for energy, Ancillary Services 12

and Congestion Management that operates on a day-ahead basis. 13

Currently the CAISO only operates a real-time market. The provision 14

of this new forward market enhances the ability of market participants 15

to meet their energy needs, 16

• Congestion management using CAISO’s Full Network Model (FNM) 17

that represents all network transmission constraints. FNM removes 18

existing technical and software obstacles to the accurate depiction of 19

available capacity and transmission constraints on the CAISO 20

Controlled Grid across all market time frames, 21

• Congestion Revenue Rights (CRRs) to allow market participants to 22

manage their costs of transmission congestion. CRR holders are 23

entitled to receive revenue based on congestion charges along the 24

CRR’s specific source-to-sink transmission path. CRRs will be 25 190 California Independent System Operator Corporation Electric Tariff Filing to Reflect Market Redesign and Technology

Upgrade, FERC Docket No. ER06-615-000.

193

allocated to Load-Serving Entities (LSEs) and will be tradable 1

products, allowing market participants to procure or dispose of CRRs 2

to optimize their cost of congestion based on their load requirements 3

on the CAISO Controlled Grid, 4

• Elimination of CAISO’s current market separation rule and balanced 5

schedule requirement. That is, market participants will no longer be 6

required to submit schedules to bring power to the grid that are 7

balanced by schedules to take load off the grid. Under MRTU, market 8

participants will submit supply and demand bids to specific locations 9

of the grid, and the new market will clear all economic demand and 10

supply bids while treating self-schedules as price takers, 11

• Local energy prices by price nodes (approximately 3,000 nodes in 12

total) to eliminate the distinction between inter and intra-zonal 13

congestion, also known as Locational Marginal Pricing (LMP). This is 14

different than the current zonal market in California made up of only 15

three congestion zones. Indeed, most of SCE’s service territory is in a 16

single congestion zone (SP15) with one associated price point. In 17

MRTU, LMP means that marginal energy price will be determined at 18

each node in the CAISO Controlled Grid, including the marginal cost 19

of congestion and transmission losses, based on each market 20

participant’s bids for supply and demand, and 21

• New market rules and penalties to prevent gaming and illegal 22

manipulation of the market. 23

In addition to wholly new market features, MRTU will include 24

modifications to certain existing market rules. Examples of changes to existing market rules under 25

MRTU include: 26

• Elimination of the current system bid conduct and market impact test, 27

194

• New bid caps for energy and Ancillary Services, and 1

• Local market power mitigation through the institution of a cost-based 2

Default Energy Bid for generation that is dispatched out-of-merit to 3

relieve congestion. 4

(2) The MRTU Release 1 Project 5

SCE has received permission from the CPUC (via Advice Letter 2091-E) 6

to track expenditures for projects such as the MRTU Release 1 capitalized software project in a separate 7

memorandum account and will seek to recover these costs in a separate ERRA Reasonableness of 8

Operations proceeding outside of the GRC, during which a detailed presentation of the following project 9

costs will be made. For completeness of the discussion of MRTU software projects, PPBU is providing 10

a description of the project and its high-level project costs and schedule in this testimony for information 11

only. 12

The major components of MRTU Release 1 include the following: 13

• Management of the grid using FNM, 14

• Implementation of over 3000 pricing nodes for LMP, 15

• Creation of a Day-Ahead market, 16

• Demand settlement based on Load Aggregation Points (LAPs), 17

• Provision of CRRs, 18

• Institution of the IFM, 19

• Institution of a RUC process, 20

• Institution of bid caps and the Default Energy Bid for local market 21

power mitigation, and 22

• Elimination of balanced schedules. 23

The procurement and development of new applications required for 24

MRTU Release 1 is comprised of three primary PPBU initiatives: 25

• Operations and Settlements 26

• Planning 27

195

• Data Management 1

(3) Operations and Settlements 2

This SCE project initiative involves the procurement, configuration and 3

installation of a major system that is comprised of a suite of products. Power Cost Inc. (PCI) is 4

providing the GenTrader/GenManager/GenPortal/GenBase system suite based on SCE-specified 5

requirements and CAISO-specified MRTU market design rules and protocols. MRTU introduces new 6

market rules, algorithms, and market protocols, as such, there were no existing “off-the-shelf” 7

applications that were available for procurement by SCE. Thus, the procurement process for the PCI 8

system necessitated a hybrid approach, i.e., purchase of: (a) existing products not explicitly affected by 9

MRTU, (b) core products that can be configured to meet SCE’s business needs and (c) newly designed 10

and developed products that must conform to the new CAISO market design and protocols. Thus, the 11

MRTU-specific customizations to be designed and built by PCI are dependent upon the issuance of the 12

MRTU Business Process Manuals (BPMs). The CAISO has repeatedly delayed the release of the BPMs 13

and introduced numerous changes in the BPMs over time. Thus, design and development efforts by PCI 14

have been affected by these delays and changes, introducing potential risk for cost increases in the 15

overall project. 16

The suite of products to be delivered by PCI will support multiple 17

business functions for PPBU operations under MRTU. The business functions and associated products 18

that support them are described below. 19

Day-Ahead Trading and Bid Optimization 20

Two products support the needs for Day-Ahead Trading and Bid 21

Optimization: (a) PCI GenTrader and (b) PCI GenManager. PCI GenTrader is used to run “studies” 22

and generate a set of information related to bid curve data for available dispatchable resources, physical 23

and financial “position” for each hour, and additional data that is used to optimize SCE’s bids into the 24

CAISO’s IFM and RUC. This data set is generated based on a number of resource-specific parameters, 25

existing forward power supply, available power options and forecasted variables introduced into each 26

GenTrader study. 27

196

PCI GenManager supports several key functions: 1

• Evaluation of the data sets produced by the GenTrader studies, 2

• The capture and management of day-ahead power trades and 3

exercised options, 4

• The continuous calculation of SCE’s forecasted physical and 5

financial position for each hour of the next operating day, and 6

• The ability to define the data set to be used in creating the bids 7

required to be sent to the CAISO. 8

Real-Time Power Trading 9

Although the operational needs for Real-Time Trading vary 10

slightly from those of Day-Ahead Trading, the same two products support the needs for Real-Time 11

Power Trading: (a) PCI GenTrader and (b) PCI GenManager. PCI GenTrader will be used to run a 12

limited set of “studies” to produce a select set of information related to resources that have not been 13

dispatched at their full capacity and may have available energy that can be bid into the RTM. Physical 14

and financial “position” for each hour and other decision-support data will be delivered to enable 15

effective utilization of available SCE resources. 16

PCI GenManager supports several key Real-Time functions: 17

• The evaluation of the data sets produced by the GenTrader 18

studies, 19

• The capture and management of Real-Time power trades for 20

intra-day delivery, 21

• The continuous calculation of SCE’s forecasted physical and 22

financial position for each hour of the operating day, and 23

• The ability to define the data set to be used in creating Real-24

Time bids to be sent to the CAISO. 25

Gas Procurement 26

197

The Gas Procurement function is indirectly supported by the use of 1

the PCI GenTrader product. The business activity performed is the purchase of the estimated volume of 2

natural gas required to fuel the generating plants, based on the projected dispatch instructions from the 3

CAISO. 4

In today’s CAISO market design, SCE is able to define the 5

dispatch levels for each of its generating resources; thus, the volume of natural gas can be determined 6

and procurement can be executed in a day-ahead natural gas market. However, the MRTU market 7

design only permits SCE to “bid” these generating resources into the market and the CAISO makes the 8

final determination as to the dispatch level for each unit. 9

These CAISO IFM awards for dispatched amounts will not occur 10

until after the day-ahead natural gas market closes; therefore, the calculated amount of gas required will 11

not be known in time for day-ahead gas procurement. Thus, the use of the PCI GenTrader product is 12

critical in that it provides a forecasted volume of required natural gas that can be purchased in the day-13

ahead market rather than the more expensive post day-ahead market. 14

Operations: Pre-Scheduling 15

The Day-Ahead Operations group within ES&M will utilize the 16

PCI GenManager product as its primary tool to perform post-MRTU implementation business functions. 17

The principal modules within GenManager that will be used heavily are Bid Formulator, Bid Validation 18

and Bid Submittal. The available features within these modules will enable the Day-Ahead Operations 19

group to complete their core functions of creating, validating and submitting bids to the CAISO in the 20

IFM. In addition, GenManager features will enable the Day-Ahead Operations group to review and 21

ensure the validity of IFM and RUC awards received from the CAISO. 22

Operations: Real-Time Energy Management 23

The Real-Time Operations group within ES&M will utilize the 24

PCI GenManager product as its primary tool to perform post-MRTU implementation business functions. 25

The principal system functions within GenManager that will be used will include monitoring of: (a) 26

individual generating resource performance and (b) the availability of generating capacity that may be 27

198

bid into the CAISO’s RTM. These monitoring functions will be based on near real-time data fed back 1

from generator output meters and CAISO market clearing results that will be processed through 2

GenPortal and available in GenTrader. 3

The availability of these GenTrader features will enable the Real-4

Time Operations group to complete its core business functions of: (a) monitoring plant performance 5

against CAISO-instructed energy production targets, (b) identifying scenarios that require mitigating 6

actions and (c) noting potential opportunities for SCE to bid available capacity into the RTM. 7

Operations: Outage Management 8

The Outage Management capabilities expected to be included 9

within GenTrader and GenPortal will be used to determine if any generating resources have been 10

identified to be operating (or expected to be operating) at reduced capacity. If there is any indication 11

that a generator resource is, or will be shutdown or de-rated, the Day-Ahead Operations or Real-Time 12

Operations groups will need to make the necessary adjustments to respective bids developed and 13

submitted to the CAISO. 14

The Outage Management module will also provide multiple 15

capabilities with respect to the administrative protocols of reporting reduced operating capacities or 16

shutdowns of generating units to the CAISO. There will be two key automated interfaces within the 17

Outage Management module: (a) a SLIC interface for two-way reporting with the CAISO and (b) a 18

website-based interface with generating plant operating personnel to enable effective and prompt 19

communications between the plants and ES&M Operations staff. 20

Finance: CAISO Settlements and Allocations 21

The MRTU market design will involve a number of changes to the 22

current CAISO charge types, as well as a number of significant adjustments to technology-based items. 23

In addition, the market design changes will have a direct impact on SCE’s charge allocation process. 24

This process involves PPF’s review of all CAISO charges, and, based on individual contract terms and 25

conditions, the identification of charges that are to be billed back to counterparties. 26

199

The GenPortal and GenManager products will be employed to 1

support these business functions. GenPortal will provide the communication mechanism wherein all 2

CAISO MRTU settlement files will be transferred to SCE and stored in the system. GenManager will 3

provide the features necessary to enable the PPF ISO Settlements group to execute three core business 4

functions when MRTU is operational: (a) perform next day predictive CAISO settlement calculations 5

on select charge types for immediate after-the-fact analysis feedback to various business groups, (b) 6

validate CAISO settlement statements through the “shadow settlement” functions within GenManager 7

and, (c) manage the overall charge allocation process and related resulting data. 8

Finance: Structured Contract Settlements 9

This group will also utilize data generated by and/or contained in 10

the GenManager product. The principal types of information required to ensure the validity and 11

accuracy of all settlements with counterparties after MRTU Release 1 implementation will include: (a) 12

energy trades, (b) exercised options, (c) IFM and RTM awards per generation resource, (d) outage 13

information per generating unit, (e) any real-time curtailments that affected generating schedules and (f) 14

expected energy values from the CAISO. 15

In addition to the base counterparty settlements functions, the 16

Structured Contracts Settlements group must be able to identify the CAISO charges that may be 17

allocated to a counterparty based on the existing contract terms and conditions. GenManager is 18

expected to provide the support features necessary for PPF to identify and classify these allocated 19

charges once MRTU has been implemented. 20

The availability of these types of data within the PCI products, 21

combined with other SCE sources of actual meter data, will support the core end-of-month business 22

functions of the Structured Contracts Settlements group that performs all counterparty settlements. 23

When final CAISO settlement data is available in GenManager, the Structured Contracts Settlements 24

group will perform true-up calculations and make any necessary adjustments to counterparty 25

settlements. 26

200

Finance: Accounting – Receivables and Payables 1

The principal support function provided by the PCI GenManager 2

product for this business function will be the calculation of the payables and receivables for CAISO 3

charges. The CAISO invoice amounts will be validated through the features of the GenTrader product, 4

and the determination of any financial adjustments will be identified in the process of validating CAISO 5

settlement statements. 6

In addition, the CAISO charge allocation process will produce the 7

amount of receivables due per counterparty. The system will generate, store and make available this 8

information for access by the PPF Accounting & Reporting group. The receivable amounts will be 9

converted into appropriate invoices for submittal by SCE to the appropriate counterparties for payment. 10

Financial: Reporting 11

PCI GenManager, GenPortal and the associated database 12

(GenBase) products will collectively contribute to the performance of various reporting business 13

functions by PPF’s Accounting & Reporting group. Also, with the MRTU market design there are new 14

financial-based transactions that must be identified and reported. For example, IFM awards for energy 15

and demand bids, and RUC awards for energy and RTM awards must be considered and reported 16

accordingly. 17

Reporting of CAISO charges and associated receivables for proper 18

entry into SCE’s Energy Revenue Recovery Account (ERRA) accounts will be supported by the 19

accumulated set of data available through GenManager and GenPortal. All this data will reside in the 20

PCI system in the underlying GenBase database. 21

(a) Planning 22

This SCE project initiative involves the procurement of several 23

major planning products to enable SCE’s ES&M group to develop optimal “least cost dispatch” plans 24

for the portfolio of generation resources available to SCE to meet its customers’ load in the new MRTU 25

market. Although the MRTU market design somewhat modifies the “least cost dispatch” scenario, SCE 26

201

is committed to participation in the new MRTU markets to achieve the same basic objective: least net 1

cost for energy delivered to our customers. 2

The need for new systems to carry out this objective is based on 3

the new MRTU market design and associated rules and protocols. Principal business drivers for change 4

are: (a) submittal of “bids” for CAISO’s procurement of available generator-based energy under MRTU 5

versus submittal of SCE’s “scheduled energy” for each generating resource under the current CAISO 6

market and (b) the introduction of LMP at approximately 3,000 specified nodes on the overall 7

transmission network versus today’s market, where SCE’s service territory lies predominately in a single 8

congestion zone (SP15) and associated pricing point. 9

The new MRTU market design requires a completely new set of 10

tools for SCE’s use in planning for the optimal set of bids to be submitted to the CAISO. The principal 11

factors that are taken into consideration for bidding are: (a) demand forecast for SCE’s anticipated load, 12

(b) energy price forecasts for various time horizons (e.g., monthly, next day and real-time), (c) natural 13

gas prices for similar time horizons and (d) forecasted market-clearing prices and unit dispatch levels for 14

the IFM and RTM. 15

CAISO’s MRTU market design changes are expected to evolve 16

over the next several years. In concert with this evolution, PPBU has developed a procurement and 17

internal development strategy for the new systems and tools to perform required planning-based 18

business functions. Each primary PPBU planning area and the associated procurement and/or 19

development of systems needed for MRTU Release 1 is noted below. 20

Demand Forecasting 21

As new MRTU market rules are defined, SCE will pursue either 22

procurement of new systems to meet the new market requirements or upgrades to existing application 23

tools to ensure accurate forecasts for SCE’s customer loads. The anticipated expenditures for these 24

system improvements are included in the cost forecasts below for MRTU Release 1A and MRTU 25

Release 2. 26

202

With respect to the MRTU market, there is a significant change in 1

how market participants will treat their forecasted loads. Unlike today’s market wherein the forecasted 2

load is simply identified to the CAISO for achieving “balanced schedules,” for MRTU SCE must supply 3

“demand bids” to the CAISO, for which SCE will incur associated costs from the CAISO. 4

Determination of the amount of forecasted load to be bid into the IFM, versus left for the RTM, will be a 5

required business function (known as SCE Demand Bidding Strategy). To support the development and 6

implementation of SCE’s Demand Bidding Strategy, the functionality of the PCI GenTrader and 7

GenManager tools will be employed. 8

Price Forecasting 9

Nearly all aspects of price forecasting will be affected by the new 10

MRTU market design, both initially and over time. SCE’s current set of applications and price 11

forecasting tools are not suited to the new MRTU market design and associated granularities for nodal 12

pricing. Thus, the immediate, as well as anticipated, rules and protocols have prompted SCE to procure 13

new applications that are designed to support LMP-based markets such as those in PJM Interconnection, 14

the Midwest ISO and the New York Power Pool. 15

Additionally, there are multiple time horizons for which PPBU 16

personnel must develop price forecasts for the MRTU market. In this regard, PPBU has developed a 17

strategy that employs a set of applications and support tools to achieve the desired outcomes of accurate 18

and timely price forecasts to meet the various business needs. The current set of applications and tools 19

are described below. 20

(i) Itron 21

The Itron application will support both short-term and long-22

term forecasting needs. It will provide ES&M staff the capabilities to identify a multitude of variables 23

and price-affecting factors to produce a range of price forecasts for consideration in performing PPBU 24

business activities necessary under MRTU. Primary business functions supported will be: (a) day-25

ahead energy price forecasts for supporting the development of the short-term plan for Resource 26

Optimization and IFM bidding, (b) real-time (intra-day) energy price forecasts to support potential 27

203

bidding options for the RTM, and (c) predicting CAISO market-clearing prices at the various LMP 1

nodes to support the IFM and RTM bidding strategies on a daily basis. 2

(ii) Pattern Recognition Technology (PRT) 3

Given the goal of achieving the most accurate price 4

forecasts possible to ensure the optimal use of SCE resources and least-cost results for SCE customers, 5

PPBU intends to evaluate and utilize various price forecasting strategies and algorithmic approaches. 6

To this end, ES&M management has obtained the services of PRT, a market-leading price forecasting 7

company, to supplement ES&M’s resources for developing effective and accurate price forecasts. These 8

services will consist of SCE’s daily receipt of nodal price forecasts for various time horizons and 9

commodities, e.g., energy and ancillary services. 10

(iii) Resource Portfolio Optimization – Short-Term Plans 11

The ES&M Resource Optimization group is responsible for 12

development of several short-term resource plans under MRTU. These include: (a) Day-Ahead Plan for 13

IFM, (b) a Balance-of-Month Plan for managing unit constraints and dispatch options for SCE-managed 14

resources through the end of a given month and (c) a 13-month look-ahead Plan for assessing the mix of 15

available SCE resources and identifying optimization strategies for evaluation with various ES&M 16

front-office groups. 17

To support the generation and management of these various 18

resource plans, PPBU has procured an industry-leading system that will provide the wide range of 19

product features and functions needed by the Resource Optimization group. This product is known as a 20

“Unit Commitment Engine” as it produces recommended (committed) dispatch levels for generating 21

units based on inputs provided by the users. The Generation Manager system is being provided by 22

Global Energy and is also referred to as the “Unit Commitment Heavy” or “UC Heavy” tool. The 23

Generation Manager tool will support very sophisticated unit commitment strategies and provide a high 24

degree of flexibility for adapting to the new market design changes under MRTU. The Generation 25

Manager tool will replace the existing Microsoft Excel spreadsheet tool, which cannot be modified to 26

204

support the new, complex needs – such as estimating the outcome of the CAISO IFM for various 1

strategies. 2

In addition to the Global Energy Generation Manager tool, 3

the PCI GenTrader product described above will also be used to evaluate options for Resource 4

Optimization Plans for the IFM. GenTrader is often referred to as “UC Lite,” in that it can be used to 5

refine proposed unit dispatches based on updated information from that used in the full-scale UC Heavy 6

studies run in the Global Energy Generation Manager tool. GenTrader study results will contribute 7

updates to the final Day-Ahead Plan that will be generated by the Global Energy Generation Manager 8

application. 9

(iv) Resource Portfolio Optimization – Long-Term Plans 10

To ensure the optimal use of available energy resources for 11

minimizing costs to its ratepayers, PPBU also develops long-term Resource Optimization Plans to 12

identify and manage the changes over time in the available sources of energy. These changes result 13

from terminations of existing contracted energy sources, possible reductions in available energy capacity 14

in aging units and effects of emission credits available for identified units. 15

These long-term plans do not require the level of 16

granularity and detail demanded by the various short-term plans. Thus, although MRTU introduces a 17

new LMP nodal market, SCE’s long-term power procurement needs in order to meet its forecasted 18

customer loads do not require that the tools have all the features and functionality required of the Global 19

Energy Generation Manager application, discussed above. 20

PPBU has determined that an upgrade of its current long-21

term resource optimization tools from Global Energy will be sufficient to support long-term resource 22

optimization under the initial and early stages of MRTU operation. The identified and installed 23

enhancements will enable ES&M’s Long-term Planning group to continue to assess SCE’s long-term 24

resource needs until there is sufficient operating history from MRTU operations. Given the lack of any 25

MRTU-specific market and resource operating data, the procurement of any new major application will 26

be deferred. The forecasted costs for new tools are considered in years 2009 and beyond. 27

205

(v) Transmission Management – Congestion Revenue Rights 1

With the implementation of the FNM and advent of LMP 2

nodal pricing in the MRTU market design, it is essential that PPBU be able to manage the congestion 3

management aspects of the new market. To do so, ES&M personnel will require a set of applications 4

and tools to maintain a representation of the new CAISO FNM and manage on-going temporary and 5

permanent changes to that model to reflect the operating transmission environment. 6

In conjunction with the FNM, the new MRTU market 7

design includes the presence of CRRs that provide financial benefits regarding congestion management 8

charges and support determination of generator dispatches from SCE-available resources. Under 9

MRTU, a certain number of CRRs will be allocated to SCE and additional CRRs will be available via 10

monthly auctions and secondary market transactions with counterparties. 11

These new MRTU design elements will give rise to two 12

major business functions for ES&M personnel: Congestion management through the FNM, and 13

evaluation and procurement/sale of CRRs. To achieve the identified goals of these business functions, 14

ES&M has procured one application and secured the services of an industry-leading consulting firm. 15

The basic scope and business support functions for each are described below. 16

ABB GridView is the application that has been procured to 17

store and manage the FNM. This is a widely-used application that enables the incorporation of the 18

complete set of transmission nodes as identified by the CAISO in the FNM. In addition it provides the 19

features and functions required to evaluate the impacts on nodal pricing due to transmission outages as 20

well as installation of new transmission capacity throughout the CAISO control area. These evaluations 21

will provide significant inputs to the process of valuing CRRs at various nodes of interest to SCE. 22

ES&M has also engaged the services of ECCO 23

International, Inc. for development of forecasted prices and value to SCE of CRRs throughout the 24

CAISO FNM. These services will enable PPBU to most accurately predict the value of CRRs for SCE’s 25

use and provide a foundation for developing a pricing strategy for participation in future CRR monthly 26

auctions and potential direct secondary market transactions. 27

206

(b) Data Management 1

In conjunction with the procurement and implementation of new 2

vendor-supplied applications, it is necessary for PPBU to implement additional database applications to 3

support the effective management of data associated with daily PPBU operations, including 4

management of its resources and interactions with the CAISO for market operations. The capabilities of 5

these data management systems will support PPBU’s effective planning and optimal resource dispatch 6

to achieve a “least cost” bidding structure that will provide SCE customers the required energy to meet 7

their needs through the most economical means. 8

These data management systems will serve three primary functions 9

within the overall PPBU operation: 10

• Management of Reference Data 11

• Capture, storage and distribution of Common Data 12

• Reporting and analysis of business operations 13

A brief description of the purpose and benefits of each major 14

system is addressed below. 15

Reference Data 16

The primary function of the Reference Data system will be to 17

ensure all applications within the PPBU operating environment will be aligned with respect to the core 18

points of reference that define the overall PPBU operation. The necessity for this alignment is that when 19

power procurement data is either extracted or captured/stored, it must be assigned to the appropriate 20

entity such that all end users, whether they are automated systems or individuals, will have the proper 21

context or point of reference for the specified piece of data. 22

There will be a specific set of entity types included in the initial 23

design for the Reference Data System. This initial set will ensure that PPBU’s MRTU applications will 24

have an approved set of references to draw upon for the business functions supported by each 25

application. The detailed reference data for each set of entities will be relatively static with low 26

volatility. Changes to the specific reference data will be “business-event” driven, i.e., business activities 27

207

such as execution of new energy contracts, addition of counterparties, or business-related changes to 1

operating profiles for generation resources will drive the updates to the set of reference data. The 2

Reference Data System is essential to ensure PPBU’s effective participation in the CAISO MRTU 3

markets and its ability to effectively manage settlement processes with counterparties. 4

Appropriate business processes will be developed to ensure the 5

reference data is maintained as current and accurate for use by other applications and end users. In 6

addition, technology-based solutions will be developed to enable the effective communication of 7

changes and exchange of data between the Reference Data System and other PPBU applications. The 8

initial system design, development, and deployment is expected to address near-term needs for PPBU 9

under MRTU, as well as establish a solid foundation for expanding the system to meet evolving business 10

requirements. Given the expectation that MRTU will continue to evolve, this platform will provide the 11

base for cost-effective solutions required in the future. 12

Common Data 13

The primary functions of the Common Data System are to receive 14

and store “transactional data” that has been identified as required for use by more than one application 15

or multiple end users to support performance of varied PPBU business functions. This transactional 16

data, e.g., bilateral trades, generator output meter data, or SCE system load data, will be mapped to 17

appropriate reference entities in conjunction with the set of reference data managed within the Reference 18

Data System. 19

The Common Data System will ensure all applications within the 20

PPBU operating environment will have available to them a single source for data that is essential for 21

each application to perform its business functions. In addition, end users that may need to extract 22

transactional data will have a centralized location from which this data can be extracted. The “single 23

source” function supported by the Common Data system will provide consistency in the data applied for 24

multiple end uses. This approach will also eliminate the need for multiple interfaces to a single source 25

system, thus reducing maintenance costs. 26

208

Appropriate business processes will be developed to ensure the 1

identification of transactional data that is needed to support both system-based applications as well as 2

user-developed applications (UDAs). Once identified, appropriate procedures and technology-based 3

solutions will be established to ensure the transactional data is: (a) extracted from the appropriate source 4

system, (b) available when required, (c) in the appropriate level of granularity and (d) transferred via 5

applicable interface mechanisms. The effective exchange of data between the Common Data System 6

and other PPBU applications will enable real-time operation, and support maintenance for data integrity, 7

through elimination of potential sources of errors. 8

It is anticipated that initial system design, development and 9

deployment will address the near-term needs for PPBU under MRTU, as well as establish a solid 10

foundation for expanding the system to meet evolving business requirements. Given the expectation 11

that MRTU will continue to evolve, this platform will provide the base for cost-effective solutions 12

required in the future. It will also serve as a key component in the architecture for the eventual PPBU 13

Data Store. 14

Data Store 15

The PPBU Data Store will be established to enable overall 16

reporting and analysis needs of PPBU to be carried out in support of both tactical and strategic 17

operational business functions under MRTU. In addition, the Data Store will provide functionality 18

required to support various data-based business needs for PPBU, other internal SCE organizations and 19

external entities such as regulators, special interest groups and business counterparties. 20

The Data Store will be designed with a core foundation to enable 21

early use while definitive business requirements evolve. It is anticipated this system will serve as the 22

underlying data repository to support post-operation analyses and gain insight on enhancements to 23

operational practices, strategies, and other planning activities that can be leveraged for improving 24

effectiveness in participating in the MRTU market. In addition, the data manipulation and analysis tools 25

available with this repository are envisioned to enable more complex analyses that can benefit SCE’s 26

long-term resource planning and energy supply strategies. 27

209

c) Project Costs and Schedule 1

As indicated above, SCE has received permission from the CPUC (via Advice 2

Letter 2091-E) to track expenditures for MRTU Release 1 in a separate memorandum account and will 3

seek to recover these costs in a separate ERRA Reasonableness of Operations proceeding outside of the 4

GRC, during which a detailed presentation of the project costs will be made.191 The high-level project 5

costs and schedule below are provided for information only. It is anticipated that SCE will incur an 6

additional $30.8 million between 2007 and 2008 in order to install and operationalize the new systems 7

required to participate in the new market mandated by MRTU. The activities to be accomplished during 8

this time will include: 9

• Complete deployment of production hardware, 10

• Complete implementation of all software and associated integration, 11

• Complete CAISO Market Simulations, 12

• Complete pre-production testing, 13

• Startup on MRTU “Go–Live” on March 31, 2008, and 14

• Implement PPBU Data Store by December 14, 2008 15

Table VI-37 MRTU Release 1 Project



2007 $26,800,000

2008 $4,000,000

Total $30,800,000

191 SCE’s Advice Letter 2091-E, effective May 24, 2007, is available at www.sce.com/NR/sc3/tm2/pdf/2091-E.pdf.

210

2. MRTU Release 1A Project (PPBU) 1

a) Introduction 2

The CAISO’s MRTU Release 1A program includes enhancements to MRTU that 3

have been ordered by FERC to be implemented within 12 months of the startup of MRTU (current 4

schedule for “Release 1” startup is March 31, 2008)192. FERC has ordered components of the Release 5

1A to include: 1) Virtual Bidding; and 2) Scarcity Pricing enhancement for reserves. Additional 6

components that may be incorporated in Release 1A include items that will be deferred from the 7

implementation of Release 1 or items currently slated for Release 2 but that are deemed urgent by the 8

CAISO. The CAISO does not intend to finalize the list of enhancements to be included in Release 1A 9

until mid to late 2007 as it completes a process of eliciting input from the market stakeholders.193 10

b) The MRTU Release 1A Project 11

SCE intends to design and implement a project to meet the requirements specified 12

by CAISO for the MRTU Release 1A. 13

Virtual Bidding is a mechanism whereby market participants can make financial 14

transactions of energy in the Day-Ahead market with the explicit requirement to reverse these 15

transactions in the Real-Time Market, thereby arbitraging their expected differences between Day 16

Ahead and Real Time prices. Virtual Bidding is described in more detail in the MS&RP department’s 17

O&M testimony, at Section B.1.(b)(2). 18

In MRTU Release 1 there is no explicit measure for the Scarcity Pricing of 19

generation capacity reserves. As discussed in the MS&RP department’s operations and maintenance 20

(O&M) testimony, Scarcity Pricing is designed to send appropriate price signals to the market during 21

192 FERC September 21, 2006 Order Conditionally Accepting the California ISO's Electric Tariff Filing to Reflect Market

Redesign and Technology Upgrade in Docket Nos. ER06-615-000 and ER02-1656-027 (Tariff Amendment No. 44 and Proposed MRTU Tariff).

193 CAISO White Paper – Three-year Market Initiatives Roadmap 2006-2008, Revised November 28, 2006, http://www.caiso.com/18bc/18bc8d6230fb0.pdf.

211

times of insufficient supply.194 The CAISO is in the process of developing Scarcity Pricing rules, which 1

are still in their infancy. 2

The Virtual Bidding and Scarcity Pricing components of Release 1A will likely 3

require additions and modifications to the systems currently being deployed to meet the requirements of 4

the MRTU Release 1 program: PCI GenPortal, and potentially, the PCI GenManager and PCI 5

GenTrader. However, the full scope of the MRTU Release 1A, outside of Virtual Bidding and Scarcity 6

Pricing, is unknown at this time. Moreover, the details of these two proposed enhancements are 7

unknown since the CAISO is still in the process of designing these enhancements. 8


Once the scope of CAISO’s MRTU Release 1A initiative is set and the 10

specifications for the market changes have been developed, SCE can then identify vendors to help it 11

modify existing systems or develop new capabilities to meet the new market requirements. The vendors 12







d) Projects Costs and Schedule 19

The MRTU Release 1A project cost forecast is based on implementing a simple 20

COTS product. This forecast assumes that the only two functional items required by Release 1A are 21

Virtual Bidding and Scarcity Pricing for reserves. It is anticipated that the PCI system will be in 22

production and it will be the only system that requires enhancement. The PCI system will need to have 23

the scheduling software modified to allow Virtual Bidding and the settlement system modified to 24

calculate charge types based on the new Scarcity Pricing rules. Since the application will be in 25

194 See Exhibit SCE-08, Vol. 1 (PPBU Market Strategy and Resource Planning), Chp. I, Section B.

212

production, there is no additional hardware cost associated with this project. It is assumed that there will 1

be integration with the PPBU systems used for price forecasting, risk management and planning. Since 2

both Virtual Bidding and Scarcity Pricing are new mechanisms for the California energy market, it is 3

anticipated that considerable business user involvement in the project will be required for software 4

selection, integration and customization. 5

The solution for MRTU Release 1A will be implemented within 12 months of the 6

startup of MRTU (current schedule for Release 1 startup is March 31, 2008). Based on the projected 7

schedule for project expenditure in 2007 and 2008, SCE has received permission from the Commission 8

to track the expenditures for the MRTU Release 1A project in a separate memorandum account (with the 9

costs of MRTU Release 1) and will seek to recover these costs in a separate ERRA Reasonableness of 10

Operations proceeding outside of the GRC, during which a detailed presentation of the project costs will 11

be made. The project costs and schedule are provided here for information only. It is anticipated that 12

SCE will incur an additional $1 million by 2008 in order to modify its systems to meet the potential 13

requirements of MRTU Release 1A.195 14

Table VI-38 MRTU Release 1A Project



2007 $250,000

2008 $750,000

Total $1,000,000

3. MRTU Release 2 Project (PPBU) 15

a) Introduction 16

The CAISO’s MRTU Release 2 is currently scheduled to be completed within 17

three years of the initial MRTU Release 1 (scheduled go-live date - March 31, 2008). It will include 18

195 See Workpapers to this Exhibit for the specific calculations resulting in this forecast.

213

enhancements ordered by FERC to be implemented within the three year time frame, as well as other 1

enhancements resulting from a stakeholder ranking process. There are over 20 market enhancement 2

components identified for consideration as part of Release 2. These include, among others: 3

• Interface between the Scheduling and Logging for the ISO of California 4

(SLIC) generation outage tracking system, and CAISO Scheduling 5

Infrastructure Bidding Rules system, 6

• Ancillary Service export capability, 7

• Bid Cost Recovery for units with run time greater than 24 hours, 8

• Modeling combined cycle generation systems as discrete generating units, 9

• Increased number of LAPs beyond the three specified in MRTU Release 1, 10

• Use bid-in demand rather than forecasted demand in the Market Power 11

Mitigation process, 12

• Resolve issues with the integration of intermittent resources such as renewable 13

generators, 14

• A full Hour-Ahead market, 15

• Sale of CRRs in auctions, 16

• Self-provision for RUC, 17

• Simultaneous runs of the RUC process and the IFM, 18

• Incorporation of a full Dispatchable Demand Response model, 19

• Creation of multi-settlement Ancillary Services (A/S) market, 20

• Consideration of import energy in the RUC process, 21

• Allow contract arrangements whereby generation resources meet Resource 22

Adequacy requirements only part of the time, 23

• Automation of sub-LAP adjustments – a process that will be manually 24

performed in MRTU Release 1, 25

• Accommodate use-limited resources with limited number of hours or start-26

ups, 27

214

• Treat Start-Up Energy as instructed energy rather than uninstructed deviation, 1

and 2

• Multi-segment bidding for some A/S services.196 3

As the term suggests, consideration of a measure does not necessarily mean a 4

measure will be included in MRTU Release 2, and new measures may still be proposed for 5

consideration for inclusion in MRTU Release 2. CAISO has not specified the cutoff date for defining 6

the scope of MRTU Release 2. 7

b) The MRTU Release 2 Project 8

SCE intends to design and implement a project to meet the requirements specified 9

by the CAISO for MRTU Release 2. Many of the proposed enhancements described above, and 10

additional design features, need to be evaluated in light of the success or lack of success of MRTU 11

Release 1 and it is unlikely the CAISO will publish much additional information on the scope of MRTU 12

Release 2 before mid-2008. 13

California environmental legislation is also likely to impact many of the proposed 14

components of MRTU, as additional use of renewable resources (wind, solar), demand response, and 15

greenhouse gas mitigation are likely to influence the priority for the development of solutions for some 16

market design issues (e.g., Dispatchable Demand Response, LMP impact on renewable resources, Multi-17

day unit commitment). 18

MRTU Release 2 enhancements will likely impact all components of PCI, SCE’s 19

forward planning and optimization tools, and possibly SCE’s Entegrate energy trading and risk 20

management system (discussed in Section V of this chapter, below). However, the full impact is 21

difficult to assess at this time, due to a lack of specification of the scope and design of the CAISO’s 22

intended enhancements. 23

196 See CAISO White Paper: Three-year Market Initiatives Roadmap 2006-2008, Revised November 28, 2006,

http://www.caiso.com/18bc/18bc8d6230fb0.pdf.

215


Once the scope of CAISO’s MRTU Release 2 initiative are set and the 2

specifications for the market changes have been developed, SCE can then identify vendors to help it 3

modify existing systems or develop new capabilities to meet the new market requirements. The vendors 4








The cost forecast assumes that a majority of the identified issues for Release 2, 12

listed above, will be implemented. Since the market elements will require an extensive stakeholder 13

process and further definition of technology impacts, the cost forecast provided herein is PPBU’s best 14

estimate of the magnitude of a project that may substantially expand or could narrow in scope. Once the 15

CAISO has finalized the scope of MRTU Release 2 and produced a business requirements manual, 16

PPBU will revise this cost forecast based on the published requirements and provide this information to 17

the Commission, as appropriate. 18

Presently, it is anticipated that the MRTU Release 2 project will include two 19

initiatives: 1) Highly Complex COTS; and 2) Highly Complex Development. It is anticipated that the 20

MRTU Release 1 suite of COTS packages will provide a good foundation for many of the requirements 21

identified for Release 2, but the additional market features currently identified by the CAISO for 22

potential inclusion in Release 2 are extensive and highly complex. As a result, additional charges, 23

modules, or possibly even new products will be required as part of a COTS system to support Release 2. 24

In addition, several of the components are likely to be specific to the California 25

marketplace and thus customized development of systems for some aspects of the project will very 26

likely be needed. Many of the components listed above were deferred from Release 1 because of their 27

216

complexity. If these items are implemented, the complexity of gathering requirements and completing 1

the development will be very high. The CAISO requirements definition process includes holding 2

stakeholder meetings to attempt to arrive at a consensus solution across diverse interests of each market 3

participant. While this consensus building process has proven to be very time consuming, the depth of 4

understanding acquired through the process is essential to both the IT and business personnel 5

responsible for implementing the solution. Since the list of components is very broad, it is expected that 6

considerable analysis will be required throughout the process to determine how each solution will be 7

incorporated into the existing SCE application portfolio. 8

PPBU anticipates that it will incur the following expenses by 2010 to modify its 9

systems to meet Release 2 requirements.197 10

Table VI-39 MRTU Release 2 Project



2008 $5,000,000

2009 $12,000,000

2010 $2,680,000

Total $19,680,000

4. Energy Procurement and Energy Planning Tools Project (PPBU) 11

a) Introduction 12

Energy Procurement Tools are a series of systems used to support PPBU’s 13

competitive solicitations for power or natural gas resources. Energy Planning Tools are upstream 14

support systems to the procurement function that help identify procurement needs, collateral 15

requirements, procurement cost risk, and the development of market parameters (e.g., price and 16

volatility forecasts) among other things. PPBU manages $7 billion of energy transactions annually to 17


217

serve SCE’s customers and these tools will help to ensure efficient and accurate PPBU operations. 1

These tools are particularly important at this time, given the additional regulatory and procurement 2

requirements that are currently in place, or SCE anticipates will be in place, for future operations. 3

Examples of these requirements include: 4

• The change from zonal pricing in three zones (in California) to over 3,000 5

locational pricing nodes under MRTU, 6

• The development of a Day-Ahead energy market in MRTU, 7

• Management of capacity “tags” to meet the CPUC’s Resource Adequacy 8

requirements, 9

• Price forecasts for SO2 credits, 10

• Potential price forecasts for GHG emissions credits to meet GHG emissions 11

reductions requirements, and 12

• Expanded gas forecast points from Southern California Border and Malin to 13

Permian, San Juan and Opal. 14

b) The Energy Procurement and Energy Planning Tools Project 15

The systems PPBU will procure to enhance its procurement efforts (Energy 16

Procurement Tools) and its planning for procurement (Energy Planning Tools) include: 17

Energy Procurement Tools 18

(1) Web-Based Energy Auction System: This system will be used by SCE to 19

complete competitive solicitations in the procurement of electrical energy, electrical capacity, and 20

natural gas. The system would have multiple functions including (i) web interface with counter-parties 21

to allow bid submittals, deal parameter entry, and bid withdrawal, (ii) contract valuation algorithms that 22

take the contract parameters and calculate the contract value automatically, and (iii) iterative auction 23

format clearing mechanism. This system would replace existing manual and ad-hoc tools used for these 24

functions. 25

(2) Market Modeling and Position Reporting: This project will build a position 26

analysis and reporting system for potential new products and resource attributes not currently captured 27

218

in existing PPBU systems. For example, SO2 and GHG position reporting and modeling, as well as 1

tracking Resource Adequacy (RA) attributes, require such systems. Additionally, PPBU must upgrade 2

its Risk Models to incorporate the procurement cost risk for the new products or attributes. Similar tools 3

need to be acquired or built for fundamental modeling of the natural gas market in the West as PPBU 4

expands its gas forecast points from Southern California Border and Malin to Permian, San Juan and 5

Opal. 6

Energy Planning Tools 7

(1) Collateral and Mark-to-Market Tool: Includes a cash collateral system that 8

models both existing and future contract obligations with regard to posting collateral to support 9

procurement contracts. This functionality would also help automate existing interface to Mark-to-10

Market valuations used for day-to-day operations. This tool would replace existing, ad-hoc user 11

developed applications. The new tool will better accommodate the expanded operations anticipated by 12

PPBU. 13

(2) Nodal Long-Term Market Simulation: With the introduction of nodal pricing 14

through MRTU, there is a need to consider nodal prices as part of long-term market simulation. 15

PPBU’s current long-term market simulation tools consider only zonal prices. 16

This is sufficient for today’s market and contract evaluations, but will be unsuitable for forecasting long-17

term nodal prices and perform contract and RFO evaluations under MRTU. A system will need to be 18

built to satisfy these requirements. 19

(3) Short-Term Market Simulation: With the introduction of nodal prices and the 20

FNM under MRTU, PPBU must be able to simulate the overall market on a short-term basis while 21

taking into account the FNM and the simulated behavior by other market participants. 22

This system will enable market simulation-based price forecasts and will support 23

the development of SCE bidding strategies. This system will also support bilateral trading of CRR 24

contracts as well as participation in the secondary CRR market. The system will also support bilateral 25

energy trades in the week-ahead and balance of month markets. 26

219


Once the specifications for the tools have been developed, SCE can then identify 2

vendors to provide or develop new capabilities to meet the specified requirements. The vendors will be 3

evaluated based on the following criteria: 4







It is anticipated that PPBU will spend approximately $13 million in capital 11

expenditure between 2007 and 2009 to develop, procure and install the tools described above. 12

(1) Energy Procurement Tools 13

The web-based energy auction system is forecast as a medium complexity 14

COTS package with additional integration efforts to support data transfer from the auction system to 15

existing support systems to perform the valuation and analysis. This project has an estimated cost of 16

$2,950,000.198 17

The market modeling and position reporting project has two components: 18

(1) Develop market models for each product; and (2) Procure a market model for Natural Gas. 19

The first component includes the various models required to value the 20

non-energy products and to calculate risk metrics associated with the products. Due to the complexity 21

of the market parameters and the contract terms associated with the products to be modeled, PPBU 22

expects that most of the modeling must be performed with custom developed applications. PPBU will 23

review available modeling tools that allow for significant modeling configurability or customization. 24

While a common framework may be developed using a commercially available modeling tool, most of 25


220

the analytical work capabilities will still require customized development. The market models will 1

require input from multiple sources that are expected to have different data formats. The model output 2

will be exported to multiple systems within PPBU. The market modeling algorithms will be derived 3

from internal business knowledge and therefore no external consulting is expected to support this 4

project. Since there is significant customization required even if a modeling tool is used, this component 5

is estimated to be a medium complexity development effort, with an estimated cost of $1,412,500.199 6

The second component is a gas model that could be used to further 7

evaluate the western natural gas market. Since natural gas is a widely traded commodity, it is expected 8

that a software vendor would provide this functionality. This project is anticipated be a medium 9

complex COTS package due to the number of functional and integration points anticipated for an 10

effective gas market model, with an estimated cost of $1,405,000.200 Similar to the modeling tool 11

described above for non-energy products, the gas model will also have multiple inputs to run the model 12

and output to one or more systems. Inputs would include, for example, items like transportation pipeline 13

capacity, assumptions concerning Liquid Natural Gas capacity, and forecasts of worldwide demand for 14

natural gas. The total cost of the components is estimated at $2,817,500. 15

(2) Energy Planning Tools 16

Existing PPBU systems cannot calculate a forward collateral requirement 17

for complex structured transactions (e.g. tolling agreements) because such transactions are not valued in 18

PPBU’s current ETRM system. The existing logic for calculating forward collateral requirements is 19

embedded in a variety of customized PPBU solutions that need to be converted to a more secured 20

application and database environment. The collateral requirements are dictated by the specific terms 21

and conditions proposed by the offer. These contracts are very diverse and will require a collateral 22

calculation engine that provides significant flexibility in modeling specific contractual terms and 23

199 The specific calculations resulting in this forecast are provided in the Workpapers accompanying this Exhibit. 200 The specific calculations resulting in this forecast are provided in the Workpapers accompanying this Exhibit.

221

conditions. This flexibility is the primary driver of the complexity of this project. The total estimate for 1

this medium complexity development project is $2,290,000.201 2

SCE uses multiple tools to model market behavior and simulate market 3

dynamics. The current set of tools is being augmented through the MRTU program, specifically with 4

Global Energy’s Resource Optimization tool and ABB’s Gridview. These tools specifically assist SCE, 5

respectively, in bidding generation units into the CAISO and determining the value of Congestion 6

Revenue Rights. Additionally, SCE uses Global Energy’s Planning and Risk tool for generation 7

dispatch and resource planning. These tools may be augmented or additional tools procured to manage 8

long term and short term market simulations. These simulations model market behavior by other market 9

participants beyond SCE to determine the overall market behavior within the nodal market. 10

It is assumed that these two simulation engines would be different as the 11

calculation methodologies for long term and short term are significantly different. The underlying 12

model may be similar but there are adjustments to the modeling granularity that would most likely 13

require two different COTS products. Based on their expected functionality, the products will be 14

medium complexity. The Long-Term Simulation tool is estimated to have a capital cost of $2,912,500. 15

The Short-Term Simulation tool is estimated to have a capital cost of $2,012,500, for a total cost of 16

$4,925,000. 17


222

Table VI-40 Energy Procurement and Energy Planning Tools Project


Energy Auction System

Market Modeling & Position Reporting

Collateral & Mark to Market

Market Simulation Models Total

2007 N/A $600,000 N/A $925,000 $1,525,000

2008 $1,900,000 $1,200,000 $2,290,000 $2,000,000 $7,390,000

2009 $1,050,000 $1,017,500 N/A $2,000,000 $4,067,500

Total $2,950,000 $2,817,500 $2,290,000 $4,925,000 $12,982,500

5. Capacity Position Register and RA Registry Compliance Process (PPBU) 1

a) Introduction 2

Under CPUC RA requirements (per Public Utilities Code §380(c)), PPBU must 3

secure total system-wide generation of approximately 115% to 117% of SCE’s expected peak load. In 4

addition, in coordination with the CAISO, the CPUC has established local-area RA requirements. For 5

example, the CPUC mandates that SCE must procure a certain amount of system capacity from 6

generation located within the LA Basin. SCE is required to submit annual system and local RA 7

compliance filings as well as monthly system RA compliance filings to the CPUC (with copies to the 8

CAISO and the CEC). 9

PPBU’s Capacity Position and RA Registry Compliance project will ensure all 10

generation capacity data and associated attributes are maintained in a controlled environment and that 11

compliance errors are minimized. Currently, SCE capacity data is held in various controlled and 12

uncontrolled systems across PPBU: 13

• ES&M generation and capacity contracts data are stored in Nucleus, 14

• Renewable & Alternative Power (RAP) generation and capacity contracts data 15

are stored in the Wholesale Energy System (WES), and 16

• Utility retained generation data is maintained in tracking spreadsheets. 17

223

This project will provide a system of record for all capacity resources (or will 1

interface with a system of record such as Entegrate) and interface to the CAISO’s SLIC generation 2

outage tracking system. The system acquired through this project will serve as SCE’s internal RA 3

compliance tracking and reporting system. 4

b) The Capacity Position Ledger and RA Registry Compliance Project 5

This project will build a Capacity Position Ledger and RA Registry that will 6

actively track the following items for all of the generation resources in SCE’s portfolio, including SCE’s 7

retained generation, and all types of power contracts, including Qualifying Facility (QF) and other 8

renewable resource contracts: 9

• Capacity by generation source and generation type, 10

• Actual capacity expectations, 11

• Outages, 12

• Demand side management, 13

• Contract tie-in by capacity, 14

• RA data such as actual capacity vs. RA requirements, for total system and for 15

local areas, and 16

• RA capacity projections. 17

The Capacity Position Ledger and RA Registry will also need to accommodate 18

many scenarios where specific resource characteristics can influence SCE’s ability to count resources 19

for RA compliance. Currently, SCE is required to comply with System RA and LA Basin local RA 20

requirements. Each of these requirements may have different counting rules for the same resource (e.g., 21

scheduled outages do not impact Local RA showings but do impact System RA showings.). 22

The Capacity Position Ledger and RA Registry Compliance project will result in 23

a system where all of the generation capacity data and associated attributes under the control of PPBU 24

are maintained in a centralized, controlled environment to enhance compliance with RA requirements. 25

224


Once the specifications for the register have been developed, PPBU can then 2

identify vendors to provide or develop new capabilities to meet the specified requirements. The vendors 3








The tracking and reporting of capacity positions will be accomplished by 11

acquiring an additional module to the Entegrate product. Since this is an additional module for an 12

existing system, there would be no additional hardware or server licensing costs. The module will 13

acquire capacity data from external systems and several external systems will need the data to support 14

regulatory compliance reporting. This means the project will require a substantial integration effort. It 15

is anticipated that the requirements will be served by a medium complexity COTS product. The 16

complexity is primarily driven by the multiple sources of information and the different formats of the 17

information delivered. The costs of this COTS product are estimated at $1,102,500 and it is anticipated 18

that the project will be started and completed in 2009.202 19

Table VI-41 Capacity Position Register and RA Registry Compliance Project



2009 $1,102,500

Total $1,102,500


225

6. Resource Adequacy Capacity Market Project (PPBU) 1

a) Introduction 2

A centralized capacity market for the RA program is currently under 3

consideration by the CPUC.203 If a centralized capacity market is approved by the CPUC, it will then be 4

subject to a CAISO stakeholder process and subsequently submitted to FERC for approval and 5

implementation. A forward centralized market would change how individual LSEs such as SCE will 6

satisfy and comply with CPUC-mandated RA requirements.204 7

Under CPUC RA requirements (per Public Utilities Code §380(c)), PPBU must 8

secure total system-wide generation of approximately 115% to 117% of SCE’s expected peak load. In 9

addition, in coordination with the CAISO, the CPUC has established local-area RA requirements. For 10

example, the CPUC mandates that SCE must procure a certain amount of system capacity from 11

generation located within the LA Basin. If the centralized capacity market is adopted by the CPUC and 12

FERC, and implemented by the CAISO, PPBU will need to be able to interact with the market in order 13

to manage SCE’s resource positions and demonstrate that it is in compliance with the RA requirements. 14

b) Background 15

(1) PPBU’s Role in RA Compliance 16

One of PPBU’s responsibilities is to manage SCE’s fulfillment of RA 17

requirements. Currently, PPBU (through the ES&M department) tracks resource capacity from 18

structured, bilateral contracts and SCE’s utility-retained generation to demonstrate that SCE has 19

complied with RA requirements. 20

203 See Exhibit SCE-08, Vol. 1 (PPBU Market Strategy and Resource Planning), Chp. I, Section B. 204 The CPUC is currently scheduled to adopt a final decision regarding a centralized capacity market, or other long-term

RA structure, in January 2008. Due to the current uncertainties surrounding the scope and features of any CPUC-approved centralized capacity market, and the anticipated actions to be taken by the CPUC in 2008 with respect to the potential approval of a centralized capacity market structure, SCE’s Application for this General Rate Case includes a request to update its expense forecasts relating to the Centralized Capacity Market during the update phase of this proceeding.

226

(2) The RA Capacity Market Project 1

The CPUC is currently considering long-term market designs for RA 2

compliance. SCE has proposed a four-year forward centralized capacity market administered by the 3

CAISO.205 All loads within the CAISO would be subject to the capacity market structure and would be 4

billed for capacity based on the resulting auction prices and their realized load.206 5

If the CPUC approves a centralized RA capacity market structure, and the 6

CAISO obtains FERC approval to operate such a market, PPBU will modify its systems in order to 7

participate in the market in various ways, including but not limited to: 8

• Participating in the primary auction, 9

• Monitoring and modeling the resulting market charges associated with 10

capacity and RA, and 11

• Validating and paying the market charges. 12

It is not possible at this time to describe all of the interaction between 13

PPBU and any new RA capacity market. The scope, structure, and specifications of such a market are 14

not known, and in fact many of the detailed market mechanisms will require development and 15

refinement in a subsequent CAISO process. If the CPUC approves the capacity market by January 16

2008, following its current schedule for the proceeding, SCE anticipates that the CAISO stakeholder 17

process will go through the remainder of 2008, ending with FERC approval in 2009. In this scenario, 18

the market would be implemented in late 2009 or early 2010. 19


Once the scope for the centralized capacity market for RA is defined, PPBU will 21

be able to determine the specifications to work with such a market. This will drive the potential work 22

scope for the project and then PPBU can determine if it will need outside vendor assistance to complete 23

the project. If so, the vendors will be evaluated based on the following criteria: 24

205 Id. 206 Southern California Edison Company's Track 2 Centralized Capacity Market Proposal, filed March 30, 2007, in R.05-12-

013.

227







The RA Capacity Market project assumes that the centralized capacity market 7

would operate as described in SCE’s proposal to the CPUC. PPBU expects that this project will require 8

an additional module added to the Entegrate product. The additional module would value the RA 9

capacity market charges that SCE will incur with its portfolio. Since this is an additional module to an 10

existing system, there would be no additional hardware or server licensing costs. Integration 11

requirements for importing external sources of data will leverage the Capacity Registry project and 12

therefore no additional integration costs are added beyond the base case. The RA Capacity Market 13

project is expected to be a Medium Complexity COTS project based on the anticipated functional 14

requirements to value RA capacity charges in this new market. The complexity is similar to the Market 15

Modeling project described above, as multiple sources of data are required to support the valuation of 16

the capacity market. The costs are estimated at $1,050,000 and it is anticipated that this project will be 17

started and completed in 2009.207 If, however, the capacity market mechanism adopted by the CPUC is 18

substantially different than the proposal provided by SCE, PPBU will need to revise the project scope 19

based on the specific regulatory requirements published by the CPUC, as well as the tariffs and business 20

requirement manuals published by CAISO to implement the CPUC’s decision when these become 21

available. 22


228

Table VI-42 Resource Adequacy Capacity Market Project



2009 $1,050,000

Total $1,050,000

7. Tolling Automation Project (PPBU) 1

a) Introduction 2

A critical PPBU business function is structured contracts/tolling settlements. 3

Through this process, the PPF Department determines the netted financial obligation that SCE has to its 4

counterparties for each contract.208 The financial results are based on terms and conditions of the 5

prevailing executed contracts for which settlement provisions vary per contract. All relevant 6

transactions, including the actual delivery of requested energy, any non-performance events that may 7

reduce SCE’s financial obligations, and reconciliation of costs for natural gas must be factored into the 8

final calculations. These and additional components must be accurately modeled and monthly charges 9

calculated correctly to ensure SCE’s obligations are not overstated. 10

PPBU’s current ETRM suite, SunGard Nucleus, and the future system Entegrate, 11

are not capable of supporting all the variations in charges to be calculated. To date, PPF staff has had to 12

develop work-around solutions to meet requirements for settling the tolling unit contracts that have been 13

executed. Without the availability of a full-scale automated system that can support the current and 14

anticipated requirements for these contracts, PPF staff will be forced to continue to design and 15

implement independent, often manual, tools in order to perform the core business functions required to 16

settle structured and tolling contracts. The manual nature of these tools means that PPF will need to 17

utilize additional manpower to settle the contracts as SCE’s load base expands as anticipated. Also, it 18

208 See Exhibit SCE-08, Vol. 4 (PPBU Power Procurement Finance), Chp. I, Section C.2. for a description of counterparty

settlement activities.

229

will become increasingly laborious to perform quality assurance validations on tolling contracts 1

settlement as these manual tools proliferate. 2

b) Background 3

(1) Tolling Contracts Settlement Activities 4

The basic power contract settlement business functions involve the 5

administrative setup and periodic determination of the net financial outcome of energy transactions 6

under the structured contracts executed by SCE with its counterparties.209 For these contracts, the 7

primary area of focus involves tolling arrangements. Tolling arrangements include contractual 8

provisions wherein SCE receives energy from generating facilities in return for specified compensation, 9

including in most cases SCE supplying natural gas to enable the units to produce the desired amount of 10

energy. 11

Tolling contracts typically do not have the same terms and conditions 12

across multiple contracts that will determine methodologies and calculations of charges and related 13

financial settlement values.210 The presence of these diverse and inconsistent provisions among legacy 14

structured contracts and tolling agreements is a direct result of both internally and externally-driven 15

factors as discussed below. 16

Internally, PPBU is challenged with a diverse set of existing resource 17

types for which financial considerations were established under previously-approved operating 18

strategies. As the on-going energy needs for SCE’s customer base are evaluated and energy markets are 19

monitored, PPBU develops new operating strategies and economic risk models to ensure its customers’ 20

interests are protected. These evolving economic models provide the core basis for PPBU’s negotiating 21

strategies for new energy supplies, typically via tolling contracts. Thus, the specific provisions that 22

drive financial settlements are subject to constant change. 23

209 Id. 210 Id.

230

External factors contributing to the variance of settlement terms and 1

conditions include: market-based energy supplies, availability of power from existing generation 2

resources, potential for new generation development and the overall future outlook on the natural gas 3

supply. In addition, the CAISO market design continues to evolve as MRTU is implemented. The 4

constant market changes imposed on SCE and other CAISO market participants present a continuous 5

stream of new requirements that impact the contract terms applicable to financial settlements for tolling 6

contracts. Accordingly, PPBU expects that future contract negotiations will continue to define new 7

terms and conditions that drive financial settlement methodologies and calculations. 8

(2) The Tolling Automation Project 9

The settlement provisions in SCE’s tolling contracts and associated 10

algorithms necessary to calculate payment amounts cannot be readily modeled in PPBU’s current 11

ETRM (Nucleus) or in the soon-to-be implemented ETRM, Entegrate. Like Nucleus, Entegrate is 12

designed for deal capture, physical scheduling of energy, risk management support and settlement of 13

standard energy-based transactions (i.e., purchase/sale of power, natural gas and financial derivatives.) 14

Thus, PPBU’s Tolling Automation project seeks to build an automated system that will support PPF’s 15

settlement of tolling contracts and interface with Entegrate to prepare final invoices. The automated 16

system will accommodate three primary functions required to settle a tolling contract: 17

(1) Capturing all contract terms that affect economic calculations, 18

including but not limited to: 19

• Term (start and end date/time) 20

• Rules for calculation 21

• MRTU “awareness,” including locational marginal prices, CRRs, and 22

credits 23

• CAISO charges 24

• Generation resource heat rates and status 25

• Allowable capacity by unit and time period 26

• Allowable unit starts 27

231

• Allowable outages 1

• Capacity payment and payment adjustment rules 2

• Ancillary services by type 3

• Unit fuel requirement 4

• Demand charges 5

• Emissions cost and responsibility 6

• Variable O&M cost and cost drivers 7

• Gas/fuel transportation costs 8

• Replacement energy costs 9

(2) Accessing and capturing external financial and physical data required 10

for settlement, including: 11

• Settled index prices for gas and power 12

• Associated fuel contract transactions such as hedges 13

• Associated fuel transport transactions 14

• Fuel transport tariffs 15

• Meter data 16

• Schedules 17

• CAISO interface protocol 18

• CAISO charge data 19

• SCE Generation Operations Center Log 20

• SCE Generation Management System interface protocol 21

• Counterparty information 22

• Scheduled and actual fuel flows 23

• Scheduled and actual power deliveries 24

(3) Calculating the expected payment amounts and invoice line items, and 25

generating exception reports on major economic factors such as fuel and power volumes, number of 26

starts, O&M, etc. The automated tolling settlement system would interface with Entegrate to record and 27

232

produce the actual invoices. The system would also need to have ad-hoc reporting capabilities to allow 1

for monitoring and auditing of the settlement of the tolling contracts by PPF’s counterparty settlements 2

group. 3

In sum, the automated system will support PPBU’s expanding operations 4

by streamlining the settlement of structured tolling contracts. The principal benefits of the automated 5

system will be its ability to: 6

• Provide PPF with the capability to quickly and accurately settle tolling 7

contracts with different terms and conditions, 8

• Provide a higher degree of security and quality assurance over the 9

current, mostly manual user-defined tools and processes used by PPF 10

to perform tolling contract settlements, and 11

• Allow PPBU to efficiently expand its operations in response to load 12

growth, changes to the California energy market, and the growth of 13

regulatory mandates such as the RPS or GHG emissions reduction, 14

which may require PPBU to engage in the purchase and sale of 15

additional items such as Renewable Emissions Credits or GHG 16

emissions credits through structured contracts. 17


Once the specifications for the Tolling Automation solution are defined, SCE will 19

determine if it will need outside vendor assistance to complete the project. If so, the vendors will be 20

evaluated based on the following criteria: 21






233


This project would take inputs from several systems to assist with settling 2

complex structured contracts. The systems providing information to this system would include the 3

following applications: 4

• Resource Optimization (MRTU Release 1 Project) 5

• PCI GenManager (MRTU Release 1 Project) 6

• Common Data (MRTU Release 1 Project) 7

• Data Store (MRTU Release 1 Project) 8

• Market Modeling (Energy Procurement and Energy Planning Tools Project) 9

• Price Database (2007 Project) 10

• Generation Management System (Existing Application) 11

The system itself would be composed of several sub-components that would 12

include: 13

• Data Importer 14

• Data Validation 15

• Contract Builder 16

• Calculation Engine 17

• Settlement Viewer 18

• Settlement Reporting 19

• Settlement Exporter 20

The work flow associated with this system would be to import data from the 21

various systems in their respective formats (e.g., comma separated values, XML). This imported data 22

would be validated against a series of business rules to determine whether the data falls within the 23

expected range. The Contract Builder sub-component would model the contract terms and conditions 24

and establish the equations applicable to the contract. The Calculation Engine would calculate the 25

equations using the relevant imported data to determine the settlements associated with the contract. 26

The Settlement Viewer would be used to verify the results using a set of business rules that determined 27

234

whether the calculations are within the expected range and identify any outliers. The Settlement 1

Reporting sub-component would allow for reporting from the system. The Settlement Exporter would 2

export the information in the correct format for the Entegrate product that is used for invoicing purposes. 3

Based on the complex nature of tolling contracts, the functionality of the system 4

will require inputs from multiple systems, with validation logic to ensure data integrity and user screens 5

to evaluate data used to describe the settlement terms and conditions. It is anticipated that this will be a 6

Medium Complexity COTS project with significant customization. Vendor labor is also increased 7

above the base case as the amount of customization involved will likely increase the need for additional 8

vendor support.211 The cost of this project is estimated at $3,887,500. PPBU anticipates that the project 9

will be implemented in 2008. 10

PPBU expects that implementation of the Tolling Automation Project will enable 11

the PPF department to reduce the number of additional analysts it would otherwise need to hire to carry 12

out tolling settlements activities by seven FTEs. Over the initial five-year life of the project, this would 13

result in a savings of over $4.5 million in avoided labor costs.212 14

Table VI-43 Tolling Automation Project


Year Forecast Capital Expense

2008 $3,887,500

Total $3,887,500

8. Greenhouse Gas Project (PPBU) 15

a) Introduction 16

Assembly Bill 32 (AB 32), the Global Warming Solutions Act, instituted a long-17

term greenhouse gas mitigation program. The stated purpose of this legislation is to cut GHG emissions 18

211 The specific calculations resulting in this forecast are provided in the Workpapers accompanying this Exhibit. 212 See Workpapers to this Exhibit for the calculations supporting this estimate.

235

to reduce the level of GHG emissions in 2020 to that of 1990. The California Air Resources Board 1

(CARB) is responsible for recommending a mechanism to accomplish this. CARB’s proposal is due by 2

January 1, 2009, and it will most likely include an emissions cap and credit trading system.213 3

b) PPBU’s GHG Role 4

PPBU is responsible for ensuring that SCE satisfies environmental requirements 5

related to providing power to retail customers. For example, PPBU is responsible for managing SCE’s 6

position in emissions credits and eligible renewables in order to meet various environmental and other 7

regulatory requirements. PPBU anticipates it will need to develop the capability to identify, validate, 8

purchase, sell and otherwise manage GHG emissions credits for SCE, once a GHG emissions reduction 9

mechanism is adopted. 10

(1) The Greenhouse Gas Project 11

In October 2006, California, under the order of Governor Schwarzenegger 12

formed a GHG trading partnership with seven northeast and Mid-Atlantic States (known as the Regional 13

Greenhouse Gas Initiative). Other initiatives to reduce GHG emissions and to generate GHG emissions 14

credits may also take place in order to achieve the emissions reductions mandated by AB 32. These may 15

include: 16

• Programs to encourage and measure increased energy efficiency in 17

homes, buildings and industry, 18

• Increased deployment of renewable energy sources and methods to 19

capture the GHG credits generated by these sources, 20

• Generation of GHG emissions credits from electric and hybrid 21

vehicles, 22

• Generation of GHG emissions credits for distributed energy sources 23

through the avoidance of transmission losses, and 24 213 Due to the current uncertainties surrounding the scope of GHG emissions requirements and the anticipated actions to be

taken by the CPUC, and potentially the CARB, in 2007 and 2008 to develop such requirements, SCE’s Application for this General Rate Case includes a request to update its expense forecasts relating to GHG requirements during the update phase of this proceeding.

236

• Capture of GHG emissions at the generation sources and injection 1

back into ground reservoirs. 2

There are many potential impacts of GHG legislation and regulatory 3

initiatives on PPBU operations, including but not limited to the following: 4

• Trading GHG credits and managing GHG positions to satisfy emission 5

reduction mandates, 6

• Planning generation resource deployment to optimize GHG emissions, 7

• Additional use of renewable resources (e.g., wind, solar, hydro) for 8

GHG emission reduction – which may influence the priority of some 9

market design issues (e.g., Dispatchable Demand Response, 10

Locational Marginal Pricing impact on renewable resources, Multi-day 11

unit commitment) in MRTU, 12

• Improved metering and monitoring of renewable and distributed 13

generation resources, 14

• Significant increases in demand side management (DSM) programs, 15

and 16

• Potential modifications to greenhouse gas reporting through the 17

California Climate Action Registry (CCAR). 18

As the second-largest California electric utility, SCE expects it will take a 19

leading role in developing and implementing the programs necessary to achieve GHG reductions. With 20

this GHG project, SCE is planning to take a proactive approach to compliance with AB 32. However, 21

the full extent of PPBU’s future involvement with potential programs to reduce SCE’s GHG emissions 22

cannot be precisely known at this time. There are many unknowns associated with GHG reduction 23

requirements, such as: 24

• The details to be included in CARB’s recommendation for a program 25

to achieve the mandated reduction, 26

237

• The nature of, and rules surrounding, a potential GHG emissions credit 1

market, 2

• The liquidity of a GHG emissions credit market, 3

• The nature of the GHG emissions credit as a trading commodity, 4

• The certification requirements for GHG emissions credits, and 5

• Impacts of GHG requirements on MRTU market design. 6

At a minimum, PPBU anticipates that it will need to be ready to purchase 7

and sell GHG credits, report to the CCAR or some other centralized registry, and be able to validate the 8

transfer of GHG credits in trading transactions. There may be additional requirements to enable PPBU 9

to track GHG credits from other sources such as DSM. PPBU may also need to develop the planning 10

and risk management capabilities for GHG emissions credits similar to the capabilities it currently 11

possesses for power and gas transactions. 12


Once the scope for meeting the GHG emission reduction requirements is defined, 14

PPBU will be able to better determine the potential work scope for the project and then determine if it 15

will need outside vendor assistance to complete the project. If so, the vendors will be evaluated based 16

on the following criteria: 17







Because of the uncertainties that surround this project, SCE can only provide a 24

very high-level estimate of the costs required to participate in a potential centralized RA market. AB 25

32’s currently-established milestones include the following: 26

238

• January 1, 2008 – Reporting and verification process established (similar to 1

current CCAR) 2

• January 1, 2010 – Implement early emission reduction voluntary measures 3

(Air Resources Board to develop plan) 4

• January 1, 2011 – Quantify GHG emission reductions from voluntary offset 5

projects 6

• January 1, 2012 – Implement limits and mandatory measures to meet 2020 7

goal of emitting 1990 GHG emission levels. 8

The primary systems required to support these efforts within PPBU will be 9

associated with accurately accounting for the forward GHG levels in the planning process. Additionally, 10

optimization of emission impacts within the economic dispatch algorithm will be required. 11

As an emissions credits market emerges, additional requirements may evolve. 12

The emissions module within Entegrate is expected to be able to manage simple transactions, track 13

nominal emissions positions, and possibly value the current emissions position. 14

The cost estimate provided below is based on the assumption that the following 15

are the only requirements within PPBU to manage GHG during the timeframe applicable to this GRC: 16

(1) monitoring emissions from the energy portfolio; (2) planning for various carbon constrained 17

scenarios; and (3) managing the position and valuation of carbon offsets and/or credits. 18

The first component, monitoring emissions from the energy portfolio, would 19

require tracking the carbon content of SCE’s procured energy portfolio. This would require applying 20

allocation algorithms for all energy purchased from non-specified resources (e.g., imbalance energy in 21

the California market) as well as tracking the carbon associated with purchases from specific resources. 22

This is assumed to be a module of Entegrate and therefore is characterized as a simple COTS product, 23

assuming that the vendor will have a usable module to offer. It is also assumed that there will be 24

additional integration and customization efforts than normally incurred with a simple COTS product, 25

given the number of interfaces that may be required (e.g., to Settlements or Planning). Because this is 26

239

assumed to be an add-on to an existing application, there are no additional hardware or server license 1

costs. The total estimate for this component is $812,500.214 2

The second component would add additional planning capability (e.g., market 3

modeling, portfolio valuation, transaction valuation) under carbon constrained scenarios to the multiple 4

Planning and Risk tools (short-term, mid-term and long-term planning) included in the MRTU Release 1 5

project. PPBU’s estimate of expenditures for this component assumes that these changes are only 6

needed for Global Energy’s products and that the changes would be applied to both the Planning and 7

Risk tools as well as the Resource Optimization tools offered by the vendor. This assumes that neither 8

the PCI GenTrader tool nor the ABB GridView tool would require any changes to their algorithm to 9

account for carbon constraints. 10

Because the foregoing constitutes new functionality for the Global Energy 11

products, incorporating the California-specific requirements is likely to require specific customization to 12

the models. In addition to this customization, the interfaces to external systems will need to 13

accommodate specific data generated through the modeling of the carbon constraints. As a result, this 14

component is anticipated to be a Medium Complex COTS product. There are no incremental servers or 15

server licenses, but since the planning tools generate large data dumps, it is assumed that additional 16

storage space will be required. The total estimate for this component is $2,705,000.215 17

The third component, managing the position and valuation of emissions, would be 18

a component of the emissions monitoring module and the planning tools discussed above. Conceptually, 19

those systems could manage emissions positions, including tracking and validating the position and 20

applying prices to calculate emission credit values. However, since the GHG emissions market will be 21

new and compliance with the emissions reductions requirements is crucial to SCE, PPBU may require 22

additional analytical support to accomplish these functions and effectively operate in the new market. 23

PPBU expects this component will be a Medium Complex COTS product with additional integration 24

214 The specific calculations resulting in this forecast are provided in the Workpapers accompanying this Exhibit. 215 The specific calculations resulting in this forecast are provided in the Workpapers accompanying this Exhibit.

240

and customization. The complexity is driven primarily by the valuation methodology, which requires 1

multiple inputs from a variety of sources with differing data formats. There are no incremental 2

hardware or server licenses. The total estimate for this component is $1,500,000.216 3

PPBU anticipates that the project will cost a total of $5,017,500 in capital 4

expenditures in 2010, based on the organization’s best estimate (in light of the limited information 5

currently available) of the GHG functionality SCE will require. As the specific requirements of AB 32 6

become better defined by the CARB and other regulatory agencies, PPBU plans to validate and update 7

these assumptions and the associated cost forecast and will make this information available to the CPUC 8

as deemed appropriate by the CPUC. Since there are major uncertainties surrounding the rules and the 9

resulting business processes and data formats at this time, these estimates, based on the high level 10

assumptions described above, may need to be significantly increased if the actual regulatory-driven 11

requirements turn out differently. 12

Table VI-44 Greenhouse Gas Project


Year Monitoring Planning Valuation Total

2009 $812,500 $1,200,000 $0 $2,012,500

2010 $0 $1,505,000 $1,500,000 $3,005,000

Total $812,500 $2,705,000 $1,500,000 $5,017,500

9. Demand Response Project (PPBU) 13

a) Introduction 14

The CPUC has encouraged the growth of Price Responsive Demand Response 15

(PDR) in order to “enhance electric system reliability, reduce power purchase and protect the 16

environment.”217 In D.05-11-009, the CPUC developed a strategy and initial programs to promote DR. 17

216 The specific calculations resulting in this forecast are provided in the Workpapers accompanying this Exhibit. 217 CPUC Rulemaking (R.)02-06-001.

241

In proceeding A.05-05-006, the CPUC adopted 2006-2008 programs and goals for DR for SCE and the 1

other California energy IOUs. In 2007, the goal for PDR is 5% of the utilities’ gross power needs. 2

Currently, PDR constitutes between one and two percent of SCE’s portfolio. This 3

is partly is due to SCE customers’ participation in Reliability Demand Response tariff programs, such as 4

I-6 and Base Load Interruptible rates. However, SCE anticipates that PDR will become an increasing 5

factor in its power requirement as customers respond to the Company’s PDR programs. Furthermore, in 6

the recently-opened Rulemaking regarding DR issues – R.07-01-041 – the CPUC will, in addition to 7

addressing other DR issues, set and potentially expand PDR goals for 2008 and beyond.218 8

b) How Demand Response Impacts PPBU 9

PPBU must be able to accurately track and model how PDR is impacting SCE’s 10

net power needs, i.e., how much power will need to be generated and/or procured. Currently, SCE has 11

Critical Peak Pricing, Capacity Bidding and Demand Bidding programs underway. Load aggregators 12

are now allowed to create demand response blocks from individual consumers (participating in the 13

aggregation program). Under the new market rules of MRTU, the location of the PDR impact will 14

affect SCE’s power costs due to Locational Marginal Pricing, as well as the Company’s costs for 15

congestion management and resource adequacy. An effective PDR program may also become, in effect, 16

the equivalent of a dispatchable generation resource. 17

Given the developmental nature of the current DR environment, it is not possible 18

to predict the full extent of DR’s impact on the entire spectrum of PPBU’s operations. However, it is 19

clear that the following PPBU functions will be impacted: 20

• Long term resource planning, 21

• Short term dispatch planning, 22

• Risk control, and 23

• Position reporting, 24 218 Due to the current uncertainties surrounding the scope of the demand response program goals and rules to be established

in the ongoing demand response rulemaking, and the anticipated actions to be taken by the CPUC in 2007 and 2008 with respect to establishing such goals and rules, SCE’s Application for this General Rate Case includes a request to update its capital expenditure forecast relating to the Demand Response project during the update phase of this proceeding.

242

c) The Demand Response Project 1

The anticipated increase in PDR programs will, in aggregate, result in sufficient 2

power volumes to require PPBU to closely monitor (including in real-time) the power reductions from 3

the programs. PPBU will also require analytical tools to value the impact of PDR programs on 4

wholesale energy activities. PDR will impact PPBU systems in demand forecasting, energy planning, 5

and energy operations. 6

The DR project concentrates on the application needs for augmenting PPBU’s 7

tracking, monitoring, planning and valuation capabilities. PPBU anticipates that there will be 8

modifications to Entegrate (PPBU’s ETRM), PPBU’s short-term dispatch and long-term planning 9

models, and position reports to accommodate PDR as a resource for participating load. 10

R.07-01-041 will help to better define the scope and specifications of this project. 11

The rulemaking has been initiated to: 12

• Establish protocols for estimating the load impacts of PDR programs, 13

• Establish methodologies to determine the cost-effectiveness of PDR 14

programs, 15

• Set PDR goals for 2008 and beyond, 16

• Develop rules for goal attainment, and 17

• Consider modifications to PDR programs to support CAISO in incorporating 18

PDR into market design.219 19

PPBU awaits further clarification from the CPUC in R.07-01-041 regarding the 20

PDR goals and any rule changes for DR programs generally.220 Once the CPUC develops PDR goals for 21

2008 and beyond, including the rules for goal attainment and the protocols for establishing load impacts, 22

PPBU will be able to develop the specific components related to the high-level project requirements 23

219 Assigned Commissioner and Administrative Law Judge’s Scoping Memo and Ruling in R.07-01-041, issued April 18,

2007 (Scoping Memo). 220 Under the schedule provided in the Scoping Memo, workshops related to 2008 and 2009-2011 goals for DR programs

are scheduled to occur throughout 2007, with CPUC decisions relating to the goals scheduled to be adopted no earlier than February 2008 (for 2008 goals) and March 2008 (for 2009-2011 goals), respectively. Scoping Memo, at 12-13.

243

described above and more clearly define the scope of its DR capitalized software project. PPBU’s best 1

estimates for this project, given the information currently available and the schedule set for R.07-01-2

041, are provided below. 3

d) Vendor Selection Process 4

Once the project scope is better defined in light of determinations made in R.07-5

01-041, PPBU will determine if it will need outside vendor assistance to complete the project. If so, the 6

vendors will be evaluated based on the following criteria: 7






e) Project Costs and Schedule 13

As described above, the details of the programs are not fully defined at this time. 14

PPBU assumes that future DR programs will elicit responses from multiple customer classes and employ 15

a variety of different delivery mechanisms. This means that data will need to be collected and 16

interpreted from multiple sources and at varying intervals. Given the potential number of functionalities 17

required and integration points that may be involved in this project, we anticipate that this will be a High 18

Complexity COTS project. The estimate for this system is $4,480,000.221 PPBU anticipates that this 19

project will begin and be completed in 2009. 20


244

Table VI-45 Demand Response Project



2009 $4,480,000

Total $4,480,000

Appendix A

Witness Qualifications

A-1

SOUTHERN CALIFORNIA EDISON COMPANY 1

QUALIFICATIONS AND PREPARED TESTIMONY 2

OF EDWARD ANTILLON 3

Q. Please state your name and business address for the record. 4

A. My name is Edward Antillon. My business address is 2244 Walnut Grove Avenue, 5

Rosemead, California 91770. 6

Q. Briefly describe your present responsibilities at the Southern California Edison Company. 7

A. I am a Senior Manager in Business Process and Technology Integration (BP&TI) within 8

the Transmission & Distribution Business Unit (TDBU). My duties include the 9

development, design and implementation of major technology or process improvement 10

initiatives that provide direct on-going improvement and operational efficiencies for 11

Power Delivery’s field work forces. 12

Q. Briefly describe your educational and professional background. 13

A. I have a Bachelors of Science degree in Business Administration from University of 14

Phoenix and a Masters in Business Administration from Claremont Graduate University. 15

I joined SCE in August 1983 and have held various positions in the company including: 16

Journeyman Linemen, Electrical Crew Foremen, General Foremen, General Supervisor, 17

Technical Specialist/Scientist, Area Manager, Supply Chain Manager, Oversight and 18

Quality Assurance Manager, and currently, a Senior Manager in BP&TI as described 19

above. 20

Q. What is the purpose of your testimony in this proceeding? 21

A. The purpose of my testimony in this proceeding is to sponsor Exhibit SCE-05, Volume 3, 22

entitled IT Capitalized Software, as identified in the Table of Contents thereto. 23

Q. Was this material prepared by you or under your supervision? 24

A. Yes, it was. 25

Q. Insofar as this material is factual in nature, do you believe it to be correct? 26

A. Yes, I do. 27

A-2

Q. Insofar as this material is in the nature of opinion or judgment, does it represent your best 1

judgment? 2

A. Yes, it does. 3

Q. Does this conclude your qualifications and prepared testimony? 4

A. Yes, it does. 5

A-3



OF KEVIN R. CINI 3


A. My name is Kevin R. Cini, and my business address is 2244 Walnut Grove Avenue, 5



A. I currently hold the position of Vice President of SCE’s Energy Supply and Management 8

(ES&M) Department. I have held this position since February 2007, and was previously 9

the Director of ES&M since October 1997. In this capacity, I oversee a department of 10

approximately 100 SCE employees. Although Department responsibilities have changed 11

over time, current major responsibilities include: purchasing electrical energy and 12

capacity to serve SCE’s retail load; selling surplus power in the wholesale market; buying 13

natural gas and gas transportation and storage for SCE generating resources and for 14

CDWR contracts that have been allocated to SCE; hedging gas price risk; optimizing 15

SCE’s generation portfolio in short-term markets; conducting longer term portfolio 16

development planning (principally in the 1- to 5-year horizon); developing various 17

forecasts supporting procurement and operations (such as load and price forecasts); 18

scheduling power and gas; administering SCE’s power and gas contracts, including 19

resolving contract disputes; maintaining compliance with various CPUC and FERC 20

requirements related to procurement, operations, market behavior, information sharing, 21

etc.; and participating in CPUC, CEC, CAISO, CDWR, FERC and other proceedings or 22

stakeholder processes in which procurement operations or costs could be impacted. 23


A-4

A. I have a Bachelor’s degree in Chemistry and a Master’s degree in Business 1

Administration from the University of California, Irvine. I served in the U.S. Navy from 2

1977 to 1981 as a nuclear-trained submarine officer. 3

I have been employed by SCE since 1981. Initially, I was assigned to the Chemistry 4

Section at San Onofre Nuclear Generating Station. I served as Supervisor of Chemistry 5

at Unit 1 from 1982 to 1987. I have worked in ES&M and predecessor departments since 6

1987, holding positions of increasing responsibility. My initial responsibilities were in 7

gas regulation. Beginning in 1991, I was responsible for development, negotiation, and 8

administration of long-term gas supply, transportation, and storage contracts. In July 9

1993, I assumed responsibility for the administration of SCE’s coal contracts. In 1996, I 10

assumed responsibility for all of SCE’s gas regulatory functions and the negotiation and 11

administration of long-term power contracts. Up until January 1, 2004, ES&M has been 12

part of the Generation Business Unit. As of that date, ES&M became part of the new 13

Power Procurement Business Unit (PPBU). Responsibility for the coal contracts function 14

has remained with the Generation Business Unit and as of January 1, 2004 resides outside 15

of ES&M. ES&M’s back office responsibilities were assigned to a new PPBU Finance 16

department beginning in 2005. 17



entitled IT Capitalized Software, as indicated in the Table of Contents thereto. 20


A. Yes, it was. 22


A. Yes, I do. 24

A-5


judgment? 2

A. Yes, it does. 3


A. Yes, it does. 5

A-6



OF TRACY M. FELIX 3


A. My name is Tracy M. Felix, and my business address is 300 N. Lone Hill Avenue, San 5

Dimas, California 91773. 6


A. I am the manager of Credit & Payment Services operations for Southern California 8

Edison. 9


A. I received my Bachelor of Science degree in Business Administration from the University 11

of Riverside. I have worked for SCE for 16 years. I have held positions in the Customer 12

Communications Organization, Billing Organization, Direct Access Project Management, 13

Consumer Affairs and Credit and Payment Services. 14





A. Yes, it was. 19


A. Yes, I do. 21


judgment? 23

A. Yes, it does. 24


A. Yes, it does. 26

A-7



OF JOHN FOULK 3


A. My name is John Foulk, and my business address is SCE General Office #2, 2255 Walnut 5

Grove, Rosemead California 91706. 6

Q. Briefly describe your present responsibilities at the Southern California Edison Company 7

(SCE). 8

A. I am Director of the Information Technology Operations Division which maintains the 9

SCE’s computing and network environment as well as providing information technology 10

support to all 14,000 SCE employees. In that capacity, I have the responsibility of 11

providing strategic direction for delivering reliable and available wireline and wireless 12

computing, voice, and data services in support of Company’s electric utility and general 13

business operations. These services include telephony; two-way mobile radio; 14

transmission and distribution grid control network; personal devices such as pagers, 15

Blackberrys and cellphones; help desk and break fix services, moves/adds/changes, 16

disaster recovery, network monitoring, production change control, and capacity planning, 17


A. I received my Bachelor of Science degree in Engineering at the California Maritime 19

Academy in 1971. I received my Project Manager Certification from the University of 20

California, Irvine in 1999. I joined the Nuclear Information Services Division at SONGS 21

as a contractor in 1984. I took a permanent position as the Supervisor of the Data 22

Engineering Group in 1986. I received numerous step promotions and was hired as the 23

General Manager of Information Technology Application Services group in 1999. In 24

2006 I was elected to my current position as the Director of the Information Technology 25

Operations Division. Prior to joining Edison I was employed with National Steel & 26

A-8

Shipbuilding Company (NASSCO) in various capacities within their engineering 1

department, marketing department and contract management department. Prior to 2

NASSCO I was employed by Westinghouse Corporation as an engineer in support of the 3

U.S. Polaris to Poseidon nuclear submarine conversion program. 4


A. The purpose of my testimony in this proceeding is to sponsor the portions of Exhibit 6

SCE-5, Volume 2, Information Technologies O&M/Capital, and SCE-5, Volume 3, 7

Information Technologies Capitaized Software as identified in the Table of Contents 8

thereto. 9


A. Yes, it was. 11


A. Yes, I do. 13


judgment? 15

A. Yes, it does. 16


A. Yes, it does. 18

A-9



OF STUART R. HEMPHILL 3


A. My name is Stuart R. Hemphill, and my business address is 2244 Walnut Grove Avenue, 5


Q. Briefly describe your present responsibilities at Southern California Edison Company 7

(SCE). 8

A. I am the Director of the Renewable and Alternative Power Department of the Southern 9

California Edison Company. 10


A. I received a Bachelor of Science in Electrical Engineering from California State 12

University, Fullerton, in 1988 and a Master’s degree in Business Administration from Cal 13

Poly, Pomona, in 1995. 14

From 1986-1994, I worked in Electric System Planning in the Transmission Planning, 15

Supply Planning, and Resource Strategies sections. I was responsible for studying 16

transmission, performing production cost modeling, and project analysis. I performed 17

resource planning and cost-effectiveness analysis for the Biennial Resource Plan Update 18

(BRPU). I performed studies in integrated planning, integrated bidding, and addressed 19

other resource planning issues. I also performed economic and operational studies and 20

helped develop SCE’s long-term resource plan. 21

From 1994 through September 2000, I worked at Edison International’s Strategic 22

Planning and New Business Development group, where I helped evaluate business 23

initiatives for Edison International’s companies. These initiatives included: new 24

business startups, acquisitions, performance improvement programs, and alternative 25

operating strategies. 26

From September 2000 through October 2002, I served as Director of Business 27

A-10

Development of SCE, where I evaluated a variety of opportunities for the Company. 1

In November 2002, I became Director of Resource Planning and Strategy. In this 2

position, I directed the development of long-term resource plans for SCE. I directed the 3

analysis of demand response, energy efficiency, and advanced metering. I directed the 4

development of SCE’s 2003 resource plan, 2004 Long-Term Procurement Plan, and the 5

need and cost-effectiveness analysis of Mountainview, San Onofre Steam Generators, 6

Devers Palo Verde 2 transmission line, Devers Palo Verde 1 Series Capacitor Project, 7

and SCE’s 2003 and 2005 Renewables solicitations. 8

In March 2006, I was appointed the Director of Renewable and Alternative Power 9

(formerly QF Resources). I oversee the management and administration of SCE’s 10

existing QF and renewable contract portfolio and the origination of new renewable and 11

alternative power contracts. I also oversee the interconnection agreements for customer-12

based generation, including distributed generation, solar photovoltaic, and small wind 13

facilities. 14





A. Yes, it was. 19


A. Yes, I do. 21


judgment? 23

A. Yes, it does. 24


A. Yes, it does. 26

A-11



OF KENNETH PICKRAHN 3


A. My name is Kenneth Pickrahn, and my business address is 2244 Walnut Grove Avenue, 5



A. I am currently the Direct of Finance for the Power Procurement Finance Department. I 8

have held this position since January of 2005. In this capacity I oversee a staff of about 9

55 individuals. The Finance Department supports both the Energy Supply and 10

Management, Renewable and Alternative Power, and Market Strategy and Resource 11

Planning department and performs all settlement, payment, accounting, budgeting, meter 12

management, business process and system development, and administrative functions for 13

the Power Procurement Business Unit. 14


A. I have a Bachelor’s degree in Business Administration from Central Michigan University 16

and a Master’s degree in Business Administration from Michigan State University. 17

I previously held banking and treasury management positions with Bank of America and 18

The Flying Tiger Line from 1982 through 1986. I began my career with SCE in 19

December of 1986 and held various Treasury and finance related positions. In 1996 I 20

joined Edison Source, a subsidiary of Edison International, and later became Vice 21

President, Treasurer, and Chief Financial Officer for each of the Edison Enterprises 22

companies, which were also subsidiaries of Edison International. In 1999, I returned to 23

SCE to help develop the Edison Carrier Solutions department which provides wholesale 24

telecommunications services within SCE as a Competitive Local Exchange Carrier. 25


A-12




A. Yes, it was. 4


A. Yes, I do. 6


judgment? 8

A. Yes, it does. 9


A. Yes, it does. 11

A-13



OF MICHAEL L. PINTER 3


A. My name is Michael L Pinter, and my business address is 4910 Rivergrade Road, 5

Irwindale, California 91706. 6


A. I am the Director of Software Development and Maintenance. In this capacity, I am 8

responsible for the Development and Maintenance of the Application Software portfolio 9

for Southern California Edison. 10


A. I received my Associate of Arts degree in Marketing from Mt. San Antonio Jr. College in 12

June 1977. I received a Bachelor of Arts degree in Business Administration from 13

University of Redlands in 1981. I have worked for Southern California Edison for 29 14

years in various capacities. The more recent positions included Manager of Inventory 15

Management from 1985 to 1991, General Manager of Client Device Services from 1991 16

to 1995, General Manager of Computing Services from 1995 to 1999 and Director of 17

Infrastructure Services from 2000 to 2006. Effective May 1, 2006, I assumed my current 18

position. 19


A. The purpose of my testimony in this proceeding is to sponsor the portions of Exhibit 21

SCE-5, Volume 2, entitled Information Technology (IT) O&M Overview, SCE-5, 22

Volume 2, entitled Software Development & Maintenance (SDM), SCE-5, Volume 2, 23

entitled Incremental O&M for New Software Applications, and SCE-5, Volume 3, 24

entitled Software Asset Management. 25

A-14


A. Yes, it was. 2


A. Yes, I do. 4


judgment? 6

A. Yes, it does. 7


A. Yes, it does. 9

A-15



OF SOLOMON TESSEMA 3


A. My name is Solomon Tessema, and my business address is 4910 Rivergrade Road, 5

Irwindale, California 91706. 6


A. I lead the Technology and Risk Management organization in IT which is responsible for 8

technology planning, systems engineering, information security, and business continuity 9

planning. 10


A. I was trained as an electronics and computer engineer with a graduate degree. I have 12

more than 28 years of experience in the Electronics, Telecommunication, and 13

Information Technology industries. Over my career, I have assumed progressively 14

advanced positions as field engineer, project engineer, supervising engineer, middle 15

manager, senior manager, and now an SCE Executive with broad span of people, 16

processes, technology, and change leadership responsibilities.. 17





A. Yes, it was. 22


A. Yes, I do. 24


judgment? 26

A. Yes, it does. 27

A-16


A. Yes, it does. 2

A-17



OF RUSSELL G. WORDEN 3


A. My name is Russell G. Worden, and my business address is 2244 Walnut Grove Avenue, 5



A. I am presently a Director of Regulatory Affairs in Edison’s Regulatory Policy & Affairs 8

Department, and the Test Year 2009 General Rate Case Manager. My responsibilities 9

have previously included management of SCE’s 2003 and 2006 general rate cases. 10


A. I received an Associate of Arts degree from Cabrillo College, in Aptos, California in 12

1974. I graduated from San Francisco State University in 1977 with a Bachelor of Arts 13

degree in Political Science, cum laude. After college, I joined the Washington, D.C. staff 14

of U.S. Senator Richard Stone (D-FL) where I served as a Legislative Aide until 15

December 1980. From January 1981 until March 1985, I served as a Legislative 16

Assistant to then Congressman Ron Wyden (D-OR). In March 1985, I joined the 17

Washington, D.C. office of Southern California Edison as a Governmental Affairs 18

Assistant, and in May 1988, I transferred to Edison’s Regulatory Policy & Affairs 19

Department. I was promoted to my current position in February 2006. 20





A. Yes, it was. 25

A-18


A. Yes, I do. 2


judgment? 4

A. Yes, it does. 5


A. Yes, it does. 7

information technology volume 3 â€“ capitalized software

Documents