Migrations are almost always complex and come with many different sets of requirements and considerations. Adding in an Enterprise Asset Management (EAM) integration coupled with a Utility Network implementation in combination with the migration, brings the importance of proper strategy and planning to the forefront. Following some of the techniques discussed below, will help prepare you for a successful implementation of these cutting edge technologies.

Requirements Gathering

In complex migrations that involve a GIS upgrade and EAM upgrade/implementation, a detailed requirements gathering process is of the utmost importance. Open discussions of current systems, business requirements, and desired future state outcomes, ideally in a workshop environment, is requisite. Asking the right questions will lead to overall better results.

Necessary questions include:

• What are the key touchpoints from system to system?
• What types of assets are being consumed in each system?
  • Are there differences in naming or design between each system?
• What is the key linkage from GIS to EAM?
• What fields are required to satisfy each system?
• Do fields need to be added to GIS to facilitate asset location in an EAM?

Ensuring that you are asking the right questions is only part of the solution. Involving the proper stakeholders in these conversations is pivotal. These stakeholders know their data and processes better than anyone and involving them in the discussion not only results in a clearer requirement gathering, but also gives the stakeholders some buy in on the decision making process.

Data Standardization

Data models are the bedrock of any GIS related implementation. Whether it’s an industry standard model such as UPDM or PODS for gas or a more customized electric model, having a clear understanding of model consistency vs migration efficiency is a must. Factors such as having one or multiple instances that we are migrating from play a huge role in this decision making. For example, if data is coming from multiple instances, deciding to try, and fit multiple fields into one existing future state field vs extending the model to accommodate all variances will always come into play. Strategies such as overriding model domains with source domains is often a preferred and expedient path in both terms of migration and EAM value consumption.  Field additions that would accommodate business requirements and EAM requirements should be analyzed in workshops to ensure the data model meets them. Furthermore, in a Utility Network implementation, Asset Group and Asset Types (which are characterized by material and/or asset function) should also be closely examined for extension to meet business need. A good practice to ensure a leaner dataset, is to look at field usage and data population percentages. If fields or data aren’t being used in the source, then likely there wouldn’t be any need for it in a future state system. Finally, weighing data types to conform to data model or replacing with a more efficient data type (i.e. text to integer) to potentially improve indexing performance is a wise practice.

Migration Strategy

The most important question surrounding a Utility Network implementation, is what is the state of data? The Utility Network requires a very high level of data fidelity to accommodate all the functionality that comes along with the technical stack. Topology is a key mechanism within the Utility Network and bad or unconforming data against a set of rules create dirty areas inside that topology. The greater number of dirty areas that are present in a dataset, the more performance degradation a user will see. Dirty areas also prohibit the use and creation of subnetworks, which drive tracing through set of tiers. The following list is some frequently seen errors during a migration from legacy to future state:

• Stacked Features
  • These are often junctions or devices that have the same x,y location. De stacking them or using a Z offset (increasing the Z vertices inside a particular geometry) to de-stack but also disconnect on the points/line clean the dirty area.
• Connectivity Rule Issues
  • Connectivity rules are a major driver of the Utility Network. If a line or point doesn’t adhere to the rule placed upon it, this creates a dirty area. An example of this would be a line with a different asset group connected to another line and without a junction or device acting as a transition between the two.
• Geometry Issues
  • Multipart lines are an example of a topology error we see associated with bad geometry.

With all these factors in mind, it’s a good idea to know what state your data is in before moving to the Utility Network. None of these factors should prohibit you from doing so, rather it should act as a guide to consider what actions to perform before doing so. Actions such as: