Capability Modelling
Introduction
Capabilities are one of the most misunderstood concepts in modern businesses. The idea isn't new, you only have to look at how the defence and nuclear industry have used this term for over 20+ years. Quite often people use the terms capabilities and function interchangeably, but it's important to note that they are NOT the same thing and can NOT be used in this interchangeable manner. In this section of the TOGAF® AIDES Space, we attempt to define capability and demonstrate why it's not just a function.
Capability can be defined as - the ability to achieve a desired effect/outcome in a specific operating environment, it is a logical construct that is made manifest through the components of an organisation.
Conepts
Capabilities are high level building blocks that can be arranged in a number of ways to allow an enterprise to achieve it's goals. Let's try and resolve the mystery surrounding this term.
Consider a situation where you are looking to employ the services of a builder to do some work on your home. What key characteristics would you consider when you're looking to employ someone in this role?
- what skills do they have (physical competency - bricklaying, plumbing, electrical work, roofing, carpentry etc)
- what are their competencies (education, qualifications and areas of knowledge - bricklaying, plumbing, electrical work, roofing, carpentry etc)
- what will they charge and what is the payment model
- what's their work ethic (turns up on time, is diligent and doesn't leave a job half done, honesty)
- how quickly they get the job done - can they deliver in the time allotted
- customer relationship management (how much they keep me informed about the costs and what they are doing) - communications skills
- have they go the tools for the job (good knowledge of the right tools for the job) - equipment
- what is the quality of their work (consider TQM as defined by Toyota)
- how well organised are they, this will involve the team around them and how effectively they work as a team
- how well they understand your requirements
- how well they understand building regulations
In this example you are measuring how capable the builder is using a number of criteria as listed above, your measurement isn't based upon just the service they offer.
Use the following statement as a guide to your thinking "being able to do building work doesn't make you a competent/capable builder". Most people can run (to some degree), this doesn't make them a capable runner, that capability only comes from training, eating well and plenty of sleep. In other words there are a number of key characteristics that must be developed in order to enable that capability (see comment 1 below).
The next thing to remember about a capability is that in many cases the concept gets aligned against a business function, service or team, but it is none of these things. It is a logical entity with distinct measurable characteristics (as shown above in the building example) that work together to achieve a desired outcome. Typically a capability considers the following (a MOD perspective on the characteristics of a capability TEPIDOIL)
- skills and competency (roles/personnel)
- training
- philosophy (way of thinking)
- equipment (operational level)
- organisation (required organisation structure)
- information (data and processes)
- infrastructure (platforms, communications, and core primary services)
- logistics (pulling it all together)
Alternatively one could choose to define capability using the architectural unification approach POLDAT
- Process (business processes)
- Organisation (structures)
- Location (Geographical information)
- Data (models, life cycles, security etc)
- Application (software, security, interoperability etc)
- Technology (infrastructure)
Both TEPIDOIL and POLDAT pay no attention to organisation unit boundaries (business unit, sector, service, function etc) but weave a conceptual path through segments of the enterprise, selecting those areas within those segments with the characteristics required to deliver the outcome.
More often than not, an outcome is delivered through multiple capabilities
And these arrangements can come in all shapes and sizes
We can now start to see that as we weave through the different parts of the organisation we need to ask the following questions (to help define the nature and characteristics of a capability)
So in actual fact, the outcome is delivered through a set of POLDATs that execute in defined manner
The nature of a capability
Our next task is to try and illustrate the dynamic nature that exists between the elements described above? We know that there exists some kind of structural relationship between the elements and we've hinted at this in the models above, but the behavioural heuristics are an important part of understanding any system.
One approach that we are currently trying, is to map the thread of behaviour that is needed using an UML activity model. We do not use it to map a process flow but to simply illustrate the way in which a number of entities must collaborate to realise the capability. As an illustration of this we could use swimlanes to provide a visual way of representing organisational units and inner lanes to represent other elements within the model (do not confuse this model with value stream mapping, that is not what we are doing).
This model captures the weaving nature through our first example of one capability to deliver a goal |
---|
Each blue round tangle represents an activity or set of activities being executed (remember we are not mapping process flow)
In this example we show multiple capability paths delivering a goal |
---|
So how does this help me
That's a very good question and it depends on your perspective; there are several advantages that I would like to describe and I am sure that you can think of others.
Partnership to deliver a goal(s)
In this context the partners will have some clearly defined goals but, they will have similar or even the same set of capabilities which makes it easier to do like for like comparisons, allowing you to ignore the physical implementation e.g. comparing the check-in or baggage handling capabilities across airports. These partners will clearly want to know which of them has the best capability to help deliver the outcome(s). Once these partners have a clear understanding of each others capabilities, they can decide amongst themselves which one of them should bring which capability to bear to deliver the outcome.
Another example would be a food retailer wanting to expand it's geographic reach. It already has a national transportation capability (it's speedy, cost effective, small, can deliver varied goods, including food but not frozen food) but not an international capability. The retailer could attempt to expand its transportation capability - this could be costly and if the expansion fails it could be a cost the organisation dearly. It could purchase the capability from a logistics company or it could partner with another retailer that has the desired capability and geographic reach the retailer wants. The last two options would be highly favourable. The logistics company would be used to deliver goods of all kinds and would definitely have the infrastructure required. The other retailer if selected correctly would be bring brand expansion to the food retailer as well as other possible benefits.
Comparison strategy
If within an industry sector a clear set of capabilities have been defined, it becomes easier to compare companies within that sector without getting bogged down in the implementation detail (business functions, services, software and hardware etc).
A very good example of this would be training organisations. How would you compare a number of training companies.
Ref A
- size of the portfolio (single supplier to meet all your training needs)
- training schedule (courses run on a regular basis across many locations)
- geographical reach (ability to attend courses without having to travel 10s of miles)
- ability to deliver training in a public and non public manner
- quality of the delivery (the trainers have a reputation of being easy to work with and having a great delivery style)
- flexibility of courses (i.e. can be courses be tailored)
- programme delivery (boot camps etc, managed learning, apprentiships)
- the brand
- flexible and attractive cost models
Having worked in the training industry for 21 years I would categorise the core capabilities for a training company as
- portfolio size - the scale of available topics
- training delivery - the ability to deliver a learning outcome, involves courseware and possibly equipment
- portfolio management - the ability to make courseware available through authored courseware or purchased courseware
- customer relationship management - the ability to understand your customers training needs
We should be able to attribute these capabilities with characteristics listed above Ref A.
With just these three capabilities it's possible to perform a comparison of any number of training organisations
Industry alignment
You want to compete in a particular sector but the way in which you are structured and operate doesn't allow you do a like for like comparison with your competitors. So you take an industry defined capability model, look at its outcomes and determine how would you align your organisation up against the industry standard to bring about those capabilities to deliver those outcomes.
Creating new goals/opportunities
Once you have gone through the exercise of defining your capabilities (which when combined in certain ways deliver certain outcomes), it now becomes possible to combine those capabilities in other ways to discover what other outcomes can be delivered, in other words what opportunities do the new combinations create.
A good example of this is eTOM from the TMF (Telemanagement Forum)
Tactical alignment to strategic goals
Your defined capabilities are there to deliver a long term strategy. In the interim, pressure points force you to respond on a tactical basis to deliver certain outcomes. These short term outcomes require certain adjustments to your long term defined capabilities, the capability increments (up or down) result in work being done in your organisation to handle the pressure point. The aim is to not change the long term goals but adjust them to deliver the short and long term outcomes.
Defining your capabilities
Defining a capability is an extensive task but once done can lead to a major simplification in the overall understanding and modelling of a enterprise.
Start by looking for industry capability models for your sector. Ensure you have a clear understanding of the outcomes of each capability and which outcomes are delivered by combined capabilities.
If there are no industry capability models, begin by clearly stating your own desired outcomes. Now logically map out a set of capabilities that deliver those outcomes.
Once your capabilities are defined, begin to ask the questions shown in the diagram below (for each answer you will need to map it to what you currently do in your organisation)
Consider the following example, you want to build a home from scratch, core required capabilities
- architecture (building architect)
- building services (described above)
- garden landscaping
- land management (with planning permission) - a key resource !
It's now clear from the discussion above that there will be a certain amount of activities woven through each of these distinct capabilities to deliver the outcome of "Deliver built built house"
By simply concentrating on the capabilities, you can begin to ask the following questions
- maybe there is a company that is capable of doing all of these things for me
- if I clearly define and price each capability I will be able to go to market and buy these as building blocks
But it also raises a few questions
- if you go with option 1 above, you can leave it to the company to ensure that they have a project management capability to pull together the other capabilities to deliver the home
- if I go for option 2, I will need to understand each of the capabilities in order to ensure that they work in a coordinated manner. I.e. using POLDAT (what is the organisational structure I need to have in place to ensure that these capabilities function as one)
Whichever approach you take, the emergence of a complex matrix of capabilities to deliver our outcome will begin to appear
So the reality then becomes as shown in the figure below. Here we see that the individual who wants the house built must interact with each organisation, clearly outlining their goals. A set of capabilities (comprised from the functionality within those organisations) will be assembled to deliver those goals. Note we have only shown one capability per organisation but there may be many.