Back-Office Operations by zhangyun

VIEWS: 34 PAGES: 26

									Draft Version: 1.0




Back-Office Operations

KeySpan Energy is responsible for supporting LIPA’s entire back-office billing operation.
KeySpan currently produces approximately 1.8 million bills for LIPA on a bi-monthly basis,
which include both electric and gas customers. There are 1.1 million electric meter
readings obtained on a bi-monthly basis. KeySpan manages the billing cycles against two
reading schedules which are classified by Odd/Even months.

       Schedule A Odd month: Accounts for 900,000+ meter reads
       Schedule B Even month: Accounts for 880,000+ meter reads

The back-office operations at KeySpan are comprised of an array of functional groups, all
of which are responsible for all of the day-to-day functions and activities associated with
managing the customer lifecycle and ultimately producing the final deliverable –
production of invoices for LIPA’s customers. The integration of complex, sophisticated,
“best of breed” and costly "back-office" systems is prompting a fundamental change in
how KeySpan views and manages their operations. KeySpan recognizes that their
escalating number of "best-of-breed" vendors, from billing and customer care to fraud
protection and workforce management, require constant and continuous evaluation, and
that no one solution can solve their back-office integration issues. This coupled with
integration of state-of-the-art software applications to a legacy CIS creates challenges
and inefficiencies within the KeySpan operation. Consequently, the one-vendor-can-do-it-
all approach is a distant memory. KeySpan recognizes the value of partnering with other
service providers to meet the burgeoning back-office demands, and is following the lead
of a new breed of system integrators and a host of ancillary service providers.

KeySpan administers and operates three different billing systems to accomplish the billing
component of LIPA’s business. Trying to focus on business users, leverage what is in
place today for residential billing and customer care, and integrating other services from
different vendors, presents a difficult challenge for KeySpan as the requirements can vary
dramatically by customer class. KeySpan recognizes the limitations of the legacy CIS
billing system, but needs to balance change with the recognition that the current system
successfully bills 80 to 90 percent of LIPA’s customer base.




LIPA
March 3, 2002
Page 1 of 26
Draft Version: 1.0




KEYSPAN    BACK-OFFICE               BUSINESS        DESCRIPTIONS,           ROLES       AND
RESPONSIBILITIES

A.      Meter Reading and Service Orders

The Meter Reading team processes, manages, and controls a series of daily transactions
falling into a pre-billing function. Included in the responsibilities of this unit are securing
meter readings and reading verifications, service order changes including name changes,
residential electric turn-on and turn-off orders, residential gas turn-off service orders for
gas, and “special” meter readings.

Nine out of ten KeySpan customer offices house a meter reading staff. Each customer
office utilizes the same technology and follows the same daily business processes. All
local offices are managed individually.       However, workflow from each office is
consolidated at the end of each business day for a single upload and workflow process to
the CIS.

The meter reading organization utilizes various hardware and software products to
accomplish their daily tasks.    The descriptions below provide the basic system
functionality and work flow required for KeySpan to manage the meter reading and
service order business units.

CARDS

CARDS is a Computer Assisted Radio Dispatch System utilized for non-emergency work
orders for both gas and electric services. CARDS interfaces with the CIS for generating
non-emergency work orders, and the mobile dispatch system (MDSI) that provides mobile
workforce management and the automation of activities associated with scheduling,
dispatching and oversight of KeySpan’s mobile workforce. MDSI provides a cost-effective
method for KeySpan to communicate and manage field workers, and allows for such
personnel to interface on a real-time basis with the CIS
In addition to interfacing to the CIS and MDSI systems, the CARDS system integrates to
the CARES application. The CARES system is a restoration response system for electric
outages, and is used to diagnose the physical cause of a service outage. The CARES
application is also utilized as an information source by customer service representatives
who can view emergency service orders and job status and provide this information to
customers.




LIPA
March 3, 2002
Page 2 of 26
Draft Version: 1.0




Non-emergency work and out-of-cycle work is processed utilizing the CARDS application.
Such work passes through to the ITRON system and consists of assignments like re-
reading meters to confirm earlier readings, etc. The ITRON system is the system utilized
for the collection of meter readings and completion of out-of-cycle meter readings and
service work order requests (more fully described below). Out-of-cycle or ”non-cycle”
work orders generally are accumulated until 4:00 a.m. and are then transmitted to the
customer offices for download and dispatch. Service order requests are captured directly
into the CIS, and are transferred real-time to the CARDS application for scheduling.

In addition to the major software packages that are mentioned in the immediately
preceding paragraphs, there are a series of subsystems, or file transfer protocols within
the CIS that are critical to managing the service order process, and may, if not working
properly, negatively effect workflow related to the CARDS application. These applications
are described below:

       The MIC file is part of the CIS, and acts as a “holding file” which stores data on
        meter work, meter investigation, meter change out, etc. The MIC file is part of the
        CARDS system.

       Electric Metering is the system utilized for recording meter swaps/change outs.

       SAMM is the scheduling system and a module within CIS rather than a separate
        application. It acts as a calendar that processes and schedules non-emergency or
        non-cycle work.

The Service Order Process

Service orders can be created through multiple sources including customer calls to a CSR
or the IVR. The Customer Service Representative can create a service order for a new
account at a pre-existing premise, as both meter and location information already exist for
that premise. The CSR creates the service order utilizing screens that are part of the
CIS. At completion, the service order is transferred to the CARDS application. The
transfers occur in real-time. All work requests are queued in the CARDS system until
4:00 a.m. daily, at which time a DCI (Datacap Input file) is created for each customer
office. The DCI file contains customer and meter input records for each account to be
processed or serviced, as well as its assignment into a work route or meter reading route.
Each day, there are multiple DCI files created for each customer office since service
orders and routine meter reading assignments are segregated. All jobs in the DCI files
are encoded by job type.




LIPA
March 3, 2002
Page 3 of 26
Draft Version: 1.0




Each customer office performs a series of pre-defined steps when retrieving DCI files
each day. Each customer office is required to:

       Back up each DCI file to diskette after download from CIS occurs.
       Through a cut and paste routine, create work assignments for field workers
        (manual process).
       Back-up cut and paste work assignments to diskette.
       Load daily work assignments into the ITRON handheld units for each field worker.

