Reliability HotWire

Reliability HotWire

Issue 111, May 2010

Hot Topics

Enterprise Level Management of FMEAs — A Fictional Case Study

Waloddi Corporation is a mid-sized company that designs and manufactures small electrical vehicles for use in indoor environments, such as airports and stadiums. The company was established in the mid-90s and has been growing steadily ever since. After the recent economic downturn, this year has started to look very promising for Waloddi. They are ramping up production and shortening product development cycles. One of the lessons learned from previous products is the need for a greater focus on reliability, which is considered to be the key for increasing and sustaining their market share. The warranty costs from field failures have been far beyond their targets, and there has been no process in place to incorporate lessons learned from the field and drive reliability through the design. With these factors in mind, Waloddi’s management made the decision: They would no longer be putting out fires, but would instead focus on prevention of failures and building a reliability culture in their organization.

The Need for Enterprise-wide FMEA Management

Up to now, reliability activities were partially managed by quality and partially by testing, but there was no actual expertise in the methods and techniques to design in, measure and improve reliability. The first step was to actually build a reliability team inside Waloddi. Next, the new team started examining the processes needed to implement a good Design for Reliability (DFR) process. One of the analyses that they realized they needed to integrate more fully in the process was the Failure Modes and Effects Analysis (FMEA). FMEA is considered to be the roadmap for product improvement. It is at the crossroads of reliability and quality; it drives design improvements and identifies gaps in testing.

Waloddi engineers were already familiar with FMEA. They had a spreadsheet template that various departments were using. However, there was essentially no centralized process around it. FMEAs were residing on local hard drives here and there. There was a lot of knowledge that was scattered and there was no way to create a central repository where that knowledge could be queried and applied to similar designs as they evolved. The results of that situation were repeated design mistakes, no real control over assigned actions and no common platform to audit FMEAs and implement process improvements.

After attending ReliaSoft’s Effective FMEA training seminar series, they decided to organize their FMEA process with the Version 5 release of ReliaSoft's Xfmea software.

Xfmea is based on a relational database, which provides centralized data storage. The once-scattered information can be gathered together and used as a basis for collaboration and knowledge management. Multiple users can collaborate on the same analysis, and they can easily find and reuse information from other FMEAs through powerful queries and predefined "phrase sets."

With an Xfmea 5 Enterprise license, users have the option to store data in individual Standard databases (Microsoft Access®) and/or in a centralized Enterprise database (Oracle® or SQL Server®). Since Waloddi already had a corporate-wide license for SQL Server, they decided to set up a dedicated database server running SQL Server 2008 Enterprise edition to host their new centralized FMEA data repository.

Configuring Access Levels

Xfmea 5 allows for different access levels within the database. Waloddi assigned some users to the Admin access level (so they could create user accounts and manage configurable system-wide settings) and some users to the Power access level (so they could manage configurable system-wide settings). For all other user accounts, the access permissions vary depending on access group.

Waloddi created access groups based on their global sites. For each individual user account, it is possible to choose what type of access the user will receive for projects in each access group. For example, a user might have read/write (User) access to the analysis projects from their own work site, read-only (View) access to the analysis projects from other sites and no access at all (None) to projects that have been identified as confidential.

Figures 1 and 2 show how easy it is to provide different levels of access for individual users.

Figure 1: Adding User Login and Contact Info, and Defining Access Level by Access Group

Figure 2: Assigning Access Types to a Specific User for Various Groups

Creating a Waloddi Global Profile for DFMEAs and PFMEAs

The team spent half a day revisiting the scales used to rate severity, occurrence and detection. Up to now they had been using the AIAG standard, but they decided to make some necessary changes in their scales in order to better characterize their specific products. They started from two of the predefined profiles shipped with the software (DFMEA: AIAG-4 and PFMEA: AIAG-4 ) and then they customized the settings to fit a few specialized needs for their Design FMEAs (DFMEAs) and Process FMEAs (PFMEAs). Figure 3 shows an example of the Waloddi DFMEA severity scale.

Figure 3: The Waloddi DFMEA Severity Scale

The team also decided to customize several Xfmea 5 interface settings in order to meet their specific needs. All it took in Xfmea 5 was to add a profile definition with the specific customized settings, as shown in Figure 4.

Figure 4: Adding a Customized Profile

