EXHIBIT 99.476
[GRAPHIC]
[LOGO]
CALIFORNIA POWER EXCHANGE PX SYSTEMS PROPOSAL
[PEROTSYSTEMS LOGO] [ERNST & YOUNG LLP LOGO] [ABB LOGO]
January 14, 1997
Procurement & Materials Management Department
Southern California Edison
8631 Rush Street, G04, 2nd Floor
Rosemead, California 91770
Attention: Ernest W. Schimmelman, C.P.M., NCE
Manager-Contracts
Reference: California Power Exchange PX Systems
RFP No. 2311655
Dear Mr. Schimmelman:
The PX Alliance, consisting of Perot Systems Corporation (PSC), ABB Power T&D
Company Inc. (ABB), and Ernst & Young LLP (E&Y), is pleased to provide the
enclosed proposal for building the PX Systems in response to your RFP No.
Z311655 dated November 1996. Our response also incorporates Addendum No. 1
dated December 27, 1996.
By teaming our respective companies to create the PX Alliance, we bring to bear
a unique blend of experience and know-how as well as the proven collective
capability, talent and extensive skills necessary to provide a comprehensive
and innovative solution for delivering the on-time operation of the PX Systems
for the California Power Exchange. In addition to our industry and
technological expertise and the depth and breadth of superior quality
resources, we also offer the global experience of our combined companies in
power markets. We will work hand-in-hand with the California Power Exchange to
facilitate successful energy market operations by January 1, 1998.
PSC will be the program manager of the PX Alliance, with overall and direct
responsibility for the design, development, testing, installation and
deployment, and potentially the eventual operation of an integrated turnkey
solution for the PX Systems. While PSC will be the primary control contact and
direct interface to the PX, all three parties of the PX Alliance are fully
committed to the delivery and successful implementation of the PX Systems.
The PX Alliance members have a clear and comprehensive understanding of the
monumental task at hand. We have learned from experience as evidenced by our
proven track record in implementing systems for the competitive market
infrastructure of electricity industry restructuring around the world and by
our active ongoing involvement in activities within WEPEX and the California
market.
The proposal that follows details our approach to developing and implementing
the PX system, in response to your RFP. We have attached a listing of the
proposal contents, per your instructions to bidders, Please contact Pat
Gabden at (243) 367-1404 with any questions regarding our proposal. PSC, ABB
and E&Y welcome the opportunity to discuss our proposal with you in greater
detail, and we look forward to working with the Power Exchange.
Sincerely,
/s/ Edward M. Smith /s/ Ralph D. Masuello /s/ W. F. Hunter
- ------------------------- ----------------------- ------------------
Edward M. Smith Ralph D. Masuello William F. Hunter
Vice President General Manager Partner
Perot Systems Corporation ABB Power T&D Company, Inc. Ernst & Young LLP
THE PX ALLIANCE PX SYSTEMS PROPOSAL CONTENTS:
- --------------------------------------------------------------------------------
The PX Systems Proposal submitted by the PX Alliance is presented in two
volumes -- Volume I, the Technical Proposal and Volume II, the Commercial
Proposal. The contents of each are listed below.
TECHNICAL PROPOSAL
Section 1 Executive Summary
Section 2 PX Implementation
Section 3 System Architecture
Section 4 Bidding Module
Section 5 Scheduling and Price Determination Module
Section 6 Publishing Module
Section 7 Settlement Module
Section 8 Billing and Credit Module
Section 9 Administrative Systems Module
Section 10 Project Management
Section 11 PX System Rollout
Section 12 PX Operation
Appendix A Technical Table of Conformance
Appendix B Questionnaire Response
Appendix C Configuration Drawings and Floor Plans
Appendix D List of Deliverables
Appendix E Sample Documentation
Appendix F RPI Experience Forms
Appendix G Biographical Information
Appendix H Preliminary Project Schedule
Appendix I Sample Progress Reports
Appendix J Database Sizing
Appendix K Administrative Systems -- Additional Functional Requirements
COMMERCIAL PROPOSAL
Section 1 Executive Summary
Section 2 Pricing Information
Section 3 Proposed Payment Milestones
Section 4 Maintenance Services
Section 5 Creative Options
Appendix A Terms and Conditions
Appendix B Commercial Table of Conformance
Table of Contents
<Table>
1.0 Executive Summary..................................... 1.1
2.0 PX Systems Implementation............................. 2.1
PX Business Definition....................................... 2.1
PX Business Processes................................. 2.1
Data Architecture..................................... 2.2
Business System Architecture.......................... 2.2
Technology Architecture............................... 2.2
PX System Description........................................ 2.3
Project Management........................................... 2.3
Approach.............................................. 2.4
Description........................................... 2.5
Project Initiation and Planning....................... 2.5
Project Implementation................................ 2.6
Develop Test Plan..................................... 2.7
Subsystem Testing..................................... 2.7
System Integration Testing............................ 2.8
Final Testing......................................... 2.8
Development Hardware......................................... 2.8
Configured development system......................... 2.9
Time/Schedule......................................... 2.9
Production Hardware.......................................... 2.9
[Illegible] Standard Software Development.................... 2.10
Purchase Software Implementation............................. 2.10
Project Schedule............................................. 2.12
Lessons Learned.............................................. 2.13
Optional Joint Study of the Proposed Bidding, Bid Evaluation
and Scheduling Protocol...................................... 2.16
3.0 System Architecture................................... 3.1
System Design Overview....................................... 3.1
Hardware Design.............................................. 3.2
General Replacements.................................. 3.2
Hardware Definition................................... 3.2
Processors............................................ 3.4
Local Area Networking................................. 3.4
Processor Interconnections............................ 3.4
Auxiliary Memory...................................... 3.4
Data Archive Units.................................... 3.4
Printers.............................................. 3.4
Consoles.............................................. 3.5
Video Copiers......................................... 3.5
Other Peripheral Devices.............................. 3.5
Consumable Supplies................................... 3.5
Configuration Characteristics and Availability............... 3.5
Communication................................................ 3.7
User Interface Software...................................... 3.7
Borland Delphi........................................ 3.8
Miscellaneous Support Functions.............................. 3.8
Batch Scheduler and Execution Controller.............. 3.8
Historical Information Management system.............. 3.[Illegible]
Back-Up System............................................... 3.12
</Table>
This document is being provided to the California Power Exchange Systems
proposal evaluation team and is privileged and confidential information. No
part may be reproduced, transmitted or otherwise distributed outside of the
evaluation team without written permission of ABB Power T&D Company Inc. (ABB),
Ernst & Young LLP (E&Y) and Perot Systems Corporation (PSC).
[GRAPHIC OF MAP]
Table of Contents
Payroll/Human Resources..................................... 9.9
Functional Overview................................... 9.9
Commercial ????????................................... 9.10
Key Requirements..................................... 9.10
10.0 Program Management Approach.......................... 10.1
Program/Project Management Objectives...................... 10.3
Program/Project Management Methods......................... 10.4
Risk Management...................................... 10.4
Scope Management..................................... 10.5
Issues Resolution.................................... 10.7
Quality Management................................... 10.9
Knowledge Coordination and Transfer.................. 10.10
Customer Interface................................... 10.11
Market Participant Coordination...................... 10.11
Statelocators Communications......................... 10.11
11.0 PX System Roll-out................................... 11.1
Introduction............................................... 11.1
Roll-out Description................................. 11.1
Participant User Procedures.......................... 11.2
Operation Procedures................................. 11.3
Help Desk Roll-out................................... 11.4
Operational Support and Modification................. 11.5
Systems Management................................... 11.5
Services Provided.................................... 11.6
Delivery Record...................................... 11.6
Customer Required Testing.................................. 11.7
Training and Documentation................................. 11.8
Overview............................................. 11.8
Approach............................................. 11.9
Task 1: System Review................................ 11.9
Task 2: Define Training Scope........................ 11.10
Task 3: Develop Detailed Training Plan............... 11.10
Task 4: Define Training Environment.................. 11.11
Task 5: Implement Training Plan...................... 11.11
Task 6: Post-Training Review......................... 11.12
12.0 Power Exchange Operations............................ 12.1
Introduction............................................... 12.1
PX Business Operations..................................... 12.2
Trading Operations................................... 12.2
Post Trading Operations.............................. 12.3
Support Services..................................... 12.4
IT Operations........................................ 12.4
Human Resource Requirements................................ 12.6
Why Perot Systems?......................................... 12.7
[GRAPHIC]
1. EXECUTIVE SUMMARY
EXECUTIVE SUMMARY
AN ALLIANCE FOR THE NEXT MILLENNIUM
[GRAPHIC]
Change has become today's watchword as industries and companies position
themselves for the next millennium. California is on the cusp of significant
change -- the deregulation of its power industry. Creating an energy trading
market for the State of California sets the stage for the evolution of the
energy industry across the United States and highlights the foresight of those
visionaries working to create an independent Power Exchange.
Concepts must now be married with action to develop and deliver a fully
operational Power Exchange and commence trading market operations by January 1,
1998.
The timeline defined for achieving this goal is aggressive -- nine months
from contract start to market simulation -- and demands a high degree of
innovative technology to deliver this business solution combined with a
qualified team of experienced implementers to lead the delivery. Challenges
remain as the business rules, PX and ISO structures, and legislative rulings
continue to unfold.
SUMMARY
ABB, Ernst & Young and Perot Systems, three innovative industry leaders, have
formed an alliance specifically to leverage our unique combination of proven
products and services, mobilization and training, systems integration and
project management to bring the California Power Exchange to a timely and
successful operation. Our alliance -- the PX Alliance -- is the only team that
has actually delivered the business solutions required by the California Power
Exchange -- and has delivered them successfully.
The PX Alliance will take the approach of rapid development through field
tested, proven off-the-shelf products. Coupled with this technological know-how
is a fully committed, multi-disciplinary team with vast experience in
developing energy markets across the globe. The PX Alliance's proposed business
approach provides a high value, quality solution that mitigates the potential
risk of delay and focuses on the on-time, successful delivery of an operational
Power Exchange. The PX Alliance offers the best solution for a fully
operational Power Exchange.
The PX Alliance will establish a stand-alone company with operations based in
California whose sole mission will be the successful delivery of California's
PX by January 1, 1998.
Our three companies already employ more than 2,500 Californians and maintain
offices in Santa Clara, San Francisco, San Jose, Sacramento, San Diego, Los
Angeles, and Irvine.
Four critical factors differentiate the PX Alliance from our competition.
The PX Solution -- field tested, proven, off-the-shelf products that we will
adapt as required to deliver a successful Power Exchange to the state of
California.
The PX Alliance Approach -- rapid development and prototype delivery that
provides maximum opportunity for shareholder involvement while leveraging our
experience in similar operations worldwide.
The PX Alliance Experience -- unparalleled worldwide experience successfully
delivering solutions of similar size and complexity, supported by an unequaled
depth and breadth of talent specifically experienced in shaping the
deregulating California electricity industry.
The PX Alliance Team -- a multidisciplinary team with proven experience,
exceptional insight and unsurpassed leadership in the worldwide electricity
industry, with a unique synergy built on the strengths and expertise of our
three companies.
12
EXECUTIVE SUMMARY
THE PX ALLIANCE SOLUTION
[CHART]
The PX Alliance solution is fully compliant with all key requirements outlined
in the Request for Proposal. Our integrated service offering is based on field
tested, proven, off-the-shelf products that have been developed and implemented
in energy-trading markets throughout the world. The PX Alliance solution
integrates seven key functional areas:
BIDDING. ABB's Packaging & Settlement System (P&SS) provides an integrated and
proven approach to bidding, scheduling & settlements, most recently implemented
in Singapore's Power Pool. ABB's PowerWeb, the web interface product, has
recently been developed for the New York Power Pool's BidBox. The bidding
function of the P&SS can be readily scaled for the required number of market
participants. Further details are in Section 4 of the Technical Proposal.
SCHEDULING AND PRICE DETERMINATION. ABB's family of scheduling products
provides the basis for this module. They are currently used by more than
40 utilities, including the Albania ISA (Columbia), New York Power,
Singapore, and Eskom (Republic of South Africa) Pools, and by the UK National
Grid Company. Inherent in these products is the option to address voluntary
congestion management, a feature developed for and tested by the UK National
Grid Company and National Power, the UK's largest power generator.
13
EXECUTIVE SUMMARY
They also incorporate the specified options for Simultaneous or Sequential A/S
Scheduling. Further details are in Section 5 of the Technical Proposal.
PUBLISHING. Oracle's suite of WebTools and Netscape's Enterprise server along
with ABB's OASIS form the foundation of this module. Further details are in
Section 6 of the Technical Proposal.
SETTLEMENTS. ABB's Pooling & Settlement System (P&SS) is the core for this
module. The popularity of P&SS in power pools across the globe has resulted in
its application to a wide variety of power pool and power exchange operating
nodes. Extensive ad-hoc query and user reporting facilities for both
confidential and non-confidential reports are incorporated into this product.
Further details are in Section 7 of the Technical Proposal.
BILLING & CREDIT. Ernst & Young has designed and implemented billing models in
more than ten different energy transmissions systems throughout the US and the
UK. The critical billing invoice component of the subsystem is based on E&Y's
GasSolutions (TM) product, which was developed and implemented initially to
address requirements arising from deregulation of the US gas markets. This
product has since undergone further refinements as it has been introduced at
British Gas*TransCo business unit and modeled after the UK's national electric
grid and power pool. This product incorporates extremely flexible billing
regimens to meet all specified requirements. Further details are in Section 8
of the Technical Proposal.
ADMINISTRATIVE SYSTEMS. Seamless integration and flexibility are hallmarks of
the PX Alliance solution's Administrative Systems which leverage Oracle's
proven industry standard suite of applications packages. Both Ernst & Young,
who will be leading customization efforts in this area, and Perot Systems, the
overall project manager, have extensive experience in delivering Oracle based
solutions. Our solution is sufficiently flexible to accommodate outsourcing
non-core functions such as payroll processing should the PX choose to do so.
Further details are in Section 9 of the Technical Proposal.
SYSTEM ARCHITECTURE. An infrastructure built on world class technology designed
to prevent any single point failure threatening operations underlies our
business solution. Digital Equipment Corporation (Digital) has been chosen to
provide the requisite hardware and applications which will employ Oracle's
relational database products. Digital currently holds the world's performance
record for transaction processing utilizing Oracle's RDBMS. The PX Alliance
members have developed and implemented the world's largest transaction
processing system on an Oracle distributed client server, supporting 500
complex transactions per second. Further details are in Section 3 of the
Technical Proposal.
14
EXECUTIVE SUMMARY
THE PX ALLIANCE APPROACH
The PX Alliance will deliver an early release of the commercial business
systems to serve as a prototype and market trial tool by leveraging our proven
off-the-shelf products and technology. Based on input from the PX staff, market
participants, and stakeholders, this Alpha release will facilitate [illegible]
customization and continued development of a successfully operating Power
Exchange. Our rapid development, early release approach affords the PX and its
stakeholders the opportunity to validate related business processes and
protocols, mitigating the risk and meeting the challenge inherent in the
abbreviated timeline. In Section 2 of the Technical Proposal we describe our
approach in further detail and include our specific observations,
recommendations and lessons learned in creating similar systems for other power
pools around the world.
Proven program management, rapid system development methodologies, systems
integration, evaluation, testing and quality assurance methodologies are
equally fundamental to the success of the PX. Much attention has been given to
these critical foundations in Sections 2 and 10 of our Technical Proposal.
Section 11 details our plans for mobilization, roll-out and training. Following
the Alpha release, the PX Alliance will lead the training, bringing to bear
their unique knowledge and operational insights.
The PX Alliance is fundamentally committed to the successful operation of the
Power Exchange by January 1, 1998. Complementing our base Technical Proposal,
we offer three options for your consideration, each of which would provide an
even more robust operation.
As a further demonstration of our commitment to the successful operation of the
California Power Exchange, the PX Alliance also plans to present a proposal for
the ISO Scheduling Infrastructure, Scheduling Applications, and Business
Systems. Given the overlap of these functions and the commonality of their
solutions, we will offer significant savings should we be selected for both
contracts. The unique worldwide experience of the PX Alliance and our in-depth
involvement in the California electricity market provide even more synergy than
might be expected from merely selecting the same partner for both operations.
Because of our closely integrated team approach, we can focus on the concurrent
development, seamless integration and expeditious roll-out of these parallel
operations to minimize the overall build time and further mitigate the risk.
The RFP deals solely with the initial build and implementation of the systems
and infrastructure to deliver California's Power Exchange by January 1, 1998.
Clearly, the PKX will require significant operational staff to provide these
business services, indicative of our commitment to your success. Perot Systems
offers to assume responsibility for these continued operations. This ready and
expedient solution provides a single point of responsibility, accountable for
the provision, implementation, operation, and support of these complex business
systems. It will also reduce transition timelines and costs, mitigate the risk
of inefficiencies arising from hand-offs, and ensure readiness for market
response. What's more, this solution commits the PX Alliance to assume even more
of the risk in validating business processes and protocols. Further details are
in Section 12 of the Technical Proposal.
The PX Alliance recommends building a prototype to help define and test the
business rules concurrent with the continued and [illegible] development of the
fully responsive PX system. The early and frequent involvement of the PX
staff, market participants, and other stakeholders to establish and validate
the market rules, revised protocols, and bidding and scheduling operations is
critical to the successful and timely operation of the Power Exchange. Further
details of our testing plan are outlined in Section 2 of the Technical Proposal.
EXECUTIVE SUMMARY
DUR PX ALLIANCE QUALIFICATION
- ------------------------------------------------------------------------------
[CHART]
With our combined capabilities and global experiences, the PX Alliance is the
only credible team that can legitimately attest to having delivered the business
solution required by the PX.
ABB Power T&D Company Inc. (ABB) is a world leader in providing applications and
products to power pools and energy trading systems. ABB has successfully
implemented the replacement system for the Generator Order And Load (GOAL)
project for the UK's National Grid Company, the PUB Singapore Power Exchange,
and the New York Power Pool open market bidding, pooling and scheduling systems.
The GOAL replacement project incorporated strict project software auditability
transparent to the market participants. ABB has also been selected to provide
the core power exchange elements for the creation of the National Energy Market
system of Australia, the components of which are nearly identical and
complementary to California's Power Exchange. ABB is recognized as a pioneer in
the development of technologies to address real time power systems requirements
throughout the world.
15
EXECUTIVE SUMMARY
Ernst & Young LLP (E&Y) is one of the world's premier professional services
firms. with over 64,000 employees world-wide, their expertise spans virtually
every industry segment. E&Y has been involved in electricity industry
deregulation globality, providing services ranging from economic analysis of
market mechanics in New Zealand, Australia and the UK to business
transformation of UK and US power and gas utilities. E&Y's team has also
developed billing, settlements and bidding systems for a number of the US and
UK gas companies.
One of E&Y's core competencies is auditability of software. Within the PX
Alliance, E&Y will work closely with ABB to provide stringent checks and
balances for all software implemented. The resulting transparency of the
decision making process will enhance market integrity and encourage greater
participation, which in turn will lead to a more efficient and accessible power
market. E&Y also has extensive experience in the application of Oracle's suite
of administrative and financial systems with demonstrated skills customizing
and implementing applications similar to those we will provide the PX.
Perot Systems Corporation (PSC) will serve as the PX Alliance's overall program
manager and system integrator, PSC is one of the world's fastest growing and
most innovative venture technology companies. PSC's Energy Group is focused on
the changing dynamics of the global utility sector.
Since 1991 Perot Systems has been actively engaged in a strategic alliance with
one of the twelve former UK Regional Electricity Companies, a contract
valued at approximately $400 million. PSC has developed technology-based
business solutions and provided operations support to assist this multi-billion
dollar company in meeting the challenges of a competitive market. PSC developed
and implemented retail energy billing and trading systems which are key to
these initiatives.
Perot Systems has extensive hands-on experience in California's planned utility
restructuring. Both Southern California Edison and the Los Angeles Department
of Water and Power (LADWP) selected PSC to develop and implement comprehensive
business solutions to administer wholesale energy contracts and ancillary and
transmission grid services. The relationship with LADWP, the largest contract
of its kind ever awarded by the City of Los Angeles, focuses on the
transformation of the largest municipal electricity utility in the US to a
commercially competitive enterprise. As a result, PSC brings significant
business and industry insight to the PX Alliance.
While not the largest company of its kind, Perot Systems holds the distinction
for winning the world's largest contracts with the most ambitious time
schedules. This is one of PSC's core competencies and a stated strategic
direction.
Perot Systems developed and successfully implemented the world's largest
[Illegible] database application using open systems client server technology -
in just 13 months. This EuropCar International effort involved 55 systems
across nine countries and BOD offices, required placing PSC's associates in
Oracle's R&D labs, and resulted in the creation of Oracle's Version 7 operating
system specifically for this venture. More than 3,000 employees were trained in
the operating systems and the reengineered business processes. Training media
included reference guides, video tapes, video conferencing and online material
in nine different languages. Sixty trainers were used, exploiting a "train the
trainer" philosophy. Perot Systems was awarded a ten-year contract to run the
overall system, with incentive payments tied to business improvements in market
revenues.
In 1996 Perot Systems formed a strategic outsourcing alliance in excess of L6
billion with Swiss Bank Corporation, PSC provides services and technology which
support a distributed environment and customer population of more than 20,000
users. The Wall Street Journal touted this alliance as "the outsourcing
business model of the future."
17
[GRAPHIC OF MAP]
EXECUTIVE SUMMARY
PX ALLIANCE PROJECT ORGANIZATION
- -----------------------------------------------------------------------------
[CHART]
OUR PX ALLIANCE TEAM
A company -- and the products or services it creates -- is only as good as the
people who comprise it. The PX Alliance has assembled the joint team by drawing
the very best each company has to offer in terms of experience, talent and
leadership. The PX Alliance brings together a multi-disciplinary team steeped
in knowledge of the industry, technology, processes and people, whose
credentials are unsurpassed by any single supplier, integrator or any other
group of companies. The California Power Exchange will be the focus of this
unique combination of experience and capabilities gathered to deliver the full
PX business solution by January 1, 1998.
Each member of the PX Alliance core team was chosen for his or her specific
expertise and unique capabilities to meet the needs of the Power Exchange.
ED SMITH -- ACCOUNT/COMMERCIAL MANAGER
Ed is a corporate officer and Vice President, PSC; Chief Executive Officer of
Perot Systems Europe (Energy Services), Ltd., and Vice President of PSC Energy
Corporation, with responsibility for leading PSC's energy group business
operations on a global basis. He has held senior leadership positions in
domestic and international power, gas and telecommunications markets. Ed was
PSC's first U.S. operations associate assigned to Europe and led Perot's
engagement with East Midlands Electricity, PLC, third largest of the UK's twelve
regional electricity supply and distribution companies, with whom he formed a
12-year alliance that is still considered a model for power-industry
transformation. Since that time he has led energy related business development
efforts in North America, South Africa, India and several Asian countries. Ed
brings to the PX Alliance both proven ability to direct large-scale projects and
in-depth insight into the unique challenges of the deregulating utility
industry.
18
EXECUTIVE SUMMARY
LARRY SMITH -- PROGRAM MANAGER
An associate with Perot Systems, Larry has over 25 years of experience in
virtually all aspects of the software business. His expertise includes global
project management, software development, business process reengineering,
financial models and product market strategy. He brings to bear significant
experience leading multi-million dollar projects involving multiple vendors and
international deployment. He has served in numerous technical and managerial
positions for a wide range of hardware and software products, information
systems, and client solutions in worldwide industries and markets. His
performance in entrepreneurial projects demonstrates his ability to set and
communicate strategy, define goals, and deliver results.
CINDY BLACK -- PROGRAM OFFICE MANAGER
Cindy has nearly 18 years of experience in systems organization and project
management. She established a Program Management Office for the Perot Systems
Infrastructure organization which is responsible for the management of 300
separate projects relative to Data Centers, Networks and Network Consolidation.
As Project Manager for Swiss Bank Corporation, she was responsible for deploying
NT workstations to over 25,000 users worldwide. She recruited staff, established
procedures, formalized processes, and interfaced with the client. She has also
been responsible for establishing schedules for complex client software
implementation from development through software live dates. Cindy's hands-on
experience and depth of technical knowledge will help ensure that the PX
Alliance meets and even exceeds the demands of the Power Exchange.
ALI IPAKCHI -- PROJECT MANAGER, BIDDING, SCHEDULING AND SETTLEMENTS
An associate of ABB Systems Control, Dr. Ipakchi has more than 20 years of
experience in software development, project management, and applied R&D in
process control and the utility industry. As manager of the Power Applicators
department at ABB SC, his department has grown at the rate of 30% per year,
includes more than 50 engineers, and generates in excess of $15 million
annually. His established academic credentials, combined with his software
development project management experience will be instrumental to the
successful implementation of the bidding, scheduling and settlement modules.
STEVE BEHRENS -- PROJECT MANAGER, BILLING AND ADMINISTRATION
Steve Behrens is a Senior Manager in Ernst & Young LLP's Utility Consulting
practice. He has over 19 years of consulting experience, with emphasis on the
specification of information technology to solve business problems. He has 14
years of experience in the electric and gas utility industry participating in
the planning, design and development of a broad range of systems including
customer management and billing, service order management, financial reporting,
budgeting, employee management, power plant maintenance, and materials
management. His attention to detail and exacting performance standards uniquely
qualify him to lead the development and successful implementation of the
billing and administration modules.
PAT GOLDEN -- PROJECT MANAGER, INTEGRATION AND ROLL-OUTS
Pat Golden is a key FSC Energy business leader and technical expert. He is
currently leading an international forum to develop commercially leasible
"across the interface" (electric meter) solutions that will enable
organizations to innovate new and advanced products and services. Pat has more
than two decades of experience in control systems technology and applications,
with particular expertise in developing the technology enables necessary to
achieve business objectives. His industry experience encompasses electricity
and petrochemicals, and he has acknowledged skills in information engineering,
system design team management, and implementation across multi-functional
platforms. His skill set and knowledge base make him eminently qualified to
effect a successful integration and roll-out of the PX Alliance solution.
19
Executive Summary
[GRAPHIC OF MAP]
MEETING THE CHALLENGE
- -----------------------------------------------------------------------------
We, the PX Alliance, applaud the State of California for empowering the PX to
take this proactive leap toward the new millennium by being the first in the
United States to offer its citizens the benefits of deregulation. This
monumental task requires a quality team and close alliance between the PX and
your chosen provider to overcome the innumerable challenges to success.
We, the PX Alliance, three innovative industry leaders, are totally committed to
the success of the California Power Exchange. Our unique combination of proven
products, [illegible] services, robust training, thorough systems integration
and expert project management will be focused on bringing the California Power
Exchange to timely and successful operation by January 1, 1998.
20
[GRAPHIC]
2. PX IMPLEMENTATION
PX Systems Implementation
2.0 PX Systems Implementation
- --------------------------------------------------------------------------------
The members of the PX Alliance have been engaged in the provision of
electric industry solutions worldwide. Thus, we understand and appreciate
the unique challenges faced in creating the California Power Exchange.
This experience and industry knowledge enables the PX Alliance to
construct an implementation plan necessary to successfully create the PX
business and administrative systems. Key to this plan is the interactive
involvement of all stakeholders in the PX implementation effort -- from
the conformation of designs through the delivery of an orderly market
trial. This feature will later enable the delivered PX systems to fulfill
all aspects of the stakeholders' rational expectations. The Alliance also
recognizes that the dynamic environment in which the PX is being created
calls for flexibility in the implementation approach as well as in the
technical solutions. The Alliance looks forward to working jointly with
the PX TAC and the PX Project Manager in tailoring its proposed
implementation approach to support the creation of a governing Board of a
sustainable and enduring PX business entity.
This section describes the implementation approach proposed by the PX
Alliance to meet the infrastructure and business systems needs of the PX.
Key implementation activities essential for a successful installation are
also described.
Section 2.1, PX Business Description, outlines the proposed approach to
provide one of the most critical aspects of a successful systems
development and implementation project -- the definition of PX business
processes focused on satisfying customer requirements.
Section 2.2, PX Systems Description, provides an overview of the software
system proposed to meet the requirements of the PX, identifying the
functional components and describing the hierarchy of the proposed system
solutions.
Section 2.3, Project Management, summarizes the approach for management of
the individual development and integration activities of each project.
Further details on methods are contained in Section 10.[illegible].
Sections 2.4 and 2.5, Development Hardware and Production Hardware,
describe the processes involved in procurement and installation of
hardware for off-site development.
Section 2.6, Modifying Standard Software, addresses the process to be used
to customize the Alliance's existing products to meet the specific
requirements of the PX. The software system proposed for the PX is based
on a set of field proven products, developed, installed and in operation
in energy markets throughout the world. Using existing and field-tested
products minimizes the design risk and ensures rapid delivery of the PX
systems.
Section 2.7, Package Software Implementation, provides a detailed
description of the steps involved in delivering standard back-office
applications that will support the PX's day-to-day financial and
accounting, human resource and purchasing business operations.
Section 2.8, PX Systems Project Schedule, describes the project timeline
established for the various processes outlined in Sections 2.1 through
2.7. It also identifies the critical milestones and the key intermediate
dependencies involved.
Section 2.9, Lessons Learned, presents some relevant experiences from the
PX Alliance's previous systems development and implementation projects,
identifying potential hazards to avoid and opportunities to exploit in
carrying out the PX Systems project. Further details on experimental
recommendations have been provided in Section 12.
Section 2.[illegible], Optional Joint Study of the Proposed Bidding and
Bid Evaluation Protocol, presents a PX Alliance option to create a
prototype to help further define and test the bidding and bid evaluation
protocol.
2.1 PX Business Definition
2.1.1 PX Business Processes
The PX Business Process Model is the foundation upon which all effective
business and information technology programs are based. An overview of the
Business Process Model has been developed from the RFP to support the
Power Exchange business. This model, elements of which
21
Implementation
are outlined in the succeeding sections of this proposal, provide the basis for
ensuring the integration of the business processes with the system solutions
proposed by the PX Alliance. The business model has four main components:
- - The Business Processes and Subprocesses
- - The Business System Architecture
- - The Data Architecture
- - The Technology Architecture
Business Processes
The Business Processes define the business activities that are repeatedly
executed to fulfill a specific PX business requirement. Most, if not all, of
these processes are supported by hardware systems and software. Upon contract
award, detailed models will be created that show the data requirements for each
process and the inter-relationships of processes across the PX organization.
Business processes are characterized by:
- - Process descriptions associated with each system module, such as scheduling
and price determination
- - Business process flows by major business events, such as [illegible] bidding
- - Data flow diagrams showing the data used by each process and process
inter-relationships, such as settlement data
- - The completed business process models form the framework for integrating the
PX Systems.
Data Architecture
The Data Architecture defines the data and structures that support the business
functions forming the Business Process Models, the current data architecture is
incomplete and will be refined through the process of defining and developing
the individual software modules.
The contents of the data architecture include:
- - Entity-Relationship Diagrams for the various PX Systems
- - Definition of each entity and associated attributes
- - Definition of business rules governing the relationship of the entities
- - Relationship of entities to business functions identifying those functions
which create the data, versus those which only read and/or update the data
A properly defined data architecture ensures flexibility and open access to all
non-confidential information in the PX System.
2.13 Business System Architecture
The Business System Architecture defines the applications that manage the
data and support the business functions of the enterprise, including:
- Definition of each system module application
- Relationships between business processes, functions and supporting
application
- Data managed by the application
- Integration of the applications
The business systems architecture provides the roadmap for integration of
all the PX Systems.
2.14 Technology Architecture
The Technology Architecture defines those technologies supporting the PX
systems applications. It identifies the platforms for collecting,
transporting, storing, processing and delivering data to business users.
The technology architecture is described in Section 3 of the Technical
Proposal.
The Technology Architecture defines the following:
- Specific Architecture Components, including hardware, software and data
communications
- System flow
- Key technology capabilities and limitations
The technology architecture as defined by the PX Alliance, assures
flexibility in PX System implementation and scaleability for future growth
to meet and/or exceed the requirements as described in the FAD and RFP
documents.
PX Systems Implementation
2.2 PX System Description
A key factor necessary for successful implementation of a major project of
this magnitude is a system architecture that adequately addresses the
unique characteristics of the overall system. After a careful analysis of
the requirements of the PX, the PX Alliance has established a system
architecture (shown in Exhibit 2.2-1) that is tailored specifically to the
critical needs of the PX system. It addresses the key business and
administrative functions required for satisfactory PX operation, along
with the associated system integration activities necessary for delivering
the requisite market functions within the short time frame.
The proposed System Architecture groups the business functionalities
required for the Power Exchange into the following business operations:
Commercial (or Business) System and Back Office (or Administration)
System.
The Commercial System focuses on the major business functions of the PX
that are key to providing services for a competitive energy market in
California:
- Bidding
- Publishing
- Scheduling and Price Determination
- Settlement
- Billing and Credit
[CHART]
These modules are described in further detail in Sections 4 through 9 of
the Technical Proposal.
A subsystem of the Commercial System, the Historical Information
Subsystem, provides information audibility through the capabilities for
storage and tracking operational information associated with the
Commercial System.
The Administrative or Back Office System, also key to the successful
operations of the PX, provides the basic administrative infrastructure and
functionalities required for the PX organization to perform its regular
business activities. The various capabilities for the Administrative
subsystem are described in Section 9 of the Technical Proposal.
EXHIBIT - 2.2-1-PX CONCEPTUAL OVERVIEW
- --------------------------------------------------------------------------------
As shown in Figure 2.2-1, all systems are designed to work around a
centralized open database structure comprising a distributed Oracle
database architecture. This database architecture provides the common
medium for transfer of data items amongst the various systems.
2.3 Project Management
The purpose of Project management is to offset the risk of failure to
deliver a fully operational system to the PX by January 1, 1998. The PX
Alliance is proposing that the Project Management for the Power Exchange
Project be directed by a Program Office coordinating all activities of the
system project managers, ensuring the overall integration of the PX
System, and offering a single point of accountability to the PX staff and
the PX Program/Project Manager. Project management directs the steps
comprising the development and
23
[GRAPHIC OF MAP]
PX Systems Implementation
implementation process. Using our proven methodology, the project managers
for the individual subsystems (as well as the project managers for the
hardware implementation, business process definition, and training
projects) will work under the direction of the PX Alliance Program
Manager. The managers will agree to the development and implementation
milestones by creating detailed stages, activities and tasks, and
identifying interdependencies of the development projects.
2.3.1 Approach
The PX Alliance brings to the PX Project off-the-shelf technology and
business systems whose demonstrated effectiveness is in evidence within
energy markets throughout the globe. These capabilities, combined within
the experiences of the PX Alliance members in developing those markets,
are seen as critical to delivering an operational California Power
Exchange within the very short timelines remaining until January 1, 1998.
Recognizing that the unique requirements of the PX will necessitate
modifications and further integration of these business subsystems, it is
the intentions of the PX Alliance to take full advantage of its proven
business solutions to set up an Alpha Release of the Commercial Business
System in the first few months following the contract award. This release
will serve as a test bed for business user interaction and iterative
development of prototypes. This approach is expected to shorten
development timelines and offer the opportunity for validation of related
business process and protocols. It also allows for an early focus on
training and development of documentation well ahead of the market trial
phase. Heavy emphasis will be placed on change and release management to
exert appropriate quality control as these module developments are moved
through iterative prototyping into beta release and production.
System integration is another responsibility of Project Management. System
integration tasks for the Power Exchange center around the testing and
validation of the following major interfaces:
- An interface with the Market Participants provided from the Bidding and
Publishing modules. This requires interfaces with WEnet and subsequent
access through [illegible].
- The interface to the ISO systems for passing schedules and supporting
data, as well as for receiving fully vertified schedules and usage
information for settlement of the day ahead and hourly committed
schedules.
- Seamless interfaces between the Commercial and Bank Office business
systems.
- The interfaces with metering management and financial service
organizations.
Full and seamless integration of the PX Systems with these interfaces,
forms one of the major challenges in developing an operational energy
trading market for California. The following sections describe how the PX
Alliance will manage that integration to ensure the successful delivery of
the energy trading market by January 1, 1998.
21
PX Systems Implementation
EXHIBIT 2.3-1 - SYSTEM INTEGRATION PERSPECTIVE
[CHART]
The systems integration and project management approach for the Power
Exchange emphasizes customer involvement from the very beginning of the
project. The objective is to plan and control development of the PX
Systems from implementation to conclusion, with high levels of
productivity and [illegible], and low levels of uncertainty. While
ensuring maximum flexibility in dealing with situations of uncertainty.
Details of the PX Alliance's Project Management methods and associated
organizational design are contained in Section 10 of the Technical
Proposal.
2.3.2 Description
The PX projects [illegible][illegible][illegible] of the business
requirements, work products, quality of deliverables, and performance
[illegible]. Within the PX, efforts [illegible] [illegible] structured and
planned to refine the initial business systems [illegible] into
[illegible] project [illegible]. Except [illegible] the project will
include the [illegible] and [illegible] of [illegible] necessary for
project completion and [illegible] [illegible] [illegible] encompassing
all the activities necessary to ensure that the systems developed adhere
to the Power Exchanges requirements.
2.3.3 Project Initiation and Planning
In developing the Project Plan for the PX, project objectives are stated
and clarified, major deliverables are identified, and project milestones
and schedules confirmed. The project charter clearly describes the
project's scope in terms of logical or functional boundaries and
identifies interfaces and interdependencies with related PX projects.
Using the overall project schedule shown in Appendix H, a detailed project
plan for day-to-day management of the PX project will be created. Working
with the PX and its designated Program Manager, the PX Alliance Program
Manger and the subproject teams plan the work that will be done during the
project by developing a task-level work plan (work breakdown structure)
that includes milestones, [illegible] effort estimates, and resource
assignments.
[illegible]
PX Systems Implementation
[GRAPHIC OF MAP]
With this information the team will then develop a detailed project
schedule.
Overall program controls will be implemented to manage the performance of
the PX project tasks. Project managers will monitor and [illegible] the
following aspects of project performance.
- SCHEDULE TRACKING. The information project plan will be updated to
reflect project progress. Additional reports will track the number of
task starts and completes, capture weekly activity, and compare actual
progress with the baseline.
- COST TRACKING. Reports will list the expenses charged to the project,
compare actual to planned expenses, and highlight activities and tasks
that are over budget.
- RESOURCE MANAGEMENT. Weekly activity reports will capture the hours
expended per project task, calculate resource utilization, update
estimates to complete activities, and feed into the project budget. The
project plan will also facilitate the leveling of resources over the
project duration.
- PROJECT REPORTING. Periodic project status reports will communicate the
project's progress in terms of percentage complete, estimates to
complete, actual vs planned, activities completed, and project issues.
Progress meetings will also assist in communicating project status and
issues.
2.3.4 Project Implementation
The PX systems projects are implemented according to the plans
constructed in the planning stage, with the project managers responsible
for the design, forecasting, monitoring and control of project
activities. Examples of standard milestones during the implementation
stages are:
- Customer Review of Functional Requirements Documentation
- Completion of Subsystems Testing
- Completion of System Testing
- Completion of Final Acceptance Testing
The development and implementation process is based on a hierarchy of
systems described below.
- An Enterprise (such as PX) is made up of a number of Business Systems.
- A Business System is composed of a number of Subsystems or functional
modules.
- The components of a Subsystem Module are [illegible] as Functions.
- One or more Units make up a Function.
The following is an example of the hierarchy as [illegible] the Power
Exchange.
- Enterprise .................................. the Power Exchange System
- System .......................................... the Commercial System
- Subsystem/Module .................................the Billing Subsystem
- Function ..................................... Validating a [illegible]
- Unit ................................ Code performing a validation task
All software revisions are developed and integrated with a view towards
this hierarchy. The development and integration process is made up of a
specific integrated sequence of steps which will be followed in ensuring
delivery of a fully integrated operating business environment. These
steps are:
- Definition of Functional Requirements
- Design and Prototyping
- Coding and Unit Testing
- Functional Integration and Testing
- Subsystem Integration and Testing
- System Integration and Testing
- Enterprise Integration and (Final) Testing
DEFINITION OF FUNCTIONAL REQUIREMENTS
The purpose of the [illegible][illegible][illegible] understanding of the
functional specifications and business deliverables, geared toward
implementation. This document will be used to produce the test procedures
for all acceptance testing purposes. This document requires approval of
the PX to [illegible] [illegible] [illegible] [illegible] [illegible]
agreement regarding the [illegible] [illegible] contract. The [illegible]
step [illegible] the [illegible]
25
P I Systems Implementation
[illegible] [illegible]
[illegible]
[illegible] [illegible]
[illegible]
Functional Requirements Documentation and Review
Upon completion of the business [illegible][illegible][illegible]
[illegible][illegible][illegible][illegible][illegible]
[illegible][illegible][illegible][illegible][illegible]
- Will the [illegible] meet the overall enterprise needs
- Will the [illegible][illegible][illegible][illegible]
- Will the [illegible][illegible][illegible][illegible]
The PX staff and/or the PX Program Project Manager will be asked to verify
the appropriateness of other aspects of the project at this time such as
- Training
- Availability
- Input controls
- File controls
- Output controls
- Confidentiality internal
- Confidentiality external
- Audit trails and follow-up actions
- Access control
Any [illegible][illegible][illegible][illegible]
[illegible][illegible][illegible][illegible] [illegible][illegible]
Design and [illegible]
[illegible][illegible][illegible][illegible][illegible]
[illegible][illegible][illegible][illegible][illegible]
[illegible][illegible][illegible][illegible][illegible]
[illegible][illegible][illegible] Each function of the [illegible] into
[illegible] and a set of prototype [illegible] is a [illegible] design
specification and a collection of [illegible] [illegible] options can be
exercised. [illegible]
23.5 Develop Test Plan
On project [illegible], the PX System's Test Plan will be developed with
the overall project plan. As the various Test Plans [illegible][illegible]
System Stability Test, etc) are developed, they will be approved by the
PX. The schedule for the testing process is represented [illegible]
Testing Schedule.
23.6 Subsystem Testing
Subsystems testing is the testing and evaluation of the component pieces
within each business module, without testing the operation of the module
as a whole. In this stage, the unit test procedures and the associated
test data are created. Functional test procedures are created and test
data are generated by running special test programs, conversion programs,
or system utilities. Unit tests are conducted using the test data created.
Thread testing, which combines individual test units into threads of
functionality, will be performed. A thread is first defined by selecting a
particular function and determining which units contribute to that
function. Threads are in turn integrated and incrementally tested as
subsystems.
The project team will verify that [illegible] test cases are performed and
that the unit tests:
- Execute each decision with the possible outcomes at least once
- Execute [illegible][illegible][illegible][illegible]
- [illegible][illegible] of the program against its specifications
- Test the [illegible] and performance of the user interface
Tests also verify that the [Illegible] are consistent and adequate,
entry of required fields is enforced; fields are edited properly,
error messages are consistent, and other standard [Illegible] properly
Upon completion of our testing, all tested modules are loaded into
the development library. This leased version represents the core
[Illegible] of the subsystems for system integration testing.
2.3.7 System Integration Testing
During the system integration tests, the previously tested individual
unit software is combined to form a complete business system module.
Integration testing includes the integration of programs into
subsystems, and subsystems into the overall system. Examining the test
data created by the subsystem testing tests are conducted and results
analyzed. An incremental testing technique is used. This is a
disciplined method for testing the interfaces between unit-tested
modules. It is characterized by adding individual unit-tested modules
& programs one by one to a given unit-tested module, and then
testing each new combination.
The project team will execute regressor tests to verify that
interfaces from and to the subsystems being developed are functioning
correctly. Upon completion any provisions of [Illegible].
2.3.8 Final Testing
[Illegible]
[Illegible]
Exhibit 2.3.8-1 Testing Schedule
[Chart]
2.4 Development Hardware
[Illegible]
[Illegible] (folio)
P X S y s t e m s I m p l e m e n t a t i o n
be delivered on March 1, 1997 unless canceled by the PX Alliance. The
backup system hardware will be used for development while the production
hardware is set up for acceptance testing. This has several advantages
including [illegible] acquisition of the development hardware, the
ability to install and test the production hardware in parallel
[illegible] development and providing a completely separate "production
environment" to simplify the management of releases.
2.4.1 Configured development system
As soon as the hardware is delivered its physical configuration will
begin. Design and planning for the hardware configuration has already
begun. Working with the vendors and OEMs, the complete configuration plan
is expected to be completed as soon as expenditures under the PX system
contract are agreed and, prior to physical installation.
The configuration includes the main processors, the chem PCs, the
networks, and all development software as described in Appendix D of the
Technical Proposal.
A detailed description of the hardware and software configurations is in
Section 3 of the Technical Proposal.
2.4.2 Time/Schedule
The schedule for the development hardware acquisition and configuration
as shown below.
EXHIBIT 2.4.2-1 HARDWARE SCHEDULE
[CHART]
2.5. PRODUCTION HARDWARE
The implementation of the California Power Exchange and a successful
transition to a competitive market place will depend on the optimal use
of the computer infrastructure. The PX Alliance recognizes, based on
subsidiary experience with power exchanges throughout the world, the
unique command the California PX [illegible] and design of hardware
platforms have been completed with the objective of [illegible] in the
hardware capability.
Designing with optimal flexibility in mind has allowed the PX Alliance to
significantly reduce risk of performance problems while simultaneously
providing a significant capability for [illegible] within the hardware
infrastructure. A detailed description of the hardware and software
configuration proposal is contained in Section 3 of the Technical
Proposal.
2.6 MODIFYING STANDARD SOFTWARE DEVELOPMENT
Modifying Standard Software Development is guided by the same Project
Management procedures described earlier. The development process follows
the [illegible], design, prototype/code, and testing phases of software
development. For the various business functions, the development phases
will occur in parallel. The actual development cycle may include multiple
variations of the development phases.
This approach ensures a core business functionality is developed early in
the project, with new functionality added in the iterative cycles all the
way through to PX Systems callout.
2.7 PACKAGE SOFTWARE IMPLEMENTATION
In addition to bringing its own proven products to bear in producing the
required PX business systems, the Power Exchange will also require
administrative software packages from the Oracle [illegible] of
applications to support its day to day business operations. The
Administrative Systems Application Implementation effort will leverage the
existing fit of these packaged software applications with the PX functional
requirements to implement the required institutional procedures that
control the operation of the implemented systems. The PX receives the
benefits of:
- A speedy implementation effort that leverages the work of prior Oracle
application implementations
- Lower implementation [illegible] due to the depth of experience and
the proven capabilities of both the applications and the
implementation team
- The value received from the lower lifecycle cost from receiving quick
delivery of a robust system that fully satisfies the PX's back-office
business requirements
The objective of the Administrative Systems Application implementation
effort is to successfully implement the Oracle applications while also
identifying and resolving any key requirement gaps between the selected
packages and the PX administrative functional requirements. A rapid package
installation effort will be achieved [illegible] leveraging existing
experience, knowledge and reusable objects.
The Application Implementation process comprises several stages (depicted
in Exhibit 2.7.12 that are characterized as follows:
- Requirements Confirmation (Confirmation)
- Solution Design and Definition (Definition)
- Solution Development (Development)
- Solution Implementation (Implementation)
[CHART]
[GRAPHIC OF MAP]
PX SYSTEMS IMPLEMENTATION
EXHIBIT 2.7-2 IMPLEMENTATION SCHEDULE
[CHART]
2.8 PROJECT SCHEDULE
Several activities must be performed in parallel to achieve a timely
completion of the project. Exhibit 2.8-1 depicts an overview of the
timeline and events proposed by the PX Alliance to bring these
activities realistically to a successful completion by January 1, 1998.
Key milestones are as follows:
- Project Start ........................................... 3/1/97
- Functional Requirements Definition Completed ............ 4/1/97
- Business Systems Design Completed ....................... 5/1/97
- Alpha Release -- Subsystem Testing Complete ............. 9/1/97
- Beta Release -- System Testing Complete ................. 10/1/97
- Final Release Market Trial .............................. 12/1/97
- Ready for Operation ..................................... 1/1/98
The PX Alliance is confident that with the proposed sectional approach
(i.e., use of existing field proven products developed by the PX Alliance
partners and by other renowned third-party vendors) and with the proposed
implementation processes coordinated by a second Project Management
methodology (described in Section 10), it will meet the critical deadline
of January 1, 1998 for the [illegible] of operation of the PX. It is
imperative that the PX Alliance and the PX Project Management staff work in
close [illegible] to ensure key initial activities are achieved on time.
Major [illegible] events which must be completed or [illegible] for the
overall project to come to a successful completion by January 1, 1998 are:
- Contract award on February, 1997
- Contract signed by February 28, 1997
- Functional requirements [illegible] approved by April 1997
- ISO interface definitions completed by May 9, 1997
- PX facilities available by June 15, 1997
- PX staff available to participate fully during the December
and Design and Prototyping phases
If a PX Alliance is [illegible] achieve the [illegible] deadline of January 1,
19[illegible]
PX Systems Implementation
EXHIBIT 2.[ILLEGIBLE]-1 OVERALL PROJECT SCHEDULE
[CHART]
Lessons Learned
[ILLEGIBLE]
[ILLEGIBLE FOLIO]
PX Systems Implementation
exercise should be seen [illegible][illegible] experiences of the individual PX
Alliance [illegible][illegible] these markets.
No two reform exercises are the same. There are as many approaches to
[illegible] [illegible][illegible][illegible] points, objectives and timetables.
However, there is ample anecdotal evidence that suggests certain [illegible] or
actions bring about [illegible] more durable results. [illegible] on "lessons
learned" follow
Tight time frames for implementation combined with major change require
significant effort to mitigate the risk of partial failure.
Commentators generally hold one view that a step-by-step approach to market
implementation is to be preferred - if timescales allow. Advantages are
- - A managed release of systems and processes with the ability to incorporate
modifications as necessary will result in a more robust and high quality
end product.
- - The market participants become more active in the new market more quickly and
more effectively than is otherwise the case of big bang rapid changes
The Victoria pool (VicPool) effort is usually held up to be an example of phased
development. This has allowed the market to learn while managing systems, cost
and, risk.
On the other hand big bang approaches to system implementation and the start up
of market operations reflect the desire to effect wide ranging change as
quickly as possible. Often, timescales are driven by the need to meet external
requirements or schedule. For example, the [illegible][illegible][illegible]
electoral timescales in England and Wales led to a number of structural
imperfections. Although many of these mistakes have been fixed, such as ABB's
replacement of the GOAL scheduling program, a number of imperfections
[illegible] [illegible][illegible] the operation [illegible][illegible]
The PX Alliance proposes to [illegible][illegible][illegible]
the tight time frames for market[illegible][illegible][illegible]
key elements in our approach.
We will use field tested software as the basis for all of the key applications
- - Bidding, Scheduling and Pricing, Settlements, Publishing, Billing and
Collection, and Administration.
- - We have proposed and will rigorously implement project management as a tool
to stay on track with our plan, process revisions, and maintain high quality.
- - We will commit sufficient resources with extensive hands-on experience in all
areas which are critical to the success of this project.
Ensure adequate training and trials.
Market systems inevitably bring with them new commercial arrangements and
expose participants to different [illegible] complex) processes and ways of
doing things and new disciplines. Market participants need to understand how
the market works, that systems have been duly tested and what the market means
for them in terms of business practices and protocols.
The recent New Zealand experience illustrates the pain; well the NSFM wholesale
market venture on 1 October 1998. The scheduling, pricing and dispatch model
went through active [illegible] only a week prior to that date. Many of the
price spikes experienced by the market over subsequent months are still not
understood [illegible] month's prices have been [illegible]in full on two
occasions and have only just been finalized.
The PX Alliance has an extensive training and [illegible] period preceded by the
opportunity for the Market Participants take part in overall system
implementation by working with the PX and the FX Alliance to establish the
operating requirements from the user's perspective. This will occur through an
early prototype release that is possible only because we have held proven
software for the major applications. Thus the PX Alliance plan incorporates
both the technical aspect of system implementations, as well as significant
input, starting [illegible][illegible][illegible]so that
[illegible][illegible][illegible][illegible][illegible]
User participation.
[illegible][illegible][illegible] processes a [illegible][illegible]
[illegible][illegible][illegible][illegible][illegible]
P X S y s t e m s I m p l e m e n t a t i o n
[illegible]
[illegible]
KEEP IT SIMPLE.
Market restructuring and implementation is inherently complex. Since the England
and Wales experience [illegible] as lacking transparency, there have been a
number of attempts to simplify market operations. It is now accepted wisdom that
physical and market operations can be [illegible] with many decisions and
processes pushed out to participants. Scandinavian reforms, in addition to being
evolutionary, have also seen the incorporation of many simple trading deadlines
from [illegible] markets.
An example is again provided by NZ. The market designers insisted on the
introduction of a voluntary day ahead [illegible] commitment market which was
[illegible] independent of the dispatch process. This was despite user views
that, unless it was a mandatory [illegible] NZEM participation, it added
nothing to the market process. The day ahead market operated for the last four
days of market operation (with low volumes and has subsequently not cleared it
as now considered redundant.
SIGNIFICANT CHANGE TO MARKET DESIGN AND BUSINESS RULES, ESPECIALLY LATE INTO A
PROCESS, CAN BE EXPENSIVE AND CAN IMPERIL IMPLEMENTATION TO TIME.
[illegible]
The PX Alliance proposal suggests a clear responsive and reasonably flexible
mechanism whereby changes and their [illegible] are evaluated and decisions
made in light of [illegible].
MAKE SURE THERE ARE BACKUP SYSTEMS AND AUDIT TRAILS AVAILABLE WHEN THE SYSTEMS
GO LIVE.
The previous example is applicable here too. The credibility [illegible] makes
[illegible][illegible] participants cannot see clear [illegible].
The [illegible] comprehensive, [illegible], work procedures.
PARTICIPANTS MUST SIGN OFF CRITICAL BUSINESS RULES WELL IN ADVANCE.
A number of power exchange developments have been [illegible] at risk because
key elements of the market rules have changed or have been shown not to work.
New Zealand is a good example. Key aspects of the scheduling (and therefore
[illegible]) [illegible] continued to be refined in the run up to
and even after market implementation. These changes are a large contribution to
the problems still being experienced.
In a second example, business rules for the Australian national market have had
to be rewritten many times over the last three years. [illegible] the
[illegible] since participants refused to endorse them, more recently they were
considered overly technical. Changes have significantly slowed down the process.
This is not to say that rules must be locked in stone. The England and Wales
[illegible] rules are held to be the worst example of rules that are overly
complex and very difficult to change. The point is that there needs to be a
defined process.
* FOR SIGN OFF OF RULES IN A TIMELY MANNER FOR THE PURPOSES OF IMPLEMENTATION.
* FOR REVIEW AND REVISION POST IMPLEMENTATION, IF NECESSARY.
The PX Alliance process recognizes the [illegible] processes for [illegible]
with [illegible]
[illegible]
[GRAPHIC OF A MAP]
2.10 OPTIONAL JOINT STUDY OF THE PROPOSED BIDDING, BID EVALUATION AND
SCHEDULING PROTOCOL
An important business objective of the PX Alliance is both the successful
development and implementation of the PX business systems and to ensure the
subsequent successful operation of the power market in California. To that
end, we offer to perform a joint study with the Power Exchange to "debug"
and refine the Bidding and Scheduling protocol specified in the RFP.
The proposed joint study has not been included within the scope of the PX
Alliance's fixed price proposal. However, the advisability of conducting
this validation of protocols against a simulated market appears clear. Work
needs to start and be completed as early as possible (e.g., in one to three
months) to incorporate any desired changes emerging from this analysis.
Should the PX indicate an interest in this joint study, the PX Alliance
would gladly prepare and submit a detailed work scope and cost estimate.
The PX Alliance has closely monitored the Power Exchange's development of
the specified Bidding and Scheduling protocol. We fully appreciate the
extent of the effort expended to produce this protocol. We are also aware
that the physical power system in California and the proposed market
structure for the PX are more complex than their counterparts elsewhere in
the world. As such, certain aspects of the proposed protocol may need to be
further refined to ensure an efficient power market. Specifically, we offer
to jointly study and refine the following aspects of the Bidding and
Scheduling protocol:
- The proposed iteration between PX, participants, and the ISO -- The
sequential and simultaneous bidding for energy and ancillary services.
- Congestion management modeling in PX
- The business rules (e.g., Activity Rules) that need to be implemented
to minimize [illegible]
We propose to study these aspects in a simulated environment as soon as
approved. Given the short time frame available we propose to focus on
searching for "fatal bugs" that might ensue that we could then connect
promptly to ensure successful operation of the power market in California
in 1998. It is important to note that the PX Alliance would not carry out
this study by itself. Active participation of other experts and the PX
customers who were involved in the development of the specified Bidding and
Bid Evaluation protocol is essential. The study can be carried out
following the general steps outlined below.
- Identification and prioritization of specific aspects of the protocol
to be tested
- Experiment/study design to test each specific aspect
- Perform the study, analyze the results, identify the bugs, and refine
the protocol
Each experiment needs to be designed to take advantage of existing
"off-the-shelf" software (e.g., bid preparation, scheduling, bid
evaluation) or semi-manual processes
The experience of the PX Alliance is very strong in the area of bidding,
scheduling and price determination. We also have several powerful and
proven scheduling, bidding, and bid evaluation software packages that we
can configure quickly for this study. We are therefore confident that we
can productively work with the PX to successfully analyze any troublesome
issue.
[GRAPHIC]
3. System Architecture
3.0 System Architecture
[CHART]
3.1 System Design Overview
The PX Alliance system solution is specifically designed to meet the PX
requirements, while leveraging existing and newer software products, high
performance [ILLEGIBLE] to meet the Power Exchange's evolving needs. The
PX Alliance fully realizes the technical challenges and the [ILLEGIBLE]
of the PX implementation. We believe that the proposed solution
[ILLEGIBLE] these requirements.
The key considerations in developing the proposed PX system design
include:
- Functionality - to meet the requirements of the California Power
Exchange, as outlined in the Functional Requirement Document and the
Request for Proposal.
- Proven Technology - to minimize risks associated with timely delivery
of the system.
- Flexibility - to [ILLEGIBLE] anticipation to future PX needs.
[graphic of map]
System Architecture
- Modularity - [Illegible]
- Performance - to provide [Illegible]
- Flexibility - [Illegible]
- Scalability - to allow [Illegible]
The PX Alliance proposes the use of Digital Alpha hardware for the
system servers and Oracle relational database management system as the
database platform. The Digital Alpha and Oracle combination is
considered to be the industry's best performance delivery platform for
relational database management and transaction processing.
The proposed system is based on a distributed Client/Server
architecture. The servers will be operating under the UNIX operating
system and will be responsible for front-end data communications,
database management and applications software, and data archival and
administrative functions. The user interface clients at the PX centers
will be based on Pentium PC technology running under Windows NT or
Windows 95. The graphical user interface screens on these clients will
be built using Borland's Delphi IGU [Illegible] one of the leading
high performance looks for large scale applications. The user
interface for PX Market [Illegible] will be based on Web technology,
which will also support file upload and download and fax interfaces
for submission, schedules and settlements results. Communications
links with the ISQ, metering agents and cash managers will be
supported through the [Illegible].
The applications software [Illegible] based primarily on existing
technologies. ABB's Pooling and Settlements System (P&SS) will be the
basis for fulfilling the [Illegible] and Publishing requirements, and
the associated data processing and dispute management functions. ABB's
OASIS and [Illegible] bidding system recently developed [Illegible],
will be the basis [Illegible] [Illegible].
3.2 Hardware Design
3.2.1 General Requirements
The computer infrastructure [Illegible] PX operator is a key factor in
the successful transition to a competitive energy marketplace in
California. Based on our substantial energy trading experience with
power pools [Illegible], the PX Alliance recognizes the unique demands
that will be imposed on the computer infrastructure. The technical
architecture proposed by the PX Alliance will meet or exceed all
system requirements as described in the [Illegible].
The design and sizing of the PX hardware is a function of the number
of PX Market Participants and the pattern by which they participate in
day-ahead, hour-ahead, and auxiliary services markets. Although
significant benchmarking has been performed, the true number of
participants and [Illegible] [Illegible] is essential to the
successful operation of the Power Exchange. The PX Alliance is
proposing a hardware architecture which significantly reduces
[Illegible], provides major growth capability, and [Illegible] cost to
the PX.
3.2.2 Hardware Configuration
Exhibit 3.2.2-1 represents the proposed hardware configuration and
illustrates [Illegible].
System Architecture
Exhibit 3.2.2-1 PX Computer Hardware
[CHART]
[GRAPHIC OF MAP]
System Architecture
3.2.3 Processors
The PX Alliance has selected Digital Alpha processors. The Digital Alpha
machines offer unparalleled [illegible] performance and potential for
[illegible] [illegible] housing has been [illegible] to offer the
appropriate level of flexibility and growth when and where it is
[illegible]. Each Digital processor cabinet has the capability of
housing multiple CPUs.
Digital's [illegible] systems can readily adapt to the changing business
environment and rapidly serve the [illegible] processors. The 6400 system
offers 12G5 [illegible]. See [illegible] technology for optimum
throughput its maximum configured memory is [illegible] GB. The maximum
configured memory required for the proposed system is [illegible] GB.
By [illegible] Digital's clustering technology, the PX Alliance provides
the optimum level of [illegible] and the capability for "hot" stand-by
processors. Digital clusters are included to support the key operational
systems of the Bidding and Scheduling and Publishing modules.
3.2.4 Local Area Networking
High-speed throughput from the network is necessary to minimize
processing times and to provide PX Market Participants with high level
quality service information enters the LAN environment via an OC-3 AIM
[illegible]. Based on the PX Alliance experience with other Pooling and
[illegible] systems, network performance is [illegible] to the provision
of quality service. We believe the peak performance requirement will
extend beyond the [illegible] per second offered by typical networking
systems. The network aggregate load may increase to OC-12 requirements
as the market matures. To accommodate these increases, we recommend the
introduction of ATIV-based Local Area Networking matched to the 155MB's
presented by the [illegible] OC-3 multi-plexor.
- As required by the [illegible] high-performance devices have been
selected to provide network resilience within the system, so that failure
of any single component would not result in failure of the entire
network. Digital products will be used to minimize the time required for
[illegible] diagnostic procedures while enabling [illegible] featured ATM
services.
3.2.5 Processor Interconnections
Micro-channel connects promote bus speed connections between redundant
cases of processors, enabling fast switching following primary processor
[illegible][illegible] information between systems supporting processors
is achieved using 155MB's ATM technology, [illegible]
[illegible][illegible][illegible]
3.2.6 Auxiliary Memory
[illegible] storage of information is provided through [illegible] or a
Redundant Array of inexpensive Disks [illegible][illegible] units will
provide optimum up time and enable "hot swapping" of disks without
[illegible] normal operation.
Redundant disk [illegible][illegible][illegible][illegible]processors to
increase resilience and enable access to the disk should a controller
fail. This solution also enables alternate processors to gain access to
mission critical storage arrays following primary processor failure.
Our system requires, at most [illegible] [illegible]over multiple
controllers. The [illegible][illegible] has a maximum capability of
[illegible] per [illegible].
3.2.7 Data Archive [illegible]
Historical archiving will utilize [illegible] [illegible] [illegible]
[illegible] the daily security backup on a magnetic [illegible]
[illegible] library to minimize operator involvement. [illegible]
[illegible] [illegible] designed for [illegible] capacity archiving, will
store [illegible] [illegible]. Multiple libraries are specified
[illegible]
3.2.8 Printers
Based on our [illegible][illegible][illegible][illegible]
[illegible][illegible][illegible] We recommend [illegible]
[illegible][illegible][illegible][illegible] and provide up to
[illegible]
[illegible] [illegible] [illegible] [illegible]
3.2.9 CONSOLES
Workstations. Pentium PC workstations running Microsoft's Windows NT
or Windows 95 operating software are proposed as a standard. Each
workstation will readily accommodate expanding RAM to twice the
capacity [illegible] and be configured for optimum performance with
Microsoft Windows. Each workstation will have at least one [illegible]
and one [illegible] port for PX connectivity, as defined in Section
[illegible] of Volume II of the PX Systems Technical Specifications
document. Other standard equipment will include monitor and mouse with
specifications designed to enhance clarity of displays and reduce
potential user fatigue. Each workstation will be capable of
[illegible] an audible [illegible], as required.
Monitors. Monitors will be at least 20 inches across the diagonal and
conform to California and Federal requirements for screen resolution
and emissions. The screens will conform to the industry norm for
business application workstations and have a refresh rate of 75 MHz or
better. 75 MHz monitors are specified in lieu of the required 100 MHz
monitors as they represent the de facto industry standard for
commercial applications. All monitors presenting a frequent display of
information will be equipped with screen savers to protect the unit
from phosphor burning on the screen.
Keyboards. All keyboards will be provided with QUERTY alphanumeric
keys with an integral numeric key pad. Keys will repeat if depressed
and held down. Cursor navigator keys will be provided as separate
keys. The keyboard will be attached to the workstation by a
[illegible] by a detachable plug.
Mouse. Each workstation will be equipped with [illegible] will enable
[illegible] tracking of the cursor as required and provide three
buttons for use with PX software. The mouse shall be connected to the
workstation [illegible] plug-detachable cord.
The proposed system, using software control, allows operators to open
multiple windows on their workstation. This capability exceeds the
[illegible] of the [illegible] [illegible] keyboard and mouse as a
unit among the monitors at a console using cursor positioning.
3.2.10 VIDEO [illegible]
[illegible] provided to enable screen [illegible] made as required.
The video copier will be connected to the local area network (LAN) for
access by [illegible] workstations [illegible] the PX. The video
copier will use [illegible] by [illegible] and produce images of at
least [illegible].
3.2.11 OTHER PERIPHERAL DEVICES
Modem and fax equipment will be installed on the computer network to
enable remote software support.
3.2.12 CONSUMABLE SUPPLIES
All computer [illegible] consumable items required for testing and
installation will be provided. Magnetic media required for backup and
dumps during the testing and installation period will also be
provided.
3.3 CONFIGURATION CHARACTERISTICS AND AVAILABILITY
The proposed PX system solution has been designed to offer flexibility
and future growth while managing risk and cost. The chosen system
architecture is a distributed computer environment that enables the PX
Alliance to provide the PX with a significant amount of processing
capability while minimizing the potential risk arising from component
failure.
[illegible] Wide Area Networking is to be provided by [illegible] and
as such is outside the scope of this proposal. However, [illegible]
devices have been configured on both the front-end processing system
(Digital [illegible]) and the Domain Name and Authentication Server
[illegible] to ensure connectivity to the [illegible] device. The
back-end Digital [illegible] processors are afforded dual routing to
the WAN through the use of Digital's Gigaswitch.
The processors have been sized to meet the requirements at
[illegible] Functional Requirements Docu-
[illegible]
System Architecture
ment. Redundant processors have been configured to support primary processors
and sized to ensure that equal power is provided in the event of primary
processor failure with minimal degradation in operational performance. No
processor is allocated to support more than one primary processor, which ensures
that no two primary nodes may fail and result in an overload condition on a
support processor.
All workstations have equal access to the operational systems to ensure that
authorized users may switch to alternate workstations in the event of a
workstation failure.
The PX Alliance believes that the solution presented offers unparalleled
redundancy of CPU, processor, network, storage, and site level. Experience has
shown that the impact on performance often is underestimated when configuring
redundant systems. Digital offers full processor fail over to a hot processor
with a coordinated roll back with the proposed Oracle relational database.
Context and user roll back will be performed.
Digital currently holds the performance record for transaction processing
utilizing an Oracle relational database system and is a preferred processing
platform by Oracle. The PX Alliance currently holds the world record for the
largest transaction processing system on an Oracle distributed client server
system. Experience gained from this environment of approximately 500 complex
transactions per second affords the PX Alliance insight to preempt issues that
could arise during PX implementation. This enables the PX Alliance to reduce
the time frame for implementation and ensures delivery by January 1, 1998, as
required.
In addition to processors held in hot standby, the solution offered includes
the introduction of a back-up site to protect against earthquakes, natural
disasters, and local civil unrest. The back-up site will be maintained on an
hour-behind basis and will be ready to operate should there be a significant
failure at the primary site.
Secondary processors at the back-up site will be regarded as off-line and able
to provide maintenance [illegible] at the discretion of the PX. Periodically,
maintenance processors will be taken down to enable upgrades and preventive
maintenance to be performed. In order to perform maintenance over the complete
processor set, processors will be rotated from primary to backup to all time
and then down.
All devices will be assigned a designation of primary, backup, dependent, and
down. All devices connected to the Bidding and Scheduling processors will be
regarded as primary with the exception of small DAT (Digital Audio Tape)
systems and CD drives used for software archives and software updates.
The Bidding, Publishing, DNS, and Scheduling systems run on redundant processor
groups. With the exception of small DAT tape systems and CD-ROM drives used for
software archival and software updates, all devices accessed by processors
within the group will be available to the other group members should the
primary processor fail.
Each group may be interrogated and configured through use of a GUI-based
management tool. Fatal and recoverable errors will be tracked for both network
and processor related failures. Tools will be provided to indicate the
operational state of a processor, processor group, or device. All operational
process errors and alarms will be logged for audit purposes.
Function restart is not required on the critical processor groups as the
[illegible] is transparent and automatic. The processors work with the database
system to ensure integrity. Manual restart is required to start the non-
critical systems after processor failure.
Failed processors may be repaired from the on-site maintenance kit. Should a
CPU fail, the processor will automatically restart without the faulty CPU.
Should the failure require repair time greater than acceptable, a decision may
be made to switch to the back-up site.
The proposed system complies with the requirements detailed in the Functional
Requirements Document, Section 11.8 - Device Redundancy and Configuration
Management.
The system has been designed to provide the availability of 99.9 percent for
Bidding and Scheduling and 98 percent for Settlements, Billing and
Administration.
An exception to the power requirements detailed in the Functional
Requirement Document, Section 11.11.1 - Power Supply is to be noted. Power is
required to be provided for both a single phase and a three phase supply at
120-210 VAC. Definitions for the requirements will be made following site
selection. An uninterruptable and [illegible] power
SYSTEM ARCHITECTURE
supply (UPS) scheduled to be available during [illegible] times of the PX
computer systems. The PX Alliance cannot ensure operation of equipment not
supported by a conditioned power supply. The UPS is also required to
provide power to workstations within the PX location.
We strongly recommend that the PX provide a backup generating facility when
utility power is not available. Sufficient battery or transient power is
required to enable operation while the generator [illegible] up to replace
the utility supply.
The hardware installation will meet environmental specifications as
detailed in the Functional Requirements Document. It is required that the
purchaser provide adequate computer facility environment conditioning such
as an [illegible] systems, to be specified by the PX Alliance.
3.4 COMMUNICATION
It is acknowledged that the primary mode of communication with the PX is
via the WEnet Wide Area Network (WAN). The PX Alliance notes that the WEnet
as an Intranet which, by definition, allows firewall services between the
internal Intranet and the external Internet communities.
Provision has been made to enable the PX System to interface with the SONET
multiplexor without loss of bandwidth. It is anticipated that the PX System
will [illegible] the building LAN installed by the Intranet Service
Provider (IaSP) for workstation traffic and printer connectivity. However,
should this not satisfy performance or connectivity requirements, the PX
Alliance will implement an alternative facility.
The network components must be designed to handle a peak load situation.
Any degradation in network performance reduces time to respond to bids and
requests, and results in a reduction of service by the PX client base.
Experience has shown that an hour-ahead [illegible] will be approximately
1,000 bytes in size and a day-ahead energy bid will be approximately 20,000
bytes (including energy and ancillary services). Peak loading and
[illegible] when the day-ahead market closes at the same time as the hour
ahead market closes. At this time 21,000 bytes of [illegible] [illegible]
per participant will arrive on the PX IAM from the SONET Multiplexor.
Generally, overhead [illegible] and UDF acknowledgment [illegible], the
fund expected is [illegible] x 23,100 bytes or 369 6MB.
Since the SONET QC 3 Multiplexor has a transfer rate of 155MBs the data can
clear in three seconds, at 2,066 seconds, assuming only 10% [illegible]
simultaneously. In addition, there is still capability for a portion of
Market Participants to alter their bids via the Web screens and to normal
query traffic to proceed.
It is vital to clear data as soon as possible. With this in mind, the PX
Alliance has chosen to implement OC-3 capability directly to the processor.
For future performance requirements, the PO bandwidth of the 8460 Digital
processor enables the introduction of OC 12 as it becomes available without
a major processor swap out the internet user base and fax processing
equipment will be connected to the network via the Fast Ethernet LAN
running at [illegible]MB/s.
It is believed that fax transmission identified in the Functional
Requirements Document should be increased to a minimum of 26,800 bps to
match the standard PC fast fax systems currently available. Fax processors
provided will be rated at a minimum of 28,800 bps. To enable the use of 2%
of participants using tax simultaneously, 40 analog lines will be required
initially. This number will rise to 700 should participants grow to 10,000
as is projected.
It is noted that the laSF is required to provide PABX and [illegible] bank
facilities. These should include the initial 40 lines for receipt of fax
transmissions from participants. Network fax processing will be provided to
receive up to 40 simultaneous fax receipts.
All networking components will be manageable from a network management
console through use of the SNMP protocol.
3.5 USER INTERFACE SOFTWARE
The PX system users can be divided into two general categories. PX
operations personnel at the Primary and Backup PX facilities, and PX Market
Participants and outside users.
The proposed PX system architecture provides a full client/server
configuration for the PX operator interface. This allows standard desktop
applications and other "user inter
[illegible]
SYSTEM ARCHITECTURE
[ILLEGIBLE] to run on the clients, while the database and the Commercial
and Administrative applications will run on the servers. The standard
Microsoft Windows and Windows NT Graphical User Interface (GUI) are used
as the platform for the PX Operations personnel user interface. The user
interface applications are developed with Borland's Delphi.
3.5.1 Borland Delphi
Delphi is a leading Fourth Generation programming language (4GL) which
offers a complete set of GUI development and deployment tools for high
performance applications. It provides an open design for support of
various hardware and database platforms and offers a [ILLEGIBLE] set of
graphical and tabular display capabilities for client server type
deployment.
The PX Alliance team members have extensive experience in successfully
deploying client/server applications using Delphi technology. It is used
in the core P&SS product, as well as other energy trading products of ABB.
Screens created by Delphi [ILLEGIBLE] Windows standard look, feel and
navigation characteristics in addition to standard dialogue and tabular
displays. X-Y plots and many other graphical capabilities are supported.
Other standard features include display of a button description upon
painting, extensive help facilities, and complex GUI objects.
Delphi's Database Desktop provides a [ILLEGIBLE] and easy to use
environment for applications development. Screens are constructed and
connected to database tables through single point and click functions.
Some of these capabilities include:
- Changing properties of graphical objects directly on screen using
tabbed dialog boxes.
- SQL tools to let you work with SQL tables directly through the Database
Desktop user interface and makes it easier to query SQL tables. In
addition to the standard SQL capabilities, such advanced query features
as use of underlying indexes in live queries, constrain updates to
satisfy query conditions and ANSA-92 SQL-compatible for remote
operations, are supported.
- Movable Toolbars add convenience and can be docked or left floating.
Context sensitive toolbar buttons change based on the kinds of object
active on the Database Desktop window and provide quick equivalents to
menu commends or keystrokes. For example, if a table is active, the
Toolbar buttons will be related to table manipulation.
- Database Desktop Help is organized into a familiar, easy-to-use
book-like table of contents that makes it easier to find the
information needed.
- [ILLEGIBLE] handling uses Windows common dialog boxes for convenience
and [ILLEGIBLE] compatibility.
3.6 Miscellaneous Support Functions
The following subsection details two key system software functions that
are included in this Proposal.
3.6.1 Batch Scheduler and Execution Controller
The Batch Schedular and Execution Controller (BS/EC) program provides for
the sequencing and execution control of various applications.
The PX operation requires automatic scheduling and sequencing of several
application programs in a reliable and efficient fashion. The BS/EC
provides a software facility for the purpose, with support for periodic,
event based, operator initiated, and sequenced application execution. The
execution of such applications as hourly and day-ahead scheduling will
be controlled by this program.
The BS/EC program interfaces with the Bidding and Scheduling systems via
messages passed to trigger the execution of the application sequence.
[ILLEGIBLE]
System Architecture
Execution Trigger
A program or a sequence can be achieved via three different types of
triggers
1 System Event, on which the sequence is to be initialized and
executed by the occurrence of some specific external events.
2 Periodic Cycle, in which the sequence is to be initialized and
executed by a periodic trigger.
3 Manual Request, in which the sequence is to be initialized and
executed by an operator manual request.
Individual programs as well as the entire sequence may be executed on
demand.
Program Components
The BS/EC program is composed of the following components.
Sequence startup - The startup task brings the sequence from the down
state into a ready state with the specified sequence execution mode.
Once ready, triggers proper to the mode are issued to initiate a
sequence (and thus bring it into the active state)
Sequence abortion - This task interrupts an active sequence after the
currently active node(s) completes its execution.
Sequence shutdown - The shutdown task terminates the program or sequence
bringing it into down state.
Sequence suspend - This task suspends an active sequence and brings it
into a suspended state. Upon initializing this task, the sequence will
not recognize periodic and event triggers. The currently executing mode
is then completed prior to suspension of the sequence.
Sequence resume - This task resumes the execution of a program or
sequence previously suspended.
Program Characteristics
The BS-EC program maintains certain information on a database for
programs and nodes under as control. Each such node has an execution
status indicating whether the process is running, and a set of time
stamps to indicate the latest start and completion times. These nodes
also have a set of switches for enabling/disabling its execution for an
external event or a manual trigger.
A node is described by the following set of variables
- Node state defines the current state of the node, the valid actions
that can be requested to it, and the transition to the next state
according to the action requested.
- Node fast start is the time stamp of the fast activation of the node.
- Node fast end is the time stamp of the fast successful completion of
the node.
- Node timeout delay specifies how many seconds the sequence should wait
for an acknowledge message from the node since the last node activation
before it is taken out of service.
- Node error count limit specifies how many consecutive minor errors can
be detected by a node before is taken out of service.
- Node periodic alarm limit specifies the number of maximum basic
periodic cycles between the last successful execution of the node and
the current time, before issuing an alarm.
- Node validity threshold period specifies the time span for which the
latest node solution is considered valid. After that time has elapsed
the solution will be considered obsolete.
The BS/EC program supports the following states for each node
- DOWN The node process not running
- ACTIVE The node is currently executing
- READY The node last execution was successful
- ERROR The node last execution terminated with a minor error
- BLOCK The node execution is blocked due to the status of the switch
associated with the current trigger or one of its predecessor
nodes is in BLOCK, ERROR or DOWN
SYSTEM ARCHITECTURE
- WAIT: The mode is waiting for its previous execution to finalize
before restarting again.
- REQUEST: The execution of the mode is postponed because a
predecessor mode is in REQUEST, ACTIVE or WAIT state or one of
its successors is in ACTIVE or WAIT state.
EXECUTION BRANCHES
- -------------------------------------------------------------------------------
An execution branch is defined as an ordered set of consecutive nodes
(i.e., program executions) between the starting point and the ending
point. Branches may have predecessor branches, starting at the branch
ending point, and/or successor branches, ending at the branch starting
point.
A sequence is at certain execution point(s) when the execution of the
last mode in all the branches preceding the point are completed.
A branch is said to be active if any of its modes is active. Branches
in the sequence have an associated basic periodic unit, which is the
number of basic cycling periods at which all the modes in the branch
are sequentially activated, starting with the first mode in the
branch.
EXECUTION TREE
- -------------------------------------------------------------------------------
An execution tree is a collection of branches connected at points with
no closed loops and with exactly one of its points being the starting
point of all branches connected to it. This point is referred as the
tree root of the tree starting point.
The trigger execution of a tree will start at the tree start point, by
activating all the branches starting from it, and will continue with
the successor branches once their execution is completed. In the case
of the PX it is anticipated that there will be only one tree, though
the system is capable of supporting multiple trees.
3.6.2 HISTORICAL INFORMATION MANAGEMENT SYSTEM
The Historical Information Management (HIM) Server has been
specifically designed to store large amounts of data for long term
archival and to provide capabilities for the data to be retrieved at a
later date for auditing, analysis and reporting. This system is
designed to work in an UNIX/Oracle environment. It is highly
configurable and is designed to provide the flexibility needed to
support the anticipated future data archival needs of PX. Exhibit
3.6.2-1 shows an overview of the HIM Server.
[ILLEGIBLE]
EXHIBIT 3.6.2-1 OVERVIEW OF THE HIM SERVER
[CHART]
PRODUCT OVERVIEW
The features of the HIM may be [illegible] into two key components.
- Data Recording/Archiving Function -- Data Recording System
Configuration, Periodic Data ordering, Maintenance Audit, Short term
RDBMS retention and Long Term Archives
- Data Retrieved -- Application Data retrieval and [illegible] Database
Interface
The HIM Server system, when fully configured, will automatically record
and archive data. Each major function of the HIM server is described below.
Flexible configuration. A configuration icon is provided to customize a
client's site rather than software to meet changing needs.
Database data recording. Data stored in an Oracle or other database will be
exported into the appropriate export files, which are then packed and
maintained by the HIM Server. Accurate name and date information will be
attached to the files for use in future retrievals. Provision is made for
23 and 25 hour days for changeover to and from daylight savings time.
Stored data will not be affected by future database changes. [illegible]
data may be stored initially in a [ILLEGIBLE] database for direct
[illegible] access.
Recording application data. A configurable set of data tables and entities
will be recorded either periodically or when an application requests it. It
is important to note that the [illegible] need not be directly aware of
what is being
System Architecture
recorded, only that a request is made to record data. The data that is
archived will have an accurate name tag associated with the data that will
be used for later retrievals.
PERIODIC DATA RECORDING. Configurable collections of data may be specified
and recorded at periodic intervals. This periodic data will be stored with
an accurate time stamp that will be used for later retrieval.
LONG TERM ARCHIVES. These are defined as archives that may be stored on
off-line media. A configurable number of devices can be collected together
whose media is typically removable. This method of archiving provides for
infinite storage capacity.
DATA RETRIEVAL. An operator may request any data that has been archived to
be retrieved. It is the responsibility of the software to determine the
location from which the data is to be retrieved. A number of available
retrieval options are described in detail below.
APPLICATION DATA RETRIEVAL. Application data stored periodically or by
application request can be retrieved from the archives by an operator
request. The operator should enter the application name to be retrieved,
together with the point in time of interest.
SOL INTERFACE. Any data recorded by the HIM may be retrieved and viewed
through an SQL-based language interface. This interface will allow
[ILLEGIBLE] and formatting of data on a custom as well as a pre-defined
basis.
Interfaces
USER INTERFACE. Custom reports will be supplied to view certain special
types of data. Other reports will be built as the operator selects the
data to be viewed. When the operator has selected the data to be
displayed, the retrieval process will recover the archived data and,
provided with the mapping will extract the required data for the report.
PROGRAMMABLE INTERFACE. A [ILLEGIBLE] set of functions will be provided to
allow other applications to access certain features of the HIM system,
such as:
- Initializing an HIM environment
- Recording pre-defined sets of data
- Retrieving a set of data from a past point in time
- Providing a list of data to be recorded
- Providing a list of all currently archived data
Special interfaces for interfacing the historical data with the
Settlement Module and Dispute Resolution Functions will also be provided.
3.7 Back-Up System
The back-up system has been designed to handle both critical and
non-critical events. A back-up site is to be provided at the PX's
secondary location in case of major environmental disaster, civil
unrest, or major facility component failure.
Data at the back-up site will be updated at least once per hour to ensure
readiness within a one-hour ramp-up time in the event of a primary site
failure. The back-up site provides a complete replication of the primary
site and enables full service to be restored within one hour for critical
systems. The back-up systems are of comparable performance to those used
in the primary site.
Information will be passed to the back-up site through WEnet, including
protocols via Digital's [Illegible]. Transactional information will be
sent to the back-up site to keep the system as up-to-date as possible.
This is to reduce the one hour time lag from the primary site. By
utilizing fast ATM WAN protocols, the home site failure will be
significantly reduced and throughput achieved to create an Extended IAN
topology.
The back-up site will be used to perform daily tape backups, reducing the
load and con[ILLEGIBLE] on the primary operating disk subsystem.
32
System Architecture
3.8 Database Sizing
The 90 day short term storage of all data will be immediately available in
the Oracle database. The long term archival will be via the Historical
Information Management server's optical disks.
The total estimated size of the relational database for the Bidding,
Scheduling, and Settlements sections is given below.
<Table>
<Caption>
Total Daily RDBMS storage requirements for
Bidding, Scheduling, and Settlements
systems (with 30% Overhead) 12 Gbytes
------------------------------------------ ---------
90 day requirement 106 Gbytes
</Table>
Long Term Archival will be via the proposed HIM Server which utilizes
optical disks and has essentially unlimited storage capability.
The details of the analysis leading to the above database sizing is
provided in Appendix [illegible].
3.9 System Performance Assumptions
The PX Alliance accepts the Response Times set forth in Appendix D of the
FRD as the design goals for the PX Systems design and implementation in
decoding how to deliver these performance requirements as [illegible]
contractual commitments, however, several things need to be considered:
- The PX will be one of the first large scale attempts to handle major
commercial transactions via Intranet/Internet technology.
- The detailed design requirements for the PX bidding and publishing
system, in terms of forms design and content, are not yet known.
- The WEPEX protocols for pricing and scheduling are not yet settled.
- The interfaces with the ISO and how these (illegible) work are
similarly subject to potential change.
- Some of the performance requirements, such as display call up times, are
seemingly (illegible) paradigm more appropriate to the ISO [illegible]
systems than to a business system such as the PX Systems.
The systems, individual applications, and forms will be designed for
flexibility with the inherent ability to change during the implementation
process. Some questions of scaling and Internet technology remain.
Performance commitments should be conservative. The PX Alliance proposed
configuration and hardware was selected following careful analysis of
performance versus capital expenditure. The PX Alliance has also negotiated
extremely favorable terms from Digital and Oracle should product upgrades
be needed to improve performance.
The PX Alliance accepts the need for performance commitments from all of
the subsystems and user interfaces in order to meet the business needs of
the PX. If these requirements necessitate response times on the order of 1
or 2 seconds, we will need further discussion with these suppliers,
especially if the criteria may introduce higher costs and schedule risk in
the project.
Based upon current information, we propose to address the performance needs
of the PX Systems as follows:
1. The PX Alliance accepts the performance requirements set forth as
design goals. These goals shall be balanced with equal requirements
for flexibility, schedule, and transparency.
2. The PX Alliance commits to achieve business performance of response
times (illegible) the same order of magnitude of those set forth.
3. The PX Alliance commits that the PX Systems will meet all the external
business requirements. The PX Systems will in fact support the number
of bidders and bids, the time frames required for accomplishing the
day ahead and hour ahead schedule determination, and so on.
4. The PX Alliance proposes to implement a baseline PX system on the
larger hardware, scaled up to PX database requirements, early in the
project. We thus propose that the PX Alliance and PX team members use
this baseline implementation to assess performance issues so that
corrective actions can be taken early in the design phase and critical
performance behavior can be achieved and maintained through the
customization process.
(illegible)
[GRAPHIC]
4. Bidding Module
B i d d i n g M o d u l e
4.0 Bidding Module
- --------------------------------------------------------------------------------
[CHART]
The Bidding Module manages the process of receiving. Al[illegible]dating and
acknowledging bids from market counterparts in a non-discriminatory manner it
interacts with other functions either the PX Systems to p[illegible] as
necessary [illegible] [illegible] the [illegible] and Price Determination and
the [illegible] and [illegible] [illegible] [illegible] [illegible] will provide
all the necessary interfaces [illegible] data entry [illegible] display between
the PX and the [illegible] participants. The [illegible] of the [illegible]
primary functions and interfaces.
* Receives bids managing participant master files and resource capacity
information.
* [illegible] can [illegible] entry through a [illegible] [illegible]
[illegible]
* [illegible][illegible] capabilities for both participants [illegible] and
PX operators Participants can modify bids.
Bidding Module
[Graphic of Map]
through interactive Web screens, where PX operations use AGI based user
interface
- Maintains an audit trail and database of all bids for dispute resolution
as well as for archival purposes
- Provides [illegible] bids to the Scheduling Module
- Provides a proxy communications service to the Settlement Module's
participant notification process
- Interfaces with the Billing and Credit Module to validate participant
bids
- Communicates with the ISO (Ancillary Service bids and Must Take schedule
inconsistencies)
- Alerts PX operator with alarms and messages when necessary
The bidding Module will allow the market participants to provide bidding
information electronically to the PX for generation, lead and ancillary
services. This module will accept and process bid data for both the
day-ahead as well as hour-ahead scheduling functions and will fully support
the proposed [illegible] bidding protocol. This includes the necessary
control logic for the various bid cycles. The open and close times of the
day ahead and hour ahead markets, as well as [illegible] bidding cycles
will be configurable to match the bidding protocols
The Bidding Module will be responsible for the registration of the market
participants, as well as receiving and processing participant Master
file information. The following types of bids will be recognized
- Day Ahead and Hour Ahead Energy bids
- Day Ahead and Hour Ahead Demand bids
- Day Ahead and Hour Ahead Ancillary Services Bids
- Day Ahead Portfolio Bids
In addition to the single bid [illegible] specified by WEREX. The PX
Alliance will also support end formats for both bids (multiple bids in one
[illegible]) as well as bids which are valid for multiple time periods. For
example, day-ahead bids which are valid for many days and hour ahead bids
are valid for many hours.
Computer-to-computer bids [illegible] [illegible] [illegible] [illegible]
[illegible]. "FIF" [illegible] [illegible] [illegible] [illegible]
[illegible] will be supported. The PX Alliance proposes to provide a
unified web technology for the Bidding and Publishing functions. This will
eliminate the need for providing the participants with any PX special
software for companies no-computer links. A standard We browser is all that
is required. Participants can [illegible] the browser to register with PX
[illegible] bids, receive notifications and acknowledgements as web as
schedules, market clearing prices and settlement results that use of the
WEnet based Intranet will enable participants to establish a direct link
with PX, avoiding delays typical in public internets. The participants can
enter data using interactive Web screens, request upload and download of
individual or bulk bid and other data files, receive dynamic information on
the Web screens, and exchange e-mail. The upload and download functions
will be FTP compatible.
FAX with OCR capability will be supported as the secondary technology.
The Bidding Module will provide the necessary security to prevent
unauthorized and unregistered users to access the bidding system. Any
access to the system will be recorded for auditing purposes
The proposed Bidding Module will be based on ABB's Pooling and Settlement
System (P&SS) products, which is a field-proven technology consisting of
bidding, scheduling and settlement functions. The most recent
implementation of this product has been on the Singapore FLB system. P&SS
provides the overall database and [illegible] structures and supporting
[illegible]needed for the bidding system. P&SS's design closely matches the
PX requirements and provides an excellent starting point for implementing
PX specific lending protocols. P&SS's basic design is based on
[illegible]-based building protocols. A participant's bid files are
appropriately named and are placed in a secure directory assigned to that
participant. The P&SS software [illegible] [illegible] [illegible]
[illegible] [illegible] [illegible] [illegible] [illegible].
[illegible] [illegible] [illegible] [illegible] [illegible] [illegible]
[illegible] [illegible] [illegible] [illegible] [illegible] [illegible]
[illegible] [illegible].
[illegible]
Bidding Module
leted by ABB as a product called PowerWeb. This technology will extend the
base [illegible] capabilities by integrating Web based interfaces for data
file transfers, participant [illegible] active entries, and participant
notifications.
The use of these base technologies will allow the PX Alliance to focus its
development [illegible] on the PX specific needs and its demanding
performance targets.
The Bidding software will be integrated with the proposed PX hardware
system to provide the high-performance, [illegible] ability, and security
needed for the California Power Exchange. The PX system architecture (as
detailed in Section 3) has been designed with a [illegible] emphasis on the
performance reliability and security requirements of the Bidding Module
where a large number of participants may potentially be submitting bids for
different time frames and market scheduling cycles. An attempt has been
made to design the hardware and the software configurations, described
later in this section, according to the required performance
characteristics for the Bidding module. The performance and [illegible]
information provided in the Functional Requirements Document, has been
analyzed in detail in the process of arriving at the proposed bidding
solution. If selected, the PX Alliance will continue its focus on the
performance requirements of this module, following the award of this
contract. This will include early prototyping to tune the interface and
database partitioning design and use of Web and database experts and
consultants from the PX Alliance teams and from Oracle) in the design and
[illegible] process.
The remainder of this section is organized as follows
- A functional overview of the Bidding module is provided in Section 4:
- Section 4.2 provides a more detailed functional breakdown of this module,
with emphasis on key functions such as bid data collection, verification,
and participant notifications
- Section 4.3 provides a review of the various functional interfaces for
the Bidding Module
- The various user interaction [illegible] as described in Section 4.4
- Section 4.5 provides a summary of some of the [illegible] issues
associated with [illegible] [illegible]
4.1 Functional Overview
The functions of the Bidding Module can be summarized as follows
- Serves as a flexible and user friendly interface for the market
participants to interact with the PX. This interface and support user
registration, master the data submission and [illegible], all phases of
bidding, user notification, as well as publishing functions (detailed in
Section 6).
- Provide graphical user interface capability using Web page technology to
facilitate access by market participants without a need for participant
software. Support interactive Web screens, dynamic fields, and data file
upload and download.
- Support of Intranet and Internet types of connections over WEnet and
public internet.
- Support all the functions needed for user registration, user password
security maintenance, and login activity audit
- Provide for submission, update and verification of master data file.
Provide interactive Web pages and data file processing capability for
this purpose
- Support all the required bidding protocols, including hourly, daily and
ancillary services bids, as well as [illegible] day-ahead bidding, and
must-take information
- Provide a database for storage or bid data as well as other information
such as master data, validation information, accept/reject notification,
etc. Data structures will be provided to support the negative bidding
process and the required audit trail information. Such data will be
maintained in an Oracle relational database.
- Perform bid validation and notification process. The bid validation
process will be designed to support the system peak load conditions.
- Support of Fax and OCR capabilities for bid and other data submission.
It is expected that Fax input will not be used as a primary means of bid
submission by participants, but will be used as a backup method.
- Provide notification of validation information to applicable market
participant. The notification will be normally through dynamic messaging
fields or Web screens. Special JAVA Applets will be used to provide for
periodic
B i d d i n g M o d u l e
[MAP GRAPHIC]
update of such message fields on participant screens, without the need
for a continuous connection between the participant Web screen and the
server. E-mail notifications will also be supported.
-- Provide user interface capabilities for the FX operating personnel for
such functions as monitoring o the bidding process, contract access to
bid data, manual entry and modification of Fax data and the associated
OCR processing, review of bidding statistics, and the overall bidding
system data maintenance. The PX operating center user interface will
be based on [illegible].
-- Provide data interfaces to other PX functions including Scheduling,
Settlements and ISO data communications subsystem.
-- Provide all necessary information to the Historical Information
Management Module or long term archival.
In summary, the Bidding Module is the primary gateway or the market
participants to interact with the PX flexibility and performance have been
considered as the two major driving factors for the design of this module.
4.2 FUNCTIONAL DESCRIPTION
From a functional viewpoint, the Bidding Module is composed of the
following key components:
-- Participant Registration and Master File Handler
-- Bid data collection
-- Bid verification
-- Notification
-- Bid alterations Manager
-- Must-take Processing
-- Bidding/FX Operator Interface
-- Batch Schedules
B i d d i n g M o d u l e
A conceptual overview of the Bidding Value [illegible]
EXHIBIT 4 2-1 Bidding Module
[CHART]
Bidding Module
[GRAPHIC OF MAP]
We realize that the PX bidding protocols, formats and rules may evolve
over the next several months. The PX Bidding and Bid Evaluation Protocols
published by the PX [illegible] Team have been used as the basis of the
proposal. It is assumed that these protocols will be [illegible] either
prior to, or soon after, award of the PX system contract.
The proposed design of the Bidding Module assumes that bids are
represented as files with well defined and fixed formats. A bid then may
contain a single bid or include bids for different time frames (bulk
bids). Different [illegible] formats will be used for different types of
bids, e.g. day-ahead and hour-ahead.
4.2.1 REGISTRATION AND PARTICIPANT MASTER FILE HANDLER
The purpose of this function is to provide the necessary facilities for
registration of market participants and to receive information about a
qualified participant. The information will be stored in the PX database
for use by other functions and/or subsystems. This function handles the
verification of all elements of the Master Data file as applies to a
participant. The current qualification status of the participant is
verified by the Participant Master File Handler prior to acceptance of
bids for further processing. All ownership and contractual information are
verified by this functional component.
This function also handles security password assignment and control, as
well as participant data and the directory management.
This function will interface with the Bidding and Credit Module to obtain
information regarding participant's financial status and credit line.
Also, such information as [illegible] [illegible] periodic bidding,
physical scheduling plant, and other related bidding criteria will be
handled here.
4.2.2 BIDS DATA COLLECTION
The Bid Data Collection function receives [illegible] [illegible]
[illegible] participants through computer-to-computer link (Web based),
the upload, and Fax input data. The primary method for providing bids is
through a line transfer using internal Web technology through WEnet. This
allows a number of participants to prepare bid data in a secure
[illegible] [illegible] [illegible] [illegible] to the PX system via Web
screens prior to the specific [illegible][illegible] intranet and internet
access capability, as well as interactive Web screens are provided,
achieving a [illegible] [illegible] [illegible] capability. This method is
described on [illegible] [illegible] in Section 4.[illegible].
Users may change data already validated or submit new data for validation
up to the close of the associated market [illegible] subject to
[illegible] bidding protocols and rules.
Syntax error checking will be performed at the [illegible] site whenever
possible. This is for both interactive data entry via the Web page as well
as [illegible] bulk bids. The bid data, upon arrival at PX, will be
further checked for consistency and stored in the participant's data
directory.
In addition to daily and hourly energy bids (both single), the Bidding
Module will also allow reception of bids for Ancillary Services. Both
demand and supply service bids which include various forms of reserves and
[illegible] power capabilities can be bid into the system by the market
participants. The Bid Data Collection function performs the basic
format-related verification for the ancillary services for both the day
ahead and the hour-ahead markets and stores them in the main PX database
for further processing.
Special attention will be given to properly handle, organize, categorize
and archive various types of bid data, e.g. day ahead [illegible], hour
ahead, ancillary services and ISO related information.
As a backup entry process, the Bidding Module will provide the capability
for participants to submit bids by means of facsimile transmittal. The
facsimiles received by this module will be converted to text files through
the use of an Optical Character Recognition (OCR) process. The text files
can then be reviewed and modified as necessary by the PX [illegible] prior
to storage in the database to the [illegible] function.
4.2.3 BID VERIFICATION
[illegible]
[illegible]
Bidding Module
providing the market has not closed. End consistency can be broken down
into the following different types of [illegible] checks
- Completeness Completeness indicates the bidder has entered all the
required parameters for [illegible] to be evaluated
- Individual Data Checks Individual data checks examine constraints
placed on individual data parameters either universally applied as a
given field or constrained by pre-qualification data, such as a
generation bid not exceeding the maximum operating capacity of the
[illegible]
- Relationships Relationships checks [illegible] at the interdependence
of certain parameters supplied to the Bidding subsystem, such as
consistency between day-ahead bids and hour-ahead bids
The verification and notification components are further illustrated in
Exhibit 4.2.4-1. In order to improve the performance of the bid
verification process, all permanent information are extracted from the
PX database and are stored in the Validation database. Also, bid data
received by the Collection function is stored in a database buffer for
use by the Verification function, thereby providing a high performance
environment for this [illegible] activity. The results of the
Verification function are then stored in the PX database
4.2.4. Notification
There are many different types of notifications that the Bidding Module
must provide to users of the system concerning the status of a
particular bid. Some examples are:
- Receipt Acknowledgment of bid data received by the PX
- Validation Identification of data items found to be invalid, and the
associated reasons
- Confirmation Notification to the bidder that the data has now been
accepted for scheduling evaluation
- Acceptance, Rejection Notification to the bidder as to whether or
not the bid has been accepted by the Scheduling Module.
- Results Available Compartment results from the Scheduling Module are
available to the [illegible] information
The Notification function sees appropriate flags to indicate types of
validation and other data available for the market participants' review. We
propose to use a Web dynamic messaging capability as the primary means of
notifying participants of the bid verification status. These messages will
be automatically displayed on the participants screen. This is achieved by
providing a scrollable message box on participant's Web page. Java
applications will ensure periodic update of these messages as they are
generated on the server side in addition, e-mail messaging will also be
supported
[GRAPHIC OF MAP]
Bidding Module
EXHIBIT 4.2.4-1 Bid Verification and Notification
[CHART]
As shown in Exhibit 4.2.4-1, the Notification function is designed to work
with its own local database for easy and fast access by the market
participants. It is the responsibility of the Notification function to
keep its local database synchronized with the centralized database, and
to provide a high-performance mechanism for participants to receive
information concerning their [ILLEGIBLE] and [ILLEGIBLE] inquiries.
4.2.5 Bid [ILLEGIBLE] Manager
The purpose of this [ILLEGIBLE] manage the [ILLEGIBLE] bidding [ILLEGIBLE]
manage the various stages of the [ILLEGIBLE] [ILLEGIBLE] bidding process
and issue messages to inform participants of the status of the bidding
cycle. It also manages the exchange of data between the Bidding and
Scheduling Manager as well as between Bidding and ISO Communications
Subsystems [ILLEGIBLE] which affect the management of the alternative
bidding process. A number of [ILLEGIBLE], market operating [ILLEGIBLE]
times, etc. will be fully configurable by the PX system administrators.
[ILLEGIBLE]
Bidding Module
4.2.6 MUST-TAKE PROCESSING
The Bidding Module receives must-take schedules from two sources:
- Directly from the UDC's
- From the ISO
The Must-Take Processing function compares the two sets of schedules to
ensure that they are identical. If they are found to be identical, the
schedules are stored in the PX database for use by the Scheduling and
Price Determination Module. If the schedules are not identical, then the
schedules received from the ISO are stored in the PX database, with
appropriate notifications transmitted to the UDC's involved. The ISO is
also informed of any such discrepancies detected by the Must-Take
Processing component.
4.2.7 PX OPERATOR INTERFACE
The Bidding/PX Operator Interface provides an interactive capability
locally as the PX for interactions between PX personnel, bidding and the
PX databases. This is accomplished primarily through Delphi based GUI
client applications in addition to operator screens, various hardcopy
reports are also provided.
4.2.8 BATCH SCHEDULER
The purpose of the Batch Scheduler is to coordinate the execution of the
various functional modules within the Bidding subsystems. This component
is responsible for keeping track of the overall bidding process as well
as internal data exchanges. The Batch Scheduler is [illegible] in
conjunction with the [illegible] Manager.
4.3 FUNCTIONAL INTERFACES
The Bidding Module (along with [illegible] Module [illegible]) has the
following interfaces:
- Provides bid data to the Scheduling and Price Determination Module for
preparation of schedules for day-ahead and hour-ahead operations and for
calculation of market [illegible] prices.
- Receives schedules and prices from the Scheduling and Price
Determination Module.
- Receives [illegible] end results for notification to Market
Participants.
- Provides all pertinent data to the Historical Information Module for
long-term storage and for [illegible] and [illegible].
- Communicates with the ISO regarding must-take resources and ancillary
services. All valid ancillary service bids received by the Existing
Module are transmitted to the ISO.
4.4 BIDDING MODULE USER INTERFACE
Market Participants have different capabilities and varying needs for
interfacing with the PX System than the PX system operators and PX
personnel. Therefore, the user interface for the Market Participants are
independent of those of the PX personnel.
4.4.1 MARKET PARTICIPANTS USING WEB PAGES
The Bidding Module will be accessible to Market Participants through Web
pages, utilizing standard third party Web Browser products such as,
Netscape A Web Server and Firewall, which are described in more detail
Section 6.D, Publishing Module, act as a front-end to the Oracle-based
relational database. This configuration provides ease-of-use and
single-session log-in with multiple-transaction capability. This
technology has been used successfully by the PX Alliance for the OASIS
product and is the basis for the Bid Box Module for New York Power Pool
(ABB's PowerWeb).
BID COPYING, DELETION, AND MODIFICATION CAPABILITIES
The Bidding Module will provide participants with the facility to review
and, if necessary, delete or modify already submitted data that apply to
future [illegible] or markets. The participants may also, copy and
[illegible] previously submitted data for current submissions.
[illegible]
[GRAPHIC OF MAP]
Bidding Module
4.4.2 UPLOAD/DOWNLOAD
Upload and download [illegible] capabilities will be provided in
conjunction with the Web technology, as a method [illegible] to interact
with the system. The [illegible] and download [illegible] will be FTP
compatible. The system will support these capabilities through Internet
and Intranet (WEnet) connections. The PX Alliance recognizes, based on its
experience in [illegible] markets, that the larger participants such as
the UDCs are likely to automatically generate [illegible]. The bidding
system will have the capabilities to recognize and accept such bulk bid
portfolios.
4.4.3 PX OPERATOR DISPLAYS
The PX operator displays for the Bidding Module will be provided based on
ABB's P&SS product and new displays will be built using Delphi [illegible]
technology. Hardcopy responding capability will also be provided.
4.5 SUMMARY
The proposed Bidding Module provides a robust interactive package for the
market participants to interact with the PX. A great deal of emphasis has
been placed on the sizing and performance requirements of the PX in
configuring the architecture for this critical subsystem. The PX Alliance
is confident that, with proper attention to the following items, it will
be possible to make the PX system operational within the desired time
frame:
- Bid data parameters (lot generation, load, and ancillary services) for
both day-ahead and hour-ahead bids must be clearly specified before
completion of the final software design phase.
- Information regarding participation registration must also be
specifically identified [illegible] the development phase.
- Validation rules must be well established and agreed [illegible] prior
to the start of the Design phase.
- Agreement on the number and content of the Web pages and forms must be
achieved before schedule development can be completed.
- A high level of involvement between the PX staff and PX Alliance is
recommended during the Design and Prototyping phase of this module to
take advantage of the PX Alliance members' extensive experience
[illegible] and to address the [illegible] changes to interfaces between
the PX and ISO.
4.6 ASSUMPTIONS
The following additional assumptions were made in interpreting the PX
requirements for the Bidding Module.
Two options have been specified as the addendum for the Ancillary Services
bids. It is assumed that either the Sequential A/S Auction (Option 1) or
Simultaneous A/S Auction (Option 2) will be chosen as the correct option
prior to the start of the project. In [illegible] the PX system hardware,
it has been assumed that an average of 13 "day ahead" A/S bids and an
average of 36 "hour ahead" A/S bids will be submitted per participant per
day. Though these figures are based on Option 1, it is assumed that these
will also hold true for Option 2.
[GRAPHIC]
5. SCHEDULING AND PRICE DETERMINATION MODULE
Scheduling and Price Determination Module
5.0 Scheduling and Price Determination Module
[CHART]
5.1 Overview
[ILLEGIBLE]
[ILLEGIBLE]
Scheduling and Price Determination Module
[ILLEGIBLE PAGE]
Scheduling and Voice Determination Module
Prepare Hour-Ahead Schedules
1 Submit to the ISO new [illegible][illegible]
[illegible]
2 Submit revised [illegible][illegible]
Calculate Prices
1 For each day-ahead [illegible]
[illegible] prices [for energy under [illegible][illegible]
2 For day-ahead preferred,[illegible] schedules
- Market [illegible]
- Ancillary services capacity [illegible]
Inform Participants
The market participants are [illegible]
- Day ahead energy [illegible]
- Hour ahead energy schedules
- Day ahead [illegible]
- [illegible]
- Day ahead market [illegible]
- Hour-ahead market [illegible]
- Day ahead market [illegible]
- Hour ahead market [illegible]
Inform Settlement Process
[illegible]
[illegible]
[illegible]
Exhibit 5.1.2 Revised Day-Ahead Scheduling Protocol
[CHART]
[illegible]
Scheduling and Price Determination Module
required by the amended specification [illegible]
The proposed SPD [illegible] also
aggregate [illegible]
[illegible]
[illegible]
obtained from the scheduler and adjusted as necessary for other [illegible] and
other considerations as specified in the business rules.
The proposed [illegible] for SPD is a [illegible] as required by the amended
specification. [illegible] Organization Scheduler [illegible] programming
methodology for generating optial schedules and [illegible]. This will allow the
treatment of [illegible] [requirements contraints][illegible] process.
[illegible]-Ahead Scheduling and Price Determination [illegible] (Section
[illegible])
[illegible] will contain processing [illegible] very similar[illegible]
scheduling [illegible]
- - [illegible]
- - [illegible]
- - [illegible]
- - [illegible]
- - [illegible]
- - [illegible]
- - [illegible]
- - [illegible]
- - [illegible]
- - [illegible]
Exhibit 5.1.3. Revised Hour-Ahead Scheduling Protocol
[CHART]
[illegible]
[illegible]
[illegible]
S c h e d u l i n g a n d P r i c e D e t e r m i n a t i o n M o d u l e
[GRAPHIC OF MAP]
transfer constraints will be developed by the ISO and provided to the PX
in a timely manner.
Though not required for the California PX, ABB is currently implementing a
resource scheduler integrated with AC power flow and contingency analysis
for the New York Power Pool (NYPP). This system will provide a full
function security constrained scheduling package, which can simultaneously
address network security, as well as price-based schedule optimization.
The experience gained in this process will be applied indirectly to the
California PX project for implementation of this module.
5.1.5 SPD DATABASE [FRD SECTION 4.3]
The SPD Module will contain an extensive database to hold both current and
recent data, and an audit trail of actions taken. Historical data will be
held until the archive function moves the data to more permanent storage.
This transfer is planned for system performance measurement, system
audits, as well as dispute management.
Data security will be controlled by an authorized administrator who will
define the database access map which includes authority levels (e.g. read
only).
The database functionality is partitioned into live sections:
* Input from outside the SPD Subsystem:
All input from outside the SPD will be time tagged and kept as received
for processing and archiving. This includes data from the ISO as well as
internal PX data such as that from the Bidding Module.
* Outputs to outside the SPD Subsystem:
All data sent out from the SPD will also be time tagged and archived.
* Interfaces with SPD operators:
Interface activities with the SPD operators will also be logged,
including system commands received from operators, any changes made to
the system or data, and reports provided to the operators.
* Working storage:
Working storage will contain such information as intermediate processing
results and for temporary storage for data being transferred between
processes.
* Internal processing results, activity trail:
Those internal processing results identified for saving will be tagged,
and later archived.
5.1.6 USER INPUT/OUTPUT [FRD SECTION 4.4]
Data and operator action trails will be maintained in the SPD database.
Process activity (progress) will be displayed in a process flow format.
Text/data reports will be provided from the database using predesigned
forms or custom inquiries. The database forms utility will be used to the
maximum extent for internal displays.
No exceptions are taken to this paragraph of the FRD in terms of what
information will be displayed.
5.1.7 DATA INTERFACE [FRD SECTION 4.5]
Data interfaces will be provided between the SPD Module and other PX
Modules, the ISO, and other external systems (particularly Market
Participants). All external interfaces, including those via Fax, will be
through a communications server. Internal interfaces will be via a LAN or
direct object access. Interface protection and buffers will be provided.
The functionality as outlined in the PRD will be provided.
5.2 FEATURES OF THE PROPOSED SCHEDULING AND PRICE DETERMINATION MODULE
The process flow diagrams for the SPD Module are shown in Exhibit 5.1.2.-I
and in Exhibit 5.1.3.-11c: the Day-Ahead and Hour-Ahead markets
respectively.
The SPD package:
* Is composed of a Resource Dispatch Scheduler (RDS) to schedule and to
price supply/import, demand/export, and ancillary services and a Program
Scheduler to control the process flow. The Resource Dispatch Scheduler
will use the simplified algorithm specified in the FRD for scheduling
energy and A/S. As an alternative, the PX Alliance would offer a
Resource Optimization (ROS) in place of, or in addition to, the Resource
Dispatch Schedule.
33
Scheduling and Price Determination Module
- Can treat energy and ancillary services markets either Sequentially
(FRD Option 1) or Simultaneously (FRD Option 2).
- Can handle inter-zonal transmission constraints represented by
linear constraints on the generation.
- Can handle both generation/import and load/export resources.
- Can treat resources either as self committed or, optionally, can
determine the optimal Resource Optimization schedules.
- Can treat energy and ancillary services as hard or soft constraints.
- Can model transmission losses through the use of Generation Meter
Multipliers (GMMs).
- Uses a unified scheduling method both for the daily and hour ahead
markets.
- Models cost and availability of regulation and reserves.
- Models area/zonal reserve and regulation constraints.
5.2.1 Schedulers
The ABB team of the PX Alliance is the leading supplier of resource
scheduling software for the electric power industry. The PX Alliance has
successfully implemented price based schedulers for a number of power
pools and deregulated markets around the world. This expertise and its
suite of scheduling applications puts the PX Alliance in a unique position
to provide the PX with a transition path to react to changes in the
scheduling protocols that may evolve.
Resource Dispatch Scheduler and Price Determination
As required by the FRD, the market participants would be responsible for
the inter-temporal constraints. This would mean that resources will be
self committed as they are offered to the market. However, fast solution
times are required to facilitate the iterative bidding and scheduling
process outlined in the amended FRD.
With hourly [ILLEGIBLE], the scheduling requirement is very similar to an
"economic dispatch" process. A master stack is created where available
energy blocks are sorted by price.
Bid loads and external interchange (purchase and sale offers) can also be
included in the stack. Adjustments for must-take supply and demand are
made, at which time over generation conditions can be detected for
special processing. Sub-stacks can be maintained for each zone to
accommodate power transfer limits and zonal pricing should congestion be
identified. A similar multi-area scheme has been implemented by ABB for
several customers.
The Market Clearing Price is determined by using a search method to
determine at what price the demand matches the supply. The supply/demand
price curve represented by the stack is one of the outputs required of
the system.
Ancillary Services Scheduler and Price Determination
Post analysis to determine the adequacy and price of self-supplied
ancillary services will be supported. A similar stacking scheme is a
strong candidate for performing this function. The methods outlined in
Section 4.2.1.6.1 or Section 4.2.1.6.2 of the RFD will be implemented to
determine the schedule and the price for ancillary services.
Price Based Resource Optimization Scheduler and Price Determination [illegible]
ABB's Resource Optimization Scheduler (ROS) can be used to produce
resource schedules where the commitment schedule is input thereby
modeling self-commitment. The package uses Linear Programming
optimization method to schedule both energy and ancillary services
simultaneously while considering all constraints including transmission
flow constraints. To model the transmission constraints, the package can
use simple inter-area import/export constraints, DC power flow models, or
AC power flow models. In addition, this package has the advantage that it
can generate commitment schedules if, in the future, the need for
determining the optimal commitment schedules for resources arises. This
method of scheduling is currently being used by other power pools. For
example, ISA (Colombia) has considerable hydro that must be considered in
the scheduling, as well as zonal (multi-area) constraints. The NGC
implementation is capable of handling a large number of bid parameters,
modeling all of England and Wales, and considering a
[ILLEGIBLE]
[GRAPHIC OF MAP]
Scheduling and Price Determination Module
large number of power transfer constraints. Recent modifications for the
New York Power Pool includes modeling reserve and regulation bids. The
ROS models multiple levels of reserve including regulation, spinning and
non-spinning reserves.
5.2.2 [illegible]
The PX Alliance's experience in providing schedulers and price
determination systems for other bid based Power Pools has reinforced
the need for certain system attributes. These are:
- Accuracy/Rule Compliance
- Ease of Modification and Expandability
- Reliability
- Processing Speed
- User Friendly, Automated
- Timely Development and Delivery
- Audit Trails and Auditability
Accuracy/Rule Compliance - It is essential that the logic implemented
in the Bid Evaluation and Scheduling system faithfully mimic the
relevant WEPEX rules. Procedures for establishing such consistency were
used in the NGC GOAL replacement project undertaken by the PX Alliance
team members. In this project an extensive set (1,000+) of test cases
were established, developed from the parsing and analysis, that formed
a base "test harness." As new functionality was added to the code,
corresponding cases were added to the test set. The tests were
initiated using a small data set, which eased error diagnostics. Once
the system passed the tests with the small data set it, was subjected
to tests using a robust data set modeling the entire England/Wales
system. A similar development process is proposed for the PX system.
Ease of Modification and Expandability - It was become apparent from the
PX Alliance's experience with other bid based power pools that the pool
rules will change, with changes being more frequent during the early
phases of PX operation. In fact, from past experience it is likely that
some modifications or clarifications of the business rules will emerge
from running the test cases during the market trial period. In ABB's
experience with other pool operations such as ISA (Colombia) that it
has been necessary to alter the business rules and the schedules as the
market has evolved. In both ISA and Alberta, this has been the result
of phased implementation of certain business rules as well as market
evolution and unanticipated market reactions to new business rules. The
ease of modification will be achieved by the flexibility allowed by
modular design, careful documentation, and the use of 4GL and other
higher level standard builder/implementation languages. Modification
ease is required not only in the processing logic but in the
dimensionality, the latter to address the stipulated subsequent
increases in market size.
The flexibility as indicated above applies not only to dimensionality,
but to processing functionality. The FRD calls for a simplified energy
bidding scheme based on energy prices. If the PX decides to modify the
modeling to include congestion management and/or combined
reserve/energy dispatch and/or commitment optimization, then the PX
Alliance has existing software available to supply these needs.
Reliability - The PX Alliance's experience providing schedulers for
other pooling applications has made it aware of the intricacies and
attention needed in the data preparation system to assure that the
scheduler performs its job reliably. This is in addition to those
redundancy provisions being implemented for hardware failures.
Processing Speed - In addition to using the most advanced hardware,
careful design of the database and processing logic are required for
efficiency and to assure timely completion of each required task. The
scheduler for the California PX will incorporate advanced sorting and
filtering techniques imposed on a straight-forward stacking scheme to
rapidly produce the schedule. For such large databases, data access and
storage times are of concern. Where necessary, non-relational
intermediate databases will be used, much as implemented by ABB in its
real-time control systems. To assist in task completion speed, process
oriented data organization will be used throughout. In addition,
parallel databases and parallel data access features will be used where
practical.
Timely Development and Delivery - The timetable for delivery of the PX
system is very short, demanding that existing designs, code and
technology be used whenever possible.
[illegible]
Scheduling and Price Determination Module
However, it is recognized that the California PX will be somewhat unique.
ABB's prior experience in the design of the NYPP system for de-regulated
bidding, design and the delivery of the Singapore system, and involvement
with Alberta, Colombia, NGC at the UK, and ESKOM demonstrate "why" the PX
Alliance can deliver the PX Systems on schedule. In this implementation,
existing shells, designs, processes, and code will be used as applicable.
User Friendly - In this case "user friendly" goes beyond just windows and
pull-down menus. It extends substantially into task automation. With the
large volume of data involved, the operator(s) must be continually aware
of the process status of each task, notified by the system quickly and
succinctly of any problems, and be given the facility to delve deeper
(with diagnostic assistance) into any facet of a task. In normal task
operation, each process should be entirely automatic to the greatest
extent possible.
Audit Trails and Auditability - There are two aspects to the auditability
needed for this system. One involves tracking what the system has done,
and the other involves how it does it. The former includes in its simplest
form, the tracking and time stamping of all inputs and outputs, including
operator actions as well as the retention and archiving of all data being
passed. The data archived will be in such detail as to allow the
recreation of any case in question. This information will be needed for
the handling of disputes as well as the assessment of systems performance.
The "how" question involves documentation of the process as it was
implemented. This will be needed to defend against challenges as to
whether the system accurately implements the business rules. The PX must
be prepared, and the system and its documentation designed, to satisfy
these disclosure requirements.
5.3 ABB EXPERIENCE WITH SCHEDULING AND PRICE DETERMINATION SYSTEMS
The PX Alliance has been working with a number of organizations worldwide
to implement open market power trading solutions.
In addition, the ABB team of the PX Alliance is the largest supplier of
electric resource scheduling software worldwide having supplied unit
commitment and similar systems to electric utilities representing more
than 40% of the US generating capacity, as well as electric systems in
other parts of the world.
5.3.1 PROJECTS
The following lists some of the ABB experience directed specifically at
systems designed to operate in a fully de-regulated bulk power
environment. In this new structure, offers for the supply and purchase of
power are submitted to an entity, such as the PX, which is responsible for
a number of functions. These include accepting bids/offers according to a
very specific set of rules, developing schedules to minimize electricity
costs while conforming to these rules, and providing settlement services
in terms of charging power purchasers and paying suppliers. It should be
noted that these systems must not only process information consistent with
the rules set forth, but the power exchange system must be reliable and
dependable with carefully designed security and backup systems. It must
also facilitate audits of not only the bid acceptance system but the
entire pooling and settlement process. An experienced provider with proven
products world-wide, ABB brings to the PX Alliance the major capabilities
required by the PX to meet the January 1, 1998 deadline for service.
NATIONAL GRID COMPANY - UH
ABB has been working with NGC, the National Grid Company and power
exchange for England and Wales, since 1989 to first replace and then
refine its current scheduling program. The functions of this program are
to develop the best schedule of resources from the bids/offers submitted,
and consequently minimize System Marginal Prices. The program is used in
the day-ahead as well as the near-term mode, and in the settlement
process. Transmission unconstrained and constrained modes are used in
order to capture the schedule and cost implications of transmission
constraints. Extensive effort has been expended by ABB, under the
direction of NGC, to assure the auditability of this process. ABB has also
supplied software to National Power PLC, Scottish Power, and Scottish
Hydro for both internal scheduling and for bidding into the NGC system.
59
[GRAPHIC OF MAP]
Scheduling and Price Determination Module
POWER POOL OF ALBERTA
The Power Pool of Alberta began operation January 1, 1996, and is the
first de-regulated pool in North America. ABB continues to work with this
pool, having provided it with the Couger scheduling software to accept and
process bids, and develop an optimal schedule.
INTERCONNECTION [ILLEGIBLE] S.A. (ISA) - COLUMBIA
On January 1, 1996, Columbia, under the auspices of the national grid
company ISA, began operation of one of the first de-regulated pools in
South America. ISA uses ABB's Couger product to process bids and develop a
generation schedule. The ISA Pool is somewhat unique in that the majority
of the energy provided is hydro power which is bid at the individual hydro
plant level. Price levels of bids are dependent upon the availability of
water, and have demonstrated significant variability throughout the year.
The Columbia electric system can be constrained by the transmission
network and the Couger multi-area modeling capabilities have been enhanced
to meet the ISA requirements.
[ILLEGIBLE] - SINGAPORE
Evolving from the previous Public Utility Board (PUB) of Singapore is one
of the first de-regulated power pools in Southeast Asia. This pool is
scheduled to become operational in late 1996. ABB was selected to supply
the entire system, including hardware and software for pooling operations
and settlement under a turn-key contract. Final acceptance testing of the
system was completed in July of 1996, approximately six months after
contract signing.
[ILLEGIBLE] - South Africa
ESKOM, the national utility of South Africa, recently completed an in
depth evaluation of ABB's Couger software for use as the scheduling
software for the South Africa Pool. Eskom implemented the priced based
Couger scheduling software in late November, 1996.
NEW YORK POWER POOL, NY
ABB has been retained by New York Power Pool (NYPP) to act as consultant,
designer/developer, and supplier of a system to meet de-regulation
requirements of New York. At this time, the de-regulation format and pool
rules are not completely defined/approved and are not public information.
ABB has acted as a consultant, provided input for the pool energy exchange
and pool operations systems for the implications of various rules and
processes (e.g. dual vs. single settlement systems, locational based
marginal pricing, etc.), and as a supplier of software and hardware to
meet the pool needs in a de-regulated environment. A prototype system
containing a full function scheduler which employs AC power for and system
security constraints has been developed for NYPP. This prototype system
extends the scheduling software used for the NGC system to incorporate
iterations with the power flow and security analysis for on-line
congestion management. A fully functional product is under development for
installation at NYPP in 1997.
58 [LIGHT BULB GRAPHIC]
S c h e d u l i n g a n d P r i c e D e t e r m i n a t i o n M o d u l e
5.4 ASSUMPTIONS
The PX Alliance has made the following assumptions related to the SPD
module:
* For the energy and A/S auction, it is assumed that either the Sequential
or the Simultaneous option will be implemented. It is also assumed that
the decision will be made at the start of the project.
* It is assumed that the power transfer constraints will be developed by
the ISO and provided to the PX in a timely manner.
* The PX Alliance has not included tools for Voluntary Congestion
Management (Section 4.7.3 of the FRD). It is assumed that during the work
statement phase of the project the requirements of the PX will be
discussed and the proper tools for congestion management will be
selected. The price of such tools is therefore not included in this
proposal.
[illegible]
[GRAPHIC]
6. PUBLISHING MODULE
P u b l i s h i n g M o d u l e
6.0 Publishing Module
- -------------------------------------------------------------------
[CHART]
The purpose of the Publishing Module is to provide Market Participants access to
PX information, including scheduling results, settlements results, and other
market related information through WEnet, i.e. Intranet and Internet. The
Publishing Module utilizes the same base Web technology offered for the Bidding
Module. This provides the Market Participants with a common means of
interfacing with the PX. The recent advancements in the Web technology and
Web-based applications development/deployment tools, have made it possible to
provide high performance and function rich user interface applications to a
large set of diverse users. This allows very flexible user interface capability,
where the participants can access the PX with a Web browser. Screen design
updates, reports, etc. are all managed by the PX staff and downloaded to the
client mode at the access time.
61
[GRAPHIC OF MAP]
Publishing Module
The technology proposed by the PX Alliance, includes third party tools
for creating Web screens that are linked to the PX Oracle database,
allowing automatic update of screens and reports as the corresponding
information in the database is updated. Use of specially designed Java
Applets will allow dynamic update of key status information without the
need of maintaining a continuous data connection between the client
browsers and PX based server. This will reduce the loading on WEnet and
will provide the market participants with a means for automatically
receiving new data and reports. Similar to the Bidding Module, the
Publishing Module supports the downloading of various data in the
format using "FTP" and Web based capabilities. The participants can
thus receive electronic copy of the market and their schedule and
settlements information.
The Publishing Module will provide the necessary security firewall to
prevent unauthorized access to the information, and to provide the
necessary protection from unauthorized access to participant specific
information and reports.
6.1 Functional Overview
The proposed solution will allow Market Participants to interactively
access all public information as well as all private information
specific to the participant involved. All scheduling results (day-ahead,
hour-ahead and ex-post information), prices, settlement, and billing
information can be accessed through this process.
In addition, some specific features of the module are as follows:
- Participant log-in
- Participant verification
- Firewall security
- Audit trail for traceability and auditability of key participant
actions, e.g. file download, or access to settlements results
- Historical archival of published information with publishing time
and date information
- PX operator displays
Over the past two years, Web technology has substantially advanced with
many high performance and proven third party tools now available to
facilitate development and deployment of Web applications. The PX
Alliance brings an extensive range of experience in the development and
delivery of high performance Web applications.
6.2 Functional Description
The design of the Publishing Module will include the following
elements:
- Flexibility in creating and modifying published report formats, using
third party Web enabled report generation and maintenance tools.
- Automatic linkage between Web based report contents and the PX
database, to minimize any report generation overheads.
- Firewall security for unauthorized access to reports. The published
reports will be separated from the main PX database to minimize any
unauthorized access to the PX internal database. This will be
achieved through data views and special report file directories.
- High performance access using proven third party products, which
provide reliable Web access to a large number of users.
- PX operator screens for entry of supplemental information, and
messages for publishing, as well as a review of information to be
published.
- PX operator screens for review of previously published information,
audit trail information, and participant activities.
The key elements of the Publishing Module are several field proven
third-party products, including Oracle suite of Web Tools, NetDynamics
and the Netscape Enterprise Server. The latter two packages have been
used successfully by the PX Alliance for the OASIS product and are now
being used for similar publishing functions for New York Power Pool's
Bid Box. The recently released Oracle Web tools provide a complete and
advanced set of capabilities to deliver high performance Web
applications integrated with an Oracle database.
[illegible]
P u b l i s h i n g M o d u l e
The PX Alliance proposes to utilize the Oracle tool set for the Publishing
Module. In addition, the PX Alliance has received commitments from Oracle to
provide technical support in the form of a subcontract for the implementation
of Web applications for both the Bidding and Publishing Modules.
During the design phase of this project, the PX Alliance will work with
designated PX representatives to develop the design and content of the reports
and information screens to be published by the PX. In addition, publication
protocols, e.g. timing etc. and the methods for accessing various information
will be specified in detail and made available to PX representatives for review
and comment.
WEB DEVELOPMENT AND PUBLISHING TOOLS
Exhibit 6.2-1 is a general illustration of the Publishing Subsystem Web
software elements. The market participants will be accessing the Web Server
through WEnet using a standard Web browser, e.g. Netscape Navigator. Web pages
and reports are created and can be maintained using interactive tools which in
addition to screen layout, create the required links to the database.
The Netscape Enterprise Server is a leading product for providing Web access to
a large number of users. A summary of its capabilities are as follows:
* Encryption - Communication between clients and the server can be done through
the Secure Sockets Layer (SSL) 3.0 protocol, enabling encrypted and
authenticated transactions.
* Access control - Confidential files or directories can be protected by
implementing access control by user name, password, domain name, or IP
address.
* Server Management - Point-and-click user interface allows one to manage
cross-platform servers. One can start, stop, configure, and manage the server
from any machine that has Internet access.
* Content creation and management - HTML editing with Netscape Navigator Gold
allows one to create Web pages. Texi-search capabilities and revision control
allow management of content.
EXHIBIT 6.2-1 WEB COMPONENTS OF THE PUBLISHING MODULE
[CHART]
Oracle's tool set provides a complete and high-performance set of capabilities
to Web based data access and integrated support for various data types stored
in the database. It is used to securely and reliably supply dynamic information
to Web pages on nearly any Web browser. It provides real-time transaction
capabilities. Instead of writing CGI programs or PERL scripts, it delivers
dynamic HTML pages directly through the Web Request Broker by translating and
dispatching client requests directly to the Oracle Server using PL/SQL.
Applications can be interfaced with the Web using Java (server and browser),
JavaScript, C/C++, and PL/SQL. The Web Request Broker is Oracle's application
platform for the Web, providing an open interface to
63
P U B L I S H I G M O D U L E
[GRAPHIC OF MAP]
application programs, Oracle and third party HTTP listeners, and Internet
protocols. This integrated platform links Web servers to live applications and
dynamically-generated HTML-formatted data. The software provides the
performance, scaleability and reliability needed to perform applications and
real-time transactions over the Web.
Exhibit 6.2-2 shows the key components of the Web client interfaces with the
Oracle database.
EXHIBIT 6.2-2 WEB CLIENT INTERFACE WITH ORACLE DATABASE
- --------------------------------------------------------------------------------
[CHART]
Oracle development tools, including Designer/2000, Developer/2000, Power Objects
2.0 and Oracle Express, can be used to develop and deploy both conventional
client/server applications as well as Web applications. This gives the PX
Alliance the ability to support approved Web and client/server environment with
no additional effort and no loss of existing applications. Using these tools,
existing client/server applications can be deployed over the Web or new
applications can be developed for the Web environment.
Oracle Designer/2000 [illegible] 3 for the Web includes full transactional
capabilities, with automatic application partitioning using Web Server packages
on the server and JavaScript code on the client. This enables the developer to
design applications once and deploy to both Web and client/server
configurations. Developer/2000 [illegible] 3 for the Web includes the ability to
deploy reports on the Web, enabling both high performance HTML-based reporting
and high fidelity Adobe Amber-based (PDF) publishing. Reports are developed just
once and can be deployed into both Web
[illegible]
Publishing Module
and client/server environments. Reports support features such as
drift-out to Web pages, "hidden" URLs (behind text fields, graphics,
buttons, etc.), scalable fonts (PDF only), hyperlinked table of contents,
drill-down reports (nested reports), buttons, images (including clickable
images), etc., from any Web browser delivering true data to the client.
Oracle's Power Objects 2.0 supports embedded browser functionality via
standard browsers, enabling client/server applications to contain Web
pages within the application layer. In addition, 2.0 runs as a plug-in in
Power Browser and Netscape Navigator, providing easy access to
sophisticated form functionality (far beyond that available in HTML,
JavaScript, Visual Basic Script, or Java).
The use of these Web/database application builders automates the
Publishing Module development process. These tools combine visual
development with a high-performance Java application server and scalable
database access to provide for rapid delivery of high-performance
Web/database applications.
6.3 Summary
The proposed Publishing Module provides a highly flexible interactive
tool for the market participants. Further discussions between the PX
Alliance and the PX is needed for:
o Agreement on the number and content of the Webpages (required for
implementation by 1/1/98) within the Definition phase of the project.
o A high level of involvement of the PX staff doing the Design and
Prototyping phase to minimize reconstruction of Web pages.
[ILLEGIBLE]
[GRAPHIC]
7. SETTLEMENT MODULE
Settlement Module
7.0 SETTLEMENT MODULE
[CHART]
The PX Alliance proposes to utilize ABB's P&SS software as the basis for
the development of the PX Settlement Module. There is a considerable
amount of commonality between the required settlement functionality of PX
and that of other power pools. Some differences on specific protocols and
market rules, e.g. interactive and hourly markets, exist. However, the
overall software for handling the settlement processes, audit trails and
dispute management is very similar. The major business objective of the
P&SS's Settlement Module is to effectively manage the calculation of the
funds to be transferred between a Power Pool or Exchange and the
participants that operate within it, in order that timely and accurate
clearing of these fund transfers may be achieved. The same is true of the
Settlement Module for the PX.
The P&SS's Settlement Module was specifically designed to cater to a wide
variety of Power Pool and Power Exchange operations. ABB's experiences
within the deregulated markets around the world was brought to bear in
the design of the product to produce a system based on a flexible
database and workflow management techniques. By designing the product in
this way it can easily be configured to reflect the PX specific business
rules with minimum effort and customization. This ensures that the
Operator of the Power
[LIGHT BULB GRAPHIC]
S E T T L E M E N T M O D U L E
[GRAPHIC OF MAP]
Exchange meets the required market opening timescales which are often tight and
non-negotiable.
The Settlement Module performs all the settlement related tasks including meter
data import and aggregation import of other relevant data from the ISQ,
settlement calculations for energy and applicable ancillary services,
settlement reporting, dispute management, and recalculation of Settlement based
on revised data. The proposed system supports full security access control and
the audibility of data.
EXHIBIT 7.1-1 SETTLEMENT PROCESSING
- --------------------------------------------------------------------------------
[CHART]
7.1 FUNCTIONAL OVERVIEW
7.1.1 THE SETTLEMENT PROCESS
The PX business rules define the regime under which Generators offer their
available capacity to the PX, loads provide forecasts and bids for their demand,
and other Market Participants form part of the wholesale spot market
Generator/Import and Lead/Export offer data (whether prepared by the PX or bid
by PX participants) will have been passed from the Bidding Module to the
Scheduling Module. The Scheduling Module (with an iteration with the ISO)
schedules the generation/import economically to meet forecast demand. From this
dispatch a set of advisory [illegible] prices for trading of electricity is
produced and published at the day ahead stage. During the operational day
S E T T L E M E N T M O D U L E
(also called D day), hour ahead rebids are submitted and dispatched and a
rolling program of re-dispatching as performed by the Scheduling Module to
maintain a "least cost" operating regime. The hour ahead schedules result
in sets of hour ahead prices. Other adjustments to the schedules may be
made by the ISO to relieve transmission congestion and address other power
system security related issues.
From day D-1 through day D-12, operational and metering data will be
imported into the Settlement Module from which a set of Ex-Post prices are
calculated to compensate for the differences between scheduled (both day
ahead and hour ahead) and actual generation, congestion and other factors.
From these sets of prices, the Settlement Module calculates the money flows
required to and from the PX for each of its members. Reports are produced
to detail the calculations and payments and to provide information to be
used for billing purposes by the Billing Module.
The system has been designed to operate on the basis of a strict audit
trail of all input data which, experience has shown, can have many versions
for any trading day. Each Settlement run is performed and marked in such a
way that during an audit the system can identify each version of the input
data which was used to generate a particular set of results. Multiple runs
of the Settlement Module are supported for any trading period whereby the
latest version of input data sets for that period will be used in
calculating the results.
Key features of the settlement process are:
* Receipt and validation of meter data (both generator/import and
load/export).
* Meter date aggregation.
* Receipt of relevant data from the ISO. This includes:
* Ancillary services capacity reservation and usage
* Loss factors and charges for losses
* Ex-Post Energy and Ancillary Service prices
* Ex-Ante Settlement calculation (Day Ahead).
* Ex-Ante Settlement re-calculation (Hour Ahead).
* Ex-Post Settlement calculation (daily to day D-24).
* Ex-Post Settlement re-calculation.
* Billing Period administrative.
* Settlement Reporting.
* Settlement Report Posting.
* Dispute Management.
* Electronic data interface with all pool members.
* Audit of all settlement transactions.
* User access controls and security.
7.2 SETTLEMENT MODULE FUNCTIONAL DESCRIPTION
The over-riding objective of the Settlement Module is to ensure that the
funds are transferred between the parties that are trading in the PX are
determined accurately and in a timely manner. In order to achieve this, the
system maintains a database of the relevant information (drawn from the
Bidding Module, the Schedule and Price Determination Module, the metering
agency, and the ISO) upon which it performs the required calculations as
defined by the business rules.
In order to perform the settlement process, the system utilizes the
calculated prices at which the energy was traded in the Power Exchange
within each trading day (or hour) to calculate the funds to be paid to
Producers, and those to be billed to participants who drew energy from the
PX. Additionally, and most importantly, the Settlement Module also provides
a secure audit trail of all the information used, from the data supplied by
PX participants, through to the money which changes hands between PX
participants and the PX as a result of each daily/hourly trade.
Understanding that the system must operate in an environment in which not
all information that is provided will be transparent, complete and correct,
and available in a timely fashion, the system has been designed to operate
within the very tight deadlines of the PX business rules which have been
specified.
Extensive ad-hoc query and user reporting facilities have been designed
into the system to facilitate the investigation into any disputes and offer
swift resolution.
[illegible]
[MAP GRAPHIC]
Settlement Module
7.3 DESIGN FEATURES
The P&SS product embodies a number of fundamental design features,
these include Tracking, Auditability, User Classes, and System
Security. The following sections discuss each of these in more detail.
7.3.1 TRACKING
The tracking process provides auditability, forms a basis for
investigation of any disputes raised by PX participants, and enables the
Settlement Module to compute any payment adjustments which may be
necessary between subsequent authorized P&SS runs for a particular
settlement day (or hour).
When the Settlement Module receives any form of input data necessary to
perform any set of settlement calculations, either by electronic
transfer of information from an external system (such as the meter data
from the Metering Agency), or by manual data entry into the system
itself, every file is marked with a unique identifier which indicates
its origin, the type of file, the settlement date for which the file is
applicable, and a version number, in order for the system to operate
with both DOS limited length file names, the naming convention follows
a directory structure in terms of where the files are located in the
interface. An example of such a file for metering information relating
to a specific date would be
MDR230197 IN
This information is then recorded in the settlement database together
with the full information set contained in the file. This data set in
the settlement database is then tracked by the system against the input
file date and file version number.
When files are successfully received by the Settlement Module, the
system automatically checks that their contents are valid. Providing
this check is successful, the file data is loaded into the database and
the data set is flagged as Authorized.
For manual data entry to the system a similar rule applies. Any manual
data entered into the system is checked on completion of the data input
exercise. Manually entered data is identified in data sets in a similar
way to information supplied in electronic file format by external
parties. Once the data set is completed and validated by the system, it
is Authorized. The authorization in this case is not automatic, but
rather accomplished by the user entering a password. Each manual data
set has an associated user authorization password appended. On
successful authorization, the date set if then tracked against the
settlement date and the version number of the data set. A data set is
given a version number starting from 1 for the first authorized set for
a particular settlement date. Each time data is changed and the
full set authorized the version number is incremented.
To summarize, both externally supplied data and that maintained
directly within the system has an associated version number. The date
for which the set is valid combined with the version number forms the
DATA SET TRACK.
Whenever a settlement run is performed the full DATA SET TRACK for all
data sets used in the run is recorded within the system. Each
authorized run of the settlement process will itself be allocated a
DATA SET TRACK for the output data set from the run. Thereafter it is
always possible, by looking at an authorized Settlement Module output
data set number, to identify explicitly the version of each of the
input data sets which was used in the run.
7.3.2 AUDITABILITY
The settlement process results in considerable sums of money being
exchanged on a daily basis between PX participants. As such, it is
logically an extension of the PX member's own accounting systems. It is
very important that any payment made can be traced back to the
settlement activity. This is the primary objective of the Settlement
Module audit function. Using the Data Set Tracking identifiers
described above enables all information used in production of
Settlement reports, in particular the report which triggers pool funds
transfer (the actual money movement) to be traced from input to the
system through to output to the Billing Module which is responsible for
the generation of the bills and the credit control function.
In order to guarantee auditability throughout the settlement process
each significant event is recorded together with the date, time and
user ID of the person responsible. This
Settlement Module
includes: authorization of tracking data sets; initiation of a settlement
run; authorization of settlement run results and any other event which can
have a material outcome on the payments resulting from application of the
PX Rules.
7.3.3 USER CLASSES
As with any comprehensive computer system, it is important that different
users are presented with a meaningful interface to that part of the system
which affects their particular job. For that reason, the system
incorporates a mapping between functions available on the system and
particular users who access it. Since user functions tend to be allocated
to departments or groups of participants, this control is applied to the
user class rather than to the user him or herself. An example of this is
that a Settlement Manager class of user may have access to all features of
the system on log on, whereas a data manager class of user will only have
access to those operations in which data is either imported to, or
exported from, the system.
7.3.4 SYSTEM SECURITY
As with any system which is controlling significant amounts of cash
movement there needs to be a high degree of security against inadvertent
tampering with information which is material to the money that changes
hands. We have, therefore, designed two levels of security: the first
prevents any unauthorized user from accessing the system; the second
ensures that if any material data is changed by whatever means, then
details of the change are recorded. User access security is provided by
means of user passwords which should be changed on a regular basis. Any
user not entering their correct password will be prevented from accessing
the system. In addition to this level of access control we will build a
set of trigger functions into the database. These will ensure that any
material data changed, whether by means of the pooling and settlement
system or any other tool which can access the database, will be recorded
together with details of the change and the user identifier (as known to
the system) responsible. This is performed by having an audit and security
table within the database structure for every table held which is to be
the subject to security control. This table is a mirror image of the table
which it audits with the addition of attributes (columns of data) which
identify the date and time of the change and the user name of the person
responsible. In this way any changes to the table which has this facility
allocated will be reflected precisely in the security/audit table which
will hold a copy of the old and new values and the reason for the change.
7.4 WORKFLOW
The Settlement Module makes use of workflows to manage the activities
relating to the calculation of the information relating to the funds to be
transferred to or from the various PX market participants. Examples of
workflows relating to the management of disputes and the collection of
meter data are provided to show the format of the decision making and
processing performed.
The workflows within the Settlement Module will be configured to represent
the order in which activities are performed within the California Power
Exchange and the relationships between the various activities. Where new
workflows are required, they can be easily incorporated using the existing
format and configured to control the required functionality. The same
workflow manager controls the processing of the activities within the
workflows. A workflow sample is shown in Exhibit 7.4-2.
75
S e t t l e m e n t M o d u l e
[GRAPHIC OF MAP]
EXHIBIT 7.4-1 SAMPLE SETTLEMENT WORKFLOW
[CHART]
7.5 BATCH PROCESSING
Most of the calculations and processing of information carried out by the
Settlement Module can be performed as batch processes. This ensures that
the time critical activities are performed in an effective manner.
7.6 STANDARD REPORTS
The P&SS Settlement Module produces a range of standard reports to
facilitate the monitoring of activity in the Power Exchange and the funds
flowing into and out of the PX. All reports are currently issued in the
form of a formatted text file. These files can both be user readable and
handled electronically by computer systems. In the PX implementation,
Web-based pages will be crated to provide access to these reports via the
Publishing Module. Each report will be downloadable through the Publishing
system or via "FTP-transfers. Which PX participant is to receive which
report can be configured from a report postings table which holds a list
of the report files to be produced for that participant. Each report has a
name, date, and version number incorporated into the title. This will
provide immediate information to the market participant as to which is the
most recent versions of the report and a means to track the report back
through the Settlement Module to the input data sets which initiated its
production. Additional information in the report postings table will
identify whether the market participant should receive their reports
electronically.
All reports and associated Web pages will have a standard header page
which will identify the report name, settlement date, version number,
market participant identifier, and report production date and time. The
sections which follow identify the contents of each report. Where
necessary, these reports will be customized to meet the specific needs of
the PX.
7.6.1 MARKET PARTICIPANT NON CONFIDENTIAL REPORTS
The following is a sample list of the existing P&SS non-confidential
Settlement reports:
* Ex-Ante Pool Price Summary Report [EAPPS] - This report provides a
summary of pool prices for the following settlement day.
* Ex-Ante Pool Price Breakdown Report [EAPPB] - This provides feedback on
each component of the Ex-Ante Pool Price for each settlement period.
* Ex-Post Pool Price Summary Report [EPPPS] - This is identical in
structure and content to EAPPS, but all figures are Ex-Post since they
are the result of the Ex-Post settlement run.
* Ex-Post Pool Price Breakdown Report [EPPPB] - Once again this report is
identical to the EPPPS report, but all figures are Ex-Post since they
are the result of the Ex-Post settlement run.
16
S E T T L E M E N T M O D U L E
* Ex-Ante Availability/Demand Summary Report (EARDS). This report
provides a summary of the total available power offered in each
settlement period against the total demand reserved.
* Dispute Summary (DS) -- The dispute summary report provides
Market Participants with a history of all disputes which remain
outstanding and their status, together with all resolved
disputers, but the latter reported for a limited time only.
Resolved disputes will appear in the dispute summary for a period
of 10 days from the dispute resolution, after which time they
will no longer be reported. The report is sorted on dispute
status within which each dispute is listed in order of its age
with the newest first.
7.6.2 MARKET PARTICIPANT CONFIDENTIAL REPORTS
A sample list of the P&SS Confidential Settlement Reports include:
* Generation/Import Ex-Ante Reports
* Offer Confirmation Report (EAGOC) -- This report contains an
extract from the Settlement database of all parameters used in a
Settlement run which were input from the generation/import offer
we submitted.
7.6.3 GENERATOR EX-POST REPORTS
* METER READING CONFIRMATION REPORT (EPGMR) -- This report provides
feedback to the Market Participants of the meter readings used in
the Settlement Module. Note that meter readings are classified in
Settlement as: General output; General Auxiliary Load; and
Station Load, respectively. Each of these designations may be the
result of aggregating a number of physical meter readings. It is
the aggregated figures as used in Settlement that are reported
here and not the raw figures supplied by the generating company.
This gives the generating company the opportunity to check that
the Settlement Module has correctly summed its meter readings in
the way defined at the time the meters/power station was
registered with the PX. The report is sorted per station and per
genset. Note that the Station load figure is reopened only
against the first genset on the station.
* DISPUTE DETAILS (EPGOD) -- This is a detailed report on disputes
raised by the generator. The report will contain only those
disputes which have changed status since the last time the report
was produced. Under exceptional circumstances this report can
also be produced by the Settlement operator at any time, using a
selection of disputes from the Settlement database.
* GENSET PAYMENTS REPORT (EPGP) -- Payments to generators are based
on the PX roles in place. The EPGP report provides a breakdown of
these payments to each of the generating companies trading in the
Power Exchange. The report will be structured such that payments
to each genset on the power station are itemized as follows:
detailed breakdown of component payments or each genset a total
for all of the payments to each genset a total sum or the
payments to each power station; and finally a total sum for all
payments to the generating company.
7.6.4 EX-POST REPORTS
* DEMAND RESERVATION CONFORMATION REPORT (EASDRC) -- This report
provides feedbacks to each relevant Market Participant of the
load demand/export reservation which was used in the Settlement
run. The demand reservation details are provided only for the
reservation made by the pool member concerned.
7.6.5 LOAD/EXPORT EX-POST REPORTS
* DISPUTE DETAILS (EPSDD) -- This report will be used for generator
disputes. The only difference is that it is produced here on the
per distribution company basis.
* POOL PAYMENTS REPORT (EPSP) -- This report itemizes the payments
which the distribution company must make to the PX. The report is
similar to EPSDD with the exception that demand is replaced by
payments.
* POOL FUNDS TRANSFER STATEMENT (EPSPFT) -- This report provides a
statement to the Distribution company of how much in total should
be paid into or out of the PX for a single day. (Note: this
statement will in fact be common to all PX participants, although
the sum shown will relate to individual liabilities only.)
* DISPUTE DETAILS (EPSPADD) -- This report provides the length of
time for which a dispute was in progress before its resolution,
in order to allow the accounts department to calculate interest
due on payments to and from the pool, as a result of the dispute.
[LIGHTBULB GRAPHIC]
[MAP OF GRAPHIC]
Settlement Module
7.6.8 REGULATORY REPORTS
The P&SS provides a set of reports that are designed to support the needs
of a regulatory agency which oversees the PX operation (PBRC). The
regulation may receive one or all of the reports which are produced by
the Settlement Module. Which ones are given to the ISO will be defined by
a REGULATOR pool participant entry in the report postings table. Ad-Hoc
reports can be produced and scored based on any information in the
pooling and Settlement system database should the ISO require reports in
addition to those provided for in the system.
7.7 USER INTERFACE
The Settlement Module has a standard Windows Graphical User Interface
which enables the operators to effectively manage the Settlement process.
Full use is made of tabbed pages to facilitate easy navigation around the
system and selection boxes are used wherever there is a requirement to
select a data item from a list. A typical screenshot sample is shown in
Exhibit 7.7-1.
EXHIBIT 7.7-1 USER INTERFACE
[GRAPHIC]
7.8 SYSTEM INTERFACES
The Settlement Module will require external interfaces to the Meter
Agency through which all supply and demand meter readings will be
imported and to the ISO through which all the Ex-Post pricing and other
information will be imported. In addition to these two interfaces, the
dispute resolution process, as well as the report posting process, will
require access to the PX participants.
On each settlement day, it is the responsibility of both generation and
distribution companies participating in the PX to record their supply and
consumption of electricity to and from the grid. These records should be
maintained as hourly average power produced or consumed. The generator
will record each of the meters (both generation and consumption) on each
of their generating units and on each power station. These will be
submitted to the meter agency for transmittal to the PX and imported into
the Settlement Module in the form of a [illegible] text file. Similarly,
distribution company meter readings are also transmitted and imported.
7.9 ASSUMPTIONS
The following assumptions were made in interpreting the WEPEX
requirements for the Settlement Module:
- It is assumed that the data from the Metering Agency will include the
required estimated and calculated meter values (as opposed to measured
values) and their associated quality flags. This is necessary to ensure
metering data consistency between the PX and the Metering Agency.
- Many of the calculations necessary for the Settlement process are still
to be defined. It is assumed that these calculations can be performed
using simple arithmetic and that the calculations will be clearly
defined during the [illegible]statement phase.
[illegible]
[GRAPHIC]
8. BILLING AND CREDIT MODULE
Billing and Credit Module
8.0 BILLING AND CREDIT MODULE
- --------------------------------------------------------------------------------
[CHART]
Invoicing customers is often the area that is given the least amount of
attention, but is actually one of the most critical. The ability to accurately
bill customers crucial to the success of the PX. Failure to produce accurate,
timely bills will cause serious cash flow problems for the PX and for the market
participants. All of the effort in developing the software and the leading edge
technologies of the bidding, scheduling, pricing and settlement areas provide
little value if the PX cannot effectively charge or pay participants for using
and providing energy and services.
The PX requires a full-functioning billing engine to handle the high volume of
transactions generated by the Settlement Module. It also needs a method of
accounting for participant activity that supports the buying and selling of
energy and ancillary services in an hourly market in a regulated industry. The
supporting system must be reliable to keep up with the high daily volumes.
Unlike most invoicing processes where customers are billed and vendors are paid,
the PX billing system must generate both debit invoicing and credit invoicing to
the same external entity, this produces account-
[GRAPHIC OF MAP]
BILLING AND CREDIT MODULE
ing requirements that exceed the generic billing model. Additionally,
participant accounting is needed to provide clear and consistent
accounting methods that facilitate the flow of cash while providing a
detailed audit trail.
The Billing & Credit Module will be developed to meet the business rules,
protocols and other requirements of the PX. The PX Alliance approach to
delivering the Billing and Credit Module functions utilizes utility
expertise applied to standard energy industry billing models which will be
fully integrated with a configurable accounting package. The PX Alliance
has designed and implemented billing models in more than ten energy
transmission systems in the US and UK. By leveraging our experience, we
offer the leading practices in billing and accounting as a resource for
meeting the PX requirements. The functional process models and designs for
screens, batch process and databases from GasSolutions(TM) will be used as
the baseline for adaptation based on PX requirements. GasSolutions(TM) has
evolved over the years to incorporate our most current industry
experience. The current version of GasSolutions(TM) embodies the models
that support the requirements at British Gas. Since the business rules for
British Gas were modeled after the U.K.'s national electricity grid and
power pool, the invoicing configuration is a relevant example to use for
comparison to PX requirements. To meet the accounts receivable
requirements, we believe that the Oracle Receivables(C) package provides
the majority of the needs that have been defined. Through standard
configurations and interfaces, Oracle provides a flexible solution that is
quickly implemented, allowing on-going customization through user
definition.
8.1 GasSolutions(TM) Invoicing
The invoice production requirements within the PX Billing & Credit Module
are highly similar to the functions of the GasSolutions(TM) invoicing.
Invoicing prepares debit and credit invoices for buy and sell transactions
resulting from energy market bids and participant energy balancing
settlement. For the PX requirements, participants will be bidding in
supply and demand energy bids plus ancillary services. Settlements will be
calculated and billed in a consolidated invoice package. Debit and credit
items must interface with the accounting function. Payment & receipt
processing must occur based on comparison between debits and credits.
The number of charge types and invoice types are configurable. The
invoice production process aggregates debit and credit charges separately
for tax application and general ledger reporting. For example, the PX
needs to provide a consolidated statement showing this net amount due to
the PX or to a Participant. Cash is exchanged between the PX and the
participant based on net amounts between debit and credit. For example,
if the Participant owes the PX $300 and the PX owes the participant $200,
the participant pays the PX the net equal to $500. Mechanisms can be
implemented to manage cash flow to protect the PX from honoring all
payments to participants is when the participants withhold money they owe
to the PX.
To use the GasSolutions(TM) modifications are required in the following
areas:
o Settlements Interface: Customization is required to process the
settlement transactions produced by the Settlements module. The data
involved in these transactions are different from company to company.
o Accounts Receivable Interface: While the ability to post debit and
credit invoice items separately to the accounting function already
exists, minor modifications will be required to tailor the interface to
the requirements of Oracle Receivables.
o Taxes: Although taxing is not defined as a requirement,
GasSolutions(TM) provides a simplistic tax structure. The current
structure allows flexibility in defining innumerable tax types (e.g.
for British Gas, VAT @ 17.5%, VAT Exempl, VAT @ 8.5%, etc.) and the
association of tax types to charge types (e.g. VAT @ 17.5% is applied
to capacity, commodity and scheduling charges). Tax calculation
requirements are not included in the hours or lee estimates. If
required, Ernst & Young LLP has a large state and local tax practice in
California and can provide assistance in determining the tax
requirements for energy sales and services within the state.
[LIGHTBULB GRAPHIC]
B I L L I N G A N D C R E D I T M O D U L E
8.2 FUNCTIONAL OVERVIEW
The Billing and Credit Module encompasses.
-- Invoice production
-- Accounts receivable/payable processing
-- Payment processing
-- Receipt and credit memo processing
-- Participant accounting
-- Credit and collections
-- Billing dispute resolution
[CHART]
[GRAPHIC OF MAP]
B i l l i n g a n d C r e d i t M o d u l e
EXHIBIT [Illegible] - PROCESS BILLING INVOICES
----------------------------------------------------------------------
[PROCESS GRAPHIC]
[Illegible] PROCESS BILLING INVOICES
Process Billing Invoices encompasses the invoicing
infrastructure setup, settlement, processing, application of
taxes, adjustment processing, automatic and manual, invoice
production, review and finalization, printing/transmission
of invoices and the posting of invoice information to the
Accounts Receivable/Payable Accounting Module.
Within the Billing & Credit Module, two major batch
processes complete most of the work. The first batch process
captures all the charge items generated by the Settlement
Module and updates these data items with the necessary
billing information in preparation for invoice production.
The second batch process compiles these "invoice ready"
charge items into an invoice for a participant. This section
will discuss these major batch processes and the smaller
ones as appropriate, followed by a description of the
supporting screens and processes.
[LIGHTBULB GRAPHIC]
Billing and Credit Module
Process Settlements
Processing settlement records from the Settlement Module is the first major
batch process which needs to run on a daily basis to keep up with the large
volumes of data produced. Remembering that the Settlement Module will only pass
finalized settlements when the dispute period is over (24 days after the bid
date 0+24), the Billing & Credit Module's database will only contain finalized
charges. This means that invoices can be generated from this final settlement
information at any time (alte:D+24) and on any frequency. For example, during
the second month of PX operations, on February 1, 1998, all participants
could be billed for January 1-7 because 24 days will have passed for each of
these dates.
Settlement Interface
Each day, the settlement interface will receive debit and credit settlements
from the Settlement System. Each one will be updated with information needed to
compile the bill, such as the appropriate accounting codes, invoice group
numbers, billing period, charge type codes, and other invoicing control
information that facilitates the invoice production process. The following
settlement charge types will be processed:
- - Day Ahead Commitments
- - Hour Ahead Commitments
- - Real-time Energy Balancing
- - Ancillary Service Deviations
- - Transmission Access Charges
- - Usage Charges
- - Intra-zonal Congestion Charges
- - Net Payable/Receivable
Process Adjustments & At-For Charges
While it is assumed that most charges will be calculated by the Settlement
Module, the need to make adjustments or enter ad-hoc charges may arise. For
items that require amending, PX internal analysts can directly enter line items
for the invoice for a particular charge type or just as a "free form" line
item. The full details of the charge as entered are automatically included as a
line item in the invoice packet sent to participants.
For items that are not part of the normal billing packet, but rather part of a
manual invoice, these line items can be entered in the same format as an
existing charge type or as a "free form" line item as well. These items can
then be selected for inclusion on any manual invoice generated.
To facilitate the process, some screens will provide the ability to display
charge items and allow users to filter requirements by participant, charge
type, date, hour or location. The same windows used to view this information
can be used to make adjustments to existing charge items, as well as to
manually create new charges of the same type.
Apply Taxes
For all charge items received, whether manually entered or automatically
received from Settlement Module, any tax requirements will be applied between
the preparation of the data for invoicing and the actual invoice production
run. This process is shown on the Produce Invoices diagram to show where it
logically fits in the process if the requirements are defined at a later date.
Currently, the work defined does not include this process. It is possible that
tax calculations may require different tax rates depending on location of the
meter, type of service being provided, whether the item is "self-billed" (PX
billing itself for energy purchases on behalf of the supplier) and/or any
number of local and state rules. Taxes are calculated and applied as necessary
for each debit and credit item.
Usually, taxes are shown as separate line items summed by tax account code at
the participant level for reporting to the proper tax authority and entry in
the accounting ledgers. Both the detail tax information and the summary
information are stored.
[illegible]
B i l l i n g a n d C r e d i t M o d u l e
[GRAPHIC OF MAP]
PRODUCE INVOICES
Producing invoices is the second major batch process. Invoice production begins
with collecting and summarizing final settlement information for a list of
participants for a pre-defined billing period. Since charges from the
Settlements module are processed daily (after D+24), on any given day, the
charge items in the billing system are considered "total" and are ready to be
billed when they are received. All settlements for days within the current
billing period are summed to a charge type level referred to as an invoice item.
The Billing & Credit Module's Produce Invoices process runs independently of the
processing of the Settlements interface. Because of the data volumes involved,
the best approach is to produce some invoices every day rather than once per
month. To accomplish this objective, invoice production runs will occur for a
predefined set of participants. This set will be referred to as a billing
schedule. The cyclical approach has the following advantages:
* Equitable spread of transaction processing on the system over the course of
the month (resulting in no exceptionally high-volume days)
* Continuous cash flow over the month rather than a mass influx or outflow at
one time during the month
* Balanced workload of Billing staff over the month (no all-nighters reviewing
invoices to get all participants approved)
To use an industry example of how this approach was implemented, British Gas'
invoice production volumes for the National Transportation System invoices were
low enough that each participant could be billed at the same time from a system
performance standpoint. Capacity invoices were produced on the 1st of every
month, Storage on the 5th working day and Balancing on the 15th working day.
For the total Distribution charges, the volumes of information were too large
to process all at once. A rotating billing cycle was established that means
some participants were billed from the 1st to the end of the calendar month,
others the 2nd of one month to the 1st, others the 3rd of one month to the 2nd
of the month following and so forth.
GENERATE INVOICES
The Generate Invoices Process runs can be scheduled automatically by the system
or submitted manually by a user. The [illegible] batch run produces invoices for
all invoice groups with uninvoiced charges that are due to be billed according
to the billing schedule.
The invoice package created for review will contain header information such as
the participant number, name, invoice creation date, participant address,
sent-to addresses and comments. Summary information will follow indicating the
balance brought forward, payments since previous invoice, any adjustments
applied, totals for each invoice item and net amounts due. A separate total will
be displayed for each invoice item (e.g. Net Day-ahead Settlements - due
Participant). Because totals are calculated at this level, posting to A/R and
applying taxes can be done at the participant, invoice, invoice item (charge
type) or charge item level. In considering current PX requirement definition,
invoice item would be the appropriate level to post to A/R. Taxes, as stated
earlier, require further definition. Following the summary, the supporting
information at a detail level will be included and summarized to whatever level
the PX requires.
Invoice items are generated for all charge types that have uninvoiced charges.
For example, the billing schedule may indicate that Participant A's invoices
are due to be produced today. Since Participant A only has bids and services
associated with demand (debit items), only invoice items for debit charge
types will be generated. If a participant has no current charges, just the
summary information would be compiled.
Following the invoice item summaries on the invoice, the detail line items for
all charge types will be provided. Details such as bid or service identifiers,
date, hour, energy, price and net amount due are common fields to provide on
the charge items sent to the participant.
REVIEW INVOICES
Invoices produced can be reviewed internally before submitting to the
participants. Screens will be available and summary reports will be produced to
assist in the verification process. Invoices can be approved or [illegible] by
[ILLEGIBLE]
[LIGHT BULB GRAPHIC]
Billing and Credit Module
invoice group or by batch run. If any errors or anomalies are found from
mistakes in user input (e.g. invoice group set-up incorrectly, tax or G1
account codes associated incorrectly, etc.), the invoice production job
can be re-run as necessary until the results are satisfactory. The ability
to regenerate invoices for a specific participant will be provided.
When a participant's invoice is approved, as indicated by batch or
individual approval, the data is finalized and the invoice group is
'closed out'. During 'close out', the invoice group is reset for the next
billing period and the invoice information will be submitted for delivery
to the participant.
PRODUCE MANUAL INVOICES
The ability to produce manual invoices is supported. PX analysis can raise
an invoice which can be submitted to the participant in hard copy or via
EDI. Manually entered line items can be associated to these invoices.
These invoices will be posted to accounting using the same procedure as
normal invoices.
PRINT/TRANSMIT INVOICES
Invoices will be delivered to participants on hard copy through the mail
or by electronic data interchange. A default setting will be captured in
the invoicing infrastructure that indicates the preference of the invoice
group: hard copy or EDI. The default delivery method is established for
each participant in the Invoice Infrastructure, and can be manually
overridden at the time of invoice review.
When the invoice is approved, a batch process is triggered to print the
invoices or create the invoice file for electronic transmission. All
invoices files will be compliant with ANSI X.12 standards or other
standard electronic interchange protocol defined by the PX at a later
date.
POST INVOICES
Once the receipt of the invoice is manually or electronically
acknowledged, the posting process will transfer all debit and credit
invoice information to the participant accounting and accounts
receivable/payable modules. If the invoice was sent by EDI, an
acknowledgment will return to the Billing & Credit system which will
trigger the posting process for that invoice. If the invoice was sent by
mail, the posting process will be triggered manually by a user to indicate
the invoice has been mailed. If the system fails to confirm electronic
delivery, the PX analyst can confirm receipt at the participant's request.
CANCELLATION & DUPLICATION
A facility to cancel invoices and send duplicate invoices will be
provided. Cancellation of an invoice will trigger the sending of a
cancellation notice to the participant and the appropriate updates of
accounts receivable/payable. Duplicate invoices can be sent at the
participant's request in hard copy or EDI format which identifies that the
invoice is a duplicate of one previously sent out.
INVOICING INFRASTRUCTURE
In addition to maintaining relevant participant information, the Invoicing
Infrastructure manages and executes the controls to the billing process.
In this Module, all of the necessary codes, such as General Ledger account
codes, codes to identify tax rates and codes to identify charge types, are
set up and maintained. Many of these codes cross-reference each other to
provide maximum user control and flexibility. Some examples would be
"charge types to general ledger codes" and "charge types to tax codes." By
relating these items together, the PX analysts can maintain the
relationships without requiring a programmer to change the source code.
All codes (account codes, charge type codes, tax codes, etc.) used in the
Billing and Credit Module must have effective dates to enable codes to
become inactive or active for a future date. This flexibility is also
required to allow associations between codes to change over time. If any
adjustments for previous days are entered, the system must be able to
determine the exact reference to a code on the production date which may
or may not be the most recent daily cycle. All the data structures are
date effective to fully support adjustment processing and auditing
requirements.
Invoice groups are maintained in Invoicing Infrastructure. Groups are set
up to indicate the types of invoice items a participant is eligible to
receive on an invoice. An Invoice Group enables the invoice production
process to collate all
17
[GRAPHIC OF MAP]
B i l l i n g a n d C r e d i t M o d u l e
applicable charges during the billing period for the participant
to be sent out together. All charges will be collected by charge
type into a distinct invoice. Each invoice item will contain
either debit items of the same charge type or credit items of the
same charge types to enable reporting to accounts receivable or
accounts payable as appropriate. An invoice item will contain
only one charge type for the billing period. For example, one
invoice item for the participant might contain all day-ahead
supply settlements due to the PX. Another might contain all
hour-ahead demand settlements due to the participant.
REPORTING
Common billing reports will be provided at user request and as
part of the billing period cycle. A participant invoice register
and a participant invoice log will be produced each invoice
production run. Additionally, weekly and/or monthly reports can
be generated such as total billings for the period, totals by
charge type and error logs. Reports can also be submitted at user
request from a window providing the appropriate [illegible] and
reporting opinions.
8.2.2 ACCOUNTS RECEIVABLE/PAYABLE ACCOUNTING
When receipt acknowledgment is obtained (either electronic
confirmation or manual confirmation of the invoice being posted),
the invoice details are posted to accounts payable and receivable
accounting at the detail transaction and summary levels. An
interface will load invoice transactions for posting to Accounts
Receivable and Payable. Items posted will contain standard data
fields such as participant number, name, invoice creation date,
comments, closed items indicator, net amount due and the remit-to
address.
Accounts payable and receivable can be linked together to show
net participant balances, enabling the PX analysis to review
participant information before approving credit payments for the
participant account.
8.2.3 PARTICIPANT ACCOUNTING
Participant details will be stored and maintained for use
throughout the system. Participant details such as name, address,
remittance address, bank account, contact details and affiliated
participants can be viewed and maintained. Other items such as
total amount due/owed, total cash applied, summary aged balance,
participant average days paid, date/amount of last payment and
statement flag will be compiled from the information stored
within the system database for viewing and reporting. Participant
status can be maintained in this module for use throughout the
system for determining what activities a participant can perform
on the system.
The Participant Accounting Module accommodates the PX's unique
accounting situations. Most accounting systems expect a business
associate to be either a "Customer" who receives debit invoices
or a "Vendor" who receives payments for purchase orders
delivered. To meet the PX needs, all Participant accounting can
be defined in one of two ways in the Billing & Credit Module:
1. To Net at the Participant Level: Each participant will
maintain a "Supply" account and a "Demand" account. Separate
invoices are generated for each account and for operational
purposes on the system, each account acts as a separate
participant. In the accounting systems, however, an interface
will be available to treat these participants as one entity.
Accounts receivable items will be netted against account
payables for receipt and credit processing.
2. To Net at the Participant Level/Account Level: Each
participant will have at least one account where all
transactions are netted against. Debit and credits can be
posted to each account so a Participant account defined in
this way can make supply and demand bids within the same
account. Multiple accounts for a participant can be
established if desired, but the netting will take place
against each account.
All account information is stored by participant in the
Participant Accounting Module. PX analysts can access both
detailed transactional information as well as summary information
for balances, payments and receipt activity.
8.2.4 PREPARE PAYMENTS TO PARTICIPANTS
When both debit and credit invoices are produced for a single
participant, the timing of distributing checks is an issue for
cash flow management. The PX must have a means for
28
B I L L I N G A N D C R E D I T H O D U L E
controlling disbursements of cash in a way that balances cash flow
against the rate of receipts of cash from participants.
Experience at British Gas shows that shippers would dispute debit items
to avoid payment and accept credit items in their remittance advises.
This practice resulted in British Gas outlaying large amounts of cash
in proportion to the receipts coming in. To prevent this, participants'
balances should be reviewed as they are scheduled to be billed against
the current billing and emittance advise. As participants may withhold
payments due to a dispute, the PX may elect to withhold payments to the
participants until disputes related to the invoice group can be
settled. Accounts payable provides the ability to control the issuance
of checks. Payment transactions will be posted with information such as
participant number, amount, receipt date, check number and bank
name/identifier. Payments to participants can also be accomplished
through Electronic Funds Transfer (EFT).
To avoid this issue, Market Participants receive with their invoice a
remittance advise that should be returned electronically or in hard
copy containing their incentive to pay the invoice debit charges and
acceptance of payments for credit charges. This allows the PX analysts
to issue payments based on participant's intention. Large cash
disbursements can then be better controlled in dispute situations.
8.2.5 RECEIPT AND CREDIT MEMO PROCESSING
Receipt and Credit Memo Processing Module will provide power and
versatility to manage high payment volumes. An automated process
provides the ability to process receipts sent directly to the PX's bank
via EFT. Direct debits from the participant's bank account can be
transferred to the PX bank account improving cash flow and simplifying
the collection process. Through standard and user-definable fields,
receipt data items such as participant number, amount, receipt date,
check number and bank name/identifier will be maintained.
Receipt processing is very flexible. Multiple receipt types are
processed such as:
- Prepayments/ - Stop payments
Overpayments
- Partial payments - Void payments
- Automatic recurring - Write-off
payments
- One-time customers - Non-A/R receipts
payments (miscellaneous cash
receipts)
The application of receipts allows flexibility for posting to any
invoice item as well as to the participant's overall balance. Users can
apply receipts at a header level or individually.
Debit/Credit memos can be created and applied to specific invoices,
unrelated balances, multiple invoices or to the participant's overall
balance for items not related to invoices.
Reconciliation will be provided. Bank statement items can be cleared
automatically from bank, transaction tapes or manually The system will
support multiple banks as well as user-defined bank accounts.
Standards reports and user defined reports will be provided such as
Cash Receipts Journal, Cash Receipts Application Control Report, Daily
Cash Receipts and Delinquent Checks.
8.2.6 CREDIT AND DECLINES
The objectives of the Credit Management Module are to ensure that
proper credit approval processes are utilized prior to a potential
participant joining the PX and that participants do not over extend
themselves financially and become excessive credit risks to the PX.
The collections process begins once a participant has become delinquent
in the payment of his outstanding accounts receivable balance.
Commencing on identification
89
[GRAPHIC OF MAP]
B I L L I N G A N D C R E D I T M O D U L E
of delinquency, standard approaches to obtaining payment will be
exhausted. Suspension and reactivation of participant's participation
in the PX may be initiated based on current balance information. Based
on participant status, the Bidding Module will prevent trading
activity by those suspended based on creditworthiness. Appropriate
reports will be generated as well as necessary feeds to payables and
receivables. Automatic interfaces for use with a Cash Management
System will be supported.
Online collection tools help track, monitor and collect receivables
and reduce delinquent accounts. An automated scheduling tool lists all
the actions needed to be performed for the day. The online notepad
function enables tracking of calls and follow-up actions. User-defined
dunning letters and statements can be generated which can be viewed at
any time, as well as aged trial balances and key indicator reports. PX
analysts can [illegible] down from participant accounts to the
individual transactions that make up the participant's account or to
the transactions that make up the participant's account or to the
transactions that constitute the balance in a particular aging bucket.
The Billing & Credit Module provides the means for a participant to
apply for credit and for an internal analyst to enter and update
participant credit information on an ongoing basis. Credit checks may
be conducted using TRW, Equifax and/or Dun & Bradstreet (initially a
manual task). Credit histories of any participant can be viewed at any
time by PX operators and revised as new information becomes available.
Standard reporting capability can be tailored by the user to provide
the following reports:
* Write-Offs * Dunning Notices
* Aged Statement of * Daily Collections
Accounts
* Summary Aged * Participant Statements
Balance
* Finance Charges * Monthly Sub-Ledger
Listing
8.2.7 FILING DISPUTE RESOLUTION
Within the accounting functions, a memo facility provides the ability
to attach dispute information to invoices. All details of
conversations with participants can be recorded. The flowable cash
applicant facility allows receipts to be applied partially in any
number of ways to open items. Also provided is the facility to remove
disputed items from aging Windows and Reports throughout the PX system
enable PX analysts to research invoicing disputes through the audit
trails of the system at a line item level.
8.3 USER INTERFACE
8.3.1 ERROR PROCESSING
All data items entered manually or via interface from an internal or
external system are validated according to the requirements determined
in the Definition phase. All errors encountered when a validation
fails against a data item during batch processes are documented in the
database for audit purposes. Audit information on errors will be
accessible to the users through windows and reports.
Multiple errors may exist for a single data item for batch processing,
all errors flagged will be recorded in the database. For window
processing, generally only one error message is displayed at a time.
Each data item will still go through all the defined validations. The
user will correct them in the order the fields appear on the window.
8.3.2 WINDOW INTERFACES
PX analysts will find all windows throughout the Billing & Credit
Module to be user friendly due to standard display presentation and
consistent processing of user actions. Scrolling features, actions and
prescribed functions used on one window will work in the same manner
on other windows. The "drill down" capability and filler processing
will be common features on system windows.
8.3.3 USER INTERFACES WITH BATCH PROCESSING
Most batch processes in the system will occur automatically. PX
analysts will have the ability to suspend these processes
[LIGHTBULB GRAPHIC]
B I L L I N G A N D C R E D I T M O D U L E
if necessary and initiate with manual triggers. The ability to define
parameters to control participant processing is available within the
Invoicing Infrastructure. All batch processing will produce standard
audit trails and reports on records successfully processed as well as
those rejected due to error. Standard and user defined reporting
provides timely information. All of these features provide control,
flexibility and auditability.
8.3.4 AUDIT TRAILS
Throughout the system, complete audit trails of data manipulation is
provided. When records are amended, the original record is rolled to a
history table. Views and reports on these tables can be built as
needed to meet auditing needs.
8.3.5 ELECTRONIC INTERFACES
Billing and Credit Module Files will be produced for electronic
interfaces with Value Added Network and with Automated Clearinghouse.
[illegible]
BILLING AND CREDIT MODULE
[GRAPHIC OF MAP]
8.4 ASSUMPTIONS
Area Assumption
- Taxes: Tax requirements are not included in the fee estimate
because they are not mentioned in the FRD. Fees will be
estimated on a time and materials basis if this functionality
is required.
- Invoice Our estimates and design proposal for billing schedules and
Production: periods are based on our current understanding of the
requirements. Billing schedules and periods will be delivered
by participants.
Proposed billing period terms:
- daily
- weekly
- monthly
If other terms are required, more effort than included in
the defined scope may be required.
- Business In order to proceed in the face of lack of definition, we
Definition: will make assumptions where possible, but at some point
lack of definition will impact schedules.
- Adjustments: Participants will be invoiced based on the final settlement
at D+24. Current period (prior to D+24) adjustments will be
supported but adjustments after D+24 will not be automated.
Those adjustments can be handled through manual entry on the
system.
- Reporting: Most invoice level and account information will be
reported from the facilities that Oracle provides. Only the
reports specified in the proposal will be custom developed.
- Manual Charges other than those created by the settlements
Invoices: module will be entered manually in the system to be
included on a manual invoices or current/future invoice. It
is assumed that most charges (i.e. 98%) will be
generated in settlements and invoiced as described in this
process.
- Disputes: All invoicing dispute procedures will be handled in the
Oracle financials software.
- Adjustments: Manual adjustments will not be charge specific. An adjustment
reason code can be defined to indicate which charge is being
adjusted that will tie back to the charge type. This will
allow the design of a generic adjustment [illegible] rather
than building a unique one for each different charge from
type (because they have different layouts). The following
[illegible] will be entered to identify an adjustment:
- participant Id
- bid id/location
- adjustment reason code
- adjustment description
- quantity, rate and/or charge amount
- Printers: If more than a small percentage of the participants expect to
be billed in hardcopy format, additional printers may be
required than defined in the FRD. These additional printers
are not included in the hardware estimates.
[illegible]
[GRAPHIC]
9. ADMINISTRATIVE SCHEDULING MODULE
P X A d m i n i s t r a t i v e S y s t e m s
9.0 PX ADMINISTRATIVE SYSTEMS
- ----------------------------------------------------------------------
[CHART]
The PX Alliance proposes to provide the Oracle Corporation suite of
applications packages for the PX Administrative Systems, with the
exception of the Payroll/Human Resource systems. The PX Alliance
recommends that the Payroll/Human Resource functions be outsourced to
a commercial services firm because of the factors discussed in the
Payroll/HR section. The Oracle applications provide functionality that
exceeds the PX's existing requirements, are completely integrated, and
provide a seamless interface with the proposed Billing Module.
Ernst & Young LLP (E&Y), in its international partnership with
Oracle, has extensive experience in implementing Oracle Applications,
and has direct connections to Oracle's Product Development
Organization for interfaces, customization and other support. E&Y has
over 303 U.S. professionals dedicated to delivering Oracle based
solutions. E&Y's industry experience enables the Alliance to manage
the risks associated with technology implementations; E&Y's
unparalleled understanding of Oracle Applications puts the power of
information technology to work for the PX.
Choosing the E&Y/Oracle partnership to provide the back-office systems
secures unparalleled application and industry expertise, an unmatched
depth of delivery capabilities, and an integrated and Oracle specific
delivery approach. The PX
[Illegible]
[GRAPHIC OF MAP]
P X A d m i n i s t r a t i v e S y s t e m s
will realize the benefits of a rapid and low risk implementation
that leverages the work products and experiences of prior
implementations to provide for a lower life-cycle cost.
The objective of the Administrative Systems is to support the
PX's financial managers, business unit managers, and external
stakeholders (e.g., regulators, CPJC, FBRC, IRS, etc.) with
accurate and meaningful financial information to fulfill their
specific financial and regulatory reporting needs. The primary
business goals achieved through implementation of these systems
include:
- Delivery of timely, accurate, and relevant financial and
regulatory information in a service-oriented environment
- Providing management and decision support information to
support and increase efficiency and effectiveness
- Timely release of financial information to enable management
decision-making
- The ability to obtain operating results quickly through a
short closing cycle
- Controlled operating costs throuh process efficiencies and
comprehensive management information
- Avoidance of the reliance on manual report verification
(reconciliations) that ensures report accuracy.
The administrative systems described in this section will be used
by the support organizations of the PX (including finance and
accounting, human resources, and purchasing) for day-to-day
business operations. The selected applications that support the
PX's functional requirements are depicted in Exhibit 9.1;
additional descriptions of capabilities for each functional area
are described in Sections 9.1-9.5.
EXHIBIT 9.0-2 PX ADMINISTRATIVE SYSTEMS
----------------------------------------------------------------------
[FLOW CHART GRAPHIC]
92
PX Administrative Systems
The Oracle suite of applications provides the PX back-office staff the
capability to achieve their business goals with ease. The applications
supply structured procedures for the initial development of the business
processes that are easily extended or modified to accommodate the PX's
changing needs. Using Oracle's market-leading technology, The PX Alliance
can rapidly implement solutions that integrate the PX's financial and
operational information regardless of system or format, tailor
functionality to meet specific needs, and expand the system to keep pace
with the PX's dynamically changing business requirements.
For purpose of estimating the cost and capacities for the Administrative
Systems hardware, software and outgoing maintenance, it is assumed that
there will be 25 concurrent users of the Administrative Systems within
the PX.
The following sections provide a functional overview of the Oracle
applications, followed by a description of the interface capabilities of
each sub-system. Concluding each subsystem section in Key Requirements -
a description of the applications' characteristics satisfying the
requirements as outlined in the amended Vol. III Functional Requirements
Document. Additional detailed input, processing, output and reporting
capabilities are described in Appendix K.
3.1 GENERAL LEDGER
3.1.1 Functional Overview
The General Ledger system provided by Oracle is a comprehensive financial
management solution that will dramatically enhance the financial controls,
data collection, information access, and financial reporting throughout
the PX Oracle General Ledger is part of Oracle Applications, an integrated
suite of business solutions designed to support continuous process
improvement for enterprises competing in time official markets. Oracle
Assets, also part of Oracle Applications, is a complete asset management
solution that maintains accurate property and equipment inventory, and
ensures that the optional accounting and tax strategies are chosen.
Oracle General Ledger gives the PX tremendous flexibility for managing and
streamlining its accounting processes.
Multiple calendars and multiple chart of account structures can be defined
to create both financial and RRRC books. Based on user defined rules,
Oracle General Ledger automatically creates new accounts. With the Account
Hierarchy Editor users create and maintain the accounting hierarchy
structure for the organization. Drag-and-drop capability easily
accommodates any type of reorganization.
Oracle General Ledger supports all types of journals: recurring, skeleton,
standard, reversing, and formula-based. Other Oracle General Ledger
functions include Mass Allocation, which quickly and accurately automates
costs and revenue allocations, and the Financial Statement Generator,
which defines custom financial reports such as balance sheets, income
statements, and expense reports without programming.
Oracle General Ledger's business shows reduce the learning curve, improve
the ability to research and resolve problems, and increase daily
productivity. All Oracle workbenches (internal module functions) allow
users to find official information in a flexible way, see the results in a
preferred format and selectively take appropriate action. For example,
Oracle General Ledger's Journals Workbench allows the user to view,
create, modify, optionally post or perform other actions on journals and
journal benches.
Oracle Assets, with its workflow orientation, improves the efficiency of
asset tracking. Deprecation rules default from asset categories. The Mass
Additions interface allows the creation of assets from information in any
feeder system; this improves accuracy and productivity. The Asset
Workbench allows analysis to find assets based on asset detail,
assignment, invoice, or lease information. with a selected asset, the
analyst can review financial assignment, and other detailed asset
information, perform transfer, review the purchasing or other source
information, and retire the asset.
Oracle Assets makes it easy to maintain an asset inventory than supports
the balance sheet. Flexible location codes locates assets quickly. Oracle
Assets also provides reports to inform the fixed assets management of
addition,s transfers, retirements, or other changes, ensuring that asset
inventory remains accurate. Additionally, Oracle Assets manages
construction-in-process projects from inception to completion. Analysis
can track the expenditures incurred during a con-
33
[GRAPHIC OF MAP]
PX A D M I N I S T R A T I V E S Y S T E M S
struction project's file cycle and capitalize them upon completion.
Analysis can also forecast capital spending, project depreciation
expenses, and manage actual capital spending against the forecast.
Because it uses depreciation rules, non preprogrammed logic, Oracle
Assets can be easily customized to meet specific business needs and
local requirements. During implementation, the administrative systems
project team will define the depreciation rules, depreciation books,
and financial information than satisfy the PX;s financial reporting
objectives and tax requirements. Oracle Assets helps the PX derive
maximum tax benefits and avoid paying unnecessary taxes. An unlimited
number of independent tax books can be defined, so a different
depreciation strategy for each tax authority can be developed. Tax
depreciation can be forecosts on several books at once. Oracle Assets
easily adapts to accounting and tax law changes as well as
organizational changes.
9.1.3 COMMERCIAL INTERFACES
Oracle General Ledger and Oracle Assets are fully integrated with all
other Oracle Applications to provide comprehensive, distributed client
server solutions for the PX's financial, human resources, government,
and project accounting needs. General Ledger accepts journal entries
from separate leader systems, including the debit and credit entries
coming from the PX Billing and credit Module.
Open Oracle Assets helps ensure that records remain consistent and
current Mass Additions allows loading asset information from any
feeder system, such as the cost accounting system, [Oracle Projects]
into Oracle Assets. Oracle Assets also eases general ledger
integration by automatically producing all asset journal entries for
the general ledger system.
9.1.3 KEY REQUIREMENTS
THE ORACLE GENERAL LEDGER application accommodates dual charts of
accounts (for both financial and FERC accounting), allocations
functionality and other considerations of FERC accounting. The
General Ledger account coding structure ("accounting flexheld") is
user-definable and is 25 segments long with 30 alphanumeric characters
in each segment. Unlimited charts of accounts may be defined.
Flexibility provided for journal entries and posting activities
includes batch or online posting and recurring automated, and
reversing journal entries. The system provides the capability to
define and automatically process allocations using multiple allocation
bases. This function includes the capability to establish recurring,
standard and reversing journal entries on the system. The system also
provides a mechanism to prompt the appropriate user to complete the
journal entries in necessary and post the entries to the general
ledger.
Journal entries can be created by feeder systems that are not
integrated with the general ledger; Oracle General Ledger can accept
these. These journal entries will be generated by the source systems,
transferred to the general ledger system through interfaces, edited
and validated by the general ledger system, and posted to the general
ledger system. The timing of the transfers will be established by the
accounting department in coordination with the leader department. If
any detailed entries included in the interface are not valid, the
entire journal entry is rejected and suspended. The feeder department
will have visibility of the suspended entries and will be responsible
for correcting and reprocessing the journal entry. This G/L function
furnishes the capabilities necessary to accept and process interface
journal entries. The correction and reprocessing facilities are also
included.
During the monthly close activity the General Ledger system will
generate journal entries to allocate costs across accounts and
departments. Allocations can be accomplished in two ways. First,
allocation journal entries can be triggered by incoming journal
entries based on a predefined conversion table. An amount on an
incoming journal entry may be allocated to several other accounts
and/or responsibility centers. The second allocation method is based
on an allocation table that identifies the accounts and departments
being allocated, the accounts and departments receiving the
allocation, and the method and/or value used to perform the
allocation. When allocations processing is initiated, the allocation
journal entries are generated and posted by the system. This function
provides the
81
PX Administrative Systems
capability to maintain the conversion table and the allocation table.
The function also provides the mechanism for allocation processing based
on these tables.
Oracle Assets provides the capability to establish the depreciation
method, depreciation file and first year conversion for an asset group or
for a specific asset. Depreciation methods can be defined for asset
categories, consistent with FERC and tax regulations. User can then
assign assets to the categories. Oracle supports all the standard
life-based depreciation methods (straight line, ACRS, MACRS, declining
balance, double declining balance, turn of year's digits), as well as
units of production. It also allows users to set up flat rate methods and
other user-defined depreciation methods that do not come delivered.
Additional detailed functional requirements of typical G/L systems are
described in Appendix K.
9.2 BUDGET
9.2.1 FUNCTIONAL OVERVIEW
Oracle General Ledger provides the PX comprehensive budgeting
functionality through its GL Desktop Integrator spreadsheet tool and the
Oracle Financial Analyzer add-on. Users can define as many budget
versions as desired, and password-protect budgets from unauthorized
access. The user can upload budgets from a spreadsheet, or automatically
generate amounts using formulas or Mass Budgeting.
GL Desktop Integrator is a spreadsheet-based tool for entering budget
amounts, entering journals, and reporting on balances. GL Desktop
Integrator operates within Microsoft Excel to take full advantage of
familiar Excel functionality while seamlessly integrating with Oracle
General Ledger. GL Desktop Integrator can run while disconnected from the
server; for example, a user can download a budget from Oracle General
Ledger to a spreadsheet, save the spreadsheet, then work on the
spreadsheet without being connected to the server. The user does not need
to reconnect to the server until ready to upload the revised budget back
to Oracle General Ledger. Additionally, Oracle General Ledger's "profile
options" control which users have access to Oracle GL Desktop
integrator's budget, journal, and reporting functionality, providing
security to sensitive budget information.
Oracle Financial Analyzer is a distributed application for financial
reporting, analysis, budgeting, and planning. By integrating a central
source of management data with powerful analytical tools, the system
enables organizations to meet their critical financial objectives to
control costs, analyze performance, evaluate opportunities, and formulate
future direction. Oracle Financial Analyzer adapts to any business
structure, whether cost centers, products, services, or retail outlets.
The product's models and data can be modified quickly to reflect new
priorities or organizational change.
Ensuring consistent and reliable financial information is key to Oracle
Financial Analyzer. The product maintains the integrity of financial data
in a central source and ensures that users access the data they need.
Access controls allow the administrator to determine, by user, which
financial data can be viewed and edited. Users therefore see and manage
only the information that is pertinent to their responsibilities and
interests. Executives might receive summarized data tailored to their
needs, while lower level managers receive both detail and summary data.
Oracle Financial Analyzer handles budget and forecast creation, review,
modification, and communication within the same system. The product
coordinates and streamlines the budgeting process, whether the
organization uses top-down, bottom-up, or mixed budgeting methodologies.
Oracle Financial Analyzer allocates budget objectives at high levels,
such as quarter and division, to lower levels, such as month and
department. Users can copy last year's actuals into this year's budget
and grow certain balances by five percent. Users can store slices of the
corporate financial database on personal computers to take their budgets
and forecasts on the road. At the close of the budget cycle, the
finalized budget is consolidated to provide enterprise access, and is
locked to prohibit additional modification.
Oracle Financial Analyzer supports a wide variety of financial management
tasks with its financial modeling tools. Multidimensional data navigation
tools allow users to query the financial performance of a profit center
by product, channel, and time period. Results of what-if analyses display
immedi-
[illegible]
P X A D M I N I S T R A T I V E S Y S T E M S
[GRAPHIC OF MAP]
ately. An extensive library of built-in functions helps users create
forecasts and calculate performance ratios. Users can incorporate
general ledger and non-general ledger data into analyses to derive,
and then share, new financial data.
5.2.2 COMMERCIAL INTERFACES
GL Desktop Integrator allows the definition of financial reports
within Excel Spreadsheets and runs the reports using Oracle General
Ledger's Financial Statement Generator (FSG). Accounts, periods, and
currencies can be constructed in rows and columns in the spreadsheet,
and GL Desktop Integrator will automatically create the appropriate
financial statement Generator components, such as row sets and column
sets. FSG output can be automatically loaded into a spreadsheet while
preserving custom formatting. GI Desktop Integrator provides a
spreadsheet-based reporting tool for quickly creating, previewing, and
running financial reports with transaction drilldown. The user can
also drilldown from the balances in the report to the journal and
sub-ledger details.
Oracle Financial Analyzer seamlessly integrates with Oracle General
Ledger. This integration eliminates the need for duplicate data entry,
and thereby provides a more cost effective financial management
solution. Oracle General Ledger information easily maps into relevant
Oracle Financial Analyzer hierarchies and dimensions. Oracle General
Ledger account balances are reflected in Oracle Financial Analyzer.
With a permanent link between the two applications, modifications to
hierarchies and other structures performed in the General Ledger flow
through to Oracle Financial Analyzer without additional maintenance.
Data and structures can be automatically refreshed on a continuing
basis so that data control and integrity are preserved.
GL Desktop Integrator automatically builds budget spreadsheets based
on the budgets and budget organizations setup within Oracle General
Ledger. Users can download existing budget balances from Oracle
General Ledger or create new budgets, entering new budget balances
manually, using Excel formulas, or using GL Desktop Integrator budget
rules. The users can save a budget spreadsheet on their PCs and work
on it at any time, then automatically upload new budget balances into
Oracle General Ledger.
Oracle Financial Analyzer also leverages user knowledge of spreadsheet
applications. On the desktop, the system links directly with industry
standard spreadsheets so that users can view and report Oracle
Financial Analyzer data from those spreadsheets. This link provides
users in the spreadsheet environment access to the powerful data query
tools of the Selector. Extensive file reading capabilities of Oracle
Financial Analyzer can easily load and validate data from general
ledgers, spread-sheets, relational databases, and other operational
systems.
5.2.3 KEY REQUIREMENTS
GL Desktop Integrator provides for on-line submission, review, and
approval or rejection of departmental budgets. The system has
functionality for consolidating both costs, revenues, and other budget
information in order to create projected financial statements. The
system also provides users with the capability of budgeting based on
defined levels of activity.
GL Desktop Integrator provides users with the ability to perform
analysis of actuals vs. Budget within the appropriate
organization/account/cost center and provides access to general ledger
data to support analysis of "budget" variances.
GL Desktop Integrator provides notification based on user-defined
conditions (e.g., inter company out-of-balance, missing
variance/deviation explanations), provides for exception reporting for
"unusual occurrences" (e.g., accounts with either budget or actual
amounts, but not the other) and provides for reporting (printed and/or
on-line) of the variance explanations, including the explanation, the
date/time and person responsible.
Both GL Desktop Integrator and Oracle Financial Analyzer provide an
"exception" basis analysis report. The exceptions would be based on
predefined materiality levels and percentage deviation fillers. For
example:
* Materiality level is $500
* first % filler is 5% deviation
* Second % filler is 25% deviation.
[LIGHTBULB GRAPHIC]
P X A d m i n i s t r a t i v e S y s t e m s
- If determined to be over $500, and over 5% of the budget (or
trend), the account and related data will print on the exception
report.
- If under $500, but over 25% of the budget (or trend), the
account and related data will print as a significant deviation.
Oracle Financial Analyzer provides access to general ledger data to
support analysis of "budget" variances. It also provides the
capability to display or print account variance and deviation data
based on user specified filters (whether budget item, project cost or
overhead costs). The filters can be established and maintained by the
user in order to support management analysis.
Finally, Oracle Alert provides the capability to escalate unexplained
variance notifications to the responsible person's supervisor if no
action is taken in a pre-determined time period. Oracle Alert also
provides notification based on user-defined conditions (e.g., inter
company out-of-balance, missing variance/deviation explanations).
9.3 COST ACCOUNTING
9.3.1 FUNCTIONAL OVERVIEW
Oracle Projects is used to proactively manage the costs, performance
and profitability of projects. Project managers need to manage
projects from their vantage point while financial analysts require the
details necessary to manage the overall business. Project managers
can use Oracle Projects to track detailed costs, manage within budget,
and stay on schedule while successfully achieving the project's
objectives. Oracle Projects translates project details into financial
transactions so financial analysts have the details they require. With
Oracle Projects, project activities are organized and monitored with
an unlimited work breakdown structure independent of the general
ledger chart of accounts.
A project's work breakdown structure provides an efficient mechanism
for managing the project and tracking asset costs as they accumulate
over time. All project related construction-work-in-process (CWIP)
costs for capital projects can be managed in Oracle Projects. Using
the Oracle Assets Mass Additions functionality, project information
flows directly from Oracle Projects to Oracle Assets, minimizing data
entry and ensuring accuracy.
Oracle Projects provides immediate information for informed decision
making, by enabling users to analyze all project data at any point and
make adjustments easily, while maintaining a full audit trail.
Drilldown capabilities provide source details of each transaction.
Users can define the project data they want to see and save these
inquiry formats using Oracle's folder technology. While many standard
reports are provided, managers can avoid reviewing pages of reports
and instead manage by exception. Managers, as well as all users can
automatically receive just the information they need when certain
user-defined conditions exist. Oracle goes one step further in solving
the problem of information access by providing complete
multi-dimensional analysis of critical project information.
9.3.2 COMMERCIAL INTERFACES
Oracle Projects provides a flexible system that lets the user decide
the amount of cost control appropriate. The system tracks and
accounts for all projects costs in the PX with Oracle Project Costing
as the central cost collection repository. Supplier transactions for
projects are easily recorded in Oracle Purchasing and Oracle Payables
(Described in Section 9.4). Oracle Assets provides an interface from
project accounting to the fixed assets module to post the appropriate
asset entries.
Oracle Projects includes integration with project planning and
scheduling systems. The Project Import feature allows users to
define projects in their preferred project planning and scheduling
software and import the project structure and budget into Oracle
Projects. The capability to export summarized project transactions to
the project planning and scheduling software also exists.
9.3.3 KEY REQUIREMENTS
Oracle Applications for Projects provides a flexible system that lets
users decide the amount of cost control appropriate for their needs.
The system will track and account for all project costs in the PX
with Oracle Project Costing as the central cost collection repository.
[ILLEGIBLE]
[GRAPHIC OF MAP]
P X A d m i n i s t r a t i v e S y s t e m s
Charges are input directly or imported via batch interfaces. The
application collects all project costs, both capital and expense,
to reflect the true cost of the project, then capitalizes the
assets in Oracle Projects. Oracle Applications for Projects has
the ability not only to collect expenditures and commitments
incurred against project activities, but also to control which
charges can be made against a project.
Oracle Applications for Projects provides the ability to easily
manage all project related construction-work-in-process (CWIP)
costs and expenses for capital projects, including allocated
overhead and indirect costs. Oracle Project Costing Integrates
with Oracle Assets to eliminate redundant data entry and ensure
accuracy; the application also allows for the adjustment of asset
costs, even after capitalization.
9.4 ACCOUNTS PAYABLE/PURCHASING
9.4.1 FUNCTIONAL OVERVIEW
Oracle Payables is a high-productivity accounting solution that
provides strong financial control, allowing the PX to prevent
duplicate payments, to pay for only the goods and services
ordered, and to receive and maximize supplier discounts. Oracle
Payables provides tremendous flexibility for managing and
streamlining invoice and payment processing. Users define their
own account structure, calendar, currencies, bank accounts,
payment terms, system options and defaults -- all without
programming.
Oracle Payables supports two-, three-, and four-way matching of
purchase orders, invoices, receipts, and requestor acceptance
documents. All the information needed to authorize payments is
online, eliminating the paper flow of purchase orders, invoices,
receipts, and requestor documents. Invoices are approved online
during invoice or batch entry.
Oracle Payables provides the information needed to make effective
payment decisions. It provides the PX control over when and how
to pay suppliers using flexible supplier, system, and payment
options. Oracle Payables can also create laser-printed checks.
Oracle Payables saves money by forecasting cash requirements and
preventing duplicate and unauthorized payments. Analytical
reports and system, supplier, invoice, and payment batch options
ensure that the PX takes all favorable discounts.
Oracle Payables helps resolve business issues quickly by
providing immediate and accurate responses to supplier inquiries.
Invoice and Payment Overviews allow the review of high-level
invoice and payment status information in a single window. The PX
can also record detailed information about its suppliers,
including their purchasing, payment, and invoice processing
preferences. Oracle Payables also supports flexible address
formatting.
Oracle Purchasing is a complete purchasing solution that helps
process requisitions, purchase orders, RFQs, and receipts quickly
and efficiently. Oracle Purchasing simplifies routine
transactions, allowing the procurement staff more time for
strategic tasks such as negotiating better contracts, developing
the supply base, and performing value analysis.
Using templates, requisitions are quickly and easily generated by
providing the requestor, cost center, and quantity for each item.
Using AutoCreate, purchase orders are generated from requisitions
created by online requestors, or inventory replenishments. Oracle
Purchasing even automatically builds account distributions.
Complete online access reduces paper shuffling. Requestors can
create requisitions online and route them automatically for
approval. Online approval and security options enforce specific
business requirements. For example, the PX can ensure that only
authorized personnel can approve requisitions. The package also
provides automatic routing; for example, routes requisitions
needing approval to the next [illegible] reviewer or directly to
the next reviewer with sufficient dollar limit authority to
approve the requisition. Oracle Purchasing's new Supplier-Item
Catalog feature allows requestors to browse through self-defined
or supplier-provided catalogs, select the required items, then
create a requisition at the touch of a button.
Oracle Purchasing's powerful receiving features gives full
dock-to-stock tracking of receipts and inspections. Additionally,
the new Cascading Receipts feature facilitates quick, error-free
receiving of consolidated deliveries by due date. Plus, online
inquiries and reports give the receivers the information they
need to process receipts and expedite late shipments.
39
P K A D M I N I S T R A T I V E S Y S T E M S
Oracle Purchasing also provides budgetary control features that allow
the PX to:
* Use budgetary control or expense or inventory purchases
* Activate encumbrance and budgetary control by account
* Check funds availability before approving document
* Control budgets at a summary or detail level
* View and report on outstanding requisition and PO encumbrances
Invoice Matching
* Prevent payment of invoices until the quantities on invoices
match the quantities ordered, received, and inspected
9.4.2 COMMERCIAL INTERFACES
Oracle Payables and Oracle Purchasing are fully integrated with other
Oracle Applications to provide comprehensive, distributed
client/server solutions for the PX's finance, human resources,
regulatory and project accounting needs.
Oracle Payables desktop integration can revitalize internal
communications by allowing users to visually enhance, graphically
display, and distribute all reports using other desktop tools.
Oracle Purchasing and Oracle EDI Gateway combine to provide support
for the outbound Purchase Order Change Request EDI transaction,
allowing the PX to send purchase order revisions to supplies
automatically.
9.4.3 HEY REQUIREMENTS
Oracle Payables automatically matches an invoice to a purchase order
when furnished the purchase order number. Oracle Payables
automatically provides the information, performs the matching, and
supplies the accounting details based on the matched purchase order.
All invoice information can be viewed online, including any notes or
other multimedia attachments.
Oracle Purchasing processes requisitions, purchase orders, RFQs, and
receipts quickly and efficiently, managing the entire pronouncement
process from bidding activities through to generating purchase orders.
Oracle Purchasing's online approval and security options enforce
specific business requirements. For example, it can ensure that only
authorized personnel can approve requisitions. The system can also
route a requisition needing approval to the next defined reviewer or
directly to the next reviewer with sufficient dollar limit authority
to approve the requisition.
Oracle Payables handles every form of payment, including manual
payments, wire transfers, bank drafts, electronic funds transfers, and
automatic checks. Payments can be automatically recontrolled with
bank statements. Oracle Payables can also create laser-printed checks.
Additional detailed functional requirements are provided in
Appendix X.
9.5 PAYROLL/HUMAN RESOURCES
9.5.1 FUNCTIONAL OVERVIEW
The PX Alliance recommends that the payroll and human resource systems
be outsourced to one of several companies that specialize in these
services. This others several distinct advantages including reducing
cost and allowing the PX to focus its resources on core operations.
Outsourcing Payroll/HR reduces cost in the following areas:
* Payroll labor cost that is the labor associated with payroll data
input, maintenance and administration.
* Payroll non-labor costs such as the overhead associated with
maintaining the payroll department such as stationary, heating,
lighting, space, etc.
* System labor costs which is the labor associated with maintaining
and operating the payroll system.
* System non-labor costs such as the overhead associated with
operating the payroll systems such as license fees, hardware
depreciation, etc.
The PX Alliance [ILLEGIBLE] as PX Systems integrator, provide the
services necessary to contract with the chosen Service Bureau and set
up all Administrative Systems interfaces and communication links. The
Alliance will also provide the testing, training and establishment of
procedures necessary to
[LIGHTBULB GRAPHIC]
[MAP GRAPHIC]
P X A D M I N I S T R A T I V E S Y S T E M S
assure the successful execution of the PX's Payroll and Human
Resource functions.
The PX can be more productive by allowing employees to focus on
managing the core business without having to worry about payroll,
payroll tax, government compliance, etc. The PX would only require
two cross-trained payroll and human resource employees to effectively
manage this function.
The outsourcing of services provides tremendous flexibility for
tailoring and managing payroll and human resources systems. As the
needs and desires of the PX change, the payroll and human resource
systems can be modified with additional functionality while still
remaining most if not all of the existing system.
ADP, Paychex, Ceridian, Pay USA, and Dataccounc are among the
outsourcing companies contacted to identify the typical payroll and
human resources services capabilities of service providers. It was
determined that they all met the functional requirements of the PX and
provide many additional benefits as described in the following
sections.
The payroll and human resource provider assumes the liability for
accurate, timely tax deposits and filings. The expert payroll and
taxstaff at these companies respond on the PX's behalf to all payroll
tax inquiries from tax agencies. The PX's master files are secured and
maintained by the payroll and human resources provider through regular
systems back-ups.
The payroll and human resources service provider monitors, researches,
and maintains compliance with constantly changing tax and human
resource regulations at the federal, state, and local levels. The
provider also maintains up-to-date tax deposits and Wing schedules.
The payroll and human resource systems are protected by passwords or
other special log-on codes so that only authorized users have the
ability to view or manipulate any employee information. An audit trail
is available for the payroll and human resource system so that user
changes can be reviewed.
The payroll and human resources providers offer feature with graphical
user interfaces to allow access to critical information and for
viewing and creating standard and custom reports. The familiar windows
environment helps the user navigate through the system inauditively
and the pull-down menus, mouse actions, icons, and built-in Help
screens allow transactions to occur easily and quickly. A wide
variety of standard and customer reports are available for the users
of the system. Both sets of reports are created in a windows
environment and can support Windows 3.1, Windows 95, or Window NT
operating systems. Payroll data can be exported to other applications
such as Lotus, Excel, or Word to give the PX's personnel the
opportunity to perform additional analysis.
Customer service is of paramount importance to the payroll and human
resource providers. Typically, one specialist is assigned to address
any and all questions relating to the PX's system. Training is
conducted at either the client site or at the payroll and human
resource provider's location depending on the company, to ensure the
payroll and human resource is operational and to ensure PX personnel
are completely comfortable with their responsibilities and operating
the system.
9.5.2 COMMERCIAL INTERFACES
Information is exchanged between the integrated payroll, payoff tax,
and human resources systems such that changes to any employee field
in one system is automatically updated in the other systems. This
greatly reduces data entry errors and gives users immediate access to
employee-related information. The payroll and human resource systems
also archive current and past files for easy retrieval.
9.5.3 KEY REQUIREMENTS
The payroll and human resources service bureaus completely furnish the
requested functionality for maintaining the PX's organizational
structure, backing applicants, recording employee information,
processing payroll and benefits for all employees and time reporting.
The payroll and human resources service bureaus fully comply with
federal, state and local employment laws.
Additional detailed functional requirements are provided on Appendix
K.
916
[GRAPHIC]
10. PROJECT MANAGEMENT
Program Management Approach
10.0 PROGRAM MANAGEMENT APPROACH
- --------------------------------------------------------------------------------
The objective of the program management approach for the PX is to create
an integrated organization which applies a systematic method to the
planning,e execution, control and reporting of the PX System project. The
deliverable milestones in the Project Plan provide an objective common
baseline for communication to stakeholders, including state legislatures,
utilities, regulators, project team members, and the Market Participants
as well as the PX management.
Projects for each functional module (sub-system) will be integrated into
the master project plan. Perot Systems will serve as the PX Alliance
Systems Program Manager (PM), coordinating the integration of the PX
Alliance partners' efforts across all projects, and additionally
establishing project reporting standards. The governance of the Program
Plan will be through a Change Control Board, which will be composed of
members from the PX management staff, the PX Program Manager, the PX
Alliance Program Manager, the Subproject Manager, and a Change Control
Coordinator. Issue resolution resulting in project plan changes in excess
of defined limits will be approved by the Change Control Board. Exhibit
10.1 illustrates the program management structure envisaged for the PX
Development Project.
EXHIBIT 10.1 - PX SYSTEMS PROJECT MANAGEMENT ORGANIZATION
- --------------------------------------------------------------------------------
[FLOW CHART]
XI
[LIGHT BULB GRAPHIC]
P R O G R A M M A N A G E M E N T A P P R O A C H
[GRAPHIC OF MAP]
The PM has the responsibility and authority to manage the subprojects within
the integrated program plan. The PM will serve as the point of coordination for
all reporting communications and change management or the program baseline plan.
The PX change Control Board will consist of a PX designated Change Board
member. PX Alliance Program Manager, Managers of all subprojects, and the
Change Control Coordinator. The Change Board will resolve issues which exceed
budgetary, scope or schedule tolerance [illegible] defined in the project plan.
The PM will have a staff of experienced project managers responsible or the
coordination and consolidation of all project reporting, project plan changes,
project library maintenance and issue resolution. This program staff will be
responsible for selling the level of required reporting metrics, naming
conventions and report formats across the project. They will manage the
repository for the policies and procedures of the program management processes.
The staff will also schedule and facilitate the weekly meeting for subproject
management staff.
The PX Alliance team members will each have an appropriate staff of project
leaders accountable for the successful implementation of the subproject plans.
Since each subproject will be developed and validated as independent components
in parallel, these project leaders will validate task completion, coordinate
issue resolution and inter-project issues at the subproject level, track
project status, review project plans as appropriate and in conjunction with the
Program Management policies and procedures, assess impacts of project plan
changes, and provide cost reporting information at the subproject level. They
will provide project team members with a weekly listing of tasks to be performed
and will facilitate intraproject communication.
EXHIBIT 10.-2 STATUS PROCESS FOR SUBPROJECT LEVEL
- --------------------------------------------------------------------------------
[GRAPHIC]
[illegible]
Key participants in the team are assigned for the duration of the project's
phases. However, some exceptions may result from promotions, transfers,
resignations, etc. In such instances, the PX Alliance members will inform
the customer's Program Manager of any significant pending changes and will
communicate the timing and qualifications of replacement personnel. A
smooth transition to effect knowledge transfer will be required and will
be approved by the Program Manager when complete.
The PX Alliance PM's day-to-day contact with PX management will be via the
PX Program Manager. The PM will initiate and maintain regular
communication, both formally and informally, with the PX Program Manager
and the program sponsors to assess and communicate progress and resolve
issues. The PX Alliance's Program Management team will work jointly with
the PX Program Manager to plan, manage, and control the project activities
through the completion of the PX Systems Program Plan.
10.1 PROGRAM/PROJECT MANAGEMENT OBJECTIVES
Program/Project Management is the systematic approach to managing the
initiatives, scope, priorities, risk and resources necessary for
executing the project plan and meeting the delivery milestones. This
includes managing business process technology; monitoring organizational
changes and their progress; identifying, managing, and minimizing the
risks contained in the execution of the program plan; establishing program
and project priorities which reflect the customer priorities as
established in the program plan; and providing a structured approach to
the sponsorship of change to the program plan.
The objective in instituting a robust Program Management methodology are:
o To ensure timely delivery of a quality product to the customer;
o To provide support, coordination and leadership in addressing issues
that transcend more than one project,
o To validate the progress reported on the project plan at intervals
where integration and communication are vital;
o To inform the customer of issues, risks and concerns in a timely
manner so that a measured response and management can be implemented;
o To provide a function of Systems Integration and Coordination which
identifies and communicates disconnects early in the process;
o To provide a consistent work breakdown structure for the project
reporting;
o To systematically manage the development and implementation of the PX
Systems with the initiatives undertaken by other PX and ISO
development efforts;
o To jointly develop, with all stakeholders, a proven process for
implementation of the PX Systems to achieve the results of the
program.
Accordingly, the PX Alliance members have integrated their respective
project management methodologies to provide a structured Program
Management process that provides the following benefits:
o Milestone definitions which clearly state what is required for
completion of the milestone;
o A process for measuring, reviewing, validating and integrating
multiple project deliverables across the entire organization;
o A proven, integrated issue resolution process which has been utilized
successfully in prior projects;
o Definition, measurement and management of project estimates, costs,
risks, and quality.
The establishment of the Program Management team provides a local point for
all reporting, project inquiries, project reviews and coordination of
cross-functional issues. The size, complexity and diversity of the PX
Systems development efforts require a structural environment and central
knowledge database for use in the coordination, integration, management
and control of the large number of projects in order to provide
consistent, factual, validated information to the customer and to the
stakeholders in this project. The PX Alliance's Program Management
methodology satisfies these requirements.
10.3
PROGRAM MANAGEMENT APPROACH
[MAP OMITTED]
10.2 PROGRAM/PROJECT MANAGEMENT METHODS
As part of the Program Management method, regular intra-program
communication of progress, statutes and issues will be established to
ensure that all parties are performing on schedule and at the desired level
of quality. Any slippage and issues affecting one or more teams will be
identified and addressed so that the impact on the other teams can be
readily assessed and addressed. In addition, the Program Manager will
facilitate the management of risk, scope, issues, and quality, and will
also facilitate the transfer of knowledge across teams to ensure that
risks are mitigated and economies of scale are gained.
The elements of the PX Alliance's Program Management are:
o Risk Management
o Scope Management
o Issues Resolution
o Quality Management
o Knowledge Coordination and Transfer
o Customer Interface
o Market participant Coordination
o Stakeholders Communications
10.2.1 RISK MANAGEMENT
Risk Management is the process of identification, analysis and response to
risk factors throughout the life of the program. Program Risk consists of
the following factors:
o Risk Event or Identification
o Risk Probability
o Amount at Stake (in terms of schedule, resources, or scope).
RISK IDENTIFICATION
One of the shortcomings of many project management efforts is the lack of a
centralized or global view of Risk Identification. The Program Management
approach proposed by the PX Alliance is designed to provide a centralized
view of project risk. What seems a very small risk in the context of an
individual project can be very large when applied to the Program as a
whole. The PX Alliance will utilize a single process to identify both
Risk and Issues concerning the project. When the Risk/Issue is categorized,
it will be communicated to the appropriate parties program-wide so that the
full potential impact of the concern is assessed.
The matrix shown in Exhibit 10.2.1 will be utilized for the analysis of
risk on the project.
10.4
P r o g r a m M a n a g e m e n t A p p r o a c h
EXHIBIT 10.2-1 Risk Management Function Matrix Chart
- --------------------------------------------------------------------------------
[GRAPH]
IMPACT ANALYSIS
Proven Program Management methodology requires that areas of higher risk are
monitored more closely than those with lower risk. For that reason, the Program
Office will require greater detail in the planning effort for known areas of
risk. In come cases, a series of apparently minor delays (when viewed on an
individual basis) may result in additional project risk. In this instance the
Program Office will require additional detailed planning for all affected
project plans in order to mitigate the risk.
RESPONSE PLANNING
As a result of the integrated view of Risk Assessment, the strategy for planned
response to individual instances of potential or realized risk will be
formulated and communicated to the PX Alliance program. These responses may
involve mitigation and contingency planning.
10.2.2 SCOPE MANAGEMENT
Scope Management entails tracking, investigating communicating and resolving
requests for project changes that affect the established project boundaries,
deliverables, budget or schedule. Vigorous scope management will be essential
in facilitating the timely delivery of the operational system. Any change in
scope must be clearly understood and approved by the Change Control Board. The
Customer may request a change in the project scope. the parameters surrounding
the requests are discussed in detail later in this section (Customer Changes).
The natural discover process where initial assumptions are revised and
functional requirements clarified normally creates pressure to expand project
scope: It is essential that the approved program plan establishes clear and
measurable milestones for each project. The many PX commercial sub-systems all
have interfaces with one another and will additionally have interfaces with
external systems such as the ISO
10.5
P r o g r a m M a n a g e m e n t A p p r o a c h
systems and possibly with market participants. There will be many requests to
expand the functionality of individual projects beyond their original charter
to accommodate changing needs, both internal and external. Strict adherence to
scope management procedures will be necessary to control such requests and
ensure the timely delivery of the final business solution.
The scope management process consists of confirming the initial program scope
and constructively controlling efforts to facilitate subsequent scope reviews.
This is the process which compares the original baseline project plan with
proposed changes to requirements, implementation, timing and costs. Due to the
compressed schedule for implementation, scope change must be effectively
managed to deliver a fully functional project on time. If the Change Board
agrees that changes are justified, the impact to the project is analyzed. The
project plan may be changed when the resulting project changes (i.e., cost,
timing, quality, resource requirements) are approved.
MANAGEMENT CHANGE REQUESTS
The change request procedure will provide the formal mechanism for the
submittal, documentation, screening and disposition of reviews to change the
documented project scope. Formally capturing change requests in a change
request log (or database) assists in communicating requests. It also provides
the benefits of establishing an audit trail of project changes. Change requests
will be managed by the PX Alliance Program Management team. There will be
review parameters applied to scope changes and any associated changes in cost
and schedule. These parameters will be applied consistently program-side. Each
schedule will be assessed as part of the monthly consolidation process for
reporting to determine that milestone dates have not changed without proper
approval. The master copy of the schedule will be maintained in the Program
Office and will serve as the plan of record.
CUSTOMER CHANGES
The Customer may change scope of the project through adding, deleting or
modifying the work and the specification. The Program Office for the PX
Alliance will review the impact of such requested changes with the Project
Managers within 5 calendar days of the receipt of the request.
Minor changes may be required by the Customer. In all cases, an analysis will
be performed on the impact (schedule, resources, scope) of the integrated
solution proposed by the PX Alliance. All change requests form the Customer
must be approved by the PX Program Manager. This close control is necessary to
deliver a quality product without jeopardizing the delivery date of the product
and to control the flow of change requests associated with the project.
ASSESSING PROJECT IMPACTS
The subproject teams will identify the impact to the project deliverables,
schedule, resource requirements, quality, project budget, and any other
implications. They may or may not assign the change request to an individual
for further detailed analysis. Regardless, the team will be responsible for
recommending whether to incorporate, defer or reject the change request. The
recommendations should assess whether the benefits associated with implementing
the change outweigh financial and political costs to this or other projects.
The impact of the change will be communicated to the Change Board in the review
process.
REVIEWING CHANGE REQUESTS
The PX Alliance Program Office will be responsible for communicating change
requests and implications project-wide. Change Board approval is necessary for
any formal change requests that result in changes to the overall program plan.
If a change is approved, the project charter and project plan will be updated
to create a new baseline for measurement, and the record of the change will be
maintained in the project library.
SCOPE REPORTING
The PX Alliance will report (in triplicate) the status of the project on a
monthly basis to the customer. Each of the monthly reports will list the major
deliverable milestones and the status of each. The major issues/concerns/risks
which have been identified during the month will be reported. The monthly
report will provide "workarounds" or corrective action plans for each area
which reports a sig-
10.5
PROGRAM MANAGEMENT APPROACH
nificant variance. The requirement that Program Management supports a
monthly report justifies the establishment of Program Office members
from staffs of each of the three subproject areas (PSC, ABB, EY), as
detailed reporting (weekly or biweekly, depending upon project risk)
during the month is necessary to support the monthly summary report.
The documentation of change actions of scope reporting will provide a
traceable baseline project plan for reporting to outside stakeholders.
This is particularly important on a highly visible project. This
process will provide a means of explaining project changes from the
inception of the project to its completion.
10.2.3 ISSUES RESOLUTION
An issue is defined as any unresolved matter that may have an impact on
the progress or program completion. conscientious issue management
establishes a visible decision-making process and creates a means for
reaching consensus on cross-project issues. This is critical for PX
stakeholders who have diverse interests. Also imperative for
development projects is the creation of a project audit trail, which
the issue/change management process creates. The development of and
adherence to robust issue management serves to expedite issue
resolution and ensure strong relationships.
The Program Manager will define an issue resolution process for the PX
Alliance which has contract terms and conditions and involves the
Change Board at appropriate levels. Project offices for each subproject
will be instructed in the defined process; consistent compliance to the
issue resolution process will be maintained throughout the duration of
the project. Although stakeholders will be briefed on the established
procedures and encouraged to use them at the onset of the PX Systems
development effort, the project management teams for the subprojects
have responsibility to ascertain that all raised issues are captured
and submitted to the Program Office for screening, investigation
coordination, prioritization and resolution. The issue resolution
process will be documented with procedures and will be maintained in
the Program Office as part of the Project Library.
ISSUES MANAGEMENT
Issue management establishes a visible decision-making process and
creates a means for reaching consensus on issue resolution across
projects. An issue is defined as a deliverable or project process which
has been identified as not functioning as expected; not well understood
or defined; needing revisions or changes; or delayed. the output of the
issue resolution process can be a resolved misunderstanding internal to
the project, a change in the project scope (change action), the
definition of additional areas of risk, and/or a change in the
contract.
The development of and adherence to a robust issue management process
facilitates issue resolution and places appropriate priority on issues
of critical importance to project success. The issue management
procedures identify the steps and guidelines in elevating issues beyond
the project team and the decision-making authority of all parties
involved.
10.7
PROGRAM MANAGEMENT APPROACH
EXHIBIT 10.2.3-1 BASELINE RESOLUTION/CHANGE ACTION PROCESS FLOW MODEL
[FLOWCHART]
[GRAPHIC OF MAP]
P r o g r a m M a n a g e m e n t A p p r o a c h
THE ISSUE RESOLUTION PROCESS
An issue can be raised from any area of the organization as well as by the
customer. In the Program Office, the Issue Log records pertinent information
about an issue. The Issue Log uniquely identifies each issue with a priority
number, category and project code. This is a great advantage in a highly
visible project, as there is audit ability on the decisions made and the timing
of the issues raised. A team comprised of a Program Office Project Manager and
a Subproject Manager and a Subproject Manger will investigate the issue and
recommend resolution. If the recommended resolution is a change in scope, a
change action will be initiated. If the recommended resolution is a change in
process or organization and does not affect the project plan milestones or
cost, the change may be implemented with the approval of the Program Manger and
the Subproject Manager. The PX PM will be provided with a listing of issues
raised in the monthly report.
If the customer requests a change in scope, the process described in Scope
Management (in Customer Changes) will be used.
QUALITY MANAGEMENT
The scale of the PX System requires careful project management to coordinate
multiple participants and the many sub-projects. In addition, the PX System
require parallel development of the components to meet its aggressive schedule.
Together, the scale, complexity, and parallel development introduce significant
risk to the quality of the completed system. To mitigate this risk, the PX
System will implement a coordinated, comprehensive quality assurance plan.
Normally, a unit test approach is sufficient for software and hardware systems
because they act in a stand-alone fashion with a strictly defined set of inputs
and outputs. In the case of large systems, unit testing of the components is
necessary, but is insufficient for ensuring the delivery of a quality system.
The interaction of the components becomes complicated, and therefore a
potential source of concern.
The PX Alliance will apply an iterative, tiered approach to quality assurance
to insure the successful delivery of the PX System. Testing at the component
level will include the development of test cases and a regression mechanism to
insure that each component meets its individual requirements. These test cases
will be applied at the component level on an ongoing, iterative basis to catch
potential design defects early in the development cycle. In parallel with
component testing a System Integration test plan will be developed to insure
that the overall system meets its requirements, verifying that the components
have been properly integrated.
The PX Alliance will divide the responsibility for system integration, test
planning and component test planning. As the program manager, PSC will be
responsible for overall management of quality assurance. PSC will also be
responsible for the system integration test planning and execution. ABB and E&Y
will be responsible for the unit test planning and execution of each of the
components they are developing.
The System Integration test plan and roles are described in the following
section.
SYSTEMS INTEGRATION TEST APPROACH
The PX project has been described in terms of its functionality and how each of
these components will be delivered by the various partners in our proposal. The
only way to meet the objectives of the PX project is to develop the
applications in parallel. However, the true value of the PX is in the
functionality of the aggregated system. Each partner will manage its component
parts, many of which are industry leading applications in their own niche. A
major risk in such a project is that although each of the components works
independently, the overall project will not work efficiently when integrated.
Mitigation of this risk lies in the ability of the PX Alliance to bring these
parts together into a working system.
Our approach to Systems Integration is to recognize it as a development effort
in itself. Our integration work will be subject to the same rigorous Project
Management techniques as any other development activity. The efforts will
involve project management, version and release control, performance, test
planning and validation, and operational certification. In a project which
incorporates many existing building blocks on such a tight schedule, relegation
of Systems Integration work to the end of the project would present an
unacceptable risk to schedule and quality. We
109
P r o g r a m M a n a g e m e n t A p p r o a c h
will begin System Integration and release planning at the project
inception to mitigate this risk.
10.2.5 KNOWLEDGE COORDINATION AND TRANSFER
The Project Library is established to include all documentation,
issues or changes to the project plan. This facilitates the sharing of
information, knowledge, solutions and ideas across all teams and
prevents duplication of work. The iterative development of market
protocols presents potential pit-falls; firm adherence to a
centralized knowledge coordination policy prevents potentially wasted
development effort. Additionally, the integrated nature of the systems
being developed requires coordination of the information that is
passed among the project teams.
Procedures are developed for the following aspects of this process:
o Document and data backup
o Document consolidation
o Version control
o Document management (naming conventions, control policies)
o Inter-project coordination (knowledge dissemination, standard
reporting, Standard WBS)
DOCUMENT AND DATA BACKUP
The Program Office will hold all files of record for the program plan
and for the project documentation. The hard drive for the Project
Library will be backed up daily and an additional copy of the master
schedule will be maintained on a separate storage facility. All
projects will have the following documentation:
o Completion criteria for each Program element
o Milestone Listing and Dates for Completion (projected and baseline)
o Listing of Interim Milestones and Dates for internal tracking
o Roles and Responsibilities Matrix
o Resource Plan
o Network Diagram with Critical Path
o Corrective Action Plans for Significant Variances
DOCUMENT CONSOLIDATION
The Program Office will consolidate the schedules from all project
plans on a monthly basis, and will provide a report (in triplicate) to
the customer. The Program Office Master Scheduler will have the sole
responsibility for schedule consolidation. The Program Office Change
Management Coordinator will have the sole responsibility for tracking
changes to the baseline and validating that they are incorporated into
the project plan. The Master Scheduler and the Change Management
Coordinator will be cross-trained in the event that either of them is
unavailable for the monthly consolidation process and to ensure
continuity of the Program Management staff.
VERSION CONTROL AND DOCUMENT MANAGEMENT
As stated before, the master schedule will be maintained by the
Program Office and will be updated as required through Change Actions
and Status Reports. Each month, the consolidated project status will
be archived prior to issuance and consolidation for the new project
report. The versions will be updated each month (if there are no
mid-month change actions) or at each change action, whichever is more
frequent.
INTER-PROJECT COORDINATION
A critical success factor for the PX Project is Project Integration.
The project managers must be the communicators to management, to the
project teams in other sub-projects, and to others who have an
interest in the project's results. This is an important role because,
with all the information coming to the project manager from many
different sources in different forms, the project manager must become
the "translator" to forward the appropriate information to the
appropriate recipients.
In order to coordinate the efforts of multiple sub-projects and
project status reports, the need for an inter-project coor-
10.10
PROGRAM MANAGEMENT APPROACH
dination function is recognized and will be provided for early in the
project. This function will be staffed with experienced project managers.
The project managers also play a key part in the issues resolution
process, in that they are the facilitators for discussion and
communication. The Program Manager has the responsibility for bringing the
diverse groups together in a weekly forum for discussion of problems,
information exchange, accomplishments, or issue identification.
Another factor in successful inter-project coordination is the role
of the Systems Integration staff. They will be assigned to sub-projects
across the PX Project in order to coordinate the technical scope across
projects. They will convene weekly to discuss the status of the project
and exchange information.
10.2.6 CUSTOMER INTERFACE
The PX Alliance PM serves as the primary point of contact between the PX
Alliance partners and the PX Trust Advisory Committee. The PX Alliance
Program Office is also responsible for directing and coordinating ample
customer involvement in the PX Systems development projects to secure
adequate exposure to and acceptance of PX systems, as well as to obtain
sufficient information regarding customer requirements.
For the PX Program to be successful, those who will be using the business
system should be involved in defining the requirements of the system that
they will use upon delivery. This will not only give the project
developers the benefit of an early indication of the project's acceptance,
but will also establish ownership of the systems by the customers.
The PX Alliance Program Manger will work with the PX Program Manager to
define and establish a Customer Council. This council will be composed of
a small representative sample of the end-user community. The Council will
be co-chaired by the respective Program Managers. The mission will be to
provide early two way feedback about the PX project throughout the
project's life. The items covered can be somewhat flexible (at the
discretion of the Council Chart) but will include at a minimum end-user
review of data input and presentation screens, end-user review of the
processes required for system use, usage scenarios, and some user
participation during project testing phases. The Council will meet
throughout the project life and the Chair will establish an event-driven
schedule with the PX Alliance.
Our expectation is that this constant exposure of the project to the user,
exposure of system developers to users, and stepwise refinement of the
important user interfaces will produce user buy-in to the project and will
further enhance the qualify of the business solution as a result of the
valuable information that will be exchanged.
10.2.7 MARKET PARTICIPATION COORDINATION
The PX Program Office will coordinate with Market Participants to ensure
their active participation in the development of PX project plans. Their
involvement is necessary to ensure the adequacy of the developed systems
to support the market mechanics being defined in the FERC filings. As
mentioned in the prior section, the Customer Council will serve as the
primary interface between the market participant end-users and the PX
Project.
10.2.8 STAKEHOLDERS COMMUNICATIONS
Stakeholder reporting will be divided into two groups: 1) Executive level
and 2) Project Detail Level. The Executive Level report is for wide
distribution and contains an executive summary, a high level issues/
concerns, a risk summary, a high level project status (actual vs. planned)
and a high level summary of the Milestones for the project (with status of
each. The Project detailed Level reporting will contain, in addition to the
executive level information, a detailed version of the consolidated project
plan and the detailed corrective action (workaround) plans for area which
are experiencing difficulty. This reporting process allows the PX Program
Office to disseminate information to stakeholders in a form that is easily
understandable.
PX TAC REPORTING
The PX Alliance PM will work with the customer's PX Program Manager to
develop a standardized report conveying the PX Systems project status for
presentation to the PX TAC on
10.11
[GRAPHIC OF MAP]
Program Management Approach
a periodic basis (no shorter than quarterly). A monthly management report
will summarize aspects of project activity to satisfy the TAC's
information requirements, including schedule progress, accomplishments
(milestone or deliverables), budget performance, relevant issues (e.g.,
scope changes), and planned activity.
PX TAC Reviews
The PX Alliance PM is the liaison responsible for coordinating the
involvement of the PX TAC (or its designees) in forms, reviews of
project progress and project quality. The PX TAC is expected to provide
formal reviews and approvals at the completion of the major project
phases of the PX Systems.
[GRAPHIC]
11. PX SYSTEMS ROLLOUT
P X S Y S T E M R O L L 0 U T
11.0 PX SYSTEM ROLL-OUT
- --------------------------------------------------------------------------------
11.1 INTRODUCTION
The Roll-out of the PX System involves set-up of the PX hardware,
creation of the Help Desk Function, completion of the required business
system build, and validation of the interfaces, including those to the
PX market participants and the ISO Systems. The Roll-out will be
carefully coordinated to provide a smooth and secure startup while
establishing the foundation for successful migration to PX operation.
The system Roll-out and training for the Power Exchange is an essential
part of the implementation plan and will be closely coordinated by the
PX Alliance. Component elements include:
o Installation, configuration and testing of systems architecture and
infrastructure.
o User support and service desk support during trial and early
operational phrases.
o Development of training modules and training of up to 2000
participants.
o Development of on-line user manuals.
o Formalized user trial of at PX systems.
o Market simulation exercises to identify difficulties and recommend
options for change.
The PX Alliance has particular strengths in managing such tasks, with a
depth of experience in energy and financial service markets where new
systems are rapidly introduced and integrity and security are critical.
The PX Alliance will base the PX Roll-out after Perot Systems'
innovative proprietary global training and development system called
SPIRIT. A methodology produced in collaboration with major clients,
SPIRIT has received wide at claim in the US, UK and Germany for the
Roll-out and implementation of large scale, distributed software
systems. SPIRIT accomplishes the roll-out of the distributed, large
scale system like the PX, with a two-week immersion program designed for
users and client personnel. This immersion program integrates various
disciplines, such as project management. Business Process Reengineering
(BPR) methodology, team working simulation and case study elements, to
both implement the distributed hardware and software for the PX System
and gain maximum buy-in of the PX market participants in the use and
business functionally of the PX System.
11.1.1 ROLL-OUT DESCRIPTION
The PX Alliance recognizes that the successful implementation of an
operational Power Exchange for California depends heavily on the
planning and execution of the Roll-out of the integrated PX Systems. As
part of the Project Plan, we will work with the PX Staff and the
stakeholders to develop a detailed Roll-out plan that will guide the
process.
The first step is the installation, configuration and testing of systems
architecture and infrastructure. The infrastructure and implementation,
which form the basis for a successful Roll-out, are described in
Section 2 and Section 3 of the Technical Proposal.
The Roll-out of the implementation program brings the systems, processes
and people into an integrated system that forms the operational Power
Exchange (PX). Prior to this, a clear definition of processes will
ensure that the Roll-out progresses smoothly. These processes are
illustrated in Figure 11.1.2-1 through 11.1.4-1 and detailed in the
following paragraphs. There are three main processes/procedures of the
Roll-out program necessary to ensure a smooth roll-out progression:
o Participant User Procedures. This involves all the aspects
associated with providing users tools and access to the business
information of the Power Exchange. It includes preparing and
producing user guides as well as establishing training courses for
users.
o Operations Procedures: This involves all the aspects of training and
guidance of operations in the use of the Power Exchange Systems and
business processes associated with their operation.
11.1
PX SYSTEM ROLL-OUT
o Help Desk Procedures. This 11.1.2 PARTICIPANT USER PROCEDURES
involves the establishment and The process for preparing the
operational running of a Help materials and procedures
Desk to assist both the Power necessary to provide user
Exchange Operations and the training and Market Trial
Market participants. procedures are illustrated in
Exhibit 11.1.20-1.
Given the time critical nature of the
PX program, most of the activities in
the procedures will be completed in
parallel so that the time available
for completing each task is optimized
EXHIBIT 11.1.2-1 ROLL-OUT PROGRAM-USER PROCEDURES
[GRAPHIC]
The Roll-out of the user procedures the o Training Plan
following deliverables:
o Training Materials
o User interface prototypes developed
from existing software o Training Manuals
o Test crews trials using prototypes o Training-test crews training
mobilization crews
II-2
PX SYSTEM ROLL-OUT
11.1.3 OPERATION PROCEDURES necessary for the operation of the
hardware and software of the Power
The Operation Procedures produce Exchange (see Exhibit 11.1.3-1)
the processes and procedures
EXHIBIT 11.1.3-1 ROLL-OUT PROGRAM - OPERATIONS PROCEDURES
[GRAPHIC]
The Roll-out of the operations procedures o Plans for pre-operational
will produce the following deliverables: testing - enterprise testing
o Alpha release Roll-out o Operational documentation
o Initial system and procedural testing o Documentation and training
materials
o Test crews, train the trainers
o Operations staff training
o Beta release Roll-out
II-3
PX SYSTEM ROLL-OUT
o Final release Roll-out 11.1.2 HELP DESK ROLL-OUT
The Help Desk Procedures provide
o Final release and market trial the processes and procedures
necessary for the operation of
o Market Trial (Operational the Help Desk for the Power-
Testing) Exchange Exhibit 11.1.4-1 is an
illustration of that process.
o Launch and hand-over to Power
Exchange Operations staff
EXHIBIT 11.1.4-1 ROLL-OUT PROGRAM - HELP DESK PROCEDURES
[GRAPHIC]
Given the extensive commercial The Roll-out of the PX Help Desk will
experience in building and operating be facilitated by leveraging existing
Help Desk for our clients, the PX procedures and practices which
Alliance can reduce the normal Perot Systems successfully developed
provision times to a fraction of the in the design and operation of
expected time. [illegible] Global Network support
services center. Most of the
II-4
P X S Y S T E M R O L L - O U T
existing practices, methods and standards can be adapted to use in the
PX application.
The main steps which the PX Alliance will take in establishing the PX
Help Desk are shown in Exhibit 11.1.4-1.
11.1.5 OPERATIONAL SUPPORT AND MOBILIZATION
Based on the PX Alliance's experience designing and implementing
organizations in response to market change, we suggest that the
organization needed to satisfy the Power Exchange requirements will
change through the lifetime of the Power Exchange requirements will
change through the lifetime at the Power Exchange. These changes
involve three principal phases: design and commissioning, initial
operations, and steady state.
DESIGN AND COMMISSIONING
The Design and Commissioning phase incorporates operational set-up
testing, and PX acceptance.
The PX Alliance will create a multi-disciplinary Roll-out team
comprising industry, process, organizational and technical
specialists. The objective is to create a team which can proactively
manage risk. The PX Alliance recognizes the considerable commercial
and political risk created by the changing environment and will
explicitly develop a plan that mitigates the issue.
The PX Alliance also recognizes the importance of maintaining an audit
trail during the phase and will declare a team to this process. The
implementation of the Program Management Process. The implementation
of the Program Management Process that includes maintaining the audit
trail is explained in Section 10 of the Technical Proposal.
INITIAL OPERATIONS PHASE
The Initial Operation phase will actually begin with the Market Trail
for the PX System. Based on our previous experience implementing
business processes during periods of market liberalization, we
anticipate that this phase will require the most resources in order to
introduce the new processes, procedures and systems.
The PX Alliance is establishing a dedicated team to ensure this
process runs smoothly. This team will be accountable for providing
proactive and practical service support under the strategic leadership
of the management team during the crucial stage.
STEADY SLATE
The Steady Slate phase occurs when the PX System is operational with
few changes occurring. The PX Alliance recognizes that resource
requirements of the operation will eventually reach a steady state
when the number of inquiries, process and systems changes have
stabilized.
11.1.6 SYSTEMS MANAGEMENT
The PX Alliance seeks to combine its own experience with accepted
industry practices to implement appropriate technical standards for
instance, the PX Alliance Systems Management standard is based on the
OSI FCAPS (Fault Configuration Accounting Performance Security) model,
which has been implemented successfully on many client sites.
Typically, the FCAPS model will encompass all the areas shown in
Exhibit 11.1.6-1.
II-5
PX SYSTEM ROLL-OUT
EXHIBIT 11.1.6-1 FAULT CONFIGURATION ACCOUNTING PERFORMANCE SECURITY MODEL
- --------------------------------------------------------------------------------
[CHART]
The PX Alliance will continually evaluate the PX System's management
tools and procedures against the FCAPS model to identify where
improvements can be made and to highlight any areas of operational
risk. Agreed recommendations for changes will then be given to Program
Management for resolution.
11.1.7 SERVICES PROVIDED
The PX System Roll-out will provide the following specific services:
o the day to day management, configuration management and operation
of all of the PX infrastructure.
o Software support for all proprietary system software, application
business systems and unique business configurations.
o Management of and the responsibility for the Disaster Recovery
operations and planning.
11.1.8 DELIVERY RECORD
Most service providers will claim a high level of capability in
delivery and roll-out of large software systems. The fact that blue
chip organizations turn to members of the PX Alliance for their
critical service needs is a testament to our capabilities. These
organizations include four of the largest telecommunications (the
first utility industry open to competition) organizations in the
world, a UK Regional Electricity Com-
11.6
P X S Y S T E M R O L L - O U T
pany, the largest municipal utility and second largest investor Owned
Utility in the US. The PX Alliance's delivery record speaks for itself. We
have provided successful solutions for all these companies.
The PX Alliance can effect the smooth implementation of the PX Systems for
several reasons:
o The PX Alliance is experienced in very large transition exercises,
having most recently accomplished this with the SwissBank Corporation
and described in Section 1 and Section 12 of the Technical Proposal.
o The PX Alliance has extensive experience in a variety of key
industries, with eminently qualified leadership and support staff who
understand the new energy market principles.
o The PX Alliance has considerable experience in the creation of
operational environments "from scratch," including business processes
and operational management.
o The PX Alliance's leadership team is committed to making the Power
Exchange successful.
The PX Alliance emphasizes open, comprehensive, and regular communication
with the Power Exchange, which is especially important in the early stages
of the PX Project.
11.2 CUSTOMER REQUIRED TESTING
The system developed for the PX will go through extensive tests to
evaluate compliance with customer requirements. The PX Alliance's approach
to unit, functional, subsystem and systems integrated testing is outlined
in Section 2.3 of the Technical Proposal.
Every release (Alpha, Beta, Final) of the PX System goes through an
extensive Internal Acceptance Test (IAT) before the release is available
for modification to specific customer requirements. The IAT includes
extensive testing of all documented.
For the PX System, testing will include:
o Incremental and Unit Testing
o Hardware Integration Testing
o Functional and Performance Testing
o Unstructured Testing
o Integrated System Stability Testing
o Operational Dry Run
o System Availability Testing
o Availability Testing
Incremental and unit testing is carried out for each unit specifically
written or modified for the customer.
Hardware Integration Testing demonstrates the installation procedures and
functional operation of the equipment installed in the PX System.
Functional and Performance Testing is conducted according to a set of
approved test procedures to verify that the system will meet the required
functional and performance characteristics. Test plans and procedures are
generated at the end of the Design and Prototyping phase of the
implementation process. These documents provide a detailed description of
the overall plan and the individual test steps that have been reviewed and
approved by the customer. If the PX elects to perform this test at the
development facilities, it is considered a Factory Acceptance Test.
Time for Unstructured Testing will be allocated during the PX System
testing, with up to 25% of the time to be allotted. During this time the
PX representative can do free-form testing.
Integrated System Stability Testing will be done to demonstrate the
functional operation of the PX System for a continuous 96-hour period.
The Operational Dry Run test will be done prior to placing the PX System
into service to ensure a complete and functional PX System.
The Availability Test is a 2000-hour test of continuous operation that
will be conducted as defined in the PX RFP Volume 2 Section 3.8.7.
The following are some of the key items that are tested as part of the PX
System testing.
o Conformance of the hardware to the documentation
o System installation and generation
11.7
P X S y s t e m R o l l - o u t
o Testing of all functions per the approved test procedures
o Failure of redundant equipment
o User interface capabilities
o Simulation of communication
o Demonstration that the spare capacity and expansion requirements
have been met
o Demonstration use of diagnostic and test programs
o Verification of documentation in its use for testing
o Demonstration of the recording and utilization of historical data
11.3 TRAINING AND DOCUMENTATION
11.3.1 OVERVIEW
The delivery of a quality training program is critical to the
successful implementation of the software systems being built to
support the Power Exchange. A preliminary training plan has been
developed based upon the information about the system that is
currently available. It is designed as a working plan and will be
modified and updated as the project progresses and additional system
development milestones are defined.
Our goals for delivering training are as follows:
o Streamline the training process.
o Leverage the use of technology.
o Utilize previously developed documentation for training materials.
o Combine system and business process training into one.
o Use relevant training examples.
o Provide a training environment that is reusable for future training.
o Measure training results to ensure quality training delivery.
o Provide refresher training if necessary.
A significant facet in this training plan is the involvement of the PX
business and operational personnel in the development of training
material and the actual delivery of the training. The plan will
involve each functional area in developing the training to ensure
that:
o Training material can be adjusted to future changes in business
processes.
o Training of new personnel can be accomplished in-house.
o The PX can modify training material and the training program to meet
the needs of future system enhancements.
The training plan takes into consideration the phased development of
the total system. As system components are developed to meet the
functional requirements of each functional area, training will be
provided. As of this time we anticipate providing training for all the
functional areas covered in the Technical Proposal.
The content and scheduling of specific training will be developed
during the Project Plan.
This plan focuses on the delivery of training on business processes
and the computerized tools which support those processes. However,
every system turnover should also include technical training for the
customer, which involves reviewing system documentation and the
technological intricacies of maintaining the system. For this reason
we have included a module of training called Technological Training,
the scope of which will be determined as the system development
evolves. The general areas that should be considered are:
o Technical Training - Software Maintenance
o Presentation
o Application Logic - Client/server
o Data - Databases and interfaces
o Operational Training
o Security Administration
o Server Operations
o Client and Server Back-up/Recovery
o Database Recovery
o Help Desk Training - Level 1 Support
118
PX SYSTEM ROLL-OUT
Some training tasks may be repeated for each of the functional areas,
some tasks may be deleted as unnecessary, and additional tasks may be
added to ensure that the PX receives the best system training
possible.
11.3.2 APPROACH
Training will be centered on how to use the system to support the
functional processes. Training modules will be provided for each
functional area and will integrate business processes with system
functionality. Training data will reflect actual information that is
handled by each functional area.
ASSUMPTIONS
The best training results for the Power Exchange will be assured by
adhering to the following assumptions:
o The PX Management will review and approve/disapprove deliverables
according to the schedule that is agreed upon in the Detailed
Training Plan.
o A process will be established that maintains configuration
management procedures and ensures correct version control and
migration of all software changes from the Development
environment into the Training environment.
o The PX will provide all necessary facilities and equipment to
deliver the training on the schedule as defined in the detailed
training plan.
TRAINING TASKS
The development of a successful training program depends on the
development and implementation of a thorough training plan. The
proposed PX Alliance training plan takes into consideration the
review/familiarization of the Training Team with the functional
processes and system design features of this Project. It recognizes
the dynamic schedule which exists in the final development phase of
the project and attempts to coordinate training activities within that
schedule.
Implementation dates will be assigned to each task as the Training
Plan and the Documentation Plan are coordinated with the overall
Implementation Plan.
It is assumed that the deliverables will be subject to review and
approval. The final schedule developed in the Detailed Training Plan
will define when these deliverables can be expected and when the
deliverables need to be reviewed and approved. The schedule itself is
a deliverable which will be subject to management review and approval.
Deliverables as defined in this section are those expected outputs or
results of the group of tasks. Deliverables will include formal
documents for Management review and approval, working papers, revised
working documents, reference libraries, and other elements that
constitute the evolutionary development of training materials.
11.3.3 TASK 1: SYSTEM REVIEW
The following tasks involve the review of all materials generated as a
result of the analysis, design and implementation planning phases of
the project. These steps will be repeated for each set of materials
developed. The actual delivery of training will be coordinated closely
with the implementation and Roll-out.
DELIVERABLES:
- --------------------------------------------------------------------------------
o Reference library of system documentation
o Preliminary outline of Detailed Training Plan
PROCESSES
The Training Team reviews all Process Descriptions developed for the
PX systems.
FUNCTIONS
The system functions will be defined in Process Scripts, which are
generated as a result of analyzing the Process Descriptions and
defining the physical system implementation necessary to support the
business processes.
INTERFACES
The PX System will interface to ISO and various users. The critical
points of interface are where data is exchanged. It is important to
know what system interfaces exist in order to develop the training.
11.9
PX SYSTEM ROLL-OUT
11.3.4 TASK 2. DEFINE TRAINING SCOPE
These tasks are designed to define the breadth and scope of the
training to be delivered in order to determine the resources in
personnel and time that will be necessary to deliver the training.
DELIVERABLES:
o Training plan (revised)
o Coordinated schedules with Documentation Plan, Testing Plan, and
Implementation Plan
o Recommended training delivery methods
DEFINE AUDIENCE
Define who will receive what training identify the User Acceptance
Testing group, Trainers, System Operators, System Maintenance Team, and
Users who will receive training.
DEFINE TRAINING SUBJECT MATTER
Define the type of training that will be necessary for each business
area, the operational training requirements and the system maintenance
training requirements. Identify potential cases to use for training.
DETERMINE TIMING/IMPACT TO SCHEDULE (DOCUMENTATION TESTING)
Coordinated training requirements with documentation, testing and date
readiness plans. Integrate training schedule into the overall
Implementation Plan.
DETERMINE TRAINING DELIVERY METHODS
Based upon the types of training to be delivered and the audience to be
trained, recommend the most effective method for delivering the
training. This may include several methods.
11.3.5 TASK 3: DEVELOP DETAILED TRAINING PLAN
These tasks are designed to build the initial draft of a Detailed
Training Plan. This plan will contain more specific information than is
contained in the initial plan. It will outline specific training
criteria, audience, training environment requirements, plan for
developing and testing training materials, and detailed schedules for
task completion. These tasks will be coordinated with dependent tasks
in the Documentation Plan, Testing Plan, and Implementation Plan.
DELIVERABLES:
o Draft of the detailed training plan
o Requirements for the training date environment
o Training success measurements
o Training delivery plan
FINALIZE TRAINING ORIENTATION/PURPOSE
Finalize training goals for each functional area. Finalizes the
training audiences. Define training success measurement criteria.
IDENTIFY THE REQUIRED ENVIRONMENT
Refine information gathered in previous tasks and formally outline the
interface data requirements and any simulations that may be necessary,
the specific processes, and the facilities required to deliver
training.
DEVELOP TRAINING MATERIALS PLAN
Determined by training module the types of training materials that will
be necessary. Identify what manuals will be necessary and who is
responsible for their development,what kinds of handouts will be given
to the users, and what data sets will be needed.
11.10
PX SYSTEM ROLL-OUT
DEVELOP TRAINING DELIVERY PLAN
Develop a training delivery plan for User review and approval which
will contain tasks and responsibilities as well as a schedule for
delivering the training. Some of the milestones of this plan are:
o Finalize training audience
o Develop and publish training schedule
o Arrange/verify facilities
o Execute the training
DEVELOP TRAINING EVALUATION/FOLLOW-UP PLAN
Define a plan for evaluating the training according to the success
measurement criteria and for correcting any deficiencies in training
that may be discovered.
11.3.6 TASK 4: DEFINE TRAINING ENVIRONMENT
The training environment is more than the hardware and software
necessary to execute the system. This task defines the myriad of
details necessary to ensure the training environment is stable and
reusable, and is included in the system configuration management plan.
DELIVERABLES:
o Training platform requirement
o Training data requirements
o Training software environment requirements
TRAINING SOFTWARE CONFIGURATION/ENVIRONMENT
Define the Client and Server software environments necessary for
testing. Define the needs for the training environment relative to
configuration management since system changes will be ongoing.
TRAINING DATA ENVIRONMENT
Specify the location and content of the data environment necessary to
support the business cases. Define contents of the document management
database necessary for training. Define the interlace data sets
required.
TRAINING FACILITIES
Define specific facilities and equipment and a schedule when they must
be available for training delivery. Some of the facilities include but
are not limited to: communications connections; training rooms,
overhead projectors; Training partitions on the system servers; PCs
(with necessary client software suite loaded); printers, scanners,
and more.
11.3.7 TASK 5: IMPLEMENT TRAINING PLAN
These task are the actual implementation of all of the plans that have
been developed to this point.
DELIVERABLES:
o Final training materials and training data sets
o Established and Renewable Training Environment
DEVELOP/TEST TRAINING MATERIALS
Finalize and publish/load all materials necessary for each training
module. Includes business case materials and data, handouts, manuals
and user guides.
ESTABLISH TRAINING ENVIRONMENT
Ensure all facilities are in place for training delivery. Includes
establishment of the hardware/software training environment that is
renewable and subject to configuration management controls.
IMPLEMENT TRAINING DELIVERY PLAN
Follow steps of the Training Delivery Plan. Train the trainers. Train
the users. Train the system support personnel. Train the operations and
help desk personnel.
11.11
[GRAPHIC OF MAP]
PX System Roll-out
11.3.8 Task 6: Post-Training Review
Conducts the steps defined in the Training Evaluation/Follow-up Plan.
Derivatives
- --------------------------------------------------------------------------------
-- Post-training evaluations
-- Follow-up training (if necessary)
EXHIBIT 11.3-1 TRAINING PROCESS
- --------------------------------------------------------------------------------
[CHART]
11.12
[GRAPHIC]
12. PX OPERATION
POWER EXCHANGE OPERATIONS
12.0 POWER EXCHANGE OPERATIONS
POST IMPLEMENTATION - OPERATION OF THE PX AS PART OF THE CREATIVE
CONTRACT
12.1 INTRODUCTION
The RFP and the Alliance proposal response deal with the procurement
and roll out of systems and infrastructure to support the operation of
California's Power Exchange. They do not address the subsequent
operation and first-line support of those systems and business
operations. Perot Systems, the PX Alliance Program Manger, offers to
operate the business systems for PX management, an option which the PX
Alliance heartily endorses. This section provides the details of this
option.
Because of the complex and evolutionary nature of the PX systems
requirements, significant benefit could be realized by selecting the
alliance which has developed and implemented the PX systems to operate
and maintain them as will. In particular, this will provide a single
point of responsibility for the provision, implementation, operation
and support of all complex applications required to run the PX. The
continuity inherent is such an arrangement mitigates the risk and
expense arising from the transition to a separate operating group.
Furthermore, the expertise required to promptly address the continuing
evolution of the market dynamics and PX structure will already be in
place and up to speed. There will be no learning curve.
The complexities of dealing with multiple entities assigned various
responsibilities for different pieces of the complete business solution
could be avoided by putting all elements under a single contractual
arrangement with the PX Alliance. This approach provides a managed,
smooth transition toward market deregulation and seamlessly
incorporates required upgrades as the Power Exchange evolves with the
new millennium.
Training and implementation are integral to the successful operation of
the Power Exchange; our Alliance's commitment to these areas has been
highlighted in Sections 2 and 11 of the Technical Proposal. We are
convinced that you needs will best be served by expanding Perot
Systems' involvement in the Power Exchange to extend from development
and implementation through training and operations. Based upon our
experience in similar markets around the world, we propose three
alternatives for the scope of this partnership. In each case, Perot
Systems' skill base and involvement in the systems implementation will
uniquely position us to provide a broad range of value added services.
o BASIC SUPPORT - We will operate the PX computer systems as
well as provide an in-house Help Desk for the PX staff. This
integrated support facility would respond to all queries on
systems usage and performance, and supporting technology. The
initial infrastructure will be delivered as described in
Appendix D.
o INTERMEDIATE SUPPORT - We will operate the PX computer systems
and expand the Help Desk support to provide a single point of
contact for market participants and the PX staff on all
matters, answering questions and resolving business issues,
such as bid verification, credit monitoring and resources
scheduling, and solving technology problems.
o FULL PX AND MARKET RELATED OPERATIONS - We will provide the
support services outlined in the first two options, and
assemble service and industry teams to assume responsibility
for all business and technology functions of the PX operation
under the management team selected by PX.
Clearly, the full PX and market related operations option affords the
PX and its customers the most streamlined approach to an exceptionally
robust solution:
o It will enable a smooth evolution from systems implementation
through systems operation.
o It will shift more of the risk for validating business
processes and protocols to Perot Systems, who will have even
more incentive to assure a smooth transition from development
through operations.
o It will ease the burden on PX senior management at a time of
fast and continuous change.
12.1
P o w e r E x c h a n g e O p e r a t i o n s
o it will ensure the delivery of a high quality, professional and
commercial energy trading services bureau staffed with experienced,
knowledgeable industry and technology talents.
o it could assist with the FERC approval of the PX filing due to the
independence of Perot Systems from all existing market participants in
California.
These options are not exclusive, they can be mixed and matched depending on
the final business definition of the PX and the extent to which PX
management elects to engage our services.(1)
12.2 PX BUSINESS OPERATIONS
Six fundamental processes define the PX business operation as specified in
the Functional Document: Bidding, Scheduling and Pricing, Publishing,
Settlement, Billing and Credit, and Administration. Implementing and
operating these processes successfully demands a highly skilled staff with
extensive experience in a variety of disciplines, ranging from market and
systems operations to engineering, accounting and law. Perot Systems, the
rapidly growing company of 4,000 associates and one of the world's most
innovative technology companies, has exactly the right mix of experience,
skills, and tenacity.
Underlying these business processes are four operations:
o Trading Operations
o Post Trading Operations
o Support Services
o IT Operations
EXHIBIT 12.2-1 BUSINESS OPERATIONS MODEL
[GRAPHIC]
12.2.1 TRADING OPERATIONS
Trading operations include bidding, scheduling and pricing. While these
functions can (and should) be separated for systems purposes, operationally
they will comprise a single service entity and should be administered and
managed as an integrated process.
The main functions of the bidding process are to:
o Receive energy, demand, ancillary services and incremental and
decremental price bids from the PX market participants.
o Convert faxed bids into electronic data.
o Verify syntax and protocols of bids.
o Interact with the PX participants to correct their bids for syntax and
protocol errors in the day-ahead market or simply reject erroneous
bids in the hour-ahead market.
o Submit finalized bid data to the bid evaluation process.
o Provide support to audit and dispute resolution processes, as needed.
PX staff involved with the bidding function will be required to monitor and
operate the automated bidding system and oversee the conversion of faxed
bids into electronic forms, provide back up verification procedures, and
provide sup-
- ----------
(1) We are aware of the PX Trustee's intentions to start staffing for PX
operation starting in February of 1997. The level of staffing has not been
resolved yet. We are prepared to modify our PX operation proposal presented
in this section to accommodate any level of staffing that the PX intends to
put in place. Accordingly, beyond the operational data of 1/1/98, we would
either integrate the PX staff assigned by the Trustee into our proposed
operation or simply provide operational services (business or IT) wherever
there are deficiencies in the PX operational infrastructure.
12.2
P o w e r E x c h a n g e O p e r a t i o n s
port for the dispute resolution process. Dependent upon the final form
elected for the bidding process, significant requirements for research
of disputes and resolution actions may be required to address
questions arising between PX and ISO interactions.
The main functions of the scheduling and pricing process are to:
o Take receipt of bids.
o Match supply and demand based on final PX scheduling protocols
and develop interim hourly energy (and potentially operating
reserves) schedules and determine interim hourly market clearing
prices.
o Iterate with the PX market participants on interim hourly
schedules and indicative prices.
o Develop the initial preferred schedules and submit these along
with incremental and decremental energy prices and additional
ancillary services to the ISO.(2)
o Receive the advisory redispatch from the ISO.
o Determine the revised preferred schedules based on the ISO's
advisory redispatch.
o Submit the revised preferred schedules to the ISO for its
consideration.
o Receive committed schedules from the ISO.
o Calculate the final clearing prices based on the committed
schedule (and the ISO's zonal congestion prices, if any).
o Communicate final schedules and market clearing prices to the PX
participants.
o Provide support to audit and dispute resolution processes as
needed.
With the exception of the audit and dispute resolution processes, most
aspects of scheduling and pricing operations will be fully automated.
However, periodic evaluation of these processes may require
significant efforts by assigned personnel. In addition to the
operators and modelers, the function requires a range of technical,
economics and business analysts to deal with day to day queries.
The processes across trading operations will be very similar for both
the day-ahead and hour-ahead markets, except that for the hour-ahead
market no iteration between the PX, the PX participants and the ISO
will be allowed. In the day-ahead market the focus will be on the
iterative bid submission and evaluation processes that comprise the
daily auction. Trading activity is expected to peak just before the
day-ahead market closes.
The hour-ahead market will deal with a similarly large number of bids
(albeit of slightly less complexity) that will need to be handled
within the hour as a rolling process. Deployment of assets and
resources might need to be flexed to accommodate greater volumes of
bids through peak morning and evening system conditions. A flat daily
profile is assumed for the remainder of the 24-hour period.
Operation of the bidding module is likely to require one pricing
operator and one analyst at all times.
As the market becomes more predictable and trading becomes more
routine, participant behavior will likely become more consistent
through reliance on standing bids.
12.2.2 POST TRADING OPERATIONS
The settlement process commences with the entry of committed supply
schedules and prices for the day-ahead market. Initial clearance of
the hour-ahead market is a separate process and commences with each
entry of committed supply schedules and prices immediately prior to
its respective trading period. Real-time deviations for
loss/replacement energy, ancillary service deviations, and intra-zonal
congestion are dealt with after the event based on real-time data
provided by the ISO and the metering agent. Transactions can then
balance for the appropriate settlement day. Periodic settlements
(probably monthly) will include the ISO's transmission service access
charges, intra-zonal congestion charges, and the PX's administrative
fees.(3)
PX market participants are likely to be billed for a defined
settlement period, probably monthly. The PX Alliance billing
- ---------------
(2) Depending on the PX operating protocol the preferred ancillary services
schedule may be developed simultaneous or subsequent to development of the
energy schedule.
(3) Not all costs related to the ISO have been fully specified.
123
P o w e r E x c h a n g e O p e r a t i o n s
system offers maximum flexibility to accommodate different settlement
periods for individual market participants, which may be a function of the
dispute resolution process, and the level of credit cover requested. For
these reasons, it is assumed that the PX will handle settlement, billing
and credit as a single service activity, which we term Clearing and
Settlement.
The main tasks carried out by the Clearing and Settlement Activity are to:
o Determine ex-post market clearing prices based on real time, operating
results received from the ISO and metering agent(s)(if separate from
the ISO).
o Determine debits and credits due to the PX participants.
o Monitor the credit position of the participants and police the PX's
prudential requirements.
o Run all aspects of PX cash management.
o Generate bills and checks for the PX participants.
o Support the audit and dispute resolution process.
With the exception of the audit and dispute resolution process, Clearing
and Settlement will be essentially automated. The staff will be required to
monitor and operate the automated settlement and billing system and provide
support to the audit and dispute resolution processes. The credit and
traded positions of PX market participants will be closely monitored.
The clearing and Settlement system will require a range of trained
operators, complemented by business and financial analysis who can relate
bills to trading operations.
12.2.3 SUPPORT SERVICES
The PX requires a range of non-discretionary administrative and specialist
support services to operate the other care functions.
o CORPORATE FUNCTIONS - finance and administration, human resource, PR
and communications, and legal.
o SPECIALIST SERVICES - specialist analysis and IT analysis, separate
from the support services provided as part of the IT operation.
o MARKET MANAGEMENT - dispute resolution, market information, rule
compliance and auditing, and contract supervision.
Support services resourcing will depend on the development of detailed
rules, the behavior of marked participants, and the number and frequency of
disputes.
12.2.4 IT OPERATIONS
Five fundamental processes define the IT operations as specified in the
Functional Requirements Document:
o The Help Desk
o Service and Account Management
o Computer System Support
o Computer System Operation
o Resource Management
THE HELP DESK
- --------------------------------------------------------------------------------
The Help Desk is integral to customer satisfaction, the single point of
contact for the market participant who has a question, issue or problem,
and wants immediate resolution 23 hours a day, seven days a week. It is key
to a smoothly run, widely accepted, successful Power Exchange.
Our Help Desk strives for "first time call fixing," a one-stop shop
providing immediate and satisfactory resolution of all problems at any
time. Our Help Desk will be staffed by talented specialists in various
disciplines. Our PX business operations staff will also be available when
needed.
COMMUNICATIONS. PX market participants will represent a range of energy and
commercial companies from the sophisticated to the most basic. They will
expect equally sophisticated support from the Power Exchange available
throughout the spectrum of communications media. Our Help Desk will be
accessible via telephone calls, letters and facsimiles, electronic mail,
and internet. Whatever the medium, the response must be intelligent, timely
and constructive. Our Help Desk will be staffed with employees who are not
just call logging operators, but are conversant.
124
POWER EXCHANGE OPERATIONS
with the Power Exchange's business systems and operations. We commit to
answering at least 80% of the questions at the first point of contact.
MANAGING THE RESPONSE. The help Desk must be responsive to all the PX market
participants on a wide range of matters and must be measured, monitored and
managed to ensure continuous improvement. Based on Perot Systems' extensive
experience in the operation of help desks, we propose to use our REMEDY system
to log all calls whether business or system related and track the resultant
actions and responses. Such a system offers several advantages.
o It allows the call patterns to be analyzed and operator training targeted
to improve the percentage of calls resolved at the first point of contact.
o It identifies recurring systems or hardware problems, enabling proactive,
preventive maintenance.
o It builds a knowledge database of problems and answers to Help Desk
personnel , PX employees, and market participants to enable them to resolve
recurring problems more quickly and effectively. It also provides relevant
real-world information for continued training.
o It alerts the operations and management staff when an issue has not been
resolved within a prescribed time limit, regardless of whether
responsibility for resolution rests with the Help Desk, a supporting
technology function or a third party.
o It ties directly into the problem management systems of the major hardware
and software vendors to promote rapid and effective resolution of virtually
and problem.
SECURITY AND RESILIENCE. the PX Alliance's proposal provides for an independent
backup facility to support the business functions and technical operations of
the Power Exchange. We recommend provision for a similar backup for the Help
Desk in the event of a disaster affecting the primary operating site. We propose
operating the Help Desk at both the primary and backup sites, with a shared
database and ability to switch calls between the sites. While Perot Systems
corporate facilities in Dallas would be available to provide similar support in
the short term, we recommend a backup facility dedicated to the unique
challenges of the California market and the Power Exchange.
PLANNING AND RESORCING. The number of staff required to operate the Help Desk
and their qualification will be predicated on the number of queries, the average
resolution time, and the method of communication. Based on our global experience
in similar operation, we expect approximately 50 queries per market participant
per year and approximately ten queries per system user per year. The volume
will undoubtedly be larger during the initial days of the Power Exchange
operations and will likely spike following major system or business changes.
SERVICE AND ACCOUNT MANAGEMENT
SERVICE LEVEL MANAGEMENT. Perot Systems' proven customer care methodology is
continuous process improvement through iterative customer-focused analysis and
training and systems support. We will work closely with the Power Exchange to
establish the procedures and define the performance metrics in our Service
Level Agreements (SLA). Our SLAs will be backed up by similar agreements with
supporting vendors to ensure prompt and satisfactory resolution of all
problems,.
CHANGE MANAGEMENT. Change is a daily occurrence in an evolutionary business
like the Power Exchange. Because of Perot Systems' proven change management
methodology, we can smoothly incorporate these process improvements without
interruption. Our experience change management team:
o Understands all changes proposed.
o Investigates and manages any inter-dependencies.
o Ensures effective testing.
o Minimizes the risk of disruption.
o Keeps the Help Desk current.
ACCOUNT MANAGEMENT. Perot Systems' proven account management methodology is
based on a philosophy of partnership and our core commitment to continually
improve our service and the processes and operations we support. We will
regularly monitor all services we deliver for potential improvement to ensure a
world-class, showcase Power Exchange in the State of California.
125
POWER EXCHANGE OPERATIONS
COMPUTER SYSTEM SUPPORT
TRAINING. The initial PX business systems training is discussed in
Section 11. Continuing training for market participants and PX
employees will parallel the market expansion. Using our highly
qualified, system experienced personnel to lead this training has
several advantages.
o Attendees have direct access to systems expertise.
o PX participants and employees meet first hand the people
responsible for solving any application problem.
o The system support personnel remain in direct contact with the
business users, improving the quality of their support and
communications with the customers.
OPERATIONAL ACCEPTANCE TESTING. New elements are introduced into the
operational infrastructure only after ensuring that they operate fully
and correctly to produce accurate results; do not interfere with other
components; and are thoroughly understood by the people responsible for
their operation. We recommend a series of structured tests to evaluate
each new component or software modification to thoroughly assess its
impact. While these tests would be planned, managed and coordinated by
Systems Support personnel, they would be conducted by actual operations
personnel.
COMPUTER SYSTEMS OPERATIONS
System operation of the computer systems will:
o Monitor all system functions including batch operations for
early indications of potential problems, and initiation of
appropriate corrective action.
o Balance available resources to achieve consistent performance.
o Restore applications and facilities after component,
communication, power or software failures within agreed
targets.
o Provide technical assistance to resolve problems with
availability and use, including liaison with suppliers.
o Manage the configuration of the installed base of supported
applications, facilities and services to ensure reliable
system operation through periods of change.
o Provide the database and system software expertise to keep the
Systems running efficiently.
o Administer the security and other specialist functions
required in the day to day operation of the systems.
RESOURCE MANAGEMENT
The resource management process:
o Monitors trends to predict future capacity problems and
initiate the suitable acquisition or other avoidance actions.
o Manages capacity, reserves and resilience to achieve agreed
targets of utilization and availability
o Provides and tests business resumption plans to cope with
disaster situations.
o Investigates and plans new versions of hardware, operating
system and other base software (such as database management
systems).
12.3 HUMAN RESOURCE REQUIREMENTS
Perot Systems has extensive experience in designing and implementing
organizations in response to market change, especially that of the
deregulating power industry. Specifically, Perot Systems Energy Group
created and managed an IT organization for a regional electricity
company in the UK which addressed industry wide issues that emerged
immediately following the privatization and deregulation of the power
markets. Based on our experience, we expect the overall resource
requirements for the PX to level out in the range 60 to 75 personnel as
the business activity approaches steady stale. It would not be prudent
to detail precise manpower numbers and budgets or their split between
the PX functions until full systems definition has been agreed,
business procedures have been finalized and PX interfaces with the ISO
and participants have been clearly defined.
In the preceding section, we identified a range of services which the
PX might be expected to subcontract and some
12.6
Power Exchange Operations
which might add significant value to its core functions, it is difficult
to estimate the costs of these services without a better grasp of the
volume of transactions and the number of participant interfaces with the
PX. There is further potential to benefit from economies of scale by
providing joint support services with the ISO in areas such as billing
and settlement.
Despite these uncertainties, there is a significant number of operational
roles where the expertise of the PX Alliance members and provides obvious
synergy and efficiency through their consistent involvement from design
and development to implementation and operations.
12.4 WHY PEROT SYSTEMS?
Perot Systems has a proven track record and delivery capability in the
field of help desks and technical system operations. A Center of
Excellence has been established within the Corporation to ensure that
Perot Systems remains at the forefront of innovative technologies,
emerging trends and best practices in this field. We would be happy to
discuss additional references, over and beyond those presented in this
proposal. These relationships attest to our capability to implement
quickly, meet service level agreements, perform to business metrics,
adapt to change and integrate technologies.
A key differentiator of Perot Systems is our capability to address the
essential organizational and people issues required for the provision of
a continuous, high-quality service. The quality of service is directly
related to the quality of its people. Comprehensive programs and
extensive experience demonstrate our corporate culture. Our satisfied
clients attest to our ability to deliver.
EUROPCAR
The relationship involved the outsourcing of all EuropCar IT systems
representing 55 different systems environments. The project details are:
o A 10 year agreement starting in 1992
o PSC designed and developed the world's largest implementation of a
relational data base application on an open systems client server
and network ("GreenWay") in 13 months.
o The system required a complete redesign and replacement of all the
existing EuropCar operational support systems from the front office
Sales & Marketing, Reservations and Rental Operations desks through
to the Back Office fleet management and financial systems.
o The system is able to handle 4,000 concurrent users, plus another
80,000+ "virtual" connections through various Global
Distribution/Customer Reservation Systems (GDS/CRS).
o PSC deployed the new "GreenWay" system in 9 corporate offices, 18
reservation offices, and 800 rental operations stations in 9
countries in a record 30 month time frame.
o Greatly enhanced functionality and customer information at
substantial savings over previous systems.
The company decided to replace its outmoded systems with a single, open
system named "GreenWay." PSC was selected to conceive, design, develop,
install, and operate the new system. It was developed as a client/server
system, built using an Oracle relational database and a Sequent UNIX
server.
SWISS BANK CORPORATION
In September 1995, Swiss Bank Corporation (SBC) and Perot Systems formed
an Information Technology (IT) strategic alliance. In an independent
review the Wall street Journal announced this partnership as the future
model for strategic outsourcing relationships. The partnership is based
on these components:
o Perot Systems will assume the management of the IT infrastructure of
SBC Warburg, excluding hardware and proprietary software applications
development.
o Under the guidance of SBC, Perot Systems will assume project
management of an existing corporate-wide initiative to upgrade and
standardize SBC's IT infrastructure on common systems and platforms.
o Perot Systems will take an equity stake in SBC's Switzerland-based IT
subsidiary, SYSTOR, to further
12.7
Power Exchange Operations
expand business activities and assure mutual access to technology expertise
and marketing capabilities.
This alliance is part of SBC's effort to focus IT organization into a
customer-driven core competency with economies of scale, including a number of
projects a define a standard corporate-wide service architecture, consolidate
production world-wide and continuously upgrade front-end business applications.
Approximately 700 IT professionals from SBC Warburg in Chicago, NY, London,
Frankfurt, Paris, Zurich, Hong Kong, Singapore and Tokyo joined Perot Systems in
January 1996 to form Perot Systems Global Financial Services, dedicated to
providing state-of-the-art systems and network services to SBC and other clients
throughout the global financial services industry.
SBC has a global user population of about 20,000 split by 11,000 for the
international banking arm (SBC Warburg) and about 9,000 for Domestic Division.
PSC is currently providing all support services to SBC and SBCW users everywhere
except in Australia and New Zealand. SBC and SBCW currently operate a large
heterogeneous network including both Token Ring (in Domestic) and Ethernet
topologies. The clients use a mixture of UNIX, Next and Windows 3.11 and Win 95)
operating system.
DEUTSCHE TELEKOM
PSC is finalizing the establishment of a customer service center for the German
telecommunications utility which will eventually support approximately 180,000
internal end users.
PSC also provided project management and technical skills for installation and
roll out of 100,000 networked PC's. We have been involved fully in the
conceptual development and design of the LAN, WAN, and Support infrastructure.
This includes the establishment of an internal Customer Service Center.
NATIONSBANK
At the time, one of the largest outsourcing contracts in the banking
industry now exceeded by PSC's 1995 alliance with Swiss Bank Corporation PSC
manager NationsBank's It processing services Project details are:
o Ten year contract signed in October 1991, contract modified in 1995 to
provide Technical, Operational, Management, Project and Consulting services
to client.
o Provided the technological and operational support to facilitate rapid
growth in line with NationsBank's aggressive acquisitions of other large
banks.
o Built a new data center (162 days from ground breaking to occupancy), then
migrated the bank's original three data centers into the new facility,
saving $20 million per year in operating costs.
o Data center migration enabled the bank's 2,600 + locations to access
information through one central source, with one integrated Customer
Service facility.
o Over 20 PSC associates are providing Management and Consulting expertise to
develop a 21st Century "Ideal Environment" for the Command and Control of
all Mainframe, Network and Distributed Systems throughout the NationsBank
enterprise.
NationsBank is the fourth largest bank (ranked by assets) in the United States,
and the hardware resources managed by PSC in support of NationsBank include:
o 2,024 large-scale mainframe MIPS on four large
o 8.0 terabytes of online storage
o 100,000 end-user devices
o 14 tape silos
o 310,000 tapes
12.8
P O W E R E X C H A N G E O P E R A T I O N S
TENET HEALTHCARE CORPORATION
- ---------------------------------------------------------------------
Tenet Healthcare Corporation, now the second largest investor-owned
hospital chain, operates 76 acute care hospitals and related
healthcare businesses in the United States, generating revenues in
excess of $5 billion. Under this contract the largest outsourcing deal
in the hospital industry, PSC provides the following service
functions:
- - Management of data center operations
- - Application development and support
- - Network services
- - In-hospital consulting
The seven year contract provides Tenet with $12.6 million in annual IT
savings (envisaged to realize approximately $100 million in savings
over the course of the contract), an enhanced IT environment and
increased financial flexibility.
12.9