More and more organizations are looking for ways to expedite capability mapping efforts – with limited success. Seeking shortcuts to establishing a robust baseline upon which to build business strategies and priorities, drive initiatives, target funding and drive IT architecture has delivered suboptimal results. With so much at stake and so many organizations seeking answers, I would like to say that there is a quick and easy approach to establishing capability maps and other foundational aspects of business architecture. Unfortunately, there is not and attempts to do so have produced mediocre and largely unusable results.
The Journey – As Important as the Destination
One type of capability mapping shortcut involves leveraging a copy of another business’s capability map. Most of these maps are proprietary, but even if these maps were readily available, care must be taken when using them. Given that the capability map defines the essence of a business, it is counterintuitive that one business can take another business’s map and adopt it as its own. Businesses are not cookie cutter clones of each other and neither are their capability maps. Each business has unique vocabulary, abilities, legal requirements, and policy and procedural considerations that shape certain capabilities and how they are organized. Replicating another business’s capability map imparts unrealistic expectations of commonality across businesses that do not exist.
Some organizations simply want a starting point or template. Fair enough. But using these predefined maps introduces risks as well. Interpreting another business’s vocabulary comes at a cost of not recognizing and formalizing your own business vocabulary. For example, one business’s agreement is another business’s account. Another business’s account may be a third business’s customer. The difference in meaning and context of these terms can be dramatic. While definitions help, a predefined set of business terms can derail discussions with business stakeholders. Surfacing, exploring and maturing the nuances in business terminology that form the basis for capability mapping are part of the journey of capability mapping.
Another risk is one of omission. Omitting critical capabilities because another business does not have those capabilities can leave holes in a capability map. A related risk involves misconstruing the context of a capability. For example, one organization only built legal notifications to applicants when a rejection occurred while another organization built these legal notifications under every examination scenario. In the cloned case, a critical capability only existed within the context of Rejection Management, which misconstrued an important view of the business – making the map a flawed representation of the business that had to be caught and corrected.
The biggest risk, however, is that a given business has no institutional ownership in a “derived” capability map. Institutional ownership means that business stakeholders from key parts of the organization have discussed, vetted and defined each and every capability – top to bottom. It means that the resulting map defines the essence of your business and is fully defensible within the business community. It means that business stakeholders, from the executive suite to the frontline business professional, can standup and say that this map fully represents their business and can serve as a basis for planning, strategy articulation and transformational initiatives. Adopting another organization’s map not only shortcuts the results, but shortcuts the journey and, therefore, institutional ownership and acceptance of the results.
Leveraging Industry Business Models as Templates
When it comes to capability mapping, there is no substitute for direct, extended business participation and engagement. This has become painfully clear to organizations that have tried to fast track their way to a capability map using business model templates. While there are a number of business models that can serve as a reservoir of content, they are not capability maps and introduce their own set of risks. Examples include the APQC process model templates, the IBM Component Business Model (CBM) and other industry specific business model variations.
These business models are not based on capability mapping principles and guidelines and are oftentimes a mix of organization, process, capability and even technology concepts. In addition, the framing of these concepts constrains capability decomposition and encourages redundancy – a definite taboo for the capability map. Using these templates can take a capability mapping team down a variety of dead ends.
Organization of these models can be an issue as well. For example, the CBM is typically aligned into strategy, control and manage, and execution stratification tiers. This introduces challenges when adapting these concepts to capability mapping where any given level one capability, Policy and Procedure Management for example, has all three aspects of strategy, control and manage, and execution. This issue becomes more apparent when a capability is decomposed to lower levels. For example, Policy Creation is strategic while Policy Dissemination is execution. A given CBM would often replicate aspects of Policy and Procedure Management at the top level across each stratification tier, which in turn would create more replication as this capability was decomposed into lower levels.
In some cases, the use of these business models can actually delay or derail a capability mapping effort. Some organizations have surrounded themselves with numerous, industry specific reference models and end up being paralyzed by the overwhelming amount of content. These organizations suffered this paralysis because they had no baseline capability map into which various vocabularies could be incorporated. These organizations also missed certain capabilities, omitting for example core concepts such as the creation of the very product the business was delivering to its customers.
The best way to leverage these business models are as reservoir of industry-specific vocabularies. This approach, however, requires that a capability mapping team establish a robust, well defined level 1-2 capability map that has been vetted with the business. Only at this point can a mapping team use these business models as a checkpoint to determine where additional, missing or industry standard terminology may need to be incorporated into the capability map. The robust capability baseline also allows a mapping team to leverage a stratification and decomposition structure that creates distinct, well defined and non-redundant capabilities for a business.
No Alternative to Business Engagement
Perhaps the greatest lesson learned in leveraging industry business models is that there is no substitution for direct, extensive and introspective business stakeholder engagement. The organizations that think they are simultaneously helping and protecting the business by not engaging in extensive business stakeholder capability participation have ended up doing neither. When an IT-based mapping team delays and fumbles capability mapping efforts, the business can end up viewing business architecture as just one more self-serving IT gimmick. Numerous organizations have invested a good bit of money in these business models. They have found that all the templates and business models in the world will never further the creation of a robust capability map that will have long-term, sustainable value from strategic planning through solution deployment.
As you begin or continue your business architecture journey, consider that there are a good number of organizations that have established robust capability maps, value stream maps and a number of more advanced business architecture views. As you embark on this journey, bear in mind that your efforts to find a shortcut to building your capability map may result in frustrating delays that produce a failed capability map that is of little business value and ultimately confound efforts to capitalize on business architecture.
