Agile Manufacturing Update

What do you measure?

George Bohan — Tue, 05 Aug 2008 06:13:29 GMT

I've always thought that manufacturing companies don't actually put enough focus on manufacturing as a source of competitive advantage. One of the supporting points for that position is what manufacturers measure...and don't measure.

Manufacturers tend to measure things that are directly or indirectly related to money. They measure output, an indicator of cost and, perhaps, potential revenues. They measure efficiency, again a measure of cost. They measure utilization, a measure of absorption of fixed costs. Often, they'll measure scrap, another measure of cost. They just about always measure budget variances.

Sometimes, thing customers complain about are measured like how often orders get to customers on time, or how often orders are incorrect.

To be sure, there's nothing at all wrong about paying close attention to these sorts of metrics. Cost is, after all, something that must be controlled if the enterprise is to remain competitive. And some of the yardsticks I've mentioned are as relevant to other performance factors (quality, customer service, equipment availability) as they are overall costs.

Still, most manufacturers tend to have few measures that really tell them how good they are at making stuff. Or how good they are at all the things they need to do to make stuff.

In my experience, total changeover times are rarely measured. Equipment availability is not as frequent a measure as one might assume. And getting good data regarding reasons for poor availability (or for that matter, late deliveries, incorrect orders, poor efficiency, poor utilization, etc.) is generally pretty difficult.

I get confused, at times, when lean manufacturing literature goes right to descriptions of the benefits of manufacturing cells, pull systems, takt times, and application of six sigma tools. Mind you, there's nothing at all wrong with those methods and many companies have found distinct value in employing them in their own operations. But most companies could get as much or more benefit by simply doing a better job of measuring what they're doing right now...then acting on what those measures tell them.

Agile Manufacturing and New Technology and Equipments

George Bohan — Tue, 29 Jul 2008 09:36:02 GMT

Many of the companies I've worked for were implementing (or had recently implemented) either some new technology (e.g., ERP system, MRP system), new machinery/equipment, or some combination of the two (e.g., robots). In my experience, companies don't typically do a good job of adding new stuff to their systems.

Here's the typical scenario:

Management sees a problem or opportunity.
Management figures that a technological fix will work.
Salesperson tells management that what they are selling will fit perfectly with existing systems and will be robust enough to adjust to any possible condition. Management believes the salesperson.
Salesperson tells management that, if the unlikely circumstance of a problem with their equipment/technology should arise, the vendor will respond immediately and effectively. Management believes the salesperson.
Salesperson tells management that benefits are assured. Management believes them.
Management buys new technology.
Management spends more time and money implementing new technology than anyone had anticipated.
Organization resists changes to existing equipment technology. Management acts puzzled, then angry.
New technology is harder to operate and harder to fix than than was the technology it fixed.
Management either sticks with the new technology and makes it work after much more blood, sweat, tears, time and money than it anticipated or chucks it out the back door and goes back to the old way of doing things after spending a lot of blood, sweat, tears, time and money in the failed effort to make it work.

I did some work for a company that was installing new equipment of a type that it was familiar with designed to do work that the plant was already doing. In other words, the technology and it's application were not new. The plant didn't get the new equipment up and running during the seven months I was in the plant. It was anticipated to take about three months from start to finish.

To be sure, not all companies have these sorts of bad experiences but an article I read reported that studies show that more than half of all new technology and new equipment implementations are either outright failures and have to be discarded or end up over budget and over schedule, often by very large margins, before they finally work. This pretty much matches what I've seen. And even this doesn't account for problems that can occur for months and years after a faulty implementation.

Too often, new technology and equipment that is designed to save money hurts the organization in a variety of ways:

It's hard to maintain,
It's hard to operate,
It's not robust, i.e., it's finicky and takes a lot of "tending to",
It's not "operator friendly",
It's down too much of the time,
It's hard to maintain quality,
It's hard to figure out what's going wrong when something is going wrong,
Only "specialists" can or are allowed to work on the new technology or equipment.

All of this means higher rather than lower costs and reduced agility. I'll talk about how to avoid all this in future posts.

Chrysler decides that customers might be important

George Bohan — Tue, 15 Jul 2008 06:22:54 GMT

This is the sort of thing that just drives me nuts. (It's a post in another blog about Chrysler's efforts to get more customer oriented.) Here's the link to the WSJ article that's the source of the blog post.

