Agile Manufacturing Update

Progressive Lean Sort and Shine: Part 4

George Bohan — Fri, 27 Jan 2012 12:15:25 GMT

OK, you have team leaders and they've been trained. It's time to get started with the actual sorting and shining.

Here's the basic approach: The manufacturing operations is going to be "divided up" in to areas. Each area should have a team leader. (Areas might further be divided into several locations .) A "Sort and Shine Schedule" is developed. The Sort and Shine Schedule indicates the days and times when operators will devote themselves to sorting and shining. You keep at the schedule until all areas are sorted and shined.

Now, let's go into a bit of detail.

Areas and Locations
In general, an area is the territory a team leader is responsible for. A location is a logical smaller space within an area. A present client has areas that each include several manufacturing lines. Each area is coordinated by a team leader. Within those areas, each line is considered a location. In another operation at the same client, there are manufacturing cells, each with a team leader. In this case, each cell is considered an area and each machine within a cell is considered a location. At that same client, the tool room as a whole is an area. It's divided into about ten locations; each of those locations has one or two machines, or a group of storage units. The idea is that sort and shine is carried out at each location until the entire area is completed.

Schedule
You must have a schedule. If you simply tell team leaders to go sort and shine as they and their teams get time...it simply won't happen. You must have a definitive, clear, posted schedule that shows the specific days and times when teams will stop what they are doing...let me repeat that: STOP WHAT THEY ARE DOING...to sort and shine. You can have a central schedule that applies to all areas or different schedules for each area. The schedule can provide for frequent short periods of time (e.g., every Monday and Wednesday from 2pm to 3pm) or longer periods of time less frequently (e.g., first and third Tuesday of the month from 6am to 12pm). But the schedule must have days and times and it must be posted. Then you have to keep track of the teams' performance against their schedules.

You can't overestimate the importance of the schedule. Sort and shine simply won't happen without it. (You'll find it's difficult enough to get it completed with a schedule.)

Progressive Sort and Shine: Part 3

George Bohan — Wed, 25 Jan 2012 11:57:39 GMT

OK, you've selected your team leaders...now they'll need some training in the foundations of agile manufacturing, and 5S and its purposes. They'll also need a bit of instruction as to how to go about leading and facilitating Sort and Shine.

I use a half day session to cover all this material. About two hours is devoted to agile concepts and another two hours to carrying out Sort and Shine. During the two hours devoted to Sort and Shine, I go over the purpose of 5S in general and its role in the larger agile initiative. Then we dig into how to get Sort and Shine done.

It's pretty straightforward, as you might imagine. Sort and Shine is...well, sorting and shining. I explain the terms, talk about the red tag area, and go through a quick mock "sort and shine" out on the plant floor. I also explain the self-review format and process (which I'll cover in a different post). That's about it.

If it seems simple...it is. If it seems too simple, not to worry. There's more training coming. Besides, most of the knowledge exchange isn't going to take place in the classroom, it's going to occur as you coach the team leaders as they actually implement the various phases.

Book Review: Car Guys vs. Bean Counters

George Bohan — Tue, 24 Jan 2012 21:05:57 GMT

Bob Lutz, former big kahuna design guy at all three of the Big Three plus BMW, wrote the book and it reflects his ego. Mind you, it's a good read and I recommend it but it's apparent that Bob sees himself as the best thing since sliced bread vis a vis Detroit and car making. The upside of this is he doesn't pull many punches and we get a good bit of information as to the inner workings of auto companies, culture and strategy-wise. The downside is that sometimes he just spouts off without direction or an apparent need to get his facts straight. At one point, he tries to pass off the lame rightwing canard about the Communities Reinvestment Act being the foundation of the economic crisis. That's just Tea Party baloney that's easily and often refuted but he repeats it any way.

In another case, he speaks of the time he spent communicating his particular vision to one and all. Good stuff, right? Well, he can't just leave well enough alone. He goes on to say (and I paraphrase here), "That might be counter to what an 'organizational theorist' would propose that I should have been doing..." First, I'm not sure exactly what an "organizational theorist" is but, for the sake of argument, let's say there are such. I'll go on record with a promise to pay Bob Lutz $100 for every "organizational theorist" he can find who will say that it's better to spend time in one's office poring over spreadsheets than it is communicating the vision to the troops.

Finally, Bob does a lot of whining about the media and Japanese car companies and how Japanese car companies are treated by the media. OK, it's his book...he's allowed some leeway here. But over and over? C'mon.

All that said, reading Bob's book is like sitting with him over beers listening to lots of interesting stories. Usually the stories flow and hang together well, sometimes they don't, but they're pretty interesting on the whole.

