2018 General Rate Case

Transcription

1 Application No.: A.1-0- Exhibit No.: SCE-0, Vol. Witnesses: T. Walker (U -E) 01 General Rate Case Information Technology (IT) Volume Customer Service Re-Platform Before the Public Utilities Commission of the State of California Rosemead, California September 1, 01

2 SUMMARY This volume describes SCE s proposed Customer Service Re-Platform project, which includes forecast expenditures of $0.0 million (nominal). This project is necessary to replace SCE s obsolete customer service technology portfolio, including the Customer Service System mainframe billing system. The Customer Service Re-Platform O&M costs and benefits of $1. million and $. million that are described in this volume are included in the respective FERC activities within SCE-0 and SCE-0, Volume 1 testimonies. Customer Service Re-Platform Capital Expenditures Forecast (Nominal $million)

3 SCE-0: Customer Service Re-Platform Table Of Contents Section Page Witness I. CS RE-PLATFORM OVERVIEW...1 T. Walker II. EXPECTED ELECTRIC UTILITY CUSTOMER SERVICE OPERATING ENVIRONMENT... III. SCE S CURRENT CUSTOMER TECHNOLOGY PORTFOLIO... IV. CUSTOMER SYSTEMS FAILURE RISK... A. Current Mainframe System Challenges... B. Systems Obsolescence Drives Maintenance Costs and Impacts Customers... C. On-Going Systems Modifications Increase Cost and Risk Over Time... V. CS RE-PLATFORM APPROACH...1 A. Description of CR&B Modules...1 B. Technology Impacts...1 C. Alternatives Considered...1 D. Benchmarking Against Peer Utilities...1 VI. PROJECT SCOPE AND SCHEDULE...1 A. Description of the Project Phases Assessment.... Plan.... Analyze.... Design.... Build.... Test.... Deploy.... Stabilize... i

4 SCE-0: Customer Service Re-Platform Table Of Contents (Continued) Section Page Witness B. Project Schedule... VII. DESCRIPTION OF SAP CR&B SYSTEM COSTS... A. Estimating Method... B. Forecast Expenditures Capital Expenditure Forecast... a) SCE Labor... b) Non-labor...1 (1) Non-SCE Labor...1 () Hardware/Software... c) Project Complexities... d) Delivery Contingency.... O&M Expenditure Forecast... a) SCE Labor... (1) IT... () Staff Augmentation... b) Non-labor... (1) IT Non-Labor... () CCC Staff Augmentation Contract Services... () RSO Staff Augmentation Contract Services...0 VIII. DESCRIPTION OF SCE S BENEFIT COST METHODOLOGY FOR CS RE-PLATFORM...1 A. Benefit/Cost Methodology...1 B. Project Benefit Assumptions... -ii-

5 SCE-0: Customer Service Re-Platform Table Of Contents (Continued) Section Page Witness C. Identification of Total Costs Over the Project Life... D. Identification of Total Benefits Over Project Life Direct Cost Savings by Year.... Avoided Cost Savings by Year... E. Benefit/Cost Analysis... IX. DESCRIPTION OF CS RE-PLATFORM RISK ANALYSIS...0 A. Risk Identification and Risk Statements Risk Identification...0. Risk Statements...0 B. Current Residual Risk Evaluation Frequency Estimation.... Impact Level Estimation... a) Safety... b) Service Reliability... c) Customer Experience... d) Compliance... e) Financial... C. Driver Analysis... D. Planned Residual Risk Evaluation... E. Risk Analysis Challenges and Next Steps... -iii-

6 I. CS RE-PLATFORM OVERVIEW This exhibit supports SCE s proposed Customer Service Re-Platform capitalized software project (CS Re-Platform). The CS Re-Platform project will implement a new customer relationship and billing system that will perform several critical customer-service-related functions, such as generating customer bills and providing account management, overall customer care, credit and collections and account receivables. The CS Re-Platform project is needed to meet changing customer needs and to replace legacy systems that are outdated, obsolete, costly to maintain, and have increasing risk of failure. SCE forecasts nearly $0 million in capital from 01 through 00 to plan, analyze, design, build, test, and deploy this new system. These expenditures are shown in Table I-1 below. SCE also forecasts $. million of O&M in the Customer Service and Information Technology (IT) Organization Units (OUs) to implement and stabilize the new CS Re-Platform system. This project will lead to the retirement of SCE s legacy Customer Service System (CSS), originally designed and built beginning in the s using now-obsolete technology. CSS performs essential customer-service-related functions including customer account management, credit and collections, and accounts receivable services for our five million customers. 1 When the new system is operational in early 00, nearly 0 percent of SCE s existing outdated Customer Service technology portfolio will be replaced with an integrated and more efficient system that will provide greater flexibility to adapt to changing business needs using modernized technology. Table I-1 Customer Service Re-Platform Forecast (Nominal $ millions) Year Total Capital Forecast $.0 $1.00 $. $.0 $ As part of the analysis we conducted to support the decision to re-platform, potential savings have been identified that will be achieved once the CS Re-Platform is operational. These savings are 1 Refer to SCE-0, Ch. I for additional information on the number of SCE customers. Refer to WP SCE-0, Vol., pp. 1- for a list of 0 applications and applications for replacement. 1

