One Man’s Lean Journey: Process and Data Don’t Matter…Just Emotions!

Following a structured problem solving approach takes fortitude and courage when the world around you wants to shoot from the hip and judge based on their emotions. I found this out when dealing with one of the automakers we supplied.

Our quality engineer (QE) got a call that our grilles were not fitting the front of the cars correctly and asked her to take a look into it. The QE asked me to help find the root cause. We first tested our gages at our facility and found they were certified and working properly. Our parts showed to be within the tolerances given to us by the automaker.

We decided a trip to the automaker was needed to see the process, talk with the operators and also run a couple of tests. The QE and I asked the automaker’s QE to pull two vehicles off the lot and save for us to test. One vehicle is a great example of how the part should fit and one vehicle where the part fits very poorly.

When we arrived at the assembly facility the first thing the QE and I did was go out to the assembly line and talk with the operators that assemble our grilles the the vehicles. The operators said our grille may not fit the first vehicle but would work great on the next one down the line. This was a big clue. Direct observation of the process was a huge help in understanding how our grilles were assembled to the cars. We ended up knowing the process better than the automaker’s QE.

Next we asked to see the two vehicles we requested to be set aside. Well, he only saved the bad vehicle and not the good one. This became a point of contention because we needed a good car to compare the differences and conduct a test. He argued with me for 10 minutes before I finally convinced him to pull one in from the lot outside.

I conducted my test and proved with a 95% confidence level that our grille was not root cause of the fit issues. There were two possible causes: 1) the fender or 2) the fender’s interaction with our grille (the fender on one end of their specs mixed with a grille on the opposite end of our specs could cause the fit issues).

This was not received well at all. The automaker’s QE contested everything I did and wouldn’t believe the findings even though he watched me during the entire test. It took a second automaker QE to come over and see what was going on to get any agreement. The second automaker QE heard about the test and backed up my findings.

I even volunteered my help to conduct more tests to find the root cause. They agreed to the help and both the automaker and the QE from my company had action items to complete in the next two weeks in order to do further testing.

As we followed up with the automaker’s QE over the next couple of weeks, we found he was not living up to his end of the action items and was still trying to blame our grille. The QE and I had to escalate the issue to our plant manager who supported us and called their plant manager.

A compromise was reached. The test was conducted as I laid out but I was not allowed back into their facility. In the end, it was the fender that had issues.

It was hard to stick to the process when every obstacle was being thrown in the way. It taught me a valuable lesson about how strong emotions on a subject can be even with data and facts presented.

Reflections:

• A strong process is an amazing thing to be able to fall back on in times of stress. It showed exactly why people fall back into old habits when things aren’t going well.
• The right thing isn’t always the easy thing. It can be hard to standup for the right thing even when it is good for your customer.
• Having a leadership team that supports and encourages strong processes is critical when those processes are challenged
• Solidified my belief in the power of a strong process to get predictable and sustainable results
• Direct observation of the grille being assembled provided strong facts that no one that hasn’t seen the process could argue

Advertisement

Root Cause vs. Containment

A typical response to problem solving is to contain the issue and consider getting to the root cause.  From my experience, this is because people don’t know the difference between root cause and containment.

It can be easier to see in a tangible manufacturing environment.

Problem: A group of products have a broken screw that will cause the product to fail

Containment: Sort all product to find the ones with the broken screws and replace the screws.

Root Cause: Find why the screws were broken in the first place.  Were the screws torqued too much?  Weak screws?

Most people understand the difference when an example like the one above occurs.  But in a business environment, people seem to miss this difference.

Problem: The numbers on paper say the budget is $10 million, but the manager says the budget is $6 million.

Containment: Get an answer to which budget is correct.  $6 million or $10 million?

Root Cause: What caused there to be a discrepancy between the numbers on paper and what is being said?

I see a lot of answers around poor communication or people getting the containment answer and believing they got to the root cause.  We should be finding a root cause to why there was a discrepancy so there isn’t another one in the future that causes delay in the process.

Just because you are able to move the process forward, does not mean you got the root cause.  Take the time and find the root cause.  It may take more time now, but it will save a lot of time in the future.

Balance Process and Results

In the lean world we always stress how important a good process is to achieving results.  One of my favorite graphics I have seen is the one pictured below.  It shows the four outcomes of balancing process and results.

