iSixSigma

GRR for real Vs reported

Six Sigma – iSixSigma Forums Old Forums General GRR for real Vs reported

Viewing 16 posts - 1 through 16 (of 16 total)
  • Author
    Posts
  • #50815

    Venugopal G
    Member

    Dear Friends,
     
    I am working on a project where the objective is to reduce downtime of the machine and improve its availability. This is one of the critical machines which is affecting our line productivity. I am currently in Mesaure phase and have developed data collection sheets. I observed the data being collected by the operators themselves for a week and now I am suspecting it (means they are not reporting the real idle time and skipping a few). For example let us say the shift available time is 480 Minutes and the production achieved is XX Nos, the if I calculate the idle time based on the cycle time, I would get that idle time for that shift is XX Minutes. This XX Minutes is not matching to the reported idle time by the operator in that shift. Being a production engineer I know that it is difficult to capture minute by minute idle time manually, but we should atleast capture 80% of the real idle time. Currently operators are reporting only 40 to 50 % of the data, which would not lead to a good analysis.
     
    I would like to know the method of calculating the GRR for the real Vs reported idle time data. Any help on this would be appreciated.

    0
    #175183

    Severino
    Participant

    Idea 1:  Why don’t you just skip the R&R and record their production using a camera?  You can fast forward when the machine is running and just record the time delta when the machine is down. 
    Idea 2:  You could stand out their with them for a day and make sure they understand what idle time is and see for yourself if the time matches your expectation in one shift.
    Idea 3:  Get yourself a PLC, hook it up to the machine, let it record the idle time and skip the operators.
    I don’t think calculating a R&R is going to solve your problem and its just going to waste your time.  You need to see what’s really going on and not just rely on your calculations.

    0
    #175189

    Taylor
    Participant

    V
    I agree with Jsev and want to add to it some, There are many factors which could lead you to believe operators are not reporting correct idle time. OEE can help identify those gaps. Although somewhat difficult to implement at first, this tool can help you capture those times which fall outside the “Normal” operating of the equipment. For example excessive tool adjustment or just a bad tool which had to be changed twice, etc.
     Another way is to simply set up shop with them. Pull up a chair, somewhat out of the way, and just observe, for at least a week. Perform a time study of the operation while observing, this will give you a much better idea about what is actually going on instead just looking at data that was provided by the “Mice” while the Cat was out, if you know what I mean. I think you will find that it’s a matter of not having what they need available to perform the job in an efficient manner and that most idle time is due to lack of planning.
     

    0
    #175205

    Michael Mead
    Participant

    I agree with Chad–and with you for that matter. It is difficult for the operators to manually report all downtime. If you are interested in improving throughput, why not just use your (calculated) numbers for your gap analysis and go from there? You don’t need to get to 100%, but you have not reached the “Analyze” phase yet. What is an achievable target?
    I would even ask the operators how to get to that point. Although I am not a proponent of “The operator knows everything, because he is the closest to the process”, they may have some good ideas.

    0
    #175206

    abadi samosir
    Participant

    I would suggest to use OEE as a measure in your project. The more OEE the more throughput and it can identify where the losses are (esp. 6 big losses). Solving those losses will direcly reflect to througput. As michael said, recorded downtime can be calculated based on your ideal cycle time (can be design capacity) and actual throughput

    0
    #175207

    Venugopal G
    Member

    J
    Thanks for your reply.
    1. Installting the camera at the machine is not possible at our current circumstances.
    2. I have been in the shop floor every day for the first two shifts at least 1/2 to 1 Hour explaining them, they do it when I am standing, but not when I leave.
    3. Installing the PLC is also not possible now
    I have decided to stand at the machine for few shifts and collect data on my own. But my intention was to know about the procedure on how to calculate the GRR for this kind of data.
    Venugopal.G
     

    0
    #175208

    Venugopal G
    Member

    Chad,
    Thanks for your reply.
    I have included every idle time including lack of material handling equipment, lack of material etc in the data sheet.We have a team which collects rejections (quality) seperately, and operator themselves fill the production log sheets which speaks about the numbers for the available time (performace). Then I have now the performance and quality, but I dont have availability factor, which is why the down time sheet.
    Now comes the big question.
    If I stand at the machine and perform a time study, but how much data should I collect, means how many shifts.Bcoz the same problems would not be there every shift but when I summarize a week/month data I may get a few which are there in every shift. Also I may know that the same type of the product when run in different shifts is leading to different down times (variation in the data), why so? This I mean that it can be due to lack of training/skill. If the problem is mostly skill, my project objective would be then to to change the skilled work like settings/adjustments etc into unskilled by optimizing them and developing the gauges as a part of standardization.
    Plz help me in the data collection.

    0
    #175210

    Venugopal G
    Member

    Michael,
    Thanks for your reply.
    I am not looking for 100% of the data. I can calculate the gap analysis with the numbers, but still it will not be the same as like the original na.
    Lets us say if the adjustments in the process are taking more than an hour every day, but operator do not report them bcoz they feel that the area manager would scold them as the point is turing out to their skill.
    So how to collect accurate data which is atleast 80% reliable, so as to know what is the problem actually. I have only an option of manual data collection and would be thankful if you could tell me on how much data on the suspected lines and product types is to be collected.
    Venugopal.G

    0
    #175211

    Toledo Oh
    Member

    Hi
         I think that you need to find and remove all the special causes of variation and only after your process is in stadistic control you can start using GR&R, But i recomend use the Cp & CpK before GR&R
    Thanks

    0
    #175213

    Szentannai
    Member

    Hi Venugopal,
    I think your first problem is one of low accuracy in the measurement and this is not addressed by the Gage R&R (Reproducibility and Repeteability) . I would perform a Measurement System Analysis which is a bit more general then a GRR and check what are the causes of this inaccuracy and figure out a way to improve the measurement.
    The reason this will be important is that even if you can and should find a way to measure your process by other means, as suggested in this forum, you wll still need some reliable measurements of process performance in the control phase.
    I would approach the measurement problem as a small project in itself – measure the accuracy, and the two Rs then do a root cause analysis and propose an improvement.
     
    Regards
    Sador 

    0
    #175214

    T.S.Murali
    Member

    Hi Venu,
    First thing first! Please be clear on what you are looking for!
    Total Available Time of Machine (A) = Total Working Time of Machine (B) + Total Idle Time of Machine (C) + Total Downtime of Machine (D).
    Your project is aimed at reducing the downtime of the Machine, which in turns will improve the availability of the Machine. So, focus only on Downtime of the Machine (D). You can get the working time of the machine (B) seperately if required, to calculate the (C).
    What is the type of machine downtime occurs? Is it frequent smaller downtime or occassional longer duration? If it is frequent smaller downtime, then you may have to collect information for fortnight and analyse to fix it. If it is occassional longer duration, then you need past record of at least few months to understand the type of downtime occurs or collect for few months and then fix it.
    Also your project goal will make significant impact on this. For e.g. if current availability is 60% and goal is to achieve 80%, then it is incremental. But if current availability is 50% and goal is to achieve 98%, then it is significant difference. So you need to collect very finer data to find the root causes and eliminate them.
    If you look at the goal for this project, there is no need to look at the idle time at all. Only look at downtime and get it fixed.
    In case your problem is that operators create downtime so that they will have idle time, then it is a different problem all together.
     
     
     
     
     
     
     
     

    0
    #175216

    Clive
    Participant

    One word of caution on collecting the data by watching you may not be getting a true picture of the process. Watching the process can change how people do their job they will tend to do it as they’re supposed to do it not how they do it normally, as you’ve seen with the data collection.

    0
    #175217

    Craig
    Participant

    How would you ever replicate a measurement? GRR does not seem possible in this case.

    0
    #175256

    Venugopal G
    Member

    Hi Murali,
    Thanks for your reply.
    I have not undestood the difference between idle time & downtime. I know that they are the same, if not can you please elaborate.
    All my downtimes are frequent smaller downtimes but thet eat alteast 1 to 1.5 hours a shift.
     

    0
    #175301

    T.S.Murali
    Member

    Hi Venu,
    The idle time and downtime are different. Let us consider the following:
    a)  machine in a shift of 8 hours (480 minutes).
    b) out of this 480 minutes, the actual working (productive) time of the machine is 300 minutes which helped to the production the machine is intended for. This could include material loading / unloading time. Ideally it is also the operator time spent productively.
    c) In the balance 180 minutes, there could be 100 minutes due to Downtime of the Machine. For e.g. maintenance on the machine or breakdowns of the machine or even power trip etc. That is the downtime is attributed to the machine itself.
    d) Then balance 80 minutes is due to Idle Time. That is Neither the machine is working nor it is under maintenance / breakdown. The idle time is due to waiting for operator, operator not working, operator taken a break, operator tea time, operator doing nothing except just standing near the machine etc. This idle time can’t be attributed to Machine, since there is no problem in the machine.
    I hope it clarifies the issue.
     
     
     
     

    0
    #175308

    Craig
    Participant

    Venugopal G
    I see alot of good discussion about measuring OEE and similar indicators. I still feel it is important to point out that GRR is simply the wrong tool to quantify real versus reported values. If that is truly what you want, then you are looking at Bias, not R&R.
    For bias, you have to somehow know the true value of down times and compare with reported. As another poster indicated, you should probably set up camp and conduct a time study.

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

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