Author: Mark

Posted on

Beyond the Value Stream

As I mentioned a long time ago, Art Smalley’s web site, http://artoflean.com, is an excellent resource for learning. His thinking is cutting edge – he has kept up in the field.

I am mentioning it here because he has a couple of really good resources available.

Learning From Toyota is a presentation that challenges some of the conventional thinking about what “lean” is… or better, contrasts the current “lean industry” from Toyota’s thinking and approach.

The Eight Basic Questions of TPS is a longer article on the same topic.

In both cases, Art emphasizes that the classic approach of mapping value streams and implementing flow cover only a very small fraction of what makes up the system. Indeed, in my opinion, those steps will uncover (e.g. confront) many more previously buried problems than they resolve. Yet so many practitioners, many of them even taking your money as consultants, never go beyond these basic steps.

Look at the “classic” questions and Art’s questions, and see for yourself how different the path is.

Posted on

Belts, Jonahs and Senseis

Jim’s comment in the last post on “Lean Certification” rhetorically asks “…why are there Six Sigma Black Belts?”

Interesting question. It brings up one of the very fundamental differences between the Toyota Production System and a couple of other popular disciplines, notably Six Sigma and Theory of Constraints. Both of these other disciplines have certified practitioners.

Six Sigma certifies “Black Belts” plus five other flavors under a program defined by the ASQ.

Theory of Constraints has “Jonahs” which are certified by the Goldratt Institute.

I am emphatically not going to get into a discussion about the relative merits of these systems. They are all based on the same fundamental principles, and will all deliver exactly the same results if they are applied consistently and universally. Many of the debates come from people trying to compare sub-sets of understanding. Many of those debates are fueled by the fact that people have considerable time and possibly money invested in “the way.”

But one key difference between the Toyota Production System and the other two is the origin of knowledge about them.

Theory of Constraints was deliberately designed.
Six Sigma was deliberately designed.
The Toyota Production System organically evolved.

That is not to say that TOC and Six Sigma are not evolving. They must evolve if they are to deal with problems that were not anticipated by their original designs. But those seeking to understand them go to the official repository, and learn the official, latest, version. There is a definition of “complete knowledge.”

Contrast this with Toyota’s system. It was not deliberately designed, it evolved. Certainly there are people with very deep understanding, and certainly if you visit a Toyota operation there is a system in place.

However those seeking to understand it must learn by study and research. Academics study Toyota and application of their system, trying to figure out how and why it works. They ask questions like “What is different about Toyota’s application and everyone else’s?”

In order to answer those questions they must make observations, develop hypotheses, make predictions and test them.

As a result, our understanding of why the Toyota Production System performs as it does has evolved over the years. There is no standard for complete understanding, there is only “keeping up in your field.”

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.