Author: Rick Bohan

Posted on

Lean Manufacturing Principles: The System is Perfectly Designed to Get the Results it Gets

I used to work for a large steel producer. It happens that the large steel producer would lose coils of steel that it had made for customers.  Now, I lose my keys once in awhile but I coil of steel is seven feet tall and weighs several tons.  How do you lose something that big?

Here’s how it happens:  a coil of steel gets produced and needs to be moved out into the steel yard.  It’s supposed to go into a specific bay so it can be retrieved again later.  But when the material handler gets there, another steel coil is in the bay.  Now the material handler has a problem:  does she take the offending coil out of the bay and put the right one in?  Does she just drop the new coil into another bay?  Does she take it back to the supervisor and tell him that there’s already a damn coil in the damn bay he told her to take this one to?  The choice with the mildest short term consequences is to drop the coil in another bay and make a mental note to correct the problem later.  But she forgets and by the time someone else comes to retrieve that coil…it’s lost.

I contend that this happens because the system is designed so that it happens.  You might think, “Wait a minute!  Nobody sat down and designed the process explicitly so that coils of steel would get lost!”  Maybe not.  But nor did anyone sit down and design a system that explicitly prevented coils of steel from getting lost.  So, the system was designed to allow coils of steel to get lost.

This principle has several corollaries:

  • If you’re  don’t like the results, look first at the system.
  • If you don’t like the results, it’s not the people, it’s the system.  And if it does turn out to be the people, look at the systems for hiring, training, and performance feedback.
  • If you don’t like the results, change the system.

Too often, lean methods are implemented as if the system was OK but the people just needed a little help doing things differently (shadowboards are a great example of this).  The bedrock of lean is a system of production that’s very different from the one you probably have now.

Posted on

What the heck is a “standard rate” and what’s it good for?

I got into one of those not infrequent “lean discussions” recently that focused on “standards”.  Now, the first thing that anyone discussing standards needs to do is to define terms.  I’ve found that, when using the term, some folks mean “standard practice” or “standard operating procedure”, as in, “It may or may not be documented, but it’s the way we’re supposed to be doing it.”  Other folks mean about the same thing but it’s not “standard” unless it’s documented.  Other folks will be using the term to mean “standard or target performance at a task or function” as in “The standard for this part on this machine is 150 pieces per minute.”  I’m going to focus on that use of the  term “standard”.

This discussion started as most do…why can’t our operators just produce to “standard”?  Often in these discussions, I find that managers actually are most pleased when operators perform at better than standard but they learn that they dare not wish for that.  Just as often, these discussion involve some disparaging of such standards as exist:  “They’re all wrong.”

My position is that, for the reasons alluded to above, standards in most manufacturing operations are almost (almost, mind you) meaningless.  I’ve seen standards that were never met, ever, while other products or parts had standards that were exceeded by several hundred percent. (It’s always struck me as odd that a part that runs regularly at “850% of standard” doesn’t seem to generate much discussion.  I guess managers figure they’re making money on that part, so why fuss about it?  My response is that, if that standard is that far off, why would we assume that any of our other standards are correct?)  I’ve seen too many situations where meeting the standard was seen as solely the operator’s responsibility.  In some of these cases,  a list of operators and the average rate they ran each day was posted.   Jim ran at 55% yesterday so Jim didn’t perform well.  Andy ran at 105% so he ran very well.  But the report doesn’t tell you that Jim fought bad material  or bad tooling all day and Andy ran for only three hours at that rate, after which his machine went down.

Too often, the process for setting standards is faulty and the process for assessing and updating standards is often missing altogether.  (I one heard a story about a standard being set by an engineer’s off-hand guess at what the production rate for a new part should be.  And that remained the standard for years.)  So, supervisors and operators alike tend to ignore them for the most part.

I’ve sometimes, just to be provocative, argued that most manufacturers could just toss all their standards out and be as well off.  I’m not actually sure that’s the case, mind you, it’s just that I don’t see many examples of manufacturers being helped by their out-of-date standards.  Even if standards were updated, it might only further encourage the “let’s blame the operator” approach.

