In our last article, part one, we completed step one, which included preparing for your move to utility network. If you didn’t get a chance to read that post, please be sure to as it’ll provide key background for these next steps. When we completed step one, our current 10.2.1 system was continuing to operate as per normal, and then we’d implemented SSP Sync, which is now keeping any changes made in our 10.2.1 environment moving to utility network. In this article, we’re now ready to move to step two, and in parallel we’ve constructed a thorough plan to execute the subsequent set of steps. This is where the rubber hits the road, so to speak, in terms of starting to use utility network data in production scenarios.
Moving to Utility Network, Step Two: Train Your Analysis Users and Prototype Critical Integrations
Our next step in the process of moving to utility network could take many paths, depending on the specific utility environment you have today. In our example for this article, we’ll start to train some of our analysis users (see part one for description, but analysis users are those who don’t require edit capability, such as those publishing maps, reports and running spatial queries) in the new utility network environment, ideally enabling them to take advantage of new capability, including advanced tracing, seamless creation of diagrams (formerly ArcGIS Schematics) and becoming more familiar with the more granular (high fidelity) nature of the data.
By enabling these analysis users at this stage of the program, we are not only allowing users to gain more experience with the new environment and toolset, but we are also exposing our data and data model to a new set of users, again prior to using our utility network data for production editing purposes. This also allows us to introduce changes (to the Sync process, target model, or even the source) if required. If the organization feels it is ready – it can even begin to publish data from utility network via their Portal, further exposing the utility network data to other web and mobile users throughout their Enterprise.
In this scenario, our edit users, including Engineers, are still using their 10.2.1 tools, allowing the organization to focus on one set of users at a time. If time and/or bandwidth permitted, these users (or a subset thereof) could be trialing new tools, but it’s important to note that there is not critical path task requiring them to do – their 10.2.1 production environment, tools and integrations are still running.
In parallel, we can begin prototyping and testing new integrations which publish data to other utility systems. Obviously prior to this stage, the nature of the integrations and modifications required to support using utility network would have been identified. However, as per our transition to users, the important item to note is that our existing 10.2.1 integrations are still running.
Not only does this allow greater flexibility as to the timing of integrations being deployed, but it also allows for other implementation options, such as experimenting with entirely new versions of these integrations, which – given the additional data that utility network can support – may provide even more data to those target systems than was previously available. Even more important, it allows for new versions of the target system to be prototyped. Consider these options now available for an OMS/DMS integration, all of which can be prototyped in parallel to the production 10.2.1 system prior to moving to the new utility network version of this integration:
- A new, utility network-based integration using the same data/format as existing in the 10.2.1 – In this case, the target ‘loading’ interface does not change, and we simply can run the two integrations in parallel using the same production data from both GN and utility network geodatabases to provide an apples-to-apples comparison before going live.
- A new utility network-based integration using UN-based data – In this case, a new version and new target integration would be required, but again can be operated in parallel with the existing integration. Again, the important benefit Sync brings in this case is flexibility around timing for not only the integration, but any modifications to the target OMS/DMS platform. In the past, the term going live meant in many cases both systems had to both fully operational – which created hard dependencies between the project and increased risk and complexity of the overall program. With Sync we can choose the timing of when to go live with various components of the overall solution.
In this example, we’ve used the OMS/DMS and DPS as examples of integrations that we may want to implement and prototype prior to others. However, it could be that some utilities choose to implement these last, instead focusing on other integrations such as those to mobile workforce or others, all based on what is the best fit for that organization and their own internal constraints, whether those be resources, financial or otherwise. Sync lets you *choose* when to start working on whichever integrations make sense, whenever best suits your implementation timeframe.
Moving to Utility Network, Step Three: Turn on New Utility Network-Based Integrations
At this stage, we’re beginning to turn on the integrations we prototyped and tested in the last step. This is a critical stage of the program – we’re now satisfied that utility network will meet our production needs, at a minimum in terms of satisfying those internal users (i.e., target systems) that we focus on in the previous step. (A minor celebration could be in order.)
With those integrations now up and running, we can begin to focus on other integrations using a similar approach, and also start prototyping tools, training programs and communications with our end users. At this point our organization is familiar with the new data model and structure, analysis users are actively employing new utility network-based tools, and integrations are up and running. We’re already getting value from the new utility network model and system, prior to tackling the typically most challenging aspect of GIS program, change management for edit users.
In the many years we at SSP have spent implementing GIS programs, one of the most complex – and in many case *the* most complex – component has very little to do with the technology we’re implementing. Rather, it’s the challenge of introducing a new application and user experience to a community who have invested a substantial amount of their knowledge and experience in existing processes and tools – even if those tools are paper! Planning and executing a careful, thorough and flexible Organizational Change Management (OCM) strategy is key to the success of any GIS program.
As per the approach with integrations – our SSP Sync-based approach allows flexibility on when in the overall process users are introduced to the technology and allows for additional time and focus for these areas.
Moving to Utility Network, Step Four: Transition Edit Users and Integrations
At this stage of the program, we are ready to transfer all remaining integrations, and most critically, the edit users from their 10.2.1 environment to utility network.
In prior steps, we worked on integrations that involve the GIS publishing data. As we are still using 10.2.1 as the source for feeding data via Sync to the utility network model, any integrations that update data would still be pointing at the 10.2.1 instance. Now that we are ready to move edit users to utility network instance, we can also consider integrations that update information in the GIS. There are a variety of potential applications that update GIS data, but a typical example is the Customer Information System (CIS) based integrations that update relationships between utility customers and their meters, service points and/or transformers from a CIS.
Others may include WMS-based integrations that interact with processes around work and status of jobs, and/or Asset Management-based integrations that may push data to the GIS related to assets such as “Last Inspected Date” or other information used for asset-based analysis in the GIS.
Along with these update integrations, provided that all edit users including engineers have been through training, we can start transitioning all users into utility network.
Now that we are transitioning (potentially multiple sets of) edit users, of which we may want to slowly transition groups or teams slowly, the risk of conflicts arises (and no, not the versioning kind that we all know and love), as we now have two systems operations with the ability to edit the same data. The ‘update’ integrations described above also have the potential to conflict with other edits. To avoid the risk of creating inconsistent data, careful planning must be taken to address the sequence that each set of users (and integrations) will go live. For example, we may choose:
- Option A — We could go “Big Bang” the traditional approach to turn all users and edit integrations on at once – which is the least risk in terms of data conflicts but also most complex to manage in terms of deployment
- Option B — Isolate users (and their edits) in terms of geography and/or types of data. For example, we could go live with users in Region A on UN, while allowing users in Region B to continue to use 10.2.1. This eases the transition, but as many of us know – how well can you actually isolate one geographic area from another, especially when it comes to a distribution system? Another approach could be to move certain type of data edits to utility network ahead of another (i.e., landbase vs. network). If this approach is used, we also have to take into consideration the fact that as soon as we are no longer editing 10.2.1 data in any area, the information in 10.2.1 will become ‘stale’ – so we need to ensure that any integrations related to that information have already been migrated.
All of the above requires planning and thought, but at this point in the process we have still the bulk of our users (the read-only kind) throughout the enterprise live – and gaining value from your utility network model! And this affords us the appropriate time to proactively and carefully move our edit users.
Moving to Utility Network, Step Five: Retiring SSP Sync
This is the easy part! Now we have all of our users and integrations interacting with the utility network model and related tools. Even if Sync is still running – it shouldn’t be pushing any data up to utility network. If it is, you have a rogue interface or users who just can’t let go of the old system – which should be pretty easy to track down! All that is left now is to retire Sync, and thank it for all the work it’s been doing in enabling you to easily transition to your utility network environment at your own pace.
I hope you’ve enjoyed this 2-part series! As started in Part 1 – there are numerous different approaches to migrating to utility network. SSP Sync is one of them – one that provides an effective risk mitigation strategy to moving your environment to the new model. However, there may be various reasons that your organization would prefer to not take this approach – many people like to use the Big Bang approach and move everything together – and that’s another method that SSP Innovations has had long experience with and can certainly help.
The most important point I hope you’ve taken is that a proactive, broad approach to planning your migration project is critical, and while the project may seem daunting, it presents a great opportunity for not only your GIS users, but also the broader organization whose systems make use of the data your GIS provides them.