iSixSigma

A Case of Mistaken Capability

Lean Six Sigma (LSS) teams focus on the statistical analysis of metrics when identifying opportunities for improvement. The strong focus on data-driven evaluation, however, can overshadow the human element that exists behind the data collection plan. Despite its importance, the impact of human interaction is not easily visible or quantified, buried under reams of data. The common expression “numbers do not lie” may be true, but a clear understanding of where the numbers came from, and of the human factors involved, is required to reveal the truth in the data, as demonstrated in this case study.

Data Vs. Performance

Due to a rising occurrence of late deliveries, Company X initiated an investigation of a process that was failing to meet the required output on time. The process was considered stable and capable of meeting customer requirements until the past two months. There were no records of recent changes that could account for this downward performance trend, making it more difficult to pinpoint the cause or causes of failure.

The leader of the project investigating the process decided to perform a cycle time study by accessing the process database (“desktop time study”) in lieu of a plant visit. The desktop time study was repeated multiple times with similar results each time.

The desktop time study focused on the process start and end time stamps. At initial glance, the data showed capability to meet the required lead time without the need for additional resources. There also was a high level of confidence in the accuracy of cycle times since the data had come from computer time stamps before and after completion of each task. To everyone’s dismay, however, the wave of late shipments persisted.

Handpicked Content:   Using Lean Six Sigma to Improve Call Center Operations

Due to the incongruity between the data and performance, the project leader decided to visit the center and perform a visual audit. Eureka! During observation of the process and interviews with the operators, the project leader discovered the main cause of this erratic performance level, discussed below.

Mistaken Process Capability

The process occurs in two parts, Process A and Process B. The operators for Process A (Team A) had been with the company for a long time and had developed repeatable Lean-based techniques to simplify the flow and still maintain a high level of quality. Their improvements had allowed the operators to complete their process earlier than the anticipated cycle time.

The supervisor of the succeeding process took advantage of this opportunity and utilized the extra time of Team A to perform data entry for the start-up of Process B. The result was a shortened cycle time – and thus improved capability – for Process B. The shift in resource allocation was not documented, however, giving the impression that Process B had increased its capability utilizing the existing resources of Team B. In reality, only Process A had the extra capability attributed to Lean streamlining.

After a period of time operating this way, the business experienced a change in volume that required Team A to focus solely on its own process, leaving no extra time to help with Process B. Since the system was based on an erroneous calculation of capability for Process B, it was not known that the change in volume – and thus the change in where Team A’s time was spent – required additional resources to be assigned to Process B to maintain productivity. The true capability of Process B was revealed, which in turn led to the late deliveries.

Handpicked Content:   Creating Customer Delight – A Case Study in Diagnostic Clinics: Part 4 of 5

In a nutshell, it was a case of mistaken process capability (see figure below).

Mistaken Capability of Process B

Mistaken Capability of Process B

Fixing the Problem

Meanwhile, the salespeople of the company were producing pricing and delivery-time proposals based on the erroneous cycle-time and resource-allocation information. Without the borrowed capability from Team A, the true capability of Process B was lower. Therefore, the actual capability did not match quoted capability and fell short of customer requirements.

The salesperson who made the initial bid would rather waive their commission than have to tell the customer, “Sorry, the price bid is wrong and now we have to increase the price.” A quick solution that could also stand the test of time was needed.

To address the problem, the improvement team implemented several different action plans, including:

  • Mirror the Lean improvements from Process A to shorten total process cycle time.
  • Utilize the expertise of Team A in Lean implementation for cross-training.
  • Require time study methods to be approved by subject experts or process owner to capture any undocumented yet critical knowledge about the process. 
  • Require periodic reviews of capability measurements to ensure continuous optimization.

Lesson Learned

Although numbers do not lie, their origin and meaning must be carefully interpreted. Using the right methodology, creativity and a willingness to consider the human element will achieve better results.

Advertise on iSixSigma.com
Advertisement

Comments 23

  1. Thomas Whitney

    Fantastic article and great lessoned learned. Every project lead need always visit the process and people to truly understand where, why and how data is collected. That is what is the data telling you! Data is passive in a data base but from where it originated it originated is not.

    0
  2. Gayle Roten

    Janet, this displays the organization and re-organization of time capability beautifully! You have
    detailed the process in a wonderful scenario! Great Job!

    0
  3. Joy Hannan

    A great case study to identify invisible problem(s) and find the solution to solve it. It is an eye opener and a good example in think out of the box. Sometimes we trust our data so much and we do not recognize the erroneous data leads to a path that goes nowhere. This article is very useful to me.

    0
  4. KC Kern

    Nicely illustrated need for correct methodology. Thanks!

    0
  5. Astrid Weis

    Great Article Janet! Data has to drive the business, but this article shows it so nicely that we truly need to understand the data before making decisions. Great Lessons learned!

    0
  6. Janet Bautista Smith

    Hello Thomas,
    Thank you for the comment. Yes, you are absolutely right–process and people are key elements in data collection.

    Sincerely,
    Janet

    0
  7. Rod Johnson

    Thanks Janet. I enjoyed the read. I have seen this type of problem rear its head over the years and now I have some names to assign to the various components and a path to walk down to correct it.

    Regards…

    0
  8. Janet Bautista Smith

    Hi Rod,
    Thank you for your comment. Working with you this last few months on Lean projects is also a great experience for me in seeing the other aspect of data analysis.

    Sincerely,
    Janet

    0
  9. Chris Seider

    Janet,

    It looks like you can have an easy conversation informing the customer of the documented processes.

    However, just having 9001:2008 doesn’t mean you have documented the processes as they presently exist. You may want to audit adherence to the documented procedures as referenced by your ISO controlled documents before the conversations with your customer.

    Interesting article. If I understand the article, the total cycle time was correct but the time associated with step B was incorrect?

    0
  10. Lisa Doerner

    Janet,

    Nicely written article!

    0
  11. Robert Tripp

    Janet,

    This is a great case study and an excellent example of the dangers of relying on data analysis alone to try to understand a process. I like the way that it demonstrates the risks you take when you neglect parts of a disciplined DMAIC approach, specifically the parts that involve meeting with the core participants in the process to watch the process and document it (gemba followed by process mapping). I like to think of the problem–solving process as one that involves a lot of checks and balances which help avoid (though don’t always prevent) drawing erroneous conclusions from lack of or bad information. Some of the checks and balances like looking at the process with the team and MSA were exactly what was overlooked in your case study and the article demonstrates that well. Nice work, and I am glad to see that you are participating on the iSixSigma community.

    All the Best!

    Rob

    0
  12. Jeremy Garrett

    Interesting article! A great reason why seeing a process in person is so important and just viewing the data will not show everything.

    0
  13. Irene Perez-Saucedo

    Janet,
    Beautifully written! As always, you are very concise and detailed in the way you articulate both verbally and in writing. For someone who is not active in the day-to-day operations, I was certainly able to appreciate the information through your scenarios and comparisons.

    Sincerely,
    Irene

    0

Leave a Reply