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.
In observing a new business architecture initiative within an organization, we’ll notice that the motivation behind this initiative is typically driven by some issue or a “pain point” identified by the senior management. These “pain points” become apparent after a realization that some capability is no longer adequate to get the organization to its target goals. In such situations a business case will be built showing an economic return after the problem is remedied. This justifies the purse holders within the organization to allocate funds for the business architecture project. For example, during a recent consulting engagement, a major New York bank identified serious deficiencies with its new commercial client on-boarding capability. These included disjointed business processes, contradictory or non-existent procedures, gaps in regulatory compliance, and cumbersome reporting structure. A business architecture development initiative was sponsored by senior executives to address what was considered an existential threat to the bank. After completing the business architecture analysis focusing on the new client on-boarding and defining all critical components related to this capability, a project road-map was developed with specific business transformation goals in mind.
So far we’ve talked about a very reactive approach to business architecture development where an inadequate performance or a problem forces leadership to act. Reaction to a problem is the most common trigger for starting business architecture activities analogous, in our personal lives, to visiting a doctor and getting treatment after becoming ill. In the rest of this article I would like to propose a pro-active approach to business architecture development that narrowly focuses on the organization’s core value proposition.
When senior leadership is asked to describe the value proposition of their organization they may say something like …“we will provide our customers with high quality widgets supported by 24/7 help desk and a life time warranty” or “our widget will beat the highest efficiency standards and will be offered at an affordable price”. In order to deliver on its value proposition an organization must have capabilities that can do that. These capabilities provide the enabling infrastructure as well as the prerequisite for continuous success and must be the focus of the management team and leaders at all levels within the organization.
At this point I feel obligated to provide my definition of the “capability” since there is a lot confusion and controversy around this concept among business architecture practitioners. I view “capabilities” as a collection of methods, processes, technological and human resources that work cohesively to deliver on organization’s value proposition and provide a distinct advantage in the market place. A prime example of this in action is Wal-Mart’s logistics capability. It consists of highly efficient product distribution and warehouse inventory management systems coordinated with a large fleet of company owned trucks. Although emulated by its competitors, Wal-Mart still does it more effectively through a unique way of combining various components of its logistics capability.
When defining capabilities that support a value proposition, we should focus on unique, core capabilities that really differentiate an organization from its competition and provide it with an advantage. These would not include processes, systems, and other resources that, although necessary, are merely needed to keep the “doors open” and the “lights on”. Such activities and resources should be viewed as business functions required for any organization just to stay in business and do not offer any advantage. Although it may seem that the identification of core capabilities shouldn’t be difficult since it should be obvious to the leadership team what makes their organization successful, clearly defining and framing a set of unique capabilities is often very challenging in practice. An iterative discussion that includes different perspectives may be advisable in order to get to the essence of what makes an organization competitive in the marketplace and makes its value proposition viable.
After we’ve defined our value proposition and identified core capabilities that support it, we are ready to focus on the key components of the developing business architecture. As we already discussed above, an organization’s capability is really an interaction between various resources under its control. These resources are basically of three types: human, physical, and intellectual. They may include skilled employees, technology and machinery, strategies and methods, legal and contractual relationships, government regulations and compliance rules. Although this list is not exhaustive, it is sufficient to build a model for our purposes here. How well an organization combines and manages these resources, or what we would call components of its capabilities, determines its ability to deliver on the value proposition. In other words, business processes must be designed to be efficient and effective, must be executed by well-trained staff, and must be supported by appropriate technology. Additionally, business processes must be aligned with the organization’s strategies that are derived from its value proposition, and processes must be continuously monitored to measure their performance. To actually do all this in the most optimal way and to do it continuously is no trivial task. But here is where the full power of business architecture plays a critical role.
In our proactive approach to defining business architecture, we would decompose our distinctive core capabilities into their constituent components (see figure above) and identify various relationships between these components. To capture information about these components and their interrelations as well as the ability to continuously monitor these relations and dependencies is the main rationale behind the business architecture development effort within the organization. This is true for the following reasons. If we understand what makes us successful down to its constituent parts and are aware of how changes in the business environment will affect our organization, then we are able to deliver on our value proposition, meet the expectations of the marketplace, and have an advantage over our competition.
In conclusion, I would like to reiterate that by defining and maintaining business architecture for core business capabilities that support the organization’s value proposition, we are providing the company’s leadership with a very powerful tool. The leadership team will have greater insight into what is really important within their company when it comes to allocating investment dollars; it will be able to model changes to strategy and see potential business outcomes; it will be able to quickly determine the needed operational adjustments from changes in the marketplace; it will be able to identify the impact on the organization’s capabilities and their constituent components when there is a major shift in company’s direction that changes its value proposition. In addition, a business architecture that is focused on the organization’s main reason for existence – its value proposition – and developed around the core business capabilities, will serve as a great foundation for further development of architectural components for other important but less critical areas of the company.