At the end of each business day, service order assignments must be routed back to the
CIS, CARES, and CARDS applications for updating customer and premise records. Each
customer office performs a series of pre-defined steps to create an outbound DCO
(Datacap Output file) back to the CIS for daily processing and consolidation with other
customer office files. The DCO file contains completed route information and incomplete
work which is flagged for rework, is transmitted from the local office back to the
mainframe and is utilized for bill generation and customer information updates. Each
customer office is required to:

       Have each field worker load his or her ITRON handheld Datacap unit into the
        ITRON system. After each handheld uploads the day’s completed work, it then
        downloads the next day’s work in “one” operation.
       After all field workers load their completed work, a back-up file of the local office
        ITRON database is created prior to the local office DCO file creation.
       The local office DCO file is created, and a back up local office DCO file is created
        and stored on floppy disk.
       The local office DCO file is transferred daily by a pre-designated time to the CIS,
        where the received file is then backed up again at the mainframe prior to
        consolidation with other customer office DCO files, thus creating the master DCO
        file.

Incomplete Service Orders

All assigned service orders may not be completed on a given day. Customer Service
Representatives may assist in finalizing incomplete service orders depending on the
service order type. For example, incomplete work orders such as “unable to gain access
to meter for reading” can often be rectified by a CSR calling the customer to secure the
meter read.

Incomplete service orders will create an exception report the next business day after file
maintenance and daily processing have been completed. The exception output is
produced in a hard copy report and is automatically sent to each customer office for the


LIPA
March 3, 2002
Page 4 of 26
Draft Version: 1.0




unprocessed work queue. In addition, the customer offices receive reports for the prior
day’s completed work orders including both meter reads and service orders.

The CSR responsible for closing out an incomplete service order requires access to both
a “creation” screen and a “completion” screen within the CIS in order to close the
exception. The exceptions are processed directly on the mainframe.

Routine Meter Reading

The ITRON Process

 As mentioned above, ITRON is the handheld meter reading system that is utilized for the
collection of meter reads and for work order completion. ITRON interfaces to both the
CIS and MDSI.

The mainframe CIS application directs and controls the meter reading routes. There are
20 work days or reading cycles per month. Each cycle is then sub-divided into districts.
Meter reading routes are groupings of geographically related meters occurring within a
district. The grouping or packaging of meters occurs through the use of an in-house
system called ARTS.

The ARTS (Automatic Routing Timing System) is a database that tracks historical meter
reading schedules. This is not a bolt-on application, but rather is a part of CIS and data is
processed through a file transfer protocol.

The CIS flags records for meter reading, accumulates these records until the day in which
they will be read, passes the records through the ARTS system to have them combined in
into logical and well-scheduled routes, and finally flags each of the records again to
signify that a meter read request has been generated for the field. Meters scheduled to
be read and service orders are segregated by various codes in the DCI or DCO file
produced daily as part of this system
The process of downloading information from the CIS to ITRON requires manual
intervention, and requires an IT person to keystroke the process to begin the download
procedure. No scripts have been written to automate this process. Routes are created 2
to 4 days in advance so in the event of system downtime, meter schedules can still be
created. The creation of meter-reading schedules is not an automated process, nor is
logic built into the system allowing for the automated creation of route schedules. Manual
routines such as cutting and pasting various schedules are required to concatenate
pieces of data together in order to create a meter reader’s schedule.




LIPA
March 3, 2002
Page 5 of 26
Draft Version: 1.0




Each local office will follow the same steps defined in the service order process to secure
their daily meter reading schedule, and will extract the DCI file for download to the ITRON
system. Each local office is required to perform a series of pre-defined steps when
retrieving their DCI files. The steps include:

       Back up each DCI file to diskette after downloaded occurs.
       Create work assignments for field workers.
       Back-up of cut and paste work assignments to diskette.
       Load daily work assignments into the ITRON handheld units for each field worker.

The handheld ITRON units do not provide the meter reader with the prior reading taken at
a particular meter. This practice avoids the meter reader being able to “guess” at what
the current meter reading should be, and ensures that the meter reader goes to the
physical location and reads the meter. Meter readings can pass or fail for various
reasons, and meter readers must enter the meter reads twice to ensure that the readings
are an exact match. The handheld units will allow the meter reader to enter his/her own
notes for items such as how to enter a premise, where the meter is located, if there is a
dog on the premise, etc., but has no capability to adjust anything that may effect billing.
To summarize, readers can:

        -    Change a record for meter location
        -    Change a record for meter number
        -    Add notes for reading impediments; i.e. dogs
        -    Cannot impact billing or revenue through input to the handheld

Each meter reader works 7 hours per day including travel time. Meter readers returning
from the field are required to report back to the office daily, where meter information is
uploaded from the handheld unit back to the ITRON system.

At the end of each business day, completed meter reading assignments must be routed
back to the CIS in order for the billing process to commence. ITRON has a series of
controls to ensure data integrity prior to uploading the information into the mainframe.
The data is cleansed and validated at the local offices. From here a series of events take
place resulting in an output file that eventually will be concatenated into a single file.
Then, further consolidating all of the individual offices’ data produces a single upload to
the mainframe. Incomplete assignments are rerouted, and are routed back in the ITRON
queue for rework.

Each individual office will process its batches daily for roll-up into a master file for upload
to the CIS. If a single office is having difficulty processing it’s daily file, KeySpan will
purge the local office files into a master file, and processing will occur with the exclusion


LIPA
March 3, 2002
Page 6 of 26
Draft Version: 1.0




of the customer office that is having difficulty. The file from the downed office will get
processed in the next bill run as soon as the problem has been resolved. Bad records or
meters can be eliminated without losing the entire batch. To prevent unauthorized access
and tampering to the DCI inbound or DCO outbound file, the ITRON system contains
multiple levels of security, and can only be accessed by predetermined and authorized
users at the local office.

