Organizational Best Practices for FRACAS Implementation: Management Considerations when Developing and Deploying a Corrective Action System

P T C . c o m White Paper Relex — A PTC InSight Product Page 1 of 7 Organizational Best Practices for FRACAS Implementation: Management Considerat...
0 downloads 1 Views 954KB Size
P T C . c o m

White Paper

Relex — A PTC InSight Product

Page 1 of 7

Organizational Best Practices for FRACAS Implementation: Management Considerations when Developing and Deploying a Corrective Action System Introduction To produce high quality products in an increasingly competitive marketplace, the ability to efficiently discover, track, and correct incidents or failures found during product development, testing, and operations is crucial. This need spans all industries and classifications, including hardware and software production, process management, and services in both government and commercial sectors. A survey conducted by the Reliability Information Analysis Center (RiAC) cited that companies view this subject, most commonly referred to as FRACAS (Failure Reporting, Analysis, and Corrective Action System) to be among their top two most important reliability tasks. Manufacturers and service providers have employed a variety of methods for tracking product failures and managing corrective actions. These can range from so-called “manual” approaches using paper-based intake methods and handwritten forms, to a combination of electronic spreadsheets and personal databases, to large enterprise systems that affect hundreds or thousands of customers, suppliers, and engineers worldwide. Conceptually, it is easy to understand the need for and the benefits of a failure tracking and corrective action system. However, implementing an efficient and effective system that yields an end result of more reliable products and improved designs is complex. A wide range of factors must be considered by organizational management and those responsible for directing and implementing the FRACAS company-wide to ensure the best possible outcome. Since its inception in the 1970s as part of the United States Department of Defense (DoD) regulations, efforts have been made to define structured approaches and guidelines for the implementation of failure reporting, analysis and corrective action systems. Organizations such as RiAC, in accordance with the DoD, have studied the requirements of both large and small companies to develop general guidelines for a FRACAS. In addition to the RiAC guidelines, other efforts on this subject have been published for public use, including SEMATECH’s “Failure Reporting, Analysis and Corrective Action System” Planning and Implementation Guide and NASA’s “Preferred Reliability Practices, Problem Reporting and Corrective Action System” documents. Nevertheless, the implementation of a cost-effective FRACAS that produces an end result of more reliable products remains a complex and challenging undertaking. These publicly available guidelines fail to address many of the practical complications that exist. These complications are neither process-related nor technical in nature, but stem from each company’s organizational structure, goals, and expectations.

White Paper

Relex — A PTC InSight Product

Page 2 of 7

1. What is a FRACAS? A FRACAS, or Failure Reporting, Analysis, and Corrective Action System, is a closed loop system used to improve the reliability of a product, service, process, or software application. The “closed loop” in a FRACAS refers to the systematic manner in which every issue that is reported is addressed, ensuring that no failure or incident is missed. The need for a FRACAS spans all industries and classifications, including hardware, software, process management, and services in both government and commercial sectors. Software-based FRACAS processes offer the added benefit of built-in analytical capabilities, allowing organizations to track key system metrics that include Failure Rate, MTBF, MTTR, Availability, Cost, and user-defined calculations, among many others. Built-in reporting and graphing features mean these metrics to can be trended with regards to time, severity, and many other factors. In addition, the effectiveness of the FRACAS itself can be monitored by tracking the overall improvement of the system as a result of the FRACAS. FRACAS is used extensively in the following industries: Aerospace, Automotive, Defense, Electronics, Manufacturing, Telecommunications, Medical Devices, and others. While a corrective action system is commonly referred to as a FRACAS in many government-related initiatives, it may be referred to by other names in other industries, including a CAPA (Corrective and Preventive Action) System, Corrective Action System, Quality System, and others where the first letter of the FRACAS acronym is replaced by a “P” for Problem (PRACAS), an “I” for Incident (IRACAS), or a “D” for Data or Defect (DRACAS). In addition, FRACAS can be applied for RMA (Return Materials Authorization or Return Merchandise Authorization) processes and various other quality assurance processes, like bug tracking, call centers, and the like. How is a FRACAS Performed?

