Gentle reader: can you help me to solve a debate?
Introduction
Many companies have adopted the practice of capability modeling in the past few years. Often, this is done to align the portfolio of business initiatives (and often, IT projects) with corporate strategy. Many folks, including our own Microsoft Services Business Architecture (MSBA) consultants, view capability modeling as both a great business architecture practice (it is) and a great way to align SOA to your portfolio (it is that too). Internally, Microsoft IT has adopted capability modeling with a great deal of success.
Unfortunately, the way that capability modeling is described today, there is an element of business architecture that is “outside” the capability mindset: business process. Capabilities are often defined as a ‘mapping’ to business processes, but there is little or no attempt to include process modeling in the capability modeling approach.
This could cause some confusion if you are not careful. Many companies have long-standing efforts to describe, optimize, and reuse their business processes. These efforts are led and guided by various methodologies including six sigma and lean engineering.
So if your company is a process oriented one (or becoming a process oriented one), how do you fit in capability modeling? Do these two methods conflict?
I do not believe that the do. In fact, I believe that they are quite complimentary… but you have to take a moment to see how they relate. The debate that is going on at the moment: how do they relate? That’s where I’d like your opinion.
Perspectives
In process modeling, you divide up the things your company does into high level cross functional processes (like selling, marketing, fulfillment, etc). Breaking down processes into sub-processes, and sub-sub-processes, you eventually get down to activities. (I use the same definition as the Workflow Management Coalition: an activity is a unit of work. Think of it as the leaves of the process tree.) Process modeling is essentially concerned with how these activities are done.
These activities are interesting from a SOA standpoint, because the activities are where you actually perform automation. You connect services to these activities. This is where work is done.
Unlike process modeling, capability modeling attempts to separate the “what” from the “how.” The capability view is quite understandable for the business, and unlike process modeling, doesn’t require considerable training in order for the business to describe itself. I’ve seen a group of four business architects analyze a business, and adapt an existing capability taxonomy to it, as a PART TIME EFFORT, in a couple of months. All this while holding down their other responsibilities. If you don’t have a group of architects to call upon, like we do, tailoring such a hierarchy can be done in a matter of weeks using a full-time Microsoft consultant. Maintaining the hierarchy is fairly simple. Using it is quite valuable for project portfolio alignment, both in the business and in IT.
With capability modeling, you create a hierarchy of the company’s capabilities. You then identify the capabilities that best align to corporate strategy, and which one of them need the most work. Focus your work there, and you get a big payoff through focused investment.
Microsoft is an interesting bird, but I don’t think we are unusual. We want to do both. Which unfortunately means that, unless we are careful, we end up with two hierarchies. No one wants to maintain that, and we don’t get consistent benefits if process modeling and capability modeling don’t work together. But how to combine them?
There are two opinions within this company.
Opinion A
In this understanding, the notion of “Capability” is a good way to create the top levels of a hierarchy, while process creates the lower levels. This requires discipline because you have to limit the hierarchy of capabilities to one or two levels. On the other hand, it is not possible, after just a few levels, to describe “what” a company does without making assumptions about “how” the company does it. This view is illustrated with the diagram below.
Opinion B
In this understanding, the notion of Capability is related to the objectives of specific organizational units within a company. This is a totally different perspective, in that we are intentionally saying that capabilities should look like the organization itself, an the business should “see itself” in the capability hierarchy. There is little or no attempt for capabilities to be mutually exclusive from one another, and they can go down to five or more levels of depth. Therefore, the fact that the support division sells support contracts, while the retail division signs up retailers using retail contracts, both of which ‘sell stuff’ is not a problem, because we are less concerned with redundancy in the capabilities themselves. Where we find uniqueness is in the activities.
In this view, activities are a shared and linked resource, managed in a database of activities. A functional view would assign particular activities to a particular business unit or department, which reports in an organizational chart up to a senior leader and eventually the CEO.
Business processes are ways to thread those activities together, respecting the fact that sometimes different departments MUST perform the same activities, but that they don’t have to use the same processes to do it.
What do you think?
These two opinions are quite different. Perhaps they are both quite useful, and the choice of which to use depends on your company. Perhaps, one is optimal and the other is suboptimal, and you should avoid one and use the other.
I’d love to hear your opinion. Personally, I like “Opinion B.” But I reserve the right to be wrong on this.
Your turn to vote. I’d love to hear your thoughts.
PingBack from http://microsoftnews.askpcdoc.com/soa/merging-capability-modeling-with-process-modeling
Opinion A: I don’t like the idea that capabilities are performed by a process.
Opinion B: Does the hierarchy of capabilities have to look like the organization itself? I do not think so, but if you think so isn’t this the case for Opinion A too?
My vote goes to Opinion B. Relating capabilities and processes gets easy and natural when you think along these lines.
+1 for Option B. My concern with the process-oriented approach is that processes that may span multiple capabilities and organizational units are too difficult to manage or govern? Who "owns" the process? Who funds it? I think option B, whereby capabilities (exposed via services) are orchestrated to form processes is the most flexible and ultimately useful of the two.
Thanks for insightful post. Out of curiosity, do you ever read Steve Jones’ stuff? He often talks about similar topics.
Hmmm there seem to be two issues here for me.
The first is how your organisation is structured. Is it functionally oriented or process oriented? THat in itself will drive you to one option or the other.
The second is the size of the organisation.
If you are a massive multinational with hundreds of products and services that might drive you to option B where it’s easier to design and exert control over the things done.
If, on the other hand you are a one location, four or five products organsaoiitons, maybe option A is better for you, as the integration is easier.
Anoher dimension is the dynamism of your marketplace. How fast do you need to be moving to stay in the game/ahead of the pack?
If tings are relatively stable (eg you are the department of main roads) then the process path seems to me to be better as it will put efficiency ahead of effectiveness. If you are a market leader in a tough high value industry, maybe you need to look at effectiveness first and efficiency later.
Does that make sense? Do my assumptions align with your model?
Hi Craig,
I like the way you think. There may, in fact, be more than one "right" answer. It could depend on the size and complexity of the company, as you suggest, or the maturity of the process-orientation efforts.
Assuming that there is a model you would use for the most complex of situations, and we simplified from there depending on the situation, would you use "a" or "b" to model that "most complex" scenario? It sounds like you would vote for "b" in that case.
— N
Doesn’t this depend on which operating model your organisation pursues? If it is operating under the Replication or Unification model, then would you not define a single capability map, but under the Coordination or Diversification model would you not define a different capability map for each division?
This then defines the extent to which your organisational structure influences your capability map.
Once you then had your capability maps, would you not then just define the business processes that support each capability independently? These business processes would of course interact, but would do so through an event-driven model.
One business process in one capability would raise business event, which would then trigger other business processes within other capabilities.
Hi Bill,
First off, I agree that the operating model is an important variable in how any particular company uses the relationship between capability and process. Unification and Replication companies have one architecture (although Replication has many instances). Diversification has many architectures because there are many companies. Coordination is the most complex, with one information architecture and many application and potentially technical architectures.
However, you make an interesting statement. You say "would you not then just define the business processes that support each capability independently?" In that, I’m reading that you feel that capability is a high level structure, and that business PROCESSES fall under them, not business ACTIVITIES. If so, then you are essentially voting for opinion "a" (which is fine).
As I go through the literature (Read through Rummler and Brache this weekend), there is a lot of discussion about the fact that these two aspects are related, but not a lot of discussion about HOW they are related. If you need to put something into a database, you need to be pretty good about understanding the relationship.
— N
I am more inclined to go with Option A. I see business capabilities being a taxonomy for your business processes. In a typical retail or manufacturing enterprise, you would have business capabilities such as "Develop products and services", "Sell Products & Services", etc.. To me, these provide a high level categorization for the business processes in the enterprise. It provides the opportunity for process variability depending on the operating model but at the end of the day, the business capability is the same no matter the operating model (Unification, Replication, Diversification, Coordination).
Hi Brian,
Sounds like a vote for Option A.
Do you see processes like "Order to Cash" in your environment? How would you handle that if the capabilities like "Sell Product" are at the top level? Perhaps "Order to Cash" isn’t really a process?
Not trying to put you on the spot. I’m honestly asking.
— Nick
Enjoying the discussion,
We have a capability object that I believe fits the above description but we are looking at this a bit differently and I would like to get some feedback. We have it placed capability as a logical part of our application architecture. It is tied to our application (again logical) and also to an object to represent the physical software. The intersection of this defines a usage scenario or specific implementation of the capability using specific software. Since the capability is at a logical level we tie it to the process model at a lower level but not at the activity level. The usage scenario would tie more closely to the activity level.
Our thinking is we needed capability in this place to answer questions like how many processes are supported by the same capability, how many software solutions support the same capability, what applications use what capabilities, and what capabilities do we have that we are not using (software capability not deployed). We see this as a key part to understand how to consolidate, harmonize and enhance our business by understanding capabilities from an application (logical) perspective and then tying it to the business processes that use them.
I understand that some of you may be thinking not all capabilities have software supporting them. We do accept that and would have capabilities within an application, tied to a business process but there is not any software. Essentially this is a non-system supported capability. This may represent an opportunity going forward as technology or the business process changes to automate that capability. This is another perspective we are expecting the placement of capability to help us identify.
So we are not option A, closer to option B and could easily add in the second hierarchy shown in B, but not sure what it would add.
We are very early in our modeling and would encourage feedback on this, especially gotchas that we may need to watch out for or concerns you may have around this approach being successful.
Thanks, Andy
Hi Andy,
I’ll confess. When I presented this discussion, I took a very small portion of our metamodel and exposed two opinions about that portion. The metamodel that we use certainly extends to the same places that your model does.
I’m glad to hear that you have modeled logical capabilities into logical applications. We have done the same, but we used different words (of course). The concepts are identical. The fact that two people come to the same conclusion, independently, means a great deal to me.
So I like your concepts. We use different words, partly, because the word capability is used in SO many ways already. Early on, there was a proposal to model ‘application capabilities’ just as we are modeling ‘business capabilities’ and ‘technical capabilities.’ The odd thing is that the business and technical architects both wanted to use the same word.
We backed out of using the term ‘application capabilities’ to avoid confusion.
So we model logical applications (we call them solution domains). And those logical applications have ‘features’ (our word that maps to your definition). It is not a perfect word. There are no perfect words, but it works for us.
One thing that I like to keep seperate is the notion of ‘requirement’ from ‘feature.’ We want the business processes to dictate a desire, and from those desires come requirements. Have you ever noticed that processes are rarely performed exactly as described? Life is messy. Processes are neat. They are a mere shadow of reality. On the other hand, they reflect a desire for orderliness, for a lack of variation, and a consistency that delivers efficiency… and those desires are the requirements that we are trying to live up to.
So we don’t use ‘application capabilities.’ Our terminology is not consistent yet, but we are getting closer. For us, the business needs capabilities. Processes interweave those business capabilities together. Business systems provide features that support those business capabilities.
That much we all agree on. The rest… well, that’s what this post is for, now isn’t it?
Nick
Yes I imagine Microsoft businesses would be best addressed by B.
I also think B sets you up for beter flexibility and leveraging opportunities for the future, so there is another dimension;
Are you trying to stabilise the business or disrupt it for innovation opportunities?
A bit late to weigh in, but I believe BPM as a management discipline/theory is all about B, and typically poses A as the "old" stovepiped way. In reality, most organizations getting started in BPM implementations (i.e. automated solutions) do not tackle cross-functional processes right away… too hard. But B is the goal.
Thanks, Bruce.
A few weeks ago, in a blog post , I asked about the relationship between business process modeling and
I came to an approach that fits closely with Option B. The challenge was how do you describe and understand the many aspects of something as big and as unique as a business. An understanding of the business strategy answers the WHY question. The capabilities describe WHAT the business must be able to do to follow the strategy (logical activities described by what they achieve, but not how). These are grouped into the most appropriate higher levels of capability grouping for navigation and communication. The processes describe HOW the activities are performed in a given context or scenario (a more physical and detailed description of the activities and their sequencing).
The key for me was establishing the activities as the central building block for a model that could be presented through many views for many audiences. This is the easiest level to get a common understanding. The activity has a capability description which describes what the activity does or achieves (the black box view). When in a process context it is described in more physical terms, with resources and enablers (an implementation view). The same activity can appear in many process (e.g. goods receipt).
This provides an inventory of business activities with a WHAT view and linked contextual HOW views that can be accessed through the two perspectives described in option B. I also apply a similar capability and contextual implementation view of an inventory of services that are candidate enablers for the activities. This links the strategy through to activities and services and identifies business value. A strong theme for me in this approach is that the capabilities can be analysed with heat maps and are more stable over time than a purely process view. By understanding and managing capabilities they provide a strategic platform for more agile processes. Focusing on processes only doesn’t give the same flexibility.
With both perspectives the grouping of activities into a capability hierarchy or processes depends on the audience. I prefer not to have a process hierarchy but just to be able to view the links between a series of activities between 2 selected events within a context I describe as a scenario.
Hi Antony,
Perhaps your situation is different than mine. When I describe this reference architecture, some people understand it, and some do not. The capabilities view appeals to people whose frame of reference is organizational or functional. They sign up.
But for people who need to see cross-functional processes, who want to optimize along the lines of a process, or want to examine the customer’s experience across an entire process, they need a ‘front door’ to not only find the processes, but to MEASURE the processes.
Without a process heirarchy, there is no way to create a roll-up measurement framework that ignores the organizational boundaries and focuses on the customer experience and operational excellence.
So while I agree with the idea of placing ‘activity’ at the center, I would find a reference model that lacked a process heirarchy insufficient.
Nick,
A very good discussion.
I agree that a process view is essential as the activities have to be put into a number of named processes. By not being keen on a process hierarchy I really mean describing processes within processes within processes. In my experience this has lead to inconsistencies in representation. Activities for examples found sometimes at level 2 in other places at level 4. I’ve also found many different views about where a process starts and ends and this to me depends on the audience. End to end to me is made up by connecting together many smaller processes but all at the same level i.e. the level that contains activities. I read this as been consistent with option B … " connects many ".
My front door would be a grouping of processes into a process area. This to me this is for navigation and the criteria for grouping. So in my approach I cover cross functional but have measure at various point horizontally rather than rolled up.