Local Office batch consolidation of completed work orders and completed routine meter
reading work occurs in the CIS. No middleware solution is involved in the consolidation
process. The CIS has logic built into it that verifies that all mandatory fields are included
in each individual file that is being brought into the consolidation process. At the CIS
level, there is no checking for the accuracy of the data, but rather an operation is
combining and sorting the pre-bill date and checking for file corruption. (This process is
the same for multiple office remittance processing consolidation).

The current ITRON system is scheduled for replacement with the next generation of
ITRON in 2002.

Other subsystems or interfaces utilized in the metering process include:


       CRIS (Customer Read Input System) is part of the CIS system. Integration with
        the CIS occurs at file maintenance time. CRIS identifies and utilizes actual
        readings secured by meter readers over customer mail-in meter reading cards or
        other estimated meter reads. This hierarchy of acceptance ensures that the most
        accurate meter reading (in a situation where there may be multiple readings for the
        same customer) is the one that is used in the final bill calculation.

       AMR’s (Automatic Meter Reading devices) produce readings that are transmitted
        to the metering organization and then to CIS from the metering application. The
        AMR reads are secured by telephone or cellular service, and are identified and
        segregated by rate class, and coded as an AMR transaction. The AMR
        transactions are processed through the normal channels, but are not included in
        the same file as routine meter reads. The file structure is the same as the routine
        meter reading or service order DCI/DCO files, but is processed as a separate file.
        AMR/ERT meters are included and identified in DCI/DCO, but are flagged to be
        skipped by meter readers.

ENSCAN is a broadcaster that wakes up electronic receivers and transmitters (ERTs)
and pulls in meter reading data. The ERT is hardware, which resides on the meter;
however, it is not used for electric meter readings at this time. An ERT (is installed on the



LIPA
March 3, 2002
Page 7 of 26
Draft Version: 1.0




meter and can work utilizing a handheld solution, mobile solution, or pole-top reader. The
ERT transmits a signal to pass the meter reading back to ITRON. The meter reader is
not required to physically go out to read the meter. The ERT is utilized mostly for R&D
purposes, particularly in areas where access is difficult, e.g., Fire Island is difficult to get
to, and is all-electric. The ERT is a fully automated process. Meter read data is passed
through the system in the same manner as standard reads.

Telephone reads – Telephone reads occur at the meter level and are transmitted via a
modem that is connected to the meter. This process is used primarily for industrial
customers. KeySpan obtains telephone readings at will, utilizing land lines as opposed to
cellular devices to eliminate breaks in the transmission process.

B.      Remittance Processing

The Remittance Processing team posts customer payments, verifies receipt of all
electronic payments, prepares deposits and reconciles reports. Staff in this unit provides
secondary support to the Call Center and Account Maintenance, and the Collection
Department in resolving issues related to the customer’s payment history.

KeySpan processes more than 900,000 remittances per month utilizing various payment
processing services including external lockbox, in-house lockbox, ACH payments, direct
debit, walk-in vendors (pay stations – Western Union) and web payments. Citibank is the
clearinghouse for ACH transactions and for external lockbox remittance processing.
Chase Manhattan is the clearinghouse for direct debits.

Remittance processing follows the same file transfer methodology as meter readings for
file consolidation and upload to the CIS. Ten offices have the ability to accept walk-in
payments. All offices follow the same process and utilize the District Office Teller System
(DOTS).

Payment processing from external collectors (ACH and Direct Debits with Chase
Manhattan Bank) are handled utilizing a VAN or “external mailbox” as the method of file
transfer. The VAN provider for KeySpan is ADVANTIS. Files are split off to segregate file
type being transferred, and are transmitted over a secure telephone line. KeySpan
utilizes an outbound transaction for Direct Pay transactions and sends the direct pay
transactions over a secure connection to ADVANTIS during file transfer.

Western Union and Cutaway also are transmitted utilizing the ADVANTIS mailbox. In
addition to the confirmation of the file transmission, all external sources will send a
summary report to KeySpan via fax identifying the totals that were received with each file
transmitted, with cash deposits following thereafter.



LIPA
March 3, 2002
Page 8 of 26
Draft Version: 1.0




Files that are picked up at the ADVANTIS mailbox are processed through what KeySpan
identifies as “Phase 1” processing. The remittance files are translated into a standard
language and prompt the generation of a series of reports that are used to validate
inbound remittance files. The remittance processing team validates the dollar amount of
the file that had been transferred. If the files are in balance, the remittance processing
team will contact the Customer Accounting team for final verification. Upon final
validation, the Customer Accounting team will set a flag which signifies that Phase I
processing has been complete. This releases the batch into Phase 2 processing (
processing in the file maintenance run). If files are not in balance, remittance processing
will keep researching the errors until the files are in balance. Phase 2 processing will not
occur until remittance processing is in balance.

Citibank is the external lockbox for KeySpan. Citibank delivers a daily tape to KeySpan
for processing. The tape is loaded directly into the CIS by the remittance processing
team, and will go through the normal Phase1 processing routine.

KeySpan’s internal lockbox processing (Bank Tec) creates an end-of-day-file which
follows the same methodology as the DCI/DCO routing and gets imported directly into the
CIS via File Transfer Protocol (FTP).

Web payment transaction payments are logged into a holding file utilizing an internal GUI,
and are processed through the normal ACH processing channels.

Telephone payments taken by a customer service representative are collected into the
Speed Pay system and are held until 10:00 A.M. daily. Manual checks are produced by
Customer Accounting, bundled and sent to remittance processing for manual payment
posting. These checks are processed in Phase 1 batch processing.

External collection agencies send tapes to KeySpan for delinquent customer payments.
The tapes are loaded directly into the CIS, and follow the normal remittance path
channels including Phase 1 and Phase 2 processing.

After all daily remittance files have been processed, a “shadow” file is created which
equates to a “dummy payment” being posted against the customer’s account. The
shadow system, in essence, tricks the CIS into viewing the payment ahead of the actual
posting to the customer’s account so as to allow a Customer Service Representative to
see a customer payment in the event that a customer inquiry is received prior to the
payment being posted. However, the customer payment is not reflected in the CIS until
the next day after the file maintenance process has been completed. Shadowed files
exist for: Lock box, Western Union, Bank Tech, DOTS, and cash payments.



LIPA
March 3, 2002
Page 9 of 26
Draft Version: 1.0




KeySpan posts all direct debit information to the customer’s account at the time the direct
debit is generated, thereby reducing the customer’s accounts receivable balance at the
time the batch processing occurs. It is assumed that direct debit is a “good” transaction.
In the event that the transaction fails, KeySpan treats the bounced direct debit in the
same manner that they would treat a bounced or returned check. All exceptions are
handled in the remittance processing group.

A direct-debit batch file is created at the time the bill generation occurs, but the
customer’s bank account is not debited immediately. A direct debit customer has the
same payment remittance cycle (20 days) as a person sending in a physical check. This
provides the customer with the same timeframe to dispute a bill.

At 3:30 P.M. batch files are closed, reconciliation occurs, and a batch file is created and
sent to the mainframe by 5:30 A.M. the next business day for processing. The payment is
then posted to the CIS and applied to the customer’s account, where it is reflected in the
customer’s account balance between 3:00-4:00 p.m. the next business day.

Deposits from construction jobs and offline-billing include items such as special services
or product offerings and are handled through a separate billing engine. The information
on these accounts is not encompassed in the customer record in CIS and is not handled
within the remittance-processing unit.

C.      Collections

The Collections Team processes, manages and controls the production of credit notices,
initiates termination requests for non-payment, makes special arrangements for payment,
follows up on unpaid accounts, and works with collection agencies in accordance with the
specified business practices.

When a customer account has aged to 30 days in arrears, it is placed into the aging
“bucket”, and a calling campaign commences to begin the collection activities. The
telephone collections campaigns can vary, along with other collection activity based on
customer type, amount of arrears, prior arrearage history and a number of other factors
that comprise a credit weighting algorithm.

A late notice will be generated after 30 days directly from the CIS. The collection process
is enhanced by the utilization of an external system called MELITA. MELITA is a system
utilized to speed up the telephone collections portion of the collections process. MELITA
uploads and downloads file transfers in the collection process. A file is created for the
MELITA System, which is derived from the file maintenance review of delinquent



LIPA
March 3, 2002
Page 10 of 26
Draft Version: 1.0




accounts generated from the CIS. MELITA handles the automatic telephone dialing of
the customer’s account and then presents the CIS transaction window to an available
Customer Service Representative when a person answers the phone. MELITA utilizes an
auto dialer (predictive dialer), which will call the list of delinquent customers until an
individual answers. When a customer answers the telephone, the MELITA screen will
toggle over to the CIS customer information screen for each customer that is contacted.
A daily download of all accounts receivable occurs, populating MELITA with information
on accounts that are delinquent and separates accounts that are to be processed by
telephone collection from those assigned to receive other collection treatment. MELITA
also identifies customers that cannot be terminated for non-payment, i.e., cut off.

After the initial 30-day late notice is generated by the CIS, it is followed up by five “soft”
collection telephone calls, then another late notice on day 38. This procedure repeats
every six days after day 38 until 60 days have passed, at which time a termination notice
will be generated along with a last reminder call, and an offer of a payment arrangement
(the protocol for this process is defined by the New York State Home Energy Fair
Practices Act).

The procedures for actual termination for non-payment are specific and deliberate, and
include 2 field contacts which must occur within 72 hours prior to termination of service.

If a customer makes a payment or payment arrangement during MELITA processing, the
account goes back into the normal billing loop. If an account is terminated for non-
payment and no payment or payment arrangement is made within a fixed timeframe, the
account is closed or “finaled.” Note that customer balances and active account
delinquencies are not reported to credit bureaus.

Field representatives are empowered to turn off service, collect funds at the premise, or
make payment arrangements with the customer.

There are various regulations and conditions that can limit KeySpan’s ability to terminate
service to either a residential or commercial customer. A database is maintained and
managed by KeySpan’s in-house legal department for use in the initiation of direct credit
action against a customer. Generally such action is limited to customers that are not
incapable of paying for service, but just refuse to pay. Records of such accounts are
routed automatically to the legal department based on predefined criteria coded in the
CIS system.

Prior to initiating such direct legal action, KeySpan will closely examine a customer’s
credit information to ascertain whether :




LIPA
March 3, 2002
Page 11 of 26
Draft Version: 1.0




        1) the customer is paying other bills (aside from LIPA bills)
        2) the customer has a significantly high balance, enough to warrant legal action
        3) the customer has an account status of “life support” which automatically
        triggers protections provided by regulation or statute

