On a recent business transformation engagement with a large retail industry client a question arose regarding process design. More specifically, a concern was raised about potential human errors or mishandling of some process activities and the consequences that would result from that. One subject matter expert gave an example of an order-to-cash call center purchase processing. Often, when ordered item is not in stock a phone representative would offer the customer a substitute product at the same price as the out of stock item. Such exceptions were not supported by the existing order processing systems, and the procedures for handling such transactions were poorly written. A phone representative would hand write these exceptions on sticky notes and later submit them for special handling. While the phone representative was “delighting” the customer, she was not completely aware or concerned about the problems these transactions created for inventory management and accounting staff downstream.
Since this was a “business transformation” initiative and discussions stayed at relatively high level most people involved were business architects, process owners, and line of business managers. After hearing a few more examples of process pain points our consulting team suggested a method for analyzing processes for points of failure, identifying consequences of these failures, and steps to eliminate or reduce such failures. Client representatives were very eager to hear about this method until we explained that it’s an approach widely used by Six Sigma practitioners. Business architects especially were against using such tools since they considered Six Sigma analysis to be data intensive and task level focused. In other words Six Sigma work is performed “down in the weeds” not at the architecture level. Besides, Business Architecture Center of Excellence (CoE) and Six Sigma CoE existed within this organization but rarely talked to each other. After our consulting team explained what we had in mind we had a lukewarm agreement from the client to run a process analysis workshop. This workshop turned out to be a huge success that led to more sessions and eventually contributed to providing clarity and focus to the entire initiative. A big, long-term benefit to the client was the breakdown of the analytical silos and the appreciation of cross disciplinary approaches to analyzing business problems.
The approach that we proposed to the client was to use Process Failure Mode & Effect Analysis (PFMEA). Although today it is a part of the common Six Sigma tool set and included in DMAIC methodology, the failure mode & effect analysis (FMEA) concept was born more than sixty years ago in the US military. Its original intent was to provide a standard for design and development process for aerospace and defense applications. Gradually, FMEA was adopted by the automobile industry and then its popularity spread to other industries and it became a standard tool used by process engineering practitioners.
So, what is FMEA and how can we apply it to our work? FMEA is an analytical approach used to identify and understand the opportunities for failure and the impact of risks in a product or process design. It includes risks prioritization and the definition of steps to remove or reduce the impact of these risks. FMEA provides a slightly different approach depending on whether the focus is on product design or process design. For example, in product design we would be using a component or functional block diagram to understand the interfaces between various parts of the product, we would look for any manner in which the components may fail, and we would identify the consequences of these potential failures. When we design a process, we would use process diagrams to analyze the steps for failure to perform their intended function and the impact on the process output.
Now that we’ve defined the FMEA, let’s take a look at the typical method and format used to capture relevant information. It is highly recommended that the FMEA activity is performed in a collaborative, workshop style environment. Since we are focusing on business process analysis and design, we would use process diagrams and/or flow charts to review individual steps for potential failure. This is not a trivial exercise and requires an experienced facilitator to manage the team discussion. Special care must be given to maintain a balance between more dominant or aggressive team members and those less aggressive or more quiet, so their concerns can also be heard. If this balance is not maintained, our analysis may be skewed towards a certain group or process area and not be complete.
An example below for a fictitious account opening process will illustrate the information capturing format.
(Click on image to enlarge)
The column titles in this table are self-explanatory except for those with three letter acronyms with numerical values in their fields.
SEV – severity of the effect of failure. Here, our ratings are on the scale of 1 to 5 with 5 being a very negative effect if a failure occurred as described.
OCC – likelihood or frequency of the occurrence of the cause of failure. Again, the rating scale is from 1 to 5 with higher occurrence rated with a higher score.
DET – detectability or an ability to detect failure for a given cause. Here, the scale from 1 to 5 is defined in reverse with higher detectability assigned a lower score.
RPN – Risk Priority Number is a product of SEV*OCC*DET and provides an overall risk score for a cause of failure.
As we capture information and analyze it with our team, we’ll use RPN scores to prioritize risks that require a more immediate focus. In the example above, a “validate client address” step in the process has the RPN of 60, which is significantly more than the other scores and therefore will be a high priority for remediation.
The last four columns of the FMEA table capture actual redesign or remediation actions that were implemented and the new, hopefully improved scores. Typically, in a well-managed, process-focused organization the FMEA reviews will be performed on a regular schedule to monitor any degradation in process performance and identification of new risks. RPN target level may be set with maximum threshold levels a breach of which will require immediate action.
The FMEA is a powerful analytical tool appropriate for both process design and current state process analysis. Although it has been widely used by the Six Sigma practitioners, its conceptual simplicity and flexibility makes it easily adoptable by other disciplines such as business process management and business architecture.