Systems
Before starting an RCM analysis, we need to know what we are analyzing. RCM is most often used as a discipline in the wider Engineering Asset Management (EAM) process. As such, the asset is often considered the primary unit of equipment.
In the context of EAM, an asset is typically defined as any item, physical or non-physical, that has economic value and is owned or controlled by an organization. EAM involves the systematic management of these assets throughout their lifecycle, from acquisition to disposal.
From this definition, we see assets as discrete units with economic value - a rather financial way of looking at your equipment.
This is not the ideal starting point for an analysis. Assets do not work in isolation - they work with other assets. Assets do not provide value to your organization by simply existing - they provide value by doing something.
So when deciding what to analyze, we need to move past the concept of an asset, to the concept of a system. The term system has many definitions, but in this context, it simply defines a boundary - where does the system boundary lie that separates your many assets into a system that provides a function. A successful RCM strategy is dependent on understanding the major functions your equipment must perform and where to draw the system boundaries for each major function.
A system may include several assets, be a subset of a large asset, or include several complete assets and subsets of other assets. The important thing is to define a system boundary with a clearly definable function.
For example, an emergency diesel generator can be considered a single asset. But the function this asset provides (emergency power), is not provided by the asset in isolation. The function is provided by this asset, plus its fittings and supporting systems. We should not analyze the asset in isolation, we need to analyze the asset in its system, so include mounts, electrical connections, water supply and safety precautions such as fire extinguishers. The system provides the function, not the individual asset.
Products
Many organizations use several assets of the same type. Fleet maintenance is a good example of this; a single product template is used to create many assets, for example a fleet of aircraft or a fleet of wind turbines. In this context, a product is the design template to manufacture many assets.
All asset-intensive organizations will have assets based on product templates. It would be highly inefficient to analyze each instance of such a product, we often need to analyze the product itself. The same analysis will then be used as the basis for the maintenance of all associated assets.
However, there are a few important considerations:
- Product Systems:
As explained above, a product should not be analyzed in isolation. The product should be analyzed as part of a system that provides a function. As such, the same product may require several analyses, one for each function it provides (as it is used in different systems). For example, the same type of pump (same product) may be used in different systems to perform qualitatively different functions.
- Product Versions & Variants:
A single product may offer variants or modifications. Also, the design for a product may change over time; version 2 of a product may be substantially different to version 1. When performing an analysis, it is important to define the scope - which variants or versions does this analysis cover? By covering many variants/versions, the analysis will include obsolete or optional functions, which must be subsequently managed when linking to specific assets. For example, a car may come with an optional sunroof. Do you perform one analysis, and include the sunroof function, or two analyses, one for each option? This question can get exponentially more complex as you continue to add variants and options to the product.
If you are dealing with such products, it is highly recommended that you use an RCM software package that can manage such variants.
- Operating Context:
In RCM, the "Operating Context" of an asset is a prime concern when starting an analysis. More details can be found here.
Products working under different operating contexts will require separate analyses, or must be managed as variants as discussed above.