(Continued from "Lean Journeys - Part 2")

Another year is upon us, and it’s time to look forward to new challenges and frontiers. It has been a while, and I will finally finish my thought on going lean from back in October! (Thanks for bearing with me - please refer back to "Lean Journeys - Part 2" as a refresher).

Bottom line - by proper batch-sizing, the stamping operation went from being a 7 day operation to a 5.5 day operation. This allowed us to concentrate our focus on continuous improvements as far as changeover time, and uptime, without shorting our customers. Of course, by doing the batch sizing optimization, we weren’t lean. We were in a better position to get lean. As we made improvements in changeover, we reduced our min-max levels gradually. We found that that was the optimum way to go, while still supplying our customer (assembly area) with componenets.

There was resistance in expanding the batch sizes, as this was counterintuitive to lean thinking. It was a little bit of a struggle to show how this short term "hit" could be the means to the end (of being leaner). I really tried to show how important it was to keep the customer supplied in the short-term, while making improvements to help the long term.

Best of luck to everyone. Have a safe and prosperous 2007!

(Continued from "Lean Journeys - Part 1")

There were two departments in the plant, and the press area served both with most of their raw material. After about two weeks on the job, I found that my area was shutting down one assembly cell per day on average. As you could imagine, my stress level was getting very high in a short time. I started making daily schedules of what I wanted to run and when I wanted to run it. I tried scheduling by piece count and by run time, but nothing I did worked. I knew that I had considerable downtime, and my changeover times were considerable, but I was in a constant state of firefighting for weeks.

After consulting many references, I started to take a six-sigma approach to the dilemma. What were the inputs? Obviously changeover time was an input. Running downtime was another....but what was the "Y" here? I initially went with assembly stock-outs per day, since if I could keep the plant running, I could buy time to make the press area more efficient.

First, I had to figure out what my average customer demand was (takt time), and weather the demand was leveled. Leveling of demand is very important, since this makes the production signals of a pull system stable and predictable. As it turned out, my highest demand product was shipped as an assembly in one week quantities to Europe by boat with a two-week lead time....not good, but I considered it system noise since there was no way to immediately control that factor. Luckily, the weekly demand for the product was stable.

As it turned out, taking a hard look at the operations, I found both good news and bad news.

The good news:

I had more capacity than I thought…on average I could run more pieces than my demand required.

The bad news:

1) My changeover times were astronomical.
2) My unplanned downtime was also too high.

What was happening was that the min-max levels for the pull systems were so low, that the average press was almost spending more time changing over than actually running parts! This was causing sheer chaos in the operation.

The improvement plan consisted of:

1) Re-setting min-max levels to reflect operations characteristics (aka “Take the initial hit”).
2) Improve changeover times/reduce unplanned downtime using conventional problem solving.
3) Lower min-max levels to the improved operations characteristics.
4) Repeat the problem-solving process.

My next blog will discuss the before and after results of the activity, and will also discuss some of the conventional stumbling blocks for “going lean”.

Please take a look at the following as they are really excellent references:

Kaizen for Quick Changeover: Going Beyond Smed by Kenichi Sekine, Keisuke Arai, and Bruce Talbot

Factory Physics Second Edition by Wallace Hopp and Mark Spearman

Deciding to go lean is very popular in today’s business climate. Eliminating overproduction and reducing excessive inventory (along with waste) is a must. If you’re a black-belt, you’re role may be central to the lean transformation (depending on the organization). Although there are many benefits to leaning-out operations, especially in a batch processing operation, there are also many growing pains that go with it. The important question to ask is weather or not your operation is ready for them.

Today I have been thinking about some of my past experiences with lean implementation. I will always remember my first day on the job as an operations supervisor in a stamping shop. Since I only worked in an MRP (scheduled) environment before that, I was impressed at the kanban areas and the visual min-max levels. I remember being somewhat perplexed that day though. The problem was that all of the kanban areas were empty! I remember thinking that I could schedule my way out of the issue without any problems. I was absolutely wrong, and the following months proved to be some of the most challenging yet rewarding in my career. Check back in a couple of days as I continue with this story, but for now, what are some of your experiences in implementing "lean"? Please feel free to share them!

Lean Journeys – Part 2

One of the toughest challenges that a manufacturing black-belt faces is institutionalizing data collection systems that yield project-critical information. Whether the needed data is attribute or variable, it is still a tough challenge to implement the system. Once the GR&R issues are resolved, it doesn’t get any easier. At this point, the black-belt has to “make it happen” on the floor. Many of us have been there, standing on the line for hours training the personnel on the proper measurement procedures required.

