Category: Quality

Posted on

A Morning Market

In past posts, I have referred to an organization that implemented a “morning market” as a way to manage their problem solving efforts.

Synchronicity being what it is:

Barb, the driving force in the organization in my original story, wrote to tell me that their morning market is going strong – and remains the centerpiece of their problem solving culture. In 2008, she reports, their morning market drove close to 2000 non-trivial problems to ground. That is about 10/day. How well do you do?

Edited to add in March 2015: I heard from Barb again. It is still a core part of the organization’s culture.

So – to organizations trying to implement “a problem solving culture” and anyone else who is interested, I am going to get into some of the nuts and bolts of what we did there way back in 2003. (I am telling you when so that it sinks in that this is a change that has lasted and fundamentally altered the culture there.)

What is “A Morning Market?”

The term comes from Masaaki Imai’s book Gemba Kaizen pages 114 – 118. It is a short section, and does not give a lot of detail. The idea is to review defects “first thing in the morning when they are fresh” – thus the analogy to the early morning fish and produce markets. (For those who like Japanese jargon, the term is asaichi, but in general, with an English speaking audience, I prefer to use English terms.)

The concept is to display the actual defects, classified by what is known about them.

  • ‘A’ problems: The cause is known. Countermeasures can be implemented immediately.
  • ‘B’ problems: The cause is known, countermeasures are not known.
  • ‘C’ problems: Cause is unknown.

Each morning the new defects are touched, felt, understood. (The actual objects). Then the team organizes to solve the problem. The plant manager should visit all of the morning markets so he can keep tabs on the kinds of problems they are seeing.

Simple, eh?

Putting It Into Practice

Fortunately we were not the pioneers within the company. That honor goes to another part of the company who was more than willing to share what they had learned, but their key lesson was “put two pieces of tape on a table, divide it into thirds, label them A, B and C and just try it.”

They were right – as always, it is impossible to design a perfect process, but it is possible to discover one. Some key points:

  • There is a meeting, and it is called “the morning market” but the meeting does not get the problems solved. The difference between the organizations that made this work and the ones that didn’t was clear: To make it work it is vital to carve out dedicated time for the problem solvers to work on solving problems. It can’t be a “when you get around to it” thing, it must be purposeful, organized work.
  • The meeting is not a place to work on solving problems. There is a huge temptation to discuss details, ask questions, try to describe problems, make and take suggestions about what it might be, or what might be tried. It took draconian facilitation to keep this from happening.
  • The purpose of the meeting is to quickly review the status of what is being worked on, quickly review new problems that have come up, and quickly manage who is working on what for the next 24 hours. That’s it.
  • The morning market must be an integral part of an escalation process. The purpose is to work on real problems that have actually happened. Work on them as they come up.

Just Getting Started

This was all done in the background of trying to implement a moving assembly line. There is a long back story there, but suffice it to say that the idea of a “line stop” was just coming into play. Everyone knew the principle of stopping the line for problems, but there was no real experience with it. As the line was being developed, there were lots of stops just to determine the work sequence and timing. But now it was in production.

The first point of confusion was the duration of a line stop. Some were under the impression that the line would remain stopped until the root cause of the problem was understood. “No, the line remains stopped until the problem can be contained,” meaning that safe operations that assure quality are in place.

The escalation process evolved, and for the first time in a long time, manufacturing engineers started getting involved in manufacturing.

The actual morning market meeting revolved around a whiteboard. At least at first. When they started, they filled the board with problems in a day or two. They called and said they wanted to start a computer database to track the problems. I told them “get another board.” In a few days that board, too, filled up. It really made sense now to start a computer database. Nope. “Get another board.” That board started to fill.

Then something interesting happened. They started clearing problems.

PDCA – Refining The Process

The tracking board evolved a little bit over time.

The first change was to add a discrete column that called out what immediate measures had been taken to contain the problem and allow safe, quality production to resume. This was important for two reasons.