It's clear that Bob has great regard for intuition, creativity, playing hunches, experimenting, and bold decisions. He has far less regard for numbers, over-much process, over-much analysis, over-much discussion. He's not altogether wrong in these positions, of course, but I think it would be easy for a design guy to assume that the intuition and gut level decision making appropriate in his field would be applicable to all aspects of the enterprise. There's no question that non-value-added admin processes are waste and that any organization can suffer from "paralysis by analysis". But you can't run the whole place based on hunches and gut feel.

One thing that does come through in Bob's book (and it's not the only good thing but maybe the biggest good thing): Good strategy and a culture that supports good strategy is impossible (or, at least, really difficult) to the extent that you don't love the product. Even if you're selling plain stamped disks, you have to feel that those stamped disks are vital to the well being of society. As soon as you see your own product as a mere commodity in competition with other commodities, you're on the road to ruin. And I'm not talking about blind acceptance of the shortcomings and faults of one's own product. I'm saying that a company has to be vitally interested in the product and the customers' relationship with it if one is going to have an equally vital strategy.

Bob does a good job of relating the manner in which "brand management" (think: toothpaste) and beancounting hurt the auto companies. I'd argue that both approaches come from a false "We just make a commodity" view of the product.

Books Reviews: Crash Course and Once Upon A Car

George Bohan — Tue, 24 Jan 2012 20:19:46 GMT

I've read two books that, IMHO, are "must reads" for anyone interested in the auto industry, strategy, general industry and manufacturing or business in these United States. Once Upon a Car by Bill Vlasic covers the buildup to the bankruptcies of Chrysler and GM. Crash Course covers much of the same ground but starts way back in the early days of the industry. It's clear both authors talked to a lot of the same people. Both authors even have the same line about Mulally when he signed the contract with Ford and it being the first time in four decades he didn't add a cartoon plane next to his name.

Both books are balanced. Both are very readable. (I have recommended the Vlasic book to my wife.) Both books would serve as good reading for any MBA strategy class.

The authors don't go into the companies strategies as such but it's not hard to pull at the threads and tweak out the overall fabric of strategy for each of the companies...such as it was.

Auto companies present interesting cases in strategy, I've always thought. For one thing, auto companies are big...really, really big. For another, the difference between a good decision and a bad one can be lots of money.... as in billions and billions of dollars. Lastly, when you're at the top of a company that is so very large, it's probably impossible to have even, say, a quarter of the information you need to make good strategic decisions. I can imagine it gets very easy to maintain the status quo, certainly if most things are going well as they were for the auto industry during the nineties. Even when they aren't going so well, I can imagine it's easy to hang on and hope for better times to come around.

Well, in reading these books, it seems like that's about how strategy, or what passes for it, unfolds within the Big Three. (And, it's starting to appear, within Toyota as well.) Add to this a culture that seems as if were purposefully designed to hinder communications, innovation, team work, and high performance, and you've got about everything you need for a set of businesses that need to be bailed out of their own incompetence every twenty five years or so (in the case of one of them, at least.) So, strategy is difficult for auto companies...but all the players knew this going in. And still they make the same mistakes over and over.

Here are the lessons I learned or the truths that were verified for me via the books:
1.) As a quote that starts a chapter in one of the books says, "Culture eats strategy for breakfast."
2.) Most of the folks running these companies really are as dumb as it seems they are. They keep doing the same things over and over and expecting different results.
3.) Big is good until it's bad. Then it's very, very bad.
4.) If you don't love the product AND THEREFORE the folks who buy the product, you shouldn't be anywhere near the company much less running the damn thing. This is why CFO's and lawyers make bad strategists.
5.) The most important competency an organization can have is agility. The most important loss a company can suffer is it's agility.

The Importance of Culture

George Bohan — Sat, 31 Dec 2011 01:28:06 GMT

From an HBR article, "The Contradictions that Drive Toyota's Success":

"Toyota has a strict hierarchy but it gives employees freedom to push back. Voicing contrarian opinions, exposing problems, not blindly following bosses orders - these are all permissible behaviors."

From Once Upon a Car: The Fall and Resurrection of America's Big Three Automakers:

[Mark] Fields learned quickly how Ford was ruled by pay grades, status, and titles. The first time he raised his hand in a big meeting, he was shot down by his boss... 'You never say anything until you tell your manager.'

Might be all we need to know about the difference between the two companies.

Progressive Lean: Sort and Shine: Part 2

George Bohan — Wed, 21 Dec 2011 11:28:51 GMT

The first step is to identify and appoint team leaders if you don't already have them.

The role of the team leader is to lead and coordinate lean activities in his or her work area. You might also have the team leader lead and coordinate production activities in the work area.

If you don't already have team leaders, you'll need to take these steps:

