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.

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 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.