Work Simple
Gartner published their 2020 Field Service Management Magic Quadrant last week and one of the first statements they make about the future is: “By 2025, over 50% of equipment manufacturers will offer outcome-based service contracts that rely on access to digital twin data, up from less than 20% in 2019.”
But what is outcome-based service contracts in the context of field service?
I’ll try to explain this by following the journey a service organisation could take to grow towards outcome-based service offerings.
Stage 1 – Time and material
Many service providers start out by simply offering their knowledge, skill and time to asset owners. If an asset fails or stops producing, the service provider is called out to fix it as it is the one that has the know-how. It can do it faster and more efficiently then the asset owner and it will charge base on the time and material it uses to carry out the repair.
In this context, all the risk is borne by the asset owner. If the fix takes longer to carry out, the owner will pay more. If the asset fails again a few days afterwards, the service provider will be called out again and charge for its time and material, again.
Stage 2 – Outcome-based work
One way to transfer some of the risk – and rewards – to the service provider is through a contractual agreement based on the outcome of the work done. The service provider gets paid a fixed amount, based on a schedule of rate, to carry out the work regardless of the time or material used.
The service provider can reap the benefits of working more efficiently in this model, but the risk of asset failures is still squarely on the asset owner. The asset owner is still the one calculating and planning the preventive maintenance regime that will minimise reactive break-fixes.
Even if we speak here about outcome-based work, this is not truly what we would call an outcome-based service. The service provider is not yet truly incentivised to work for the better outcome of the asset owner.
Stage 3 – Up-time objective
From the perspective of the asset owner, its target outcome is all about ensuring that its assets remain productive. It wants to maximize up-time as a failed asset is non-productive and leads to loss of revenue.
Outcome-based service is about aligning the targets of the service provider to the ones of the asset owner. This could be, for example, by setting up a commercial agreement where the service provider shares in the benefits of keeping assets productive rather than getting paid for each repair.
In this context, the asset owner is not telling the service provider of when an asset has failed, or when to maintain it to prevent failures; it is the service providers responsibility to determine these and act independently to minimise down time.
Like in the previous stage where the service provider could reap the benefits of working more efficiently, more benefits can be produced by the service provider right-sizing the maintenance program to minimise unexpected downtimes: avoiding over-maintenance, but keeping in mind that a failure costs 3 times more than a planned maintenance.
Stage 4 – Revenue objective
But ultimately, the real target for any asset owner, above and beyond asset up-time, is a predictable, constant stream of revenue. The difference with the previous stage is that with a revenue objective, the actual asset instance doesn’t matter. This is especially true for rotable assets, or equipment that can be swapped in and out of installation.
In a revenue-objective outcome-based service model, the asset owner, to a degree, doesn’t care about the equipment (type, model, instance, etc.). All it cares about is that it can continue to produce revenue from whatever asset serves him. It is the service provider’s responsibility to select appropriate assets, determine maintenance regimes and execute swap-outs so as to never affect the owner’s revenue stream.
The flag-ship example for this model is the Rolls-Royce “flight hour” service, where the engine manufacturer doesn’t sell engines, but flight-hours. The airline doesn’t care which engine is installed on its plane – the service provider can, at any point, come and swap out engines if its IoT signals predict problems – as long as the aircraft can fly when it is scheduled to fly.
The more we progress in the stages of the outcome-based service journey, the more the service provider takes on the responsibility of prediction:
Prediction capabilities come from data (which is why Gartner talks of “access to digital twin data”), and good, clean prediction-enabling data comes from good service management systems that can properly “debrief” the work and learn from it.