Let me see if I have this right...in 2008, Nardelli decides it's time to change the culture so that Chrysler is more customer oriented?

Look down in the WSJ article and find this sentence:

"They also saw a tendency for the company to use the cheapest parts available, even if that compromised quality."

Well, there you go...get all the top execs into a room and tell them to buy stuff that actually works.

Sheesh. No wonder these guys make the big bucks.

Better late than never I suppose.

July issue of my newsletter will be out soon

George Bohan — Tue, 15 Jul 2008 05:49:13 GMT

What do unlabeled controls, hard to read gauges, poor training, and unmarked tooling have in common? Subscribe to my newsletter and find out in the next issue.

To subscribe, go to my website and type your email address in the little block. That's all there is to it.

Setup Sheets

George Bohan — Mon, 14 Jul 2008 10:29:17 GMT

If I came into your manufacturing plant and asked where the information needed for every setup (tooling, settings, initial rates, final rates, etc.) was kept, what would the answer be? Too often, it's "I keep it right here," as the operator or setup person points to his or her head.

I'm surprised at how rare setup sheets are. I know that creating setup sheets for every product a plant makes is a big deal, but creating one for each of the, say, 25 most frequently produced products should be that difficult. But, too often, set up sheets don't exist for any products at all. If they exist, they're old.

The fact that setup sheets are available and up-to-date doesn't guarantee that operators won't make mistakes, but not having setup sheets at all just about guarantees that they will at one time or another. It also means that teaching new operators or setup people will be that much harder.

I don't care what you're doing that you call "lean manufacturing", if you don't have up to date setup sheets for at least your most frequently made products, you really aren't doing lean.

Some thoughts on Six Sigma...

George Bohan — Fri, 11 Jul 2008 05:26:24 GMT

I'm a proponent of good data collection and analysis and that makes me a proponent of Six Sigma in general. My experience, though, is that manufacturing organizations get interested in Six Sigma too early. Sometimes they get interested in Six Sigma instead of what they should be paying attention to.

Let me give an example.

I'm working with a company right now that stamps small parts for commercial roofing. Part of the stamping die is called a barb. These barbs are thin, pointed pieces of metal that poke holes in the metal. And they break...a lot. When they break they have to be replaced and that takes several minutes. So it's to everyone's advantage not to break barbs.

Now, the company could conduct an involved Six Sigma-type study as to the causes of barbs breaking with lots of data gathering and perhaps even some designs of experiments to test different barb configurations and composition. Or the company can focus on making sure that their are standard procedures for things like die setup, line setup, barb placement and replacement, that operators are trained to those standard procedures and that their practice is regularly assessed to assure that they stick with the standard procedure. And that's what this company is doing.

The point is not that Six Sigma won't provide some benefits in this case. The point is that, until the basic sources of variation are addressed, there's not much use in going after the more subtle sources of variation. Given, especially, that the resources of most small companies are limited, they are better off paying attention to standardizing, documenting and teaching consistent practices than in training Black Belts.

More on Value Stream Maps

George Bohan — Fri, 11 Jul 2008 05:27:39 GMT

In a recent post, I talked about my "value stream map conversation starting question": "Would it be worth it to cut the cycle time of the process, even if the cost remained the same?"

In the case of the client referred to in that post, the question prompted the first insights for the team as to what lean manufacturing is really all about.

The team I was working with at that particular client said they had never worked on a project that didn't have cost reduction as its primary motivation. Ever. So when I asked about possible competitive advantage that didn't have cost reduction as its foundation, they simply didn't know how to respond. No one had ever presented such a notion, that companies could compete on something besides low cost.

Ever more often, I see the term "lean" to mean "low cost". So, lean manufacturing becomes simply a rehash of old style, worn out manufacturing thinking and strategy: if we reduce the cost to zero, we'll have infinite margins. Nobody puts it quite this way, of course, but that's really what the low cost strategy is all about.

This isn't to say, of course, that cost reduction has no place in manufacturing, or in lean manufacturing for that matter. It would be silly to even suggest that. It is to say, though, that the reductions in cost achieved through the application of lean manufacturing concepts and practices aren't, can't be, the primary motivation for implementing them.

So back to the value stream map...it's primary purposes are two-fold: to reduce the cycle time and to reduce the variability of cycle time. Either is good. In the case discussed in the previous post, the quoted lead time for the product was six weeks but the real cycle time varied between three weeks (not very often achieved) to more than a year (not very often). If the value stream map allowed the company to hit the original six week lead time, give or take a few days, all the time, what would it mean to the business?