While the specifics of how each FRACAS process is implemented will vary, a FRACAS usually includes the following steps: • Record the Failures or Incidents: Using a database management system and an established procedure, critical data associated with each failure or incident is recorded, and the process is initiated • Analyze the Reported Failures or Incidents: Using the same database management system into which the failure or incident data was entered, established procedures are used to determine and record the root cause of the failure or incident • Identify Necessary Corrective Action: Using the same database management system to track its development, implementation, and result, a corrective action plan must be developed and implemented to reduce or eliminate the reoccurrence of the failure or incident • Review and Verify the Corrective Action: The effectiveness of the corrective action must be reviewed and recorded, using the same database management system, and the incident closed out per established procedures

An effective FRACAS ensures that all failures or incidents proceed through these four major steps: “closing the loop” to ensure that no failure or incident is missed.

What are the Limitations of a FRACAS?

Although implementing a FRACAS can be an excellent way to improve a product, service, or process, its inherent limitation is that it can be difficult to apply effectively. As with any technique, it is critical that a FRACAS process is well planned and efficiently executed; otherwise, the system could fail to manage data effectively, fail to identify the root causes of problems, or fail to close the loop in the FRACAS process. For that reason, the Relex team, which has deployed numerous FRACAS systems in organizations throughout a variety of industries, presents the following practical guidelines for managers and others responsible for the development and implementation of a successful FRACAS system.

2. FRACAS Best Practices While the general closed loop corrective action process seems to follow a common sense approach, many factors can make the application of a FRACAS difficult. Because of these potential challenges, the following best practices are strongly recommended for use during FRACAS implementations. Set Expectations and Goals

Prior to deploying the FRACAS corrective action system, it is essential to set the expectations and goals of the system. Identifying the purpose and goals of the FRACAS, as well as identifying the roles and responsibilities of all stakeholders in the process, is essential. It is also critical that all stakeholders in the process understand and agree upon the established expectations and goals of the system. Involve the Stakeholders

It is of the utmost importance that all stakeholders in the FRACAS are involved in and supportive of the process. The stakeholders will include many within the organization and may also include customers and/or suppliers. By involving all stakeholders, support may be gained for acquiring sufficient failure data, and a common process can be achieved across the whole organization and outside entities.

White Paper

Relex — A PTC InSight Product

Page 3 of 7

“A survey conducted by the Reliability Information Analysis Center (RiAC) cited that companies view a FRACAS to be among their top two most important reliability tasks.”

Gain Active Management Involvement

Management involvement and support can significantly impact the success of the FRACAS. Active management participation often results in obtaining and maintaining necessary funding and resources, and may very well provide the leadership needed to implement and maintain a successful FRACAS. Keep the Process Simple

The most successful FRACAS processes are easy to use, employ userfriendly software tools to automate the workflow, and require modest investments in resources and training. By keeping things simple, it is more likely that those outside the quality/reliability functions will participate as required. Ultimately, it is important that the FRACAS be simple enough to work well for both the expert and novice. Of course, it is also important that the process is designed to allow for a thorough and effective FRACAS.

3. Apply Best Practices to Common Challenges The best way to observe the benefits of these best practice approaches is to see the ways in which they help overcome the challenges that organizations commonly experience when implementing a FRACAS. Each of the following Challenge / Solution scenarios demonstrates the benefits of a best practice approach to FRACAS implementation: Challenge 1: Complex Organizational Interactions

A proper FRACAS process can span many different functional groups within an organization. Data is contributed by and/or needs to be made available to the following groups: • Manufacturing

• Quality Assurance

• Operations

• Customer Service

• Reliability

• Field Services

• Sales and Marketing

• Suppliers

Leverage Software Tools

• Testing

• Maintenance

Utilizing available software tools is one key way to help automate the FRACAS and make it easier to use. Software tools can help automate data entry, data analysis, and data output, while providing a central storage area for critical FRACAS data and results.

• Failure Review Board (FRB)

• Management

• Engineering

• Others

Provide for Efficient Data Entry and Analysis

The collection and analysis of FRACAS data can be two of the most time-consuming tasks for a FRACAS. Easy to use Web-based forms are often a great way to provide for efficient data entry. Automated calculations, graphs, and reports, along with the ability to filter data, can increase the efficiency and effectiveness of data analysis. Supply Training

