| GISdevelopment.net ---> GITA 2001 ---> A Tangled Web of Pure Opportunity |
OMS for the Masses - A Web-based Approach
Scott Lowry
GPU Energy
2800 Pottsville Pike
Reading, PA 19640-0001
Paul Long
Red Planet Consulting
5445 Conestoga Court – Suite 5E
Boulder, CO 80301
Scott Lowry
GPU Energy
2800 Pottsville Pike
Reading, PA 19640-0001
Paul Long
Red Planet Consulting
5445 Conestoga Court – Suite 5E
Boulder, CO 80301
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:
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.
Project Background
Project initiation came about from a convergence of events. As stated previously, GPU had a need for new remote OMS functionality for the people in the district offices. BC Hydro, an electric utility in British Columbia, Canada, had the same need and had developed a web-based application to satisfy some of their remote OMS needs. With some negotiation, GPU was able to procure the application and use it as a starting point for their OMS development. Without this head start, the application would never have been implemented on time.
GPU had a very aggressive schedule for project implementation. Eight weeks from conception to going live - including a week for training. Program requirements needed to be determined, final functionality worked out, a team formed, and a lot of arm-twisting in order to get the team “buy-in” on the schedule. Surprisingly, the schedule was met and the system was ready for implementation on time. This would not have happened without a lot of hard work and dedication from the entire team.
GPU required a tool for remote users to monitor, update and close-out OMS projects. The tool needed to be both simple, yet provide functionality as a work management tool for local storm management. Also, the tool design and ultimate integration was to be consistent with GPUs organizational philosophy of local accountability for performance.
Smallworld was selected to co-develop the software in conjunction with GPUs IT staff. The tools needed to be “supported technology” rather than developed and supported in-house. Following development, the software would be piloted to insure performance prior to full rollout in the 59 operating districts.
Project Description
Technology & Architecture
As we already had a working application as our starting point and the schedule was very aggressive, the technologies to be used for the web application, now called PowerOn Remote, were essentially pre-selected for us.
The application is written as an Active Server Pages (ASP) application. ASP is a Microsoft server-side technology that allows web pages to be created dynamically by running a script (usually VBScript).
The traditional interaction between client browser and web server is:
The previous paragraph described the technologies used to deliver OMS data via web browsers. However, this is only one-half of the story. The real value of the application is the remote updating capability. Updating the OMS database using dispatching and restoration functions required a different set of tools. The OMS itself does not directly update its database tables via ODBC; it uses the GIS environment to perform updates to the database. The decision was made to use the new Smallworld Internet Application Server (SIAS) application as to mechanism to apply updates to the OMS database. This allowed us to call the same functions with the same data as the full-featured OMS.
The following diagram illustrates the technical architecture of the OMS system at GPU. The bottom area illustrates the standard OMS setup and its interaction with the OMS databases. The top area shows the new web-based application and its database interaction.
Poweron Remote Application
PowerOn Remote was developed in order to fill a gap in the GPU Energy emergency restoration process. The volume of data being processed and communicated in storm situations was too much for the DMCs to effectively handle. Additionally, the district offices held much of the local knowledge essential for efficient outage restoration. The goal was to provide a simplified OMS tool for the districts, which would enable them to better participate in the restoration process.
Requirements The business requirements for the application were simply to provide a tool to monitor, update, and close-out OMS project information from district offices. In order to satisfy these requirements, program functional requirements had to be flushed out. They are outlined below:
Based on the above requirements and on the existing functionality provided by the obtained application, the system was designed. Entry into the application was via the GPU Energy corporate intranet. Access to the application was granted based on the login id of the user. The initial panel of the application allows the user to select the projects they wish to see. They can select GPU zones, GPU districts, or view projects individually by project id or Customer Contact (CC) Notification number.
The list of projects satisfying the search criteria AND which have been assigned to remote users are then displayed. Projects are displayed in an HTML table. Each of the column headings is sortable. This is the primary panel for interacting with the system. Each of the projects is selectable individually or as a group. When selected, each project is displayed in a tabbed window. Tabs currently exist for:
Project Details
This panel displays detailed information about the project. It is displayed in a printable form for single page output. It is strictly a read only panel.
Trouble Calls
This panel displays a listing of all customer calls associated with the project. Columns are sortable.
Dispatch
This panel allows the dispatching of crews, the updating of customer care information (i.e. ETR and situation description), and the entering of comments. Dispatching information is seamlessly sent to the crew via mobile dispatch.
Restore
This panel allows the completion and closing of projects. All information required for restoration, completion, and close-out is filled in on this panel.
In addition to the above panels, a panel was developed in order to manage crews. Crew management takes the form of being able to set crews on and off duty, make them unavailable, and to edit their descriptions.
Training
User acceptance of any new technology is often the difference between achieving a desired result or being just another icon on a PC. Suddenly GPU had a technology that district operations needed and wanted. And before the next storm, which GPU experienced during the week, the web application was moved from a shared-server to a production quality server. During the storm heroic attempts were made to add “users in the heat of the battle.” No easy task, and while heroic, this was no way to introduce a new technology and have employees understand the underlying process changes which accompanied the new tool.
Objective based employee training was conducted to engage employees in the changes made to the emergency operations “work-flow” including the use of the web application. Also, all employees needed to understand their role in the emergency management process. To accomplish the process training to the 59 district locations, GPU utilized Interactive Distant Learning (IDL) satellite technology. Hands on user training were provided to 20-30 “power-users” in each of the four GPU Energy Regions. Power-users in turn had the responsibility for further training storm support teams within their Region.
What remained was to build employee confidence in the new tool and the workflow changes. To accomplish this remote dispatching would be performed by the district offices using the new application. This would give them familiarity in using the tool and better prepare them for storm situations.
Challenges
There are many challenges that any new application must face in the rollout phase. People issues, data quality issues, organization issues, technology issues, etc. all must be prepared for and dealt with. This section will examine some of these issues and explain how they were managed.
People
GPU engaged the involvement of field employees (Clerks, Front Line Supervisors, Call Center Reps, Engineers, Managers, etc.) in the original project concept, software testing, approval, training and ultimate integration of the product into the GPU culture. The concept team began with six employees and increased to 16 for system testing. Piloting the software in four locations again doubled the number of users. Each of these employees became a spokesperson for the tool, committing time and effort that has lead to employee acceptance.
Organization and Structure
Integration of the new technology has impacted both the DMC and district offices. Creating a tool that emphasizes local responsibility for escalated storm management has increased employee accountability. Also, in some rural Pennsylvania district offices, the tools availability for local dispatching has created a competition between the district and the DMC regarding dayshift crew management.
Current Usage
Process training has been completed and users trained in each of the four GPU geographical regions. With increased confidence and positive momentum the tool is utilized to support escalated events. Several districts have also continued with local dispatching of work.
Future Directions
The future possibilities of web-based OMS applications at GPU are enormous. Some application areas currently being considered include:
This project has demonstrated the power and simplicity of web-based applications development, implementation, and process integration. Meeting the aggressive time schedule was only possible through the concerted efforts of GPU IT staff, my co-presenter Paul Long of Red Planet Consulting, Randy Cough of Smallworld, and the original concept design team. As well, a word of thanks goes to Ivor Block, Manager T&D Information Systems at BC Hydro, for the sharing of PowerOn product experience.
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.
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.
Project Background
Project initiation came about from a convergence of events. As stated previously, GPU had a need for new remote OMS functionality for the people in the district offices. BC Hydro, an electric utility in British Columbia, Canada, had the same need and had developed a web-based application to satisfy some of their remote OMS needs. With some negotiation, GPU was able to procure the application and use it as a starting point for their OMS development. Without this head start, the application would never have been implemented on time.
GPU had a very aggressive schedule for project implementation. Eight weeks from conception to going live - including a week for training. Program requirements needed to be determined, final functionality worked out, a team formed, and a lot of arm-twisting in order to get the team “buy-in” on the schedule. Surprisingly, the schedule was met and the system was ready for implementation on time. This would not have happened without a lot of hard work and dedication from the entire team.
GPU required a tool for remote users to monitor, update and close-out OMS projects. The tool needed to be both simple, yet provide functionality as a work management tool for local storm management. Also, the tool design and ultimate integration was to be consistent with GPUs organizational philosophy of local accountability for performance.
Smallworld was selected to co-develop the software in conjunction with GPUs IT staff. The tools needed to be “supported technology” rather than developed and supported in-house. Following development, the software would be piloted to insure performance prior to full rollout in the 59 operating districts.
Project Description
Technology & Architecture
As we already had a working application as our starting point and the schedule was very aggressive, the technologies to be used for the web application, now called PowerOn Remote, were essentially pre-selected for us.
The application is written as an Active Server Pages (ASP) application. ASP is a Microsoft server-side technology that allows web pages to be created dynamically by running a script (usually VBScript).
The traditional interaction between client browser and web server is:
- A request is made from the client browser (i.e. Internet Explorer or Netscape) for a new web page (i.e. by following a link).
- The client browser locates the web server (i.e. gita.org).
- The web server locates the page requested and sends it to the browser.
- The browser renders the HTML for viewing and interaction.
The previous paragraph described the technologies used to deliver OMS data via web browsers. However, this is only one-half of the story. The real value of the application is the remote updating capability. Updating the OMS database using dispatching and restoration functions required a different set of tools. The OMS itself does not directly update its database tables via ODBC; it uses the GIS environment to perform updates to the database. The decision was made to use the new Smallworld Internet Application Server (SIAS) application as to mechanism to apply updates to the OMS database. This allowed us to call the same functions with the same data as the full-featured OMS.
The following diagram illustrates the technical architecture of the OMS system at GPU. The bottom area illustrates the standard OMS setup and its interaction with the OMS databases. The top area shows the new web-based application and its database interaction.
Poweron Remote Application
PowerOn Remote was developed in order to fill a gap in the GPU Energy emergency restoration process. The volume of data being processed and communicated in storm situations was too much for the DMCs to effectively handle. Additionally, the district offices held much of the local knowledge essential for efficient outage restoration. The goal was to provide a simplified OMS tool for the districts, which would enable them to better participate in the restoration process.
Requirements The business requirements for the application were simply to provide a tool to monitor, update, and close-out OMS project information from district offices. In order to satisfy these requirements, program functional requirements had to be flushed out. They are outlined below:
- The application shall present a list of all projects, similar to the OMS.
- As the number of projects being viewed may be large, the application shall be able to sort and filter the list of projects.
- Information displayed for each project shall be meaningful.
- More detailed information, which can be easily printed, shall be available for each project.
- The system must be able to “hand off” projects from the DMC to district offices. The DMCs will continue to maintain initial responsibility of projects and will perform analysis. They will assign projects to the districts as required.
- A list of trouble calls shall be viewable for each project.
- The application shall be able to dispatch crews to projects.
- The application shall be able to update information about projects in progress to support the Call Center (i.e. estimated time of restoration (ETR), comments, and situation description).
- The application shall be able to enter all required completion information for a project and be able to close-out projects.
- The application shall be able to perform simple crew update functions (i.e. put crews on/off duty).
- The application shall be able to indicate status for each crew.
- The application shall not be available to everyone. Security factors need to be considered.
- The application shall fit seamlessly into the current data flows.
Based on the above requirements and on the existing functionality provided by the obtained application, the system was designed. Entry into the application was via the GPU Energy corporate intranet. Access to the application was granted based on the login id of the user. The initial panel of the application allows the user to select the projects they wish to see. They can select GPU zones, GPU districts, or view projects individually by project id or Customer Contact (CC) Notification number.
The list of projects satisfying the search criteria AND which have been assigned to remote users are then displayed. Projects are displayed in an HTML table. Each of the column headings is sortable. This is the primary panel for interacting with the system. Each of the projects is selectable individually or as a group. When selected, each project is displayed in a tabbed window. Tabs currently exist for:
Project Details
This panel displays detailed information about the project. It is displayed in a printable form for single page output. It is strictly a read only panel.
Trouble Calls
This panel displays a listing of all customer calls associated with the project. Columns are sortable.
Dispatch
This panel allows the dispatching of crews, the updating of customer care information (i.e. ETR and situation description), and the entering of comments. Dispatching information is seamlessly sent to the crew via mobile dispatch.
Restore
This panel allows the completion and closing of projects. All information required for restoration, completion, and close-out is filled in on this panel.
In addition to the above panels, a panel was developed in order to manage crews. Crew management takes the form of being able to set crews on and off duty, make them unavailable, and to edit their descriptions.
Training
User acceptance of any new technology is often the difference between achieving a desired result or being just another icon on a PC. Suddenly GPU had a technology that district operations needed and wanted. And before the next storm, which GPU experienced during the week, the web application was moved from a shared-server to a production quality server. During the storm heroic attempts were made to add “users in the heat of the battle.” No easy task, and while heroic, this was no way to introduce a new technology and have employees understand the underlying process changes which accompanied the new tool.
Objective based employee training was conducted to engage employees in the changes made to the emergency operations “work-flow” including the use of the web application. Also, all employees needed to understand their role in the emergency management process. To accomplish the process training to the 59 district locations, GPU utilized Interactive Distant Learning (IDL) satellite technology. Hands on user training were provided to 20-30 “power-users” in each of the four GPU Energy Regions. Power-users in turn had the responsibility for further training storm support teams within their Region.
What remained was to build employee confidence in the new tool and the workflow changes. To accomplish this remote dispatching would be performed by the district offices using the new application. This would give them familiarity in using the tool and better prepare them for storm situations.
Challenges
There are many challenges that any new application must face in the rollout phase. People issues, data quality issues, organization issues, technology issues, etc. all must be prepared for and dealt with. This section will examine some of these issues and explain how they were managed.
People
GPU engaged the involvement of field employees (Clerks, Front Line Supervisors, Call Center Reps, Engineers, Managers, etc.) in the original project concept, software testing, approval, training and ultimate integration of the product into the GPU culture. The concept team began with six employees and increased to 16 for system testing. Piloting the software in four locations again doubled the number of users. Each of these employees became a spokesperson for the tool, committing time and effort that has lead to employee acceptance.
Organization and Structure
Integration of the new technology has impacted both the DMC and district offices. Creating a tool that emphasizes local responsibility for escalated storm management has increased employee accountability. Also, in some rural Pennsylvania district offices, the tools availability for local dispatching has created a competition between the district and the DMC regarding dayshift crew management.
Current Usage
Process training has been completed and users trained in each of the four GPU geographical regions. With increased confidence and positive momentum the tool is utilized to support escalated events. Several districts have also continued with local dispatching of work.
Future Directions
The future possibilities of web-based OMS applications at GPU are enormous. Some application areas currently being considered include:
-
Enhanced Reporting
Concepts are under development to expand Internet reporting of outages and to support overall storm management reporting needs. There are various web-based reporting packages that seem promising in delivering high quality reports with less impact on the operational environment. Reporting can include delivering high value data to both internal and external organizations. The general public can be informed of outage status, expected restoration time, cause, etc. via the internet. Specialized reports can be provided to 911 emergency centers, public officials, sensitive customers, and the media. Internally, web reports can be used to communicate outage activity, events, and unique system incidents to call center personnel. Executives and management can be given summary reports from a company, regional, and a district level with drill-down capability.
- Maps
Currently, maps are not being used in this web application. Maps have great potential as decision-making and communication aids. Detailed location and feeder maps can help in the remote analysis stage of an outage. They can act as a reporting aid in delivering summarized location information on outages. High impact summary maps shading areas by number of outages or number of customers without power are all ways in which maps can help in decision making and communications.
- Enhanced Update Capability
The level of update capability is quite a bit simpler in the web application than in the main OMS. This was done partly because of the aggressive schedule but also because of the requirement to keep the application simple. Any increase of the level of update capability will have to be balanced with the need to keep the application easy to use. One area where additional functionality is required is in the area of confirming outages.
This project has demonstrated the power and simplicity of web-based applications development, implementation, and process integration. Meeting the aggressive time schedule was only possible through the concerted efforts of GPU IT staff, my co-presenter Paul Long of Red Planet Consulting, Randy Cough of Smallworld, and the original concept design team. As well, a word of thanks goes to Ivor Block, Manager T&D Information Systems at BC Hydro, for the sharing of PowerOn product experience.