There's a nice definition given for "rework" and "repair" in Paragraph 1.4 of the IPC-7711/7721.
Ben
-----Original Message-----
From: TechNet [mailto:[log in to unmask]] On Behalf Of Blair Hogg
Sent: Thursday, May 16, 2013 8:14 AM
To: [log in to unmask]
Subject: EXTERNAL: Re: [TN] Trend Analysis of Repair Usage
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]
>______________________________________________________________________
______________________________________________________________________
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]
______________________________________________________________________
|