7 described in Section II.G as part of a discussion of benefits reflected in SCE-0 and SCE-0. The major benefits of the CS Re-Platform include: Decommissioning of the obsolete, mainframe-based CSS and related subsystems, Discontinuing the reliance on aging infrastructure and applications software languages that are no longer being used in industry, Alleviating system failure risks and ongoing upgrade and maintenance costs associated with continuing the use of obsolete and aging infrastructure, Reducing the rate and impact of customer system incidents, Providing more efficient ways for customers to interact with the company, Lowering operating costs by $1. million per year for this rate case period, and Integrating with the company s SAP system, which is the platform SCE uses for finance, human resources, supply chain, work management, and governance. Reduce dependency on a scarce few resources on a proprietary system and dated technology. We have included an analysis conducted by Infosys, SCE s application maintenance provider, of the feasibility of sustaining the current Customer Service technology portfolio. Infosys also provided recommendations for the timing of decommissioning and replacing current systems, given the current status of those systems and the SCE s needs. This analysis is discussed further in Section III. In SCE s 01 GRC, SCE s customer service model included three key components for engaging customers: (1) energy solutions, () intelligent delivery and energy advisory services, and () effective and enabling customer interactions. This model now forms the foundation for simplifying the customer experience and advancing operational and service excellence. Additionally, incorporating a modernized foundation for the Customer Service technology portfolio will enable SCE to provide for the future needs of customers to become more active in their energy solutions. As discussed in this exhibit, the CS Re-Platform investment is critical to achieve the Customer Service strategy, and follows SCE s overall IT strategy to simplify customer transactions, streamline systems, and managed obsolete software using the principles of Software Asset Management (SAM). See A (SCE s 01 GRC), Exhibit SCE-0, Vol. 1, pp. -1 for additional information on SCE s Customer Service models.

8 II. EXPECTED ELECTRIC UTILITY CUSTOMER SERVICE OPERATING ENVIRONMENT As discussed in Exhibit SCE-01 and further detailed in Exhibit SCE-0, Customer Service, the electric utility industry environment continues to evolve as public policy continues to encourage more options for customers to participate in energy solutions. As more choices become available for customers to participate in energy production, storage, and demand-side management programs, SCE has developed a customer service strategy that will allow SCE to support its customers in an efficient manner. A key component of this strategy is modernizing the existing Customer Service technology portfolio to deliver simple and efficient solutions to address increasing customer needs and expectations. Customer participation in the grid through distributed generation, energy efficiency, demand response, and energy storage is expected to increase at a rapid pace. For example, since 0, SCE has experienced on average a 0 percent per year increase in the number of Net Energy Metering (NEM) applications that it receives from customers. This trend for NEM is expected to continue, and comparable impacts are expected in other areas such as the mandatory implementation of default timeof-use rates for residential customers, zero net energy standards, and electric vehicle adoption. As such, SCE must be able to support this growing customer demand. We need appropriate customer care systems in place to provide accurate program information to customers, and allow for simple, efficient ways for customers to enroll in programs and rates and participate in the grid and energy solutions that make sense for the customer. In addition, expanding Community Choice Aggregation (CCA) in SCE s service territory is expected to continue, which will add additional complexity to a wide range of customer service transactions handled by SCE s systems. Given the current trends for the evolving electric utility industry and the increasing demand from customers for simple and efficient ways to conduct customer service transactions, a key focus of SCE s customer service strategy is to provide the capabilities for customers to experience efficient self-service transactions and provide accurate information that will allow customers to participate in grid and energy Refer to SCE-0, Chapter I.A. on industry trends. Refer to WP SCE-0, Vol., pp.-0 for additional information on industry changes from A CIS Survey and Industry Perspective, presented by TMG Consulting at CS Week on April, 01. Refer to SCE-0, Chapter IX for more information regarding the NEM activities funded in this GRC.

9 solutions. To support these goals, it is critical that SCE invest in a new Customer Service technology platform that will improve the integration of the proposed Customer Service software projects (i.e., SCE.com Strategic Upgrade/Stabilization, Digital Customer Self-Service, and Alerts and Notifications), to replace the majority of SCE s current Customer Service technology portfolio. Even absent this changing electric utility customer service environment, the outdated design and limited resources with knowledge of aging components of the Customer Service technology portfolio make it difficult to make system modifications to meet SCE and customer needs. Without the CS Re- Platform project and related efforts to replace obsolete systems, SCE will incur higher costs for making the needed system changes and will have an increased risk of system failures with each change. Information by TMG Consulting shows that SCE is not unique in this situation. The TMG Consulting information demonstrates that there is a rising concern by utilities nationwide that their customer systems are becoming obsolete due to their age and inability to meet rising customer concerns and advances in technology. The TMG Consulting information also shows that percent of the utilities surveyed have either replaced their CIS in the last six years ( percent) or plan to replace their CIS in the next four years ( percent). These challenges are described further in Chapter III. Refer to SCE-0, Chapter I regarding SCE s Customer Service strategy. Refer to SCE-0, Vol., Capital Software Projects, for additional details regarding other Customer Service Capitalized software projects. Refer to WP SCE-0, Vol., pp. 1 and, A CIS Survey and Industry Perspective presented by TMG Consulting at CS Week on April, 01, for additional information on CIS replacements in the industry.

10 III. SCE S CURRENT CUSTOMER TECHNOLOGY PORTFOLIO This chapter describes SCE s current Customer Service technology portfolio, the significant challenges that the outdated systems face in meeting current business demands, and the need to replace critical systems to effectively reduce risk and perform in the future operating environment. The current Customer Service technology portfolio comprises over 0 applications, at the core of which is SCE s CSS system, a highly-customized mainframe-based application designed in the s, which has been continuously modified over the last years. SCE s legacy applications are highly complex and interdependent to deliver critical customer service functions, such as billing and energy-usage management, customer care, outage communications, and demand-side management. As technology has advanced and with the introduction of new business functions such as smart meter data collection and digital self-service, the sub-systems and interfaces to CSS have become more complex and concurrently dependent upon both older and newer technologies. An increasing number of the legacy systems are becoming outdated or obsolete, which increases the risk of failure. Components of the customer service subsystems reside on outdated technology architecture, an aging infrastructure, and application system code that is no longer taught in computer science classes. Over time, continued modification of the legacy applications has resulted in degraded system performance and increased complexity and manual intervention to maintain them. The Customer Service technology portfolio has evolved to become a complicated web of interrelated systems. Figure III-1 and Figure III- below show the enormity of the complex interrelationships and dependencies for the Customer Service technology portfolio. Refer to WP SCE-0, Vol., pp. 1- for additional information on age of applications. Refer to WP SCE-0, Vol., pp. - for additional information on risks of system failure from Infosys Customer Service Sustain Legacy Assessment Study.

11 Figure III-1 Legacy CS Platform Architecture (Part 1 of ) 1 1 Refer to WP SCE-0, Vol., pp. - for a larger version of Figures III-1 and III-.