Identify and document the responsibilities, duties, and activities that you want the team leaders to carry out.
Make a decision as to whether or not you'll adjust the compensation of team leaders.
Post the team leader position. Interview candidates. Make your selections.

Identify and Document Responsibilities
Essentially, you're writing up a job description here and I'm sure you (or someone in your organization) has done this before. Make sure the team leader description capture the following points:

Team leader will be the coordinator of planning, scheduling, and implementation of lean activities in his or her area.
Team leader, with the team, will track progress on lean activities using the methods provided by the organization.
Team leader will work with the operating team to get all this done. Team leader will assure that the team is participating in lean activities and is engaged in using lean methods and tools as they are deployed.

Team Leader Compensation
You'll probably want to consider additional compensation for team leaders, especially if team leaders have production coordination responsibilities in addition to their lean initiative duties. You'll find that they do add value to the organization above and beyond any additional compensation, assuming that you utilize and support them.

It's difficult to say just how much additional compensation is appropriate without knowledge of prevailing wages in your industry or region. Trade associations or local business agencies will probably be able to help with this.

Post, Interview, Select
Don't appoint team leaders if you can avoid it at all. Take the time to post the positions, interview, and make careful selections. If you find that you're selecting the leaders you would have appointed anyway, no harm done. Often, companies, find excellent candidates whom they hadn't considered. Even if they don't end up selecting these candidates as team leaders, they have identified "bench strength": associates who can be developed to positions of responsibility.

Progressive Lean: Sort and Shine Part 1

George Bohan — Wed, 14 Dec 2011 11:22:14 GMT

Just about anyone who has any experience at all with basic lean tools will know what I'm talking about in this phase. Sort and shine...what could be simpler? And you're right...it's Sort....then Shine. The training won't take long, if you get my meaning.

What will take longer is the actual implementation. Not because it's a difficult tool. But because you're going to do it in a way that may change the structure and will probably start changing the culture of your organization.

Here's why....team leaders and their teams are going to plan, schedule, and carry out Sort and Shine in their own areas. With help, of course, but mostly, they're going to do it themselves.

Here's the game plan:

If you don't already have team leaders, you need to identify and appoint them.
You need to train the team leaders.
Either during the training itself, or some time shortly thereafter, the team leaders need to put together a Sort and Shine schedule for their areas.
The team leaders and their teams will conduct Self Reviews within their areas to show that they have completed and are sustaining Sort and Shine.
You (or somebody) will track their efforts and post them. The team leaders will meet regularly (weekly or bi-weekly) to review progress, bring up issues, etc.

I'll talk about each of these issues in upcoming posts.

Progressive Lean: Strategy and Spread the Word: Part 4

George Bohan — Mon, 28 Nov 2011 11:34:07 GMT

Finally, you need to do some training for team leaders so that they are prepared for the next phase: Sort and Shine. So, there are two issues to consider: the content for the training itself and just who the team leaders will be.

The first issue is easily addressed: Just use the material I've provided here (see the link at the bottom of the post). Adjust the material as you need to. The only thing I ask is if you do use this material is that you mention my name. That's fair, isn't it?

You'll see that the material goes over the basics of agile manufacturing as well as the details of how to implement the Sort and Shine phase. There isn't enough detail there to allow you to lead the next phase but don't worry about that...we'll give you that knowledge through these posts.

As to who gets this training, that might be a tougher issue if you don't already have team leaders. By team leaders, I'm talking about operators who have a few additional responsibilities regarding communication to and coordination of a small group of other operators who work in the same area and/or do similar work. Where the span of control of supervisors isn't very wide, they can act as team leaders.

