Author: Mark

Posted on

“Certifications” – Buying Credibility?

There has been an uptick in chatter about “lean certifications” in various forums lately. For anyone considering getting some kind of certification, I’d like to pose some things to think about, especially before you pay a lot of money to someone to “certify you.”

There is no standard definition of what “lean” is. Anyone claiming to certify you in “lean” is simply certifying to their own standard.

Toyota does not “certify” people. They mentor, they train, but do not “certify.”

Anyone making a big deal over calling themselves a “sensei” probably isn’t. There are a few exceptions, mostly people who spent 15+ years working directly for Taiichi Ohno, or perhaps some next generation people. The term “sensei” in those cases is one of respect, not a title or defined level of understanding.

There is no test you pass to become a “sensei.”

It is, in my opinion, totally impossible to demonstrate the necessary knowledge and skills with any kind of written exam. It is much more about how well someone interacts with people to teach and guide them through solving problems than it is knowing how to calculate takt time of a feeder line.

How good a certification looks on a resume depends on who is reading it.
I suppose there are hiring managers out there who buy this. I have certainly seen more than a few “Help?” posts by people hired for expertise who don’t know how to break down a value stream and figure out where to put a pacemaker.

When I am reviewing resumes of someone claiming lean expertise, I look at the whole story. A “certification” means you have gotten some formal education, but doesn’t tell me you can actually put any of it to use. I will use that certification as a starting point for questions. My questions try to draw out:

How did you learn this stuff? Are you still learning? Or do you think you already know it all?
I will try to get you to tell me some stories about how you have taught people, and what you learned in the process.
I will ask questions trying to draw out your understanding of jidoka, andon and problem solving as critical components to the management system. What I am looking for here is where you are on a continuum of understanding from “implement the tools” to “creating a deep culture.”

A certification, by itself, does not add to or detract from your credibility – unless you come in believing that “being certified” automatically means “being qualified.” If that is the case, you probably didn’t make it in the door, and if you did, my bullshimeter is likely to peg about 90 seconds into the interview. I’ll keep at it, because sometimes people don’t know what they know and I give the benefit of the doubt for a long time, but if a “certification” is all there is, then there really isn’t much.

On the other hand, if you are looking for your own professional development, and look at a program for what it is: An academic education, and possibly an opportunity to establish professional network, then go for it. Just don’t go in believing that “being certified” means a whole lot else.

Posted on

Anchoring a Problem Solving Culture

More than a few organizations I know are starting to understand the importance of establishing a culture of problem solving. Hopefully they are shifting from a tools implementation model to one which emphasizes how people respond to the daily friction generators.

In an email on the topic to a friend today, I cited four things that I think need to be there before this can be achieved. Upon reflection, I’d like to expand upon and share them. I think I can say that a lot of the failures I have seen can be traced back to only emphasizing one or two of them.

The organization must reset its definition of “a problem.”

I started to get at this mindset back in January with the post “Chatter as Signal.”

In “traditional” organizations something is labeled “a problem” when it causes enough disruption (or annoys the right (wrong?) person). Anything that does not cross that threshold is tolerated. The “problem” with this approach is that many small issues are ignored and worked around. Their effects, though, tend to clump and cluster into larger cumulative symptoms. When those symptoms reach the threshold of pain, someone starts wanting some kind of action, but by now it is too late for simple solutions.

Another face of the same thinking is the “big problem” syndrome. “We can’t fix everything.” “We have to prioritize on the big hitters.” True enough, but it is not necessary to fix everything at once. That’s the point. Sure, prioritize the technically tough problems. But, at the same time, put the systems into place that allow everyone to work on the little ones, every day.

When the “big problem” statements are used as a “can’t do it” or “we can never be perfect” excuse, the organization’s underlying mindset has dropped into the ”

The “Chatter as Signal” attitude really means instead of putting together plans and processes and then tossing them over a wall for blind execution, the problem solving organization systematically and continuously checks “reality” (what really happens) against their “theory” (the plan, what they expect to happen). Whenever there is a difference between the two, they look at that as “a problem.”

Maybe the term “problem” is unfortunate.

A lot is made out there about being truly forward-looking organizations seeing “mistakes” as opportunities to learn. A “mistake” is nothing other than an instance of “We did this thinking some specific thing would happen, but something unexpected happened instead.” Or “We thought we could do it this way, but it turns out we couldn’t.” In different words, those events are “the outcome wasn’t what we planned” and “we couldn’t execute the process as planned.” In other words, “problems.”

