A common problem for engineering teams is to measure – and report – on the duration of equipment breakdowns.
This deceptively simple metric leads directly into calculations of overall equipment effectiveness (OEE), and given that breakdowns cause lost capacity, impact delivery times and are just plain expensive to fix, it should be a critical metric within any container terminal.
And a solid understanding of breakdown trends – and costs associated with them – often supports your dialogue with the Finance Team when it comes time to replace expensive capital equipment such as quay cranes.
Recently, I was able to discuss this with two Mainpac container terminal customers who explained how they capture and report on breakdown duration.
Our Australian customer noted that: "As with most terminals, we've struggled to capture consistent, accurate data on breakdowns. For some time we considered using the start and end times on those work orders associated with the breakdown work, but it's not really satisfactory because the amount of work recorded usually overlaps the actual downtime for the equipment."
Indeed, this is a common thought and hits on the most obvious issue with this 'solution'. As illustrated by the graphic, the downtime measure of:
Work Order #4 stop time minus Work Order #1 start time = 4 hours
*does not guarantee that the equipment was down for all of this time. [See Diagram 1]
The other issue with this method is whether you can even identify which work orders relate to which job. It looks obvious in the example above, but in a busy terminal generating dozens or hundreds of work orders a day, this can be far from a simple task.
As the Engineering Manager with our terminal customer in the United States noted, there is a subtle but serious flaw with this method.
"Sometimes we have work orders that are open overnight. They relate to the breakdown, but for whatever reason are not closed at the end of the shift. Sometimes that is legitimate, because that aspect of the job will be picked again the next morning, but more often closing out the job is overlooked and if you are measuring breakdown duration in this way it absolutely skews the statistics.
"So you end up reporting breakdown durations that Operations knows are wrong, and backtracking to correct the data is time consuming and frustrating."
Clearly, just counting work order start and end times is unsatisfactory, unless you change the way those work orders are structured, as the Australian customer explains.
"What we do is create a work order for the breakdown, but we make this the parent and use its start and end time to record that breakdown duration. Then, we create children work orders if necessary to capture the other tasks associated with the repair work. But we ignore their start and end time for the purpose of capturing the breakdown duration."
As Diagram 2 illustrates, there is no difference in the Engineering hours consumed or the tasks applied to resolve the breakdown, but the duration is more accurate.
There is an additional innovation that this customer has added, being a 'breakdown button' on key equipment, which automatically raises a breakdown work order when pressed. This significantly improves their breakdown repair time because Engineering knows about breakdowns at the same time as Operations and has a dedicated team ready to respond. This team is using WiFi tablets to manage breakdown work orders, allowing them to take ownership of the breakdown process from start to end.
"Adding the breakdown button and tablets was more a change management issue than a technology issue, but as the benefits emerged in terms of accurate reports and cost allocation within Engineering, and faster time to fix for Operations, this became one of the those 'why didn't you do this sooner' good ideas.
"Still, having proved the process we plan to roll this out to our other terminals and that's a great outcome as far as I'm concerned."
You don't have to implement a breakdown button and WiFi tablets to improve your data capture of course, though these are certainly good ideas. But you should be looking at a parent work order to establish downtime duration.
Otherwise, you will struggle to capture and report the true costs associated with breakdowns, putting Engineering on the back foot across the board.