GISdevelopment.net ---> GITA 1999 ---> System Architecture

Distribution utility enterprise integration - A new paradigm

Chuck Howard
President, IT Project Manager
Geographic Information Technology, inc.
101 Inverness Dr. East, Suite 130
Englewood, Colorado 80112
Phone: 303-708-9352
Fax: 303-708-9356
E-mail: choward@,geoit.com

Andy Schlegel
GPU Energy, 2800 Pottsville Pike
Reading, Pennsylvania 19640-0001
Phone: 610-921-6487
Fax: 610-939-8516
E-mail: aschlegel@m u.com


The paradigm shift

What Has Charuzed?
If a paradigm shift is a change so great, that we need to rethink the way we frame our questions, not just how we respond to them, then one is occurring in the North American utility right now. The change is pervasive, and it would take longer than this session allows for us to examine it carefully, so we will narrow our focus on the information technology part of the change. At the center of the change is utility acceptance of enterprise resource planning (ERP) concepts and products. Five years ago, it would have been hard for anyone to believe that any utility would be replacing all their major business systems; customers, work, materials, financial, human resources, at the same time in favor of a single product to meet these systems critical needs. Yet today, the sales figures from providers like ERP, People Soft, and Oracle tell us that over 200 utilities worldwide have started down that path. This change has had a big impact on AM/FM/GIS project and products; mostly positive.

Why The Change
There are many reasons for the change occurring now. However, four stand out above the rest: the move to open competition among utilities, the millennium bug, a need for more integrated solutions, and downsized IT staffs. Competition has driven executive to realize that problems associated with the business can not longer be addressed by increasing staffs. The must be resolved with more efficient work processes supported by good tools; including IT tools. The Y2K issue arose during the struggle to identify solutions for the first. When faced with the risks and the costs for these first two issues, complete replacement began to seem feasible. The ERP vendors then had two very appealing messages; a single solution to all these systems requirements will produce a more integrated result, and product solutions require far less IT support than do designware based or custom developed solutions.

The integration promise is perhaps the one that has had the most impact toward supporting the paradigm shifi. Executives have known for years that they have paid a price for the loose integration of their legacy systems. They are demanding more today. Many of the companies making the change feel so strongly about the value of more integrated solutions that they have allowed only minimal input from the people who used to decide what products would be purchased. They feared that people lower in the organization would value integration less than best of breed functionality.

Impact on AM/FM/GIS
There has been an impact on AM/FM/GIS implementations. In a few cases, projects were delayed due to budget constraints. However, more often than not, ERP initiatives have helped get GIS projects approved. When executive decide spend the money to do ERP, it becomes apparent that GIS is complementary and can be done about ten percent more. In short, GIS looks small by comparison to ERP.

The other noticeable impact is that when GIS is done with ERP, a higher level of integration is expected, with both ERP and other systems such as outage management. Many executives want to see tight integration among all systems that service the field work force and those systems being a "bolt-on" to ERP. This is a whole new challenge for AM/FM/GIS projects. It demands careful planning and knowledge of the ERP function and interface points.

GPU Energy has implemented a filly integrated solution of ERP, GIS, Outage Management, and Mobile Dispatch. They have done it in a very short time. We have a lot to learn from their experience.

The GPU energy experience
GPU Energy is made up three companies that operated under the names of JCP&L - Jersey Central Power & Light Co., Met-Ed - Metropolitan Edison Co., and Penelec - Pennsylvania Electric Co. These companies combined serve 2.1 million customers and 24,000 square miles of service territory.

Where Are We Today
Because of operating under three different companies we currently have three different IBM GFIS systems, and three different Graphic update environments. The systems are all basically the same, but each has their own uniqueness that causes each to be different. We also maintain multiple different legacy databases for each company such as transformer records, property records, joint use, and street light. Each company also has their own operating procedures, which is often even harder to change into one system. Most important of where we are today is that the systems are NOT INTEGRATED.

Where Are We Going
We are currently in the midst of moving to a completely different platform and are planning to be implemented by the GITA conference. Where we are going is listed below: Smallworld GIS - Convert from IBM GFIS to Smallworld ERP- SAP R/3 - Enterprise wide solution for all applications Disconnect - Tie to SAP with our GIS objects CH Expert Design - On-Line Design system Smallworld PowerOn - New outage management system MDSI - Computer Assisted Dispatch INTEGRATED In the following sections we will relate the experiences we have gained by implementing each of these products and the impact it has when trying to do it with an ERP such as SAP.

The first hurdle for GPU in moving to the new GIS was to make a common model. This included first understanding the three different models and then combining them into one model. This was complicated by the fact that we were implementing an ERP at the same time and had to insure that both systems were kept in sync. The next problem encountered was moving away from the point connector model and using a more graphical model. This was not an easy move for our developers and users of the system. It was very hard early on during conversion to understand how the model worked and how it was being converted. Early on we did not have tools to provide us help in determining if our data was being converted correctly.

Enterprise Resource Planning
The implementation of our ERP system was based on process flows more so than data requirements. This proved to be a problem and a blessing for the GIS team. While it was fmstrating in that we were not being provide with data requirements when they finally decided it was time to concentrate on data we provided them with our model. The other aspect of the ERP team was that they were working on new business procedures while requiring old procedures for day one implementation. This was mostly a focus problem in that we needed to know what was required for implementation rather than where we were going in the future. There is a fine line between spending time looking into the future and insure that what you are planning to implement will meet those requirements and what is needed day one.

