We did it. We implemented and went live with Cityworks for our wastewater collection system and treatment plant. We migrated from three asset registries and two CMMS to one. Breathe in, breathe out. It feels so good!
Let’s check the box because the job is done. Right?
Well, hopefully not.
Implementation is just the first step in developing a sustainable asset management system that improves the quality of maintenance planning, increases staff efficiency, and supports decision-making.
We made common configurations and improvements during our implementation, such as adding universal custom fields and modifying XMLs. However, as we approached and moved past “go-live,” it became clear we could further improve the usability of Cityworks. Without successful adoption and use by our frontline staff, we’d still be collecting incomplete data, fraught with inconsistencies and inaccuracies—inevitably providing misleading information to our decision makers.
So, how do we increase our potential to properly use our new CMMS? By focusing on the experience of frontline staff. Sorry, managers, your reports can wait. Besides, what’s a report with bad data?
Our first ongoing improvement goals fell into two main categories: functionality and infrastructure enhancement. Here are a few examples of improvements we made for our treatment plant users.
Functional
We recognized early in our implementation that staff struggled to search the 94 different treatment plant asset classes when creating a work order. So, we decided to use the Entity Lookup tool to simplify the process. With some FME (Feature Manipulation Engine) scripting and a little JavaScript, we turned this tool into an enterprise quick asset search for creating attached work orders.
The FME script populates the entity identifier table with our equipment numbers and asset EUIDs, while the JavaScript requires the user to search a valid equipment number before creating the attached work order.
We also realized the staff needed to see identifying asset attributes in their inbox. Our staff often plan work order schedules based on attached assets in their assigned work, but they couldn’t see asset attributes in their search results or inbox. To address this, we populated the asset’s Address field with its number and name, which is then duplicated in the work order’s WO Address field under Location Information. This allows staff to see asset information in their inboxes and plan their work without needing to open each work order.
Infrastructure
In our legacy asset registry, all assets were stored in one asset class. Yes, you read that right. One. It made searching easy, but it wasn’t an ideal registry.When we migrated to Cityworks, we went live with 94 asset classes. Staff had focused on discrete rather than generalized functions, leaving us, for example, with five asset classes for HVAC and eleven for instruments. This level of parsing increased the administrative burden of managing the registry and proved clumsy when searching for assets.
Suddenly, we were on the other extreme of having too many asset classes.
The solution was clear: consolidate asset classes. After meeting with maintenance staff to refine our categories, we used FME to merge asset classes. We also improved the use of the Type field in our asset table schema and updated the attached assets of all existing affected work orders.
We manually reconciled existing work orders with the consolidated asset classes, updating the work order templates, custom fields, and relationship classes. Now, we operate with 72 asset classes. This simplification benefits the users, Cityworks admins, and the GIS staff.
Additionally, we first implemented Cityworks with most of our asset classes as objects since we did not have their spatial information. However, there are limitations to assets stored as non-spatial objects. For example:
- The parent feature of the asset is added to every work order
- The work order cost is split between all attached assets unless manually adjusted
- You cannot use the map to locate an asset without the hierarchy
- The xy of the work order is the centroid of the parent feature
- And work order event layers are stacked with other work orders at the feature’s centroid
Our solution? In the FME model used to consolidate assets, we also called a python script that gave each asset the xy value of its parent feature, converting the object tables to feature classes. We then manually moved each asset point to its correct spatial location. Now, we are officially operating a GIS-centric asset management system.
The glow of finishing an implementation can quickly fade once you see the system’s use in the real world. This is not a set-it-ad-forget-it system, but no true asset management model should be. The proper use of Cityworks must be fostered through ongoing training, relationship building, and working with staff to improve tools and processes. Our ability to improve the usability of Cityworks keeps staff engaged and invested in the continuous improvement process.
By Ian Morales, GIS Analyst, Central Contra Costa Sanitary District, Martinez, California