12 Figure III- Legacy CS Platform Architecture (Part of ) 1 System obsolescence and failure risk, coupled with difficulty in modifying and maintaining customer systems, have hampered SCE s ability to meet current and future business needs. In light of these concerns, in August 01 SCE requested that Infosys, SCE s current application maintenance provider, assess the feasibility of sustaining the current Customer Service technology portfolio. The

13 assessment included analyzing SCE s current technology portfolio characteristics, comparing SCE s systems with other utilities of similar size, and evaluating the risk and costs of sustaining the current legacy systems. Infosys analyzed the technology risk associated with applications becoming unstable or non-supportable, operations risks including the likelihood of occurrence and the severity of potential systems outages, and transformation risks associated with the ability to implement new business capabilities. These issues are described further in the next section of this exhibit. The assessment concluded with a recommendation that SCE transition to a more modern and agile customer technology platform no later than The recommendation was based on the outdated and obsolete software and hardware platforms still in use at SCE, high incident and problem counts within the Customer Service technology portfolio, significant maintenance and development effort to make system changes, the inability to support future Customer Service requirements, and the increased systems fragility and risk of failure. SCE had previously planned to replace the core of its customer systems as part of the Enterprise Resource Planning (ERP) program in 00. However, the effort was placed on hold and removed from scope due to the Commission-adopted Edison SmartConnect program that required significant resources and system modifications to the Customer Service technology portfolio in the same timeframe. 1 Refer to WP SCE-0, Vol., p. - for additional information on the transition to a modern platform from Infosys Customer Service Sustain Legacy Assessment Study.

14 IV. CUSTOMER SYSTEMS FAILURE RISK This chapter identifies the challenges and failure risks SCE faces with the existing core utility Customer Service technology portfolio software asset. This chapter provides examples of recent failure events and the impact such events have on customer service operations. In addition, this chapter describes the effects that obsolescence of core utility software assets has on maintenance costs and customer impacts. Finally, this chapter also describes the impacts that on-going modifications to aging systems have on costs and increased risk of failure. A. Current Mainframe System Challenges Mainframe system failures at SCE were rare for several years after CSS was first implemented, but there have been several failure events in the last few years. In 01, there were three mainframe failure events that resulted in impacts to critical customer service functions. Because CSS and the mainframe are at the core of the Customer Service technology portfolio, any failure results in the inability to perform customer billing, payment processing, collections activities, outage reporting to customers, and routine service transactions, including customer self-service on SCE.com. In addition, when the mainframe is unavailable, the Interactive Voice Response (IVR) and Customer Service Representatives (CSRs) cannot access customer account information for handling customer inquiries and requests for service. The complex systems interfaces to CSS serve over,00 users across the Company in Customer Service, Transmission and Distribution, and Finance and Revenue Reporting. Mainframe failures impact these organizations and third parties such as Energy Service Providers and Community Choice Aggregators who rely on SCE usage, billing, and payment data for their revenue processing. One significant mainframe failure event can take several hours or days from which to fully recover. In April 01, SCE s mainframe was unavailable for hours and caused operational impacts across Customer Service for nearly an entire week. Customers could not view their usage and bills or make payments online, a full cycle of over 00,000 bills were delayed, and the Customer Contact Center (CCC) were severely impacted in its ability to effectively respond to customer service requests. In other cases, monitoring of the mainframe performance identified that a catastrophic failure was imminent and the system was proactively made unavailable during peak business hours to avoid prolonged operational and customer impacts. The complex nature of the Customer Service technology portfolio results in systems outages of several hours when emergency and routine maintenance is performed.

15 B. Systems Obsolescence Drives Maintenance Costs and Impacts Customers Besides mainframe failures, other components of the aging Customer Service technology portfolio have frequent incidents of business-impacting events, resulting in degraded performance to both users and customers. 1 These problems drive the majority of IT maintenance incidents even though applications in the Customer Service technology portfolio represent less than 0 percent of the total number of applications at SCE. 1 Approximately 00 incidents a month associated with the current CSS system require intervention by systems maintenance personnel, on top of the close monitoring required to identify potential risks before they become issues. The rate of customer systems incidents is much higher than peer utilities running on more modern platforms. 1 Many of the frequent problems that SCE experience are data-related and require an IT programmer to make changes directly in the CSS databases to release individual accounts and exceptions for billing or for user work queue access. The rate of new accounts and issues requiring intervention sometimes exceeds the ability of IT programmers to clear them for processing, resulting in delayed bills and repeat customer inquiries. More modern systems have built-in safeguards to help ensure data integrity and reduce the reliance on legacy systems knowledge and intervention. Mainframe based systems were common throughout the s, and a limited workforce still exists for technology of that era. However, certain modifications were made to SCE s mainframe and foundational CSS systems that only a handful of knowledgeable personnel understand. Even with fullytrained staff and proactive monitoring, unforeseen systems issues can arise. One example occured in April 01, when SCE had no other viable option but to engage a former employee to lead the recovery of the mainframe, because the on-site team could not resolve the problem without external support. As SCE and its maintenance vendor inevitably experience staff attrition, the ability to effectively maintain the legacy customer systems will continue to deminish. 1 An incident is any event that is not part of the standard operation of a service that causes or may cause an interruption to or reduction in the quality of that service. 1 Refer to WP SCE-0, Vol., pp. - for additional information on IT maintenance incidents from Infosys Customer Service Sustain Legacy Assessment Study. 1 Refer to WP SCE-0 Vol., pp. - for additional information on the rate of customer system incidents from Infosys Customer Service Sustain Legacy Assessment Study.