If you are an integrated black-belt, you have even less time to dedicate to the system implementation, yet the need for the system still exists. I’ve found that in this case, it helps to obtain maximum leverage from resources at your disposal.

Some of the best sources of leverage are the front-line data collectors. These people are typically team leaders or production team members that actually make the products on the shop floor. They have a wealth of practical knowledge of the production process, and are, in most cases, willing to help improve the process in any way possible. However, I’ve seen cases where data collection sheets are pushed onto the data collectors, without any input from them, without giving them any insight as to where the data is going, or how it will be used. Naturally, the response from the data collector is less than enthusiastic, and since the system depends heavily on him/her, the system is likely to fail.

Here are some ways that I’ve found to leverage these very important team members to ensure data collection success:

1) Involve the people that build the product at the very start of your implementation. In this way, they are involved and realize why the need for the data is important. Remember, physically taking the data can be more of a burden to them, so it is absolutely important that they realize how important it really is.

2) Give the team members a chance to make the data collection system successful before going to their supervisor. It may be very tempting when activities seem to stall to go to the supervisor for support. Support the team members, and they will support you in most cases. Of course, there will be cases where you will need supervision to help.

3) Let the team member collecting the data be a part of the data “report-out”. Eventually, the data has to be reported on or used in an analysis. Giving the team member the opportunity to see how it is used and analyzed is a learning opportunity for him/her, and will also give a feeling of being a part of the business.

I’d really like to hear how your organizations’ have handled data collection at the front-line. I look forward to hearing about your experiences.

To a black-belt, looking at problems from a SIPOC point of view comes naturally...creating process flow maps, identifying potential inputs, identifying internal and external customers, etc. These activities are (or should be) core to implementing a given black-belt project. To an engineer that has not been though six-sigma training, many times these processes are not explicitly followed, but rather the inputs are assumed in some way. These inputs could be assumed based on experience, process knowledge, or even only by what data is available. To the integrated black-belt, these assumptions can lead to frustration when interfacing with an engineering problem-solving team.

In order to bring the team together, its important for the integrated black-belt to let his/her leadership get the team past these assumptions. One way to do this is to challenge the assumptions brought forth by team forcefully, yet eloquently.

A typical conversation between a product engineer and an IBB (integrated black-belt in manufacturing) may start like this:

Product Engineer: The design allows a +/-1 mm deviation from nominal and currently the widgets are out of tolerance we all know that this is causing the problem with the final widget assemblies.

How the IBB responds to this concern is dependent on the circumstances, however there are two basic ways: immediately defensive or immediately inquisitive. A defensive reaction in this case almost always builds a wall between team members, and gives the impression that you're not a team player. However, this reaction is natural, since as an IBB, you immediately question weather or not your product development colleague has considered the pertinent inputs to the problem.

Ive found that the inquisitive approach almost always yields better results. Your colleague may be absolutely right. Build a mutual trust with your colleague based on the fact that you will investigate the issue from the process side and give an update at the next meeting. Before then, perform your analysis if solid data is available using the appropriate tools (tolerance stack-up analysis, ANOVA, etc) to isolate the potential causes and bring those to the table. If solid data is not available (poor R&R, etc), then bring that fact to the table. In either case, take the time to illustrate the methods you used to draw the conclusion(s). This will allow the whole team to learn new methods of root cause identification.

And above all else, if your colleagues statement is correct, then begin activities to improve the process as soon as possible without delay. This will build even more trust and the beginning of a good working relationship with your colleague.

I'd like to hear about some of your experiences with IBBs and how the interface works with the non-trained population. Please share your thoughts.

Kosta Chingas began his career with Ford Motor Company in production supervision. In May 2000, he joined the first wave of black-belt candidates at his facility. He became a certified black-belt by Ford in September, 2001. In 2002, he joined BorgWarner automotive as press area operations supervisor where he optimized kanban min-max levels and introduced team-leaders into the press area. In 2003, he returned to Ford and was selected to become the facility master black-belt, coaching the facility black-belts and delivering green-belt training to roughly 200 total hourly employees. He also co-delivered one of the first waves of manufacturing black-belt training in the Chicago area for regional candidates.

In 2005, Kosta joined DaimlerChrysler as a dimensional control engineer for Mercedes-Benz US International, where he is responsible for the dimensional control process of the M and GL-Class underbody assemblies.

Kosta obtained a B.S. Mechanical Engineering degree from Northern Illinois University in December, 1999.