In summary, specify what you intend to accomplish, how and when you intend to do it.
Any departure, necessary or inadvertent, from this specification is a problem.

The organization must have a process for immediately detecting and responding to problems.

It doesn’t do much good to define a problem unless you intend to respond. And you can’t stand and watch every second for problems to occur. That is the whole point of jidoka. When Sakichi Toyoda developed his loom, the prevailing common thinking was “sometimes the threads break.” “When that happens, some material is ruined.” “That is reality.” “Perfection is impossible.” Chatter is noise.

But Sakichi changed the dynamic when he designed a loom that detected a broken thread and shut itself down before any bad material was woven. Now I am fairly certain that, even today, threads break on weaving equipment. (And the same technology developed by Sakichi is used to detect it.) So, as a jidoka, this is a case of detecting a small problem and containing it immediately so it can be corrected.

Consider this: If the organization really understands jidoka then any problem that goes undetected is a problem. Thus, it isn’t necessary to fix it all at once. Rather, when problems occur, get back to where they occured. Look at the actual situation. What was the very first detectable departure from the intended process? It is quite likely that it is a small thing, and also likely it happens all the time. But this time it didn’t get caught and corrected.

Then ask: Can you prevent this departure from process?
If you can’t, can it be immediately and automatically corrected?
If not, can the process be stopped?

But detecting the problem is only the first step. The response is even more important. When a Team Member (or a machine) detects a problem and calls for help, a real live human needs to show up and show genuine interest. The immediate issue is simple: Fix the problem. Restore a safe operation that produces defect-free output. That may take a temporary countermeasure involving some improvisation, and may compromise speed and cost a little, but safety and quality are never compromised for anything… right?

The next step is to start the process of actually solving the problem. At a minimum, it needs to be written down and put into the “We’ll work on that” management queue (See the next item) to get solved. Note that “fixing it” and “solving it” are two completely separate things.

The organization must have a process for managing problem solving.

When a problem occurs, the first response is to detect it, then to fix (or contain) it. That is jidoka. But at some point, someone has to investigate why it happened, get to the root cause, and establish a robust countermeasure.

Again, I have talked around this in a couple of previous posts:
Systematic Problem Solving
A Systematic Approach to Part Shortages

However it is done, however, the organizations that do it well:

  • Have a public written record of what problems are on the radar. The most common approach is a board of some kind in the area where the daily review takes place.
  • Did I just say “Daily Review?” There is a process to check the status of ongoing problem solving activity every day. Problems being worked on do not get a chance to fall off the radar.
  • They manage their talent. The organization I talked about in the “Part Shortages” story had a lot of problems, not just in part shortages, but technical issues as well. Initially they had been assigning each problem to someone as soon as it came up. That quickly became unworkable because, in spite of their tremendous talent, the key players really couldn’t focus on more than one or two things at a time. It was demoralizing for them to get hammered at the meetings for “doing nothing” on five problems because they had been working on the other two. The countermeasure was a prioritized pull system. Each new problem went into a queue. As a problem solver became available (because s/he was done with one), the next problem on the list was assigned. The prioritization system was simple: The manufacturing manager could re-sequence the queue at any time.Thus, the problem at the top of the list — the next one to be assigned — was always the next most important. But it was another important rule that made this work. No one could be pulled off a problem s/he was already working on in favor of a “hot” problem. The only exceptions were a safety issue or a defect that had escaped the factory and had been reported by a customer. However you manage it, keep these things in mind:
    • Don’t arbitrarily multi-task your talent. People can’t multi-task. This is actually overloading. The other word for it is muri.
    • Don’t jerk them from one thing to the next without allowing them completion.
  • They solve the problem at the lowest level of the organization capable of solving it. The corollary here is largely covered below, but it bears mentioning here: If the level that should be solving it isn’t capable then they work THAT problem – developing the skill – rather than ignoring the issue or overloading someone who is never going to have the time to work on it. This is probably the most important lesson in this piece.

They deliberately and systematically develop their problem solving skills at all levels.