Final bills – Collection action is undertaken on closed or finaled accounts as well as on
active accounts. Twenty-three days after a final bill has been generated, customers
whose account balance was more than 30 days in arrears, i.e., had 60 –90 day old
outstanding balances at the time the account was closed (finaled) are classified as “early
referral” accounts and are forwarded to a collection agency. Prior to going to a collection
agency, KeySpan will take days to identify if the delinquent account can be tied to another
account that may have been activated by the customer. In the event that a determination
can be made that the customer has a currently active account, the final bill amount will be
transferred to the account. Such customers are likely to be automatically placed in the
collection process.

In the event that a match cannot be found for that final bill, the delinquent account is sent
to a collection agency, which will maintain control of the delinquent final account balance
for 45 days. If attempts by the collection agency remain unsuccessful after 45 days, the
delinquent account is returned to KeySpan. At approximately day 99, the delinquent
finaled accounts pass through another queue to again attempt a match between the
delinquent account and another active account established by the same customer. If no
match occurs, the bill will be written-off as uncollectible at the 120-day mark. Note that the
collection process can be interrupted if the customer has a hardship documented by the
collection agency.

After the account has been written off, it is returned to a collection agency. KeySpan
utilizes 5 primary collection agencies and 2 secondary collection agencies. If payment
arrangements are made between the collection agency and the customer, the collection
agency informs KeySpan to suspend the charge-off process so that the collection process
can continue.

 Once a final bill is produced, and a charge-off has occurred in the CIS system, there are