16 C. On-Going Systems Modifications Increase Cost and Risk Over Time SCE s customer systems are regularly modified to meet new regulatory mandates and rising customer expectations. Due to the complexity of the customer portfolio, these changes require detailed planning, analysis, design, construction, and testing prior to implementation. Additional time is needed to perform comprehensive cycles of testing to help that the changes will not cause existing functionality to stop working, and that complex interfaces still work properly. With multiple concurrent system changes and limited resources with legacy Customer Service systems knowledge, resulting projects cost more and have longer lead times for delivery. System development timelines typically require at least six months and cost several hundred thousand dollars to develop new rates and functionality. Changes are most often made to some of the oldest portions of CSS, the billing and accountmanagement modules. In 01 alone, SCE is making substantial billing and rate changes to support the 01 GRC Phase II, Residential Rate OIR, Net Energy Metering (NEM) Cost Responsibility Surcharge (CRS), NEM Successor Tariff, and Community Choice Aggregation. The need for more significant system modifications is expected to increase as the electric utility environment continues to evolve with more complex energy choices and solutions as discussed in Chapter II of this exhibit. SCE s current Customer Service technology portfolio is not equipped to meet these future needs and will incur increased costs and risk with each change. CSS and its related systems must be replaced in line with the recommendation to reduce failure risk, decrease system degradation and maintenance costs, reduce customer disruptions, and prepare SCE to meet future operating requirements. 1 In addition, core utility software, such as the Customer Service technology portfolio, becomes obsolete for a number of reasons. For example, software is subject to age-related degradation similar to other core utility system components, such as poles, wires, and transformers. The age of software assets is a key driver for technology obsolescence, as explained by Moore s Law, which states that computers double in speed every months. This profoundly affects application technology, because new application technologies are designed for the increasing computing capacity. In addition, as technology 1 Refer to WP SCE-0, Vol., pp. - for additional information on recommendations to meet future operating requirements from Infosys Customer Service Sustain Legacy Assessment Study.

17 advances, aging software portfolios become more vulnerable to security risks or failure to operate because software vendors limit or no longer support older products. These issues formed the basis for SCE s Software Asset Management (SAM) process, which was first introduced in SCE s 00 GRC. 1 The SAM process established a systematic approach to evaluate and, if necessary, replace aging and obsolete core utility software applications to reduce business risk associated with potential security exposures, and failures resulting from outdated or unsupported technology. The SAM processes and criteria were introduced and adopted by the Commission in SCE s 00, 00, and 01 GRCs. 1 Beginning in SCE s 01 GRC, the SAM processes and criteria appear to have become the accepted method to evaluate an aging technology portfolio. In SCE s 01 GRC, the Commission reaffirmed its approval of SAM projects adopted in the 01 GRC and approved revised forecasts for several projects including Integrated Work Management, Usage Measurement System, and Design Manager Refresh. 0 SCE evaluated the CS Re-Platform project following the SAM criteria adopted by the Commission in these prior GRCs. As discussed in SCE-01, in the 01 GRC, SCE is highlighting an enterprise risk analysis undertaken on a pilot basis for specific programs and projects to date. The complete risk analysis of remaining on the legacy customer systems is described in Section IX of this testimony. 1 Refer to WP SCE-0, Vol., pp. - for additional information on SAM. 1 Refer to WP SCE-0, Vol., pp. -1 for additional information on SAM. 0 D.1--01, pp

18 V. CS RE-PLATFORM APPROACH This chapter describes in detail the approach that SCE took in recommending the CS Re- Platform project that will replace the majority of the applications in the Customer Service technology portfolio. This section identifies the alternatives that SCE considered to address the current system risks and SCE s future business needs. This section also provides comparative data on peer utilities that faced similar situations with implementing large-scale modern customer information systems. In addition to assessing its legacy customer systems risk in 01, SCE undertook an effort to consolidate and optimize its overall technology portfolio. To support this effort, SCE initiated discussions with SAP to review its latest customer relationship and billing ( CR&B ) product suite. A fit/gap assessment was performed to confirm that all of SCE s core customer service business needs could be met through SAP s CR&B product. Because SCE had initially planned to implement SAP s CR&B in 00, a list of previously-identified product maturity gaps and concerns provided business and IT teams with additional context to support their assessment of SAP CR&B. SCE subsequently conducted a technical assessment to confirm the feasibility of SAP CR&B and to identify the optimal timing for replacing its legacy Customer Service applications with a modern SAP-dominant technical architecture. Through a competitive process, SCE selected Accenture, a leading provider of customer information system integration services, to develop a comprehensive technical assessment and provide recommendations. The resulting CS Re-Platform solution, scope, cost, deployment, schedule, and cost/benefit analysis are included in the following Chapters VI through VIII in this GRC application. The CS Re-Platform project will replace the majority of the outdated Customer Service technology portfolio with SAP CR&B modules on a platform that is both flexible and scalable. Minimizing the number of system interfaces will reduce the risk of system failures and technology operating costs. Utilizing SAP-packaged software, SCE will receive regular upgrades, which will also provide SCE with the opportunity to co-innovate and stay connected with technology developments and to meet future business needs. The more simplified and streamlined CS Re-Platform architecture is depicted in Figure V- below. 1

19 Figure V- Future CS Re-Platform Architecture 1 1 A. Description of CR&B Modules The CS Re-Platform solution will primarily be composed of SAP CR&B that will include several solution modules. These integrated solution modules will collectively provide the system capabilities required to deliver customer service business processes. In addition to the SAP solution components, the CS Re-Platform solution architecture will include complementary solution components that will build upon SAP s technical capabilities to deliver targeted business solutions. The CS Re-Platform will include the following key SAP solution modules: SAP Customer Relationship Management and Billing for Utilities - Supports the processes for marketing, sales, and billing of energy and non-energy products as well as the 1 Refer to WP SCE-0, Vol., pp. 1-1 for a larger version of Figure V-. 1

