From my old Mil-Q-9858 and Mil-Std-1520 days I remember that the defeinitions we used were that rework would leave the item indiscernible from original manufacture, while repair would bring the item to a usable state, however, one could tell upon inspection that it wasn't originally intended to be manufactured in that manner. Repairs were normally actions that had to be approved via a Materials Review Board, which was typically representatives from Engineering, Quality, Manufacturing Engineering, and, in many cases, a customer represntative. MRB actions had to include a corrective action statement as to why the defect occurred and what actions would be taken to minize recurrence.
If a MRB repair process was defined well it could be approved as a Standard Repair process and allowed to be used repeatedly without MRB approval.
I suppose that if you get 6 people in a room you might get 8 different opinions as to how repair could be defined.
Blair
On Wed, 15 May 2013 17:32:46 -0400, Bob Landman <[log in to unmask]> wrote:
>Exactly my thoughts.
>
>Having just spent considerable time at our assembler dealing with boards that did not test ok due to a variety of pick & place and solder paste problems,....
>
>To me they required rework, not repair.
>
>Repair, to me, implies that at a point in time the assembly did power up and test ok.
>
>Rework covers a multitude of sins in assembly.
>
>Bob
>
>Sent from my iPhone
>
>On May 15, 2013, at 4:32 PM, Ahne Oosterhof <[log in to unmask]> wrote:
>
>> A repair is due to damage. Rework is due to assembly error.
>> A thought from Mike Bogden, Engineer
>>
>> My follow up on that thought: "Rework" is "Repair waiting to be needed".
>> ===
>>
>> Why wait for a "standard" to do tracking of rework and repair? The
>> requirement exists in-house.
>> The better you track both of these, the better and quicker you can fix these
>> problems in order to improve quality and bottom line.
>> It helps if you determine the cost of each individual of these problems so
>> that you can tackle the most costly ones first. And cost should include time
>> to analyze cause of the problem, determining frequency of problem, cost of
>> component involved, cost of time lost, maybe even the cost impact of field
>> failures (hard to put a number on).
>>
>> Ahne.
>>
>> PS: I have stated before: some people are very proud of their rework
>> department, but should not be of the fact they need one.
>>
>>
>>
>> -----Original Message-----
>> From: TechNet [mailto:[log in to unmask]] On Behalf Of Stadem, Richard D.
>> Sent: 15 May, 2013 06:53
>> To: [log in to unmask]
>> Subject: [TN] Trend Analysis of Repair Usage
>>
>> I am trying to find out if there is an industry requirement or
>> recommendation that usage of Repair Procedures be tracked and monitored? I
>> could not find any information on this in IPC-7711/7721. In previous lives
>> the number of repair usages was tracked, and pareto was published quarterly
>> (number of repairs used versus number of total CCAs built, number of repairs
>> used by a given CCA part number, number of repairs associated with a given
>> component part number, etc.) .
>> Because repairs are infrequent, it is not easy to detect any trend in their
>> usage, but over time the trend analysis can provide good data to detect root
>> causes.
>> I just want to know if there is any industry standard that covers this.
>> I am talking about repairs, not rework. If you don't know the difference
>> please do not respond.
>> Thanks
>> dean
>>
>> This message and/or attachments may include information subject to GDC4S
>> S.P. 1.8.6 and GD Corporate Policy 07-105 and are intended to be accessed
>> only by authorized recipients. Use, storage and transmission are governed by
>> General Dynamics and its policies. Contractual restrictions apply to third
>> parties. Recipients should refer to the policies or contract to determine
>> proper handling. Unauthorized review, use, disclosure or distribution is
>> prohibited. If you are not an intended recipient, please contact the sender
>> and destroy all copies of the original message.
>>
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please contact helpdesk at x2960 or [log in to unmask]
>> ______________________________________________________________________
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please contact helpdesk at x2960 or [log in to unmask]
>> ______________________________________________________________________
>>
>
>______________________________________________________________________
>This email has been scanned by the Symantec Email Security.cloud service.
>For more information please contact helpdesk at x2960 or [log in to unmask]
>______________________________________________________________________
|