no “note” capabilities permitted on the customers account. The account transitions to
view-only status on the CIS, along with debit and credit posting rights. KeySpan
generates reports to the collection agencies notifying them if it has collected funds directly
from the customer for delinquent accounts being managed by the collection agency. It is
the collection agency’s responsibility to adjust the ledger balance of the accounts that
they have been contracted to collect upon. KeySpan audits the collection agency reports
to ensure financial responsibility.




LIPA
March 3, 2002
Page 12 of 26
Draft Version: 1.0




The direct costs to KeySpan related to collection agency fees are relatively low for
customers in the “Early Referral” process, but are high during the “Charge Off” process.
This scale reflects the increased difficulty in collecting outstanding balances as the
delinquent account ages.

In order for a collection agency to invoice KeySpan for their fees, detailed invoices must
be provided for each customer from whom the agency has successfully collected
outstanding amounts.

Reports on the collection of funds by the agencies will first be sent to the KeySpan
collections team for documentation; then to Customer Accounting for balance
adjustments and recording in order to account for collection agency commissions,. and
finally to payment processing to adjust customer account balances.

A module within the CIS called SACM is used during the collection process. SACM is the
subsystem that is used to determine assignments for field collectors. It is a menu-driven
system that provides one with the ability to access pending work and assigned work.
Field assignments originate from three KeySpan offices: Garden City,
Brentwood/Patchogue, and the Hamptons office. SACM can identify scheduled jobs such
as:
             Whether an account is to be turned off
             if late and delinquent notices have been generated on an account, etc.
This SACM system generates paper notices. This is not an automated process and work
that has been assigned and completed must be manually entered into CIS so that the
system will reflect the change in status . This is strictly a field collection application that is
utilized for work queue management. This process is not tied to MDSI.

Returned Checks - If a check is returned during the collection process, remittance
processing will provide the collection team with the physical returned check, triggering a
series of activities in the collection process. All returned checks are handled through the
collections team regardless of whether the account is in some stage of the collections
process.

D.      Billing

The majority of LIPA’s billing is routine billing and accounts for 90% of its volume.
Routine billing occurs as meter reads are received from ITRON, are uploaded to the
mainframe CIS, and pass through the nightly batch process.

Large electric customers are billed utilizing an offline billing routine. Rate structures are
handled outside of the CIS utilizing an excel spreadsheet, with results being incorporated


LIPA
March 3, 2002
Page 13 of 26
Draft Version: 1.0




into the CIS via screen scrapes and Visual Basic applications. This type of billing is
classified as “Special Billing”. Tariff and rate classes, along with bill calculation formulas,
are set up in an external spreadsheet and bill calculation occurs offline. There are
approximately 2,000 such offline billed accounts comprised of dual service (gas and
electric) and about 1,000 additional accounts for each individual service type. This
process is utilized for special contracts with both commercial and small industrial
customers.

The offline bills are not considered to be significant in number , but are significant in terms
of the dollars of revenue they generate.

Routine billing is an automated process occurring within the CIS daily. Routine billing
occurs after daily processing and file maintenance procedures have been completed. A
number of actions must be taken before a billing run can begin. These include: cash
postings, ITRON daily uploading, and setting the daily system constants

The sequence of events is:

    1)   ITRON meter reading jobs are validated and then uploaded.
    2)   The accounting group sets the daily constants.
    3)   The CIS validates the daily constants.
    4)   Cash charges are applied to customer records.

The File Maintenance Job process is the global batch-processing job for all KeySpan
activities requiring daily processing. Billing is a batch job within file maintenance. If any
process fails within the batch processing, IT staff trouble-shoot the processes and
resubmit that component of the job that failed. There is a rotation schedule to ensure the
appropriate IT staff coverage. At the time of a given failure, the IT resource “on call”
identifies the batch job that failed, and will either fix the problem or remove it from the
batch process so that other batch elements will continue.

Streetlight billing is processed within the CIS. The CIS stores the customer rates, then
accesses a separate DB2 database inventory to calculate the bill.

In the routine billing process, exceptions generally are hi/lo failures, and are sent to the
billing team for analysis. Exception memos are automatically printed, documenting
details of the failure, and are worked by billing analysts. Each billing analyst corrects the
exception and releases it back into the work queue for processing. This is handled by
“flagging” the exception as completed in order for it to go back into the regular batch-
processing queue.




LIPA
March 3, 2002
Page 14 of 26
Draft Version: 1.0




Exceptions must be handled prior to the next bill being generated for a given customer.
The system does not allow a current bill to process without a prior bill being processed
first. Demand accounts cannot be resolved without a relatively thorough investigation.
Normal exceptions are generally corrected within one business day. However, those
exceptions that require field investigation are not included in the one-day turn around
time. Billing of commercial accounts is generally put on hold until resolution of
exception(s) has been completed.

The CIS automatically checks and verifies batch totals. During the morning following the
batch run, there is a manual verification of rates. One randomly selected bill from each
rate class is verified. As of the date of AEG’s last meeting at KeySpan, the bill verification
process occurred after the bill print stream had been created and been sent to the internal
print facility. KeySpan advised us that during February, 2002 the bill verification process
was to reverse itself, and bill verification will occur prior to the print stream being sent to
the internal print facility.

There are two balancing routines to ensure that bills that have been generated equate to
the system total. Bills are balanced based on the total number of bills generated, and the
total dollar value of the invoices.

Checkpoints prior to billing include:

        DCO ITRON upload
        Check posting
        Manual verification of number of items going through bill run
        System balancing (is automatic, but have a human eye verify the balancing totals)
        Totals per district office are validated

E.       Revenue Processing

Revenue Processing is a full-service accounting organization whose primary
responsibilities include examining where goods and services were sold, who they were
sold to, as well as segmentations by customer class, geographic location, commodity,
customer ownership, marketer and tax base. The revenue processing group works with a
data warehouse and is embarking on a strategy to lower posting time. Revenue
Processing is composed of three teams within KeySpan:

        Remittance Processing
        Customer Accounting
        Treasury Services



LIPA
March 3, 2002
Page 15 of 26
Draft Version: 1.0




The Revenue Processing team manages off-line bill generation, i.e., bill production
outside of the CIS.