20 management of the related customer service processes. It includes the operation of a call center with support for utility industry-specific sales and service processes, campaign management, opportunity management, account and contact management, and interaction center-based sales support for residential and non-residential customers. This solution module contains the billing engine that will support rate management, billing simulation functions, billing on behalf of a third party, plausibility check functions for billing documents, and bill printing with all related processes. This solution module will also support device management, meter reading, profile management, and customer financials. Most of this functionality is contained in the center part of Figure V- labeled SAP CR&B, interfaced with the Meter & Device related boxes at the lower left and the Self Service boxes on the right. Also includes interfaces with the existing SAP Financial modules. SAP Energy Data Management - Supports the collection and management of energyrelevant data in a central energy data repository, enabling load profiling, complex billing, and energy-settlement processes based on contract terms agreed to with the end producer or consumer. This module provides capabilities for metering and measuring load shapes, settling energy quantities (wholesale purchasing, transmission, and embedded generation), managing schedules and billing intervals, as well as cumulative-consumption customers. A central database supports the import, monitoring, validation, and storing of time-series data. This group of activities is housed mainly in the Meter Data Management Systems (MDMS) interfaced with the data repository BW/Hana shown in the Reporting and Analytics section. SAP Business Intelligence (BI) - To meet the core reporting requirements of a Customer Service organization, SAP BI provides industry-specific reports and analysis scenarios as well as a reporting environment to enable the creation of specialized reports as needed. These activities are represented in the Reporting and Analytics collection of systems. Other SAP-solution modules included in the CS Re-Platform solution architecture include SAP Collaborative Services Management for Utilities, SAP Customer Financial Management for Utilities, and SAP AMI Integration for Utilities. B. Technology Impacts The CS Re-Platform will replace the majority of the applications within the Customer Service technology portfolio to a SAP-dominant solution architecture running on distributed hardware. The mainframe is expected to be decommissioned after full implementation and stabilization of the project. 1

21 Other related applications outside of the core Customer Service mainframe-based applications will also be moved to upgraded platforms. In addition, several non-mainframe applications will move to the SAP suite, reducing the overall number of separate applications that support Customer Service. C. Alternatives Considered When considering the feasibility, strategic drivers, and timing of the CS Re-Platform, a number of alternatives were assessed: Sustain the legacy solution architecture Based upon the recommendation from the assessment conducted by SCE s existing application maintenance provider, Infosys, the alternative to sustaining the legacy technology platform was not a viable option given the obsolescence of the mainframe legacy architecture and the risk of this legacy infrastructure. Alternative (non-sap) solution architecture Based upon SCE s strategy to reduce and simplify the Customer Service technology portfolio while standardizing application infrastructure across the Enterprise, SCE IT determined that a non-sap solution architecture would not be a viable alternative. Defer the project go-live date beyond 00 Based upon the recommendation from Infosys, the CS Re-Platform go-live must be no later than 00. As such, deferring the project go-live beyond this date was not a viable alternative. Implementation options As part of the technical assessment performed with Accenture, two deployment approaches were considered by the CS Re-Platform team: Single Release (CS Re-Platform solution assumption) - The most recent major North American Utilities Customer Information Systems (CIS) implementations have been predominantly single release, in which all data objects and core capabilities are converted at once. Capabilities are fully deployed at one time and typically over a single week or weekend. Benefits of this approach include a shorter stabilization period, reduced data conversion risk, single impact to customer operations, and reduced interface development. Phased (or Multiple Release) - A phased implementation is usually performed when a company wants the ability to evaluate the effectiveness of a new application before rolling it out throughout the business. Phasing may involve the utilization of pilots, for example during global implementations or for companies with multiple operating companies. This deployment option was not 1

22 viable, given the incremental operational disruption this would introduce (relative to a single release deployment approach). D. Benchmarking Against Peer Utilities The decision to move forward with the CS Re-Platform was based on the risks of system obsolescence and the potential for system failures, and SCE s experience with the SAP solution. However, to be prudent, SCE confirmed SAP was the optimum solution and benchmarked other findings against peer utilities and CIS market research. As discussed in Chapter II above, there is an increasing concern by utilities nationwide that their customer systems are becoming obsolete and that percent of the utilities plan to replace their CIS in the next four years. In addition, market research in CIS offerings for electric utilities shows that the size of a utility has a major effect on the utility billing/cis solutions. SCE s volume of customers limits the solution options to Oracle or SAP offerings as these two leading vendors provide comprehensive, modern platforms, but at a substantial cost. SCE examined large utilities that have deployed a CIS solution since 00. In over 0 percent of the cases, SAP was the chosen solution for CIS deployment. CR&B is a leading electric utility industry CIS solution with strengths and ease of integration to our existing ERP environment consistent with SCE s strategy for standardization. Refer to WP SCE-0, Vol., p., A CIS Survey and Industry Perspective, presented by TMG Consulting at CS Week on April, 01, for additional information on utilities with plans for CIS replacements. Refer to WP SCE-0, Vol., pp. -, Navigant Research, Electric Utility Billing and Customer Information Systems, 01, for additional information on CIS solution options available based on utility size. Refer to WP SCE-0, Vol., p. 1 for additional information on utilities CIS deployments. 1

23 VI. PROJECT SCOPE AND SCHEDULE This chapter sets forth the project scope for the CS Re-Platform project and identify each of the phases within the project scope. This chapter also describes the schedule for each of these phases. Although the CS Re-Platform primarily addresses the obsolescence and risk of CSS, the project will impact the broader Customer Service technology portfolio. This includes other Customer Service applications, such as MDMS, SCE.com, Interactive Voice Response (IVR), and Energy Efficiency and Demand Response programs. The analyses conducted by designated process teams created a to-be process model. Ten business processes, in no particular order, will be in scope for the CS Re-Platform, including functions such as: Reporting Conversion Exceptions Account & Receivables Management Product & Program Management Finance Billing & Meter Reading Customer Interaction Device & Field Market Transactions These ten business processes include over 0 sub-processes that are shown in Table VI- and are grouped by business capability. 1

24 Table VI- Process Estimating Factors Initial Count of Sub Processes by Business Capability 1 1 These sub-processes define the scope of the project as each must be designed, built, configured, tested, and documented. Each of the processes and sub-processes will be mapped to a SAP solution. To the extent a process departs from the standard SAP process, changes must be developed within the project. These SAP process changes are commonly referred to as development objects also known as Reports, Interfaces, Conversions, Enhancements, Forms, and Workflow (RICEFW). The number and complexity of the RICEFW objects drive the work needed to implement the solution, and, therefore, drives the cost. Table VI- shows the initial RICEFW counts used to determine the scope for the Project. The table shows the number of each RICEFW by process area. The largest single category of RICEFW is the Interfaces, which highlights the importance of connecting with other systems such as SCE.com, Outage Management (OMS), MDMS, and IVR. As SCE progresses through the project phases, continued refinements will be made to the scope to verify that all the development objects identified are indeed necessary, and that no critical ones have been inadvertently missed in the initial assessment. 1