It is easy to fall into the trap of assuming that someone with a technical degree is a skilled problem solver and critical thinker. Experience suggests otherwise. And even if there are a couple of people who just have the innate talent, there are not enough of them to go around. There are lots of approaches out there. In reality, all of the effective ones are anchored in the same thinking, they just use different tools and lingo to frame that thinking. My best advice is pick one, teach everyone to use it, then insist that they follow the process exactly. Only by doing that will you actually learn if the process itself has weakness or shortcomings.

Along with this is don’t confuse the tools with the process itself. THIS IS CRITICAL: Anything you draw on paper (or create in a computer) is a tool. The seven problem solving tools are not a process. A statistical control chart is not a process. An A3 is not a process. A cloud diagram is not a process. All of these are tools. The framework in which they are used is structured thinking, and that is a process.

This is important because the process itself is straight forward and simple. It can be taught to anyone. Teaching them the tools, however, teaches them nothing at all about how to solve problems. So many “problem solving courses” spend a week teaching people how to build Pareto charts, histograms, tree diagrams, run charts, even build control charts, and yet teach nothing at all about how to solve problems. Most problems can be solved by unsophisticated troubleshooting techniques that systematically eliminate possible causes. Some can’t, but most can.

This got long, but I guess I had a lot to say on the topic. In the background, I am planning on putting together some basic material on “the process of problem solving” and making it available. Hopefully that will help.

As always, comments are encouraged and appreciated. It tells me that someone actually reads this stuff.

Posted on

Computers and Muda

In a short, but interesting, thread on lean.org, Emma asks an interesting question: “Can an IT system support Lean?” She goes on to point out a general trend she has seen where the “kaizen guys” offer a lot of resistance to the introduction of sophisticated I.T. systems.

“Lean” stuff aside, I offer this recent post on Tech Republic, “The Seven Habits Of Wildly unsuccessful CIOs.”

Though the article is written about individual CIO’s, it applies to the sub-culture of information technology in general. However, there are a few points where I think the scope should be expanded.

#1, “Acquire technology simply because it’s new” talks mainly about upgrades. I would expand this to discuss “Acquire technology simply because it’s cool.” I.T. folks are biased toward computerized solutions. Now that’s great, and it is what we pay them for. But often there is a simpler way, perhaps with the information system as an enabler rather than the centerpiece. One of the fundamental principles we taught at a previous company was “Simple is best.”

In #3 “Create solutions in search of a problem” the article emphasizes off-the-shelf solutions vs. an in-house solution to everything. Again, though, I want to take the title of the paragraph and expand the scope. Just because it is slick and “does this” and “does that” does not mean it is useful. More features, and for that matter, more information, is not necessarily better. I want just what is necessary for the next step in the process. Any more provides a distraction, an opportunity for error.

#4 “Reach beyond the competency level” is classic. If you don’t know how to do it, please don’t say you do. It is OK to take on an experiment, but please control it and understand it before it is imposed on everyone. And make sure the “solution” solves a “problem.”

#6 “Failing to understand the relationship between technology and business” – read the technology chapter of “Good to Great” and “The Toyota Way.” Those both offer great insights on how great companies use technology as a multiplier without making it a boat anchor.

If you are an I.T. person, and are encountering the same push-back that Emma is from your kaizen people (or for that matter, push-back from anyone), I would recommend you read the article. Then do the following:

For each key point in the article, write down how an I.T. organization that does exactly the opposite would perform and behave with its customers. This is creating the idea of the ideal supplier.

Then take a hard look in the mirror. Compare your actual attitudes, beliefs, behaviors with that list. Talk to your customers, and ask them how they perceive your organization.

You are likely to find gaps between the ideal state you defined and your actual performance. If so, develop a plan to close those gaps.

Posted on

Financial Transparency 2

A couple of interesting comments to the last post (as well as the original question) got me thinking some more. I’d like to go back to basics.

There are no specific practices and behaviors that are “lean principles.”
I believe the principles operate at a higher level. The principles have to do with creating a culture in which people naturally surface and solve problems, supported by the organizational and workplace structures.

In this case, “financial transparency” may, or may not, be found as an attribute of companies that are otherwise doing very well establishing this culture.

Financial transparency is a countermeasure, not a principle.

A countermeasure would be applied against a problem which, if not solved, prevents the organization from taking a step toward the ideal.

Some organizations’ paths may take them to or through a problem where financial transparency is the solution.

Some organizations may take other routes and never need to address that. For example, if they otherwise operate with 100% integrity, and there is solid trust.. is there a need to disclose everything?

