Measuring Maturity in BPM - Automation is the wrong answer

I'm working on a BPM effort right now.  I've spent a bit of time talking to business users inside my company about Business Process, and how they'd like to see us become more of a process oriented company.  Then I compare what they are saying with what the IT industry values, and measures, and I'm seeing a huge gulf.  Basically, IT doesn't get it.

Aside: there's real value in becoming a process oriented company.  For folks who need a little convincing, consider checking out this little book (BPM is a team sport, by Spanyi) from your local library.  It's dry, but a lot less dry than most BPM books... fairly consumable.

Part of my effort is to understand the answer to this question: Assuming we all agree that BPM is a good tool, how do we know if we are using that tool well?  In short, how do you measure the adoption of BPM?

And there, to answer that question, is a Maturity Model from Gartner.

And it is wrong.  Ouch.

First some background:

It has been almost two years since Gartner unveiled their BPM Maturity Model at a Gartner conference.  Here's an interview with Jim Sinur, one of the two authors of the approach.   Unfortunately, I can't put a graphic up on my blog without violating Gartner's IP, but the interview provides some insight:

Intelligent Enterprise (IE): Can you recap the maturity model you unveiled at the Gartner BPM Summit?

Jim Sinur (JS): There are five stages: process understanding, process control, enterprise execution, corporate performance management and, last, competitive differentiation. You start modeling and measuring in the process understanding stage. In the second stage, you're doing more optimizing and tweaking. This is where you take advantage of rules management and optimization. In the third stage, you craft a cross-enterprise process architecture and maybe extend that to your trading partners. In the fourth stage, you instrument a framework of corporate performance management goals against the actual process.

Let's dissect that, shall we?

• Level 1 - Modeling and Measuring. 
• Level 2 - Optimizing and Tweaking
• Level 3 - Cross-Enterprise Process Architecture
• Level 4 - Instrumentation of Corporate Performance Management Goals
• Level 5 - competitive differentiation

OK, here is where I make a confession.  I have read the original material.  I won't quote directly from it, but I can assure you that it describes the path from Level 1 through Level 5 as a series of 'events' that trigger a growth in maturity.  Understand the events, and the competencies, and you have a maturity model.  

In other words, if you are at Level 1, and your business is happy creating models and measuring things, you may reach up one day and say "hey look!  We measured the time it takes to issue a purchase order, and we think we can improve it."  And now, you are on your way to level 2.

Does anyone ask why the business would put in a measurement in the first place?  It costs money to collect information.  Why do this?  Because... they want to measure a process.  Reality check: process orientation comes first, probably in a small setting, long before measurement takes hold.  So you can't say that metrics lead to process management, if process management is a prerequisite to metrics! 

So what brings in process orientation if it is not for the sake of becoming efficient?  I'll get to that in a minute.  The important point is that a maturity model is a system of measurement. And if you want a particular outcome, it pays to measure the right thing.  The Gartner BPM Maturity Model measures the adoption of BPM for the sake of efficiency. 

Let me harp on that for a moment.  In the Gartner model, we do BPM to become efficient.  Each step describes motivations, and outcomes, in terms of achieving the goal of operational efficiency.  We are more mature when we have created an end-to-end view for the sake of efficiency.

Yet, as I've spoken with people around this company, people who use process management to get results, not one person speaks about trying to achieve efficiency.  

That doesn't mean we don't care.  We do.  But that is not how to measure BPM, because if you do measure BPM on the basis of efficiency, you are missing the big picture.  And that is why the Gartner BPM Maturity model is wrong.  It measures the wrong thing.

Still holding your breath?  Let's go back to the key question: What brings in process orientation if it is not for the sake of efficiency?  Why does the business spend money on developing process models?

Two answers, both good:

1. Customer retention.   Business Process modeling helps you to understand the customer's processes.  With that understanding, you can communicate with different business teams, in order to improve the customer's experience of the company's product.  You can change your processes so that the customer doesn't have to jump through hoops.  They feel valued.  They buy more products.  Improving the customer's experience increases the top-line revenue while reducing attrition.  Big win. 
    
2. Time to market.  Process modeling allows the company to coordinate across different business teams.  With that understanding, you can bring a new product or service to the market quickly, because you can coordinate the efforts of many people. 

These are the reasons that a business will initiate using a process-oriented approach.  The Gartner BPM Maturity Model does not measure either one.  How well do you know your customers?  At what level of scope do you perceive customer issues: departmental, divisional, corporate?  How responsive are you?  Can you meet the needs of different customers?  To how fine of a level? 

Perhaps there are two models: one aligned to understanding the customer, and the other aligned to understanding the internal processes for the sake of communication, understanding, and consensus.  The latter method will eventually spawn a discussion of efficiency, but not right away.

The only thing more dangerous than measuring nothing: measuring the wrong thing.

Sorry, Gartner.

Comments

• Anonymous
  April 18, 2008
  I think the real issue here is that the maturity of the process is not the same as the maturity of the process capability. By that I mean that a company needs to build the capability to define and manage processes as well as building the processes themselves. The Maturity Model tends to measure that rather than the actual maturity of any given process itself. I fully agree with your statement about measuring the wrong thing (and indeed have blogged about that on my own site..)! Good post, Nick

• Anonymous
  April 19, 2008
  Great article, Nick! And very recognizable. And concerning Gartner, I lately attended a seminar where one of the Italian Gartner bobo's happened to dive into SOA for almost one hour, in front of a large group of experts, without mention semantics and data even once... It seemed a low mature and aged web services story. How can I respect their knowledge and understanding? -Jack  

• Anonymous
  April 20, 2008
  The comment has been removed

• Anonymous
  April 22, 2008
  The comment has been removed

• Anonymous
  April 22, 2008
  Hi Neil, I agree that you can't manage what you can't measure. Maturity models exist to provide guidance.  That is certainly the intent.  We want to guide organizations by letting them know where they are, and what the next steps are. We have to assume that an organization would use the tool to help them to reach a mature state from a less-than-mature state.  We want to describe the path to take to get there.  Otherwise, no reason to create it. And you can't start with a mature state.  You have to start where you are at.  Then, you work to the NEXT LEVEL, with the mature state sitting 'out there' as a final destination.  That is the guidance that a maturity model provides.  A maturity model doesn't just answer "what is the final destination" but more importantly "what is the NEXT destination?" At the end of the day, any BPM maturity model, regardless of source, has a predictable 'mature' state.  It is the closed loop of process modeling, measurement, control, and improvement, for the sake of customer alignment, time to market, and optimal cost, that you are describing.  On that point, I think we can agree. However, the steps in the middle are important, because those steps provide guidance about how to get to that end.  If the steps are poorly laid out, the road is more difficult.  A useful maturity model is one that provides guidance so that the road is an optimum path.  A "less useful" maturity model leads the subscriber down a suboptimum path, encouraging the development of capabilities in the wrong order, or for the wrong reason. The reason for moving from one stage to another matters a great deal.  You measure success through the stages of maturity, and therefore, each stage is a goal in and of itself.   Yes, Gartner's model looks at each phase and adds capabilities... but the specific capabilities, and the rationale for adding them IN THAT ORDER, is misguided.   Therefore, if you put efficiency before customer process alignment, or measurement before communication, it matters.  The path is suboptimal. And a maturity model that leads people down a suboptimal path is not a useful one.

• Anonymous
  April 22, 2008
  The comment has been removed