What if the span of control of supervisors is wide but you don't presently have team leaders? Or you have them in some areas but not others? My recommendation is that you develop the position. And, yes, I know....that can be a big deal. But It will provide benefits throughout the agile implementation and beyond.
Here are a couple of articles from another blog to help you along (the first article is a little heavy on the jargon, but you'll get the idea):
Role of the Team Leader
Team Leader As Focal Point

You'll read that team leaders have central responsibility for making the agile initiative successful. That responsibility starts with the next phase. You'll depend on them to plan and carry out most of the "on the floor" activities" of that phase.

Team Leader Training Materials for "Spread the Word"

Progressive Lean: Strategy and Spread the Word: Part 3

George Bohan — Fri, 11 Nov 2011 13:15:43 GMT

Let's assume you have developed a set of measures you're happy with.

The next step is to develop a calendar.

Here's what's going to go on your calendar:

Regular day and time for Steering Committee meetings.
An "all employee meeting" to announce the agile initiative.
Deadlines for full development of the metrics.
Regular "all employee" meetings to keep everyone updated on the agile initiative.
Deadlines (albeit loose ones) for the upcoming phases

Last time I provided a list of things you need to put on your calendar. Let's look at that list again and talk about why you need to attend to each one.

Regular day and time for Steering Committee meetings.
I talked about the role of the Steering Committee (SC) in another post. The SC needs to meet no less than every other week (or twice a month, whichever) during the startup of an agile implementation. You can move to monthly meetings after a year or so, when the program has momentum. Weekly isn't too often. You should meet for four hours each month. In other words, if you meet twice a month, meet for two hours at a time. Weekly, meet for an hour. Devote one of your meetings to reviewing metrics. The other meeting can focus on reviewing recent activities and planning for upcoming ones. That's pretty much the agenda for SC meetings:

First meeting each month: How are we progressing? (Review of metrics)
Second meeting each month: What did we do last month? (Review of recent activities) and What's coming up next month? (Plan for upcoming activities).

An "all employee meeting" to announce the agile initiative.
Somewhere along the line, you need to announce to everyone what's going on. Some companies already have "all employee" meetings of one sort or another. This announcement can be made at one of those meetings. If you don't have regularly scheduled meetings with employees, you need to plan one.

The announcement doesn't have to be complex or involved. Twenty or thirty minutes should do it. This isn't the time to train everyone in agile concepts and tools. It will be enough simply to talk about what's been going on and what will be coming up in the near future. And make a pitch for their participation of course.

Deadlines for full development of the metrics.
During the planning sessions, you decided on what metrics you'd be using for the agile initiative. Now you have to make charts for all of them. You probably have some of the data ready to go and it's just a matter of making the chart. In other cases, there might be some "data mining" to do first. In still other cases, you might have to actually gather the data. Put deadlines on all these activities or you'll be twelve months into the initiative with no metrics.

Regular all employee meetings to keep everyone updated on the agile initiative.
If you already have a schedule of "all employee" meetings, you're set. If not, make a schedule. There...that was easy, wasn't it?

General time frames for the upcoming phases.
This is a hard one because you've never carried out the phases before and I don't know how large or complex your facility is. So, we're talking general time frames here, not hard and fast deadlines.

A few guidelines will help:

Think in terms of months per phase rather than weeks, unless your facility is very small (20 employees or fewer). My present client has about 250 employees and a variety of operations. It's taking them about 8 months to get through Sort and Shine (the next phase). The original plan was six months. Another client with 400 employees and equally complex operations took about six months but they also had two full-time "lean champions" that I worked with to push things along. In general, it's going to take longer than you think.
Be ready to be flexible. It's better to get through each phase well than quickly. As long as progress is being made and the effort is moving forward, don't get too locked in to specific deadlines.
Monitor progress against the schedule at your Steering Committee meetings. You'll be able to adjust the calendar as needed before the deadline is hard upon you.

As a rough guideline, plan for two months to get through this phase and six months for each of the next two phases. The last two phases are ongoing, though there will be elements within each that you'll want to establish time frames for.
.

Progressive Lean: Strategy and Spread the Word: Part 2

George Bohan — Thu, 03 Nov 2011 15:08:03 GMT

OK, you've answered the question, "Why the heck are we doing this?"

Now you need to answer the question, "How will we know it's working?" And that gets us to selecting metrics for the initiative.

I've written a lot about metrics and their selection here on this blog. In fact, I'm just going to link back to those posts rather than re-write it all.

How to Get Started: Part Five - Planning I

How to Get Started: Part Five - Planning II

How to Get Started: Part Five - Planning III

How to Get Started: Part Five - Planning IV

There you go. I know it's pretty lazy to just provide links but I didn't feel like typing it all again. Besides, it will help my Google Analytics numbers! Besides, I'm going to do the same thing when I get to developing the calendar, so get used to it.

Progressive Lean: Strategy and Spread the Word: Part 1

George Bohan — Wed, 02 Nov 2011 00:46:36 GMT

Like Julie Andrews said to those Von Trapp kids, "Let's start at the beginning. It's a very good place to start."

Before you go to kanbanning and heijunking, you have to develop a strategy for what you're about to do. Planning, of course, can be straightforward or very complex. I bet you're like me in that you prefer straightforward planning.

The planning I'm talking about will be done by senior leaders. Essentially, senior leaders will discuss and come to consensus on the following:

An answer to the question, "Why the heck are we doing this?" , aka, a vision;
A set of metrics by which you'll measure your progress;
A calendar of events and milestones.

Let's take them one at a time.

Why the heck are we doing this?
Before getting too far down the road, you need to get clear on why you're bothering to do all this lean stuff anyway. In other words, you're going to have to establish an overarching vision for the initiative. Because, here's the thing...lean is a royal pain in the ass to implement. Don't get me wrong. The tools are pretty easy. It's the discipline and the necessary culture change that will wear you out.

A "cost cutting only" vision won't work. It's too hard and requires too much investment up front.

What kind of vision will work? A strategic one. By that I mean that a lean/agile initiative has to be seen as a central part of your long term strategy to gain market share, building capacity so as to increase the top line. OK, I could wax eloquent for pages about visions dancing like sugar plums in your head but the main point here is that you have a clear one that provides an answer to the question above.

The answer should be strategic and proactive. "Cutting costs" is neither.

I'll talk about the set of metrics next time.

Company Culture and Lean: Communication

George Bohan — Mon, 31 Oct 2011 14:42:42 GMT

In a recent post, I listed eight components of company culture. The idea is that these eight components are the building blocks of culture. Further, they are eight "levers" that we can "push or pull" in order to change culture within the company.

Nobody will be surprised to see Communication at the top of the list, I'm sure. Communication is, simply, the manner in which members of the organization pass information back and forth and the channels they use to do so.

As we go through the eight components or "levers" of culture, we'll find that each will have a continuum associated with it that we'll use to describe the company's culture. In the case of Communication, the continuum goes from Tight on the one end to Loose on the other.

The closer a company is to the Tight end of the continuum the more likely it is to have close-to-the-vest, "need to know", untimely, infrequent communications through impersonal channels, e.g., posted notices, emails, "paycheck stuffers", etc. There will be formal policies regarding who is allowed to see what, hear what, transmit what.

Performance data, in particular, is likely to be closely controlled. I once had a client who I was helping to implement TQM methods. One of our first initiatives was to develop and share performance data, e.g., scrap, efficiencies, downtime, with everyone. One plant manager told me that, in the past, he would have been terminated for sharing such information with employees.

A lodging company I worked for didn't share customer satisfaction feedback with guest service employees until its TQM initiative started.

On the other hand, the closer a company is to the Loose end of the continuum, the more information (of all sorts) is going more freely through more channels. Communications are more frequent, more likely to be transmitted face to face. Information is transmitted on a "want them to know" basis. Performance data is more freely shared.

There are circumstances and conditions under which a Tight Communications culture is to be preferred: think of patient medical records in a hospital, or individual account information in a bank. In most organizations, though, a culture that is too close to the Tight end of the continuum risks having low trust, slow reaction to problems, slow decision making, and low morale.

The effective use of lean concepts and tools generally requires an organization to move down the continuum toward Looser Communications.

Company Culture and Lean

George Bohan — Mon, 24 Oct 2011 11:00:00 GMT

A lot of my own work is around helping companies change their cultures in ways that enable lean and agile methods but, I confess, I don't write much about it here. And that's not a good thing, especially given how critical I am of the manner in which most lean literature addresses the issue of culture...or doesn't.

The problem for me and all those other writers is that culture is difficult to define. Heck, it's even difficult to describe because it's so all-encompassing, so comprehensive.

I've come up with a way of looking at culture that makes it all more accessible, I think. We'll start with the model first, then work our way to specific examples.

The model tells us that there are eight elements that make up culture. These elements refer to things that all organizations do. Culture is simply...how they do them.

The eight elements are:

Communications
Decision Making
Planning
Collaboration/Teamwork
Motivating Performance
Managing Agreement
Teaching and Learning
Innovation

These elements are listed in no particular order of importance. The model says that all organizations do all of these things, one way or another. They may do them well or they may do them poorly but no organization has no internal or external communications. No organization doesn't make decisions. No organization doesn't plan. And so on.

You might look at some of the elements and say, "Wait...I know of organizations that don't plan or don't innovate." Again, doing something very poorly is different from not doing it at all. Take innovation: Can you point to an organization more than about 18 months old that is doing everything the same way it did it the day it started? My guess is, no. "But," you might reply, "I know of companies where such changes have been badly conceived, badly planned (when they were planned at all), and badly implemented. You can't really say that those organizations are innovative."

Again, to say that organizations, one way or another, attempt to change processes, products, services, etc. badly is not to say that they don't do so at all.

OK, you get my drift.

In the next posts on this topic, I'll provide a bit more description of each cultural element.

Progressive Lean: Let's Get Started

George Bohan — Thu, 20 Oct 2011 11:10:07 GMT

OK, after several introductory posts, we're ready to get started laying out the Progressive Lean approach. Here are the five phases:

Strategy and Spread the Word
Sort and Shine
Straighten and See
Simplify and Solve
Standardize and Sustain

Quickly, let's go through what will happen in each phase.

Strategy and Spread the Word
The Steering Committee is established. That Steering Committee develops a plan and a schedule for rolling out the subsequent phases.

The plan and schedule is communicated to everyone in the plant. Supervisors and team leaders are trained as to how to carry out the Sort and Shine phase.

Sort and Shine
The plant, both shop floor and administrative areas, is divided into areas. Each area has associated with it a team and a team leader who will further divide the areas into smaller locations. The teams will develop and carry out a schedule for sorting and shining those locations.

Straighten and See
Team leaders and supervisors are trained regarding visual controls. The teams develop a new schedule for planning locations for everything in their assigned areas, putting everything in the selected location, and putting the necessary visual controls in place.Implementation of Leader Standard Work begins.

Simplify and Solve
Supervisors and operators learn and participate in value stream mapping, team problem solving (A3, 5P, 8D...whatever), set up time reduction, poka yoke, kanban, heijunka. Teams are established to address operations problems and improvement opportunities.

Standardize and Sustain
Task instructions are developed. TPM protocols are developed and implemented. Systematic operator training and cross-training is implemented. Leader Standard Work is fully implemented.

That's it in a nutshell...a small one. Next time we'll look the whole plan over again and address some possible issues with it.

More on metrics...

George Bohan — Thu, 13 Oct 2011 10:25:26 GMT

Here's an article that I ran across in a LinkedIn discussion group...

As you might imagine, it's the sort of article that drives me (and, I'm sure, most practitioners) nuts. Here's the first sentence of the article:

"Lean manufacturing principles, widely touted by companies as an effective way to eliminate waste and boost the bottom line, often do not achieve targeted cost savings, according to a study to be released on Wednesday."

Right away, we know something is amiss. "Widely touted"? Touted? As if there were no evidence that lean principles and methods work? Please. OK, we'll allow for some journalistic license. Let's go on.

"Analysts at New York-based consulting firm AlixPartners LLP found that about 30 percent of companies surveyed achieved a 2010 goal of cutting at least 5 percent of manufacturing costs by employing lean practices such as those championed by Six Sigma, Kaizen or Value Stream Mapping.
Nearly half the 100 executives surveyed were targeting savings of 5 percent or more. The majority of executives reported savings in the 1 percent to 4 percent range, which AlixPartners views as being below the optimal range.
In addition, nearly 60 percent of the executives surveyed do not expect they can sustain at least half of the savings they did make over the long term."

Nowhere in the article will you see anything further about what "costs" means to the survey takers. Nowhere will you see anything about why these companies set cost reduction targets. Or how they picked the targets they did set. Or whether there were other gains that might have mattered more to customers than cost savings at their supplier.

If a company, say, reduces downtime by 50%, scrap by 75%, overtime pay by 90%, increases inventory turns by 50% to 100%, while improving delivery performance to just about 100%, improves market share, and increases sales per employee by, oh, 5%...do you think anyone gives a damn if costs only went down by 4%?