So it is entirely possible that two, otherwise similar, organizations may have reached the same point on their journey by doing different things.

Now, there are some countermeasures which are nearly universal because they address issues nearly everyone has. (note that I say “nearly”.. never say “all” in this business.)

Without a culture of trust, for example, people in the organization really cannot contribute. They have to come to work, do exactly what they are told, and go home.. knowing full well that the things they did today are probably stupid. Doesn’t exactly help them feel like winners, does it?

But while financial transparency certainly reflects a degree of trust, it is neither necessary nor sufficient to generate it, and I guess that is the key point here.

Posted on

Financial Transparency – Is it important?

Steve Fonseca asks an interesting question on The Whiteboard.

Are lean companies really transparent with their customers and suppliers as to cost/profits. Is this a lean principle or not, or to what extent?

I am going to offer an opinion, then perhaps other readers can chip in.

First, there is no real definition of what is, or is not a “lean principle.”
Second, there are infinite shades of the term “financial transparency.”
Thus, there is no definitive answer to the question.

So, in my view, I don’t really see a correlation. Nor do I see a significantly greater degree of openness as a prerequisite to success with infusing a culture of continuous improvement.

Toyota is publicly traded, and as such, is really restricted by insider trading laws on how much financial information they can share with customers / suppliers short of sharing it with everyone.

Anyone else? What have you seen out there? Does a degree of financial transparency, above and beyond what is normal in business relationships, offer a significant competitive advantage, or drive continuous improvement faster?

Posted on

Theological Debates

A frequent topic in the lean.org forums is some version of “what is the difference between lean and ____” where the blank is one of the industry buzzwords. Some of the common ones are various prefixes to “Sigma.” Others are old standards such as TQM, SPC, TOC, etc. These discussions are always interesting as the various camps line up. “Lean looks at waste, while xxx-Sigma looks at variation” is a common one. Apparently “Agile” is about high-tech machinery, and of course, none of that is found in “lean.”

My put on all of this is pretty simple. It’s all the same, people.

There is nothing about TPS that excludes any level of machining technology, so long as that technology is applied as a solution to a problem rather than for its own sake. The last time I checked, Toyota, and TPS, were obsessive about stamping out variation. Constraints? Yup. You bet I know what the constraint is, and you bet I manage it tightly. If I have done everything right, my enterprise constraint is production (rather than sales), but just barely. And internally, if I have done it right, my constraint is manual work rather than technology. Why? Because every Team Member can work on improving manual work cycles. Not the case with an engineering constraint.

In the end, this is all about the rational, deliberate application of skilled problem solving, using the scientific method, aka PDCA.

If you are looking at “which one to implement” stop fretting about it. Go out to your work area, stand and watch a while, see what is stopping your good people from doing a great job, and start fixing it.

Posted on

Refuting Lean

On the backside of this site, I get information about things like the search terms that brought people here. One caught my eye today.. “lean refutation.”

Since this site comes up as the 121st item in the Google search, I think I am safe to conclude that the person intended “lean manufacturing” to be the topic. The hit, by the way, was on the “Management Resistance or Poor Process” post, which I suppose has some relevance to the search as well.

I can speculate about a lot of reasons that would cause someone to search for that kind of information, but ultimately I suppose it is someone either caught in the midst of a company (or a consultant) with a distorted view of what it is all about; or someone whose comfort zone is being violated pretty badly (or a combination of both).

Here is a question for my readers:
Inverting the problem, how would you “refute lean?”
Then, based on your answer(s), what countermeasures would you develop?

I think it is important for us to understand that there are both distorted views of what this is about (and those distorted views are being enthusiastically implemented in a lot of places); and there is a good chance that people’s comfort zones can be violated.. and many of those people are ones we want to bring along.

Posted on

Accurate Forecasting

Why can’t we get a more accurate forecast from sales?
Manufacturing managers the world over have the same complaint.

Maybe the word “forecast” is tripping everyone up.

A forecast is a prediction. Maybe it is based on some kind of market analysis, maybe even asking the dealers what they think they will sell. It could be based on a lot of things.

Once a forecast is complete, it is regarded as the best guess for how things will pan out, but those things are (felt to be) largely beyond our influence.

We forecast weather. How many hurricanes will we have this season? Will it rain on the outdoor wedding? Tides are forecast (accurately, but we can’t change them).