25 Table VI- Initial RICEFW Counts Line No. Process Area Reports Interfaces Conversions Enhancements Forms Workflow 1 Reporting 1 1 Conversion Exceptions Account & Receivables Management Grand Total 0 Product & Program Management 1 Finance 1 Billing and Meter Reading 1 1 Customer Interaction 1 Device & Field Market Transactions 1 Grand Total SCE s project scope includes resources to configure SAP and to develop the RICEFW objects, hardware and software purchases, facilities and equipment to conduct this work, internal and external labor, training delivery, data cleansing, including both automated and manual conversion, and staff increases to offset operational impacts. Staff augmentation is also included to mitigate against the operational impacts of project go-live. Based on the process areas affected, the Customer Service and IT business areas directly affected by the CS Re-Platform include, but are not limited to: 1 Customer Contact Center (CCC) Revenue Services Organization (RSO) (Billing, Credit and Collections, and Payments) Meter Services Organization (MSO) Strategic Commercial & Industrial, Institutional, Agricultural, & Government and Business Solutions in Business Customer Division (BCD) Refer to WP SCE-0, Vol., p. 1 for a detailed definition of RICEFW. 0

26 Consumer Affairs, Marketing Communications & Digital Customer Experience, Program Development, Launch and Operations, and Program within Customer Programs and Services (CP&S) The Information Technology organizational areas include but are not limited to: Service Management Office and Operations Enterprise Architecture Business Integration & Delivery The CS Re-Platform project will replace over 0 percent of the existing Customer Service technology portfolio. SAP CR&B will interface with approximately 0 percent of the Customer Service technology portfolio that will not be replaced by the project, including but not limited to the following applications: SCE.com and other digital initiatives i.e. Mobile Web SCE.com is not in scope but will require interface connections to the new solution, therefore some design elements of SCE.com will be analyzed within the CS Re-Platform design. MDMS All data from the existing Customer Data Acquisition System (CDAS) system (part of CSS) will be migrated to the new SAP Solution. CDAS will then be retired. However, meter interval data will continue to be maintained and stored in MDMS. T&D Systems All T&D systems that interface with Customer Service such as Outage Management System (OMS) will not be replaced, but will require connecting interfaces. Another critically important scope element is an assessment of the organizations impacted which will drive how we will manage change. Results from our previous large scale system deployments have shown getting the organization ready to accept the new system is critical to having a successful program roll out. A. Description of the Project Phases The CS Re-Platform project is estimated to take 1 months to implement, excluding the early planning phases (see Project Schedule in section B of this chapter). The 1-month implementation is broken down into six distinct phases as shown in Figure VI- below. Each project phase feeds into the next, seeing the solution through from initiation to deployment. These project phases are typical for an SAP CIS project and follow the approach taken on SCE s previous SAP implementations and are further detailed in the upcoming sections. 1

27 Figure VI- CS Re-Platform Redesign Project Phases The project phases are described in the sections below: 1. Assessment The initial phase of the CS Re-Platform began with assessing the current Customer Service technology portfolio relative to SCE s Customer Service and IT operation and technology strategies. This exercise helped determine the high-level target state to be achieved through the CS Re- Platform. This was followed by a Fit-Gap assessment between the current portfolio of systems and an SAP-dominant solution (Customer Relationship & Billing). The Fit-Gap assessment confirmed where the SAP-dominant solution covered current capabilities directly out-of-the-box, and generated an inventory of RICEFW objects for the incremental capabilities required beyond the out-of-the-box solution. Furthermore, this Assessment phase, which is ongoing until the beginning of the Plan phase, will refine the solution and scope assumptions because of the high-level To-Be process design and include the selection of the System Integrator.. Plan The Plan phase will focus on detailed planning of the 1-month effort, including building the detailed work plan, identifying and documenting project assumptions and risks, refining the highlevel solution scope and requirements and establishing the approach, technique and tools to support solution-requirement traceability throughout the project lifecycle. Additionally, this phase will support onboarding project resources and define how to organize the project governance structure. Once the detailed planning is completed, appropriate staffing plans are developed for every activity identified in the detailed planning process so the appropriate people and skills can be on-boarded. This work is expected to take two months and be completed in the third quarter of 01.. Analyze The Analyze phase of the project will focus on understanding and documenting the detailed current-state business processes (As-Is process design), defining and documenting the detailed

28 target state business processes (To-Be process design), defining the business requirements, and developing the solution functional designs. From an IT Architecture perspective, this phase will focus on understanding and gathering technical architecture requirements and defining the target architecture design and system landscape. The output of this phase is a validated list of the RICEFW objects, which will feed into the subsequent Design phase. This will also drive the refinement of the cost and schedule estimates for the remainder of the project. This phase is planned for three to five months to complete.. Design During the Design phase of the project, the detailed business process flows will be broken down into more granular individual activity and steps to determine how the RICEFW objects should be designed to support the defined To-Be business processes. The functional designs developed during the Analyze phase will serve to develop the technical designs for each RICEFW object. In parallel, the project infrastructure, environments, and tools will get set up and the technical architecture will be designed to meet the technical, security, and performance requirements. To prepare for the Test phase, functional analysts will start to document test cases and scenarios, to be further refined and detailed in the next phase. These will feed into the overall Test effort. This phase is planned to take four to six months to complete.. Build The Build phase of the project will begin by refining the customization, integration, and data conversion designs until they are concrete and detailed enough to be built. At this point, each of the RICEFW objects will be developed and areas of the solution that require configuration of the packaged software will be built. Building out RICEFW objects include developing and programming: (1) reports, () interfaces with external systems, () conversions or changes in the standard design, () enhancements that are additional requirements above that which is offered by the standard solution design, () forms that may be used in a business process, and () workflow when the requirements dictate a new flow of how the work in a process is to be done. During this phase, solution components are built and tested, while configuration and custom components are planned for testing in the subsequent phase. Technical environments and production infrastructure are also established. In anticipation for the Test phase, test scripts, test cases, and scenarios are further developed, as well as expected test results to track against. This phase is expected to take seven to nine months to complete.

