Agile Manufacturing Update

"Dollarizing" Lean Gains

2010-01-28T11:56:00Z

I've a good friend who has many years of experience in manufacturingmanagement and leadership. He asked me if I had any "dollarized successstories".

It's an interesting question. When I get working with clients, they almost never push the issue of "impact of lean on top level metrics"...in fact, they sometimes push back when I suggest that we work to establish the link more strongly. I think there is the feeling that their existing data won't support such an analysis. Or if it does, they're just not interested in the labor it would take to do the analysis. (In other words, they take on faith, I guess, that reducing setup times is a good thing for their business but don't want to get into the hassle of figuring out how much impact a 50%reduction in setup time of their highest volume product or on their highest capacity production line would have on EBIT. When I was working with a box company, they had a machine on which they carried out over1000 changes a year. In many cases, they changeovers were twice as long as the run. It wasn't hard for me to figure out how much money each minute of changeover reduction was worth based on 1.) sales of the boxes that could be run in the saved time (which is important only if the machine is at full capacity, which it was) and 2.) charge rate of the machine. As you might imagine, both figures were reasonably large and senior management's response was, "Yep, that's some interesting information alright." And the subject never came up again. The point being, even when I showed them, using their own data, how much money they were making/saving, they were only mildly interested. )

While working with another company, I constantly had to push the whole issue of performance metrics. Early on, there was one metric that they were interested in....budget. Period. If you were under budget,you were OK. If you were over budget, your ass was grass. You could be the biggest dumbass in the company running a plant that looked like a Bankok brothel but, so long as you were under budget (or somewhere close), nobody bothered you. So, when we came in preaching teamwork,employee involvement, and world class performance, they looked at us like we were from another planet.

I went to the plant managers once to suggest that a good project might be working to make the metrics standard across similar plants. That idea went nowhere.

My point in all the rambling above is to say that, manufacturing managers, in my experience have been very hard to work with vis a vis pulling info together and figuring out the impact improvement initiatives have on their bottom lines.

How to Keep Lean Going: Pull Systems

2010-01-25T13:32:00Z

Now we get to a tricky part...implementing pull systems.

By the way, that's what we're going to call it...Pull Systems. NOT kanban.

Nobody actually knows what the hell a kanban is. Your associates and operators won't know what it is even after you've explained it. All the talk you'll do of kanban cards and kanban bins will just confuse them. Kanban is just jargon used by folks who want to make all this lean stuff seem mysterious.

Why is implementing pull tricky? Well, you can't just do pull like you can (for the most part) just do 5S, Quick Change, or VSM. Mind you, just doing any of these doesn't mean you'll be effective or successful, but it is possible to do a one-shot, one-time,
short-on-results effort at any of them. That's not possible with pull systems. It takes a good bit of time and study to implement even limited pull.

It's not every manufacturer that badly needs to implement pull. I've worked in several settings in which raw material went into one end of the machine, a finished product came out the other end. It was packaged, taken to shipping, and put on a truck. And that's before we got started on our lean implementation.

In other cases, the finished product was packaged and taken to a warehouse. Our "pull implementation" consisted of a leadership directive to have only a certain amount of inventory on hand, e.g. one month rather than six months. Not much else needed to be done.

Pull systems are most useful (and most challenging to implement) where products have lots of parts and pieces coming from lots of different places. Each part and piece has its own lead time. Parts and pieces get made into sub-assemblies that get made into other sub-assemblies that get put together into a finished product. Every one of those parts and pieces and sub-assemblies needs to get where it's needed in the right quantity, at the right time, with near perfect quality or the whole system comes crashing down and gets tossed aside for the old way of doing things. All of which is to say...if you haven't done a good job on 5S, Quick Change, Work Standardization, preventive maintenance, and scrap reduction, don't even THINK of trying to implement pull systems.

Think Outsourcing is the Answer? Check this out.

2010-01-18T12:31:00Z

I'm one who believes that much, maybe most (but not all), outsourcing is a mistake. I'm one who believes that outsourcing only to reduce labor costs is probably mostly a mistake. And so, I'm always on the lookout for stories, anecdotes, and data in support of that view.

