Mapping your processes and your technologies tells you what your organization has. But sometimes you also need to know what it needs.
In other words, if you were to build a bank - or an airline, or a power company, or a university - from scratch today, what would the parts on your shopping list be?
That might seem like a strange question. For the most part, organizations have already been built and the focus is on keeping them running smoothly.
But the job of building an organisation is never finished. Not only must organizations continually evolve to meet the demands of their markets and their communities, but they also need to optimise their own internal business and IT operations.
For example, you may need to change your processes to comply with new regulations; or merge two businesses together, understanding where they perform the same functions and where they don’t; or just understand how efficiently your existing processes and IT have been implemented for any number of reasons, including improving customer service, reducing cost and managing risk.
In fact, almost any time that you need to ask ‘what do we have?’ you probably also need to know ‘what do we need?’ The key to answering that second question is a set of Capability Models.
What is a Capability Model?
A Capability Model is a logical model of your business or IT.
What does logical mean here? Well, in this context it means that the model describes what needs to be done without defining how it is done. How includes who does it, which technologies are used, or where or when those activities are performed.
You can think of capabilities as a standardised set of requirements or ability to’s.
For example, a Business Capability model might say the company requires the ability to ‘Manage Customer Accounts’ without specifying which teams manage those accounts or which systems they use. Manage Customer Accounts is just something the organization needs to be able to do.
And while saying the organisation ‘Manages Customer Accounts’ without saying how risks just stating the obvious, the ability to split out organisational requirements from the solutions that fulfil them is essential to architectural analysis.
Because Organisations are so large and complex, capability models can get quite large too. The normal way of dealing with this is to build the models as hierarchies, with the top levels being broad-brush generalised descriptions of major functions or activities, and the lower levels describing those activities in progressively more detail.
So a high-level capability might be Finance, which consists of a number of sub-capabilities which describe in more detail the activities that make up the Finance Capability - for example Payroll, Tax Management or General Accounting; and each of those will in turn have sub-capabilities – for example, General Accounting will have sub-capabilities such as Project Accounting, Investment Accounting and Reporting, and Accounts Consolidation.
In this way, every part of a Capability Model can be decomposed or rolled up. So how detailed should you get? That’s a hard one to answer. Some people will say that Capability Models are always only high-level, but in practical terms that doesn’t have to be the case – nobody’s marking your homework here, and the most important thing is to make sure that they are useful.
A good rule of thumb is to build them to the level at which you need to make decisions, and then maybe one level below. For example, if you’re discussing Payroll systems or processes, then you need to go down to that level so you can distinguish Payroll systems and processes from others that are also related to Finance but not Payroll. Then having a level below Payroll helps everybody understand exactly what Payroll means.
Generally speaking, most useful Capability Models go down three or four levels. Any more, and there’s a good chance that you’re getting carried away.
Why Capability Models Matter
Okay, so the theory is straightforward enough. But it doesn’t answer the question of why we need such models in the first place. And without that, you may get some push-back over the need for them. After all, going back to our Manage Customer Accounts example, the teams performing those processes, or using those systems, know that they Manage Customer Accounts. And they are quite capable of performing – or changing – those processes themselves.
What’s more, if those changes involve coordinating with another team, then they can set up a meeting. And the CEO can distribute responsibilities among the branches of the org chart, and track the results on a Dashboard all without a set of models, can’t they?
Well, kind of. But it misses an important point: The various moving parts of your organization might be people, processes and technologies, but these really represent the implementation of something far deeper and more fundamental: Your business model. It’s the business model that defines the requirement for those processes and systems, and we express those requirements as capabilities.
But when they design those processes and systems, people are not working off a single set of company-wide requirements. Organisations are not built that way. Instead they’re built in a far more organic, bottom-up manner, with each business unit or department interpreting that business model in their own way.
The results are multiple processes that duplicate customer data; or multiple departments that go out and buy applications that do the same thing. When there isn’t a single set of requirements, then there is no standardised set of solutions. And while that’s not necessarily a problem – after all, organisations need to allow local autonomy to adapt to their markets without undue bureaucracy – it does allow for duplication and inefficiencies to creep in that carry very real cost, agility and risk implications.
So our Capability Models allow us to ‘see the wood for the trees’. Once we map what we need to what we have, those models act as an efficiency benchmark, allowing us to spot those inefficiencies and duplications, and even to articulate the cost or risk of that inefficiency.
For example, in this model where we’ve mapped our applications to our business capabilities we can straightaway see we have three applications that deliver Learning and Development. Do we need that many applications, with their attendant costs and supplier contracts? Whatever the outcome, we can at least see that this is an area that requires a closer look.
Business versus Technical Capabilities
It’s not just the business model that can be expressed as a set of logical ‘ability to’s’; we also need to do the same with our technology.
The need for a separate Technology Capability Model may not be immediately obvious. After all, isn’t the technology there to support the business too? So I have Payroll processes that use Payroll systems. Can’t I use one logical model to describe them both manual processes and IT systems?
Exactly right, and that’s the power of capability models – that they can describe manual and automated processes using the same language.
The problem is that using your Business Capability Model to describe your IT systems will not accurately describe what all your IT systems do. This is because while some software is specialised to perform a particular Business Capability or Function like paying customers or running marketing promotions, other software is generalised: It can also be used to pay customers, or run marketing promotions, but it can equally do a whole host of other things.
That’s because software of the first type is designed to do one thing and only one thing straight out of the box; the second type of software has to be configured to do so – but can equally be configured to do pretty much anything else.
Take this example: I have a SAP Accounting System which I use for running my accounts, and I have a Microsoft Business Intelligence System which I use for analysing those accounts. My SAP system is purely for accounting – I couldn’t use it for running a marketing campaign, for example. But I could use my Microsoft system for analysing marketing campaigns.
Why? Because out of the box, the Microsoft BI system doesn’t do anything but analyse data. What kind of data, in support of which business capabilities or processes, is determined by configuration.
But if I mapped my Microsoft BI system only to the Business Capability it currently performs, I could be misled into thinking it’s a dedicated Accounts Analysis system, and when I require a Marketing Analysis system, I’ll go out and buy another Application when I should have re-used.
So the Technical Capability Model is used to describe lower-level capabilities – such as data analysis – which can be configured to support multiple business capabilities. In this way, by mapping our IT systems to both models, we get a much more accurate view of how efficiently we’ve implemented our IT estate.
What’s the Difference between a Capability Model, a Function Model and Service Model?
There are a lot of related concepts out there in the world of enterprise modelling, and a lot of contradictory definitions. You may come across concepts like Function Models, Service Models or Logical Applications that look very similar, as well as seeing statements like “Capability Models are high-level, and decompose into Functional components” or “Capabilities are Delivered by Services”. It can get confusing.
But fundamentally, all these concepts are related to the same root idea of having an abstracted or logical description of your business and its systems.
Our advice is to keep it simple. You only need one set of logical business and technology models. Avoid calling them different things depending on their level, and avoid mapping multiple logical models containing very similar concepts together (e.g. “The Customer Accounts Capability is delivered by the Manage Customer Accounts Service which is fulfilled by the Customer Accounts Management Logical Application”). This kind of structure is hard to understand, hard to analyse, hard to communicate and hard to maintain. So don’t get hung up on what standards say you should do – focus on the simplest set of models that will give you the answers you need.
What’s the Difference Between a Business Capability and a Business Process?
Another common area of confusion is the difference between a Business Capability and a Business Process. You may hear statements like “Business Capabilities are high-level Processes” or “Business Capabilities decompose into Processes”. Neither of these are quite true.
To answer this question, we need to look at how Business Capabilities and Business Processes are put together.
A Business Capability represents a logical group of activities, and those activities are usually grouped by the fact they access a common resource – for example, a particular type of information.
So, for example, all the activities that access or update Customer information are grouped together. This means that these activities are de-duplicated i.e. if they appear in one part of the capability model, they cannot appear in any other part of it. And this is exactly what makes a Business Capability model an effective benchmark for analysing inefficiency or duplication.
A Business Process on the other hand represents a logical sequence of activities, typically in response to a common event and delivering a defined outcome. So sending a customer their account details in response to their request to open an account is a business process, that has a start event (the customer’s request) a succession of tasks or activities (logging the request, validating the customer’s identity, setting up the account) and an outcome (sending the account details to the customer).
But Processes can and do duplicate activities, which makes them a bad benchmark for analysing efficiency. Let’s take an example:
I’m a Brit, and like most Brits I drink a lot of tea and a lot of coffee and I like milk in both. So I might have a ‘Make Tea’ process and another ‘Make Coffee’ process. Both processes consist of a number of different steps. And while some are different (e.g. ‘take lid off coffee jar’ or ‘get tea bag from box’) many are the same (‘get cup’, ‘boil water’, ‘pour in milk’)
Now if I treated both processes as completely separate requirements, there’s a risk I might end up with two sets of cups, two kettles and two bottles of milk. But I don’t do that, because I intuitively understand the interdependencies between a process (make tea) and the capabilities (boil water) it requires.
That seems obvious when applied to everyday activities, but in an organisational context where communication between departments is often lacking and top-down process design is minimal, that understanding is often missing. So a customer’s address may get changed (or not changed!) in multiple different processes, or two departments go out and purchase different analytics systems with the same functionality.
So while understanding processes is essential for understanding how organisations create and deliver value, understanding capabilities is essential for understanding how to do that efficiently and consistently.
How Do I Get Started?
There’s a lot more to say about Capability Modelling, and we’ll add to this article over time, but the best way to learn modelling is to do modelling.
If you already have your own Capability Models then you can start loading them straight away. Check out our knowledge base articles on how to get them into Ardoq and, if you get stuck, reach out to us on Intercom.
If you don’t, well, we’ve given you a head start. Our out-of-the-box Business and Technical Capability Models are a great template to build on. You can add to them or delete from them as required, but take a good look down them before you start hacking. Whatever your business or organisation, you’ll find parts of them where they already give a pretty comprehensive description of your organisation and its technology, and others where you need to do a little more work.
You may also find you want to change the language to be closer to that of your own organisation’s.
Our one final piece of advice is not to get bogged down in the modelling or trying to build the perfect model. Capability Modelling is a means to an end, not an end in itself. It’s your ability to answer questions like ‘where can I simplify my IT?’, ‘where can I standardise my processes?’ and ‘am I investing my change budget in the right parts of by business?’ that make the models valuable.
And as ever, keep it as simple as possible - but no simpler!