Even when a simple FRACAS process is implemented, providing comprehensive training early in the implementation process can alleviate the concerns of those involved and help make them active participants in the FRACAS. As feedback is accepted and the FRACAS evolves, it is a good idea to provide additional training in the more advanced technical and software-related aspects of the process. Encourage and Offer Feedback

Encouraging feedback from the users of the FRACAS can help those in leadership roles adjust the FRACAS to become more efficient and effective. Likewise, providing feedback to all participants, including feedback in the form of outputs from the system, can be encouraging, as it can demonstrate the positive, tangible results of the efforts of all who have adapted to and successfully implemented the FRACAS.

With all of these different groups involved in the process, the interaction across and between various groups can become quite complex. Some groups may need to be included at multiple points throughout the workflow. This increases and complicates the steps required to close out an incident. Consider the following scenario: A simple process is defined such that a field service representative reports or logs an incident. Quality Assurance reviews this incident and then assigns it to the Reliability group to perform a root cause analysis. The Reliability group then recommends a corrective action that the Engineering group implements. Finally, the Failure Review Board approves the corrective action and closes out the incident. Over time, additional groups may request to be involved. For example, Customer Service believes that they too need to be involved at the corrective action step in the process. Because they directly interface with the customer, they want to understand and possibly shape the corrective action response that may occur. Sales and Marketing may also need to be involved to properly manage a customer’s account. And, a Supplier may wish to be involved in the analysis and corrective actions that have occurred with its parts. Very quickly, the number of groups involved increases, and the process becomes more complex. This may result in a long cycle time between the opening of an incident and its eventual closing. If the process is too complex, incidents can become “forgotten” and never worked through to completion.

White Paper

Relex — A PTC InSight Product

Page 4 of 7

Solution 1: Overcoming the Challenge of Complex Interactions

While working with the stakeholders in the planning phases of a FRACAS, identify the simplest workflow possible while still keeping everyone involved at key steps in the process. Whenever possible, automate communication. This way, all groups that need to be aware of the status of an incident can be notified easily. It is generally helpful if each functional group has a key contact person who may attend FRACAS planning meetings and communicate important information to the functional group. Regular FRACAS process review meetings involving all key stakeholders from the various functional groups can be helpful. These meetings can decrease in frequency over time. And, of course, before the final FRACAS is deployed, make sure that all stakeholders have signed off on the proposed communication plans to ensure you can overcome the challenge of complex organization interaction. Challenge 2: A Lack of Prioritized Goals

Consider the following scenario: a customer contract specifies that a FRACAS system be utilized for a particular project. But due to financial constraints, the resources are lacking to complete a fully featured FRACAS implementation. Project managers implement a temporary Microsoft® Excel®-based or Microsoft Access™-based solution, fully intending to replace this solution in the future with a more substantial system. But a fully featured FRACAS never materializes. Consequently, a minimal FRACAS system becomes the standard, resulting in poor efficiency and a lack of cohesiveness.

Involving all stakeholders in the FRACAS workflow: Each group in an organization has different roles in the FRACAS. The goal in designing a FRACAS is to accurately capture each group’s role and to ensure that software processes carry this workflow through to each required member automatically. Web-based communication technology like that found in Relex FRACAS can help ensure that every incident is addressed: effectively "closing the loop".

In another example, a company believes that a FRACAS is important to the success of a product but sees it as something they will get to in the future. As the product lifecycle progresses, the company gains an appreciation for the necessity of a FRACAS. By this time, the company is far past the point of the budgeting and planning processes. Therefore, a proper implementation does not occur and teams are left scrambling late in the project to find resources to implement a FRACAS. Once again, a minimal FRACAS system is implemented. In a third example, an executive management team has high expectations for the system. They envision that the FRACAS will save the company money on warranty costs; while the reliability group expects significant data that can be used to discover trends and improve a product’s design over time. Unfortunately, because the program manager is provided with minimal financial resources, she can only implement a basic FRACAS. The system is not deployed early enough to sufficiently track information, which limits the data available to executive management and to the reliability group. It will take some time for the data to be complete enough to perform a meaningful analysis. The result is a system that falls short of everyone’s expectations. What caused the problems in these examples? First, goals and expectations from the various groups were not discussed and prioritized in relation to each other. Second, there was no objective FRACAS leadership across the groups. And, finally, effective executive sponsorship verifying and tracking the goals was nonexistent.

