GISdevelopment.net ---> GITA 1998 ---> User Perspective

The middle age crises

Kevin W. Miller
AM/FM Application Coordinator
First Energy
253 White Pond Drive
Akron, Ohio 44320, USA


Abstract
FirstEnergy (FE) Experiences in the Transition from Development to Production. As the AM/FM project at FirstEnergy continues and the number of users and amount of data increase, the focus of effort necessarily begins to shift from conversion and development to support and maintenance. During this shift it is important to balance the resources of the project to maintain the conversion effort while providing for support requirements of the growing user population. Application development must also continue to provide the tools necessary for the efficient maintenance of the rapidly expanding database. This paper will discuss both the issues FE had planned for and the unforeseen issues FE encountered while changing the way GIS is thought of from a development and conversion effort to an enterprise solution. We will then generally discuss the solutions we have implemented or plan to implement as well as alternate solutions.

Introduction
FirstEnergy . is an electricity provider for more than 2.1 million customers over 13,500 square miles of Ohio and Western Pennsylvania. This company is a result of the recent merger of Centerior Energy and Ohio Edison Company. To streamline operations and improve customer service, Ohio Edison started development of a fully integrated AM/FM/GIS application in 1992. The intention of the project was to develop a system that would capture the benefits of automation for the operations areas of the company. The goal was to provide access to all pertinent company data within one system to improve customer service and operations effectiveness.

Like all utilities in this climate of deregulation, FirstEnergy is under going intense change. Their goal of becoming the best performing electric company in the region is driving this change at an even greater pace. Development of any system in this environment is a challenge. Developing a system like AM/FM/GIS, which affects many operational areas and corporate departments over a period of several years, presents challenges that require a very effective plan and hard work to overcome. FirstEnergy began its project with a very solid plan and has worked to follow it while adapting to changes from outside the project and unforeseen difficulties.

The Firstenergy Goal
The FirstEnergy Plan was to develop a system that would replace our existing paper mapping systems and assortment of facility databases with an automated digital mapping and facilities management system. We intended to leverage the latest technology to represent our facilities data graphically and geographically. We felt that it was important for the health of our database, to ensure the data is be kept current by making the system a fully integrated part of the operations work processes. We intended to have the data updated by the designers of new work as a part of the design and estimating process. We also planed to use the spatial power of our system to empower legacy corporate data. This was accomplished by creating ‘keys’ between legacy databases and our AM/FM/GIS which allow the legacy data to be geographically positioned and electrically connected.

The plan and adjustments
The time line below indicates the original work plan. We have attempted to remain on track with this plan although adjustments were necessary to address events for which we had not planned. In the following paragraphs I will discuss each element of the time line then the unexpected events and outcomes that required adjustments.


Figure 1. FirstEnerm Original Plan Time Line

FirstEnergy started following the AM/FM industry in the early 1980s and continued to follow the industry until 1987 when a study was conducted to determine feasibility. In 1991, the 1987 study was revisited and a pilot project was approved. A small team was assembled to work with consultants and a user committee to develop a plan which included:
  • Application Scope
  • Hardware and Software Selection
  • Database Design
  • Application development
  • Conversion
  • Data acceptance
  • Funding
  • Contingencies
At this time the team developed a system time line and implementation plan. This plan was very comprehensive and served us well during the project. The team addressed all foreseeable aspects of a successful implementation. The plan was also designed to sequence all aspects of the project so that the components were delivered when needed. The following is a brief description of the elements of the plan focusing on application development.

Pilot Project The pilot was intended to meet several requirements. The primary objective was proof of concept. The pilot included the conversion of a 50 square mile area of our service territory. A demo application was developed, at the same time, which could meet the requirements document qualifications. Issues related to conversion were addressed and a general plan for conversion was developed. At the end of the pilot the potential of the system was demonstrated for the user community and senior management. The project was given approval.

Begin Data Conversion Data conversion began in a relatively small and rural operating area comprising an area of approximately 300 square miles and 100,000 customers. This area was chosen for several reasons including availability of digital kmdbase, availability of digital facilities’ data, interest of area management in digital mapping, its relatively small size, and generally rural makeup. Conversion processes, partially worked out during the pilot, were completed and initiated at this time. This process required considerable attention to perfect in an interactive process that lasted through the conversion of the next operating areas converted.

Adjustments Data acceptance and data quality assurance processes were also developed at this time. This process was hampered by a lag in application development. We had converted data coming back from the conversion vendor that our application was not capable of adequately reviewing. This was one of the first unforeseen problems that required adjustments to our development plan. The earliest converted data eventually was reconverted to correct problems that could not be seen when it was initially delivered. As described below, we were forced to attempt to accelerate development of portions of the application that would facilitate data acceptance.

Development Amlication Tools for Data Acceptance and C)uality Assurance The first identified requirement for the application in the project cycle was data acceptance. A demo application had been developed for the proof of concept portion of the pilot. The intention was to discard this demo to start application development based on needs of a production environment and the requirements document.

Adjustments As described above we did not anticipate the need to have this portion of the application in place during the early phases of data conversion. Unfortunately, time pressures and the arrival of data forced us to recycle some of the code from this demo application. We used the code as a starting point to build the data acceptance tool we very badly needed.

Development Applications for the Gap Update Process and to capture new work Our conversion process involved freezing our existing paper maps after they were scrubbed for conversion. Maps that had been sent to the conversion vendor were not updated to reflect field work completed during this time. Designs for work completed after the maps were frozen were stored as paper documents so the AM/FM system could be updated after the data were received back from the conversion vendor. These designs were intended to be posted to the AM/FM databases during the ongoing Gap Update process.