Why does the survey assume that cost savings are the only benefit that derives from an effective lean implementation?

Do you suppose the CEO's actually know what cost savings can be attributed to their lean initiatives? How could they given all the variables that affect a company's cost structure?

I get just as impatient with articles that claim cost savings. Here's one I found with a quick web search of "lean cost savings" that claims that one company's setup reduction efforts led to a $30,000 savings. Really? Where did those savings come from? Fewer workers? Less scrap? Less overtime? Reduced working capital? The article doesn't say. It does go on to say that the annual savings realized by the company are about $30,000 a year...probably way less than a 5% cost reduction for a $7M company. And who knows if even that is "hard" savings.

Any company that implements lean only for "cost savings" will be disappointed. Not because lean doesn't lead to substantial savings but because most companies don't do a good job of measuring costs and their sources.

But first...another word about metrics

George Bohan — Sun, 09 Oct 2011 01:51:00 GMT

Both long time readers of this blog will know that I address the subject of lean metrics quite a bit in this blog.

I saw, and responded to a post on a LinkedIn group discussion that raised the issue for me again. I'll be darned if I can find the original post or my comment but it went something like this:

Original poster asked how one might go about conducting a kaizen for which leaderships' stated goals are "50% reduction in the number of steps in the process, 50% reduction in travel distance in the process, reduction in WIP." (I forget the target.)