The Revenue Processing team utilizes the Oracle Financials (KeySpan) and Great Plains
Software systems as their accounting and billing packages respectively. Financial data
from Oracle Financials is not data warehoused, nor is it made available to LIPA digitally.
Rather, all accounting data that LIPA receives from KeySpan is presented in the form of
reports.

Revenue Processing receives consolidated data on a monthly basis for inclusion in the
general ledger. Daily financial transaction files are created and are combined to produce
one file for loading into Oracle Financials. Revenue processing employs daily reports to
validate financial information.

Other divisions of KeySpan that utilize Great Plains include:

       Trading Services
       Project Management

       Real estate
       Regulatory

Each of the functional groups referenced above utilize Great Plains for billing. All
customer invoices generated from Great Plains are printed utilizing the Great Plains print
functionality. Note that the print results do not update the CIS as the package is utilized
for all non-commodity billing.

Revenue results produced by the Great Plains system are uploaded to the general ledger
for financial reporting purposes. The monthly update is an automated task produced by
the Oracle Financials accounting package (General Ledger).

Special contracts for non-product billing that are not resident in the CIS require the same
amount of controls, quality and integrity checking as those bills produced by the CIS. The
responsibilities are replicated for items processed by the Great Plains system. Great
Plains invoices are generated internally and printed during the same day that the bill was
calculated.

Revenue Processing does not learn about the financial obligations for the purchase of
commodity supply until approximately three months after the commodity has been
purchased and scheduled.    This notification, when it is made, originates with an
Independent System Operator (ISO) Settlement Notification. The tardiness of this


LIPA
March 3, 2002
Page 16 of 26
Draft Version: 1.0




notification process presents a major issue within the offline billing operation. This results
in KeySpan spending a considerable amount of time putting together manual reporting
documents which must suffice in the absence of timely reporting that utilizes a
sophisticated reporting tool for tracking purchases.

There are a number of restrictions inherent within the Great Plains software. This lack of
functionality results in KeySpan having to “reverse engineer” consolidated data in order to
produce data at the required level of detail such as taxes, surcharges, etc.

Current General Ledger structures also present challenges for the Revenue Processing
team and prevent them from providing LIPA with any real level financial reporting
capability upon demand. One of KeySpan’s largest challenges is reporting against
purchases vs. revenue. Purchase charges are not segregated by general ledger code, by
customer class, or by customer type. Rather, the Revenue Processing team receives
consolidated purchase totals, resulting in the same type of issue as was discussed above
in the immediately preceding paragraph.

Calculation of unbilled revenue is another month-end reporting requirement and is
calculated through the end of the day for a given month. The Great Plains system has no
way of segregating these amounts, although determination of this information is one of
the most important responsibilities of the Revenue Processing team. This process
includes utilization of various calculations and algorithms, estimating routines, usage and
weather patterns, seasonal rates, etc.

  “Lost and unaccounted for” is another monthly calculation that is required by LIPA. This
calculation consists of billed and unbilled usage data, versus the send-out data available
from the Electric System Operations Department (ESO). In simplistic terms, this
calculation is represented by the difference between ESO send-out data minus (line loss,
commodity theft and giveaways) minus accounted for revenue. The resultant is “lost and
unaccounted for”. The “lost and unaccounted for” is allocated across all rate classes.

There are approximately 600,000 customers that hold dual service accounts, i.e., electric
and gas accounts. KeySpan has had many challenges in the payment allocation and
processing related to the application of cash from multi-service customers and has made
considerable modification to they CIS in order to be able to perform this segregation
function. New systems have been put in place regarding separation of cash. This is not
an issue on the Great Plains system, as it does not process dual service customer bills.

Customer adjustments requiring issuance of a check are processed in the CIS as part of
a batch process which creates a transaction that goes to the Customer Accounting group




LIPA
March 3, 2002
Page 17 of 26
Draft Version: 1.0




where the check is ultimately generated. A quality control process is in place to validate
the check amount prior to mailing.
Other transaction types performed in the Customer Accounting group include:

        Transfers between accounts
        Resolution of misapplied payments (correction information is generally identified by
         the customer not seeing a payment reflected on their account)
        Unidentified payments with no recognized account

Miscellaneous revenues arising from construction jobs (“contributions in aid of
construction”) are maintained in a separate, stand-alone ACCESS database which tracks
construction deposits and ensures that customers receive refunds once the necessary
deposit requirements have been met.

F.       Electric Marketing

KeySpan’s Electric Marketing team is responsible for the development and servicing of
LIPA’s customer programs. Specific responsibilities include developing, implementing,
selling and servicing of these products and services. In addition, the Electric Marketing
organization is responsible for new and creative rate development and contract structures
for LIPA’s major accounts.

There are three sales teams within the KeySpan organization.

        Metering Group – Comprised of 12 account executives who are responsible for
         LIPA’s “250 major accounts” and provide account management services of all
         types including the resolution of service issues.

        Economic Development Group – Responsible for expansion opportunities, rate
         incentives for existing LIPA customers and Come to LI programs, as well as
         offering other non-commodity products and services.

        Product Sales Group – Handles small to medium-size commercial and industrial
         customers and acts as a vendor relationship manager providing support functions
         including incoming call handling, brochure requirements, fulfillment activities,
         HVAC services, construction, etc.

The Energy Hotline is an information line which manages retail choice for LIPA. They
provide technical support, audit promotion of efficiency, and billing and reconciliation.




LIPA
March 3, 2002
Page 18 of 26
Draft Version: 1.0




The Technical Support group manages energy audits and proposed installations of
energy equipment.

Tariffs are defined within the marketing organization. The Customer Care team is the
liaison with Marketing to determine the feasibility of a tariff design, and getting tariffs
included in CIS. KeySpan programmers are responsible for implementing and coding the
tariff. The Marketing team is responsible for identifying the billing determinants. The
Billing team is responsible for maintaining the tariffs.


Standalone databases housing data on individual programs that are administered by
KeySpan do not feed back into CIS unless a program is identified as an AMR or OMR
account, or it is imbedded within a rate structure or tariff. A CSR cannot identify any of
the programs that a customer is participating in by utilizing data contained in the CIS.
This is a major limitation of the current system as it hampers the ability of KeySpan/LIPA
to pro-actively offer programs and services that would benefit the customer and/or
generate revenue.

