The Manual Pareto Chart
When was the last time you created a Pareto chart manually? For those of you not familiar with a “Pareto ” chart, it is simply a bar chart that organizes the categories from highest-to-lowest in frequency of occurrence. Pareto charts are useful when “issues” outnumber the resources available to solve them; obviously, you would want to put the resources on the largest issues first. (I want to mention here that frequency of occurrence is not necessarily the best way to prioritize issues; a much better method is using a technique called FMEA(Failure Mode Effects & Analysis) where each possible mode of failure is ranked by multiplying its severity to the customer, its frequency of occurrence, and its probability of detection to determine its overall ranking. But for everyday issues in a production process, we’ll stick to occurrence frequency to rank our issues.) With the Pareto chart, the x-axis will list the various issues, while the y-axis plots the frequency of occurrence.
This type of bar chart is prevalent in manufacturing plants, however, the Pareto chart is useful in any environment where continuous improvement through problem solving is important. For those of us over forty years of age, we remember sketching manual Pareto charts. They weren’t nearly as sophisticated, aesthetically pleasing, and quick to make as today’s computer-generated charts, which are easily handled by Microsoft Excel and myriad other graphics software packages. So why on earth would we ever want to make a Pareto chart manually in this age of laptops?
The answer can be found in two words: real-time. To explain, let’s consider the creation of a computer-generated Pareto chart. To begin with, we don’t create the chart until we have all the data. “All the data” can mean one month’s worth, one week’s worth, or maybe even one day or one shift, but not one hour or every 15 minutes. Second, we create the graph on our computer while in our office, well away from those whom the data is measuring. These two points make the computer-generated Pareto chart a weak tool for real-time production monitoring.
In comes the manual Pareto chart, ready to assist in real-time communication directly to those who can impact today’s production results – namely the manufacturing associate and the first line of direct support. Let’s walk through an example to clarify how it works.
We start with a production status board that is in view of those doing and directly supporting production. In this example, we are going to monitor production output to the established standard every half-hour. The product is a Widget, and we’ll set the standard at 10 finished goods every half-hour. With the shift starting at 7 am, the first data recording will occur at 7:30, and we’ll assume that 10 units were completed in this period. The person recording the production will use a green pen (green is “good”), and write 㥶” in the proper place on the production board. Since no production related issues occurred during this period, the Pareto chart directly below the production status remains blank.
During the next half-hour, let’s say that one Associate’s pneumatic screwdriver stops working, and the repair takes about ten minutes. Instead of producing 10 finished goods, the team’s output is only 7 units. This time ׅ” is recorded on the production status board, using a red pen. All the associates notice the red on the production board, so they realize that they are now behind schedule. In addition to recording the production count (7), three “X’s” are recorded in a column on the Pareto chart, directly above the label “pneumatic screwdriver”. The “X’s” represent finished goods production loss (10 – 7). Based on current data, it has been predetermined that those directly supporting the production team must use problem-solving to eliminate each issue that exceeds a quantity of 5 lost units during a shift, and this is marked with a red line on the Pareto chart. Of course, we would love to resolve every issue that occurs, but unfortunately our resource constraints force us to choose wisely. This limit of 5 lost units has been determined to be the threshold where issues must be addressed. Therefore, a problem-solving list that is posted directly below the Pareto chart remains blank.
All during the shift, the production board and Pareto charts are updated each half-hour. When a Pareto category exceeds the marked limit of 5 lost units, then the issue is recorded on the problem-solving list. A “direct support” person will then record his name, planned countermeasures, and target date; the status is also updated at standardized time intervals until the issue is resolved. Everyone can see the status of problem-solving, and who is doing what to eliminate the current issues.
So now we see how a manual Pareto chart can be utilized to alert the production personnel as well as direct support when issues arise, and to show when an issue warrants immediate attention. Computer-generated Pareto charts are useful for long-term trends (weekly, monthly, and annually, for example); but for real-time communication and action, keep it simple with an erasable manual board.
First time implementers of this very useful trio of charts (production status, Pareto, and Problem-Solving List) should keep the following points in mind. First, if you do not have individuals whose primary duty is real-time direct support, then manual Pareto charts and problem-solving lists are a complete waste of time. Associates will not sustain real-time data recording if no one is taking action on the issues being recorded, and morale on the production floor will plummet. Second, if you set the “action” limit too low on the Pareto chart (meaning almost every issue requires action), you will quickly build a long, long list of problems to solve – without ample resources to address them, causing everyone frustration. In fact, I recommend that you begin with a problem-solving list that is designed to record only two or three issues; all other issues will go in a holding pattern until these few are resolved. After 6 months, you may change the form to allow for more issues to be recorded; only do this when you have demonstrated a successful track record of adherence to this process, as well as dependable, efficient problem-solving by a confident team of direct support. Finally, be patient; learning and following a standardized problem-solving methodology takes time to develop. At the same time, be persistent; don’t be quick to call the program a “failure” after the first few weeks’ poor performance. Observe, audit, and correct the process every day. Encourage, coach, and give support, but never give up.
On another day, we’ll see how this skill of real-time problem-solving is the basis for successful incremental continual improvement, and how world-class Lean companies begin training this skill to all levels from day one. When a production floor is operating with disciplined real-time monitoring procedures and surrounded by well-trained problem-solvers, one can practically smell the “kaizen” or continuous improvement in the air.
Until then, good luck in taking another Lean step forward! Remember, patience and persistence.
Sam Frazier is a Lean SME (Subject Matter Expert ) who transforms business processes and culture to achieve world-class levels in Quality, Cost & Delivery. He pioneered the Lean effort inCorning Incorporated, and has spearheaded kaizen events in the US, Mexico, Germany, Poland, Puerto Rico and the Dominican Republic. His projects have totaled over $30 Million in cost savings.
Contact him at samfraziertps@sbcglobal.net.
