The FME script populates the entity
categories, we used FME to merge
identifier table with our equipment
asset classes. We also improved the
numbers and asset EUIDs, while the
use of the Type field in our asset table
JavaScript requires the user to search
schema and updated the attached
a valid equipment number before
assets of all existing work orders.
creating the attached work order.
We manually reconciled existing
We also realized staff needed to see
work orders with the consolidated
identifying asset attributes in their
asset classes, updating the work
inbox. Our staff often plan work
order templates, custom fields,
order schedules based on attached
and relationship classes. Now, we
assets in their assigned work, but
operate with 72 asset classes. This
they couldn’t see asset attributes
simplification benefits the users,
in their search results or inbox. To
Cityworks admins, and the GIS staff.
address this, we populated the asset’s Address field with its number and name, which is then duplicated in the work order’s 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
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: 1. The parent feature of the asset is added to every work order 2. The work order cost is split
class. Yes, you read that right.
between all attached assets,
One. It made searching easy,
unless manually adjusted
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
3. You cannot use the map to locate an asset without the hierarchy 4. The xy of the work order is the centroid of the parent feature 5. And work order event layers
The glow of finishing an implementation can quickly fade once you see the system’s use in the
us, for example, with five asset
are stacked with other work
real world. This is not a set-it-and-
classes for HVAC and eleven for
orders at the feature’s centroid
forget-it system, but no true asset management model should be. The
instruments. This level of parsing increased the administrative burden
Our solution? In the FME model
proper use of Cityworks must be
of managing the registry and proved
used to consolidate assets, we also
fostered through ongoing training,
clumsy when searching for assets.
called a Python script that gave
relationship building, and working
each asset the xy value of its parent Suddenly, we were on the
with staff to improve tools and
feature, converting the object
other extreme of having
processes. Our ability to improve
tables to feature classes. We then
too many asset classes.
the usability of Cityworks keeps
manually moved each asset point
staff engaged and invested in the
to its correct spatial location. Now,
continuous improvement process.
The solution was clear: consolidate asset classes. After meeting with maintenance staff to refine our
we are officially operating a GIScentric asset management system.
Header and top image courtesy of Joe Zumbo of Central San.
FALL 2018 17