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.
As BPM practitioners we often hear of a high level of failed initiatives among the organizations that took a continuous process improvement path. This perceived lack of success is observed in the outright failure to implement BPMS (Business Process Management System) projects and/or institute a BPM practice as part of the organizational transformation efforts. Many reasons are given to explain this phenomenon among which are inappropriate technology chosen to support the effort, lack of focus on the ultimate goals for the initiative, failure to follow some prescribed methodology or “best practices”. All these reasons for failed BPM implementation initiatives are valid; however, I would like to provide analysis from a different, slightly more structured point of view.
Larry Bossidy and Ram Charan, in their insightful book “Execution: the Discipline of Getting things Done”, describe a framework for analyzing organizational performance based on what they call “the three core processes of execution” – Strategy, People, Operations. If we boldly apply this analytical approach to a BPM initiative and focus on the actual execution of this initiative, we may discover some uncomfortable facts that may greatly help us improve the chances of success. That is, if we are open-minded and willing to deal with the shortcomings in our organizations.
Looking through a “Strategic” perspective, we would focus on vision and planning by executive management and what actual actions are being taken by the organization’s leadership.
How aware is the senior management team of the changes that are coming from the BPM implementation? Are these changes aligned with the goals of the enterprise and were risks properly assessed and contingency plans developed?
Are there any other strategic projects being initiated at the same time as the BPM initiative and if yes, are there potential resource constraints, conflicting priorities, and unresolved political roadblocks?
Were senior managers responsible for the success of the BPM initiative and for championing its implementation involved in the analysis and planning that motivated the project in the first place?
Is the organization being prepared for a cultural shift that may be required to gain the most benefit out of the new BPM practices? Is there an enterprise-wide communication plan that unambiguously shows leadership’s commitment to the initiative, explains the motivations behind it, presents a vision of a better future state, and explains how the organization and the individuals involved in it will benefit from this future state?
A “People” perspective provides us with a more tactical view into the day-to-day activities required for the successful implementation of the BPM initiative.
Are functional leaders at all management levels prepared to discuss with staff the positive changes that will come with the new BPM practices?
Were the “business people” responsible for regular business functions and the functional “subject matter experts” assigned to the BPM project team involved in any early analysis that motivated the initiation of the project?
Was any comprehensive assessment of people’s skills performed to identify potential capabilities gap with the new BPM paradigm?
Do project champions and sponsors have enough power and political will to make necessary personnel changes, at all levels of the organization, to better align people with the new process environment?
Do people directly involved in the project clearly understand the rewards of success and the cost of failure and is the difference between the two outcomes significant enough to increase peoples motivations for success?
Are individuals and groups, within and without the organization, who are not directly involved in the project but may influence the future state performance of the BPM activities, “on-board” with the coming changes, were these changes even analyzed and communicated to them?
An “Operational” perspective provides a concrete view into organization’s capabilities.
Is the organization capable of operating at changed levels brought in by the new BPM practices? The supporting infrastructure for the new paradigm will have to be adjusted or changed – has it been analyzed and addressed?
Are those responsible for performing key business process tasks, as well as the business process owners, have been properly informed of the coming changes and were provided with necessary training?
If in the changed operational environment historically antagonistic groups are now expected to closely collaborate, did the leadership address the possible outcome of this situation and the risks involved?
Were interfaces to the organization’s supply chain partners thoroughly analyzed to understand the impact from the BPM initiative? The previous question would also apply to the organization’s internal and external clients – do decision makers truly understand the potential impact of the new operating environment on these two critical constituencies?
Issues listed above may seem like very obvious, common sense questions people would ask during the planning and analysis phase of a BPM initiative. However, it is always surprising how often many of these questions are not raised at all or raised in a very haphazard way just to check off a task on a plan. I believe that good execution ultimately relies on the human factor within an organization. We can see this factor as the common ingredient present in all three “core processes of execution” described by Bossidy and Charan.
So the takeaway from this paper is that even with adopting the “best practices” and selecting the best technology available on the market, the ultimate determinate factor of success of the BPM initiative or any important activity within an organization is the people. It is the leaders, at all levels of the organization, who based on their experience and commitment are willing to ask the right questions, challenge the status quo, and honestly deal with impediments that stand in the way of success.