RFC反应流程图.ppt

反应流程图 Response Flow Checklist,PCS Elements,Create Measurement Plan,Establish Monitor(SPC),Implement Response Flow Checklist(RFC),Element 1,Element 2,Element 3,Contents,IntroductionWhat is an RFC?Benefits of Using an RFCWhen Should an RFC be Used?Developing an RFCDocumentation of RFC ResultsRFC Storage and RetentionRFC Continuous Improvement GuidelinesRFC Expectations,What is an RFC?,A document to contain suspect product and return the process/equipment to a productive state as quickly as possible.Composed of defined set of tasks(action items)to be performed in specific orderRequires certain decisions to be made to find solution to the problem and therefore may lead to two or more different solutions depending on the scenario.,RFC Structure,”Diagnosis activities are used first to determine the cause of the process instability.For each possible cause,there is a set of remedy activities that are used to fix the problem once the cause has been determined.”Verification activity is the final step.It is performed to make sure that the process problem has been fixed.,Example of an RFC(Flowchart Type),Exposed Copper Monitoring RFCSpec xx-xxxx,Benefits of Using an RFC,Identifies cause of process or equipment failuresControl charts and SPC trend rules tell us only when the process is out-of-control,not why it is out-of-control.They cannot tell us what to do to fix the problem,either.For that,we need the RFC.Leads Mfg Technician/Specialist through steps in solving the problem in the quickest possible timeMinimal need for Engineering involvementDocuments problem cause and resolution history,When Should an RFC be Created?,Statistical process control When an out-of-control(OOC)condition occurredProduct quality and yield controlWhen questionable products are detected at any stationWhen low yielding lots are seen at any stationProcess/Equipment failureFor restoring a machine to production after it has been shut down due to a process/equipment related failure,RFC Model,Who Develops the RFC?,Initiated and led by the process or equipment owner(e.g.,Module Engineer)in a team environmentRFC Development Team should include the following:Process/Equipment EngineersProduct EngineersQ&R EngineersMaintenance TechniciansManufacturing personnelShift Managers,Mfg Supervisors,MS/MT/OperatorStatisticiansContent experts,RFC Development Flow,Step 1:Brainstorm potential causes,Using a Fishbone diagram,brainstorm all the possible causes of out-of-control signals for the process step.Consider 5M+E factors.Use any existing data or experience on causes of out-of-control incidents.Augment the list with all applicable causes from other existing RFCs for similar parameters.Dont forget to include some of the less obvious ones,such as gauge instability,calculation errors,or plotting errors.Use FMEA when available.,Step 1:Brainstorm potential causes(cont),Example:Problem:Missing unitsPotential causes:Incomplete lot identifier Improper staging of lot Counting SOP violation Equipment jamming Wrong information on ticket,Step 2:Assess likelihood and ease,Establish basis for initial ordering of potential causesLikelihood of being the cause of the problemEase of checkingUse Likely/Ease matrixScore each potential cause on a scale of 1 to 5Do not consider difficulty of fixing the problemFor each potential cause,add Likelihood and Ease scores to get an overall score,Example:Missing units Likely/Ease Matrix,Scale:Likely1-Likely to be the cause 5-Unlikely to be the causeEase1-Easy to check 5-Difficult to check,Step 2:Assess likelihood and ease(cont),Step 3:Create overall RFC process flow,Rank each potential cause according to its total Likely/Ease score(i.e.,lowest total score has highest priority).Examine the prioritized list for logical ordering and grouping.Similar problem causes can be investigated simultaneously or in combined actions.Avoid redundancy.Actions should be grouped by users:MS/MT/Operator,Technician,Engineer.Examine the ordering from other existing similar or related RFCs.One suggestion is to start with calculation and plotting error checking.Next should be measurement procedure/equipment checking.It is best to rule out possible data/plotting/measurement errors first,before we tamper with the machine or process itself.If the FMEA has been used as a basis in Step 1,the FMEA occurrence number should also be used as a reference in assigning likelihood and ease scores.,Step 3:Create overall RFC process flow(cont),Example:Missing units Initial flow based on Likely/Ease overall score:1.Incomplete lot identifiers highest priority2.Counting SOP violation3.Improper staging of lots4.Equipment jamming5.Wrong information on tickets lowest priority,EXERCISE 1,In groups of 4 to 5 people:Identify a problem common to the groupCreate an initial RFC using Steps 1 to 3Choose a reporterPresent to the class after 20 minutes,Definition of Terms,ACTION-specific instructions telling the RFC User what tasks to perform nextAvoid redundant actions,be specificClarify ownership of the actionCluster ownership of actions,avoid bouncing between ownersDATA-information collected by the RFC UserIncludes observations and measurements,Definition of Terms,QUESTION-requires the RFC User to evaluate the data against specific criteriaUse questions that require yes/no responseAvoid subjective questionsRESPONSE-what action should the RFC User take based on the evaluation of the dataEnsure all responses lead to an action,Step 4:Create detailed RFC process flow,List all steps required for the following:Determine if potential cause existsFix potential causeTest and verify fixUse flow diagram to communicate the logical flow of the RFC.When creating flow for fixing the problem,Utilize synergy from other RFCs in wording and descriptions.Actions must be absolutely clear.Avoid ambiguity.The decision flow may stop when all Operator-verifiable causes have been exhausted.Many checklists may continue through Technician-verifiable(or even Engineer-verifiable)causes as well.Examine the overall decision flow for completeness and logic.Check for infinite loops and dead ends.Modify if needed.,Example:Missing units,Step 4:Create detailed RFC process flow(cont),Step 5:Compose the RFC,Translate the detailed flow created in Step 4 into an RFC draft.An action for verifying if process/equipment is up for production when a final solution is achieved should always be included in the RFC.Include instructions for re-starting the process.If the accept criteria specified in the verification procedure have been satisfied,it is safe to assume that the problem has been solved.Otherwise,it must be assumed that the problem has not yet been fixed.If out-of-spec processing could have occurred,the RFC may reference the applicable spec or disposition procedures.However,the disposition procedure should not appear in the RFC.Verification of process/equipment status can be done in two ways:Run a certain number of unitsUse 2-sigma limit rule,Step 5:Compose the RFC(cont),Running a certain number of unitsQuantity to be processed for verification is determined by the RFC Development Team and should be specified in the RFCVerification/monitoring should be required after running the units to determine whether to resume production or not.,Step 5:Compose the RFC(cont),2-Sigma Limit RuleIf next control chart point is within 2-sigma limits,it is safe to assume that the problem has been solvedAll succeeding control chart points will follow the standard 3-sigma limit ruleOtherwise,it must be assumed that the problem has not been fixed and continue using the RFC to diagnose and fix the problem,Step 5:Compose the RFC(cont),The last RFC action should state whether the RFC was successful in finding the problem cause.It describes final engineering actions taken when the RFC is not successfulDesignates that the action owner is the EngineerIf applicable,it instructs the Engineer to return the RFC to the MS/MT/OperatorUse the hexagon toolExample:,Step 5:Compose the RFC(cont),The RFC Development Team is responsible for determining if the RFC actions taken need to be documented for passdown and traceability purposes.For RFC actions taken that need to be documented:Create a cover sheet only if requirement is paper-based documentation.The following information are required to be supplied by the primary RFC User if applicable:equipment number,lot numbers affected,lead count,date/shift/time problem was encountered,Employee ID of MS/MT/Operator and/or Technician.The cover sheet should contain required RFC instructions as well as include RFC trigger point,i.e.,when to use the RFC.If electronic documentation(e.g.,automated RFC tool,EDC)is required,it should capture the same information as listed above.,Example of an RFC Cover Sheet,Example of a Flowchart RFC(Column Type),Example of a Flowchart RFC(Conventional Type),EXERCISE 2,Using the same grouping as in Exercise A:Complete the RFC flow following Steps 4 to 5Choose a reporterPresent to the class after 20 minutes,Step 6:Development Team Review,Review the RFC to ensure correctnessReview for logic,typographical and other errors,clear and consistent wording,ease-of-use,correct formatting,infinite loops,and dead ends.,Step 7:Publish the RFC,Incorporate RFC into a spec and publishThe entire RFC should be documented within the module operating spec or as an attachment.Conduct RFC training to all users and stakeholders,Documentation of RFC Results,If requirement is paper-based documentation:For every action item completed,RFC User toSign outside of the tool diagram for a flowchart type RFCSign outside of the“Initial”column for a tabular type RFCWhether requirement is paper-based or electronic documentation,RFC User should document the last RFC action completed and corresponding corrective actions.Example:In paper control charts,documentation is written on the back of the chart together with comments for the OOC points.In EDC,documentation is done in the Annotation portion of the EDC screen.,RFC Storage and Retention,Manufacturing,or whichever group the primary RFC User belongs to,is responsible for creating a storage and retention system for documented RFC actions.Retention period for documented RFC actions must be defined.,RFC Continuous Improvement,RFC has to be reviewed periodically for improvement on documented periodic basis or whenever there is any change in the process/equipment.Check effectiveness of defined RFC action itemsEvaluate performance of machine affectedReview overall RFC usageAssess success of RFC in finding the problemRFC Owner is responsible for reviewing the RFC.RFC must be revised/updated when found to be ineffective or insufficient during the review.,Continuous Improvement Guidelines,Check effectiveness of defined RFC Action ItemsMake a frequency chart to show how many times the RFC stopped at each action item.Does a high frequency Last Action Completed indicate a processing,procedural,or equipment change is in order to prevent the problem?Should a specific Action be moved closer to the front of the RFC?Does the problem description and solution listed under the Last Action Completed accurately reflect the actual problem and what was done to resolve it?,Continuous Improvement Guidelines(cont),Evaluate performance of machine affectedDoes the same machine#have all or most of the problems?Are the problems spread equally among all the machines?Look if there are time patterns.What do these indicate?Example:Do most of the RFCs in March stopped at Action C?Do most of the RFCs from Shift 1 stopped at Action E?,Continuous Improvement Guidelines(cont),Review overall RFC usageIs it time to remove“never used”Action Items from the RFC?Could process improvement be made based on the RFC data?Does the report highlight something that should not be part of the RFC?,Continuous Improvement Guidelines(cont),Assess success of RFC in finding the problemHow many times where the MS/MT/Operator successful in bringing the process/equipment“back up to production”without Engineering assistance?%Effectiveness=100*(#of RFC fixes by MS/MT/Operator)Total#of RFCs usedCan some skills/responsibilities be transferred from MS/MT/Operator to Engineering or vice versa?Does the RFC work successfully?Do new Actions need to be added in the RFC?,RFC Expectations,RFC development should be initiated by the process or equipment owner in a team environment.Formation of a cross-functional team(Process/Equipment Engrs,Product Engrs,Q&R Engrs,Statistician,Technicians,and Mfg personnel)will facilitate the development of a more robust RFC.RFC is required for all out-of-control(OOC)situations.There should be a defined retention period for documented RFC actions taken.RFC should be reviewed periodically by the RFC Owner for improvement on documented periodic bases or whenever there is any process/equipment change.,