You may be tempted to set up the Assets in your EAM in a hierarchy, or Asset Based Modeling, due to ease or current understanding, or maybe that’s the way it’s always been done and was inherited from your old system software. However, the case for creating and maintaining a Location Hierarchy, or Location Based Modeling, is undeniable. This bases the EAM Hierarchy on Functional Locations (those defined by systems, such as HVAC, at which Assets reside), while allowing Geographic, Electrical, or multiple other hierarchies to co-exist, creating numerous benefits.
*Written by Scott Yates, Senior VP, EDI
|Benefit of Location Based Modeling||Details*|
|1. Intuitive Navigation||A Location based hierarchy provides additional navigation capabilities BEYOND that of just standard Maximo Asset Search/Query. Using context-based Location systems for Functional Systems (HVAC, FPLS, etc.), Geography (Building, Floor, Room), Electrical and more provides an additional way to physically navigate to the record you are looking for by following the relationships that you are aware of through the drill-down.|
2. Captures relationships between Assets in different Systems/Subsystems
|This is one of the primary premises behind the Location Based Model. By establishing a one to one relationship between an Asset record and “Functional Location” record, you can create an endless number of relationships between Assets. The primary ones that we recommend and believe provide significant value to all organizations are: Geographic, Functional, and Electrical.
It can be likened to looking at a set of Engineering Drawings where each layer shows a different set of relationships within the same space. Toggling between the “Location Systems” in Maximo (which can be accomplished with a single click) allows you to look at a different layer of relationships between the Assets.
This can’t be done with a pure Asset Hierarchy model because Maximo only allows an Asset to belong to one parent (Asset) and only allows it to be associated to one Location.
|3. Captures critical information at the right level||Here is where the Location Hierarchy really provides an advantage that a purely Asset-Based Hierarchy does not. Location Based Modeling separates the contextual characteristics of the System an Asset is installed on from the physical characteristics of the Asset that are germane to its nature.
This is due to the 1:1 relationship of an Asset to a Functional Location, which is organized by Systems and Subsystems. For example, when I first install an FPLS system I can identify a useful life on the “Functional Location” for a Fire Alarm Control Panel to define my requirements/expectations for any Fire Alarm Control Panel I want to install on this system. I can then assign a Useful Life on the specific serialized Fire Alarm Control Panel (Asset) I install there that is defined by the actual history or manufacturer’s recommendations based on the specific make/model that was chosen.
Having both the “Functional Location” and the Asset record allows you to isolate and define, system- or context-based attribution as it relates to any Asset to be installed at that position (i.e. System Requirements/Specifications) from physical attribution that will not change on a specific Asset regardless of where it is installed (i.e. Manufacturers Specs).
Finally, the organization of Assets into larger Subsystems and Systems provides an easy capability to roll-up data to any point in the hierarchy using any of the three contexts. (For example, replacement cost for all FPLS systems as a total, replacement cost for FPLS systems in Building 1; replacement cost for a specific FPLS system in Building 1; replacement cost for a specific panel, replacement cost for all “equipment”, regardless of system in a particular room.) You can get each of these costs using a single, unchanged report, simply by selecting a different “Location” as the input to the report.
|4. Supports reporting and analysis both horizontally (all Systems) and vertically (specific System)||In Location Based Modeling, there are two very important concepts at play to make reporting and analysis of cost and work history so powerful:
1. The one to one relationship of the Asset to the “Functional Location” means that any work order written against the Asset will be associated to BOTH the physical Asset and “Functional Location” of the Asset at that time, permanently. This provides a cradle to grave view of an Asset despite its move history among Locations, AND a history of the System/Subsystem despite the number of Assets it has held.
2. The organization of Assets into larger Subsystems and Systems provides an easy capability to roll-up data to any point in the hierarchy using any of the three contexts (or any additional contexts you create). This further enables analyzation of failure in system design or context. You can get each of these rolled-up costs using a single, unchanged report, simply by selecting a different “Location” as the input to the report.
|5. Maintains history during Asset moves||If the contextual information/attribution exists on the “Functional Location” records, which don’t move, and the Asset only carries physical attribution (like serial number, manufacturer’s specs, etc.) then there will be no need to update data on the source Location, destination Location, or Asset that is moving. You simply move the Asset. This is effective for more than just attribution as well and can apply to PM schedules, Job Plans, Manuals, Drawings, Safety Plans, etc.
Also, from a work history perspective, with the one to one relationship between “Functional Locations” and “Assets”, not only does the work history against that specific Asset go with it, the work history of that Asset while it was installed on that system, stays with the system it was removed from!! This is hugely important in doing system-based cost and failure history analysis as well as in any type of historical audit.
It should also be noted that systems are not installed, re-designed, or re-installed very often, at least not in comparison to how often Assets are replaced or removed.
Stay tuned next month for Part 2 where we continue discussing the benefits of Location Hierarchies.