I watched a video recently where Russ Ackoff said “The difference between efficiency and effectiveness is the difference between knowledge and wisdom.” Knowledge is just information. Wisdom is application of the knowledge. This means that knowledge is useless, dangerous even, if not applied in the right manner. The same is true with efficiency and effectiveness. Consider this sports analogy. I often hear quarterbacks or coaches talk about being more efficient in the passing game. An efficient passing game might mean completing more (all?) passes in the shortest amount of time. Is this really the way to win? What if all the passes are behind the line of scrimmage for no gain? This leads to no points scored and a lost game. But, at least they can pull up the stats and brag about 100% passing efficiency. The opposing team completed only 1 of 40 passes, but it was for a touchdown and the win. Their efficiency was awful, but their effectiveness was better. This is often the problem in production environments. Virtually every production plant or job shop I’ve visited tracks efficiency. Religiously. Many times, this is the main performance metric and bonuses are tied to it. Unfortunately, this is the tail wagging the dog. Effectiveness, as determined by shipping the product and getting paid, is the real goal of the company, right?
Efficiency isn’t inherently bad, but effectiveness shouldn’t be sacrificed for improved efficiency. To go back to our earlier analogy, this is like hoarding knowledge without attempting to gain wisdom. I suppose part of the problem could be that no distinction is made between efficiency and effectiveness or that there is an assumption that increased efficiency must lead to increased effectiveness. This is a common fallacy. I worked with a client that had a lot of hand assembly operations. Their on-time delivery percentage was in single digits. It was aggressively suggested that the problem was poor efficiency. That is, the assemblers should not be working on one assembly at a time but should complete multiple assemblies in parallel because this would be more efficient. The assumption being that this increased efficiency would result in improved effectiveness as measured by better on-time delivery numbers. This is rarely the case.
Here’s an example of how this causes problems. Company X has demand for one subassembly A, but to “be efficient” they release a work order to build 5. The plan is to use one and put the other 4 in inventory. That will put us ahead of the game on later builds, right? Each assembly takes about a day to build. 5 takes 5 days, so it actually didn’t save any time per build. That same assembler is also assigned to do additional work on the job that needed subassembly A. Instead of starting to work on it after one day (if only one subassembly A was built), she doesn’t start working on it for 5 days. This means that we added 4 days to the lead time for that order. Another assembler was building subassembly B, which shares some parts with subassembly A. Since extra subassembly A’s were built, we are now short parts for subassembly B. That’s OK, we’ll just take one of the subassembly A’s from inventory and remove the parts we need. Does this sound familiar? There is more horror, but I’ll stop here since I think I made my point.
Another reason companies strive for efficiency is because they are more focused on costs than revenue. In Eli Goldratt’s classic The Goal, the bean counters can’t understand how the plant can be more profitable (i.e. effective) if the efficiencies are lower. I don’t know where this phrase originated, but I’ve found this to be true of many controllers: “She knows the cost of everything but the value of nothing”. Efficiency is cost-focused, effectiveness is value-focused. Efficiency is a trap.
Don’t be efficient,
Dave