GIS/ERP Systems Deployed to Great Effect
A common risk in building and deploying GIS/ERP integrated systems is not paying proper and timely attention to data quality and modeling thus putting schedule, budget and, ultimately, project success in question. This article explores the relevant factors and what must be kept in mind to minimize this risk.
Applications and underlying enterprise systems traditionally had a reputation for inadequate user experience (UX) and reliance on character based UI design resulting in lower user adoption and not completely delivering on promised productivity gains. These shortcomings became more apparent over the last eight years with the rise of consumerized, easy to use mobile applications that do a handful of things very well and require little or no training. A key driver of the rise of consumerized apps is the utilization of maps in UI design. Introduced in 2005, Google Maps exposed the masses to a map’s ease-of-use in both enterprise and consumer settings. This has led to many enterprises to ask why business systems and applications don't offer that same ease-of-use.
“The use of the map as the UI can hide the dependencies and steps it takes to render objects and associated information (metadata)”
Map based applications ("mapplications") and GIS systems like Esri ArcGIS have long been used in academic, government and scientific communities. GIS systems have also been used by enterprises including asset-intensive industries like utilities, oil and gas (O&G), and transportation but were isolated from their enterprise (ERP) systems. Within the last decade, enterprises began looking at how to bring together GIS and ERP data to improve business processes. The advent of smartphones (starting with the Apple iPhone) and the resulting consumerized applications were a catalyst in creating mapplications with a high quality UX running on integrated GIS/ERP systems. For asset intensive industries, these geospatial integration projects offer clear improvements in the service chain for field operations reducing windshield time and increasing wrench time. For the first time, a field worker can see their tasks (like work orders) on a map along with the assets (like power poles, gas pipelines, and transformers) in one application.
The use of the map as the UI can hide the dependencies and steps it takes to render objects and associated information (metadata). For a mapplication running on a GIS/ERP integrated system, there are even more dependencies and steps that need to be executed properly. These include data quality of the ERP and GIS data and also how that data is modeled - including in any existing enterprise GIS databases. Therefore, it is critical to pay increased attention to these for GIS/ERP integration projects – map related requirements must be addressed from the start. We've seen where the apparent simplicity of a map leads to exactly the opposite - the project team decides to wait until late in the project to implement the map functionality because it is viewed as an isolated component. This is common in projects that use SAP Work Manager and similar products because the map (spatial) capability can be enabled independent of the core SAP Work Manager functionality. We have deep expertise in this area because Critigen co-developed with SAP the map capability in SAP Work Manager and deliver implementations. Going forward, I refer to SAP Work Manager instead of a generic mapplication. The map based functionality in SAP Work Manager can be provided by a standalone app as well.
Below is a simplified architecture of a typical GIS/SAP Integrated system. There are variants including the use of SAP’s GEO.e engineered solution which merge selected spatial asset information into the SAP Plant Maintenance (PM) module. A discussion of GEO.e is outside the scope of this article. The system below relies on a cross reference or mapping table that is maintained in the SAP PM instance and is populated with unique identifier pairs from SAP assets and the corresponding assets in GIS.
Some mapplications simply show the approximate location of business objects from the SAP PM instance (like work orders, notifications, equipment and functional locations) derived from an address or X/Y coordinate. A system like the one depicted above can go well beyond that by providing the exact location and spatial representation (point, line, polygon) of those business objects to SAP Work Manager. This means a substation can be shown as a polygon, and a pipeline or power transmission line as a polyline. This allows the field user access to more detailed information and exact location of assets, especially those found underground, like pipelines or buried electrical lines. Functionality provided by this type of system can be provided by the SAP HANA Cloud Platform.
The foundation of GIS/SAP integration is the existence of a linkage between assets stored in both systems. Furthermore, the representation and modeling of the assets must also be consistent across both. For instance, a gas transmission line can be modeled in different ways. For example, a pipeline can be modeled as a series of line segments (or functional locations) broken at a valve, or it can be modeled in LAM as a continuous line with assets located at specific locations (i.e. mileposts or stationing) along the line. If the underlying asset data isn’t modelled and stored in the GIS system the same way, it’s impossible to render that asset on the map in SAP Work Manager because there isn’t a 1:1 mapping between SAP and the GIS asset data. That mapping implies a unique foreign key relationship between assets in the GDB and SAP PM.
The spatial representation, location accuracy, and map symbology should be driven by the business requirements. For instance, do crews need to know the exact location of a piece of equipment within a substation, or do they just need to get to the substation? If an asset isn’t serviced often, or it’s easy to find in the field, maybe it isn’t required. The finer the granularity for geolocating each asset, the greater the data collection and maintenance effort. Taking an inventory of all of an organization’s assets and evaluating business requirements can help guide how much effort, including the locational accuracy and granularity, and whether it’s necessary to store the actual shape of the asset in the GIS database vs. an approximate representation. For instance, one of our clients chooses not to represent their functional locations as polygons but as points because the main purpose was navigation to the location.
When the above is considered, data quality is clearly critical – for a business object in SAP PM to be displayed on the map, it must have a corresponding asset in your GIS system. If not, those assets and associated work in SAP will not display on the map. You must have alignment between your GIS and SAP asset data for project success. The types of business objects to be displayed are determined by business requirements. If the assets in the GIS database are replicated from enterprise GIS database(s), business processes are needed to keep the two systems aligned. As explained earlier, if a piece of equipment or functional location in SAP PM is represented as multiple assets in the GIS database, it will be impossible for the user to see the asset on the map. The upshot of this is data modeling and data quality – especially for systems used by map based applications – must be considered from the start of a project.