Beyond KPI’s

Working Together or in Silos

Working Together or in Silos

In the asset management world measuring performance through the right KPI’s is important, focusing on the results of the asset management processes and adjusting regularly to the trends seen on the dashboards is vital to continuous improvements.
However it is not enough just to focus on the KPI’s, one always needs to be aware of what is behind the KPI’s, what behaviours KPI’s are driving and what is the ultimate goal for the business as a whole.

Example:
A batch production process breaks down, it is a small component that is relatively easy to change, just takes a few hours to do. However, the spare part is not available in stock and it will take 2 weeks to get that spare part. Luckily, they have two exactly the same types of processes side by side and the production batch cycles allow for the part to be taken from one manufacturing process and installing it on the other process while the batch preparation is done. Thus not affecting the production and delivery of the product is without any production losses noticeable.
So the Maintenance Supervisor adapts to this situation and had a Maintenance Technician perform the switch regularly keeping the production, as well as the customer, happy because production went as planned.
However when focusing on the maintenance KPI parameters this results in an increased Break Down Maintenance over the 2 week period, as they needed to move the part from one process to the next in line with the batch production cycles. This also resulted in non-compliance to part of the PM program, as the maintenance technician did not have the time to do all the planned PM’s because of the added Break Down Maintenance. It can also be assumed that because the PM’s where not done that could result in further unforeseen breakdowns.
The Maintenance Manager comes to the Maintenance Supervisor not happy with his decision, because he monitored the KPI’s and could see that the Maintenance KPI’s, noticeably the break down KPI and PM compliance KPI where not trending in the correct direction.
After weighing the options and understanding the story behind the KPI’s development the Maintenance Manager agreed that out of a bad situation the Maintenance Supervisor selected the best possible path.
Conclusion:
If everyone is focused on a single dominating goal, it is less challenging to adjust to situations as described in the example here above, as long as we understand the underlying attributes that affect the KPI’s developments.
However in a silo situation where there might be tension between the silo’s (e.g. production vs. maintenance). In that case the example might have developed in a different way, i.e. half the production down for 2 weeks because of a failure where the spare part cannot be delivered for 2 weeks, the maintenance KPI’s would suffer a bit (one break down) but the production KPI’s would suffer even more.
Food for thought:
Is there a clear understanding in your organization for the why’s of the decisions that are made, i.e. are there clear governing goals?
Do you sometimes sacrifice your goals for the greater governing goals? And are you recognized for that?
I welcome your feedback and discussions below this Blog post.

Systems in Maintenance & Reliability processes

A good friend of mine Gísli Gylfason just sent me a link to a interesting article from Johnny Bofilios.

After reading that article my mind wondered on to a few points:

Point 1: A software system that solves all of manager’s problems does not exist except in the advertisement brochures.

Regarding this point software systems do not solve the problems; good processes and work procedures can solve problems as well as many other activities. However software systems are merely tools that document the process and the results from that process, or other activities, being done. They can help us in many ways, for example to analyse problems, but in the end they are “just” tools that we use to try and be better at what we do.

Point 2: A bad manager without a system will be more efficient at being a worse manager with a system.

Point 3: A good manager without a system will be more efficient at being a better manager with a system.

Regarding points 2 and 3: A software system can only make a process being managed more efficiently. This can of course be both negative and positive. The process can be more efficient at being bad and more efficient at being good!

Point 4: Define your processes first and then choose the system that suits them best. Be careful not to tailor the solution too much. Tailoring the software solution can be extremely expensive and hard to maintain.

For example let’s compare to a car: you can take a car that almost suits your needs and modify it to almost perfectly suit your needs.

My super jeep

My super jeep

This car here above for example (my super jeep) has taken me everywhere I want to go in the past 4 years. There it is on top of a mountain in the middle of the Icelandic winter. I drive it on top of the snow and even glaciers, while in summers I drive on bad trails just about anywhere I want.

On top of the Eyjafjallajökull Glacier during the volcanic eruption of April 2010 in Iceland

On top of the Eyjafjallajökull Glacier during the volcanic eruption of April 2010 in Iceland

The same applies for a good software solution. If it is fundamentally good for your needs then it can probably be tweaked here and there to perfectly suit your needs. There are many great CMMS and EAM software solutions out there. You can also adapt them to your specific needs, but in the end it all falls down to how good your maintenance & reliability processes are and how well they can be executed.

Even with excellent software systems, great knowledge and skilled people, you can not get more efficient or productive than what the processes allow them to be.