When it comes to lifecycle cost modelling, there’s a common dilemma. How much detail should you go into?
A highly detailed model is likely to appeal to engineers and accountants. But it doesn’t necessarily translate to more value to your business.
There are several key considerations when developing a lifecycle cost model to ensure value to an organisation.
1. Lowest Replaceable Unit
Lowest Replaceable Unit (LRU) refers to a single component at the lowest point in the asset hierarchy that can be procured on its own and replaced in order to maintain that asset. For example, an LRU for a desktop computer would be a motherboard. Reliability is often modelled at the LRU with costs also captured at this level. If an asset can be repaired through replacement of the LRU component, it may make sense to also capture lifecycle costing at the same stage, as it would most accurately reflect what would actually happen when failure occurs.
2. Dominant Failure Mode
An asset may fail in several ways that will result in it needing to be replaced. For example, a car tyre can fail due to normal wear as well as due to a puncture. For degradation modelling purposes, the failure mode caused by wear would likely dominate the puncture failure due to a much higher frequency of occurrence. In this case, it might be sensible to only include the dominant failure mode and ignore the minor failure mode given the minimal effect the puncture would have on the overall model.
Also, an organisation may not have the resources required to capture failure data at a granular level, which would make splitting the failure modes out a pointless exercise.
It may also not make sense to model asset types where a dominant failure mode is completely random in nature and doesn't provide a reasonable warning that it will fail within a given planning period. Relatively inexpensive components such as exhaust fans might work perfectly one minute but fail to work the next time they are used. In this case there’s little point in trying to predict when the cost will be incurred. Instead, you may possibly maintain a replacement in stock to minimise inconvenience.
3. Access Restrictions
It may be difficult to assess the condition of certain assets, or accurately predict the timing of maintenance requirements. Examples might include buried assets, or assets which can’t easily be stopped to carry out a condition inspection. If the cost of inspecting the asset outweighs the consequence of the failure, it may arguably be more sensible to allow it to fail without using invasive procedures to predict its failure. Again, the strategy would be to allow for the cost of failure and stock spares to minimise downtime.
4. Contractual Arrangements
The maintenance of certain assets may be managed by external providers under a fixed term contract. In many cases there is little that can be done about these arrangements until the term expires. So, in this situation, it’s a waste of time from a cost perspective to model a high level of detail of assets covered by the contractual arrangements.
However, understanding the maintenance requirements over an upcoming contractual period could be highly beneficial to enable efficient scoping for the services during the period to ensure value for money.
5. Budgeting Requirements
An organisation’s financial budgeting and reporting requirements may drive the level of detail of cost capture and forecasting. These reporting requirements may be related to geographical locations, responsibility boundaries, asset classes, safety or environmental aspects, or simply regulatory driven.
There is no single answer to the level of detail your lifecycle model should have. However, the level of detail should support what your organisation is trying to achieve.
Lifecycle models are primarily developed to enable decision making. If there’s little desire to drive improvement in the way funding decisions are made to affect asset performance and risks within a portfolio, there may be little benefit in a highly detailed model. On the other hand, if an organisation wants to lower costs by reducing service levels of a certain facility or asset class, then more detailed scenario analyses may be worthwhile.
It is important to ensure that the effort to generate lifecycle models is commensurate with the potential gains in either cost reduction, risk management, or end user satisfaction. Drivers for modelling effort may vary between organisations or even within the same organisation over time, depending on stakeholder expectations and risks being managed.