White Paper

Relex — A PTC InSight Product

Page 5 of 7

Solution 2: Overcoming a Lack of Prioritized Goals

To overcome the problems that result from the lack of prioritized goals, use best practice principles. First, the goals and expectations of the FRACAS should be discussed and agreed upon by all stakeholders, including management. It is also helpful to obtain objective FRACAS leadership so that all stakeholders’ goals may be considered in the planning. Also, determine which goals can be accomplished well by the FRACAS as it has been designed, and make sure all stakeholders have signed off on and agreed to these planned and prioritized goals.

Streamlining Data Entry and Data Tracking: By entering a single identifier, such as the serial number of a returned product, as shown above, Relex FRACAS uses lookup table functionality to autopopulate the remaining fields.

Challenge 3: Ineffective Data Tracking

The key to ensuring a FRACAS is effective is to gather and report meaningful data. This seems to suggest that the more data an organization can gather regarding an incident or failure, the better its FRACAS will be. But this is not necessarily the case. Too much data may prevent companies from discovering meaningful trends. For example, many legacy FRACAS systems collect 80 or more fields of information when recording a failure. Although much of this data is valuable, gathering too much data can result in several problems. For example, suppose it takes customer support personnel five seconds to enter data into each field. They will spend 400 seconds or 6.6 minutes filling in all 80 fields, not including research time, resulting in a general feeling that it is just too time consuming to fully log a problem. Fields are routinely skipped and some issues are not even reported because it is too much trouble. To prevent this, designers develop input screens that will easily accept incident information. However, as is often done, designers utilize free flowing text fields to allow customer support personnel to type any information that they think is useful. The personnel can then become confused, and do not always know what to enter. Consequently, they begin to include extraneous or irrelevant data and sometimes just leave the field blank. Not only is it difficult to perform any meaningful analysis with the resulting data, but it also becomes a tedious manual process to review each individual incident in search of trends. Solution 3: Effectively Managing Data

To avoid the problems of inefficient and ineffective data tracking, organizations should establish functional procedures before data collection begins. Using simple, streamlined forms which store data in a central database is often the best approach. Training the FRACAS users responsible for data entry helps ensure that all important data is entered correctly and efficiently. It is also helpful to remind those responsible for entering failure data of the importance of capturing the data at the time of failure, and the long term benefits to the organization that can result from timely data capture. Whenever possible, employ automation when capturing the failure data.

4. Steps to a Successful FRACAS These three common challenges to FRACAS implementations are by no means all-encompassing, but they do outline typical problems that prevent companies from realizing the dramatic results that can be achieved with a successful FRACAS. To help avoid these common obstacles from the outset of planning a FRACAS, the following eight steps are recommended: Step 1: Define the Goals and Success Factors

Defining the goals of all intended users and stakeholders is the foundation for a successful FRACAS. Every step in the process of implementing a FRACAS will be based upon these goals. Ensuring these goals are understood and agreed upon by all is key before implementing the FRACAS. A mistake or misunderstanding at this step can have negative consequences later. Because issues may not become known until months later, it is important to commit to a thorough job of researching and documenting everyone’s goals and the rationale behind them. To begin this process, hold a series of short team meetings with each of the groups and stakeholders with a role in the FRACAS. Map out each group’s specific goals and expectations for the FRACAS. Typical goals include lowering maintenance costs, improving overall reliability, and improving next generation product design. Be careful to avoid the common pitfall of moving off of goal establishment and into detailed requirements. The purpose of this exercise is for each group to come to a consensus on the priority of its primary goals. Step 2: Define the Output

With goals and success factors in place, it is time to define the results or outputs that each group is expecting from the FRACAS system to achieve the success factors that were outlined in the group’s agreedupon goals. Typically, the results are stated in terms of calculations, charts, graphs, and reports. For example, the Reliability group may need a Pareto chart indicating the number of failures by part number. The Field Service group may require a report indicating the cost of warranty repairs by part number. The Quality group may require a reliability growth chart.

White Paper

Relex — A PTC InSight Product

Page 6 of 7

