And we would have to document each usage of the standard repair process and analyze for trends. On Thu, 16 May 2013 07:14:29 -0500, Blair Hogg <[log in to unmask]> wrote: >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] >>______________________________________________________________________