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