• Having a Good Process and Getting Good Results is the gold star.  We know we have a solid process that will give us the good results we want.
• Having a Good Process and Getting Bad Results is half way there.  We know the process works like it should.  It just doesn’t give us the results we want so we need to go back and redesign the process.
• Having a Bad Process and Getting Good Results you are gambling.  You got lucky to get the good results and it won’t be consistently repeatable.
• Having a Bad Process and Getting Bad Results is just not good.  Nothing is working and you should start working on this right away.

I am one of the first to stress process, but as you can see it must be balanced.

When designing a process it must have the right mix of structure and flexibility because it is about understanding, learning and getting the results.

For example, when designing a manufacturing process you may be more prescriptive because of the need to get a particular assembly done correctly.

For a process around coaching or problem solving, there needs to be more flexibility.  A determined process should be designed and used but it shouldn’t be as prescriptive as a manufacturing process.  It allows for the person to be able to go where the problem is taking them but achieving the desired results is still extremely important.

The need to balance the importance of a good process and the getting good results is a key skill to have when teaching people about lean.

Veteran’s Affairs (VA) Designed to Add Waste

Sometimes you just wonder if people design processes in order to create waste.  Like it is a hobby and creating all the waste is just fun for them.

People I am close with recently had a death in the family.  He was a veteran with illnesses from handling Agent Orange in Vietnam.  He passed at the VA hospital.

The family believes the unexpected complications that lead to his passing are related to his illness from handling the Agent Orange.  The VA hospital asked the family if they would like to request an investigation and the family did.

After close to 6 months, the family receives a letter stating the investigation is complete.  If the family would like to see the results they need to submit a request for the results.  Really?!  How many people do you know that request an investigation into anything and don’t want to know the results?  So the VA wants to create more paperwork and processing to send something the family requested months earlier.  Again, the family originally requested it.  Why wouldn’t the VA just send the results?

As ridiculous as that sounds, that isn’t the biggest waste of this ordeal.  A week later the family receives a letter stating they will receive the results via the mail within 2 weeks.  What?!  Why wouldn’t the VA just send the results?  They have already set the expectation that it won’t happen quickly because the investigation didn’t.

Someone has a job that is sending letters saying the information is being sent.

I don’t know where to even begin with this.  The family has been through enough.  The VA should be making things easy on the family and not more frustrating.

Quick simple solution.  When the family requests an investigation have the results sent directly to them after the results have been finalized.  No requests for sending the results.  No letter saying the results are in the mail.  Just send it.

When you hear of something like this, you really have to wonder if anyone is paying attention to this process and how it got designed so poorly.

Process Work Changes People’s Thinking

I am still amazed at what can be accomplished by improving the process first and then looking at how technology can support the process.  I have always been a big advocate of looking at process first.  Yet, still today I see great cases of studying the process first and then implementing supporting technology.  In most cases, the technology needed to support the process is simpler than the original technology plans.

The rewarding part of the work is having success in an area that was hesitant to have the process work done.  An area claiming just to need the technology.  After completing the process work and seeing the benefits, that same area starts to ask for more process work to be done.  That is a great feeling.

Another benefit of getting people to see the benefit of doing the process work first is they start to ask more questions around the end-to-end process.  People start to see the entire process and the affects a change has in one area can have on another area.  The end-to-end discussion becomes easier for people to have.

This shift in mentality can start to break down work silos and get more people engaged in the entire process.

Are you doing end-to-end process improvement at your company?  Is it starting to change people’s perspective?

Guest Post: A Few Thoughts on Policy Deployment

This week is Lean series week at Beyond Lean.  The blog posts will center around strategy deployment (or Hoshin Kanri).  Justin Tomac, Chad Walters, Karen Wilhelm and Tony Ferraro will be guest blogging.  This will give you different perspectives from on strategy deployment all right here at Beyond Lean.

Today’s post is from Justin Tomac.  Justin and I have worked together for the last five years.  My knowledge of strategy deployment has really grown since I have worked with him.  Justin Tomac has been a Lean practitioner a year or two shy of two decades.  His Lean background consists of various deployments with hands-on office, engineering and shop floor transformations with mentoring and training being provided by TBM and Shingijutsu consultants.  A GE certified Six Sigma Black Belt, he has an Industrial Engineering degree from South Dakota School of Mines & Technology and an Engineering Management masters from Wichita State University.  If you would like to contact Justin he may be reached at justintomac@yahoo.com