So, what, if anything, are standards good for?  To my way of thinking, they’re helpful in establishing a schedule and that’s about it.  If I need 1000 widgets and the “standard rate” is 100 per hour, I know I need to schedule ten hours (or so) to make those widgets.  If we “run at rate”, I know we’ll stay on schedule.  If not, I know we’ll fall behind and I’ll need to be modifying the schedule.  And I can do this even if we typically run below rate by a good bit so long as we run at a consistent rate.

 

 

Posted on

Lean Manufacturing Principles: Consistent is Better than Fast

Since the beginning of the Industrial Revolution, manufacturers have had a devotion to, not to say an obsession with, efficiency and speed.  Everyone talks about efficiency, for example.  I hear folks who couldn’t define efficiency on a dare speaking of its virtues.  I hear references to the need for more efficiency in situations and circumstances where efficiency would be difficult and maybe impossible to quantify, e.g., physical therapy and product design.  Even in those situations where efficiency as a concept and a metric makes sense, it’s used incorrectly as often as not.  And all this is apart from the fact that much of what managers do to promote and improve efficiency actually hinders it.  But that’s another discussion.

I’d rather that managers talked more about consistency and predictability.  Let me give an example:  let’s say it takes me an average five hours to complete a product changeover on a particular piece of equipment.  The longest it ever takes me is five hours and 15 minutes and the quickest I ever get it done is four hours and 45 minutes.  On the other hand, your average changeover time is four hours and sometimes you get it down in two hours but other times it can take you up to eight hours.  Who would you rather have doing your changeovers?  Who is going to make it easier to establish and meet a production schedule?  I’m am, of course, even though I might not be as fast or as “efficient” in some cases.

We can play this same scenario out with any operating factor or metric: scrap, cycle times, errors, delays, uptime.  My view is: better mediocre and consistent than highly variable.

Now I know what you’re thinking:  “But shouldn’t we always be striving for excellence rather than just consistent mediocrity?”  The answer is: “Of course!”  But consistency is fundamental to excellence.  Again, if I can be consistent at less than excellent performance, that’s a step forward from highly variable performance that is only occasionally excellent.  Further, the steps I take to get more consistent will also help me achieve excellence.  The path to eventual excellence goes right through consistency.

Posted on

Lean Manufacturing Principles: No “Manufacturing Heroics”

Over the next few weeks, I’m going to be going over what I consider to be some of the fundamental principles of agile thinking and practice.  Every approach, every model has to have a set of principles on which it’s founded.  To take a really big example, all the laws in the US are built on the principle that all people are created equal and are entitled to equal protection under those laws.

My agile principles won’t be quite as meaningful but you get the idea, I hope.

So, let’s get started.

A few years ago, I was visiting a plant in Kankakee, IL.  I was talking with one of the operators who was giving me chapter and verse of the problems he ran into in trying to produce a quality product efficiently.  Bad material, bad schedules, bad information, bad tooling, bad equipment and on and on.  He concluded by saying, “But, in spite of all that, I get it done.”

In his own eyes, and I’m sure in the eyes of his managers, he was a “manufacturing hero”.  He fulfilled the mission, met the goals, captured the hill in the face of nearly insurmountable obstacles.  But it occurred to me at that moment that his “heroism” was a significant part of the problem.  The company, and certainly the customers of the company, would have been much better off if that operator and his associates at the plant told management, “I’m not running this bad material.  I’m not operating this faulty equipment with it’s inadequate tooling. And I’m not running this ad hoc, reactive schedule you keep handing me.”  Better yet, of course, would be a management team that held inviolable the principle that operators never have to “just get it done”, that they always have adequate, capable materials, tools, equipment, supplies, and information to do their jobs.

I’ve seen “manufacturing heroics” played out in other ways in other organizations.  The supervisor who grabs a wrench and pushes everyone aside to fix a die or a machine that’s not running right.  The managers who spent time each day in long meetings developing operating schedules. Hours of overtime expended because the ship dates had to be met.

I know, I know…there are times when any manufacturing operation has to resort to these tactics.  The question is, are these tactics the norm, as they clearly were in the Kankakee plant?  If the operations are continually dependent on “manufacturing heroics” to get product out the back door, something is clearly wrong.

Agile concepts and tools are designed to get rid of these heroic actions.  But the first step is to quit holding them up as the sort of behavior that’s expected or desired.

 

Posted on

Agile Manufacturing Update…Starting Over

