Step 4: Know How You’ll Measure Success
This may sound obvious but it’s actually the root of many issues in technology rollouts. You and the vendor have a broad based discussion about what problems their solution will address for you,and you sign the agreement. But once the solution is implemented, you’re finding that not everyone’s definition of success is really the same. The folks on the line are expressing frustration that the new tool seems to be adding work to their day- and nobody asked them what success might look like to them to help get buy in.
You’d agreed with the vendor that the goal was to reduce ‘downtime’ for example. But is that all downtime? Just unplanned downtime? What if downtime actually goes up at first as the solution starts identifying issues you were not aware of? It might reduce risk of future unplanned events that are catastrophic, but right now it just seems like you’re going backwards not forwards. Is that success? If you think the solution will help reduce costs, have defined exactly what costs will go down and how much?
Also make sure you’ve got all the parties involved and watch out for competing measurements or priorities. What success looks like to one team may not be the same as another. Does the maintenance team get measured by the number of tickets addressed? If so, a solution that reduces the need for teardowns and time-based maintenance might actually make it harder for them to meet their goals. And don’t just limit the exploration to your own teams. Know how will other groups want to measure the value of the solution: For example if you justify the spend to finance as a way to reduce cost, can you simply repurpose the savings to other areas of the business (meaning your budget doesn’t change) and still claim a cost savings to finance (a geat win)? Or will they pressure you to demonstrate the savings by reducing your budget (no fun). If you can increase capacity and production can you say you impacted revenues and gross margin or are you just seen as a ‘cost center’ by the business? Getting all that ironed out in advance will help you be able to justify the investment- and keep other teams on board as you move to scale.
And make sure you have both short term and long term metrics. New solutions can make a big impact on the business so the early results are dramatic. But once the solution becomes part of your steady state the value might not seem so obvious. Make sure you’re asking not just ‘how much new value can I see from the solution today’ but ‘what would be the impact down the road if I stopped using it’?
Finally let the vendor help you define the metrics. It might seem like you’re exposing yourself by letting them help define success but remember they’ve (ideally) seen dozens or hundreds of your peers use the solution and have a lot of insight into how to measure and what success can look like. They may even be able to point to kinds of value that might not be apparent to you out of the gate, but that help you to justify the solution and create more ways for you to impact the business.
Comments
-
Brian, excellent post. Too often the expectations are that unplanned downtime just goes away. While the goal for the unplanned aspect should be "minimize", the fact that planned downtime may indeed bear this burden is a natural result - either in magnitude (hrs) or frequency of occurence. And yes, many times the spare parts budget will also see an impact until the failure mode insights become aligned with the reliability efforts. I would always tell the manufacturing team to 1.) focus on what you can control and 2.) think beyond the fix. Removing the emotion associated with unplanned and random yet repeating failures enables sustainable solutions to become realized.
0
