iSixSigma

A Question on Analyze Phase

Six Sigma – iSixSigma Forums Old Forums General A Question on Analyze Phase

Viewing 28 posts - 1 through 28 (of 28 total)
  • Author
    Posts
  • #33939

    Hemansu
    Participant

    Hi,
    I would like to know if sampling can be done in Analyze phase as well. I’m doing a project on reducing the cycle time for processing invoices. After having sampled the invoices in Measure phase and arriving at a baseline sigma, am not really sure if I need to further sample in analyze phase. The reason being the amount of data to be analyzed is very huge.
    Thanks,
    Hemansu

    0
    #92859

    Manu Gautam
    Participant

    There is no hard and fast rule regarding sampling usage for a particular phase only. However, you did not state the purpose for which you want to do sampling. If you have already baselined your process and used sampling, you already would have segmented and sampled the data.
    Help me understand your requirement better, so as to provide you more assistance.

    0
    #92860

    Hemansu
    Participant

    Hi,
    Thanks for your reply. Let me give you an example to explain this better: Lets say, for US region, the number of Invoices posted to SAP [Opportunities] is 21000 of which the number if defects is 2300. The baseline sigma is already calculated using this data. Since I cannot analyze all the 2300 defects, I need to know if I can sample this defectives of 2300 invoices.
    Thanks,
    Hemansu 

    0
    #92868

    Manu Gautam
    Participant

    You can do sampling but ensure bias is avoided.
    What i can imagine is you want to sample defective invoices and do defect categorization.
    If you know they are defective then you know the reason of their failures, more focus should be on analysing the defect category and using Pareto to focus on key areas.

    0
    #92879

    ROSS
    Member

    It is very typical to gather data in Measure, then move on to Analyze and look at the data — root causes and all — only to realize that you need more data, or didn’t collect all the data you need to determine your root causes. This is especially true on GB projects where the BB or MBB coach is not fully engaged in the project definition and data collection plan creation. Don’t fret — just be pleased that you realized that you need more information. It’s a learning curve!

    0
    #92883

    Mike Carnell
    Participant

    Hemansu,
    You got good advice from both Tony and Manu. I would consider two things if I were you.
    Your question makes it sound like you have been taught a very mechanical process rather than a thought process. If you are just checking off boxes because someone has generated another one of those “workbook” type approaches (typically to make a MBB or Champions job easier) then you can expect mediocre results and in a few years you will look around and understand you still don’t have a clue what you are doing.
    You are defining a problem in terms of a dependent variable (Y) and learning to control it with independent variables (x’s). You use the appropriate tools when and where you need them. At this point we still don’t have Six Sigma police (at least not globaly) and there is no Six Sigma jail. Your customer (your employer) expects results so that is what you deliver.
    The second point is that if you continually loop back to measure from analize because your project was poorly defined. Fix the project selection process. Whomever is picking your projects is short cutting their responsibility of delivering a well defined project and whomever is running your deployment is letting them do it. It is costing you time (wasting your companies resources) amd if they have hit you with a “number of projects per year target” you will fund their lack of involvement at your next review.
    Just my opinion.
    Good luck.

    0
    #92884

    KBailey
    Participant

    I agree that it’s ok to use sampling in the analyze phase on a project like this, but there’s something else you should consider.
    These invoice defects are probably caused by problems in several different processes; e.g., sales, order entry, invoicing. When you categorize the defects and dig into root causes, you’ll find that one category has multiple root causes. At the same time, a poor process such as order entry can cause many categories of defects. You can do your first Paretor analysis to find your biggest categories, and then do a Pareto analysis each of those categories, only to find that you have to fix several different sources in order to get significant improvement. The end result can be paralysis of analysis, delayed implementation, and incremental change (rather than radical improvement).
    I would suggest backing up to the input processes. Break the project up into several smaller projects to improve customer set-up, capturing order information, order entry, order fulfillment, and invoicing processes, one at a time, rather than trying to reduce one category of defect at a time, such as invalid PO# or pricing errors.
    If possible, do a pareto analysis on the source of the defects. You can use sampling. Essentially, I’m talking about returning to the Define phase, but based on my experience, I believe it will pay off in the end.

    0
    #92888

    Ron
    Member

    This is interesting I have seen this often.. People are using the wrong tool set to address a problem.
    From the simple description you offered your project seems to be a cycle time reduction project. Six Sigma tool will help you reduce variaition and you may gain a little improvement. Utilize the Lean toolkit, Value Stream Mapping, Load Balancing, etc. You need to get a view of the entire process so you can determinbe if this is truly the “Bottleneck” in the process.
    You should have created a focused problem statement in the Measure phase which points you in that direction. The Deliverable from the Analyze phase is  set of root cause analysis that pinpoints the root of the problem you found in the measure phase.
     

    0
    #92892

    KBailey
    Participant

    Upon re-reading the original question, I realized my first answer didn’t actually answer it. As Ron pointed out, make use of the lean tools.
    However, you may also want to look at the variation in cycle time. You can use sampling to do a histogram of the cycle time. Chances are it will look like a Weibull curve. You may change your approach based on the shape of the curve. The lean toolkit tends to shift the minimum and average times. However, a relatively flat curve and/or a large tail may drive you to use other tools. For example, you may want to sample invoices that take longer than time t to process, and do a pareto analysis on the causes of the delay. You can also use sampling for regression modeling to look for factors such as $ amount or number of items on invoice that could affect time.
    However, since the relationship between these factors and cycle time could change when you lean out the process, in most cases you’re probably better off applying the lean tools as Ron described first.

    0
    #92893

    Spiderman
    Member

    From your quick description of your problem…..it sounds like prework to me.  You have good information to fill your charter….now it is time to narrow down the causes…..and scope your project to be more specific.  Pareto the data and scope your project to go after the big dogs. 

    0
    #92895

    PB
    Participant

    Hi!
    I concur with Ron. One of the first things you should have done is a SIPOC (40,000 feet view) map as you learn in the Six Sigma program. Once done, narrow down to your project area and create a Process Map. This helps you to define your project better. This project may need a complete Value Stream Map on the process. You will find that you can use the DMAIC approcah but your project may actually be  a Lean type project.
    However, you are not alone if you have to go back to measurement from the analyze phase. I typically would like additional time spent in the measure phase so that I am absolutely sure the project I am working on will not need a revised charter.
    Good Luck.
    PB

    0
    #92904

    SJ
    Member

    It looks like this discussion was going very well and then Ron came along and took a dump all over it along with his fan club.
    Hemansu-
    There is a defect (probably more than one) in your process.  You mentioned that you’re trying to reduce cycle time.  That probably should not be your focus.  As previously mentioned you need to stratify your defects based on your defective invoices.  And focus on eliminating the vital few that your data points to.  SAMPLING:  Make sure that when you are doing that you have sampled the defective units to appropriately represent your population. (you are dealing with attribute data so n is going to be very large) By fixing the defects in the process you will automatically improve the cycle time of your process.  Measure cycle time as secondary metric.  Get some quantifiable primary metric on your defect also. There will definitely be opportunities to apply lean in your process.  Do it along the way.  SS and Lean are a great combo, they don’t have to be segregated.
    Don’t worry about where you use sampling.  If sampling is going to help you learn something that will contribute to the successful completion of your project then sample, don’t do it to check off the box.  Your not technically in the A phase but don’t worry about it.  Your MBB or BB should be doing support with you. That support should consist primarily of one thing, helping you apply tools to get to a solution that will generate financial benefits for you. My guess is your support guys are probably measuring the progress of your project by compliance to their standardized set of documentation or some other NVA compliance to try and justify keeping their jobs probably like this guy this Ron does.  Don’t pay attention if that is their focus, keep yours on learning about the problem and fixing it.
    Keep plugging away!

    0
    #92913

    KBailey
    Participant

    I’m not sure, but I think someone referred to me as Ron’s fan club…
    SJ is right that reducing defects will probably improve cycle time. However, even a 6 sigma process can have a lot of wasted steps and wait time. Besides, you may spend time reducing defects in activities that aren’t necessary. Why try to improve an activity that you shouldn’t be doing to start with?
    This is why I suggest looking at a histogram of the distribution of your cycle time measurements, and then looking at what’s inflating the time. If there’s lots of space between the y-axis and your curve, but your curve is fairly tight, I would expect you to find a lot of wait time and/or wasted steps, but a low defect rate. If your curve starts close to the axis and is wide with a big tail, I would look for defects and associated rework, either from your process or from your process inputs. If there is a lot of space between the y-axis and your curve and you have a wide curve with a large tail, I would adopt a combination approach of eliminating wasted steps and wait time AND reducing the defects that cause delays. 
    Reasoning: wasted steps and wait time will tend to shift the entire time distribution curve to the right on the histogram. They may or may not add variation in cycle time. Defects will tend to increase the variation in time, as well as the average. However, the defect rate generally shouldn’t change the minimum time for a non-defective, so the left side of the curve should start up at about the same point, regardless of defect rate. Value Stream Mapping may get you a more complete and accurate picture, but take weeks or months longer to get the full picture mapped out with all the metrics.
    Hope this helps!

    0
    #92917

    Mike Carnell
    Participant

    KB,
    This thing has gotten pretty twisted around in a pretty short time. SJ is obviously a practitioner who understands how to get focused and get results. That is what we get paid to do.
    I am not sure where you got the graph to see if there is wait time. The first time we did Lean was in the mid 80’s at Motorola. The Manufacturing Manager had us all read “The Goal” and then he wanted us to identify the bottleneck. I was standing with him on the production floor (after he had all the shelves removed one evening so the floor was the only place left to store anything -s o we had to walk around it) and asked him how we were going to find it. He said “We’re going to stand out here for the next couple days and see where all the shit piles up.” Lets not make this stuff any more complicated than it needs to be. If you are interested in wait time – get up and go see. It is the stuff that isn’t moving or being worked on. The bottle neck is the next operation after the big pile. If you have a couple big piles only ones the bottle neck but you probably need to fix the other one anyway. Some pretty straight forward stuff.
    I am not sure how sampling became it should be a Lean project but that is a long stretch.
    Good luck.

    0
    #92918

    Statman
    Member

    Mike,
     
    “It is the stuff that isn’t moving or being worked on. The bottle neck is the next operation after the big pile”
     
    Not necessarily.  It could be batching in the previous operation due to long change over times.  Reducing the change over time and running smaller batches reduces the bottle neck.
     
    However, I totally agree with you.  You need to turn off Minitab and walk the process to find out what is going on.
     
    Cheers,
     
    Statman

    0
    #92924

    Hemanth
    Participant

    Hi Hemansu
    Somehow I am against sampling in the analyse phase esp in cases like yours. Sampling comes with a risk and it is for you as a GB/BB to decide if you wish to take that risk (well, I dont..)
    If I were in your position I would hire a trainee / junior level guy ask him (or do it myself) to develop a database in MS ACCESS. I have done it for a process where we use to get 200 records every day and in the end the team could stand before anyone and get the proposals approved. It also gave us multilevel pareto charts and that helped us enormously in identifying root causes.
    With sampling you could run into a situation where someone (not statistically oriented) might question your analysis just because it is a sample of overall invoices. So think over it.
    Hemanth
     

    0
    #92925

    SJ
    Member

    Hemanth-
    Let me get this strait….
    You dont sample, you measure and hire someone to sort (100% inspection) the entire population because:
    1) you dont like risk and
    2) you’re afraid people wont believe you
    Are you serious with this?

    0
    #92927

    Hemanth
    Participant

    Hi SJ
    Well I am serious about this. Its not that I dont do sampling and neither do I profess 100% inspection or sorting. It is only in this case where we have 2300 defective invoices that I recommend considering all 2300 invoices rather than risk loosing information because of sampling. To me sorting 2300 invoices for defect categorisation is an uphill task but a manageable one.
    Well, frankly I need some time to answer your questions. I am still struggling to answer them…are those some trick questions???

    0
    #92930

    Ron
    Member

    Hemansu,
    There is no six sigma jail ! You won’t get arrested for taking additional data. The question you should ask is what am I sampling to determine?
    If you are not sure where your problem lies you are still in the Measure Phase. If your are focusing on issues you are in the analyze phase.
    What is the data you already taken telling you? How have you analyzed it? The deliverable from the analyze phase is defined and statistically valid root causes of your problem statement.

    0
    #92935

    Mike Carnell
    Participant

    Statman,
    Your right, it could actually be something else like a long change over but that needs work also.
    A little IBWA (improvement by walking around). There comes the next law suit.
    Have a great holidays.

    0
    #92939

    Mike Carnell
    Participant

    Hemanth,
    I am a little surprised at your response considering many of your previous posts.
    There are trade-offs when you sample but they are mitigated by the defect rate and your aversion to risk. If you are building medical devices you need a higher level of confidence and at that point 100% may make sense (that doesn’t incude Ace banages for the BD people). If your defect level is high then sampling can be very effective (check out your Poison tables).
    What is the risk on an invoice? Where is the payback on 100% inspection (you are going to have to explain why it is any different than sorting). There isn’t much risk (the idea that there are 2300 records assumes it isn’t a high dollar item). If the only risk is that somebody doesn’t believe you – run the sample data and do your analysis. You can quantify the risk. If it is a concern ask them before you calculate the sample size and run the analysis how much they are willing to accept and why. requiring perfect information to make a decision is a fatal business strategy. If you think that 100% inspection eliminated the risk – run a GR&R on the the junior guy doing the visual inspection.
    If they don’t buy your work, give them the 2300 invoices and let them come up with data to prove there is a significant difference between what you got and what they got.You use data to get in the game. If you don’t have data you don’t get to play. Why would you let them redefine the game based on their ignorance.
    Just my opinion.
    Have a great holidays. Good luck.

    0
    #92943

    Mike Carnell
    Participant

    Hemanth,
    Have you checked out the featured article on the home page (of iSixSigma)? It seems relative.

    0
    #92947

    SJ
    Member

    Hemanth-
    Relax buddy, don’t spend too much time thinking about those questions.  They are not meant to trick you.
    I would argue that it is NVA to sort the entire 2300.
    A portion of those invoices should be categorized to determine the fields that contribute the majority of the defects.  How….by sampling.  The whole reason that we sample is it saves us time & money (by not hiring someone to sort for example) and can give us the information we need to know as long as we answer a couple questions
    1) What do I want to know? 
    2) What is significant how do I set my Alpha, Beta and Power values and what test do I use to give me my sample size?I understand you want to see everything that is happening.  But you don’t need to when you can get the same information faster by sampling. It is not necessary to treat invoices the same way you would treat a pacemaker.  Just manage your risk. 

    0
    #92970

    Hemanth
    Participant

    Hi SJ
    Well you sure do have a point. Maybe I am being over cautious here bcos of some of the experiences I have had here..
    Hemanth

    0
    #92971

    Hemanth
    Participant

    Hi Mike
    Nice to hear from you. I do agree with you and SJ. May be I am being overcautious in my analysis here.
    Thanks and have a nice holiday
    Hemanth

    0
    #92975

    Hemansu
    Participant

    Hi,I believe there is nothing wrong in sampling in analyze phase considering the defects which go upto 60000 invoices. In measure, I have already calculated the baseline sigma taking into account all the 60000 defects. However, i wouldn’t know where does the problem lie unless i analyze this data..and for analyzing the data i need to do sampling because it is virtually impossible for me to look into all the defects. Only after the analyze phase I will have a base to go forward which would help me in focusing on the major contributors in terms of time taken in each step of the invoice flow.Any suggestions?Thanks,Hemansu 

    0
    #92986

    KBailey
    Participant

    Hemansu,
    It may help if you clarify your objective and the COPQ driving it. You said before that the project is to reduce cycle time. What is the main problem you’re trying to fix? Is it one of these?
    1) All invoices take too long to go through the process (cycle time)
    2) Defects take too long to go through the process
    3) Spending too much time and money fixing defects
    4) Too many defects (project isn’t about cycle time, as originally indicated.)
    It’s great to categorize the defects, but if your project is supposed to focus on #1, worrying too much about the defects now may distract your team from the defined project objective, increasing your project cycle time. Depending on your company’s management culture, it can be politically damaging to you and the Six Sigma effort. You may get better results by focusing on the wasted steps, delayed batch processing, and bottlenecks in this project. Focus on the defined objective, and then as part of your report to management, you can include basic definition for another project to deal with the defects.
    If the project isn’t specifically focused on #1, clarifying the nature of COPQ you’ve found and your direction from management may help generate appropriate suggestions.

    0
    #92989

    SJ
    Member

    Hemansu-
    That’s good advice from KBailey.
    Another thing you should be careful of is using a process sigma measure as the primary measure for your project. It is not a sensitive metric, and will not give you the appropriate resolution you will need to see. Once your “Defect” is clear find a quantitative way to measure it (% of defects / week/month for example)
    Also, dont be afraid to cut the project into a couple. Keep it at a manageable size or before you know it the project will be 8 months down the road and you’ll still be looking at root causes. Hit the process piece by piece. You should be able to work 2 to 3 projects in parallel if your a full time BB.
    Good luck!

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

The forum ‘General’ is closed to new topics and replies.