EXHIBIT 99.414
[SCE LOGO]
DOCUMENTATION
AUTHOR: Pamela Arora 10/09/97 03:53 PM
CATEGORY: Project Management
SUB CATEGORY 1: WES
SUB CATEGORY 2:
SUB CATEGORY 3:
SUBJECT: Overview Documentation - Workflow
[ATTACHMENT]
BODY: Workflow document from Russ
WHOLE SALE ENERGY SYSTEM
TECHNICAL DESIGN REQUIREMENTS
Author: Russell Lauour
Table of Contents
<Table>
Purpose: .................................................................... 3
General Comments: ........................................................... 4
Introduction: Business ...................................................... 5
Introduction: Technical ..................................................... 7
Document Management: ....................................................... 8
Workflow: .................................................................. 9
Operations: ............................................................ 11
Payments: .............................................................. 11
Compliance: ............................................................ 11
Workflow System Requirements: .......................................... 13
</Table>
PURPOSE:
This document provides a rough overview of some of the design requirements
placed on the system design team when the developing what is now known as the
VIES system.
The document attempts to provide a brief business overview of the primary
business benefactors of the system. It also attempts to provide some insight
into why technical solutions have been proposed and implemented.
GENERAL COMMENTS:
One of the overriding constraints has always to keep the customer happy, to
exceed their expectations. This was all done with a view to gaining more
business. As such direct adherence to the contract wording has not been
followed. The contracts lack of definition also ensured its use as a scope
management document was flawed. The customers expectations have never been
managed. To do so would have potentially upset future deals.
Another point to note is that the strategic importance of this system to our
customer must be in question. We're a year late and Edisons is not screaming
down our throats for its money back. Pan of the business benefit for this system
was a reduction in staffing in QE Resources. Edison went through a retirement
review last year which saw a reduction in QFR staff of around 15 people. More
than VIES was to achieve. QFR seems to be surviving with these cuts and without
WES. This lack or urgency or commitment to WES from the customers perspective
has also hindered development.
Given the number of sales opportunities realized from our presence here and the
fact we're a year late and n Million overspent. Some may consider the previous
paragraph's comments as redundant, or depending on how many shares you've got in
the company maybe repugnant is more appropriate. However, things are as they
are. Time is like scope it cannot be changed or constrained.
If the company wants to ensure the minimum costs possible on this account it
must be willing to manage the expectations of the customer. It must be willing
to set, define and adhere to some scope. It must enforce signoff and closure on
analysis, design and implementation. Even if this means upsetting the customer.
If these things aren't done then this project will take as long as it takes. The
project will continue to manage itself as it has done for the last two years.
We'll finish when the project wants us to finish not before.
INTRODUCTION: BUSINESS
The wholesale energy system provide a business solution to departments within
Southern California Edison who deal with the management of contracts related to
bulk purchase and sale or electricity.
The primary business sponsor for the system is the Qualified Facilities
Resources group (QFR). The groups function is to manage contracts with around
400 "green energy" generators (QF's). Technologies used by these QF's are
"wind", "Solar", "Hydro", "geothermal" etc.
Mound 20 years ago Edison was obliged to sign contracts with individuals and
companies who could generate electricity using non-fossil fuel sources. These
contracts where long term 20-25 years.
At the time Edison signed these contracts the price at which Edison would pay
these QF's was based on the price of oil ($100 a barrel in 1970). However, over
the years the price of oil has dropped. This makes the price at which Edison
pays these QF's very high compared to other sources of electricity.
Edison pays out around 2.4 Billion dollars a year to these QE's. Of the 400
contracts 90 receive 2 billion dollars.
Edison re-coups the 2.4 Billion dollars from their "Retail" customers. However,
Edison can only reclaim this money if each year it can prove that it has treated
all QF's fairly. If for any reason the Californian Public Utilities Commission
(CPUC) feels Edison has been biased, then it may disallow a portion of the 2.4
Billion. This means the disallowed costs are borne by the Share Holders of the
company in reduced profits.
Each year QFR produces a report known as the Energy Cost Adjustment Clause
(ECAC). This reports documents management statistics on the number, type and
outcome of specific business transactions which take place between the QE's and
Edison. For instance it will specify the number of QF's requiring Insurance
during the reporting period, the number that passed Insurance review, the number
that failed etc. CPUC will use this document to validate that Edison has been
fair and impartial in its dealings with the QF's.
As stated earlier the contracts that Edison signed do not provide the cheapest
source of available energy. Edison can attempt to reduce its liability to pay
these QF by two means.
1) Buy the QF out
Edison pays the QF a lump sum to compensate the QF for the
expected life of the contract,
2) Derate or Decertify the QF because of no-compliance to the
contract rules. For example the QF may fail to generate during
peak periods. Such infringements can he punished by lowering the
payments to the QF or seeking the contracts termination.
Within QF Resources the business processes have been broken down into four main
areas:
CONTRACT MANAGEMENT:
Negotiations and Buyouts, derations and decertifications. Contract
interpretations etc.
COMPLIANCE:
Periodic review of contract clauses.
OPERATIONS:
Review a QF's requirement to be paid even when not generating.
Contracts with the QF's allow them to be off-line for maintenance and
still be paid a portion of their normal monthly payment. This groups
analyses the outage requests against the contractual and operational
requirements of the QF.
PAYMENTS:
Process within this area calculate and distribute the payments to the
400 QF's. QFR does not itself produce vouchers for the QF's. This is
done by Edisons "Accounts Payable" department. Strict audit rules
apply to the payment production. Given the dollar values involved this
is understandable.
NOTE: THE DEFINITION OF THESE FOUR AREAS WAS AN OUTCOME OF THE ANALYSIS PROCESS.
QF RESOURCES ITSELF IS NOT STRUCTURED IN EXACTLY THIS WAY.
INTRODUCTION: TECHNICAL
From the analysis that has been performed over the last year and a half, two
supporting technologies where suggested to help provide business benefit to the
customer.
1) Document Management
2) Workflow
Note: Contractually Perot was confined to developing on only approved Edison
environments. This meant IBM Unix (AIX), Sybase Database servers. Client
development was restricted to Microsoft development tools, Visual Basic and C++.
Windows NT was not a strategic platform when we signed the contract As such
Windows NT components could not be incorporated into the system design. This
ruled out some document management packages and Workflow tools.
The target user base for the VIES system is around 100 users, in 4 - 5
departments.
Most of the following comments relate to QF Resources. The Billing portion of
WES has been implemented and signed off. Document Management has been provided
to the billing groups. There implementation is based on the VIES overall
document management solution. Workflow components are not targeted for the VIES
billing groups.
The general design for WES was to provide a system which was "one stop shop" for
business user. All work would be presented to the user through the application,
all documents and any general data entry applications.
Giving the user 3 applications to login to was not considered as an option.
As such the design of the client was based on the Windows 95 Explorer concept.
All work based items would be delivered to a folder called "Activities". Within
this structure would be subdivisions by work area. Document access would be
through a folder called "Documents". This view would appear exactly like a
normal PC file system. Although instead of browsing the local PC the user would
be browsing the corporate document management system. Finally, any adhoc data
entry tool would be provided under a Windows 95 control panel style view.
Given the complexity of the system and the number of components the development
of a consistent framework for the user to navigate through and for developers to
develop in was important.
Logging onto the VIES application give the user access to;
1) VIES Sybase server on IBM AIX.
2) VIES Saros Document Mgmt Server on IBM AIX.
3) An Oracle RDBMS running on HP-UX (for metering data).
4) A DB2 Database running on an IBM Mainframe (for purchase and sale
transaction data).
All of the above access is achieved from one VIES login. Apart from a timedelay,
the user is superficially unaware of the services they have connected to.
DOCUMENT MANAGEMENT:
QF Resources is a heavily document centric organization. Their primary business
input is paper their primary business output is paper. Their primary information
reference source is paper.
Problems encountered when in a paper environment are the issues with concurrent
access to documents, available of documents, ability to find historic documents.
For some users the QF contract is their primary business document. However, if
one users has it, no other user can obtain access to that contract If the
document librarian doesn't know who has the contract its missing until returned.
The QF contracts are highly contentious, the QF wants more money, Edison wants
to pay less. As such the contracts can have many additions and addendum's.
Access to the latest copy is important when making decisions regarding the QF.
A group which is close to QF Resources is the Law group. This group manages
litigation with the QF and ensures that Edison is not exposed to lawsuits from
decisions from QF Resources. Law is usually heavily involved in document and
contract reviews processes.
Law can request whole contracts and associated correspondence. While such
document are out of the QFR group it can effect the ability of that group to
make accurate decisions.
The desire to implement a document management solution was based around a need
to provide a centralized, auditable document repository. Such a repository would
allow multi user access and provide simple document search facilities to allow
quick access to historic information.
Saros was chosen as Edison already had 700 licenses available which could be
provided free to the VIES system. Edison had other Saros implementations, mainly
in the Legal groups.
Saros provided Client and Server API's which would allow integration of the WES
batch environment with the WES client Saros had 32 Bit API's which would work
under windows 95. It was an Edison requirement to develop a Windows 95 (Look and
Feel ) application. Although this may not have been stated in the contract.
Document management is nearly signed off and nears completion.
WORKFLOW:
Workflow was originally proposed as a technical solution in the 1995 Phase I of
the project. Its use in Phase II (The VIES prototype Phase) was a direct result
of the Phase I recommendation.
WANG workflow was made available to the phase II development team as Perot was a
VAR for WANG. The Phase II development team had little "real" workflow
experience. What experience was available was within a structured workflow model
environment.
During Phase III (Current WES implementation) it became clear that WANG's
structured workflow model would not fit the process definitions that had come
out of the WES analysis.
Structured workflow solutions perform well in high volume, document centric
environments where the flow of a document from process to process can be clearly
defined. Such environments are Medical and insurance claims handling. Some
financial organizations dealing with loan or mortgage requests.
Within the QFR groups input document volumes are low, maybe 50 a day. Although
the documents are low in volume their high in variability. The potential process
associated to a document cannot purely be determined from its type. A
knowledgeable user must be able to read the document, discern its content and
then decide to file IT, associate IT to an existing piece or work or create a
new piece of work to deal with it.
During phase III it became clear that processes within QFR were not complex in
terms of their flow between workers. They were complex vertically, once a user
started a process, they could take any number of options or route a piece of
work to any number of other people/roles.
Structured solutions require the ability to define the process completely,
including exceptions. Most structured tools don't allow repetition of choices or
random selection of choices.
The term vertically complex attempt to describe the fact that the worker
performing the role has many options available to them and many tools to support
the options. These tools are mainly document and spreadsheet templates.
However, in the mists of this chaotic and adhoc work was a requirement to audit
what was being done. Requirements also exists for specialized processing when
items where completed.
Our users were "knowledge based" worker requiring the delivery of information,
tools and documents to complete their assigned tasks.
As stated, documents make up a large proportion of the tools used within QF
Resources. Given the need to provide a document management solution, workflow
had to be able to integrate its output into the document management system.
WANGS Saros integration was poor. Also, WANGS server API's where difficult to
obtain and little document was provided to support them. WANG had not produced
the promised 32 API set that would have allowed us a true 32 bit client
solution. It was felt that given the hype around Windows 95 and 32bit
applications WES could not be anything but 32bit compliant.
So, given the inability to fit the process definitions into a WANG model, its
poor server integration, its poor Saros compatibility, its lack of 32bit client
API support. WANG was dropped as a workflow solution for WES.
Also we had difficulty getting consultants that knew the product from an
analysis or an implementation point of view. Perot, as in other areas of the
project could not provide skilled staff to support the project from a workflow
perspective.
Note: WANGS choice as technical solution was not based on merit but on the
"WE'VE GOT SOMEONE WHO THINKS THEY KNOW THE PRODUCT PRINCIPLE.". We had no
experienced WANG workflow analysts, modelers or API developers.
Having dropped WANG, what was the replacement going to be?
One of the consultants that had joined the WES development team indicated that
"collaborative" workflow tools did exists. However, the only one identified at
the time was from "Action Technologies". The platforms available where NT only.
As stated NT was not an option. Inaddition paying $100,000 + for a new workflow
tool was also considered to be an unappealing option to the account manager.
Attempting to convince the customer on a fix priced bid that they should pay,
would have been a consummate sales effort. An effort which failed. Even though
we tried WANG would not refund the purchase price of the product. Perot was
unable to leverage any pressure on WANG to achieve a refund.
The only option left was to look at producing our own workflow functionality
which provided the components needed to support the project. This was not an
attractive option. Most workflow venders have been in the business a while and
have a chance to perfect their products over the years.
However, a simple(ish) workflow design was developed based on a Sybase Database
design. This is now the basis for the WES Workflow.
The workflow requirements of this system fall into three main areas.
Operations:
STRUCTURED WORKFLOW: Process Trigger A-> B-> C-> End
Workflow within this group fits a more traditional view of workflow.
When outage requests are received they need to be evaluated in a
predefined order. One QF may have a maintenance, HydroSpill and
dispatch requirement in the same month. Inaddition these outages may
span the same time frames.
Different Operational analysts deal with different outage types. Within
the business there is a pre-defined order within which these outages
must be reviewed.
As such work needs to "flow" between different analysts based on the
rules of evaluation precedence.
Note: The rules for work flowing is not managed internally but by the
payments system. This means the workflow solution had to allow an
external agent to decide the process flow.
Workflow mearly provided a delivery mechanism and audit trail.
Payments:
Presentation of an Object based on its state to roles who manage an
object of a specific type in a specific states.
Within payments the requirement was for an audit process. Images of the
statement generated by the batch system were checked into document
management on the Unix Server.
Users would review the statements and approve them for release. Two QF
resource roles were involved the Contract Manager (Approver) and the
Payment Analyist (Releaser). This two stage audit process was designed
to ensure accurate statements with a security review.
Before WES statements could be held up in the manual process without
visabiliy to other (management users). Now, managment can find out when
statements are held up. When Contract Managers are not doing their jobs
by releasing statement.
This portion of WES does not run on the workflow engine. Its based on
simple structured queries against the statement tables.
Compliance:
To ensure QF's are conforming to their contracts, QP Resources run
admin processes to check for Insurance, security renewals etc. To check
that QF's are generating at the right capacities.
The contracts stipulate conditions that the QF must conform to. These
compliance procedures ensure that these are adhered to. Prior to VIES
these process were either not done or done by hand.
If a QF's fails one of these checks they can have their payments
reduced or contracts terminated.
These compliance procedures are described to the workflow model as a series of
tasks (steps) to be executed. Each task may have zero or more tools associated
to it These tools can be templates or visual basic data entry forms,
spreadsheets etc.
The WES workflow engine allows for any external server or client action to
create a workflow instance. Once created the user can execute any step in any
order. However, all actions are tracked in the audit trail.
All documents created by the workflow process are checked into document
management system.
Workflow System Requirements:
Process Definition
The workflow system should allow for the:
1) Definition of an event as series or child events (tasks).
2) Definition of tools to events based on state.
3) Definition of child events to parent events based on
state.
4) Definition of specific business rule execution on change
of event state.
5) Ability to access tools in external systems: Eg Document
templates from a document managment system.
6) The definition of individual roles to perform events.
7) The ability to define the states and event can be in.
Process Initiation
The workflow system should allow for the:
1) Creation of workflow events by batch server processes.
2) Creation of workflow events by client requests.
3) Control of process flow by external systems.
Process Presentation
The workflow system should allow for the:
1) Access to the workflow que from client or server.
2) Ability to define different tools to be launched for
different events
3) Compliance to a Windows 95 look and feel for client based
access
4) Intergrated login ability. No multi system logins for
users
5) Ability to segment work not just by role but also by data
within process. Example Contract Id. 7 Contract managers
each with a seperate group of contracts.
Process Execution
The world1ow system should allow for the:
1) Abilty of a user to pick and chose the order in which
events are executed.
2) Ability to complete a process without performing all
predefined tasks.
3) Ability to re-open a process and change its state.
4) Ability to integrate the workflow process with a document
managment system.
5) Ability to re-assign work on an individual or block
basis.
6) Ability to define the priority of the work based on due
date of completion.
7) Ability to suspend work for a time period. Put the item
on a reminder and have it reappear on a given furture
date.
8) Ability to find events across the system by type, time,
state, role and user. Having found the event the user
should be able to launch and view the event and its
history.
9) Ability to add other nominated roles or users to the
event on an adhoc basis. The solution should allow for
the definition of the events to be performed, timeframes
in which to perform the event and make specific documents
available to the other part via this adhoc request.
10) Ability to add adhoc on the fly events to an existing
process. User may which to add a task to Validate
Statement. Such a task would not have been defined in the
orginal process defintion. Its inclusion would be for the
executing user.
11) Ability to create an adhoc on the fly event which the
user can add events(tasks) to. Workflow engine would
mearly provide the audit trail and delivery mechanism and
container for this adhoc event.
Process Completion
The workflow system should allow for the:
1) Ability to record all event state changes that take
place.
2) Ability to define management reports based on audit tail
data.
3) Archive data based on state, type.
4) Ability to create new events on the completion state.
5) Ability to execute business specific operations.