A competitor’s sales might be forecast, because we really don’t know their plan.

A sales forecast gets put together, approved, agreed, and entered into the data system.

Then two things happen.

Manufacturing bets the farm on it. They order long-lead parts, establish production plans, set factory capacity. They decide, based on that forecast, how much money is going to be spent, whether anything is actually sold or not. Those decisions often have to be made months in advance.

Meanwhile, all too often, sales has forgotten about the forecast, except perhaps, the top line sales figures. They work hard to sell whatever they can. They push for the big order. They offer the world to prospective customers. They will offer discounts, then push for higher unit volumes to close the dollar targets. Many times they operate on a quarterly (or worse) cycle.. as long as they have a great June, then April and May don’t matter so much.

Meanwhile, back in the factory, when April and May have been dry, they get slammed on June 4th, and end up expediting in parts (at great expense), and working overtime (at great cost), to make product that was sold at a discount.

This is no way to make money.

Let’s get back to what I think is the original issue – the word “forecast” meaning “prediction” (or “educated guess”).

Let’s change one word.
Sales Forecast Plan

That changes the entire meaning.

A “forecast” is a prediction of some event we have little or no control over.

A “plan,” on the other hand, is a set of actions which, if carried out as intended, are predicted to give a specific result. This is a different kind of prediction. This is the kind of prediction that an engineer makes. She analyzes her design, applies her considerable understanding of materials, structure, load transfers, then she predicts at what point that design will fail. If it is a brand new design, it is often tested to destruction (like a new airplane wing). This isn’t to test the design so much as to validate the models used for the prediction.

Sales isn’t engineering, I know that. It involves the most complex thing we know about – human psychology.

The sale planning process goes roughly like this:

  • Financial, margin, volume targets to hit the higher level strategy for profit and growth.
  • What must be sold, when, where to hit those targets. There may be more than one set of options.
  • What must be done to achieve those numbers. This includes consideration for:
    • Unit volumes and mix. (Which are really the only thing the factory cares about.)
    • Total profit targets.
    • The margins that have to be held to hit those profits, at those volume and mixes. (Yes, sales is responsible for margins and profit.. how much money the company can actually keep, not just top line results. “We’ll sell it at a loss and make it up in volume” is not a long-term strategy to stay in business.)
  • Then a process of looking realistically at what must be done, what can be done, deciding on a course of action, and producing a detailed plan to carry it out.

That sales plan then plugs into a production plan. Where there are planned fluctuations, we can apply planned levels of buffer inventory – FIFO inventory, not just make-to-stock inventory, to allow a small time disconnect between when it is made and when it is shipped. This is part of heijunka. (This works in both make-to-order and make-to-stock models, only the mechanics differ.)

Now the entire organization can carry out PDCA.
Are the activities in the sales plan being carried out, as planned, when planned?
If not, why not?
Are they producing the results that were intended predicted? (One-by-one confirmation.) No? OK, what have we learned that we can apply to making a better prediction next time? AND, most critically, What else are we doing to do, because we still have to hit the numbers!

And hit the numbers we must. Not by the end of the quarter. By the end of the month to start. Then in two week increments. Then in one week increments. (And all of this assumes you are making and selling something that doesn’t spoil if it is sitting on the lot for a week.)

The sales plan is the production plan for sales. It is not a guess at how well they will do Just like the manufacturing production plan, it is a firm commitment on how they will support the organization’s overall goals. Yes, reality intrudes and plans rarely get carried off exactly as written. But the thinking that went into making the plan, and the commitment to deliver the results, means the organization, as a whole, is prepared to deal with the unexpected and still stay on track.

Is this idealistic? Absolutely. It is pursuit of perfection. But until the thinking is in place, we will be stuck where we are… waiting for something outside of our control and hoping.

Posted on

Costs and Kaizen

How does kaizen actually show up on the bottom line?
This is a question that gets asked a lot, and honestly, we owe the asker a better answer than “it just does, trust us.” (Even though this is true.)

Here’s my thinking – it shows up two ways.
One is intangible. By that I mean it is incredibly difficult to quantify, even afterwards. But it is there.

IF the organization manages to get the continuous improvement engine running – meaning they understand that “pursue perfection” is not a “step in implementation” but rather the thing that gets it going in the first place – then, over time, everything starts running more smoothly.

