Manufacturing Breakthrough Blog

Using Run Charts to Understand Process Performance Over Time

Thursday April 2, 2015

The Run Chart

In my last posting I mentioned another very valuable tool in the Six Sigma tool kit, the Run Chart. I told you that like the other tools we’ve discussed so far, the Run Chart is also a very useful tool for solving problems. The real usefulness of the Run Chart is that it serves multiple purposes in your problem solving efforts. As you will see shortly, not only does the Run Chart allow you to monitor your processes as a function of time, but it also serves as a tool to determine when the problem you are working on actually started. The most effective way to present this tool is via a true case study I led while I was a VP of Engineering and Continuous Improvement for a manufacturing company that fabricated truck bodies. But first, a discussion on the basics of the Run Chart.

Background

The real purpose of a Run Chart is to display the performance of a process over time. It can be used to display upward and downward trends, repeating cycles, and large deviations that need further investigation. In a Run Chart, what you are measuring is displayed on the y-axis and is graphed against a time period on the x-axis. For example, a Run Chart in a manufacturing plant might show that production falls as a function of the time of day or day of the week or month of the year. By knowing this, you have a starting point for improvement. That is, by seeing the production shortfall as a function of time, the Run Chart provides the “when” of the problem and therefore allows you to look for “things” that might be causing production to decrease. Run Charts can also be used to track improvements that have been put into place to determine if the improvements have made a difference. Let’s look at an example.

An Example

This example involves a company I worked for that had been manufacturing truck bodies for the transportation industry since 1958 and had been one of the recognized industry leaders. The company had a staff of 17 full time engineers and engineering performance was measured by the number of hours of backlog waiting to pass through engineering. I had been hired in as the VP of Quality and Continuous Improvement because the company was losing market share and delivery dates were being missed. In addition, morale within engineering was apparently at an all-time low. Upon arriving at this company, I was informed that I would also have responsibility for engineering. Because of the poor performance in engineering, the company had fired their VP of Engineering and I was the “lucky” recipient of this group. Apparently the backlog of quotes had risen from a norm of 300 hours to approximately 1400 hours just in the previous two months.

After mapping the truck body process to better understand what was happening, I was in search of the constraint or that part of the process that was limiting throughput. It was clear immediately that the constraint was the order entry system. The process to receive a request for a quote and return it to the customer was consuming an amazing 40 days! And since it only took two weeks to produce and mount the truck body, it was clear to me why market share was declining. The response time for receiving the request for quote was slowing the process down and therefore making orders late.

My next step was to develop a Run Chart to get some history of what was happening within this process. The figure below represents the number of backlog hours from February 1999 through April 2000. The data confused me because I first observed a steady decline in backlog hours beginning in May of 1999 through October 1999 and then a linear increase from November 1999 through April of 2000. My investigation revealed that the decline was associated with mandatory engineering overtime and the ascent occurred when the overtime was canceled. The engineering VP hadn’t defined and solved the problem, he had just treated the symptoms with overtime.

RunChart1

My next step was to create another Run Chart going back further in time. If I was going to solve this problem, I needed to find out when this problem actually started. The figure below is the second Run Chart I created and it was clear that this backlog problem was a relatively recent change, so the key to solving it was to determine what had changed.

Somewhere around January of 1999, the then VP of Engineering had decided to move on to position outside the company. His replacement apparently didn’t like the way the engineering group was arranged. The company produced three basic types of truck bodies and historically had three different groups of engineers to support each type. These groups were staffed based upon the ratio of each type of truck body produced. Between June of 1996 and December 1998 the company had maintained a very stable level of backlog hours. The new VP of Engineering consolidated the three groups into a single group and almost immediately the backlog grew exponentially. The company fired him in May 1999 and hired the new VP that used overtime to bring the backlog hours down. Part of the problem was the performance metric, efficiency, in place which caused abnormal and unacceptable behaviors.

RunChart2

For me, when I came on board, the fix was clear. Return to the previous engineering configuration, identify the system constraint, focus on it and drive out waste and variation, to drive the backlog hours lower. The results were swift and amazing in that the backlog decreased from 1200 hours to 131 hours in 5 weeks and remained within an acceptable maintenance level after that.

In fact, because we also eliminated much of the waste within this process the time required to process orders through engineering decreased from 40 days to an astounding 48 hours! The figure below represents the final results of our efforts. Not only had the amount of backlog hours decreased to levels never seen before (from a historical average of 300 hours to less than 150 hours), the number of quotes completed were at all-time highs for the company.

The key to solving this problem was to first identify when the problem started and then to look for changes that had occurred in the same time frame. The Run Chart proved to be a very valuable tool, not only to determine the starting point of the problem, but it also permitted us to track the impact of the change we had made.

RunChart3

Next time

In my next posting we will discuss another very useful tool in the Six Sigma tool kit, the Scatter Plot. Like the rest of the tools presented in this series, the Scatter Plot is an excellent tool for solving problems. As you will see, the Scatter Plot helps you identify cause and effect relationships between variables. As always, if you have any questions or comments about any of my postings, j leave me a message and I will respond.

Until next time.

Bob Sproull

Leave a Comment (Please Log In First)