My response: Start by dropping the bullshit targets. (I didn't use that word because I was afraid my comment wouldn't get approved. I don't worry about that here....because I own the damn blog!)

These are bad, wrong, hateful, egregious targets for a kaizen. They are bogus. They are meaningless. They are altogether without worth.

Don't get me wrong....at the end of a successful kaizen, process steps might be reduced by 50%....or 75%....or nothing. And travel distance might be reduced by 50%....or 99.9995%.... or 12%. (Probably not nothing....it's not hard to reduce travel distance unless work stations are already crowded together and usually they aren't.) WIP might be reduced by 50% or .02% or 99.995%. And if the kaizen has an impact on these metrics, the team should say so.

But targets like these expressed this way tells me that management hasn't a clue...not the smallest clue...as to what lean is all about or what the purpose of a kaizen is.

How do they know that 50% is exactly the right amount to reduce travel distance? Did they do an analysis of the travel distance and that's what they came up with? If you believe that, I have a bridge I want you to consider buying. Same with process steps....how do they know the process has exactly twice as many steps as it should? And if the process does, shouldn't somebody have his or her ass tossed out onto the street? Maybe the "leaders" that set the target, thereby admitting that they've been complicit in letting processes have twice as many steps as they need all these years?

If process throughput doubles, manufacturing cycle time through the process is reduced by 33%, process downtime is cut by 80%, scrap is reduced by 25%, setups are reduced by 75% and on time production increases from 33% to 95%...but process steps increase by, say, two steps, will the kaizen have been a failure? According to the poster's company's "enlighted leaders"....yes.

So why am I so verklempt about all this? Because this issue of bogus metrics, especially cost reduction (which I'll address in my next post) is hurting the deployment of lean. I know...that's a bit melodramatic. But if lean/agile methods are tasked with creating benefits that it's not it's not, in particular, designed to create (cost cutting) or that just don't matter (travel distance), companies are going to convince themselves that "it just doesn't work".

It's like telling your marketing department, "If you don't reduce travel distance and cut operating costs, you've failed!"

"Whoa," you're thinking, "Where did this marketing analogy come from? It doesn't make any sense!"

Because lean implementations have more in common with marketing than theuy do with cost accounting. You implement lean, not to reduce costs, but to be able to provide products and service levels to customers that your competitors can't. Your customers don't give a damn what your "travel distances" are or how many steps your processes have. They do care whether or not you're providing them the product you promised when you promised it. So...if you can, through your kaizen:

Reduce the manufacturing cycle time and make it less variable, and
Improve throughput and make it less variable, and
Improve the quality of your product and make that quality less variable, and
Do all this while reducing the amount of material (inventory) needed to do it,

your customers will love you. And they won't give a damn whether your travel distance went down by 50% or doubled.

Progressive Lean: The Overall Idea of It, Part Four

George Bohan — Wed, 05 Oct 2011 11:29:00 GMT

OK, this is the last introductory chapter I promise.

I just wanted to go into a bit of the philosophical underpinnings of Progressive Lean before continuing on. I broached the topic a bit in my last post on advantages and disadvantages and want to develop some of those ideas further.

I tell my clients that all agile and lean boils down to two ideas:

Reducing variability of performance
Improving flow of material and information

In that order...mostly.

Low variability is another way of saying "operating excellence". In other words, operating excellence is a foundation of agility and has to be achieved (or, at least, approached) before you can have good flow. So that's what we work on first....operating excellence.

Now, the road to operating excellence goes through orderliness. There's no other way. So the early steps of Progressive Lean are devoted to creating that orderliness: Sort and Shine in phase two and Straighten and See (visual controls) in phase three.

The road to operating excellence (reduced and controlled variation) also goes through standard work practices for leaders and operators. Standard practice starts with standard conditions...sort and shine and straighten and see.

From another blog re: 5S

George Bohan — Mon, 03 Oct 2011 17:08:24 GMT

A blog I check into fairly often is Evolving Excellence. Too often, they get into "the guv'mint is always bad" political posts (which wouldn't be so bad but they aren't real smart about it...I always call them on it and it's pretty much like shooting fish in a barrel). But they also are tough on big companies that ship work overseas in the futile search for high quality at the cheapest labor dollar, which I like. When they actually address lean issues (too infrequently for a blog devoted to lean, IMHO), they're pretty smart.

Anyway, I found a couple of posts at the blog on 5S. And since we're about to talk a lot about 5S (or some of its components, at least), I figured they'd be worth your look.

Here's the first. The author is obviously not a fan of poorly implemented 5S (as none of us is) and he seems to assume that all 5S is poorly implemented. And, if the video he links to is any indication, he might be right. But keep reading...he makes several good points as the article wends its way along, including the following:

"5S is most importantly the disciplined visual control over each operation within the manufacturing process. It is the tool that enables you to rest assured that the kanban is working. It is the physical manifestation of standardized work. It is the essential support for operator-performed maintenance activities. It enables everyone on the shop floor to know that the machine set-up/changeover process is operable as designed. In short, it is the intersection of all of the process optimization and control aspects of lean."

Well said. 5S (or the components therein) should NOT be implemented simply so that the plant looks better. It's not worth the trouble. 5S is all about visual control of processes: you should be able to tell at a glance whether or not your processes are in control or not. 5S creates the foundation for this condition. Yes, your organization will look better. But that's just a happy by-product.

Here's the other article from the same blog. (You'll think you've been linked to the wrong article but read down a few paragraphs.)

Here's what the author says:

"5S is the systematic integration of all of the facets of manufacturing in the workplace in a manner that assures the best cost, optimum flow, perfact quality and absolute safety."

Again, well said.

5S is the best place to start lean and it pays dividends in and of itself. But, as the author says, looking agile and being agile are two very different things.

Progressive Lean: The Overall Idea of It, Part Three

George Bohan — Mon, 03 Oct 2011 10:28:13 GMT

In my last two posts, I laid some of the foundations for this discussion of Progressive Lean. This time I'm going to talk about what I see as the benefits of Progressive Lean.

The first advantage is that it provides companies with a step-by-step, "here's what you do first, here's what you do after that" approach. Now, I now that sounds kind of like a sales pitch but a problem I've seen with most lean literature and presentations is that they cover a lot of ground but don't do a good job of answering the question, "OK, but how do I get started? What do I do next Monday to get it off the ground? Then what will I do next? And after that?" Progressive Lean answers those questions. It doesn't throw a bunch of Japanese terms at you, then figure you know everything you need to know to be an effective "sensei". (Geez, does that term bug me.)

Further, it starts with basic, comparatively easy methods, then works it's way toward the harder ones. (I say "comparatively" because the culture change required to sustain the deployment of even the most straightforward of the methods will be a challenge.)

Another advantage is that it locks in the gains from each phase before moving on to the next. (That said, as we'll discuss, the phases have flexibility; there's no "We can't get to that problem yet because we're not to that phase," aspect to all this.)

The Progressive Lean approach can be applied in pretty much any manufacturing setting, however large or small, whatever the product. Different tools and methods will be applicable in different setting but the phases that contain them stay pretty much the same. (I haven't tried Progressive Lean in non-manufacturing settings but I'd imagine it would work there as well. I'm just not sure how "pull scheduling" translates.)

The approach is also flexible with respect to the tools that it incorporates. It does lean heavily on 5S, especially at the start, and assumes that visual controls, leader standard work, operator standard work, value stream mapping, and team problem solving will be a part of any implementation. As for Six Sigma, poka yoke, kanban, heijunka, etc., etc., it definitely allows and encourages their use but doesn't require it.

The primary advantage, in my view? It uncovers and addresses culture change challenges early in the process, when the company is working on the simpler methods. If you've attempted to implement agile/lean methods, you know that culture change is the most difficult part of it. If you haven't made the attempt, you'll learn that this is the case. It's far better, in my experience, to be addressing culture change issues while implementing Sort and Shine before you get around to, say, pull systems and cell creation.

Does Progressive Lean have any disadvantages?

Honestly, none in particular that I've run into so far.

A client that was especially eager to use one method or another out of phase ("When are we going to get to do value stream mapping?" "What about this Six Sigma I keep hearing about?") but there's nothing that says you can't do that sort of thing. At a present client, they're doing value stream maps and kaizens at the same time they're doing sort and shine.

Progressive Lean: The Overall Idea of It, Part Two

George Bohan — Mon, 26 Sep 2011 12:58:01 GMT

In my last post, I was laying the groundwork for my reasons for changing my approach to implementing lean.

The rest of the story has to do with a client I had. The client had been implementing lean with another consultant for about a year before I got there. They had conducted about ten "excellence events" and were happy with them but didn't feel that the overall idea of lean was really taking hold across the organization. They learned about Progressive 5S at a conference they went to and decided it would be a good way to get the whole organization working together on lean.

(A bit of backstory: Most of the excellence events...you might call them kaizen events...had focused to one degree or another on 5S. Most of the shop, though, not having experienced an excellence event, was pretty unorganized. Top management had been a bit non-committal to 5S activities, preferring to see hard cost reductions. The company hired a world renowned quality consultant to look at all their operations. At the top of his report: You need to clean up and organize the place if you're serious about quality. Top, middle, and front-line management got really interested in 5S after that.)

So they started rolling out the version of Progressive 5S they had learned at the conference with my help and it worked pretty well.

I spent some time thinking about the flow of Progressive 5S and found that I could broaden it to include all the activities of lean, from planning through sustaining. I came up with the 10S or 5S X 2 rubric (I need to nail down which it is...I kind of like that 5S X2). I've been using it with two other clients and it's working well.

Remember, the approach I'm going to relate to you isn't just focused on 5S. It started as Progressive 5S but my version is Progressive Lean. Progressive 5S only addresses 5S. In Progressive Lean, 5S is integrated into a broader progressive deployment that also includes set up reduction, value stream mapping, cell creation, structured team problem solving, pull systems, and so on.

In my next post, I'll go into some of the advantages I'm finding with Progressive Lean.