It is hard to put a hard-monetary return on things like:

  • Everybody is working together, as a team, toward the organization’s overall goals.
  • Everybody understands who the customer is, and keeps their focus there.
  • Every instance of a problem causes the organization to improve and learn.
  • Everybody comes to work knowing what they must do to succeed; knowing they can do it; knowing that, if there is a problem, they will find out right away; knowing that they will get support in resolving it.

In short, the organiztion performs, and that performance is getting better and better.
What is that worth? Is it better to have a superbly performing organization, or one which requires continuous micro-management of every detail? (Hint: It isn’t about hiring better people, it is about creating working conditions and processes where regular, competent people can create superb performance.)

But it is possible to understand some direct, tangible returns as well. In fact it is possible to set solid targets, understand what must be done to reach them, and track progress on activities and results.

Any organization that is self-funding (including a non-profit) must offer some kind of value to its paying customers. If “value” is what the customer is willing to pay, then it is easy to determine the, ah, value of the value.

“Value add” defines the economic result of a transformation process. We buy some stuff at some cost (value), transform it into something that is worth more to the customer, and sell it. The difference between what we paid for the stuff we bought, and what the customer paid for the product or service we sold is the “value add.”

Note that this has absolutely nothing to do with what it cost to make that transformation. Nothing at all. It is possible to add value and lose money at the same time. It happens every day.

It does cost something to run the operation that adds the value. When those costs are less than the total value added (over some period), then the organization gets to keep some of the money as profit.

When those costs are more than the amount of value added, then someone has to fund the gap – the owners / shareholders, debt, the money has to come from somewhere.

When it comes to costs, I like to keep things really simple and easy to understand.

Costs are incurred two ways, and in the details, they intermix.

  1. In order to operate, we spend money every day on things like payroll, rent, utilities. This is cash burn.
  2. We have stuff needed to operate. This is cash tied up in the business, capital, inventory, etc. Just having that stuff costs money, and a lot of this stuff depreciates. That depreciation can, in turn, be counted the same as cash burn, but real life is more abstract than that because, while payroll must be paid, “depreciation” is something we can hold our breath about.

I have not included the cost for materials that are transformed into finished product here. That cost is captured in “value add.” The above two things add up to the cost to add that value, and those costs are largely fixed (in the classic sense of the word), whether we make anything or not.

Aside from the actual materials that are bought, transformed, and sold, there are very few truly “variable costs.”

“Continuous improvement” means to continuously increase value add, and continuously decrease what it costs to add that value.

There are fundamentally four ways in increase value-add.

  1. Improve the product offering so that customers will pay more. Ideally this is done without increasing any costs. This is really the only leverage point of purely service businesses.
  2. Pay less for the raw materials and parts – push your suppliers for lower prices.
  3. Change the engineering design to one that is less expensive to source.
  4. Examine your make / buy. Look for high-leverage items that your currently purchase. These are items which:
    1. We could make if we wanted to.
    2. Have a very high differential between the cost of the pieces and what we pay for them. (i.e. the supplier has a very high value-add to us.)

    Now, here’s the rub (and where this ties in to kaizen). If you have been doing a good job at kaizen, you have made some people available. If you know how to make these high leverage parts, can you put those people to work making them? A lot of this depends on the capital required, etc. but, as a general rule, the further up the supply chain you reach, the higher your value add. It comes down to capability and cost. And if you are using labor made available through kaizen, it does not matter what this labor costs. If you are adding more value today than you were yesterday, and incurring exactly the same costs to do so, your profit is higher. And the last time I checked, that was the name of the game.

Aside from increasing value-add, the other objective is to do so at the lowest possible cost, and there is a bit of a circular reference here.

Good kaizen can free up a lot of time. I suppose, if you wanted to do scorched-earth kaizen, you could immediately lay those people off. (Don’t expect much help with further improvements after that.) Aside from the ethical issues, these kinds of actions are really disruptive to the organization, in ways that are difficult to quantify.

If you are trying to simply increase production volume (the right kind of problem to have), then dealing with this issue is fairly simple, you just avoid hiring more people. You increase output without increasing payroll.

But also take a look at the in-sourcing option mentioned above. A lot of organizations overlook these kinds of opportunities today.

Like I said, this model is very simple. It is essentially the “throughput accounting” model offered by the Theory of Constraints folks. (Believe me, I don’t just make this stuff up.) Traditional cost accounting models can be mapped directly into this model. I just find it a lot easier to understand, and more importantly, to explain to the people who actually have to make all of these things happen.

