Keeping You Informed On Lean Manufacturing
You’ll notice I’ve changed the name of the blog to Lean Manufacturing Update. The reason is shamelessy commercial…I’m hoping it shows up better in web searches. After all, if you were looking for info on “lean manufacturing”, would it occur to you to search on “agile manufacturing”? Exactly.
I still like the term “agile” better than I do “lean”. But I hope I’ll get to say that to more people by changing the name of my blog.
I used to have this blog on the regular Godaddy blog software. They bagged the blogging business, pretty much leaving me in the lurch. So now I’m on WordPress, hosted by Godaddy (I’m still trying to figure it all out). The worst part about it all…I lost all my previous content. Yeah. All of it. I had some good stuff there, too.
I’m not sure if it was my fault for not doing…something, or Godaddy’s fault for not telling me to do something. Or maybe there wasn’t anything that could be done, I forget.
I did this series on how to implement lean, step-by-step, that I was always proud of. It was well received (if the Godaddy site stats were to be believed). I’m going to do it again because, well, again, it’s good material and because I’ve updated my approach.
So, come back here every so often and see what I’ve added.
I was on a sales call a couple of days ago and was reminded, yet again, of the importance of lean measures and operating metrics. (In other words, numbers, data, metrics, charts, yardsticks, measures, what have you that allow a manager or associate to assess the level of performance of an operation or process).
Essentially, the manager was frustrated because his organization had no measures of performance. This meant he couldn’t tell if he had the right resources deployed in the right way or not.
Exactly.
This is why I always start, way back in Leadership Planning, with the development of metrics that will allow the leadership group to determine whether the lean initiative is working or not.
If you’re interested in learning more about operations metrics, do a web search for any of Brian Maskell’s books.
One of the fun parts about lean consulting (as compared with implementing lean for a single employer) is that I get to see a variety of environments and figure out how the lean tools can be applied. A few months ago, a couple of colleagues and I got a state grant to help two school districts implement lean concepts and tools in three of their support services departments: buildings and grounds, transportation (the buses), and, yes, the cafeterias.
I’ve especially enjoyed working with the lunch room ladies. We’re not far down the road but it’s an exciting place to implement lean tools. I visited the lunch rooms during morning prep and production and service to the students. I’m telling you, it’s a faster paced environment than you might suspect.
Here are some of the factors that make the kitchens fun for a lean practitioner:
I could go on.
Right now we’re working to improve the procurement process. Then we’ll be moving on to the production processes. I’ll let you know how it goes.
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:
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.
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.
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.
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.
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.