Tutorial

More documents

Recommendations

Info

eports to identify important summary details visually based on the data collected. 2.5 How is FRACAS performed? While specifics will vary, FRACAS processes generally include these steps: 1. Record the failures or incidents. Critical data associated with each failure or incident is recorded and stored under defined procedures, often in a database management system. 2. Analyze the reported failures or incidents. The root cause of the failure or incident is identified and stored in the database management system alongside the original data. 3. Identify necessary corrective action. A corrective action plan for mitigating the failure or incident is developed, implemented, and stored in the database management system. 4. Verify the corrective action. Finally, the effectiveness of the corrective action is reviewed and recorded in the database management system and the incident or problem is closed out per established procedures. 2.6 What are the limitations of FRACAS? As much as FRACAS can substantially improve products, services, processes, or computer applications, the difficulty of efficient application is its inherent limitation. Smart planning and execution during implementation is paramount, otherwise the system may fail to manage data efficiently, effectively identify root causes of problems, or close the FRACAS process loop correctly. 2.7 Where can I learn more about FRACAS? As noted in the introduction, many FRACAS resources are available, including some that define structured approaches and guidelines for implementation. You can find several key FRACAS resources listed in the REFERENCES section. 3. FRACAS BEST PRACTICES While the general closed loop corrective action process seems to follow a common sense approach, many factors can impede its application. Because of the potential challenges, the following best practices are strongly recommended for use during FRACAS implementation. 3.1 Set expectations and goals Prior to deploying the FRACAS corrective action system, well-defined expectations and goals are essential. These include the roles and responsibilities of all stakeholders in the process as well as the objectives of the FRACAS system itself. All key stakeholders in the process must agree upon the explicitly defined set of clear expectations and goals. With these in place, the FRACAS implementation can progress with clarity of purpose and the system can deploy efficiently and effectively in line with the defined objectives. 3.2 Involve the stakeholders The support and involvement of all FRACAS stakeholders is critical. Many of these stakeholders will originate within the organization, but customers and/or suppliers may be involved as well. Involving all appropriate parties leads to support for gathering sufficient failure data and unification of a common process across the whole organization. 3.3 Gain active management involvement Management involvement and support has a strong impact on the success of the FRACAS. Active management participation often results in obtaining and maintaining necessary funding and resources, and may also provide the leadership needed to implement and maintain a successful FRACAS. 3.4 Keep the process simple The most successful FRACAS solutions are easy to use, employ user-friendly software tools for automation, and overall require modest investments in resources and training. By keeping things simple, active participation from those outside the quality/reliability is more likely. Ultimately, the FRACAS must be simple enough for both the expert and novice to use. Of course, the process design must also allow for a thorough and effective FRACAS. 3.5 Leverage software tools Software, either a custom in-house tool or customizable off-the-shelf solution, is one key way to help to automate the FRACAS and make it easier to use. Software tools help to automate data entry, analysis, and output, and provide a central storage area for FRACAS data and results. 3.6 Provide for efficient data entry and analysis Entering and analyzing data can be two of the most time consuming tasks for FRACAS users. Simple web-based forms can provide for efficient data entry, while automated calculations, graphs, and reports, along with the ability to filter the data, can increase the efficiency and effectiveness of data analysis. 3.7 Supply training Even when the simplest FRACAS process is implemented, early training can alleviate the stakeholders’ concerns and foster active participation. As users generate feedback and the FRACAS evolves, providing additional training is beneficial for the same reasons. 3.8 Encourage and supply feedback There are two types of desirable feedback. Feedback from the users of the FRACAS can help those in leadership roles focus and streamline the system, while feedback from those in leadership roles to all participants showcases the results of their hard work and provides encouragement. 2 – Cline & Stillwell 2012 AR&MS <strong>Tutorial</strong> Notes
4. CHALLENGES TO EFFECTIVE FRACAS 4.1 Challenge 1: Complex organization interaction 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 • Engineering • Operations • Quality Assurance • Reliability • Customer Service • Sales and Marketing • Field Services • Testing • Suppliers • Failure Review • Maintenance Board (FRB) • Others With all these different departments involved in the process, their interaction can become complex. Some groups may want to be included at multiple points. This increases and complicates the steps required to close an incident. Consider the following scenario of how this may occur. In this simple process, a field service representative reports or logs an incident. Quality Assurance then reviews this incident and assigns it to the Reliability group to perform a root cause analysis. The Reliability group 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 request to be involved. For example, Customer Service believes that they too need to be part of the corrective action step. Because they directly interface with the customer, they want to understand and possibly shape the corrective action response that may occur. In addition, Sales and Marketing may also be needed to properly manage a customer’s account, and a Supplier may desire to be connected with the analysis and corrective actions that have occurred with its parts. In this situation, the number of entities involved increases rapidly and the process quickly becomes convoluted. This results in a long cycle time between the opening of an incident and its eventual closing. If the process is too complex, incidents can even become “forgotten” and never worked through to completion. Ultimately, the timely reporting of trends is compromised and, in the worst case, the entire process breaks down. A typical warning sign of a breakdown in the process is the phrase, “We just need to communicate better.” Although this may be true, the process may simply be too tangled to allow effective communication. While all parties have the best intentions, the results in such situations can be disappointing. 4.2 Solution 1: How to overcome the challenge of complex organization interaction While working with the stakeholders in the planning phases of the FRACAS, identify the simplest process or workflow possible while still keeping key stakeholders involved at various steps in the process. Whenever possible, automate the communication. This way, all groups that need to be aware of an incident’s status can be notified easily. Assigning a key contact person for each functional group to attend FRACAS planning meetings and communicate important information to the group further streamlines communication. Regular FRACAS process review meetings involving all key stakeholders from the various functional groups can be helpful as well. These meetings can decrease in frequency over time. Lastly, make sure that all stakeholders sign off on the proposed communication plans before the final FRACAS is deployed to ensure organizational complexity has been adequately addressed. 4.3 Challenge 2: Lack of prioritized goals Based on a recent survey conducted by PTC, the top three reasons for implementing a closed-loop analysis and corrective action system are: 1. Compliance with customer requirements 2. Gaining insights into the reliability of products 3. Improving the next generation of product design Depending on the functional groups involved, the relative importance of these reasons may vary. Consider an example organization without clearly prioritized goals. A customer contract specifies that a FRACAS be utilized for a particular project. The project manager focuses on implementing what the customer has specifically required, but financial constraints mean the resources needed to complete a fullfeatured FRACAS implementation are unavailable. Project/program managers implement a temporary spreadsheet or database solution with full intentions of replacing this solution in the future with a more substantial system, but a full-featured FRACAS never materializes. Consequently, a minimal FRACAS becomes the standard resulting in poor efficiency and a lack of cohesiveness. Here’s another example: a company believes that a FRACAS is important to the success of a product, but they see it as something they will get to in the future. As the product lifecycle progresses, the company starts to appreciate 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 develops. In a third example, a program manager struggles to provide a FRACAS implementation while her executive management has much higher expectations for this system. They envision that the FRACAS will save the company money on warranty costs. In addition, the reliability group is expecting to gather significant data to explore trends and improve their product’s design over time. Consequently, these groups expect a full-featured implementation with significant data gathering, analysis, and reporting capabilities. Unfortunately, because the program manager has minimal financial resources, she can only implement a basic FRACAS. The deployed system is not set up early enough to sufficiently track information, which limits the data available to executive management and the reliability group. The system needs more 2012 Annual RELIABILITY and MAINTAINABILITY Symposium Cline & Stillwell – 3
Page 1 and 2: 2012 Annual RELIABILITY and MAINTAI
Page 3: 1. INTRODUCTION To produce high-qua
Page 7 and 8: goals and success factors back to t
Page 9 and 10: • Identify reliability and mainta

Tutorial

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?