29 Test During the Test phase, every aspect of the solution will be tested to help ensure that the end-to-end product works as expected. RICEFW objects for every business process identified in the Analyze phase, and further detailed in the Design phase, will be tested for individual and integrated performance. Once integrated testing is completed, the team will prepare and execute the performance test and perform the mock data conversion to test the conversion process. The last step in Test is the completion of User Acceptance Testing, in which the process or business users test the product to help ensure it meets the requirements previously established for their functional areas. Training also begins during this phase to help ensure all future system users are given the foundational knowledge required to perform their day-to-day activities, limiting the impact of deploying a new system on the operations. The phase is expected to take five to seven months to complete.. Deploy Once the system is fully tested, the project will enter the Deploy phase and the effort can shift from building and testing the solution to placing it into service. This occurs through a cutover process, where production is moved from the old system to the new. At this point, the legacy system can be taken out of service and the new system is rolled out to the workforce and deployed across the entire Company. Training continues to be rolled out during this phase, to help minimize impact to operations and ensure proper adoption of the target business processes. Deployment is expected to take approximately five to seven months to complete, leading up to Go-Live in early 00.. Stabilize This phase of the project will focus on two main areas. The first will be helping to ensure the solution performs as expected, from a technological and operational standpoint. Any system issues or defects that may arise once the system is live will be addressed and resolved during this phase. Additionally, the Stabilize phase will extend beyond the Go-Live date to support operations as the new system is deployed. To safeguard against potential negative impacts to operations, Staff Augmentation resources will be brought in to alleviate potential negative impacts to operations, such as increases in call volumes, call handling times, and billing exceptions. B. Project Schedule SCE worked with Accenture to evaluate the implementation schedule options for the CS Re- Platform project. Accenture s recommendation was based on its system integration experience leading SAP CR&B implementations of a comparable scope and complexity across the globe. Many factors

30 informed the recommended project schedule, including (but not limited to) the complexity of the existing Customer Service technology portfolio, the number of impacted applications, organizations, customers, and end users, as well as the specificities of the electric utility industry in California. Based upon Accenture s assessment of these factors, coupled with the project scope, Accenture recommended that the implementation schedule be 1 months in duration (Plan to Deploy). Accenture s recommendation was supported by selected comparable utility customer information system implementations across North America, Europe, and Asia Pacific, highlighted in Table VI- below. Table VI- Selected CIS Implementations For Utilities Implementing the CS Re-Platform project will begin in mid-01 with a completion or go-live date in early 00. As shown in Figure VI- below, the phases of the project include Plan, Analyze, Other Scope abbreviations: BI Business Intelligence; BW Business Warehouse; HANA (from SAP) High Performance Analytic Appliance is an application that uses in memory data base technology allowing the processing of massive amounts of data; AMI Automated Metering Infrastructure; ERP Enterprise Resource Planning; EAM Enterprise Asset Management; Click Scheduling Software for long and short cycle orders; Syclo Mobile application for technicians receiving order requests, updates and status; GRC Governance, Risk, Compliance; MDM Meter Data Management; MAU Mobile Assets Management for utilities.

31 Design, Build, Test, Deploy, and Stabilization. SCE is presently in the assessment phase defining the target state architecture as shown in Figure V- above. The costs and scope in this GRC application reflect the analysis performed during the assessment phase. Additional refinements in scope will continue through Plan, Analyze, and Design through the first quarter of 01. Project go-live is anticipated in early 00 as shown in Figure VI- below. Figure VI- Implementation Schedule By Activity Assessment Plan Analyze Design Build Test Go-Live 00 Deploy Post Go-Live Stabilization

32 VII. DESCRIPTION OF SAP CR&B SYSTEM COSTS This chapter describes the one-time costs for the CS Re-Platform project, from years 01 through 00, which are listed in Table VII- below. SCE estimates the total capital cost will amount to $0.0 million (nominal dollars). Project Operations and Maintenance (O&M) costs are estimated at $. million (constant 01 dollars). The O&M costs have been levelized over the three-year GRC period. Table VII- CS Re-Platform Capital and O&M Forecast ($ millions) Line No. Year Total 1 Capital Forecast (Nominal $) $.0 $1. $. $.0 $0.0 O&M Forecast (Constant 01 $) $0.00 $1.0 $1.0 $1.0 $ A. Estimating Method SCE worked with Accenture to develop the cost estimates for the CS Re-Platform project based upon Accenture s significant experience implementing customer information systems at utilities of comparable complexity and size. As such, Accenture identified 0 distinct estimating factors that SCE needed to consider to develop the cost estimate for the project. A sample of the key estimating factors that influenced the project cost included: Implementation approach Software and hardware sizing Number of concurrent users expected Volume and type of data conversion and retention Number of interfacing systems Number of customers Number of meters and frequency of reads Post go-live stabilization support requirements Refer to WP SCE-0, Vol., pp. 1-1 for a list of key estimating factors.

33 B. Forecast Expenditures Capital Expenditure Forecast The CS Re-Platform costs were defined as part as the Assessment phase of the overall project, which began with a Technical Assessment in mid-01. This Technical Assessment was anchored on a Fit-Gap assessment between the Customer Service Legacy portfolio of applications and an SAP-dominant solution. This Fit-Gap assessment identified the number of objects, and their corresponding complexity, which will be built to complement the out-of-the-box SAP solution to meet Customer Service and IT requirements. Other factors that went into the solution cost estimate include considerations for the current technical architecture complexity, the sourcing mix and associated rates, non-labor costs such as hardware and software requirements, and indirect costs like facilities. The capital and O&M determination for the labor costs followed detailed analysis of the activities to be performed by resource type and role, for each phase of the project, to determine whether the effort for that phase should be capitalized or expensed. Similarly, for the non-labor costs, the capital and O&M determination followed Plant Accounting rules and GAAP. The capital expenditures of $0. million (nominal dollars) for the CS Re-Platform project fall into two main categories, labor and non-labor. The capitalizable portion of the CS Re- Platform costs will be incurred at the start of the Analyze phase in 01. Table VII- illustrates the CS Re-Platform Capital Forecast from 01 through 00. The costs associated with the Planning Phase of this project will be treated as expense.

