| GISdevelopment.net ---> GITA 1999 ---> Enterprise Resource Planning |
GIS Integrated with ERP: A Case Study
John Gartside
Principal Consultant
GeoData Solutions, Inc.
10075 Westmoor Drive, Suite 200
Westminster, CO 80021 USA
Phone: (303) 635-0500
Fax: (303) 635-0510
Email: JGartside@GeoDataSolutions.com
Noel Couturiaux
Senior Engineer
GPU Energy
PO BOX 16001
Reading, PA 19640 USA
Phone: (61 O) 921-6361
Fax: (610) 939-8516
Email: ncouturiaux@gpu.com
John Gartside
Principal Consultant
GeoData Solutions, Inc.
10075 Westmoor Drive, Suite 200
Westminster, CO 80021 USA
Phone: (303) 635-0500
Fax: (303) 635-0510
Email: JGartside@GeoDataSolutions.com
Noel Couturiaux
Senior Engineer
GPU Energy
PO BOX 16001
Reading, PA 19640 USA
Phone: (61 O) 921-6361
Fax: (610) 939-8516
Email: ncouturiaux@gpu.com
Introduction
In 1997, GPU Energy made a decision to change the way the company operates. The proposed changes would affect virtually everyone in the organization. This task seemed quite daunting in most respects, and GPU needed everyone’s help to make it happen.
It was determined early on that technology could provide the necessary tools to make this transition successful. While evaluating systems during the initial stage, GPU determined that SAP@ R/3TM could provide most of the necessary components for the new organization.
However, this type of system was missing a key component that could help GPU manage assets effectively while streamlining the record-keeping process. A geographical information system (GIS) could provide this missing component while giving users the ability to link work activities, estimates, and design data.
Many of the new work processes being developed required this type of information, so it became very apparent that integrating GIS and SAP R/3 was one of the keys to making this a successfid transformation.
This paper discusses some of the technical issues related to successfully implementing this integration while outlining the key steps necessary to tie these two very powerfhl systems together.
History
As a result of the major initiative for GPU, the RSR (Rapid Service Response) Project was created. This project would encompass a business redesign component and a technology component that would allow GPU Energy to make the change happen.
Several initiatives would have to take place prior to implementation. GPU would need to migrate several legacy systems that would provide for rapid implementation of a new GIS. FMIS was GPU’S legacy GIS, based on the GFIS/CableCAD platform. GPU selected Smallworld as the new platform, and a large migration project would convert FMIS to Smallworld.
At the same time, GPU was evaluating a new system that would replace several other legacy systems dealing with work management, accounting, outage management, and human resources. The system of choice for this direction was SAP R/3. Early on it was evident that integrating the new GIS and SAP R/3 would be critical.
Integrating SAP and GIS
During the infancy stages of this project, there were not a lot of options for linking SAP R/3 with a GIS. A company in Germany-ivl GmbH—had successfidly integrated Smallworld with SAP R/3, using a product they had developed called GISConnectTM. (The architecture employed for this technology will be discussed later in this paper.) At the time, this was the only product on the market that could perform this integration. Disconnect also had a very good track record in Europe and Australia. Therefore, in order to support the technical requirements of the project, GPU elected to use Disconnect to perform the integration.
Three primary tasks make up the effort to successfully implement such a strategy. The first step is to conllgure the product. The second step is to provide an index on all data that will have corresponding information in both SAP R/3 and the GIS. The third step is to customize any applications that will use data from both systems.
In the first step, Disconnect configuration deals with identifying the GIS classes and their corresponding SAP R/3 classes. In most cases, class names are different, and sometimes formats are different as well. The configuration utility allows the user to select the classes and the attributes the two systems will interact with.
GPU configured the equipment classes in SAP FU3 with the corresponding GIS classes in the GIS, such as poles, transformers, and conductors. They then identified each field in these classes that would be viewable from both systems and which would be redundant between the systems, as well as the rules for edits concerning which system had update ability and which had only view privileges.
The configuration module allows one to perform the necessary steps to configure a combined GIS/SAP R/3 data model. GIS and SAP R/3 object classes are mapped to each other and SAP IU3 fields of these SAP R/3 classes are made visible in the corresponding GIS object class. Other functions include the definition of field redundancy, editor layout, read-only fields’ set-up etc.
Figure 1. Configuration Menu from within Smallworld
After selecting the corresponding SAP R/3 object class for the GIS object class, the configuration on the attribute level follows from here.
Disconnect configuration data are stored in the GIS data dictionary and are therefore fully version managed. Optionally, the data can also be uploaded into the CASE datastore.
Once the objects are configured, access to SAP R/3 data is transparent to the GIS users. Options to view the SAP IU3 pages are accessed from the Smallworld editors as illustrated in the following figure.
Figure 2. GIS and SAP R/3 Data Viewable from Smallworld Editors
The configuration process indicates which field will be viewable from the GIS as well as the rules for updating the information. Some fields can be updated only from the GIS, and others can be updated only from SAP IU3.
The second step was to create the proper index between the two systems for the configuration to work. Disconnect uses the SAP R/3_ID field to link objects together. Therefore, a strategy for building these links needed to be developed. The data sets being used for this project had several origins.
The strategy used at GPU would capitalize on a unique numbering system used in GPU’S legacy GIS. An attribute called “pole_key” would allow the indexing process to search for corresponding objects in both systems. As the GIS data were migrated from GFIS to Smallworld, the pole_key was retained to keep this relationship intact.
As data were populated in SAP, this same strategy was used to retain these relationships. As objects were populated in both systems, internal numbers were assigned and used to establish the index that Disconnect would use to link up the information.
As data were loaded and indexes created, GPU performed extensive QC/QA checks to ensure both systems had corresponding objects. Mismatches were identified and resolved as the migrationhmslation process proceeded, or they were resolved over time depending on the magnitude.
The third step for implementing the system was to customize interfaces that would take advantage of this capability. The initial effort focused on integrating some of the work management tools in SAP with the GIS. Several design tools exist in the GIS, and designers needed to retrieve notifications and job requests from SAP.
Other customizations included the ability to maintain GIS data outside the design tool functionality. Methods were written to ensure that changes in the GIS that affect the SAP objects would pass the corresponding transaction to SAP to force the synchronization between the GIS and SAP.
Now that the three steps have been accomplished, access to SAP FU3 data is offered through standard Smallworld query tools. This provides a very powerful capability that is not offered by standard SAP R/3 functionality. The following figure demonstrates the ability to retrieve notification records from SAP IU3 by querying the graphics in Smallworld.
Figure 3. SAP R/3 Notification Retrieval from GIS
This capability will allow GPU Energy to retrieve or create notification records in SAP R/3 by querying the GIS from a trail point or a network trace. This is a good example of how integration of these two systems provides value-added capabilities.
Requirements for an Integration Architecture
Integration on the database level attempts to build a virtual database containing object records that are composed of one GIS record and one SAP R/3 record. As shown in the figures above, SAP FU3 fields are just normal fields; therefore, it should not matter that the field contents are remotely stored in the SAP R/3 database and not in the GIS.
This layer of integration is the basis for network representation, design jobs, and also further integration on the business process level. An implementation of such a virtual database must meet several important requirements:
Figure 4. GIS versus SAP R/3 GUIs
Conclusion
GPU Energy looked to technology to help accomplish the goal of its enterprise-wide change program. Thekeyingredient forthis chagewas thepeople of GPUEnergy, equipped titithe proper tools to get the job done.
The integration of SAP R/3 with Smallworld was proven early on to deliver bottom-line benefits while enabling the technology to have a combined capability not offered by each system individually.
It was imperative that business work flows be provided with adequate and timely data to complete work orders. For this to be successfid, two main integration pieces had to come together. First, virtual database integration allows the GIS and SAP R/3 data models to be treated logically as a single model, enabling sophisticated planning features for SAP R/3 data. The second piece, business process integration, offers complex business processes freely spread over GIS and SAP R/3. In many situations it makes sense to extract data in GIS and pass them as input data to SAP R/3 (and vice versa). GIS features such as network tracing can be utilized as special pre-processing tools for SAP R/3, allowing both systems to concentrate on their strengths, and eliminating the other system’s weaknesses by cooperation at the business process level.
References
In 1997, GPU Energy made a decision to change the way the company operates. The proposed changes would affect virtually everyone in the organization. This task seemed quite daunting in most respects, and GPU needed everyone’s help to make it happen.
It was determined early on that technology could provide the necessary tools to make this transition successful. While evaluating systems during the initial stage, GPU determined that SAP@ R/3TM could provide most of the necessary components for the new organization.
However, this type of system was missing a key component that could help GPU manage assets effectively while streamlining the record-keeping process. A geographical information system (GIS) could provide this missing component while giving users the ability to link work activities, estimates, and design data.
Many of the new work processes being developed required this type of information, so it became very apparent that integrating GIS and SAP R/3 was one of the keys to making this a successfid transformation.
This paper discusses some of the technical issues related to successfully implementing this integration while outlining the key steps necessary to tie these two very powerfhl systems together.
History
As a result of the major initiative for GPU, the RSR (Rapid Service Response) Project was created. This project would encompass a business redesign component and a technology component that would allow GPU Energy to make the change happen.
Several initiatives would have to take place prior to implementation. GPU would need to migrate several legacy systems that would provide for rapid implementation of a new GIS. FMIS was GPU’S legacy GIS, based on the GFIS/CableCAD platform. GPU selected Smallworld as the new platform, and a large migration project would convert FMIS to Smallworld.
At the same time, GPU was evaluating a new system that would replace several other legacy systems dealing with work management, accounting, outage management, and human resources. The system of choice for this direction was SAP R/3. Early on it was evident that integrating the new GIS and SAP R/3 would be critical.
Integrating SAP and GIS
During the infancy stages of this project, there were not a lot of options for linking SAP R/3 with a GIS. A company in Germany-ivl GmbH—had successfidly integrated Smallworld with SAP R/3, using a product they had developed called GISConnectTM. (The architecture employed for this technology will be discussed later in this paper.) At the time, this was the only product on the market that could perform this integration. Disconnect also had a very good track record in Europe and Australia. Therefore, in order to support the technical requirements of the project, GPU elected to use Disconnect to perform the integration.
Three primary tasks make up the effort to successfully implement such a strategy. The first step is to conllgure the product. The second step is to provide an index on all data that will have corresponding information in both SAP R/3 and the GIS. The third step is to customize any applications that will use data from both systems.
In the first step, Disconnect configuration deals with identifying the GIS classes and their corresponding SAP R/3 classes. In most cases, class names are different, and sometimes formats are different as well. The configuration utility allows the user to select the classes and the attributes the two systems will interact with.
GPU configured the equipment classes in SAP FU3 with the corresponding GIS classes in the GIS, such as poles, transformers, and conductors. They then identified each field in these classes that would be viewable from both systems and which would be redundant between the systems, as well as the rules for edits concerning which system had update ability and which had only view privileges.
The configuration module allows one to perform the necessary steps to configure a combined GIS/SAP R/3 data model. GIS and SAP R/3 object classes are mapped to each other and SAP IU3 fields of these SAP R/3 classes are made visible in the corresponding GIS object class. Other functions include the definition of field redundancy, editor layout, read-only fields’ set-up etc.
Figure 1. Configuration Menu from within Smallworld
After selecting the corresponding SAP R/3 object class for the GIS object class, the configuration on the attribute level follows from here.
Disconnect configuration data are stored in the GIS data dictionary and are therefore fully version managed. Optionally, the data can also be uploaded into the CASE datastore.
Once the objects are configured, access to SAP R/3 data is transparent to the GIS users. Options to view the SAP IU3 pages are accessed from the Smallworld editors as illustrated in the following figure.
Figure 2. GIS and SAP R/3 Data Viewable from Smallworld Editors
The configuration process indicates which field will be viewable from the GIS as well as the rules for updating the information. Some fields can be updated only from the GIS, and others can be updated only from SAP IU3.
The second step was to create the proper index between the two systems for the configuration to work. Disconnect uses the SAP R/3_ID field to link objects together. Therefore, a strategy for building these links needed to be developed. The data sets being used for this project had several origins.
The strategy used at GPU would capitalize on a unique numbering system used in GPU’S legacy GIS. An attribute called “pole_key” would allow the indexing process to search for corresponding objects in both systems. As the GIS data were migrated from GFIS to Smallworld, the pole_key was retained to keep this relationship intact.
As data were populated in SAP, this same strategy was used to retain these relationships. As objects were populated in both systems, internal numbers were assigned and used to establish the index that Disconnect would use to link up the information.
As data were loaded and indexes created, GPU performed extensive QC/QA checks to ensure both systems had corresponding objects. Mismatches were identified and resolved as the migrationhmslation process proceeded, or they were resolved over time depending on the magnitude.
The third step for implementing the system was to customize interfaces that would take advantage of this capability. The initial effort focused on integrating some of the work management tools in SAP with the GIS. Several design tools exist in the GIS, and designers needed to retrieve notifications and job requests from SAP.
Other customizations included the ability to maintain GIS data outside the design tool functionality. Methods were written to ensure that changes in the GIS that affect the SAP objects would pass the corresponding transaction to SAP to force the synchronization between the GIS and SAP.
Now that the three steps have been accomplished, access to SAP FU3 data is offered through standard Smallworld query tools. This provides a very powerful capability that is not offered by standard SAP R/3 functionality. The following figure demonstrates the ability to retrieve notification records from SAP IU3 by querying the graphics in Smallworld.
Figure 3. SAP R/3 Notification Retrieval from GIS
This capability will allow GPU Energy to retrieve or create notification records in SAP R/3 by querying the GIS from a trail point or a network trace. This is a good example of how integration of these two systems provides value-added capabilities.
Requirements for an Integration Architecture
Integration on the database level attempts to build a virtual database containing object records that are composed of one GIS record and one SAP R/3 record. As shown in the figures above, SAP FU3 fields are just normal fields; therefore, it should not matter that the field contents are remotely stored in the SAP R/3 database and not in the GIS.
This layer of integration is the basis for network representation, design jobs, and also further integration on the business process level. An implementation of such a virtual database must meet several important requirements:
- Transparent access to SAP R/3 data means the GIS user has read and write access to SAP R/3 objects; that is, the GIS user can display or update SAP R/3 data or even create new SAP R/3 records. Write access to SAP IU3 records is quite complex, as SAP R/3 knows only short-term transactions and does not support version management.
- For design alternatives, the GIS must be able to buffer planned SAP FU3records in a GIS alternative. Once a design alternative is posted, the planned SAP R/3 records have to be replaced by newly created real SAP IU3 records.
- Despite integration, GIS and SAP IU3 will always contain some remaining redundant data due to performance reasons. This redundancy must be controlled so that no inconsistency can occur.
- The user must have access to queries that refer to GIS as well as SAP FU3 attributes. An integration on the database level is an excellent basis for further integration of business processes, as one need not deal with data access and transaction synchronization issues, but can concentrate on the pure business process.
Figure 4. GIS versus SAP R/3 GUIs
Conclusion
GPU Energy looked to technology to help accomplish the goal of its enterprise-wide change program. Thekeyingredient forthis chagewas thepeople of GPUEnergy, equipped titithe proper tools to get the job done.
The integration of SAP R/3 with Smallworld was proven early on to deliver bottom-line benefits while enabling the technology to have a combined capability not offered by each system individually.
It was imperative that business work flows be provided with adequate and timely data to complete work orders. For this to be successfid, two main integration pieces had to come together. First, virtual database integration allows the GIS and SAP R/3 data models to be treated logically as a single model, enabling sophisticated planning features for SAP R/3 data. The second piece, business process integration, offers complex business processes freely spread over GIS and SAP R/3. In many situations it makes sense to extract data in GIS and pass them as input data to SAP R/3 (and vice versa). GIS features such as network tracing can be utilized as special pre-processing tools for SAP R/3, allowing both systems to concentrate on their strengths, and eliminating the other system’s weaknesses by cooperation at the business process level.
References
- Schwalm, V., 1998, Disconnect, Technical Product Description Release 3.0. ivl GmbH, Overfeldweg 55, D-51371, Leverkusen, Germany.
- Schwalm. V., 1998, “A Non-Technical Approach to GIS/SAP IU3 Integration.” Smallworld Users Conference, Barcelona, Spain.