First, it forced the team to distinguish between the temporary stop-gap measure that was put in immediately and the true root-cause / countermeasure that could, and would, come later. Previously the culture had been that once this initial action were taken, things were good. We deliberately called these “containments” and reserved the word “countermeasure” for the thing that actually addressed root cause. This was just to avoid confusion, there is no dogma about it.

Second, it reminded the team of what (probably wasteful) activity they should be able to remove from the process when / if the countermeasure actually works. This helped keep these temporary fixes from growing roots.

You can get an idea of what a typical problem board looked like here:

Morning Market White Board

The columns were:

  • Date (initial date the problem was encountered)
  • Owner
  • Model (the product)
  • Part Number (what part was involved)
  • Description (of the part)
  • Problem (description of the problem)
  • A/B/C (which of the above categories the problem was now. Note that it can change as more is learned.
  • Containment Method
  • Root Cause (filled in when learned)
  • Countermeasure (best known being tried right now)
  • Due Date (when next action is due / reported)
  • Verified (how was the countermeasure verified as effective?)

A key point is that last column: Verified. The problem stays on the board until there is a verified countermeasure in place. That means they actually tested the countermeasure to make sure it worked. This is, for a lot of organizations, a big, big change. All too many take some action and “call it good.” Fire and forget. This little thing started shifting the culture of the organization toward checking things to make sure they did what they were thought to do.

Refining The Meeting

While this particular shop floor was not excessively loud, it was too loud for an effective meeting of more than 3-4 people. Rather than moving the meeting to a conference room, the team spent $50 at Wally World and bought a karaoke machine. This provided a nice, inexpensive P.A. system. It added the benefit that the microphone became a “talking stick” – it forced people to pay attention to one person at a time.

Developing Capability

The other gap in the process that emerged pretty quickly was the capability of the organization to solve problems. While there had been a Six Sigma program in place for quite a while, most of skill revolved around the kinds of problems that would classify as “black belt projects.” The basic troubleshooting and physical investigation skills were lacking.

After exploring a lot of options, the organization’s countermeasure was to adopt a standard packaged training program, give it to the people involved in working the problems, then expecting that they immediately start using the method. This, again, was a big change over most organization’s approach to training as “interesting.” In this case, the method was not only taught, it was adopted as a standard. That was a big help. A key lesson learned was that, rather than debate which “method” was better, just pick one and go. In the end, they are all pretty much the same, only the vocabulary is different.

Spreading The Concept

In this organization, the two biggest “hitters” every day were supplier part quality and supplier part shortages. This was pretty much a final-assembly and test only operation, so they were pretty vulnerable to supplier issues. This process drove a systematic approach to understand why the received part was defective vs. just replacing it. Eventually they started taking some of their quality assurance tools upstream and teaching them to key suppliers. Questions were asked such as “How can we verify this is a good part before the supplier ships it?” They also started acknowledging design and supplier capability (vs. just price and capacity) issues.

On the materials side, the supply chain people started their own morning market to work on the causes of shortages. I have covered their story here.

As they implemented their kanban system, morning markets sprang up in the warehouse to address their process breakdowns. Another one addressed the pick-and-delivery process that got kits to the line. Lost cards were addressed. Rather than just update a pick cart, there was interest in why they got it wrong in the first place, which ended up addressing bill-of-material issues, which, in turn, made the record more robust.

Managing The Priorities

Of course, at some point, the number of problems encountered can overwhelm the problem solvers. The next evolution replaced the white board with “problem solving strips.” These were strips of paper, a few inches high, the width of the white board, with the same columns on them (plus a little additional administrative information). This format let the team move problems around on the wall, group them, categorize them, and manage them better. Related issues could be grouped together and worked together. Supplier and internal workmanship issues could be grouped on the wall, making a good visual indication of where the issues were.

"Problem Strips" at the meeting.
“Problem Strips” at the meeting.

But those were all side effects. The key was managing the workload.

Any organization has a limited capacity to work on stuff. The previous method of assignment had been that every problem was assigned to someone on the first day it was reviewed. It became clear pretty quickly that the half a dozen people actually doing the work were getting a little sick of being chided for not making any progress on problems 3, 4 and 5 because they were working on 1 and 2. In effect, the organization was leaving the prioritization to the problem solvers, and then second guessing their choices. This is not respectful of people.

The countermeasure – developed by the shop floor production manager, was to put the problems on the strips discussed above. The reason she did it was to be able to maintain an “unassigned” queue.

Any problem which was not being worked on was in the unassigned queue on the wall. All of the problems were captured, all were visible to everyone, but they recognized they couldn’t work on everything at once. As a technical person became available, he would pull the next problem from the queue.

There were two great things about this. First, the production manager could reshuffle the queue anytime she wanted. Thus the next one in line was always the one that she felt was the most important. This could be discussed, but ultimately it was her decision. Second is that the queue became a visual indicator that compared the rate of discovering problems (into the queue) with the rate of solving problems (out of the queue). This was a great “Check” on the capacity and capability of the organization vs. what they needed to do.

There were two, and only two, valid reasons for a problem to bypass this process.

  1. There was a safety issue.
  2. A defect had escaped the factory and resulted in a customer complaint.

In these cases, someone would be assigned to work on it right away. The problem that had been “theirs” was “parked.” This acknowledged the priority, rather than just giving him something else to do and expecting everything else to get done too. (This is respect for people.)

Incorporation of Other Tools

Later on, a quality inspection standard was adopted. Rather than making this something new, it was incorporated into the problem solving process itself. When a defect was found, the first step was to assess the process against the standard for the robustness of countermeasures. Not surprisingly, there was always a pretty significant gap between the level of countermeasures mandated by the standard and what was actually in place. The countermeasure was to bring the process up to the standard.

The standard itself classified a potential defect based on its possible consequences. For each of four levels, it specified how robust countermeasures should be for preventing error, detecting defects, checking the process, secondary checks and overall process review. Because it called out, not only technical countermeasures, but leadership standard work, this process began driving other thinking into the organization.

Effect On Designs

As you might imagine, there were a fair number of issues that traced back to the design itself. While it may have been necessary to live with some of these, there was an active product development cycle ongoing for new models. Some of the design issues managed to get addressed in subsequent designs, making them easier to “get right” in manufacturing.

What Was Left Out

The things that got onto the board generally required a technical professional to work them. These were not trivial problems. In fact, at first, they didn’t even bother with anything that stopped the line for less than 10 minutes (meaning they could rework / repair the problem and ship a good unit). But even though they turned this threshold down over time, there were hundreds of little things that didn’t get on the radar. And they shouldn’t… at least not onto this radar.

The morning market should address the things that are outside the scope of the shop floor work teams to address.

Another organization I know addressed these small problems really well with their organized and directed daily kaizen activity. Every day they captured everything that delayed the work. Five second stoppages were getting on to their radar. Time was dedicated every day at the end of the shift for the Team Members to work on the little things that tripped them up. They had support and resources – leadership that helped them, a work area to try out ideas, tools and materials to make all of the little gadgets that helped them make things better. They didn’t waste their time painting the floor, making things pretty, etc. unless that had been a source of confusion or other cause of delay. Although the engineers did work on problems as well, they did not have the work structure described above.

I would love to see the effect in an organization that does all of this at once.

No A3’s?

With the “A3” as all the rage today, I am sure someone is asking this question while reading this. No. We knew about A3’s, but the “problem solving strips” served about 75% of the purpose. Not everything, but they worked. Would a more formal A3 documentation have worked better? Not sure. This isn’t dogma. It is about applying sound, well thought out methodology, then checking to see if it is working as expected.

Summary

Is all of this stuff in place today? Honestly? I don’t know. [Update: As of the end of 2011, this process is still going strong and is strongly embedded as “the way we do things” in their culture.]  And it was far from as perfect as I have described it. BUT organized problem solving made a huge difference in their performance, both tangible and intangible. In spite of huge pressure to source to low-labor areas, they are still in business. When I read “Chasing The Rabbit” I have to say that, in this case, they were almost there.

And finally, an epilogue:

This organization had a sister organization just across an alley – literally a 3 minute walk away. The sister organization was a poster-child for a “management by measurement” culture. The leader manager person in charge sincerely believed that, if only he could incorporate the right measurements into his manager’s performance reviews, they would work together and do the right things. You can guess the result, but might not guess that this management team described themselves as “dysfunctional.” They tried to put in a “morning market” (as it was actually mandated to have one – something else that doesn’t work, by the way). There were some differences.

In the one that worked, top leaders showed up. They expected functional leaders to show up. The people solving the problems showed up. The meeting was facilitated by the assembly manager or the operations manager. After the meeting people stayed on the shop floor and worked on problems. Calendars were blocked out (which worked because this was a calendar driven culture) for shop floor problem solving. Over time the manufacturing engineers got to know the assemblers pretty well.

In the one that didn’t work, the meeting was facilitated conducted by a quality department staffer. The manufacturing engineers had other priorities because “they weren’t being measured on solving problems.” After the meeting, everyone went back to their desks and resumed what they had been doing.

There were a lot of other issues as well, but the bottom line is that “problem solving” took hold as “the way we do things” in one organization, and was regarded as yet another task in the other.

About 8 months into this, as they were trying, yet again, to get a kanban going, a group of supervisors came across the alley to see what their neighbors were doing. What they saw was not only the mechanics of moving cards and parts, but the process of managing problems. And the result of managing problems was that they saw problems as pointing them to where they needed to gain more understanding rather than problems as excuses. One of the supervisors later came to me, visibly shaken, with the quote “I now realize that these people work together in a fundamentally different way.” And that, in the end, was the result.

In the end? The organization in this story is still in business, still manufacturing things in a “high cost labor” market. The other one was closed down and outsourced in 2005.

Posted on

How Strong Is Your Immune System?

Each day you are exposed to an unimaginable number of viruses and bacteria. Any one of them has the potential to overwhelm your body and kill you. But your immune system detects the foreign body, responds, swarms the source of infection, defeats it, and learns so that your immunity is actually strengthened in the process.

Some people, for various reasons, have weak or suppressed immune systems. They suffer from chronic infections. Even if their immune system keeps the infection under control, it is not strong enough to eliminate it. Things which someone else might not even notice take a daily toll on their energy and life.

Your immune system represents your body’s strength to deal with the unanticipated and the unexpected.

In your organization, people encounter unanticipated and unexpected things every day. A small inconsequential defect causes some inconsequential rework. A missing part causes a search and expedite. Each of these things, in turn, propagates more variation, like expanding waves, into the system around it. The variation becomes an infection in your processes, and it has the potential to grow without bounds.

Most organizations have very weak immune systems. They are chronically sick, and expending incredible amounts of time and energy dealing with these “infections.” Because each “infection” is, at best, accommodated rather than eliminated, they tend to accumulate. More and more of the organization’s energy is expended coping.

In the work place this means that the success of the process becomes totally reliant on the vigilance of each individual, working pretty much alone, to see problems and control them enough that some form of output can continue. Worse, many organizations build elaborate systems to assign blame when one of these thousands of opportunities for problems is missed.

Ironically, a lot of “blitz” type kaizen activity actually makes the the system more sensitive to these kinds of problems. If there is no corresponding effort to strengthen the response (swarm, fix, solve) to these problems, it is no wonder that things slide back pretty quickly.

Variation is an infection. And like the viruses and bacteria we are exposed to every day, it will always be there. It is only your ability to quickly detect variation, rapidly contain it, and then deal with its cause that strengthens your organization’s ability to deal with the next one.

Posted on

Listening to the Customer vs. the HiPPO

Microsoft has an internal initiative to start running controlled experiments to determine what is actually better for users. I have no data (as I have no inside scoop from Microsoft, even though they are right down the road), but there is general opinion out there is that one of their latest efforts turned out to be less than impressive to the user community.

The mascot of this initiative is a hippo.

PERHAPS, and again, this is only speculation, when they were putting in all of the snazzy page flipping and rotating cube features, they were paying too much attention to the HiPPO and not enough to the actual customer.

What is the HiPPO?
The Highest Paid Person’s Opinon.

Who do you listen to?
Your customers? Do you actually go into the field and watch them use your product?
Do you use it the way they do, in their environment, to understand their experience?

Of does your head of engineering or sales claim to speak on their behalf when you are deciding on product features?

Posted on

Watch out for drug names that look, sound alike

Watch out for drug names that look, sound alike – Yahoo! News

One of the most common errors made in the health care industry is medication – giving the wrong stuff to the patient. There are a lot of root causes, and this article highlights one of them.

I certainly understand that the commercial pharmaceutical industry wants to establish and maintain brand awareness. And I am equally certain that they don’t really consider it "their problem" if "someone doesn’t pay attention" and prescribes the wrong medication; dispenses the wrong medication; administers the wrong medication or takes the wrong medication.

This is one of the problems with a complex system – where a problem originates in one part, but is only felt in another part.

Ultimately the solution is fairly simple. Assign an alpha-numeric code, not to the brand, but to the formulation, including the strength / dosage. Use that code for all bar coding, RF tags, database records, prescriptions, etc.

If it would help, combine that code with colored labels, backgrounds, shapes, etc. Anything to help visual distinguish one product from another.

This is, of course, not a 100% bullet-proof solution. But humans are really poor at distinguishing similar looking words from one another. We don’t see letters, we hear the sounds. This is an appropriate case where technology, which is well suited for this kind of thing, can be a big help.

Will it eliminate all errors? Of course not. Mislabeling or mixing mistakes are also common. But this would attack the problem cited in the article at its root. Then the companies can name their products anything they want, and we also eliminate all kinds of overburden on the already overworked attorneys.

Posted on

Dealing With High Turnover

Jim left a great post on The Whiteboard way too long ago.

His problems seem to sum up to these statements:

Every valve is hand made one by one in batches through several processes.

…about a 10% turnover rate…Consequently we are always training new people…the supervisor needs to make sure the worker understands the job

My inclination is to somehow explain to the owners how their employee turnover rate is hurting their production and quality.

He titled his post  Hitting The Moving Train which seems appropriate on a number of levels.

Keeping in mind that I have not done my own "go and see" so I don’t have facts from the ground, only what is reported, a couple of immediate things come to mind. Other readers (especially the couple of dozen of you who never leave comments!), feel free to chime in here.

Short term: Stop the batching. Or, more specifically, flow the batches. The key point here is that just because you run batches doesn’t mean you can’t run one-piece-flow. (Pardon the double negative.)

What does that look like here? For each batch of valves, understand all of the assembly operations, set up an ad-hoc flow line that sequences all of the steps, then run them all through.

This does a couple of things, first and foremost, it gets them off the shop floor and shipped a hell of a lot quicker because now they are DONE. The downside is the supervisor needs to teach more than one person his particular sequence steps, but it eliminates all of the routing, traveler paperwork, tracking, prioritizing, and other stuff associated with having those 50 incomplete valves sitting out there. Scheduling becomes "Which jobs are we going to set up and assemble today?"

What about the parts? Don’t start assembling until you have all of the parts.

"Wait a minute, what about just-in-time?" One thing at a time. Let’s not launch a job until we have the capacity and capability of actually doing it for now.

Next, (Intermediate Term): is make the supervisor’s job a bit easier. I am assuming that, since he is training the workers, that he understands the tasks. But does he have formal training on how to break down work into steps and instruct in a way that someone remembers how to do it? Rather than reading a book about it, I would strongly suggest contacting the TWI Institute and getting, first, a handle on Job Instruction. This is, essentially, standard work on how to break down a job and teach someone to do it. The method has been taught unchanged since mid-1944. Not surprisingly, it is bread-and-butter at Toyota… and their material is pretty much verbatim from the 1944 material.. and it is the origin of standard work as we know it.

As jobs are broken down, the inherently critical tasks should emerge. These are the things which must be done a certain way or the thing just won’t go together (bad) or will go together, but won’t work (very, very bad). Those key points are where to start instituting mistake-proofing, successive checks, etc. This will start driving toward stomping out the quality issues.

For each quality issue that comes back to bite, take the time to really understand how it was even possible to make that mistake, and focus a problem solving effort on that key point to (1) incorporate it into the teaching and (2) mistake-proof and successive-check that particular attribute. Defects discovered in the plant are bad enough. Defects discovered by your customers are another story. Do what you must to keep the defects from escaping, then work on preventing them. Don’t cut out inspection just because it is muda.. unless you are 110% certain that your process is totally robust, and any problem that does occur will be caught and corrected immediately. Anyone who thinks Toyota "doesn’t do inspection" has never seen the last 60 or so positions on their assembly line… nor have they seen the checks that are continuously being made during assembly.

And finally – the turnover issue. A couple of things come to mind. First, with the right attitude and approach, the things described above can make this a lot more interesting place to work… especially if the Team Members are involved in finding the solutions to escaping quality issues, etc.

The same goes if supervisors continue to hone their leadership skills. Employee turnover is typically caused as much by the relationship with the first line supervisor and working conditions in general as it is by wages, etc. Southwest Airlines would not exist were that not true. Neither would a couple of other companies I can think of. Go look at "The 100 Best Places to Work" and see that relatively few of them cite "the highest pay and best benefits in the area." This isn’t to say that they do not offer fair, competitive compensation. But compensation, in general, is a relatively poor indicator of job satisfaction. Far more important is a daily demonstration that someone cares and is committed to the Team Member’s success.

If they really like TWI Job Instruction, they might be attracted to Job Relations – standard work for supervisors (first line leaders) for people issues. The TWI Institute has also just launched a new program called Job Safety. This isn’t one of the original TWI classes, but it was put together by experts I know and trust, and from what I have read, it follows the same reliable method format.

With all of that, perhaps the owners will be convinced that a competitive compensation program is a way to say "Thank you" to a great team that busts their butts to keep the customers happy.

Posted on

Hospital Error – Heparin in the news again

Corpus Christi, Texas: Hospital error blamed for more infant overdoses – Yahoo! News

Key points of the story are:

  • 14 babies received heparin overdoses while in intensive care.
  • Two premature twins died, though it is unknown if this was the cause.

…pharmacy workers at Christus Spohn Hospital South made what the hospital called a "mixing error." The two workers went on voluntary leave.

The heparin, which was 100 times stronger than recommended, was given to 14 infants in the hospital’s neonatal intensive care unit on July 4.

As I have cited on previous posts, medication errors are one of the most common ways hospitals unintentionally injure or kill patients in their efforts to treat them.

I am reasonably certain that the two workers who went on "voluntary leave" (yeah, right) will absorb more than their share of blame as the system solves the problem by asking the "Five Who?" questions.

The article then goes on to cite a history of similar incidents in hospitals all over the country, though it is sometimes unclear in the writing if it is talking about this case or a previous one.

So what should happen?

First, determine where the actual root error occurred. If the manufacturer shipped mislabeled product, for example, then the problem happened THERE, not in the hospital. That isn’t to say we can’t do a better job in the hospital catching those things, but that isn’t the root cause in this case.

Any investigation should center on an assumption that the workers were operating in good faith, paying as much attention as can be expected of a normal human being, and were positive that they were doing this right. They did not want to injure or kill their customers.

Somehow, then, the process of mixing (either in the hospital or at the manufacturer) allows a 100x error to go by without SCREAMING for attention. And scream it must. Humans doing routine things in routine ways operate on an assumption that everything is routine until presented with overwhelmingly compelling evidence to the contrary.

Any hunt for "who did it" is motivated by extracting retribution rather than solving the problem. Once again, I refer the reader to the great work by Sidney Dekker on human error. We can all learn and apply it to everything that people need to do correctly – safety, quality, any other process or procedure.

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

Safety and Lean Manufacturing

This is a (belated) response to a post from Patsi Sells on The Whiteboard. She asked about safety and kaizen.

When first implementing some of the tools and mechanics of the TPS (especially in a manufacturing environment), many of the initial efforts seem to run afoul of the industrial safety professionals. My experience suggests a couple of basic causes.

  • Safety countermeasures are not seen as necessarily directly contributing to production of the product. Thus, they are often lumped in to “not value added” or “waste” – at least by implication, if not directly, by over-enthusiastic kaizen event leaders.
  • Safety professionals can be stuck on specific countermeasures vs. looking at the actual risk and identifying other possible countermeasures.
  • Safety professionals are concerned (and rightly so) about repetitive motion injury. They perceive that takt driven standard work might increase the risk of this.
  • There is overall a general lack of understanding of the difference between regulatory compliance and keeping people safe. While these two things overlap, neither is necessary nor sufficient to assure the other.

Let me start with the last point since it probably raised the most eyebrows.

An industrial safety program has two distinct and discrete objectives:

  1. To keep people from getting hurt.
  2. To comply with all laws and regulations

As I said above, while meeting both of these objectives are absolutely necessary, meeting the requirements of one does not guarantee meeting the requirements of the other. To put it more directly –

  • It is possible to be fully compliant with all health, safety and environmental regulations and still have a workplace which is extremely dangerous.
  • It is possible to have a very healthy, safe and environmentally friendly workplace and still run afoul of laws and regulations.

Thus, it is necessary to ensure that each of these things are discretely addressed in any successful program.

It is important for both kaizen and safety professionals to be aware of this. Some things are simply required by law, even if they are wasteful, and sometimes interpretation is up to the whim of a local inspector who might be having a bad day. Whatever the case, for each regulatory requirement there must be a specific, targeted countermeasure, just as there must be one for each physical risk. Sometimes these things overlap, but sometimes they do not, and that is the key point here.

I will digress for a paragraph and make this point however: If you have the basics of workplace organization in place, you make a much better first impression on a health and safety inspector than if the place is a mess. If your fire department sees the fire extinguishers are all where they should be and up to date, access aisles and evacuation doors clear, etc. he is more biased toward the assumption that you have your basic act together than if the place is a mess. Everyone has some violations, but when they are blatant, simple things it starts you off with a bad impression, and inspectors usually start digging.

Moving beyond simple regulatory compliance, the objectives of “lean manufacturing” and safety are 100% congruent. Ethically it is never acceptable to knowingly put people in harm’s way for the sake of production. At a more pragmatic level, a hazardous workplace will adversely affect quality, production, cost, delivery and morale. I will not descend to the level of cost-justifying safety simply because it isn’t necessary. But it is equally true that an unsafe workplace has higher costs than a safe one.

The good news is that the kaizen process is incredibly effective at dealing with safety hazards.

Moving up on the above list, one of the biggest places where the safety professionals can help smooth out the work is with their expertise in ergonomics.

What the kaizen people should take a little time to understand is this: Motions with poor ergonomics nearly always take longer than motions with good ergonomics. To put it a little more clearly: Ergonomic improvements are kaizen. Once a good team understands the difference between good and bad ergonomics, they can quickly see many small improvements which all accumulate.

By standardizing the method, we standardize the good ergonomics. Where there are no standard methods, the Team Members will each develop their own which may, or may not, be the safest way to do the job.

Standardizing the right motions reduces the chance of repetitive motion injury. And paying attention to why unusual motions are necessary comes back to reducing variation and overload (muri, mura) in the workplace.

At the next level up, standard work is your best friend.

To develop any process you first take a good look and specify exactly what result you expect to achieve.
Define a defect-free outcome.
Part of that definition is “perfectly safe.” No one is going to argue with this. Of course you want a process that is perfectly safe, and produces a defect free outcome. Who wants the opposite? But until “defect free” and “perfectly safe” are explicitly defined or specified, there may be room for interpretation. Do this before working on the process steps.

Next define the work you believe will deliver a perfectly safe, defect-free outcome. Define the content, sequence and timing of the work.

Now you have a specification for content, sequence, timing and outcome – the four elements of activity that Steven Spear called out in “Decoding the DNA of the Toyota Production System.”

Next – try it. Run the process exactly as you specified it. Verify two things:

  • That the Team Member can perform the process as specified – there is nothing keeping him from doing it.
  • That the Team Member actually does it that way and put in guides, controls, mistake-proofing where things go off track.

Check your results.
Was it perfectly safe? Did you see any risks? How are the ergonomics?
Adjust as necessary, then repeat.

Was the result defect free? How do you know? Is there a way for the Team Member (or an automatic step) to verify the result?

In practice, you are “trying it” and “checking the results” not just when you are developing the process, but every time it is done.

If a defect is produced at some point, then you know either:

  • The process didn’t work as you expected.
  • For some reason (which you don’t know yet), the Team Member did something different, or omitted a step.

Likewise, if the Team Member so much as skins a knuckle, you know the same things: The process is not perfectly safe or the process wasn’t (or couldn’t be) followed.

In most cases where the process was not followed you likely had a Team Member doing something in good faith to “get the job done.” This is the time to gently remind him that, when he can’t follow the process as designed, to please pull the andon and let someone know. Maybe you will have to make an exception to correct the current situation, but you HAVE to know if the process isn’t working or is unworkable.

Bottom line?
You get perfect safety exactly the same way you get perfect quality.
The methods and approach for getting it, and the methods and approach for correction and countermeasure are exactly the same.

Remember:
The right process produces the right result.

If you aren’t getting the result you want, then take a look at the process.

Posted on

Attack on Ambiguity

When real effort is spent getting to the cause of problems (vs. a reflex to find someone to blame), ambiguity often enters into the picture.

Problem solving is a process of asking questions and clarification.

Is a “defect-free” outcome of the process specified? Does the Team Member know what “success” is?
Is there a way for the Team Member to actually verify the result?
Does that check give the Team Member a clear Yes/No; Met/Not Met; Pass/Fail response? Or is there interpretation and judgment involved?

If there is good specification for “defect-free” – is there a specification for how to achieve it? Do you know what must be done to assure the result that you want? Does the Team Member know? Is the Team Member guided through the process? Are there verifications (poka-yoke, etc) at critical points?

If all of the above is in place, do you know what conditions must be in place for success? What is the minimum pressure for your air tools? Is there a pressure gage? Does it cut off the tool if the pressure is too low? Is there some visual check that all of the required parts, pieces, tools are there before work starts? Thank about the things you assume are there when the Team Member gets started.

For ALL OF THE ABOVE, if something isn’t right, is there a clear, unambiguous way to alert the Team Member immediately?
Is there a clear way for the Team Member to alert the chain-of-support that something isn’t right?

If there is a defined result, a defined process to achieve it, and all of the conditions required for success are present –
Is the Team Member alerted if he deviates from the specified process, or if a critical intermediate result is not right?
More poka-yoke.

Now you have the very basics for consistent execution.

Is the process carried out as you expect?
Is the result what you expected?

If not, then the process may be clear, but it clearly does not work. Stop, investigate. Fix it.

All of this is about getting more and more about what is SUPPOSED to happen and compare it to what is REALLY happening… continuously. I say continuously because “continuous improvement” does not happen unless there is continuous checking and continuous correction and problem solving. If you want “continuous improvement” you cannot rely on special “events” to get it. It has to be embedded into the work that is done every day.