iSixSigma

How Do I Quantify a Problem with No Historical Data?

Six Sigma – iSixSigma Forums General Forums General How Do I Quantify a Problem with No Historical Data?

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #55588

    sam
    Participant

    Hello,

    I have been placed on a new project to fix an issue that has been going on for the past 10 years. The products that are experiencing the issue are only run about 5% of the time, about once a month. Historically, when they found the issue on the line they would fix it on the line. Unfortunately, this fix can lead to a decrease in the performance of the product. Management has now taken away the rework tools assemblers had on the line so now there is a rework loop from Assembly back to Machining.

    The problem I am facing is the lack of historical data on how often this has been happening so that I can quantify the problem and put a COPQ value to it. The defect is caught just before testing so it doesn’t show up in the FPY or rework data. Thanks for your help.

    The high level process is Machining –> Assembly –> Test –> Ship

    0
    #200661

    MBBinWI
    Participant

    @BuckeyeGuy92 – one problem off the bat is that you aren’t calculating FPY correctly. It should include all steps, including testing and shipping.

    More generally, the question is – how critical is it to obtain precise data? There seems to be sufficient understanding that this is a problem. Is it agreed that it is sufficiently large to dedicate resources to fix? If so, then start to gather data every time that this product is run. That doesn’t mean that you have to wait for this data to be sufficiently detailed to start. You can do other Define/Measure activities in parallel. As the quantification becomes more clear, you can evaluate further.

    One thing to be careful of is the “squeaky wheel.” You may have much bigger problems to deal with on other products, but the one person who has a problem with this particular product makes a big deal about it, because it’s a problem for them. Be prepared, with data, to suspend the effort if the data shows it’s not really as big an issue as originally thought.

    The other thing that comes to mind is that with 10 yrs of history, why has this continued for so long? Has the swamp of problems been drained enough that this rock is finally showing up, has something changed that makes this rock bigger, or is the one person who stubbed his toe on this pebble yelped?

    0
    #200667

    sam
    Participant

    Thank you for your response. You are correct, if we were using RTY we could clearly see the seriousness of the issue.

    I have implemented a data collection sheet with the assemblers to record the occurrence. While this is being collected I am running MSAs on the measurement systems used upstream that affect this issue.

    The previous manager of this value stream left 2 years ago. Under his guidance, he would allow the assemblers on the line to “fix” the symptom, which ultimately could have lead to other problems. Since then the new VSM is more focused on the quality of our product vs. meeting his shipment dates. As a result, this “rock” was discovered.

    0
Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.