Seeking Insight on Asset Management Adjustments for UN Migration

[BrettRosso]

Good morning,

I'm reaching out to see if anyone has gone through — or is currently in the process of — migrating to the Utility Network and has had to make changes to their asset management system to align with the UN schema. Bonus points if you're using Infor Public Sector!

I'd really appreciate the opportunity to connect and learn more about what tasks or changes were involved during your migration.

Thanks in advance!

[Isaac_King]

Hey Brett,

I've worked on quite a few UN projects, Asset Management (EAM) implementations and integrations between the two. As a rule, particularly since you're implementing a new GIS model like UN, I would advise adjusting the UN to fit EAM, not the other way around.

There are some "system attributes" with the UN that are non-negotiable (asset group, asset type, subnetwork name, etc) but the majority of attributes provided in an Esri template are an example rather than a requirement. I will generally rename or re-alias as needed to fit the current business process and systems, rather than drive changes to other systems.

Another challenge with integrating EAM systems to UN is often finding how to align objects between the system, where we would historically map a feature class in GIS to a table in EAM, now we generally need to find a way to isolate the Asset Type in GIS to map to the same table in EAM. Some EAM systems have the ability to apply a query to inbound data which helps resolve this issue. If this is not an option for Infor, another good option is to publish a set of feature services with def queries that isolate the AG or AT that corresponds to an existing object in EAM.

Hopefully some of this helps. If not, feel free to send me a message!

[BrettRosso]

Thanks for the reply, Isaac — really appreciate it!

I definitely agree with your approach. I don’t plan on adjusting the UN model to fit our current EAM setup. Our existing system has a lot of unused types, null values, and some misconfigured asset classifications, so this feels like the right time to “get it right” and clean things up.

I’m not the EAM expert here, but I believe we do have the ability to query feature classes or services from within Infor. Still, your point about isolating asset types through definition queries is a great reminder, and I’ll keep that in mind as we start to piece things together.

I’ve got a general vision of how everything should function, but I’m still a bit unsure about the exact order of operations for how it’ll all come together. Your experience definitely helps frame some of those next steps more clearly — thanks again!

[RobertKrisher]

In places where you're adopting the schema defined in the Utility Network Foundation, you may need to devise a way to translate field names and field values. Some EAM systems make having a translation layer like this easy; others require more work.

[tikola]

I will bring in discussion another perspective - AGOL Data Management Solution for water utilities. I have been in last couple of years made 10 migrations where data is originated some old system and now it is squeezed to Esri Data Management model.

Task often feels like fitting a round object in square hole. It is impossible to say is old or new better - they simply are different. My principles in migration are:

• I will do it in Pro - Add Fields/Append tools. What I in practise aim is that all sensible information of old system is kept in first step. I mean that all original data attributes are stored next to Esri schema so that if I miss something it can be redo again anytime. 
• Data is then cleaned afterwards when we are sure it is no longer needed. Extra fields in attribute table will not harm but missing something in a year after harms. So I do not delete original data until I am sure some information is no longer needed and it is migrated in proper way to new system.
• I will migrate only valid data. For example in Rim elevation I make sure that all values in Esri fields are in valid range - they should be bigger than some value and smaller than some other. All the rest I will leave NULL. So I do not bring unsensible zeros or negative heights if it is not valid for that region. It is easier to separate true data and null than some random negative values.
• I clear all not valid lists away - for example all diameters in our region are metric - I leave no inches or US pipe vendor company names available in system

Our customers are tiny organizations and UN is not option for them. AGOL Data management suits well in case where organization is just few guys. UN requires way more skilled organization to handle all issues related on that. Downside in data management is that if someone wants to join drinking water and sewer system sets no limits for that - it can be done. So controlling the network in data management is totally in user responsibility.

So getting started with Data Management is extremely easy while in UN you need to know a lot before it gets usable and you get benefit of all abilities system has.

Migration is a labour oriented task where main thing is to think what you do. Do not just run some wizards and hope it will do the trick. Instead think what you are doing and act after thinking. I think that is main rule of migrating utility data in generally.