How Thinking of Assets as Systems Improves Asset Management Processes ( Getting Ready for ISO 55000 – Part 10 of 12 )
[ Insights from the “Asset Management for the 21st Century—Getting Ready for ISO 55000” Seminar, May 2013, Calgary (Part 10 of 12): This blog is based on a series of interviews with John Woodhouse from the Woodhouse Partnership (TWPL), who delivered this well-received seminar. It is part of a blog series brought to you by Norm Poynter and Paul Kurchina, designed to inspire and educate by sharing experiences with the SAP Enterprise Asset Management Community. ]
When trying to support asset management, CIOs typically subdivide the problem to get their heads around it and create models that center around individual physical asset records on the asset register. This makes the data library simpler (asset attributes are more consistent if they are structured by asset type, and at least some transactional data is asset type-specific) but, from the business value perspective, it is usually better to look at the way in which diverse assets work together in functional systems to deliver value and business results (which is why the assets exist in the first place). This system is harder from the IT modeling perspective, since systems usually comprise a mix of asset types, functional locations, and overlapping system and sub-system hierarchies and have complex performance interdependencies. However, it does reflect how we actually use assets to generate value—so it aligns better with performance outcomes, risks, criticalities, and value focus.
We also tend to do things to individual assets (e.g., inspection, maintenance, or renewal) but measure and get benefits from the systems in which they operate. So determining the right thing to do, and when to do it, requires us to evaluate impact at the systems level for costs typically incurred at the component asset level. A systems’ perspective is therefore essential for optimized decision-making, work prioritization, and delivering best value-for-money. It also means that you must understand what business outcomes are desired, how the various asset systems contribute to these, and only then how the individual components (assets) contribute to the performance of the systems. Dealing with assets as if there were independent data elements, needing maintenance and accumulating performance history, is like grouping parts of a jigsaw puzzle by their similarity of shape instead of referring to the overall picture and how neighboring pieces fit together.
Let’s look at electric motors as an example. Some asset management requirements and data attributes are evidently linked to the fact that it is an electric motor (rather than, for example, a pipe or an instrument). But the same design of motor should receive very different asset management strategies, data and performance tracking depending on its functional location (or system context): such as if it has an installed standby alongside it, or if it is used only two hours a day, or if it is in a business critical role with big failure consequences. These factors are usually considered in strategy development (e.g. RCM and RBI studies) but not often mirrored in EAM systems and data structures.
Strategic planning of business priorities (e.g., investments and improvement programs) is primarily a top-down process, informed by bottom-up asset realities (constraints and opportunities in what is possible, given the assets’ condition, performance, flexibilities, etc.). Asset systems are where these two influences collide—the performance desires of the business versus the component asset capabilities and constraints. So, in the pyramid of assets in the total portfolio, it is the operational systems level at which strategy needs to be most carefully optimized: it is the negotiation layer, where stretch targets get set and challenged, and it is the layer where success or failure needs to be measured and reported.
For more information, here’s a post with all of the links to the published blogs in this series.