Posted on

There Are (almost) No Big Problems

In a “management by metrics” world, problems are detected when performance indicators are off track. Perhaps inventory is too high, first pass quality is a problem. Maybe operational availability is tanking.

Once the problems are abstracted into numbers, the numbers become the problem. The solution, then, is usually a directive to reverse the trend, to improve this measurement or that measurement, to get things back on track.

Here is the rub: The numbers aren’t the problem. They don’t even tell you what the problem is without a whole lot of investigation, digging, and stratification. And why was this investigation and stratification necessary in the first place? Because now you are trying to sort out a batch of problems that weren’t dealt with, one-by-one, at the moment they occurred.

The further you go up in the organization, the more things are aggregated and summarized. And the more they are aggregated and summarized, the more things look like big problems, even though they are composed of many (hundreds, sometimes) of little problems.

Let me cite an example. I was in a factory where the site manager was proudly showing off his real time display of Overall Equipment Effectiveness (OEE). Each time the equipment slowed, for any reason, the display would immediately change. He could see, at an instant, how the day’s OEE compared with his target, and, he said, “take action.”

But exactly what action is he going to take?
Even the real-time display lags the actual problem.
Two weeks ago a lubrication point was missed. Today something is overheating, and we need to slow or stop the machine to deal with it.

A bracket securing a roller is loose, today the machine is stopping all the time as they clear jams.

A hole in a screen let chips and debris clog a filter, and the coolant pumps are overheating.

This list can go on. The point is that the things that actually slow down or stop the machinery are second, third, fourth levels in chains of events. The actual problem had no immediate effect on the machinery.

In this system, the very best they will ever do is fix it fast and hold the number at some level. They will never be able to actually improve it, because they aren’t dealing with the underlying systemic issue: They aren’t finding and dealing with the actual root causes.

When you get to financial measures, things are even more abstract.

Inventory levels (or inversely, inventory turns) is a great example. “We have too much inventory!” “Our inventory levels are above the industry norm!”

In the boardroom, or in the Chief of Operations’ office, this is all they can see. Because most leaders in that position really like direct action, they.. um.. “direct” that some “action” be taken.

So the organization goes to war against inventory.

Two levels down, “We have too much inventory” is still characterized as the problem because that is what they have to report every month.

Two more levels down it is often still attacking the symptom – too much inventory.

But inventory isn’t the problem.

The problem is an engineering change that missed one part on the bill of material update, delaying production for a day while all of the other parts continued to roll in.

The problem is a paint system that is unreliable, so the factory obsesses on maintaining four hours of buffer on either side of it.

The problem is pressure to keep the line moving, so people work ahead, and push incomplete or problem units into the “hospital” for later repair.

The problem is that the upstream processes have to be ready to respond to massive fluctuations in assembly’s demand.

The problem is a broken jig, local initiative to make something else instead, resulting in too much of what nobody needs and none of what they do – because they don’t want to waste time doing nothing.

An additional problem is that the typical organizational response to these problems is to add more inventory because each local unit needs to protect itself from the dysfunction problems of their suppliers and customers.

Worse, just “taking out inventory” is going to tank everything else because the underlying problems are still there.

Inventory isn’t the problem.

The problem is that each of these small problems is too small to bother addressing as a systematic breakdown that leads to “too much inventory.” While the high-level leaders are looking for a big problem, they are missing their real responsibility.

It isn’t to “do something about inventory.”
It is to ensure that the small problems that occur every day, the ones which cause all of that inventory to accumulate in the first place, actually get addressed. Actually no. Their responsibility is to ensure there are systems in place which catch those problems and address them. They do this by teaching, setting example, then checking.

Leaders – if you want to “do something about inventory” you have to do it by setting an expectation that:

  • Processes are well defined.
  • Those processes are followed.
  • When there is a problem following the process, it is raised immediately.
  • When a problem is raised, it is swarmed, fixed, understood and prevented.

You handle big problems by making sure the small ones are dealt with, every day, all day.

Then your OEE will go up quickly. OEE is an indicator of how well you respond to problems, not how well your machines run.

One more thing – for my Health Care readers.
You can substitute “medication errors” for any of this. But until there is a system in place that alerts anytime someone spots the possibility of confusion, medication errors will occur at pretty much the same rate they always have.