Category: Uncategorized

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.

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.

 

 

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.

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.

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!