You are on page 1of 9

_______________________________________________________________

_______________________________________________________________

Report Information from ProQuest


13 March 2012 07:58

_______________________________________________________________

Document 1 of 1

Using an FMEA In a Service Setting


McCain, Cecelia. Quality Progress 39.9 (Sep 2006): 24-29.

_______________________________________________________________
Abstract
Failure mode and effects analysis (FMEA) is a quality tool that allows the user to examine the process from the viewpoint of its potential for failure (what could go wrong in the process) and plan for its control through service, product or process design requirements. When completing an FMEA, begin by completing the header section, which includes the name of the individual preparing the FMEA, the project team responsible for designing the process and the individual who owns the process that is being designed. Because working with an FMEA is an ongoing task, not a one-time event, also assign responsibility and document the name of the individual who will be charged with maintaining the FMEA after its original creation. Finally, document the original date on which the FMEA was created. An FMEA can be a useful tool to help service organizations identify improvement opportunities. Look at the service related processes within your own company and determine which processes have the biggest impact on your external customers.

_______________________________________________________________
Full Text
The use of corrective action-being reactive to quality performance problems by identifying and eliminating the root cause of nonconformities-is very common. Getting ahead of potential problems and designing them out of processes or preventing them from occurring is a different challenge. ISO 9001 includes item 8.5.3, which requires preventive action to eliminate occurrence and recurrence of nonconformities. Compuware Corp. recently underwent an audit conducted by a third-party ISO 9001 registrar and received certification fur its product, support and selected services delivery groups. During the audit the auditor said, "Of course you don't use failure mode and effects analysis [ FMEA]" and then asked, "So, how do you address the preventive action requirement?" She was quite surprised to learn the process design activities for Compuware's nonmanufacturing SOPs did include the use of an FMEA. FMEAComponents At Compuware, project teams use an FMEAto test a process design-or solution-during quality planning and quality improvement projects to ensure the process is capable of meeting features and goals. The teams have found an FMEAaddresses the root causes of a problem, meets the desired outcomes and deliverables and can be implemented effectively. An FMEAis a quality tool that allows the user to examine the process from the viewpoint of its potential for failure (what could go wrong in the process) and plan for its control through service, product or process design requirements. The potential for failure is designed out of

the process before it reaches the customer. If you have documented processes, regardless of whether you are in a manufacturing or service environment, an FMEAeasily can be applied to the steps of those processes.

Take a closer look at the tool itself, starting with Figure 1. When completing an FMEA, begin by completing the header section, which includes the name of the individual preparing the FMEA, the project team responsible for designing the process and the individual who owns the process that is being designed. Because working with an FMEAis an ongoing task, not a one-time event, also assign responsibility and document the name of the individual who will be charged with maintaining the FMEAafter its original creation.

Finally, document the original date on which the FMEAwas created. As the FMEAis revisited, reviewed and revised throughout the life of the process, the revision date portion of the header section is updated accordingly. Column one of an FMEAis the service feature, which is something you anticipate doing or creating to meet customer needs, or process feature, the steps necessary to deliver the feature. At Compuware, project teams transfer the features from a customer needs clarification spreadsheet. The customer needs clarification spreadsheet is used to express customer needs in precise (measurable) terms. The spreadsheet breaks down each primary need so specific service or product and process features and goals (responses to need) can be developed. In the example shown in Figure 2, a quality planning project team was assigned the task of developing a service delivery process to ensure a steady pipeline of contract employees would be available to meet short- and long-term assignment needs. The team used the customer needs clarification spreadsheet to break down each primary customer need requiring further clarification.