A common pitfall is that each group will want as much output as possible, resulting in a bloated “wish list” that is difficult to reasonably implement. The purpose of this exercise, however, is to focus on what is absolutely necessary for success based on previously established goals. To help with this, map each output requirement back to a goal and success factor. Step 3: Map the Process Workflow

Through a series of meetings and interviews with stakeholders, discuss what process or workflow they expect to follow. Most of the groups will focus on their own internal processes but may not understand the overall process as it relates to all groups with a role in FRACAS. Based on each group’s individual input and through additional investigation, develop a consolidated process diagram. Using this diagram, search out inefficiencies and actively find ways to simplify the process. Involve stakeholders in simplifying and coordinating the process steps between the groups. Question any step that does not produce the output requirements established previously. Also, work to ensure that the overall process is not too lengthy or complex. Remember that many steps can slow the resolution of incidents or decrease the ability to report trends in a timely manner. Changes to the overall process are inevitable, but this step establishes a workable starting point.

Determine a workflow for the FRACAS: Ensure that roles of all stakeholders involved in the process are properly represented, as in this RMA (Return Materials Authorization) workflow.

Step 4: Map the Required Data and Input Method

Using the process diagram and the output requirements, determine the minimum data fields required to support the workflow process at each step. Investing time in this step helps eliminate the problem of collecting data with no direct purpose, and can help focus users' efforts. After the data fields have been established, determine how the data will be viewed by the user. It may make sense to show one large form with all of the data fields. Or, it may be better for each group to have specific forms with specific fields displayed so that their view of the data is limited for ease of understanding. Involve the stakeholders to understand what they are expecting and why. Additionally, specify how the input data will be gathered. Recall, from Challenge 3 above, that it is important to collect valid, meaningful data in an efficient manner. Popular methods include lookup tables to populate fields based on previous input, drop-down menu choices for standardized data entry, and bar code scanning. Step 5: Implement a Prototype FRACAS

Now that the goals, success factors, expected output, workflow process, and entry forms are defined, you are ready to choose an implementation approach. General purpose tools, such as spreadsheets and personal database programs like Microsoft Excel or Microsoft Access, are limited in their capacity to handle large amounts of data and may not support the sharing of data between multiple users. FRACAS calculations and graphing are not intrinsically supported by general purpose software, and no functionality is included to generate workflow noti-

fications automatically and ensure a closed loop process. In addition, this approach may require internal support to create and maintain a customized application. Based upon the size of the workgroup, a small group collaboration tool or a large, Enterprise-wide application may be required. Relex FRACAS offers solutions for both sizes of workgroups, including workflow capabilities, built-in FRACAS calculations, and seamless integration with other reliability, maintainability, and risk analysis applications to effect a more detailed analysis. Enterprise applications provide additional tools for handling large amounts of data, including Web-based tools for streamlined data entry, workflow alerts delivered via e-mail, support for Microsoft Active Directory Services, and many simultaneous users. Relex FRACAS also supports commercial-off-the-shelf (COTS) templates with preconfigured FRACAS workflow steps, making it easy to start from a predefined solution or configure it in a few easy steps to suit organizational needs. This solution helps companies avoid the expensive, time-consuming, and often intractable results of hiring specialized consultants to create a customized solution. Easily configurable templates can be continuously adapted as your FRACAS process changes and develops, without the need for specialized programming skills. Whether selecting a small group collaboration tool or a large, Enterprisewide FRACAS application, examine the organization's immediate needs in relation to its future plans. It is important to consider the functionality required by your specific FRACAS process, the number of potential users, and the data storage requirements both at the project’s inception and well into the future. To validate the decision, implement a prototype FRACAS based on the selected approach.

White Paper

Relex — A PTC InSight Product

Page 7 of 7

Step 6: Accept Feedback and Modify the FRACAS

Once the prototype FRACAS has been implemented, with sufficient time for users to test and get a feel for it, it is important to bring the stakeholders back together and evaluate the results of the prototype system. Is this environment effective for the previously defined workflow process? Is data entry efficient and streamlined? Can the expected outputs be generated? Is the system easy to use and understand? Most importantly, revisit the goals and success factors. Does the system fulfill these goals? Will the success factors be met? It is very likely that you will find areas of the system that need to be reworked. This is the time to accept constructive feedback and make the necessary modifications. Before proceeding, gain signoff and approval from all stakeholders. You will need their continued support to make the implementation a success. Step 7: Rollout and Training

