Day 141: My KPI is Your KPI (You Just Didn't Know It)

It's long been said that you can't manage what you don't measure. I'd say there is a lot of truth to that statement, both for managing current state, and for monitoring your progress towards a future state. If you aren't tracking your progress towards some goal, you are not likely to get there any time soon.

Organizations use KPIs, at different levels, to align employees, suppliers, processes. The right KPIs can yield great results.

But if you have been around a while, as I have, you probably have seen the scourge that is Death by KPI... too many KPIs for employees to understand what is important, to help them make good decisions, to help them identify when a process is not in control... The noise can be overwhelming. Equally dangerous are KPIs that result in unintended consequences or behaviours. I call this My KPI is your KPI (you just didn't know it)...

This past week I had a situation where my department was affecting a KPI for another department. We run two production shifts here, and my staff work on the first shift only. One of our tasks is to audit production, and sign off job travelers as we go. Many jobs cannot close until we sign off. So, in some instances, we sign a job off the morning after the work is completed by the afternoon shift. The job is then closed in our ERP system that morning. 

If the product is intended to ship to a customer immediately, we tackle those audits first, to make sure they can meet any shipping cut-off times. The rest, which may be for upstream production jobs or for inventory, are completed afterwards. Our department has not been responsible for any delay in shipments to our customers by prioritizing our work in this manner. 

Recently, the Production group stated to me that my team was causing "late jobs", that is jobs were closing after the planned job end date in our ERP system. As there had been no reported delays of shipments due to my team, I was surprised by this statement, and so decided to investigate further. It turned out Production was being measured on total job completion, regardless if the next operation was an internal one or a customer shipment. So a job that closed, say, less than 12 hours after its planned end date was showing up as late, and Production's "jobs closed on time" KPI was showing less than 100%. Even if it wasn't shipping to a customer for days.

Does this matter? Is it important that less than 100% of jobs are closing on time if the product is not intended to be shipped immediately? 

I struggle with this because my top priority is to ensure that no shipment to a customer is late. One of the top level corporate KPIs here is On-Time Delivery (OTD) - every one in the building knows what it is and how important it is. Our customers do not see value in the internal processes, the internal jobs and their planned movements or transactions within our factory walls. Well, it turns out that many of our planned job end dates leave plenty of room for picking, assembly, test and inspection - typical jobs have 5-7 days of time allocated whereas the actual time required is far less - there is a lot of buffer in these schedules (that is a story for another day).

So I come back to my original question: does this internal KPI provide value to anyone outside of the affected department? 

And if the answer is "Yes", what action should be taken: should they adjust their measurement, should they finish the work a day earlier, or should I adjust my staff's working hours?

The answers, I think, are "No" and "None of the Above".

Here's why I think this: We plan our production jobs on a fixed lead time of 7 days. Lead time is made up of 5 key steps: Queue, Wait, Set-up Time, Run-Time, Move. Our Production lead time includes all 5 steps. Child jobs that feed parent jobs all have the same 7 days lead time, we do not pull out the Queue or Wait times in between these jobs. Add to this that our ERP system plans Start-to-End, in a Push method, and our Production team Pulls work based on End date, no wonder there is this level of conflict. Production has the freedom to pull jobs to start, based on the end date, not on the start date. So a job scheduled to start Monday and finish Friday might not actually start until Thursday. My team has no say in when job actually start in Production, yet Planning has allocated plenty of time to complete and close jobs.

So until we address the lead time for our production jobs, to increase their accuracy for the true Set-up and Run times, then what does an artificial ~12hr difference really make? None - in the eyes of the Customer. Some - in the eyes of the internal customer, particularly if some internal scorecards are affected.... But our schedules are so padded for Queue, Wait and Move, that we should have bucketloads of time to get jobs completed and closed on time.

Another reason I think no action should be taken is that this delay is one of the smallest contributors to late job closing.

Take Production data for May (to date):

- 1577 Jobs of which;

- 1503 Jobs closed on time or early therefore;

- 64 Jobs were delayed in closing (4.06%) of which;

- 21 Jobs were delayed due to any and all production constraints including delayed sign off and job closing (1.33%).

I'll be generous and attribute halfish of the 21 delays to my team, as there are other factors that delay job closing. So 10 jobs delayed by inspecting the next morning makes for 0.63% of all jobs. So for less than 1% difference in job completion, I should add another whole person? No. I want to understand what other production capacity constraints truly exist - like labour shortage, equipment downtime, lack of parts, vendor quality, and so forth. Is a goal of 100% a good thing? Yes! But I haven't seen enough information to suggest that my team's delayed inspection and sign-off is the biggest challenge in achieving that goal.

I guess I'd suggesting that KPIs specific to a group, department or process are useful within that group, department or process if it provides value to those who use it. When KPIs start to creep across processes, departments, groups, it is probably worth engaging the upstream and downstream customers to make sure we aren't driving unintended activity or consequences - most of which are of little to no value to our Customers. The paying kind.

Day -224: Almost a year ago today... my toughest challenge: Comrades Marathon.

One of the things I don't do enough of is reflection. Hansei. So in an effort to look back more, I thought I'd look back about a year ago to a Pretty Big Moment (TM) in my life: 

Completing the Comrades Marathon.

Below is my race report from a bit under a year ago, after I completed one of the toughest road running races out there, the Comrades Marathon. The name is misleading, as it is an ultramarathon - it is in fact an 89km run, between two cities in South Africa (Durban at the coast and Pietermartizburg up and inland). The race alternates direction so there is an "up" year and a "down" year. 2013 was an "up year". The race profile is below - you can see the first half is really an uphill marathon-ish followed by another marathon-ish.

Enjoy* 
*note there may be some potty-words in there - you've been warned

Day 127: Sometimes you have to do it the hard way

Don't get them mixed up

This week, I was lucky enough to help coach and facilitate a Black belt kaizen group. The hosting company was in the financial services sector, so no physical product manufacturing here, but a customer-focused service industry full of regulatory compliance and risk management. 

This brought back fond memories of all that Sarbanes-Oxley compliance work I did over a decade ago...  Ah yes, crying over key and compensating controls, wailing about segregation of duties, fretting about COBIT... Good times were had by all...

Ok it wasn't that bad... But it was interesting to see how other Operations folks looked at the world of Finance.

Beware of talking POO

The process areas of focus were related to user access and permissions within electronic systems and applications. The group was tasked with using lean problem solving methods to map out the current processes, identify the Points of Occurrence (the POO), determine the root causes of the POO, and propose solutions or countermeasures. The value stream mapping used was a 3D version, to show all the cross-functional steps, with a bit less emphasis on times, inputs and outputs (although those could be captured where it made sense).

While the teams struggled to keep on track and on time, they kept plowing along, head down, legs pumping, brains ticking...

Until they tried to devise solutions, countermeasures, improvements. 

Then they were stuck.

But why? These are all smart people. They had followed the process. One or more solutions should have revealed themselves, right? So why not?

Current state process mapped? Check.

POO found? Check.

Root cause analyses done? Check.

So, what now? Let's go through this again, walk me through your root causes there sparky.... 

Ah... Now I see the problem: the team didn't get to the true root cause. 

Which leads me to this corollary: determining root cause is not easy.

Whenever I see a root cause like "not a priority" or "needed more training" or something kind of subjective to the opinion of the day, I always get a bit suspicious. So the solution to that root cause is what? Change the business priorities? Retrain, everyone, again? Really? It's like having a the default solution or corrective action to any issue is "retrain staff" - it's the easy and usually ineffective solution. But people like it - it's hard to quantify its effectiveness, you can check a box ("yup, I trained those guyz") and get a warm and fuzzy, but it almost never sticks. It's the easy, weak way out and it makes me bristle just a bit.

Another difficulty of root cause analysis is that it is easy to identify symptoms, and it is just as easy to convince yourself that a symptom is the a root cause. A favourite example of this is my mom. She will Google almost any medical symptom you can think of, and undoubtedly, she will conclude that she has some obscure disease that will take her from us within the month. Mom: I have this annoying cough. Me: That's no good, have you seen the doctor yet? Mom: No, but Google says I have Killer-Wormie-Thing-In-the-Brain Disease. I'll be dead within the week. You'll have to drive me to the funeral home. How's your Monday looking? Me: Oh mom.... 

Just as nefarious is the perceived relationship between cause and effect. Or more accurately, the relationship between perceived cause and real effect. Sometimes perceived causes are not real causes, but just seem like a good enough cause, a likely, possible or even probable cause. But just because something is possible or even probable doesn't mean it is the true root cause. 

Yaargh maties, where be the polar icecaps?

For example, the graph to the right. Pirates vs. global temperatures. Looks pretty straightforward. It's obvious we need more pirates right? More pirates means happier penguins? While it is possible that the global decline in high-seas piracy contributed to the increase in average global temperature, the actual probability of such a connection is about, oh, one in a gajillion. Just because something is possible does not mean it is probable. So looking at the easy way out, the symptoms, the softball answers to tough problems isn't going to get you real results. Certainly not anything sustainable.

This is what happens when you only ask "Why" once. Unless you are Chuck Norris, you better ask 5 times.

Day 113: I am sometimes my own worst enemy

Last week, I slipped and fell, hitting my head resulting in a nice goose egg on my forehead and a shiner. I was rushing to get home, and not paying attention, thinking about what I needed to do once at home, and even the next day at work. I completely missed a top step and WHAMMO! Stars.

While returning to work with a black eye allows one to make up all sorts of fun stories for their co-workers, it reconfirmed something I had always suspected: I am my own worst enemy.

I think I have accomplished a lot in my days - and I know much of that is due to a combination of stubbornness and optimism. Too stubborn to give up and eternally optimistic that I can do it! However, I have also had some really epic failures (none of which I will share with this peanut gallery). OK, knocking my noggin isn't "epic" but you get the idea.

I had a few days to think about my latest debacle, and what might have caused it. My preference to think ahead of where or when I actually am at any moment in time was definitely a factor, or perhaps more clearly stated, my preference to NOT focus on the present, the here and now, was a big part of why I missed that top step.

Being able to anticipate changes, being able to plan "what's next", being able to see around the corner as it were, can be a great asset. But not if I am so focused on what's ahead that I forget to take in where I am now. I don't like not moving, not doing; I have difficulty just being. And I'm not talking just about relaxing, it's something more than that. Perhaps it's because I know there is so much out there, in the big world, and I don't want to miss any of it. Perhaps, it's that to stop is to stop learning, to stop experiencing. Or perhaps it is because I am not satisfied with where I am at the present. 

It may be some or all of those things. But now that I am aware of it, I hope I will see when I am trying to sabotage myself by not being in the moment. Kind of like trying to break a bad habit you don't realize you even have. Once you know about it, it seems so obvious.

AMac