If you’ve been here before, you might be surprised about the “starting over” phrase.  As I’ve mentioned, GoDaddy quit offering a blog platform and tossed me over here to WordPress.  (Hosted and managed, kind of, I think, by GoDaddy.  Go figure.)  I finally got it to work with the same URL that the old blog worked with, i.e., agileviews.chagrinriverconsulting.com (took three or four calls), so I hope the four or five folks who used to come here are still able to do so.

Here’s the thing…all those years of previous posts?  They’re gone.  Yep, gone forever into the internet twilight zone. So I pretty much need to start over.  But I’m not going to…start all over.  I mean, I’m not going to have you reading the same stuff that I wrote back then.

It’s just that I’ve changed some things about my approach to implementing an agile enterprise initiative that I’d like to review with you.  And, I’d like to revisit some of the ideas I presented along the way over the past few years.

So, keep coming back.  More good stuff to come.

Posted on

Value of Value Stream Maps: Take Two

A few days ago, I wrote about the use (or non-use) of value stream maps and, upon re-reading that post, I’m thinking I might have been a bit tough on value stream map users.  Don’t get me wrong…I do see many VSM’s that aren’t being put to use.  But perhaps I put a bit much blame into my message.

Here’s the thing…making good use of a value stream map takes lots of work.  And most of that work is discussion and data gathering.  I recently facilitated a series of meetings with one client’s leadership team wherein we updated old current state and future state value stream maps.  In other words, the maps were there, we just had to make any adjustments and modifications.  The meetings took place over several months.  It would have been easy for the leadership team to say, “This is just taking too long and it’s tough to see the end point.   Let’s move on to something more ‘productive’.”

As it happened, the work on updating the VSM actually raised energy within the team.  They’ve promulgated a series of initiatives and my problem now is making sure the leaders don’t spread themselves too thin….they all want to participate in all the initiatives.

My point is that it’s not so very hard to make a value stream map.  Heck, as I mentioned in the previous post, you can get your lean consultant to put one together for you and it will be pretty good.  The hard part (and it is hard) is the hours of discussion and deliberation needed to turn the map into action.

Posted on

The Value of Value Stream Mapping

A number of places I’ve been to have a value stream map hanging somewhere already.  Often the map has been hanging there for a good while…several years in some cases. Now, I’m a big fan of VSM’s, so I wonder how so many get made up but so few get put to use.  I’ll often ask about the map and generally get a vague answer about “not getting around to doing anything with it”.

I think there are several reasons why this happens.  First, I think at least a few of those maps were developed by a consultant or, maybe, the local “resident expert” and handed to the client.  And, so…no buy in.  The folks who are managing the value stream have to participate in developing the map.  In my experience, the development of a VSM is “labor intensive” and takes lots of consideration and discussion.  This discussion leads to insights and ideas about improvements to the value stream that can’t be obtained any other way.

Second, whether the VSM was developed by an “expert” or by the management team, there isn’t enough discussion of the transition plan:  How are we going to get from the value stream we have to the value stream we want?  Again, this takes a good deal of discussion.

Third, there’s often a lack of follow through.  The changes that might be portrayed on a future state VSM just don’t get implemented.

The value of the value stream map, then, isn’t so much the map itself as it is the process for getting it.  The discussions that take place to develop the maps (current state and future state) and to develop the transition plan provides the energy and impetus to get things done.

 

Posted on

What the hell? Where am I? And what did they do with Agile Manufacturing Update?

That’s what you’re thinking, right?

Well, here’s the quick story: GoDaddy, the host of the blog, got out of the blog hosting business.  So, I’ve had to come here to WordPress (which, ironically, I set up through and is hosted by…GoDaddy).

It’s taken me not a few calls to GoDaddy to make the switch.  Keeping the same URL was especially important.  I’ll be making changes and tweaks over the next few weeks to get things just the way I want them but at least you’ll get here by clicking the same link you always did.

There’s a big, bad downside to all this…all those great posts over the last six years or so?  They’re gone.  Yep, deleted, gone, disappeared.  Sleeping with the fishes.  I know…I’m pretty upset about it, too, but…what’re ya gonna do, right?

So…keep coming back.  More great stuff to come.

Posted on

Agile Manufacturing Update is all new!

OK, Godaddy got out of the business of hosting blogs, so I’ve got this WordPress site now.  It’ll take a bit of work to get it fully up and running but you can expect the same high-toned posts as always.  More later!