Key Input Variables for Warranty
Six Sigma – iSixSigma › Forums › Old Forums › General › Key Input Variables for Warranty
- This topic has 9 replies, 6 voices, and was last updated 15 years, 1 month ago by
Taylor.
-
AuthorPosts
-
December 29, 2005 at 2:44 pm #41848
I recently started work for a corporation that has no control over their warranty process. The data they are collecting is only financial in nature to see what hits the bottom line, nothing to get me to root cause. I am considering developing a warranty database to collect data useful enough to drive at root cause. Can anyone help me with identification of the key input variables other than the obvious (part number, date of sale, date of claim, etc.)
I am really interested in what other companies are collecting out there? Maybe a sample form…absent data of course. Is there software out there to purchase for warranty management that anyone can recommend. Thanks in advance.0December 29, 2005 at 3:34 pm #131684I think you have to take a look to CRM systems or module available and check which fits better your needs. It depend by your business, company size, system used, etc… Just some know names: SAP, Siebel, etc.. About which data you need/use it depend by your warranty process (are you in consumer, professional, medical ?) but I think you are in a good position, because if your company haven’t it, you can set it starting from your warranty Key point.
Rgs, Peppe0January 9, 2006 at 8:05 am #132055
R.M.ParkhiParticipant@R.M.ParkhiInclude @R.M.Parkhi in your post and this person will
be notified via email.Dear Sir,
The real method of warranty anlysis is to collect samples representing various modes of failures with period of failures.
Analyse to find out the failure modes.Now you know the failure modes & time for failures.
Plot for every failure mode on Webull plot & clculate beta & eta values.For beta less than 1, mostly it is due to quality & manufacturing; for beta equal to 1, pl. study the operating conditions on the field.For beta more than 3, it is a wear-out failure & needs to be addressed with design relook.
It is very essential that , you have to have failed samples for engg. analysis.
After this do accelerated testing, still better Meost, to reproduce the failure to confirm your analysis.
I think to reduce the field failures or to eliminate the same,this method,which I have followed in many companies, has delvered the results.
Pl. ask if you have any queries.
With regards,
R.M.Parkhi from India
0January 9, 2006 at 2:26 pm #132070
Tseumogne NoumodjeParticipant@haroldInclude @harold in your post and this person will
be notified via email.Riley,
I am working a warranty-related Black Belt project right now. Please email me directly for a deeper discussion. I can share with you the context of the project and the data-point types that I am collecting. I have 5 months of data covering over 1000 warranty returns.
Sincerely,
Harold Timms
6-Sigma Program Manager0January 9, 2006 at 2:26 pm #132071
Tseumogne NoumodjeParticipant@haroldInclude @harold in your post and this person will
be notified via email.Riley,
I am working a warranty-related Black Belt project right now. Please email me directly for a deeper discussion. I can share with you the context of the project and the data-point types that I am collecting. I have 5 months of data covering over 1000 warranty returns.
Sincerely,
Harold Timms
6-Sigma Program Manager0January 9, 2006 at 4:00 pm #132083Before you go to far down the road of creating a database…You might want to gather a cross functional team (from warranty processors to engineers) and brainstorm different things that could affect failures that would cause warranty (Fishbone). From that, manually collect data around the ideas and prove/disprove them. On the proven ones, work the rest of Improve on them. Once you have them worked on, put the database in place as part of the Control phase, to monitor that your fixes stay fixed. Given the time/money/effort to put in a database, this would make sure that what you put in place is gathering what you need to gather AND you would have made improvements
0January 9, 2006 at 4:30 pm #132091Before you go to far down the road of creating a database…You might want to gather a cross functional team (from warranty processors to engineers) and brainstorm different things that could affect failures that would cause warranty (Fishbone). From that, manually collect data around the ideas and prove/disprove them. On the proven ones, work the rest of Improve on them. Once you have them worked on, put the database in place as part of the Control phase, to monitor that your fixes stay fixed. Given the time/money/effort to put in a database, this would make sure that what you put in place is gathering what you need to gather AND you would have made improvements
0January 11, 2006 at 3:00 pm #132200Before you go to far down the road of creating a database…You might want to gather a cross functional team (from warranty processors to engineers) and brainstorm different things that could affect failures that would cause warranty (Fishbone). From that, manually collect data around the ideas and prove/disprove them. On the proven ones, work the rest of Improve on them. Once you have them worked on, put the database in place as part of the Control phase, to monitor that your fixes stay fixed. Given the time/money/effort to put in a database, this would make sure that what you put in place is gathering what you need to gather AND you would have made improvements
0May 1, 2006 at 12:48 pm #137039
R.M.ParkhiParticipant@R.M.ParkhiInclude @R.M.Parkhi in your post and this person will
be notified via email.Dear Sir,
I am very much interested in Warranty Analysis.
I think we can have a dialogue on regular basis.
You may contact me at my email address.
Regards,
R.M.Parkhi0July 20, 2007 at 9:43 pm #158899I realize this post if very old – but I am new to this field and am responsible for setting up a warranty process. Any help is appreciated.
0 -
AuthorPosts
The forum ‘General’ is closed to new topics and replies.