I work for an operations project where we refine images. I have a team of 50 resource whose target is to refine 60 images per shift per resource (8 hours). (i.e 7.5 images per hour). Unfortunately sometimes we face downtime and work doesn't get saved for few due to tool issues. 

While calculating a resource's weekly production how should I consider that loss of work due to system issues.

Eg: Resource A has produced 255 images in a week of 40 hours with 6 hours of system issues. How should I rate his production when compared to others? ( While other employees have different hours of system issues ) 

Option A: Should I remove number of hours lost from denominator?

Production %: 255/(36*7.5)

Option B: Give the employee targeted images for those 6 hours? 

Production %: (255 + (6*7.5)) / (40*7.5)

mattpalmer's picture

Trying to "bulk out" the production numbers by adding the "targeted" production numbers will skew your results towards the goal, and if someone else looks at your numbers and misinterprets them, they might think you're trying to claim production you didn't actually achieve.  Instead, by reducing the "available production hours" (best to have it as a separate column on your spreadsheet, so it's clear where the magic numbers are coming from and what they mean) you're keeping a clear track of what's actually happened, and you can extrapolate full-time production (with no downtime) by simply multiplying the actual-images-per-hour against your full-time hours available.

mike_bruns_99's picture
Licensee BadgeTraining Badge

One of the very few times I disagree with you Matt.  To me, both options are bad.  Leave the downtime hours in the total.

Unfair, maybe. But the "TEAM" is responsible for the production. The customer doesn't care or pay for the downtime.

Interestingly, when the downtime is removed from the target, downtime tends to increase. It's an excuse. I've seen people sabotage equipment when they were under their targets.  Just so they could say “not my fault” for missing their target.

When people are held responsible to meet their targets, no matter what, it encourages better performance. Maybe they should take better care of their equipment. Maybe there are backup ways or machines to work around the problem. Maybe the person has a suggestion to improve the reliability and reduce the downtime.

Someone else’s failure to deliver (downtime in this instance), should rarely be an excuse for a direct’s failure to deliver.

naraa's picture
Training Badge

There is another thread with the same post in

I just put a comment on it.  I agree with Mike, I think productivity should not have the subtraction of the downtime.  The number with the subtraction is also good to track because when the productivity is not good, people could complain it is because of the downtime, and so because they can not meet the target they may not even try.  By tracking the number, which I would call resource efficiency, you can immediately see if the downtime is responsible for the lower productivity and focus on what you can do with regards to the downtime.  Or praise your people if they archived the productivity goal even with the downtime (which is also possible).


mattpalmer's picture

Yes, there are a variety of situations in which you may want to wangle the numbers differently.  If you're suspicious that people are playing Luddite, and sticking their shoes in the machines, then sure, you might want to account for that somehow.  If you want to give total production averages to the *customer*, you probably want to provide productivity per customer-dollar spent -- doing otherwise just encourages optimising the wrong thing.

But neither of those is the question being asked.  We're talking about calculating the productivity of an individual, so they can be compared to *other* individuals.  That's it.  In that sense, it is completely wrong-headed to somehow blame them for inability to produce when it is outside their control.

Sure, I'm making an assumption here, that the individuals involved *don't* have control over when they can't produce.  If that assumption is wrong, OK, but I don't see any indication of that, so let's answer the question that's given, rather than assuming facts not in evidence.