I found a great article at one of my favorite blogs, Evolving Excellence, that covers all the bases of a specific example of outsourcing gone wrong. (Check out Evolving Excellence at your leisure, but go directly to the article here so that the source gets credit for a hit. More hits means more advertising means they can keep bringing us more articles.)

The basic idea here is that outsourcing is directly counter to the lean and agile approach. That doesn't mean that companies should never outsource. It does mean that outsourcing should be done only after careful deliberation as to its contribution to the overall company strategy. If it's only (supposed) contribution is to cost reduction...it's probably the wrong thing to do.

How to Keep Lean Going: Preventive Maintenance 3 - A Word About TPM

2010-01-18T11:34:00Z

Total Productive Maintenance has gotten a lot of attention and for good reason. Six Sigma has been (at least until recently) all the rage but most companies would be better served if they fully implemented TPM before they attended to Six Sigma.

There's certainly no shortage of info about how to implement TPM, so I won't go into lots of detail here. (I just did a search on "total productive maintenance over at amazon.com and got 780 hits.)

In my own view, TPM is essentially making sure that maintenance checks are integrated with standard work practices. Another important aspect is collaboration and partnership between production and maintenance.

Should TPM be a part of any agile or lean implementation? Without question. I worked at one steel mill that made TPM the primary focus of it's lean initiative.

Don't make it too complicated, though. Write the work instructions, making sure that they include maintenance checks. Implement the work instructions via training and "re-certification". Follow up to make sure the work instructions are being adhered to. That will be challenging enough without adding too many bells and whistles.

The Problems with Free Trade

2010-01-06T12:26:00Z

Wait a minute...

A business mag that publishes a piece against free trade? Now there's something you won't see every day.

But here it is.

By the way, I agree with the author's point of view.

Something puzzles me....

2010-01-05T13:09:00Z

I read an article in yesterday's Cleveland Plain Dealer about a small metal stamping firm hereabouts and the steps it was taking to deal with this recession.

(The story can be found here.)

If you read the story, you'll come to this:

The tiny metal switch covers his plant was making for customers weren't going into MRI machines in hospitals. Fist-sized metal brackets weren't going into garage-door openers in his neighbors' houses. They were sitting in warehouses.

"[Our customers] were blindly thinking that this was just a dip," Reid said.

When his customers realized that they had built up months, even years, of parts in inventory, they canceled future orders.

Now, for me, this is a real "WTF?" moment. What on earth would cause these customers to order YEARS worth of a part before they were needed? My own view is that the only thing that could cause such a thing is rank, abject stupidity on the part of the managers of said customers.

Is there another explanation? Is there something I'm missing or a market dynamic of which I'm ignorant under which the scenario of having YEARS of inventory make sense? Or, am I right....that the company was selling to dumbasses who didn't know their own business?

How to Keep Lean Going: Preventive Maintenance 2

2009-12-29T13:18:00Z

The whole issue of exactly how to set up a preventive maintenance program is a bit outside my range of expertise. On the other hand, like most lean tools, preventive maintenance isn't rocket science. The basic approach is to develop a PM checklist for each machine or piece of equipment and a schedule for carrying out each list. It's all just a larger version of changing your car oil every 10,000 miles (in my case...maybe I should revisit my schedule). In fact, your operation may already have a pretty sophisticated approach to PM. I've worked at plants where all the PM checklists were entered into the IT system and comprehensive checklists were "spit out" by the computer as per the pre-determined schedule.

I've found that effective PM is another of those approaches that depends more on discipline than on method. I know I'm supposed to change my oil every 5000 miles (I know the car and oil companies say every 3000, but I think that's bogus) but I just don't get it done. I've never gone into a plant that said, "Preventive maintenance? What's that?" (Actually, I've been into lots of plants where the operators said exactly that but I've never heard top leadership say it.) Everybody knows they're supposed to be carrying out preventive maintenance but they've gotten better at coming up with excuses for not doing it than they have for approaches for getting it done.

I'm not going to go on too long about the benefits of actually doing PM in a disciplined way...I'd be very much preaching to the choir. I'll just say that you really only need:

A PM checklist for each machine,
A schedule for carrying out the checklist,
Discipline to actually get it done.

How to Keep Lean Going: Preventive Maintenance 1

2009-12-27T13:42:00Z

I've never been a plant manager or production superintendent but I've often thought about how I'd start if I ever did acquire such a position (not that I'm trying). What would I do first? Even reasonably well-run plants generally have lots of areas for improvement...where to start?

I've pretty much decided that the first thing I'd tackle would be getting all the machinery and equipment in top shape. When I first enter most of the plants I work with, there machinery and equipment is running...for the most part...but not very well. C-clamps, duct tape, and binding twine abound. Loose electrical connections, exposed wires, and open electric panels are common. Oil, air and water leaks are so prevalent that they aren't attended to any longer; the oil and water on the floor and the constant hiss of air has become part of the "manufacturing scenery".

I worked with a company that owned several plants that extruded PVC conduit and pipe. Several of the plants were having scrap problems. A quick effort at pareto analysis by an employee team that I facilitated showed that there seemed to be no consistently occurring type of scrap. It was if one studied loss of gas mileage and found that, during one week, there were lots of miles driven in the mountains, but the next week, the front end needed alignment, and the week after that, the engine timing was off.

So, I took the team out onto the plant floor and told them that we were going to walk down each extrusion line and make a list of everything that was wrong with each line, no matter how small. (We weren't, in this case, going to look at potential improvements or enhancements to the lines, just corrections of faults.) Every place we saw rust, duct tape, C-clamps, binding twine, missing parts, oil, grease, something broken, or a "make do", we made a note of it. We focused on the lines that had the worst scrap histories.

In the short run, we got resentment and resistance from the maintenance manager. In the longer run, things worked out and scrap finally started trending down.

(A quick note: This was a plant that I had not helped with 5S. For a variety of reasons, none of them very good ones, we had never conducted 5S workshops at that particular plant. If you're thinking that 5S might have addressed this issue before it became a problem...you're right.)

5S Report Followup

2009-12-17T01:11:00Z

A few weeks ago, I posted about a 5S workshop I recently conducted. I cross-posted the same article on a LinkedIn discussion group. I got several responses, but this one was especially interesting. It's long but you'll like reading it.

I had mentioned the value of 5S in reducing raw material inventories. Here's the response.

Having several years of wire and cable experience, it is amazing the batch mentality that still exists in this business. SMED has not been necessarily embraced and therefore long runs are still encouraged. I wonder how everyone felt about two years ago when copper prices went through the roof about these practices.

I am also a former procurement officer with a military/defense contractor. Our shop, which manufactured highly one off, custom equipment ran extremely lean with regards to raw material inventory.Based on COGS our active raw material turns were typically above 20Xper year while our total turns were in the low teens. The reasons for this discrepancy were caused by engineering changes to BOM's that were never communicated back to procurement such that custom equipment that was procured never to be used could either be returned, repurposed or otherwise reserved and written off. Over a period of several years prior to my arrival, this stockpiling blossomed into an inventory valued at over $1 Million dollars (50% of all inventory). Ever tried to unload an unused C-band satellite dish that's 6 years old when the current technology is now HD. Oh, there may also be ITAR rules that apply that prevent you from selling it anywhere outside the country as well. How about a custom ordered truck chassis with an international,non-emission compliant engine package that was purchased based on a pending contract that never actually materialized (a $100,000 dollar paper weight). Who is on the hook for that one because the contract negotiators couldn't live with the original lead times and therefore bet that by promising a shorter lead time (and ordering the truck) they would win the bid. WRONG.

I agonized over this truly broken process and begged the engineering and contracts department to sit with procurement to improve the BOM process to reduce and/or eliminate these unnecessary spends but senior management couldn't develop the disciplines (didn't want to) and wanted to remain flexible (lazy) in their design choices. That's fine,but realize that there is a cost to doing that, especially when your dealing with one of a kind custom ordered equipment. Their attitude was, just push it back to the vendor, if they want our business,they'll eat it. Problem was, this vendor was a sole source for this technology. Not too many options at this point.

Its easy for people that are in the chain to just make edicts, but until they understand the whole process and landscape and ask the question WHY, things like this will continue to happen. Keeping ones head in the sand hoping problems will go away isn't an effective way to manage. It takes teamwork and understanding by all involved to arrive at a best balanced solution. But then again, what do I know.

How to Keep Lean Going: Standard Work 4

2009-12-14T12:40:00Z

In my last post, I promised to attach some examples of standard work instruction documentation. Assuming I did the file upload correctly, here it is.

As you look at this, keep a few things in mind:

I don't present this as a perfect example. I'm betting many of you have seen examples that are more comprehensive, not to say, better looking, than this one is. I just present it as an example that's pretty good. It has fairly detailed instructions, pictures, and those neat annotations. (I did it all myself!)
Anything like this is subject to ongoing improvement. Strive to get it good and reasonably user friendly but don't strive for perfection before you "go live" with it.
I hope the format makes it clear that the primary use for these materials is training. If they also work for ISO and that sort of thing, wonderful. If not...well, I've seen many organizations that were ISO registered but didn't actually do squat when it came to training. If you're going to go to the trouble of putting all this together but then NOT do training...you should save yourself the trouble.
The format is one that's worked well for me. You might like a different format better.
What about quality standards, safety standards, TPM steps, and so forth? I agree...that would be good stuff to add, if you're so inclined.

Here are the work instructions for a box machine changeover.

How to Keep Lean Going: Standard Work 3

2009-12-07T14:35:00Z

Last time, we talked about the importance of setup sheets or documents with basic information about each setup.

Setup sheets aren't the same as setup instructions. Setup sheets are the "recipe" for someone who already knows how to carry out the setup in general. A recipe in a cookbook tells you what temperature to turn the oven to and how long to leave the brownies in but it assumes you already know how to turn the oven on and set the temperature.

We also need to "how to" instructions for a setup. Just as, at some point, you needed instructions on how to turn on the oven and set the temperature. This gets us to actually documenting Standard Work.

Simply put, you're going to list each step in the setup. Then you're going to write instructions for carrying out that step. That's it.

First, some guidelines:

Simpler is better. Don't confuse the issue with lots of jargon, extra information, references to other sets of instructions, etc. Step by step instructions are challenging enough to document. Don't make it harder on yourself or the trainee.
Pictures are helpful.
Make certain...CERTAIN...that the instructions are user friendly. Instructions that the writer understands are of no use if they are so badly written that no one else can follow them.
Make certain that the instructions are fairly detailed and complete. Don't just write, "Install left-handed widget". If they knew how to install it, they wouldn't need training. Provide the instructions for installing the widget.
Along those lines, a checklist can be helpful but don't confuse a checklist with a set of instructions.

Next time, I'm going to attach some examples of standard work instructions. They're not perfect but they're not bad either and they worked pretty well for the organizations that developed them.

How to Keep Lean Going: Standard Work 2

2009-12-02T21:16:00Z

We're talking about documenting work practices and, in my last post, I referred you back to your 5S workshops.

This time we're going to talk about documenting changeover practices.

Once again, the best time to document the how changeovers should be done is right when you're conducting the quick change workshop. Once you have your new procedure....write it down.

Let's talk about another aspect of changeover "how to"...setup sheets.

Setup sheets go by different names but, essentially, they all contain about the same information. For a given product, the sheet gives the operator all the information he or she needs to set that product up. Mind you, it's not an instruction sheet per se. It's more of a basic data sheet. Information about the part or product, quality specs, customer requirements, tooling, run speeds/rates, machine settings, packaging, and so on are contained on the setup sheet. Each sheet should have information as to what the standard/spec/setting should be as well as a space to record what the operator actually achieves when she or he get the part or product running well.

You need setup sheets for every product at every machine. That's a lot of work. But, if you don't have them, you're creating a lot (a LOT) of lost time, scrap, quality defects, low efficiency, frustration, and unhappy customers.

How to Keep Lean Going: Standard Work 1

2009-12-02T19:58:00Z

Like much of lean/agile manufacturing, standard work is easy...and hard.

Here's the easy part...you just need to document how folks do what they do and train to that.

Here's the hard part....you have to document how folks do what they do and train to that.

The "documenting what folk do and how they do it" part has proven, in my own experience to be difficult to get companies to carry out. It's a labor intensive project with long term benefits and short-term hassle.

The first challenge is answering the question: "What tasks do we document? Where do we start?"

Start with the basics and with what you've already been working on.

Let's go back to 5S...at the end of each workshop you've been documenting procedures and actions as to how to keep the machine, the line, the area 5S'd, right? No? Then go back and do that. As I say, each area, machine, line, etc. should have its own 5S procedures. What will operators do during and after each shift, each week (or so), each month (or so) to keep the area 5S'd? What equipment and machine checks will them make? What "operator maintenance" tasks will they perform? (Operator maintenance tasks are those simple tasks that help keep equipment running optimally that can easily be carried out by an operator without the need for special training. Examples might be checking fluid levels, checking appropriate gages or recording devices, checking for oil leaks or loose electrical connections. It might...might...include tasks like changing filters or making other very straightforward changes or repairs.)

Got all that done? OK, you're well on your way to creating Standard Work throughout your shop.

Next time, we'll talk about documenting changeover practices.

How to Keep Lean Going

2009-12-02T14:17:00Z

My "How to Get Started" series has been going on for several months. Eventually, you get to the point where it's not starting your worried about...it's "What do we do next?" (I might have gotten a bit over into this part of the lean implementation in the first series.) So, we need to start looking at what you need to do now that you have all the basics in place.

In the previous series, our activities were those that you could just do. You can just schedule and do the leadership planning. You can just do 5S or Quick Change or a VSM. Granted, you might not do them well or you might not followup so that you continue to do them effectively. You might not deploy them beyond the first workshop. But you can say you did them. (In fact, that's what I think lots of companies have in mind when they say they're doing lean...they did one or more of these activities some time in the past. In their view, they're now doing lean.)

In this series, we'll be talking about activities that take time, study, work, and discipline. You can't just do them any more than you can just get a college degree. You earn it through several years of hard work. Same with the methods we'll talk about in this series.

What will we be covering in this series?

Here's the list:

Standard Work and Training
Preventive Maintenance
Pull Systems
Work Balancing

5S Workshop Report - Part 2

2009-11-24T11:13:00Z

In my last post, I introduced you to the idea that a 5S project might not be a straightforward enterprise. You might have to make some adjustments in your approach. I listed three adjustments I've had to make.

In this post, I'll review how I applied that thinking to a recent 5S workshop.

In the target area, a polymer was put between two sheets of aluminum and rolled. There were several sub-sections. Hardened polymer made the entry end of the machine look like a snow storm. All space around the machine was taken up with rolls of aluminum, either raw material ready to be run or "partials": rolls of the foil that had not completely run out but were being kept by the machine "just in case we ran that size again sometime".

Here's how I applied the "three adjustments":

Adjustment #1: Ask lots of questions
We spent about 10 minutes of the team answering my questions about which surrounding areas went with the machine and about the flow of material through the area.

Adjustment #2: Divide and conquer
On the basis of their answers, we focused first on an area where the raw materials for the polymer were stored and measured out. My questions about flow led us to tackle the material around the machine next. Lastly, we tackled the machine itself. We ran out of time before it was completely 5S'd.

Adjustment #3: Tackle a Big Problem
This turned out to be the interesting issue. Essentially, the area from which rolls were taken from the floor and lifted by crane to the top of the machine was filled with "partials" or rolls that had not been completely run out. Good raw material to be loaded onto the machine were being stored several yards away and had to be moved to the "staging area" and maneuvered around the partials.

I'm sure you can already see where I'm going with this.

We got rid of the partials to clear the staging area. We developed a procedure wherein the team would move the next shift's production into the staging area. We also developed a procedure to use up all the material on a roll whenever possible. A rack will be built for such partials as must be kept. (The team realized that, because three different sizes of foil are run on the machine, they would need space for three partial rolls. They also realized, however, that, if they stuck with their new procedure, no more than three partials should ever be present. At the start of our 5S, there were about 25 partial rolls on the floor.)

The area still needs some serious Sweep and Shine especially. And we didn't have time to implement much Visual Factory at all. But the team made a big improvement in the operations of that particular line.

5S Workshop Report

2009-11-23T12:08:00Z

I've a client that I've been helping get started with 5S. I think I reported on one of their previous workshops, in which they color coded two different fastener types to the machines that feed them into stamping presses. This has reduced errors and lost time due to feeding the wrong fastener to a press.

This workshop was just as valuable and as much fun.

First, let me go into some of what I face when we start a workshop.

As I've mentioned before, we start in the classroom, going over the basics of 5S. After maybe an hour, we go out onto the plant floor to get going on some "hands on" learning.

This is where things get interesting; there's often a big difference between how I hope to proceed and how I actually proceed.

Hope to..
The ideal is that we'll have a fairly small, well-defined area that simply pretty cluttered up with no plan or approach for storage of tools and materials. In this case, I'll simply start at one end, pick up something and ask, "Do we keep it, throw it away, or red tag it?" If it's a keep, then I'll ask, "Where does it go?" and we talk about how to store it and label that storage. This will segue into Sweep and Shine. Then we'll end up back in the class room to plan some Sustain. A disorganized area turns into an organized area pretty quickly.

Actual
The area is large with several "sub-sections". A "One S" (just Sort....nothing else) might even be in order because there is so much stuff in the area. The area is so covered with grease, old ink, paint, dirt, "oil dry", etc. that Sweep and Shine would be a major effort in itself. Flow of material through the area is difficult to determine.

Mind you, I've often experienced the "Hope to.." scenario. Everything goes well. But, just as often, I've run into the "Actual" scenario and I've found I have to make adjustments.

Adjustment #1
I need to resist the temptation to start 5Sing right away. I ask lots of questions and make the effort to figure out the flow of product and material throughout the area. I have them identify all the "sub-sections" and their importance in the overall picture to me. If we can identify a meaningful sub-section to 5S, we get started on that.

Adjustment #2
I am flexible around the possibility that a 1S (just Sort) might be the best start to the process. This was the case at a pipeshop in a local steel company. It was easy enough to divide the shop into smaller sectors but, even then, the first step for each sector was simply to Sort what stayed from what got tossed.

Adjustment #3
I look for opportunities to apply 5S principles to an important problem that afflicts the area. Poor flow is a common one, so if I determine that poor flow is an issue, we start on that.

Check back soon to see how I applied all this thinking to my latest 5S workshop.

How to Get Started: Part Six - Implementation IV: Value Stream Mapping 5 - Future State Map

2009-11-11T20:50:00Z

As of my last post, we had finished up a Current State Value Stream Map.

Now...what do we do with it?

Well, we're supposed to develop a Future State Value Stream Map. And I'm all for that. The issue I've run into, though, is this: By the time the team gets finished with it's Current State VSM (actually, usually before it's finished), it's generally got more energy for actually addressing the issues identified by the Current State map and not so much for putting together another map.

I don't usually push the issue of developing a Future State map right away too hard. If the team resists putting together a Future State map immediately, I let them right to solving problems but I do insist that they commit to developing a new Current State map at a later time to capture the improvements they make. I want to end up with some kind of documentation of the new process eventually but it doesn't have to be right now.

I do like to provide some guidance as to what the team focuses on as it tackles the problems it has identified. I want to make sure the team is tackling problems that will make a difference. I have the team step back from the Current State map and ask, "Which problem at which step is causing us the most delays or defects?" If we identify two or three possibilities, one of which can be addressed more easily than the others, we go for that one. But I don't tell them team to "pick something easy to start with". I tell them to go for maximum impact, if everything else is equal.

I remind the team that they are looking for significant reductions in total process cycle time. Sometimes, team members will focus on issues that make their work at a particular step easier and there's nothing wrong with this approach. Other times, team members will focus on the small stuff because solutions that would really make a difference are seen as requiring "top approval" and that's understandable. I tell teams that the goal is to make meaningful, significant improvements to the business. In the end, it's up to the team as to what it wants to tackle or propose, but I'm one to push to solve the big problems.

Assuming the team starts right into addressing an important improvement opportunity, your task as facilitator moves from helping them develop a VSM to helping them manage a project. There's a lot to this, more than there was just coming up with the original map, but I'm not going to cover that here. Just remember to stay focused on the project at hand; there can be a tendency for the team to go wandering back through different problems at different steps in their discussions of the problem it has picked. Before you know it, a team that was focused on solving a bottleneck in one department is working on a completely different issue in another department. If the team has made a formal decision to do this, that's one thing but you don't want the team simply to have wandered away from its original project. Stay on track. When an issue is addressed, go on to another one. If work on a specific issue is stalled for any reason, go onto another one if possible.

How to Get Started: Part Six - Implementation IV: Value Stream Mapping 5 - Current State Map (continued yet again)

2009-11-10T20:17:00Z

By now, you're well on your way to producing your Current State map. The team is probably already coming up with ideas as to how to improve the process. But you have one last step to carry out. This step is, as far as I know, unique to my own approach. There is probably someone somewhere doing something similar but I haven't seen anything like it in particular in the literature on value stream mapping.

It's a technique I learned in grad school and have applied to value stream mapping. The official term for the technique is "variance analysis". I usually just call it "brainstorming for the stuff that goes wrong at each step". Because that's what it is.

Here's the idea: the team goes back to the first step and brainstorms a list of everything that can go wrong at that step.

First, a few words about brainstorming (and you can skip this paragraph if you think you're well versed in the brainstorming method). Brainstorming isn't discussion...it's brainstorming. Get ideas, write them on a flip chart and keep going. Get as many ideas as you can. Don't let anybody get into talking about how bad the problem is or whether it's really that important or not. The team will sort the good ideas from the less good ones later. Get all the ideas written down.

So, again, go back to the first step and ask the team, "What is anything that can go wrong at this step?" You want to make certain that the team focuses only on problems that might occur at the focus step. Teams will tend to brainstorm problems that show up at a particular step but actually occured earlier in the process. For example, at the "inspect finished product" step, the team might brainstorm all sorts of quality defects that could be identified at that step. But the quality defect didn't occur at the inspection step, it occurred at an earlier step. It's at the earlier step that the quality defect needs to be put. On the other hand, the team might brainstorm "Quality department doesn't inspect in a timely fashion" would be a problem at the inspection step.

In other cases, you might need some clarification to make sure where the defect happens. For example, at a "receive raw material shipment" step, the team might brainstorm "wrong material delivered". You would ask, "Is this because of a ordering error on our part?" If so, then that problem would be listed at an earlier step. On the other hand if the team says, "We might have ordered correctly and still gotten the wrong material from the vendor."

After brainstorming problems at each step, the team will need to prioritize those problems. I usually have them do this at each step. Once they've brainstormed all the possible problems at a particular step, I'll ask, "Which of these problems causes the most harm and/or happens the most?" It's not necessary to get a rock-solid, data-proven set of priorities at this point. You just want a general sorting of more important and less important problems.

OK, that's it! You've finished your Current State Value Stream Map! What do you do with it? Check back here for the answer!

How to Get Started: Part Six - Implementation IV: Value Stream Mapping 5 - Current State Map (continued again)

2009-11-03T19:10:00Z

In my last post, we were talking about gathering data related to the "How long does it take between process steps?" question.

In many cases, we're in effect asking, "How long does it (the information, the product, the document) sit there?" In the case of product, it's also important to ask, "How much of it is typically sitting there?" Together, these questions can lead us to information that will show where our most serious delays and bottlenecks are.

You'll probably be surprised at how little information there is in your company relevant to these questions. Companies that can quote efficiency rates of people and equipment down to the fourth decimal point as of a few minutes ago have no idea how long it really takes to get product out the door. This is because, according to cost accounting procedures, the company is accruing costs when value is being added to a product but not when it's sitting still. So we know a great deal about the costs of actual production time but not the costs of waiting time. The fact that the data is hard to find is all the more reason why you need to look.

By the way, I mentioned in previous post that you also need to ask about the shortest, longest, and typical times for each of the process steps didn't I? Good. Companies tend to have a better handle on this sort of info, so I haven't spent much time on it but it's obviously important to have. Another datum that is important to have is what I call "leakage". Other names for leakage are scrap, loss of yield, rework, and rejects. Leakage represents the loss of valuable material and work. If I put 100 pounds of material into a process step and get 98 pounds out because of scrap, that's leakage. There's also the value of the machine and operator time on that pounds of material that has "leaked". Capture leakage at each process step.

Another thing about "leakage": it represents everything that doesn't come out of a step exactly the way it's supposed to. When I was working with the steel mill, I learned that steel that doesn't meet the intended customer's specs can be sold as secondary or non-prime steel to another customer. So they don't think of that steel as scrap (my usual term for leakage).

So, time and leakage at each step, time between each step. Draw your map and get all this info. That will take you a few weeks of meetings.

How to Get Started: Part Six - Implementation IV: Value Stream Mapping 5 - Current State Map (continued)

2009-10-30T16:30:00Z

In my last post, we were getting started on our map. I was saying that, even a simple approach to mapping a process generates a lot of discussion.

OK, so you're asking the team, "What's next?" and filling in the squares. Here are some issues you're likely to run into:

Parallel processes
Decision points
"Forgotten" steps
Steps that generate lots of other "feed in" steps
Process loops

Capture parallel processes as best you can, assuming that capturing them adds value to the map. Make sure decision points are needed in a "goes as desired" current state. In other words, make sure they aren't really "good vs. bad" decision points. If they make sense and help the team map and understand the process, keep them. (In general, I try to keep decision points at a bare minimum in VSM's.) "Forgetten" steps are those the the team remembers later in the map. Just go ahead and add them in. Steps that generate other "feed in" steps tend to be administrative steps like "produce the forecast" or "order the raw materials" or "Develop production plan". Sometimes the team will want to map all the steps that need to take place to get that document or that piece of info. I don't like to do this. It slows the mapping process down and often doesn't add much info. If it turns out that the step in question is problematic, you can always go back and develop that "feed in" process in more detail.

Once you have all the steps from first to last (circle to circle), go back to the first step and ask, "How long does this step take?" (Make it clear that you're asking how long that one step takes to complete. Teams will sometimes think you mean "How long from when one step starts until the next step starts?" And that's not what you want. For instance, if we're looking at two steps, "Make the Widget" followed by "Ship the Widget" and I point to the "Make" step and ask, "How long does this take?", the team might tell me how long it takes to make the widget and get it to shipping and wait in shipping to get loaded onto a truck. You need to separate all these times.)

Then the second step, the third and so on.

Then go back to the arrows, and ask, "How long does it take to get from the first step to the second step?" "From the second to the third?" And so on.

When getting this info, I'll generally ask for it in three ways:

What's the typical (or modal) amount of time it takes?
What's the least amount of time it takes?
What the most amount of time it takes?

In conversation, most folks understand "average" and "typical" to mean about the same thing. But if the team is actually going to pull data together (as it should be) and we say, "Get the average time," the info that comes back will be skewed. Most "time it takes" distributions aren't normal; if the least time it takes to get between steps is one day and the most is 100 days, the mathematical average might be 50 days, something that actually happens only a small percentage of time. We want to know the "On a typical day, how long does it take?" time, which is probably going to be more like two or three days.

The "least" and "most" times are just what you might think. So, you have a range of times along with the typical time between in step.

Enough for now. Tune in to my next post.