Explaining Capability Modeling to Business Process Professionals

As I’ve noted in prior posts, many hard working business process management professionals find the concept of “Business Capabilities” to be confusing at best, and counterproductive at worst.  In a recent article in BPTrends, Paul Harmon made the following statement:

the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.

This confusion is well known to me.  Within Microsoft, we have a very strong group of senior professionals who base their efforts and practices on BPM concepts.  This includes Kaplan and Norton’s Balanced Scorecards, as well as methods like Six Sigma, Lean manufacturing, and Total Quality Management. 

BPM is my world too.  As readers of my blog know, I am fortunate enough to consider myself to be a follower of these same ideas, having been exposed to TQM while I was working at IBM almost 20 years ago.  I’ve worked at many levels of process improvement. 

• At the business level: I’ve worked to convey the need for process improvement and help the stakeholders feel comfortable with methods,
• At the modeler level: I’ve worked to collect the ideas of stakeholders and map out both current state and future state,
• At the analysis level: I’ve worked to take models and analyze them for opportunities, target waste, and develop innovative alternatives, and
• At the technical level: I’ve implemented a number of BPM systems and even wrote one of my own. 

 

That experience lets me have a good relationship with both my EA peers and my BPM peers.  I’m aware of both approaches, having done both.  As my readers may also know, I use business capability models in my daily work.  I create models of capabilities that are useful, valuable, and understandable.   I know the value of capability modeling.

When I talk about business capabilities with my peers, I have to be careful.  Business capabilities are poorly explained and poorly socialized.  It can be tough to convince a BPM professional to listen to these “radical” ideas when we, the community of architects and analysts who also use business capabilities, have communicated so inconsistently about them.

First off, let’s look at the environment we work in.

Business process management practices and techniques are widely used.  In many cases, they have produces very valuable results.  However, the field is still quite young.  As in any young field, there are failures as well as successes.  I’ve seen projects succeed, and been quite proud of them.  I’ve also seen projects attempt to use BPM practices, waste time and money, and produce no real result.  The team would usually deliver something, but often that delivery occurred in spite of the process efforts, and not because of them.  Like any tool, using it well produces good results, and using it poorly… doesn’t. 

Let’s start with a problem

We all have to solve business problems.  Sometimes, you need to approach a problem one way… and sometimes a different approach is called for.  Business process modeling is a powerful tool.  Business capabilities provide an additional tool.  Sometimes you need to use them. 

Let’s look at one of those times.

Joe Freeflier is a business manager in the finance group of his large company.  The company has five divisions, each with completely different business models.  The divisions operate quite independently of one another.  They don’t share the same sales force, and they don’t really speak with the same customers.  Each division has its own plants, and its own workforce.  Joe, unfortunately, works for corporate.

You see, Joe is responsible for maintaining a set of business controls, as well as insuring that each division’s revenue recognition systems and processes are compliant and auditable.  He can see how the transactions appear on the general ledger, but he also has to make sure that some basic rules are followed in order to insure that the company is behaving in a legal and responsible manner. 

Joe has a couple of teams.  One team is focused on a large merger that the company went through in January.  His team is working with this new business to merge their financial systems with one of the existing divisions.  Another team produces important reports for the senior staff, some of which feed the quarterly corporate reporting required of publically traded companies.  A third team performs spot audits and works with the divisional finance leads to insure smooth reporting all up.  Joe’s customers are really the divisions themselves… and each of those divisions have their own business processes.

Joe needs some help.  The new merger has caused some churn.  His team is having a hard time working with the new business unit, and his manager has told him not to “govern them out of business.”  Now, Joe meets every month with Jürgen, his contact from IT, and at one of those meetings, Joe vents about his current problem.  Jürgen suggests that Joe speak with his business architect Sally, and a meeting is arranged.

Sally spends some time working with Joe to understand his concerns, and now has two choices. She can suggest either a process-centric approach or a capability centric approach.  Sally does not know if the problem can be fixed with a business process change.  She doesn’t know if the tools need to change, or the policies need to change, or the information collected needs to change, or if it is a training problem.  She just knows that Joe needs help.  Let’s walk through her thinking:

Process centric:

Sally knows Joe’s business goals and the controls he needs to insure.  She proceeds to spend time with each of Joe’s divisional customers to map out their business processes, making sure that she is fairly accurate yet high level.  Three of the divisional teams have never mapped out their processes, but one has.  She starts there, and the process looks like a standard she is familiar with.  Unfortunately after interviewing some of the staff in that division, it is clear that they don’t actually follow that particular process.  So she falls back to a standard definition from an industry group, and spends a couple of meetings getting everyone to the same very-high-level process model.   Ten weeks have gone by, but she’s made some progress in understanding the landscape. 

Now, Sally visits the newly merged team and spends some serious time understanding what their existing process is, and how it may be different.  She finds that their business is based on a kind of “consignment” financing mechanism, and the revenue recognition processes that Joe uses have to be able to handle a number of new business events that he never dealt with before.  So she returns to speak with Joe about tracking these new events, and trying to fit the new financing mechanism into his controls.  Joe puts two of his team onto a small project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system.  As it turns out, Joe doesn’t need to change his processes… what he needs is to change the way information is collected to adapt to new processes.  Joe creates his controls, and creates a set of IT requirements for the IT team to fulfill.  Sally is done.

Sally was successful, and her effort took about four months to do.  Along the way, she learned a great deal about the financial processes, and four divisional leaders now have a process model for their work.  Remember that three didn’t feel the need to create one before, and the fourth didn’t use their model.  Six months later, none of them refer to the process model at all, and it has become “shelfware.”

Capability centric:

Sally knows Joe’s business goals and the controls he needs to insure.  She spends a few days working intensively with Joe.  She has a capability taxonomy that she brought with her from another project.  Her first goal is to get a small list of capabilities that Joe sees as valuable.  After about three or four days, she has a list of capabilities that his team needs to perform in their duties.  These capabilities are “bits of process” that his team owns and needs to do consistently, regardless of the higher-level processes that his customers use.  They are the “standard parts” of processes that his customers have taken a dependency on him to perform well. 

Now, Sally visits the newly merged team and spends some time understanding what their overall process is.  Note: Sally is looking at their process!  She looks to see whether the new unit would benefit from Joe’s finance team and looks for ways to plug Joe in.  It becomes immediately apparent that Joe has some expectations that won’t fit their business.  The new business is based on a kind of “consignment” financing mechanism, and Joe is assuming a more traditional supplier-retailer business relationship.  So Sally comes back to Joe and asks him for details about his assumed business processes.  She works with Joe for another week, charting out a narrow slice of business processes from Joe’s point of view.  She then goes back to the new unit and maps out the same narrow space on a process model.

She presents these two process maps to Joe, who now understands the problem.  Joe puts two of his team onto a small project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system. 

Both methods got to the same result.

The capability effort got us there much faster.  Using business capabilities to identify the problem, and narrow the focus of the team, Joe was able to get his team to solve the problem within about four weeks of Sally’s arrival.  She didn’t have to meet with the divisional leaders even once, and she didn’t produce an all-up process model.  Had she stuck with the process-based approach, it would have take three times that long.  Along the way, the process approach produced an interesting model, but it was not later used by anyone. 

Note that, according to Lean manufacturing, the intentional creation of an output that is not actually used by anyone, is waste.  The use of capabilities allowed Sally to remove the wasteful act of creating a high-level process model. 

What I did not do

I did not answer the question: “what is a capability?”  It was not my goal, in this post, to answer that question.  My goal is to show my friends that a tool produced a good result.  If my friends want to use the tool, defining it is unnecessary.  If my friends don’t want to use the tool, defining it won’t matter.

Did you learn what a hammer was by having someone define it to you, or by swinging at a couple of nails? 

Was this a contrived example?

It was an example derived from experience.  That said, there are equally compelling examples where using the word “business capability” generates confusion.  If Sally had gone to the new business unit and had said “I know you look at things as end-to-end processes, but I want to introduce you to the concept of business capabilities,” then she would have failed in her job as a business architect.  Sally could no more use capabilities with the new business unit than she could have taught a teenager to drive by teaching him how to overhaul the transmission. 

Capabilities are a complexity.  Some business stakeholders live at that level of complexity already, and they WANT to work at that level.  For them, capabilities make sense.  Other business stakeholders live at the highest levels of end-to-end experiences.  For them, capabilities make no sense at all.

Technorati Tags: business process management,business architecture,capability modeling,process modeling,enterprise architecture