34 Table VII- CS Re-Platform Project Capital Expenditure Forecast (Nominal $ millions) Line No. Capital Forecast Total 1 Labor SCE Labor $.0 $.00 $.0 $0.0 $1.0 Non-Labor Third Party Contractor Costs $.0 $0.0 $.0 $.0 $0.0 Hardware/Software $0.0 $.0 $.0 Program complexities $. $.0 $.0 $0.0 $.00 Delivery Contingency $.00 $.0 $1.0 $0.0 $.0 Total Program Capital Cost $.0 $1. $. $.0 $ a) SCE Labor These costs comprise the capitalized portion of the CS Re-Platform cost associated with labor and expenses for both internal IT and Customer Service employees across through the implementation. This represents $1. million for the period of 01 to 00. The labor cost is calculated based on the project resource plan applying a blended labor rate that accounts for the different resource profiles and cost rates. The resource sourcing mix considered several factors, including: (1) availability of resources with the required project skillset within SCE s IT and Customer Service organizations, () alignment of IT managed-service-provider expertise with project activities, () System Integrator (SI)-critical roles to support the objective of minimizing project risk, and () industry best practice. To infuse knowledge of SCE business and IT operations into the solution design, it is critical to include SCE subject matter experts throughout the project phases. These resources will play many key roles in the Analyze, Design, Build, Test, and Deploy phases, including but not limited to: 1 Project Management and Project Controls Refer to WP SCE-0, Vol., pp. 1-1 for additional information on capital expenditures.

35 Functional Designers to define the current (As-Is) and target (To-Be) processes Subject Matter Experts (SME) to support the definition of the current (As-Is) and target (To-Be) processes Technology and Solution Architects to manage technical resources (Infrastructure, Security, Data Base Administration, etc.) Integration Coordination to support the integration of the new solution with existing and retained peripheral systems Change Management, including training development, training delivery, and communications, to design and develop training materials and methodology to prepare the organizations for the transition to the new SAP-dominant solution Developers to assess, design, and build the RICEFW objects Data Conversion to support the translation of current legacy-system data to be compatible with SAP s data model Test Execution to support the planning and designing of the testing materials, including test scenarios and test scripts, which will be used to test the new solution The SCE staffing plan is shown in Figure VII- below. Peak staffing occurs during the Build phase in 01, a critical phase of the implementation where functional and technical solution designs are developed and built to create the new solution. This category of costs also includes employee-related non-labor expenses (e.g., office supplies, travel, and meals), calculated as three percent of the direct labor. 0

36 Figure VII- SCE CS Re-Platform Staffing Plan b) Non-labor Non-labor includes the cost of non-sce labor associated with CS Re-Platform implementation activities and software and hardware purchases. Additionally, these costs include estimated costs to account for scope risks and delivery contingency. Each of these is discussed below. (1) Non-SCE Labor This category of costs is $0.0 million. Expenses for non-sce labor ranges from to 0 percent of direct labor, depending on the type of external resource. System Integrator (SI) resources are estimated to incur more extensive travel than the current managed service provider (MSP). As previously described, the staffing plan assumed a sourcing mix between SCE and non-sce labor. As per industry best practice, large scale IT implementations are usually undertaken in partnership with third-party contractors. These resources provide specialized expertise on the product being implemented and assist in designing, configuring, and testing the solution. These non-sce resources will play many different roles in the CS Re-Platform, including but not limited to: System Integrators (SI) and Management Consultants (MC) to advise and support on how best to plan and realize an 1

37 implementation of this magnitude. Their proven methodologies, experience, and lessons learned will support each phase of the implementation by providing relevant frameworks, guidance, and support to the SCE project team. SAP product knowledge, IT project implementation methodology, industry standards, and best practices are just a few of the foundational elements required for SCE to successfully implement the target SAP-dominant solution. SCE has not yet selected system integrators for this project. Software Vendors to provide product-specific expertise to support the integration between those products and the other systems they will interface with, as well as to support core design, configuration, and development activities. Examples of these vendors include: (1) Itron, who provides the Meter Data Management System (MDMS) housing the interval meter data, () Click Software, who provides the scheduling systems to supports Customer Service s Meter Services Organization as well as Transmission and Distribution Work Management, and () IBM, who provides SCE.com, which is the primary interaction point for online customer activity. Managed Service Providers (MSP), who currently support the Legacy technology portfolio, to provide knowledge on the current IT landscape and the integration points between the legacy technology portfolio and the new solution. The MSP resources will also be assigned certain development and configuration roles. This pool of resources may be located offshore or on the project premises. Staff Augmentation resources to assist in the Stabilize phase of the project. As described in the project phases, these resources will help alleviate potential negative impacts to operations associated with introducing a new solution. They will assume training, frontoffice, and back-office support roles throughout the Stabilize phase.

38 Figure VII- below shows the staffing plan for this category of costs. Figure VII- External Resources Staffing Plan by Project Phase () Hardware/Software The hardware and software costs for this project are estimated at $.0 million not including network investments. The hardware costs are estimated at $. million and include upfront hardware purchases. These costs are incurred over the first two years of the implementation, as hardware and software licenses will be necessary to support the Design and Build activities. SCE worked with Accenture to develop the estimate for required hardware, considering both the current SAP landscape and expanding that basis to include the required additional hardware for the new SAP-dominant solution. Based on the joint analysis between SCE and Accenture, as well as SCE s own experience with SAP, it was determined that eight SAP environments will be required. These include: Two Sandboxes, one for business and one for technical uses. The business sandbox will be used to prototype business processes, and the technical sandbox will be used to conduct performance and disaster recovery testing. Development is a critical environment as it is the only port of entry for all changes introduced to the solution. The SAP components are