Rule 22 Subteams; Electronic Commerce Proposal

Pursuant to our discussion at today's Rule 22 meeting, I am attaching
Powerpoint charts with the task groups that I am aware of under the Rule 22
and Data Quality and Integrity working groups;  I have taken the liberty of
including an Electronic Commerce task group as proposed below.  As part of
proposing a document that I introduced at last month's DQIWG meeting, which
DQIWG felt would be best addressed by an Electronic Commerce group under the
Rule 22 committee and which may be the first priority for the proposed
Electronic Commerce task group.

Most of the issues that would be addressed by an Electronic Commerce task
group (perhaps called a Future Electronic Commerce Directions task group)
are a different type of issue from both the issues that the Customer Data
Transactions (CDT) subteam was originally formed to address (i.e., immediate
problem-solving needs) and the issues that the Operational Manual group
should address (i.e., documentation of operational practices, including the
identification of inconsistencies that should be addressed somewhere).  An
Electronic Commerce group would focus, in contrast, on ways to improve the
efficiency of the marketplace (even though the status-quo might not be
considered a problem).  There would be no predetermined timeframe for
resolution of these issues, in contrast to the "immediate" nature of CDT's
issues -- the timing of implementing proposals raised in this task group
would depend on an assessment of the costs of implementation vs. the
benefits to be achieved.

This Electronic Commerce task group could encompass existing Electronic Data
Interchange (EDI) efforts but does not need to do so.  If an Electronic
Commerce group had formed earlier, I believe that its initial tasks would
have been those that have been the focus of separate task groups:  for
example, billing, and DASR consistency and account maintenance.  Thus, there
is no practical difference between launching these tasks as separate efforts
and now forming the Electronic Commerce group, and forming the Electronic
Commerce group earlier and launching these as its first tasks.  Use of EDI
for meter usage data may progress quickly enough toward an agreed-upon
implementation guideline that this task does not need to be combined into
the Electronic Commerce task group;  however, EDI for meter usage data could
provide a good trial for rigorous testing procedures that would be developed
by the Electronic Commerce group.  Use of EDI for meter-specific information
flows may be more closely related to non-electronic processes that are its
predecessors, so that this EDI effort could also be best kept as a separate
task group.

Given this background, the first task would be for the group to scope its
efforts.

The next task for an Electronic Commerce task group may then be to propose
Electronic Data Exchange requirements, pursuant to Section D(4) of Rule 22,
which refers to such requirements but does not completely define them or
provide specific criteria for judging when they are met.  This is the
subject of my presentation (attached) to DQIWG last month;  DQIWG agreed
with this need and referred its implementation to a forum where subject
matter experts could be found, i.e., an Electronic Commerce group.  In
summary, achieving the benefits of EDI requires sound data processing
practices.  For example, acknowledgement and verification processes are
integral to EDI.  Also, sound operations include data recovery procedures;
this type of requirement is expected for MDMAs but should apply to all
providers of data.  The utilities and large ESPs, MDMAs, and MSPs have
probably developed sound data processing practices that can be evaluated for
recommendation as requirements for other market participants.  An Electronic
Commerce group may also be the appropriate manager of a change control process.

Future tasks would consider (1) development of Internet transport mechanisms
to replace the use of Value Added Networks (VANs), and (2) desires to use
EDI for payments and the collections process, and to automate transfer of
other data including load profiles and line loss factors.  Taking Internet
transport mechanisms as an example of how an Electronic Commerce task group
might function, first steps would be to (a) identify and evaluate
alternative proposals (in this case, including the Internet "pull" mechanism
used now for meter usage data, intranets such as WENet, and external
standard-setting efforts by groups including the Internet Engineering Task
Force, Gas Industry Stsndards Board, and CommerceNet), (b) resolve
uncertainty as to the merits of the alternatives through pilot testing, and
(c) develop migration strategies once a preferred alternative is
agreed-upon.  The decision process would include at least a qualitative
comparison of new alternatives to existing mechanisms, e.g., use of reliable
and proven, but costly, VANs.

I look forward to further discussion of such a task group, and am willing to
do its organizational work.

EDI-QAQC.DOC

WG-TEAMS.PPT