The Waloddi DFMEA profile was preloaded for all users at Waloddi Corporation and was set as the default. This ensured that all users would use the same exact profile going forward.

Importing Existing FMEAs into Xfmea 5

The next steps that the Waloddi team followed were to gather all previous FMEAs that were in spreadsheets in scattered locations and import them into Waloddi's Xfmea 5 database on SQL Server. The process was as easy as mapping the columns in the Excel® files with the available fields from the Import Template interface, as shown in Figure 5.

Figure 5: Import Template for the Waloddi DFMEAs

After the template was created, the only necessary step to import an FMEA was to select the Waloddi DFMEA template and browse to the Excel spreadsheet to be imported, as shown in Figure 6.

Figure 6: Importing from Excel, Based on a template

It took about half a day for the Waloddi team to load all of the existing FMEAs into Xfmea 5. Now all the information from previous designs and manufacturing processes was easily accessible and searchable with the power of a relational database.

Working in a Corporate-wide FMEA Database

The Waloddi team continued adding projects for current and previous designs. Their database is now populated with most of their product series. Figure 7 shows a filtered view of their current database displaying the Waloddi "Runner series" FMEAs that are for products currently in development (filtered based on Xfmea's customizable project categories).

Figure 7: The Xfmea 5 Project Explorer

Leveraging Existing Knowledge

Waloddi engineers are now able to leverage existing knowledge from past FMEAs each time they work on a new analysis. Figure 8 shows an example of a team working on a component FMEA for the engine piston of a product that is currently in development, the Waloddi Runner Series 110. The Project Explorer, displayed on the left, provides access to all the available projects. In the middle, the System Hierarchy panel shows the multi-level system configuration and the system-, subsystem- and component-level FMEAs. The Analysis panel on the right displays item properties and analysis details for the item selected in the system hierarchy. In the case shown here, the hierarchical view of the FMEA is displayed. 

Figure 8: The Xfmea 5 Interface with the Project Explorer, the System Hierarchy and the FMEA

The team is currently considering adding a new cause for the failure mode "piston fractured." They have heard that there were some overheating incidents in the past, but they were not quite sure when and where they occurred. When they add a new cause record to the analysis, they have the opportunity to search across the full database of their FMEAs. In this case they selected to obtain existing descriptions from all the projects in the Waloddi database, as shown in Figure 9. Figure 10 shows that the team searched for "overheat" and the query returned all the instances where "overheat" had been used as a cause in previous FMEAs. The team decided that "overheat due to inadequate lubrication" was relevant to this project, as it had occurred in the previous model with the same engine and same piston part number.

Figure 9: Obtaining Existing Descriptions from All Projects

Figure 10: Searching for a Keyword in the Database

Setting up E-mail Notifications for FMEA Actions

One of the lessons learned from Waloddi's past FMEA projects was the need to make sure that the design teams follow through on the recommended actions identified during the FMEA. The strength of the actions management capabilities in Xfmea was one of the reasons that Waloddi chose this particular software tool. The Waloddi team activated the automated e-mail notifications feature in order to integrate FMEA actions with their e-mail system and achieve better clarity in their action management tracking. Figure 11 shows the settings they chose to use.

Figure 11: Enabling Action Notification E-mails

In addition to receiving e-mail notifications regarding actions assigned to them, Waloddi's users also can access the personalized My Portal window at any time. This interface provides quick access to all of the recommended action records with which the user is involved.

Conclusion

After Waloddi's FMEA leadership team performed the initial configuration of the Xfmea software and established the processes for Waloddi engineers to use for these analyses, multiple users from various divisions of the organization were then able to begin using the shared system to facilitate and manage the data from their ongoing FMEA projects. The enterprise-wide system made it possible to establish consistency throughout the organization with respect to both FMEA practice and the terminology used for discussing potential failure modes and their causes. It also allowed the organization to develop a keyword-searchable knowledge base of FMEA data that could be used to obtain the reports, plots and queries needed to make decisions about current designs and also could help to accelerate and improve the analysis process for similar designs in the future. Finally, the system helped the organization to implement a feedback loop for corrective actions to ensure that the effort invested in performing FMEAs leads to useful improvements in product or process designs. Although the scenario described in this article is fictional, it represents many of the actual challenges and goals that many practitioners face and attempts to "paint a picture" for how an organization might begin to establish an Xfmea Enterprise implementation to help meet these needs.