The Electric Marketing team will send out targeted marketing promotions and will do so by
segmenting based upon specific data such as a rate class, consumption, SIC codes, etc.,
depending on the type of program. The customer information is derived from the data
warehouse rather than from the CIS. Databases are designed around the marketing
program that will be offered.

Electric Marketing negotiates Offline Billing custom rates with customers. Consumption
and time are routed to Billing, which, as stated above, will then perform the calculation for
the offline bill, and enter the results into the CIS.

This team also handles third-party billing. Customers and energy service companies
(ESCO’s) are treated as one. Currently, the capability exists only to bill for commodity
transportation and delivery. However, it is expected that the capability to bill for the
commodity itself will be in place shortly. Billing for the commodity supplied by an ESCO
is presently the ESCO’s responsibility. Separate bills are rendered in such cases.

Marketing databases are designed around the specific program that is being offered to
the market place and do not interface with the CIS. CIS diary entries are made in some
cases, but records cannot subsequently be sorted by diary, thus limiting the usefulness of
that data. Each program manager has the responsibility of managing his/her own
program-specific database. Data is stored in a data warehouse for query.




LIPA
March 3, 2002
Page 19 of 26
Draft Version: 1.0




There is currently no web activity between major accounts and LIPA including bill
payment functionality, bill viewing, etc. Marketing web is one-way information transfer
going to customers, but does not allow information to come back from customers.

Rebate programs are a manual process handled outside the CIS. Certain rebate
programs can result in a bill credit, which is passed to Customer Accounting for
processing.

The data warehouse is accessible through various reporting tools. Key account revenue
is tracked through the offline data base information, which is extracted from the data
warehouse.     In order to develop improved reporting capabilities going forward,
Marketing’s goal is to “marry” SIC codes, D&B reports and consumption data into yet
another system.

There is no formalized change control process for handling requests from LIPA to
Marketing. LIPA requests originate from multiple sources and appear to be creating task
management and prioritization issues for KeySpan. This has resulted in competing
demands for resources for both LIPA and KeySpan. KeySpan has begun looking into the
implementation of a formal change control process to remedy the situation.

The Consumer Communication Group is responsible for bill formats, and for identifying
the information that is required on the bill. The current system does not allow for much
flexibility in bill formats. KeySpan will be releasing new enhancements (the ISIS system
will replace the existing 30-year old LILCO bill print process), which will then allow for
greater flexibility of bill formats, allow for more line items, will allow for multiple
consolidated accounts and summary billing, support non-commodity billing, and will
support new ESCO services including usage comparisons.

CIS Overview

KeySpan utilizes an internally-developed CIS system, which is carry-over technology from
the Long Island Lighting Company. KeySpan has reengineered the mainframe system by
adding bolt-on applications or subsystems to the mainframe to allow for greater flexibility,
better processing and controls, elimination of duplicate efforts and workarounds, and
have attempted to improve reporting mechanisms. Older systems such as the system
being discussed however, are not scalable and utilize obsolete mainframe technology as
the hardware platform, making them expensive to operate and maintain. Most of these
older systems do not possess the capabilities needed to provide customer’s Web-based,
value-added data and services, such as usage reports, online bill presentment and
diverse payment options. In addition, the current mainframe does not support LIPA’s
emerging business needs.


LIPA
March 3, 2002
Page 20 of 26
Draft Version: 1.0




Current Status

The table below summarizes the technology, applications, sub-systems, and interfaces,
which have been developed internally, migrated to the CIS, or interact as an external
application for transactions associated with customer care, billing and reporting.




LIPA
March 3, 2002
Page 21 of 26
Draft Version: 1.0




          Application        Description
          CAPS               CAPS is an vendor-supplied software application
                             which allows for the creation of outbound ACH
                             transactions in order to debit a LIPA customer’s
                             bank account for direct bill-payment.
          CARDS              Computer Assisted Radio Dispatch System is
                             mainframe based and is used for non-emergency
                             work orders for both gas and electric services.
                             CARDS creates and prioritizes customer jobs and
                             maintains the current status information about
                             each job.
          CARES              Customer Assisted Restoration of Electric
                             Service is an internally-developed, mainframe-
                             based graphics and work order system, for electric
                             work orders, and is utilized for emergency service
                             restoration. CARES is utilized to analyze the
                             source of an outage and generates a request for
                             repair. CARES displays electric facilities, allows a
                             customer representative to issue a service order,
                             provides messaging that contains the reason for
                             an outage, if a service representative has been
                             assigned, and the estimated time of restoration.
                             CARES cues the field dispatch mechanism that is
                             fulfilled by the MDSI Advantex r7 communications
                             package. : NOTE: CARES is a system that has
                             been scheduled for replacement with the
                             MAXIMO system and a new implementation of
                             the MDSI system. The new version of MDSI
                             has not been fully implemented, and questions
                             remain as to whether any of the packages
                             provide the outage analysis component that is
                             central to CARES.

          Collection Access The Collection Access File is a daily download
          File              from the CIS of accounts in arrears to determine
                            and commence collection activities including Hi
                            Risk Teams. In addition; this interface creates
                            output tapes which are dispersed to external
                            collection agencies.




