Linking Capabilities to the Operating Model: Business Functions and Organizational Structure
Nov 3, 2021
In our previous blog in our series on Capabilities and Capability-based Planning, we discussed the relationships between strategy, business models and capabilities. Now we want to delve one level deeper into the operating model of the enterprise. We want specifically to answer: How are capabilities delivered by the enterprise’s operating model?
Let’s start by clearing up an important misunderstanding: a Capability Map is not a functional decomposition of the enterprise! We have written about this confusion in our blog: Capabilities vs Business Functions: Same difference?. Many capability maps are full of business functions, or even worse, resemble organizational charts. Business functions describe the day-to-day operations of the enterprise. Now anything you actually do is obviously something you are able to do. So, for each business function, you could define a 1-to-1 related capability. But that isn’t a great way to use the concept, since there are many things your enterprise could do that it doesn’t do on a day-to-day basis: it has capabilities that go beyond mere business functions.
As an example, we can use the military which uses the expression: ‘Boots on the ground’ where they describe their potential to have troops deployed anywhere in the world in 24 hours. However, they don’t have a business function: ‘Boots on the ground’, let alone a ‘Boots on the ground department’. But ‘Boots on the ground’ is a capability.
Business functions express the concrete activities performed to deliver capabilities. In an ArchiMate model, you express this using a realization relationship: one or more business functions realize a capability. Next to that, you can of course define which departments are responsible for performing these functions and which information and technology uses it. That then provides you with a line of sight between a capability and its realization.
The next figure provides an example: The capabilities “Money Management”, “Asset Management” and “Policy and Claim Management” are realized by three business functions, with the “Investment Management” function involved in two capabilities. These functions are in turn performed by two responsible organizational units. This the basis for the operating model of your enterprise.
Figure 1 Capability realization by business functions (and actors)
A similar mapping can be made between value streams, which describe the high-level value creation steps in your enterprise, and the business process es that realize them. But we will leave that for another blog post.
The capability concept supports the collaboration of people from different disciplines. You should consider that people have different ways of thinking, depending on their background. We like to share some observations from our practical experiences.
Managers often think in terms of groups of people and the work they do (and e.g., span of control, ownership and responsibility). They therefore tend to interpret such a map as an organizational or functional structure. Similarly, people with an engineering background (and especially in IT) think in terms of functional decomposition. Both management and engineering have a design perspective where “this bit” of the enterprise or system (e.g., a department or component) needs to do “that piece of work” (e.g., perform a function or execute a business process). The potentiality and dispositional nature of capabilities isn’t something either of these worlds is natively familiar with. The military are more advanced in their capability thinking. However, we have observed a tendency for them to mix up capabilities and resources, e.g. calling an aircraft carrier a capability (perhaps betraying the military’s obsession with hardware), rather than a resource (or collection of resources) that supports a capability like “Power Projection”.
Nevertheless, even if a capability map is a bit too ‘functional’ it can still be useful and offer a way to let people adapt to and adopt the concept. Just make sure it does not depend on any specific technology implementations or organization structures and stays focused on the ‘what’ rather than the ‘how’.
Our advice is to go back to the roots of the capability concept and use it as you’ve originally intended: Describe what the enterprise does or is able to do, in other words, its potential. That’s what gives it strategic relevance. Business functions performed by the various parts of the organization can contribute to the realization of these capabilities, but don’t create both a detailed capability map and an equally detailed business function map that covers the same ground. It is advisable to use them at their own abstraction levels within a joined-up structure, e.g. using capabilities at the topmost two or three levels to express the high-level abilities of the enterprise.
Use business functions for more detailed levels, closer to implementation, to express the concrete activities you perform to deliver these higher-level abilities. In this way, different parts of the organization may also have their own distinct business function structure to deliver the same capabilities. If you then relate the various other elements of your operating model such as the people (e.g., departments, teams, roles), processes, technology and information to these business functions, you create traceability between capabilities and their realization(s).
Now you know how you can relate a Capability Map to the operating model and which pitfalls you should avoid when collaborating with different stakeholder groups. This was just one of the blogs in our series, where we aim to show you how Business Architecture and Capability-based Planning help you in supporting strategic planning and decision making in your enterprise.
If you are interested in learning more about how capabilities relate to your operating model, please contact us. We have a wealth of experience in enterprise and business architecture and are happy to demonstrate to you the powerful features of our Horizzon platform supporting these disciplines.
Look out for our next post in our Blog Series: Business Capabilities and Capability-Based Planning, where we’ll show you how a Business Capability Map impacts the wider business architecture context. Stay tuned!