Brainstorming, a group technique for generating new, useful ideas, is used to complete the next two columns of an FMEA. Because project teams are identifying potential failures, brainstorming is very important to the successful completion of an FMEA. Brainstorming gives each person on the project team the opportunity to express his or her ideas without being interrupted or criticized. It allows more creative ideas to be generated quickly than does an unstructured discussion, which often focuses on who rather than what is right. Column two in the FMEAtemplate (Figure 1, p. 25), potential failure mode, is about problems that can result while designing the feature or implementing the process-how the feature might fail. Column three, potential effect of failures, is a statement of the negative consequences of a failure. Column four is used to determine the severity rating (SEV) for each potential effect listed in column three. Using a scale (see Figure 3) of one (no effect) to 10 (extreme effect), project teams brainstorm to determine how severely the effect of the failure impacts the customer. When possible, it also is quite helpful to include customers in the FMEAprocess, especially when determining severity. Failure Mode Detection and Rating Next, for each of the potential failure modes listed in column two (Figure 1), the team brainstorms to identify potential causes and list them in column five. Column six allows the project team to assign an occurrence rating (OCC), which scores the likelihood the cause documented in column five will occur. Again, a rating scale from one (almost never) to 10 (almost certain) is used to assign the rating. It a process is performing very efficiently, the likelihood the cause of the failure will occur is very small-thus a low rating. If a process is performing very inefficiently, with a high number of errors, the likelihood that the cause of the failure will occur is very high-thus a high rating. A typical occurrence rating table for an FMEAin a manufacturing facility would begin with one in 1.5 million occurrences, which is not realistic for service companies. As you develop an occurrence rating table for your own service setting, examine the processes with the highest productivity, such as paycheck processing, invoice processing, order taking and call handling. Determine which of those processes have the highest level of productivity, such as number of paychecks processed each month, and set the failure rates accordingly. In the Compuware example shown in Figure 4, there are no processes with productivity more than 30,000 occurrences each month, so that is the number we chose to start with before moving down the scale accordingly.

Column seven (Figure 1) is the detection rating (DET). Project teams determine how likely it is current process controls will detect the cause of the failure listed in column five. As with the previous columns, a rating (see Figure 5, p. 28) from one (almost certain) to 10 (almost never) is used. If current controls are almost certain to detect the cause of the failure, a low rating is assigned. If there is a remote likelihood current controls will detect the cause or there are no controls in place to detect the cause, a high rating is assigned. Column eight (Figure 1, p. 25) is the rating priority number (RPN), which helps project teams determine which issues need the most attention. The RPN is calculated as: SEV x OCC x DET = RPN The remaining columns of Figure 1, nine through 15, are used to lower the RPN on potential failures with an RPN of 150 or higher. Column nine, recommended actions, describes activities to be taken or what can be done to prevent the potential failure. Column 10 identifies who is assigned to complete the recommended actions and the time-frame the actions are targeted to be completed. Remember, the objective is to take action before these failures reach the customer. Column 11, action taken, describes what was actually done to mitigate the effect or reduce the impact of the failure on the customer. Columns 12 through 15 are used to recalculate the RPN by multiplying severity by occurrence by detection. If the RPN is still too high, the project team needs to return to column nine and identify additional action to be taken until the RPN is reduced to a level below 150. FMEAExample

Let's look at an example in which a project team was developing a service delivery process to provide contract employees for assignments at external customer locations. At Compuware, even though we use the service, product or process features listed on the customer needs clarification spreadsheet to conduct the FMEA, we also could use the steps of a high level process flow diagram. The example shown in Figure 6 begins with the process feature "implement and manage onsite recruiting process" from the customer needs clarification spreadsheet illustrated in Figure 2 (p. 29). The potential failure mode (how the feature might fail) was determined to be "on-site recruiting process not implemented," and the potential effect (negative consequences) was identified as "insufficient numbers of employees available." The project team assigned a severity rating of eight, meaning an insufficient number of employees available for assignment would have a major effect on the customer. The

potential cause of the failure (why this might happen) was determined to be "no one available to conduct on-site recruiting," with an OCC of 8 (high), and a DET of 3 (high). Multiply severity, by occurrence by detection to calculate the RPN: SEV x OCC x DET = RPN 8 x 8 x 3 = 192 Remember, an RPN of 150 or higher needs to be investigated and the process improved until the RPN is reduced successfully . The recommended action was for branch managers to cross train recruiters on the on-site recruiting process by Nov. 15, 2006. The process owner was responsible for ensuring the branch managers completed the cross training and for notifying the project team when training was completed. Once the actions were completed, the project team's next step was to determine whether the actions successfully reduced the RPN of 192. The project team determined the actions taken did reduce the OCC from an eight (high) to two (remote). In other words, the action taken reduced the likelihood the cause will occur by increasing the pool of trained recruiters. The project team also determined the action taken improved the DET from a rating of high (three), to a rating of very high (two), by improving the likelihood it could detect the cause before the customer could be impacted. Note that the SEV of eight did not change, because the effect of failure on the customer did not change. The new RPN was calculated as follows: SEV x OCC x DET = RPN 8 x 2 x 2 = 32 Once the actions were completed and the new RPN calculated, the revision date was entered into the header section of the FMEA. These steps were repeated until all the features from the customer needs clarification spreadsheet were included on the FMEA. Process flow diagrams also were revised as needed to reflect the actions taken as the project team works through the FMEA. To maintain the FMEA, the process owner needs to review and revise it anytime a change is made to the process. Also, as processes are reviewed, which should be at least annually, the FMEAshould be reviewed to ensure nothing has changed that would impact the RPN of any of the features.