But both is better. A short, consistent cycle time is the essence of agility. Agility provides sustainable competitive advantage. Low cost doesn't.

OK...I Want To See More Participation Out There!

George Bohan — Thu, 19 Jun 2008 09:57:28 GMT

I'm not giving YouTube reason to worry, but the blog stats show that I'm getting a few more readers lately.

Here's the deal...I'm eager to see some comments. Let's get some discussion going, class!

Did you know you can also rate the articles I post? Click on the title of an article and just that article will be brought up. You can comment from there, provide a rating...and even print that article (see the little printer symbol above the copy? Click on that.)

Especially, you folks who are getting my email newsletter and coming here. A lot of you have your own lean and agile manufacturing experiences...share them with the rest of us. (In fact, if any of you want to post once in awhile...I think I can arrange that. I'll post just about anything on topic except insults directed to the blog owner.)

Value Stream Maps: Cycle Time or Cost Reduction?

George Bohan — Thu, 19 Jun 2008 09:38:12 GMT

I was facilitating a group as it developed a value stream map for one of its products. I couldn't get much energy in the room. They had been through similar mapping exercises before and nothing much ever came of them. Previous mapping efforts had always been devoted to identifying costs that might be wrung out of the process. Usually, it wasn't any trouble to identify costs. The solutions, however, usually required investments of time and/or money and there was the rub.

But we got through it, partly, I think, because I kept asking the question, "How long does this step take?" rather than "How much does this cost?"

Even as the chart was going together and the data being brought to the table by the participants, they could see that this wasn't going to be their father's process flow map. The attention was on time, NOT money.

It all came together when we finished the first draft of our current state map and I asked them to look carefully at what they had created and answer one question. (Before I give the question you need to know that a six week lead time for the product in question was quoted to customers. And meeting this lead time was iffy for the company.) The question was:

"If we could cut the lead time by half and hit that lead time consistently, would it provide a competitive advantage to the company, even if the cost remained the same."

The first response was....silence. After that....more silence. It was apparent that no one had ever asked such a question. Every improvement effort the team members had ever been a part of had cost reduction as a primary goal. Every meeting was devoted to making each unit of the product more cheaply. I was asking a question that was difficult to answer...because they had never heard the question (or anything like it) before.

The silence didn't last forever, of course. In fact, one participant said, "I think I get, for the first time, what this lean manufacturing is really about."

More about the specifics of their discussion and other thoughts on value stream mapping in an upcoming post so...stay tuned.

5S: Standardize

George Bohan — Thu, 19 Jun 2008 09:05:50 GMT

It's simple: label everything. Where things go. What things are called. Which direction to turn wheels and knobs. Does the lever get pulled up or down? Label it.

I often simply use yellow duct tape or electrical tape and a black magic marker to make a temporary label during an action workshop. It's true...this can look kind of tacky. But it gives the operators a chance to "live with" the new labels for awhile before committing to something more permanent. The idea is to get from "temporary and tacky" to permanent as quickly as possible.

In my experience, labeling goes a long way toward helping the organization Sustain the 5S gains. Labeling allows just about anyone to walk through an area and tell if 5S policies are being adhered to or not.

At one client, they've provided die carts for each work station. The die carts are labeled with what's supposed to be on them. Now, I don't know anything about the tools they need but, because of the labels, I can tell whether the die carts are in order or not. Does the labeling guarantee that the die carts are always in order? In a word...no. But it allows me, or the supervisor, or the plant manager, or...whoever, to see that a specific tool is missing and to point it out to the operator before he or she needs it. I can tell right away if Joe is missing his tin snips or not. If he is, I can (and do) tell him to round them up before the next die change.

Value Stream Maps

George Bohan — Mon, 02 Jun 2008 06:33:05 GMT

Value stream maps are simply good ol' process flow maps...with a twist. We do a little extra data gathering around how long stuff sits between steps.

I do value stream maps (VSM) as simply and quickly as I can, with a team, so that we can get talking about the value stream and how to improve it quickly. I'm not much of one to use lots of symbols or to insist on lots of data. (I've attached a value stream map from one of my clients that's been modified so as not reveal anything about the company.) The value streams I've facilitated start and end at different places (i.e., back with the suppliers in some cases, first step in the manufacturing process in others, customer inquiry in still others) but I have a consistent approach otherwise.

First, lay out the steps of the process. I simply ask, "What happens first? Then what? Then what?" As we go along, the steps are connected with arrows. This step can take several meetings because, quite often, the process in question has never been even informally mapped. The answers to "Then what?" aren't always readily available. In addition, the "Then what's?" don't always happen in a neat, serial fashion. The "Then what's?" can take place as parallel steps, for example.

Next, we go back through the map and answer the question, "How long does it take for info/material to get from this step to this step?" Having used squares for the process steps, I use triangles for the "time steps", i.e., to capture the amount of time between each step. As a first pass, I just get team members' best guesses as to the data to put into each "time step". And, yes, these "best guesses" occasionally turn out to be way off the mark, so we do spend time verifying the data. (This step in the process turns out to be an education in itself. A recent VSM showed that the process being mapped...it was a supplier to customer map of a high volume product...was in better shape, lean-wise and agility-wise, than they thought. In other cases, the learning has been in the other direction, i.e., the process was much slower than was thought.)

Another thing...as I'm getting these "best guesses", I get a range. I'll ask "What's the quickest this ever happens? What's the longest it might take? How long does it take, typically?" This is important because I stress that agility is a matter of getting variability out of a process and these data show how variable processes can be in their cycles times. The sum of all the "longest it takes" times is often several hundred per cent greater than the total "least it takes" time. I use this "total range" later in the process to generate discussion about the value of reducing variability in cycle time, even if we don't reduce average cycle time.

Then I have the team go back through the steps of the process and, at each step, brainstorm variances. Variances are simply what can go wrong at each step.

At that point, we have a map, some data about cycle times and some qualitative info about what goes bump in the night. Now I get a discussion going by asking the following question, "Even if we don't take any cost out of the process, would we get a strategic advantage if we were able to reduce the either or both of the average cycle time and cycle time variability?"

More about this question and the sorts of discussions it generates in upcoming posts.

More thoughts on 5S

George Bohan — Mon, 02 Jun 2008 05:42:02 GMT

I think I've mentioned that the lean tool I've taught the most frequently is 5S. This isn't a personal preference (though I do think it brings a variety of benefits) so much as it is a client preference. I think it's because a 5S action workshop (the term I use rather than kaizen blitz) can often create lots of quick and (this is especially important) visible change.

I've always thought there is more attention to the "housekeeping" benefits than there is to some of the other advantages 5S can bring. In some cases, it's true, I've seen a great deal of value come simply as a result of the first S. Clearing years, sometimes decades, of clutter out of an area makes it easier and safer to work in, not to mention easier to find stuff.

In other cases, though, it is another S that can provide the most value and I'm not sure it's always recognized. Sweep and Shine (my third S...even though it's two S's) can to preventive maintenance. Straighten can lead to redesigning tooling storage. Labeling as a part of Standardize can be integrated with task instructions, which, in turn, improves new operator training. (For example, the parts of a machine get clearly labeled, which makes it easier for a new operator to learn what to do.) Even good ol' sort leads to a different approach to working with vendors to reduce the inventory of supplies and raw materials.

If we get these benefits by doing 5S, why do I care if the organization pays much attention to them up front? Because getting full value from these sorts of changes and initiatives requires a good bit of work after the 5S and organizations tend to be focused primarily on the "before and after" pictures; if the place looks good, the 5S was successful.

Lean in Healthcare...again.

George Bohan — Tue, 20 May 2008 10:16:06 GMT

Just after publishing yesterday's post I came across an article on the 'net version of NYT. I think you have to be registered to get on the NYT site, but it's free. The title of the article is "In Hospitals, Simple Reminders Reduce Deadly Infections". Do a search and see if you can get to it.

The article never makes reference to "lean methods" or anything like them but reports on a couple of methods being used Woodhull Medical and Mental Health Center in Brooklyn.

Here are a couple of excerpts (I'm hoping this falls under "fair use" doctrine):

"Timeouts to wash hands and put on hairnets, a simple checklist to ensure that such seemingly obvious precautions are done, and advertising campaigns directed at everyone from the most senior doctors to the poorest of patients have been credited with drastically reducing the number of serious infections at New York City’s public hospitals."

"In late 2005, the city’s Health and Hospitals Corporation adopted a series of simple, standardized protocols based on those developed by Dr. Peter J. Pronovost, a crusader against preventable hospital deaths and a professor of anesthesiology and critical care medicine at Johns Hopkins University. Dr. Pronovost calls his protocols a checklist, and that is pretty much what they are."

"One person, usually a nurse, acts as the referee by calling, “Timeout!” and checking off the “completed” or “not completed” columns on the list as each step is called out and performed."

It's a great story and an interesting read.

And it provides support both to those who feel that lean methods have a place in health care and folks (like me) who agree that they have a place but don't need to have a name (lean or otherwise) to go with them.

My problem with labeling methods or programs as being "lean" methods seems to imply that they are special and unique and available only to those well versed in the whole field of lean concept and practice and who know the jargon. As the article implies, lean and agile practice is no more difficult than making a list and checking it twice.

Lean in Healthcare?

George Bohan — Mon, 19 May 2008 05:31:20 GMT

I recently came across a free whitepaper about lean in healthcare. (Let me know if that link works or not. It should download the file for you.) I'm of two minds about this. On the one hand, I'm not about to disparage any organization that seeks to improve itself any way it can. On the other hand, I wonder if this isn't the old story of organizations implementing the "flavor of the week" and calling in by the latest buzzword. (See my post about lean in landscaping.) Would you choose a hospital because you heard it was implementing a lean initiative in an effort to emulate the Toyota Production System? I could be wrong but I'm guessing not, and you know what lean is all about. Imagine what your everyday man or woman off the street thinks if he or she were to hear this.

Again, my point isn't that hospitals shouldn't look into lean methods and strive to implement them. I've worked in health care organizations, and, by and large, they are apt to pull implement good methods where ever they find them. It's more that:

We see the problem with the nomenclature. If you hear that your car manufacturer is implementing lean methods, you don't worry so much that the leadership might have the "cost cutting" mindset as it goes about learning the new methods. If you hear your local hospital is implementing lean methods, you'd probably be a bit concerned about the possibility of a "cost cutting" mindset. (I want to make myself clear. I'm not saying the lean methods are only about cost cutting. I am saying that too many leaders see it as being only about cost cutting.)
We see that the term "lean" is being applied to any continuous improvement program. (Again, see the "lean in landscaping" post.)

I've written about my issues with nomenclature in past posts, so I'll focus on the second point. What's the harm if organizations implement continuous improvement programs that use a few lean methods and refer to that as a "lean implementation"? A couple of things: either the terms "lean enterprise" or "lean organization" or "lean methods" either mean something specific or they don't. If they get used to describe any continuous improvement initiative, then they are being used as buzzwords to describe whatever the organization (or consultant) wants to do. (I saw something the other day in which the writer said he or she attended a "lean methods" seminar in which the consultant/speaker advocated creating competitions between employee teams to increase production. I don't need to tell readers that this is the precise opposite of anything resembling good lean/agile process.) When these approaches fail, we hear things like, "We tried to implement lean methods/the Toyota Production System, but it didn't work so we dropped it."

So, download the paper and tell me what you think.

"Productivity" and "Efficiency" are hard paradigms to overcome

George Bohan — Thu, 19 Jun 2008 09:39:36 GMT

I have a difficult time (sometimes) getting managers and workers to get past a manufacturing mindset that attends only to productivity and efficiency. I know lots of managers would ask, "Why in the world would we want to get past that sort of thinking? That's what it's all about!"

Here are the problems with the "efficiency and productivity" paradigm:

It encourages running fast rather than running steady,
It encourages running lots of rather than just enough of,
It encourages compensation and reward systems based on "lots of stuff, fast" rather than "just the right amount of stuff, good",
It seems to encourage finger pointing rather than problem solving (I don't know why this should be so but have you ever seen a plant where a strong "productivity and efficiency" mindset existed that didn't also have a lot of finger pointing?)
It doesn't encourage good preventive maintenance, good training, consistent work practice, teamwork, continuous improvement, good information flow, or good planning (Again, it's a mystery why this should be so. But it is, in my experience.)

What should replace the "efficiency and productivity" mindset? A "low variability, smooth flow" mind set. The big question is not "How fast can we run more parts?" It's "Can we set up tooling, run just what's needed, change the tooling, and run just what's needed again without any problems or delays? And can we do that over and over again?"

When landscapers start using lean methods....

George Bohan — Tue, 13 May 2008 07:51:43 GMT

I teach a class at Kent State University from time to time on Total Quality Management. I make it a class on managing change in organizations but I use lots of examples from my own agile manufacturing clients. The first big assignment is to write about a company, describing its environment, strategy, and systems. One of my students wrote about a landscaping firm owned by a family member, describing its LEAN (that's how she wrote it, so I imagine it's an acronym for something) implementation.

I was interested in learning how lean/agile methods are being applied to landscaping, so I read on with interest. One of the "kaizens" she described led to putting a holder of some sort on the front end of the riding mowers. It would hold the weed whacker so that it was easy to store, easy to retrieve, easy to put away by the landscaper. A 5S in miniature, you might say.

My first thought was, "So 'lean' is being used to describe any program in which employees come up with ideas that make their jobs easier?" My second thought was, "So what if it is?"

I am of two minds about it: on the one hand, any program that involves employees in making their jobs easier and more productive is good, whatever the name. On the other hand, if we refer to any improvement effort as "lean", don't we dilute the term? If it covers everything, then maybe it covers nothing. If it means whatever anybody wants it to mean then it makes it tougher to tell others what it actually is and how lean/agile methods are, in fact, different from other approaches.

Where blogging and agile manufacturing meet

George Bohan — Tue, 13 May 2008 07:25:37 GMT

When I started this blog, I fully intended to keep it up to date, posting often. Maybe not daily but at least once or twice a week. Like most of us, I spend a bit of time at my computer and at least some of it is spent looking at stuff on eBay, right? And what could be easier than transferring some of that eBay watch time over to blogging, right?

But I look back at my blog history and I've been good for one post every two months or so. Maybe.

The fact is that being a good blogger, like being a good practitioner of agile manufacturing isn't that terribly difficult in and of itself. It does take a lot of discipline.

It takes discipline to actually type those thoughts down and get them on the blog rather than spending another ten minutes looking at moose pitchers that are up for auction. (Yes, there are lots and lots of moose pitchers on eBay.) And it takes discipline to sustain 5S, quick change, development of task instructions, total productive maintenance procedures and everything else that's needed to make agile manufacturing successful.

Who knew that blogging would give me some insights as to the challenges managers face when they implement agile methods?

So, OK...I'm going to get better about getting these blog posts written and all of you get better about doing your 5S walk throughs.

Yet More 5S...Sweep and Shine

George Bohan — Thu, 01 May 2008 16:25:43 GMT

We've been over two of the five S's, Sort and Straighten. Now it's time for some Sweeping and Shining. (Yes, I know that's two S's but I sort of mold them together into one S.)

Sweep and Shine is just what it says. Get out the mops, brooms, and rags and clean it all up. But there's another side to this step...inspect. The idea is that, as you're wiping and shining and sweeping out from under, you're looking carefully at the equipment, machinery, tools, and tooling that you are handling. You're checking for any problems, any defects, any needed repairs. Ideally, you are making those needed repairs and addressing those defects and problems during the 5S workshop yourself. At the least, you are writing a work order to get taken care of.

I might have already mentioned this, but I conducted a number of 5S workshops at a local steel mill. Those focused mostly on the first two S's. Lots of stuff was thrown out and the rest was put where it could be found again.

During recent workshops at my metal stamping client, on the other hand, we've focused mostly on this third S. (We don't decide ahead of time which S we'll end up focusing on, it just seems to happen.) There wasn't much to Sort and Straighten was easy with just a few tools to put in place. Sweep and Shine, on the other hand, led to lists of action items regarding small repairs and "fixes" to the presses and the auxiliary equipment. A loose cable here. An electric box without a cover there. A sensor that needed to be permanently placed. That sort of thing.

So, just as Straighten can mean more than simply lining a few items up on the workbench (it might mean completely re-organizing how and where tools are stored), Sweep and Shine can mean more than...well....sweeping and shining.

Still More on 5S

George Bohan — Mon, 11 Feb 2008 06:16:55 GMT

In my last entry (geez...it wasn't that long ago was it?) I was talking about my experiences with 5S and why I like to commence with it first whenever I start a lean project. I spent a bit of time talking about the first S, Sort. In that post, I mentioned that the first S does a lot with respect to generating some team energy and enthusiasm for the overall 5S project. It also provides some quick, visible results both along the lines of "Look how much better this place looks," as well as along the lines of "You know, it's a lot easier to get work done now!"

In my experience, the first S (Sort) and the second S (Straighten) go hand in hand. The question, "Where does this go?" is a great immediate follow-on to the "Do we keep this, red-tag it, or throw it away?" question. (Assuming, of course, that the answer to that second question is, "Keep it.") So let's look at that second step.

Straighten: Where the heck did that allen wrench go this time?
Most work areas I've worked in have a lot of clutter that gets handled in the Sort step. Others didn't have quite so much clutter. But I've never seen a work area that didn't derive great benefit from the Straighten step. Tools lying everywhere, supplies spread throughout the plant, raw materials and finished product placed wherever an operator or a material handler chooses to put them, personal items mixed with work items are par for the course. And, oddly enough, the Straighten step often meets with a bit more resistance from workshop participants than does the Sort step.

Here's how it goes:

Me: Do we keep these tools?
Operator: Of course!
(Sort step completed.)
Me: OK. Where do they go?
Operator: Right there on top of that machine where you picked them up.
(Straighten step...not completed.)

And, when I point out that we want the standard location for supplies and tools to be close to the point of use, it sometimes gets even harder:

Me: Where can we put this so that it will be easy to get to when we need it and easy to put away?
Operator: Well, right on top of that machine where you picked them up was pretty good.

So, usually it takes a bit of encouragement and cajoling to get participants to decide on a standard location for items.

In addition, the team needs to come up with standard locations that everybody buys into. This points to the need to get input from everybody on all shifts who works in the area. Nothing demoralizes a 5S team more than having all their good work undone by second shift, who puts everything back where it was pre-5S.

Straighten can be fairly labor intensive, especially if there are lots of shelves, cabinets, drawers, and such in the 5S area. You have to take these into account when deciding how big an area to 5S within a given amount of time. A team might be able to 5S a fairly large area around operating equipment in the same time that it takes to do a small area that contains shelves and cabinets. When a team does a 5S, it has to 5S everything in the area.

So, just like Sort, Straighten is pretty easy as far as the "how to do it" part. It's a little harder with respect to the "getting them to do it" part.

Metrics for measuring lean/agile manufacturing

George Bohan — Wed, 19 Sep 2007 06:24:56 GMT

I start all my projects with the development of a set of metrics that the client will use to measure agile performance on the shop floor. Over the years, I've found that companies don't have good measures of shop floor performance at all. At best, there might be some efficiency measures, maybe (maybe) some measures of scrap. They also tend to be drawn toward accounting/budget measures (i.e., direct and indirect labor, budget variances, none of which, IMHO are very useful in telling them how well they actually make and deliver things.

I like measures that tell us how good we are. Measures that tell us how long it takes to do things and how often (or not) we do things the way we're supposed to. I like measures that are easy to explain. I like measures for which it's intuitively clear which direction they should go and why. I like measures that can be put onto a chart that is easy to interpret. I like measures that are based on data that is easy to collect. I like measures that tell us how long it takes to do something (change over time) or how often we do what we're supposed to be doing (making good parts, getting the tooling to work the first time it goes in, getting stuff to customers on time).

I don't like cost measures, e.g., cost of scrap. They can go up and down for reasons unrelated to how good we are. I'm not crazy about most of the efficiency/productivity measures I've seen because they tend to focus on the individual worker and they are generally based on some sort of standard rate, which, too often, nobody knows where it came from to begin with...or somebody picked it out of the air. I don't mind percentages (e.g., scrap) but I don't like complicated ratios. I don't like measures that have had all the "unusual circumstances" edited out before the data is gathered. ("On time" measures seem to be especially vulnerable to this...it's either on time or it's not.)

I've found managers do a pretty good job of developing the metrics they need but sometimes it's tough for them to get past the measures they find comfortable or that help them oversee the business but that don't do much for supervisors, leads, and operators by way of telling them where they are doing well and where the opportunities for improvement are.

A couple of quick examples: before the agile projects I start with my clients, many of them don't measure changeover time (last good part to first good part). They know it's important but they just don't track it. That just blows me away. Another uncommon measure: How much of the stuff the suppliers send us is any good?
Or: When we put tooling in to start the next work order, how often does it produce good product right away? Or how often do we go to make something but either the tooling, the machine, the raw materials, or the right personnel weren't available?

Starting the project with the development of these metrics serves a number of objectives, including helping me help them understand the fundamental business case for agile methods. It's not cost reduction, it's getting better at doing things the customer wants at a lower cost.