With no small degree of sarcasm, I think that I’m not being controversial if I say that capability-based planning is a standard activity within enterprise-level organizations. By itself, it makes absolute sense as the starting point for planning transformation. But I’ve always been a little uncomfortable with the approach of taking these capabilities, then mapping out the business and application (and possibly technical) layer changes needed to support them.
The reason is that capabilities might be delivered by business processes and business functions and application functions and the like, but how well they get delivered also depends on factors that often get overlooked in this discussion. I’m talking about the skills, the mindsets of organizations, the traditions, the existing contracts, and so on - the whole nebulous cloud of factors that some writers refer to as Corporate DNA.
The key point about this concept is that the existence of Corporate DNA is right and proper and acts as a value multiplier to the organization’s ability to operate in its chosen arena. The problem comes when the organization wants or needs to operate in a different one. To quote one business blogger who wrote about the concept - “I would bet you any amount of money I could get to The Gap faster starting from scratch than starting from Walmart.”
So it turns out that this is my problem with capability-based planning; implementing the changes is more than just changing processes or implementing new ones, amending applications or deploying new ones. It often also requires a change to skills, to mindsets, to ethos. It’s also why I like the term Corporate DNA – if the organization wants to mutate into something new, it has to change its DNA.
An interesting idea, perhaps, but what use can we make from this observation? What actionable suggestions are there, that we can extract from this idea of Corporate DNA? The main suggestion that I extract from this is that we can model some of these factors, in order to identify them and to plan for any changes that might be required. After all, the purpose of a model is to make a situation understandable.
Two things make this a bit more interesting, however. First of all is the decision on what modeling entities you use to represent things such as skills and share values, and mindsets. Here I’m going to use the ArchiMate language, since it has the widest support that I can see.
Where skills form part of capabilities, you could argue that we could model the skills as constraints on the capability. Corporate values can be expressed, not as ArchiMate values (which represent the value gained from something), but as drivers or as goals, depending on how specific they are. Existing organizational practices also seem to make sense expressed as constraints, where they restrict what the organization can do.
The second factor is more subtle – at first, it might seem that the very act of distilling the corporate DNA into formal modeling entities is an impossible task – what are the factors that make up the DNA?
However, it is actually the effort involved in separating out the components into distinct factors that is the major use of the exercise.
Corporate DNA can be an important factor in business transformations, so anything that helps the understanding of an organization’s corporate DNA has the potential to be very useful. Examining how we can model the factor that go make up corporate DNA turns out to be a valuable exercise.