The second issue of ERP implementation that had indirect impacts on the GIS implementation was the need to load data from the legacy databases and then integrates it with GIS. The three different operating companies had varying forms of integration from none to some. This caused concern on how resolve the differences in the databases and who was the driver of the data. A decision was made early that the GIS data was the driver and it would be utilized as the base to match against the legacy databases. Now it was a matter of how to match the different systems with the GIS data and then what data could be utilized.

GISConnect
Disconnect is a solution for ERP/GIS Integration. It is a piece of software that through configuration allows you to link your GIS object to the technical equipment objects in ERP. These objects in our case were decided upon to be the capitalized units. The biggest issue we had with this process is the knowledge base available on the product. The product has been implemented in other countries, but had not been implemented in the United States and we had a very limited knowledge base to work with early on. The other issue here was that it was integrating different data models. We were a facility based electrical model system and ERP was trying to implement a costing and property records model. A key decision early on here and one that was hard fought was to not try and model the electrical network within ERP. Allow the GIS to keep themodel and only provide ERP with the attributes required for their model. This decision does require that the GIS can provide the required network reporting through the use of GISConnect.

On-Line Desian
We are implementing an On-Line Design system which will be utilized by our 180 designers in 60 different locations. This product will provide us with: Design alternatives
Quick and consistent layout of GIS facilities and changeouts
Integrates the data maintenance process
Generates design order, and cost estimate reports.
It will be integrated with the ERP Work Management system to provide: List of jobs for the designer to work on
Creation of FERC settlement rules
Material lists
Estimated costs/hours
The magic of On-Line Design lies in the compatible unit library and provides: Rule base association of compatible units to facilities
Provides macro unit functionality
Recognizes cost at compatible unit level
Supports multiple cost (dead, gloved, stick) and activity types (install, retire, transfer)
Easy data loads for data maintenance
We will also be utilizing the On-Line Design system as our tool for integrating the GIS objects with the ERP technical equipment. This will provide us the following: Defining the objects that need to go to ERP
Needs to handle serialized equipment
Roll forward facility status
Delete GIS facilities no longer required
Clean up GIS alternatives
The biggest issue in implementing On-Line Design is the Work Management interface. We had a difficult time getting the requirements for the interface detailed. The ERP team did not have the details required for this interface until late in the project, which delayed work on this effort. The Disconnect product was going to provide the functionality required, but was going to be specialized code. We also had to insure that the GIS data model was consistent with the ERP data model for the fields we were going to keep in sync.

OMS - Outage Management System
During the early stages of our Outage Management system design phase we switched vendors. This created some confusion early on and delayed the detailed design until we understood what the new OMS product would include, how it would work, and knowledgeable personnel on the product. We also were looking to interface this product with ERP Customer Care System (CCS) which also was difficult in getting the details of this system since it was still in a design phase. The system will be integrated with our ERP Front Office product and the ERP Work Management product and will handle all trouble and street light orders. We are planning on dispatching both of these types of orders using the OMS product and also have it interface with our Computer Aided Dispatch system. The detailed knowledge of the system architecture of ERP was the biggest stumbling block that we encountered in the integration of these systems.

Computer Aided Dispatch.
We are implementing Computer Aided Dispatch as part of the overall project. We will dispatch trouble calls and streetlight orders to 65 trouble trucks mostly in New Jersey. This project started prior to the decision to go with the OMS product and months before the details were known of what ERP required for trouble and street light orders. They were going on the impression that whatever data they collected in the field manually, they should collect using the mobile data terminals. This proved to be troublesome when you needed to integrate this system not only with OMS, but ERP. Even though the data was being collected in the field, there was not always a clean data stream back to ERP. We had to reevaluate the scope of this product and insure that it would work with OMS and ERP implementation.

The schedule
From the beginning of the project we had a very aggressive schedule to implement the various products along with ERP. The initial kick-off of the project was October of 1997 with it really not getting underway until late November. The team was initially two different project teams being the GIS and Outage Management teams with two different implementation partners. This was later changed to one team and was also integrated into the ERP project team. The plan is detailed below: November 98- Start data conversion from GFIS to new GIS.
February 98- Map Maintenance using new GIS and ERP integration
March 98- Online Design going live in field
March 98 -Go live with OMS using legacy CIS system for trouble calls only
June 98 -Go live with OMS interfaced with ERP CCS and WM
June 98 -Go live with CAD interfaced with OMS
Conclusion
The conclusion to all of this is Don't Go Swimming Alone. Insure that you take a buddy with you or in this case insure that you have a lot of buddies with you. We believe we have a created a team of buddies that have our best interests in mind. We are utilizing GEOIT as our implementation manager for both the GIS and OMS projects and they are also providing us with technical and architectural resources. Our On-Line Design vendor is providing us technical assistance along with implementation management for their products. We have another vendor providing the conversion services along with technical assistance for the Disconnect product. We feel they all are working with our development staff to create a project team that is working on a project that will make GPU Energy a leader in the ERP and GIS integration.
© GISdevelopment.net. All rights reserved.