LIPA
March 3, 2002
Page 22 of 26
Draft Version: 1.0




          Corporate Meter   * See Electric Meter database The Corporate
          Database          Meter database is a redundant capability and
                            provides the same functionality as the Electric
                            Meter database. The primary difference between
                            the two databases is the capability to generate
                            reports which provide accounting information for
                            tax purposes. The database contains both gas &
                            electric meter information.
          CRIS              Customer Read Card System               The CRIS
                            System is utilized to enter meter reads that are
                            received by mail via a post card system. The
                            CRIS system will search the database to identify if
                            a meter reader has obtained an actual meter read.
                            In the event that a meter reader secures a read,
                            the CRIS system will reject the post card reading,
                            and override it with the reading secured by the
                            meter reader.
          Data Warehouse The Data Warehouse is a shadow box equivalent
                            that reflects data through the close of any given
                            business day. The data warehouse is used for
                            reporting purposes and ad hoc queries. Data is
                            moved daily after batch processing of bill runs.
          DOTS (District    DOTS (District Office Teller System) is the
          Office Teller     cashiering system utilized at the KeySpan
          System            customer offices. The DOTS system acts as a
                            “cash register” for walk-in payment processing,
                            and performs address scrubbing.
          EBO/ISIS          The EBO/ISIS is currently in production for a
          (Enhanced Billing limited number of customers. The EBO/ISIS is an
          Option)           upgrade to partial functionality contained in the
                            CIS system, and will be utilized when deregulation
                            occurs for the Bill Ready billing scenarios.
                            EBO/ISIS will primarily be used for marketer billing
                            and for customers with multiple accounts.
          EDI               EDI is the Electronic Data Interchange for
                            exchanging information, following the ANSI X12
                            protocol. EDI is the primary protocol utilized for
                            transmission of data to and from the UDC's.
                            KeySpan is currently developing this functionality,
                            and has outsourced it to ESG in order to meet the
                            NY guidelines for deregulation. KeySpan is in the


LIPA
March 3, 2002
Page 23 of 26
Draft Version: 1.0




                             process of certifying for the 814 (customer
                             enrollment, customer switch) and 867 (meter
                             usage data) transactions, and will obtain
                             certification for the 810 (billing) transaction when
                             NY regulations and file formats are defined.
          Electric Marketing Electric Marketing is the system used by Sales
                             and Marketing for transportation and distribution
                             programs, and interacts with the Siebel CRM. It is
                             also integrated with various warehousing tools
                             such as Onyx and Micro strategy. This system is
                             utilized mostly for downloads and extracts of
                             customer profiling information.
          Electric Meter     The Electric Meter Database is the repository
          Database           where meters (inventory) are stored. It is used for
                             both inventory and change meter validations.
          Electric Marketing The Electric Marketing Hotline is the application
          Hotline             used to administer and manage conservation
                              programs offered by LIPA. It provides users with
                              the ability to collect information from customers
                              calling the hotline.      The hotline functionality
                              includes: Access to the customer master file via
                              CIS transactions executed in the background,
                              energy usage and air conditioner load
                              requirements, online database of commonly used
                              phone numbers, label generation based on
                              literature requests to be mailed, and productivity
                              and tracking reports.
          Field Collections - This system is similar to SAMM where work for the
          SACM                Field Collectors can be assigned. It is a menu-
                              driven system through which pending work and
                              assigned work may be accessed.
          Finalist            Address scrubbing software
          ITER / ITGR         The ITER/ITGG stores all meter readings that
                              come back from the field. It stores both readings
                              which have either been posted to the customer’s
                              account or remain unposted within the CIS.
          ITRON               ITRON is the automated system for the collection
                              of meter reads for work queue on premises that
                              require reading.




LIPA
March 3, 2002
Page 24 of 26
Draft Version: 1.0




          IVR (Interactive   IVR, or Interactive Voice Response can route calls
          Voice Response     to an outside vendor to assist in call handling,
                             allows a customer to enter meter readings for their
                             account, check their current account balance, and
                             inquire about their last payment. In addition, the
                             IVR provides the option of receiving an account
                             statement in the mail, enables a customer to enroll
                             in or be removed from the Balanced Billing
                             Program, and provides automated options to
                             report electric outages. The IVR can recognize a
                             call-in customer by telephone number or account
                             number, and upon an account match, will inform
                             the customer that the outage has been recorded.
                             The IVR will check if any outage information is
                             available for the customer’s service location, and
                             will provide estimated restoration time.
          KEDLI Web          KELDI is KeySpan’s website and interacts and
                             interfaces with the CIS for obtaining real-time
                             data.
          LIPA Web           LIPA’s website which utilizes PEP+ software for
                             customer-initiated ACH transactions.         LIPA’s
                             website functionality includes allowing a customer
                             to check account balances, process ACH
                             transactions, or place their account on Balanced
                             Billing.
          Lodestar           LODESTAR provides scalable and reliable web-
                             enabled software to competitive retail companies,
                             regulated distribution companies and Independent
                             System Operators, and is utilized by KeySpan for:
                             •      Load       Profiling     and      Settlement
                             • Load Research
          Maximo             Maximo is a work management system that
                             supports equipment tracking, repair, work order
                             generation, and preventative maintenance for new
                             services for both electric and gas customers.
          MELITA             MELITA is a system utilized to speed up the
                             telephone collections process. A file is created for
                             the MELITA system, is derived from the CIS file
                             maintenance review of delinquent accounts and is
                             generated from the CIS. MELITA handles the
                             dialing of the customer’s account and then


LIPA
March 3, 2002
Page 25 of 26
Draft Version: 1.0




                             automatically presents a transaction window to the
                             Customer Representative when a person answers
                             the phone.
          MIC                The MIC file is a "collector" file for meter reads
                             and associated data including meter-reading
                             dates.
          Oracle Financial   Oracle application utilized by Revenue Processing
          Interfaces for     – General Ledger Package
          Revenue
          Reporting
          PEP+               Protocol for ACH transfers and Direct Debits

          Refund Check       The refund check system is a batch process,
          System             which prints and records checks made on return
                             deposits due to customers. The refund check
                             system facilitates the return of deposits made to
                             customers whose accounts have been finalized. .
          Bank Tec           Bank technology utilized for remittance processing
          Remittance         for KeySpan’s internal lockbox.
          Processing
          Equipment
          SAMM               SAMM is a subsystem within the CIS which is
                             invoked by the order creation screens for work
                             orders such as turn off, turn on, account changes,
                             in order to handle all of the in and out operations
                             for the CARDS pending file and the Customer
                             Relations SAMM file. The purpose of this
                             subsystem is to eliminate duplicate data entry.
          Street Lighting    CIS interfaces containing detail relating to Street
          Inventory          Lighting Inventory. The street lighting inventory
                             system is a reflection of the actual inventory,
                             which is kept on the customer master. Changes
                             to inventory will update the customer master file.
                             Small changes to inventory (9 or less lights) can
                             be made online.




LIPA
March 3, 2002
Page 26 of 26

								
To top