FMEAand Continuous Improvement An FMEAalso can be a useful tool to help service organizations identify improvement opportunities.

Look at the service related processes within your own company and determine which processes have the biggest impact on your external customers. Conduct an FMEAto identify features of the process with the highest RPNs, create a Pareto analysis to rank the features by RPN and initiate quality improvement projects. A good candidate for improvement in most companies is the invoicing process. Improving invoicing not only benefits the customer by increasing such things as the quality, accuracy and timeliness of invoices but also benefits the company by compressing payment turnaround time and accelerating cash flow. For example, let's say one step or process feature in the invoicing process is to enter information into the billing system. To complete the FMEA, the next step is to determine how this feature might fail (potential failure mode), such as inaccurate data entered into the system. What is the potential effect of the failure? The customer would receive an incorrect invoice, to which an SEV of four (moderate effect) is assigned. The rating of four is appropriate because the definition of this rating is, "Failure results in confrontation with the customer, and additional cost is incurred."

The customer would confront the company to resolve the incorrect invoice (especially if the error is not in the customer's favor), and the company would incur additional cost by creating a revised invoice. A project team should brainstorm to determine potential cause of the failure. One cause could be that the data source (for example, the order form) itself is inaccurate, making it impossible for the billing clerk to enter the right information into the system. Another cause could be human error-the billing clerk entering the wrong data into the system. For each potential cause identified, the team then should brainstorm to determine the OCC and the likelihood current controls will detect the failure before it occurs. For each potential failure the project team then should calculate the RPN by multiplying severity by occurrence by detection and take necessary steps to reduce ratings above 150. A simple improvement a company could implement to improve the data source might be to find ways to foolproof its order form, perhaps through the use of drop-down boxes. The use of FMEAas a preventive tool easily allowed Compuware to meet the ISO 9001 requirement for preventive action. The tool allows for determining action to eliminate the causes of potential nonconformities to prevent their occurrence.

FMHAs provide records of preventive action and demonstrate a preventive action is appropriate to eliminate the effects of a potential problem. They also identify the potential causes of problems and elimination of those causes-even in a service company. Sidebar In 50 Words Or Less * ISO 9001 requires preventive action to eliminate occurrence and recurrence of nonconformities. * Compuware uses failure mode effects analysis (FMEA) to ensure its service designs and processes meet desired outcomes and can be implemented effectively. * FMEAalso can help service companies continually improve. Sidebar Please comment If you would like to comment on this article, please post your remarks on the Quality Progress Discussion Board at www.asq.org, or e-mail them to editor@asq.org. AuthorAffiliation CECELIA McCAIN is the director of quality program management at Compuware Corp. in Detroit and an ASQ member. She has numerous certifications, including ASQ's Six Sigma Black Belt and the Softivare Engineering Institute's capability maturity model.

_______________________________________________________________
Indexing (details)
Subject Service industries; Failure analysis; Guidelines United States--US 9190: United States, 5320: Quality control, 8300: Other services, 9150: Guidelines Using an FMEA In a Service Setting McCain, Cecelia Quality Progress 39 9 24-29 6 2006 Sep 2006 2006 BASIC QUALITY Milwaukee American Society for Quality

Location Classification Title Author Publication title Volume Issue Pages Number of pages Publication year Publication date Year Section Publisher Publisher

Place of publication Country of publication Journal subject ISSN CODEN Source type Language of publication Document type Document feature Subfile ProQuest document ID Document URL Copyright Last updated Database

Milwaukee United States Engineering 0033524X QUPRB3 Scholarly Journals English Cover Story Photographs;Tables;Equations Failure analysis, Service industries, Guidelines 214761208 http://search.proquest.com/docview/214761208?accountid=32819 Copyright American Society for Quality Sep 2006 2010-06-08 ABI/INFORM Complete << Link to document in ProQuest

_______________________________________________________________
Contact ProQuest
2011 ProQuest LLC. All rights reserved. - Terms and Conditions

You might also like