Although it may be necessary, when time is of the essence, to allow all users onto the system at once, this approach is likely to have more issues. With so many users starting out at the same time, seemingly minor issues can become major obstacles. Although this approach can work, it requires significant planning and coordination. It should only be considered when absolutely necessary. Alternately, a phased approach whereby several groups at a time are trained and then brought online is the preferred implementation method. By using this approach, any unforeseen issues can be addressed without involving the entire user base. Additionally, the implementation and training teams are able to adapt to these issues and provide better support for later groups. Typically, the more individualized attention and training given to users, the better their acceptance and support of the FRACAS will be. Training is extremely important, especially when typical FRACAS systems involve users of many different areas of interest and levels of expertise. When users understand what is expected of them and are empowered by training to use the FRACAS, the system has a much greater chance for acceptance and success. Step 8: Continue to Change and Adapt the FRACAS

One of the most important aspects of a FRACAS is to learn what works and what can be improved. Based on this feedback, continual change can and should be expected. As business objectives and processes change, the FRACAS needs to be adapted to support these changes. It is important, however, that the FRACAS is actively managed to not only accept these changes but to also validate these changes in relation to the overall goals that were initially established.

5. Conclusion Yielding more reliable products, better collaboration throughout teams in the organization, and valuable system metrics to track product performance over many different factors, an effective FRACAS is a valuable tool for any company seeking to improve its quality and reputation. By examining the best practice approaches to implementing a FRACAS process, companies can help ensure successful adoption, streamlined implementation, and effective results from the system.

6. About the Authors Daniel Jacob is an ASQ Certified Reliability Engineer with an extensive and diverse background in engineering, project management, technical sales, and market development. As a Relex Regional Account Manager, Mr. Jacob works with customers to determine the software and processes necessary to meet corporate and program objectives. Jennifer Akers is an ASQ Certified Reliability Engineer responsible for all Relex training services. As a Relex Senior Application Engineer and Curriculum Developer, Jennifer has developed numerous training courses that focus on both the theoretical foundations and practical applications of Relex software tools.

7. Bibliography 1. Failure Reporting, Analysis and Corrective Action System (FRACAS) Application Guidelines, Product Code FRACAS, Reliability Analysis Center, 1999 Sep., p 5. 2. M. Villacourt, P. Govil, “Failure Reporting, Analysis and Corrective Action System (FRACAS)”, Doc ID #: 94042332A-GEN, SEMATECH, 1994 Jun., Available at http://www.sematech.org/docubase/document/2332agen.pdf 3. NASA, Preferred Reliability Practices “Problem Reporting and Corrective Action System,” Practice No. PD-ED-1255, available at http://klabs.org/DEI/References/design_guidelines/design_ series/1255ksc.pdf 4. MIL-HDBK-2155 Department of Defense Handbook: Failure Reporting, Analysis and Corrective Actions Taken 5. RiAC: Reliability Problem Solving, Failure Reporting and Corrective Action System (FRACAS) and Reverse Engineering, http://src.alionscience.com/pdf/fracas.pdf 6. E.J. Hallquist, T. Schick, “Best Practices for a FRACAS Implementation”, pp 663-667, RAMS 2004. 7. J.S. Magnus, “Standardized FRACAS for non-standardized products”, pp 447-451, RAMS 1989. 8. A. Mukherjee, “Integrated FRACAS systems for F117 infrared acquisition designation system (IRADS) support yield higher MTBMA”, pp 26 - 29, RAMS 2005. 9. MIL-STD-721C: Definitions of Terms for Reliability and Maintainability, 1981.

8. Learn More For more information about Relex FRACAS, please visit: www.relex.com/products/fracas.asp Copyright © 2009, Parametric Technology Corporation (PTC). All rights reserved. Information described herein is furnished for informational use only, is subject to change without notice, and should not be construed as a guarantee, commitment, condition or offer by PTC. PTC, the PTC logotype, Relex, and all PTC product names and logos are trademarks or registered trademarks of PTC and/or its subsidiaries in the United States and in other countries. All other product or company names are the property of their respective owners.

4915-Relex-WP-1009