A lot of articles and books have been written about Policy Deployment, with the focus primarily on the high level concept with exhaustive studies on implementation.  Most of us understand conceptually what Policy Deployment is, where it appears to break down is during the implementation and sustainment.  As you may know, sustainment is a key indicator of how well a concept is understood and implemented by an organization.

Below are a few key characteristics of what a Sustained Policy Deployment look like:

1)      Organic and Living.  Policy Deployment should not be a one and done planning and execution exercise.  Monthly reviews with Quarterly or Semi-Annual Adjustments highlight an active Policy Deployment. The health of these Reviews or Adjustments can be determined by How meaningful the actions and results are.

2)      Influences the Behavior and the Culture.  A robust Policy Deployment process exists to solve the various issues related to horizontal and vertical alignment of objectives, goals and priorities for a Company, Division or Department.  What the boss measures and deems important only lasts as long as the Culture allows.  Organizations that struggle with accountability, communicating (vertically and/or horizontally) strategies or tactics, simplification, etc., have Cultural issues.  I heard a saying, “Culture eats Strategy for Breakfast”, why not flip this and make Culture the main dish for the morning meal?

3)      A flexible, structured Process (not a fill-in the blank exercise).  I find it interesting that when Policy Deployment is brought up, out fly the different templates, forms, etc.  In the end, does the form or template set the Strategies or drive the priorities?  Policy Deployment should be a process that examines the business top down and sideways, irregardless of what form or template is used.  In the long run, it is what your Culture will allow or likes that will dictate what your Policy Deployment looks like.

Based upon your experiences would you agree and/or add to these?  What say you?

Process Before Technology

Before I start, technology is a wonderful thing.  It has helped to make processes more efficient and work to be done much easier.

With that being said, before technology is used or put into place, the processes that technology will support should be examined.  Take the time to create a value stream map or a process map and examine the process for waste.  Design the future state of the process.  Then define what are the changes where technology is not needed and what changes where technology is needed.

The technology should be designed to support the process.  Not the process designed to support the technology.  This is an issue that occurs quite often.

Improving the process first creates a better understanding what is truly needed from the technology.  A company can save a lot of money by improving the process first because technology may not be needed at all or fewer components may be needed than originally thought.  Also, if your put technology into a bad process all you have done is make a bad process go faster.  That means you are throwing away money faster than you before because of the waste in the process.

The key to remember is the technology should support the process.  We shouldn’t be putting in technology as a substitute to better the process.

Technology is here to stay.  We should use it to our advantage, but we should use it correctly to support our processes, not to define them.

Flip Conventional Wisdom on Business Process Rework

When applying lean to business processes, one of the most common improvements that has to be made is the elimination of errors in paperwork.  When it comes to design this usually shows itself as someone changing their mind and making changes in the design.  When someone makes changes to the design this is a form of rework.  Anytime rework is added the lead time is lengthened.

Sometimes the redesign is due to change of direction and sometimes it is due to the designer tweaking the design hoping for perfection.  One way to eliminate this waste is to shorten the lead time of the original process before the rework loop is added.  I know this is flipping conventional wisdom upside down.  Conventional wisdom says, eliminate the rework and the lead time will become shorter.  Why not shorten the original process through solid lean practices and waste elimination so that the window for design changes is shorter.  Take away the extra time that gives the designer to fiddle with the product or service.  It also causes the designer to due their due diligence up front to understand what the design must entail.  If the organization is trying to win new business or get a new product to market all the rework could cause the organization to lose the revenue from the new business or product hitting the market.

I’m not saying don’t allow rework for the sake of not allowing rework.  But look at why you have rework.  Is the original process so long that it allows people continue to think and nit-pick every detail?  If so, that may be a good time to look at eliminating waste from the original process.

I worked with a procurement group that had a very long process to go out and get quotes for marketing material.  Because the process was so long, the designers and marketers would come back up to 4 times with changes to the material and then the quoting process would have to start again.  The procurement group shortened their lead time for the quoting process and all of a sudden the marketing and design groups couldn’t come back for multiple changes.  This forced marketing and design to improve their process in order to better understand what markets they wanted to hit up front.

Some times you have to flip conventional wisdom on its ear to see things in a new way.  Even for the lean thinkers.  Our thoughts may be different then conventional wisdom but it is still very standard within our community.  We can’t forget to continue to look at things differently.