Adjustments Once again application functionality lagged behind the conversion and the gap between the converted data and the work designs completed in the field grew larger than expected. We were again pushed to attempt to catchup application development to current project needs . This caused releases of the application that were not as stable or complete as would have been desired. We were forced to catch up even though we were on schedule with the original plan.

Develop Controlled Update Process At this point we had the components of the system in place to meet the needs of the data acceptance and basic data maintenance. Next we started building the tools and processes that would make it possible to integrate the system into the user normal work process. The first part of this involved building a controlled update component that would provide for a long transaction process integrated into the production database. It had always been our intent to have designers, planners/schedulers, and estimators (not drafters and mappers) update all facilities’ data in the database. This would allow us to capture database updates in the front of the normal work process and help to ensure the health of our data. At the same time the production view of the database would only reflect work completed in the field.

Because we had a wide variety of users updating the system it was more important to provide for a controlled update process. The process we developed included a final review process by a ‘super’ user responsible for the database integrity before updates to the system are committed to the production view of the data.

Adjustments During the entire life of the project we encountered the problem of having different areas on the company in different stages of conversion. While we were starting conversion of one area, there would be other areas in the middle of conversion and other areas with conversion completed and attempting to enter the gap update stage.

Still other areas were well into the gap update and ready to use the system for design. We had planned to implement the application one component at a time. This component release approach did not account for the fact that at any given point in time, portions of the company were completely converted.

Work Design The original plan had called for the development of work design fimctionality. The intention was to develop a closely integrated Power Builder application that would replace the functionality of our existing main frame based Automated Work Order System (AWOS). We were in that process and a Power Builder application, necessary to manage the database of compatible units used by AWOS and the new application, had been developed.

Adjustments It was at this time that the one of the most important unforeseen impacts on our project occurred. A company wide performance initiatives study was initiated to address looming deregulation. One of the focuses of the study was the operations areas of the company. This impacted our plan as it was identified that work planning and scheduling were in need of systemic improvements. The scheduling procedures in use at the time were not adequate to efficiently use the work force. The decision was made to obtain a complete work management package instead of just replacing the existing AWOS system. The system being developed is called the @stomer Request work Scheduling (CREWS) system. A pilot of the system with AM/FM integration was started in January 1998.

One impact of the expansion of the work design component from a simple estimation package into a complete work management system was the difficulty of maintaining team focus. The CREWS project was based in the same management support section as the AM/FM project. Because of the close integration, there was a lot of interaction between the two project teams. The CREWS project was a very large, if relatively short term project. Its start up required team changes and reorientation.

Another impact on our plan was that our users would need to wait for the work design and estimation fimctionality promised in the original plan. The result was that the AM/FM system was more difficult to present as a normal part of work flow. It was an extra step in the work processes of our users. It was also a step that required more time to complete than the old paper drafting of work prints.

When the CREWS system is implemented, the AM/FM system will be closely integrated. Work initiated in our Customer Information System (CIS will flow into the CREWS system. Work flowing through the CREWS system will be routed to AM/FM for design and estimation. AM/FM will produce a field work print and pass all the needed information to CREWS to create a face sheet, cost estimate, bill of materials, and plant accounting updates.

Engineering Analysis The interface to an engineering analysis package was not impacted and was developed on schedule. The interface and conversion functionality were completed primarily by the software vendor and only practices and processes needed to be completed by the AM/FM team. An analysis package was selected and the integration developed was a periodic one way conversion of AM/FM data into the format of the analysis package.

Interfaces to Other Legacy and New Comorate Systems Interfaces to key legacy information systems were developed earl y in the project. The diagram below illustrates integrations that were planned or implemented based on changing needs. Of the systems indicated in the diagram, only the CREWS and Engineering Analysis initial integrations are expected to remain intact. The CIS, Distribution Transformer Inventory System (DTIS), and Customer Trouble Call System (CTCS) applications will undergo changes requiring rework of the interface or integration strategies.

Adjustments This aspect of the project has been greatly impacted by the other major event in our company, the merger. In the merger transition process, all information systems were reviewed between the two companies and the system judged most suited for the ongoing operations of the FirstEnergy were selected.

The first system to be impacted is CIS. Due to this system not being year 2000 compliant and having a tabular front-end, the customer information system in use at Centerior Energy was chosen for use by FirstEnergy. The overall impact of this is small due the simple type of interface to CIS that was originally chosen, but development time has been expended to complete the changes necessary.

We expect that over time DTIS and CTCS will both be replaced or enhanced. This will mean that there will need to be a continuing process of strengthening integration to existing and upgraded systems. There will also be probable integration to new systems. Project Wrap UP The merger has also effected the project end phase. At the very least the data conversion will not be completed until the year 2000 instead of 1998 as planned. In addition, systems roll out will require an extra two years. As a part of the merger, operating groups are being split up and recombined. This effects the project implementation plan. The data, application servers, and data servers will need to be moved and rearranged. The differences in the way the two companies were operated and materials and equipment they used has required change two the legal values and additions to facilities’ tables.

Summary
An AM/FM/GIS project is always a long and difficult project to complete. It is not possible to address all possibilities in a project of this scope in the initial plan. Even in the more stable past, allowances would have been necessary for unexpected changes and problems. A plan that remains flexible will be helpful in dealing with the unforeseen problems, changes, and opportunities that will occur during the life of an AM/FM/GIS project. As the project proceeds, it is important to review the plan in light of the changes that are taking place at your organization while never loosing sight of the end result goal. A successful implementation will exploit the opportunities presented during a project, and take full advantage of your team’s and users’ developing understanding of the nature of AM/FM/GIS.

© GISdevelopment.net. All rights reserved.