iSixSigma

Defining Primary Metric: Starting Off on the Right Path

As a Black Belt in training and working on my first project, I was overwhelmed with project information, data, statistics, tools and direction from my Champion. Quite frankly, there were times in the beginning I wondered what I had gotten myself into. At the first meeting with my Champion I was given a project metric to “reduce retail maintenance expenses.” So, like any naïve Black Belt with training limited to the Define phase, I took this high-level business metric and enthusiastically ran with it.

In my first team meeting, we determined our defect definition was any retail location which exceeded a certain monthly maintenance dollar limit, our stakeholder analysis was drafted based on maintenance spending, and our fishbone diagram was brainstormed with “maintenance expenses” as the output. Bottom line, the entire Define phase centered on reducing maintenance expenses by basically deeming any dollar spent a defect.

Project Team Has a False Start

At my first report-out for the Define phase, I nervously awaited my turn in the conference center, but felt confident in the material I was to present. In my mind, I was spot on. The audience was made up of my Champion, several other Champions with little or no experience, representatives of the consulting firm my company retained to provide us training, their Master Black Belt, and other members of senior leadership team. There were a few present who had prior experience and one vice president in particular with experience from GE. When it was my turn, I started my presentation with the opening statement, “My project is Reduce Maintenance Expenses and the objective is to reduce maintenance expenses from X to Y by Z date.”

“Hold on!” I heard from one side of the room. “You can’t have a financial metric as a primary metric. You need to reduce a defect and variation which will ultimately reduce an expense or increase revenue. You can’t use money spent as a defect for this project.”

This led to some serious and debatable discussion for the next several minutes, for which I just sat there slowly realizing how way off I was for the entire Define phase of this project. By the end of the discussion, I and the rest of the audience, understood and agreed with the vice president who voiced her objection. All of a sudden, it seemed so clear. How could I have made such a mistake? I also knew that this meant my project would need to be re-scoped and the Define phase repeated. I was frustrated that I did not see this very obvious defect and that it was not picked up by the Master Black Belt working with us. However, after my not-so-positive presentation experience, I picked myself up and started over with my team.

Scoping Down from High-Level Metric

So how did my team and I scope down from the very high-level metric of reducing maintenance expenses to the right metric? First, I generated a simple Pareto chart of the retail maintenance general ledger spending for the previous 12 months. We determined that dispensers are where we were spending the most money. Now we knew what piece of equipment to focus on. Next, my team and I brainstormed using a fishbone with dispenser expenses as the output (temporarily). Using people, process, tools and environment (just my personal preference), we were able to see that the actual maintenance calls coming in from the retail field to our maintenance help desk were a significant factor in each area of the fishbone. At this point, we knew what piece of equipment and a significant factor around that piece of equipment. Next, we created a new fishbone this time with maintenance call as the output. Using the same categories, it became clear that the accuracy of the maintenance calls from the field to our maintenance coordinators at the maintenance help desk is where the project was. Our project was re-named “Accuracy of a Dispenser Maintenance Call” and our new primary objective was to reduce the inaccuracy rate of dispenser maintenance calls from X to Y by Z date.

During the measure phase we determined that 43 percent of calls coming in from the retail field to our maintenance help desk were not accurate. Our defect definition of an inaccurate call was any call which was 1) unnecessary (a technician dispatched to the retail location determined that there was nothing wrong with the equipment) or 2) avoidable (a technician dispatched to the retail location performed a service that could have been handled by the retail location, such as clearing a paper jam or pressing the clear button on the dispenser). The Measure phase justified our new and improved direction in the Define phase.

It was a preconceived assumption that the bad calls were occurring during the overnight or early morning shifts when a person of authority was not present. However, during the Analyze phase the data showed us that the majority of bad calls actually were called in during the time a general manager was on duty. So now we knew that it wasn’t the inexperienced third shift personnel and we couldn’t find a particular division, territory or even state that stood out. It was bad all over! We concluded it is not the people it is the process and looked closely at the maintenance call process.

On Track to a Good Project

After flowing out the process we found some pretty quick hits. The data entry from the field into the existing system was based on free-form text. Because of the fast-paced environment at the field location, the personnel only had a few minutes to enter in the data into the system. In most cases, they wrote “dispenser doesn’t work” and nothing else. If the help desk team members had time, they would call the location for additional information and clarification. If not, they simply dispatched a technician to the site to make the repair. Of course in the case of an inaccurate call, when the technician got there they found that either whatever was wrong had been fixed (most likely by other personnel or by a customer), or the repair was something simple that anyone at the location could have fixed without a technician being dispatched.

One of the solutions determined by the team during the Improve phase was to implement drop-down menus to the system and provide a few quick bullets of what to check before proceeding with the maintenance request. Also, the help desk started tracking the root cause of the bad calls and provided specialized training to those market areas that showed a trend in unnecessary or avoidable calls.

In the end, the project team was able to help field personnel at the retail locations by providing them with the proper tools, training and awareness to efficiently and accurately report a dispenser maintenance call, which increased the accuracy rate of dispenser maintenance calls, and created potential savings for the company of more than a million dollars. At my final report-out my Champion finally got to see his financial metric.

You Might Also Like

Leave a Reply