OMS for the Masses - A Web-based Approach

Background

GPU Energy
GPU Energy is an electric utility operating in New Jersey and Pennsylvania. The company serves more than two million customers providing approximately 44 billion kilowatt-hours of electricity. GPU Energy is comprised of three existing electric utilities: Jersey Central Power & Light (JCP&L), Metropolitan Edison Company (Met-Ed), and Pennsylvania Electric Company (Penelec).

Two Distribution Management Centers (DMC) at GPU Energy support distribution operations in the service territory covering approximately one-half of the land mass of Pennsylvania and New Jersey. One DMC is located in Reading, Pa covering 24,000 square miles and 45 counties. The second DMC serves the NJ territory consisting of 3500 square miles and 13 counties.

Emergency restoration crews, consisting of line and substation employees are located at 59 district offices.

Restoration Process
The restoration process at GPU is focused on the efficient restoration of trouble, emergency, and outage projects. The restoration process includes a number of organizations:

Call Center
Answers customer calls, enters trouble incidents, and acts as the contact between GPU and the general public.
Distribution Management Center (DMC)
The two DMCs are responsible for supporting distribution operations. This includes analysis of the trouble situations, dispatching crews, and assuming responsibility for outage restoration.
District Offices
The 59 district offices are the front line of power restoration and are the “face” of GPU in most communities.
Customer Focus Organization
This organization is an internal organization representing the local service areas politically. They are responsible for dealing with sensitive customers, major customers, and for handling media inquiries.

Outage management at GPU Energy is composed of a number of large, complex systems. These systems are all completely integrated and data flows seamlessly between them. Customer calls come in either via an interactive voice response (IVR) unit or directly to Call Center agents. The agents, or IVR, attempt to give the customer as much information as possible without their call being passed into the PowerOn outage management system (OMS). The call details are entered into the SAP system, and from there, depending on the nature of the call, the call is passed into the OMS system. The OMS analyzes the calls and, using network data from the Smallworld GIS system, groups the calls based on network connectivity and call type. Restoration supervisors further analyze the calls and perform crew dispatching using the OMS. Crew communications is either handled through the MDSI mobile dispatch system or through more traditional methods of cell phone or radio. Dispatching through the mobile dispatch system is an automated process. Once the crew receives the project, they locate, diagnose, and fix the outage and report details back to the DMC or the district office. Projects are then updated in the OMS with the pertinent restoration details and sent on to SAP for disturbance recording and automated customer callbacks.

During normal operations, the DMCs dispatch and complete emergency, outage, and trouble projects utilizing the OMS system. During routine trouble, the volume of communication is manageable; however, in a multi-district or a growing event, managing these communications became a barrier to meeting expected service levels and contributed to employee frustration. An escalating “storm” event requires district offices to be opened to manage the event locally, including the dispatching of projects. District employees use MS Access reports generated from the OMS database containing a list of open projects, the predicted operating device, and customer calls associated with the project. Projects are then dispatched from these reports. Repair crews would complete the field work and communicate close-out information to the local district office who in turn would fax the completed paper order back to one of the two centralized DMC centers for project completion in the OMS. This type of information transfer contributed to poor communication of close-out information and delays in project completion in OMS. Anytime a project isn’t immediately closed in OMS, IVR callbacks are delayed, customer outage counts are overstated, and potential for duplicate projects arise. Employees in a local district office required a tool to monitor, update, and close-out OMS projects at a local level.

The purpose of this paper is to describe the process GPU Energy went through in creating and deploying a web-based application that would allow remote district offices to take a more active role in storm related outage restoration. This includes the background to the project, the need for the application, the functional requirements that needed to be met, the technology used, challenges met during training and implementation, and finally, a look down the road on additional functionality the application may take on.