BP Maturity Models

Sandy Kemsley in her piece today about BPMM (BPMM tutorial) clearly hasnt seen too many of these things.

Our old friend at Babson (Tom Davenport) has one, Gartner have a collection of slides for $795 (I am sure it is more than that), Bearing Point have one (The
Business Process Maturity Model: A Practical Approach for Identifying Opportunities for Optimization (overview free from BP Trends) … even a casual search on Google brings up a great number when you put in Business Process Maturity Model. But BPMG dont seem to make it to the first few pages. Every vendor worth its salts in the SOA space has one …

But none that I have seen have anything like the depth and breadth of that which is being discussed at the OMG next week (i.e. BPMM). Personally, I had a real “A Ha” moment (I know I have had a couple in the last 6 months …) during John Alden’s original presentation on the concept in June in Boston … I was writing (thrashing around) my paper on Corporate Agility and Process Innovation (available
free on the BPM Focus web site under White Papers). It was very much about at what point endless standardization of process needs to give way to innovation and personal freedom (the sort of thing that Jon Pyke alludes to in Why Workflow Sucks).

Legacy Thinking or BPM

Expecting Different Results When You Do The Same Things …

I am sure there are more of them - but here are a few that might resonate. I find that so many people are climbing on the band wagon of BPM that they dont even realize it when they are applying exactly the same thinking that caused their existing mess in the first place.

• “We are going to outsource implementation” … as in we are going to abrogate responsibility and find someone to litigate against once it all goes wrong.
• “Must get all our processes into a repository” … as in , lets spend 10 man years pouring stuff in the front end only to discover that 80% of it is out of date and we still haven’t got anything implemented.
• “Functional Requirement Specification” … as in, have you ever seen one that actually stood up to the test of time. Whatever the user signed off on was not what was really wanted.

But it goes deeper than that. We see so-called “experts” exhorting people to adopt one process modeling technique and ditch all others (see
here As Craig points out in his comment “In a way it is like learning a language (spoken or programming) you never really have a true appreciation for communication until you learn a second one.” (corrected typo).

We see many of the same old approaches trotted out with subtly different spin (I am thinking IDEF based decomposition here and all the raft of “methods” that went with it). Sure IDEF has its place, but not at the sharp end of helping people really get to grips with how things get done around here (or step outside their cosy little box). Exactly what ICAM Definition Language (and ICAM stands for Integrated Computer Aided Manufacturing) has to do with white collar office work and services is quite beyond me.

I am sure there must be other good examples of Legacy Thinking out there … a free copy of the book to anyone who can get past my BS filter (you knew there had to be a book aroudn the corner). Expect it end of Q1 2007 (which probably means Q2).

Business Process and Religion - Evangelism - Yes; Fundamentalism - No

I see I am going to have to dedicate more time to getting the blog out … but when I look at the broad range of tasks I have to get completed in the next 2 weeks I am back at the office - God knows where I will find the time.

Over the last 20 years I have found myself trying to help a broad range of people understand the various vagaries and wrinkes of business processes. But I have found a real difference in the receptivity between those people who know very little (and want to learn) those who think they know a bit (and want to be impressed). When introduced to a new modelling technique or approach, the common reaction is “why would I want to do it like that, I can always use <whatever technique I know already> to model that. What they seldom consider is what that new technique or approach might do for them, or how it might give them another subtle perspective.

So perhaps you will understand me when I say Business Process is a little bit like Religion - once people have been inured in one branch of the church, they tend to resist attempts by others to engage them (just think about Protestants and Catholics for a second - they have a lot more in common than they realize, yet they still seem to find each other repulsive). And the world of process is not that different. There are a lot of parallels between the differing factions of the business process movement, and those that one can observe in religion.

If you have been trained in UML, then that is what you want to use to model (everything must fit into that UML metamodel); if you grew up with IDEF, then all models appear as though they should be constructed around Inputs, Outputs, Controls and Mechanisms (or some other similar flavor). If Rummler Brache was your thang, then you favor the deployment flowcharts and swimlanes associated with the technique. Whether you have been brought up on LOVEM, BPMN or simple Fortran flowcharts, then the world is often colored by your original christening. It is only when you have been around for a while that you can see the benefits of the different approaches.

Putting all of that slightly different way, and maybe I am stating the obvious - a little knowledge can be dangerous. And in the world of business process, that is certainly the case.

As people search around for the meaning of life (or process) they discover different disciplines (new techniques and approaches). Sometimes, they become converted to a new religeon (say Pi Calculus, or conversational interaction loops of ActionWorflow) and feel it incumbent on themselves to act as missionaries, recruiting new sheep to the fold. Those that dont agree with them are clearly wrong, or misguided, or even worse, seditious. I suppose the point I am making is that while every branch of religion needs its evangelists, fundamentalism tends to alienate potential parishioners. And the problem with religion is that, for most people, once they have got some of it, they tend to shun all other approaches.

So by now, I hope you understand that I see the world of business processes as a pretty broad church. Personally, I am keenly interested in all process related innovation. But I don’t see that as a restrictive covenant that stops me from looking at, or even trying to explain, approaches that do not conform to some purists definition.

Indeed, I believe that it is only when you contrast different perspectives on a business process that you really understand it. You need to be able to step outside the box and see it for what it is. You need to be able to examine the interactions on one hand, and then flip it all around to look at the sequence flows; to look at what is required of the process and separate that from how it is achieved. With luck, the new BPDM metamodel from the OMG will enable the analyst to step around these different perspectives, sharing information between different modeling tools and techniques, without loosing the fidelity of the information.

Planes, Processes and Innovation

You board the jet and people eventually take their seats. I suppose I should have sussed that there were going to be problems when they didn’t board by row numbers or groups. A free for all at the Gate.

The Captain starts spouting something from the overhead speaker about 10 mins after the plane was due to leave. Something about a reported leak that had been checked already and fixed. “Phew”. But he continues … we now needed to get the paperwork sorted out. Oh oh! Everyone groans and rolls their eyeballs. It is going to take a little time. That’s OK you think … how long can paperwork take when you have 400 or so customers sitting on the tarmac in a very costly asset. 15 minutes later, he is on again. It seems that the only one who can sign the necessary paperwork is on the other side of the airport. It is going to take him 20 mins at least to get here. More groans. And you think – marvelous organization. After 50 mins, more we are told that the lawyers are now happy; we have the bit of paper that says something important to someone who will undoubtedly never look at it. But … you knew there was going to be another but, the plane cannot move now as there is nobody to unhook the jet-way. 20 minutes later, we are now unhooked but there are planes parked in the taxiway behind the gate (no doubt waiting to get in).

Finally, for want of a signature on a piece of paper (mandated by regulations) we are underway … a mere 110 minutes late. And the chances of that piece of paper ever being looked at again … not high.

Of course it is not only British Airways who have their process coordination problems (although waiting an extra hour and a half for baggage after a 2 hour delay does sort of rub salt into the wound … as this was the 4^th time since June that I had experienced a 2 hour delay I feel somewhat justified in naming them).

The point is that it is when things go wrong that organizations really differentiate themselves. And nowhere is this more visible than the airline business. Most regular travelers could tell similar stories of ineptitude and out of date procedures. But this is also a story about innovation.

Let’s change anecdotes. As any regular traveler will tell you, it is just a question of time till you leave some of your possessions on the plane. I had managed to avoid this affliction until earlier this year when, after a longhaul flight from London to Texas, I transferred to an internal flight. I got up at the end of it, totally discombobulated, and left my MP3 player, 2 sets of prescription glasses and the book I had been reading in the seat. Did I see any of the items again – not a chance.

Several hundred dollars later, I repeated the exact experience on a flight from San Jose to Santa Ana. Went in to the Lost & Found the next morning after several discussions with a telephone answering machine, the AA assistant there said something like “you realize we outsource our cleaning here,” as though that was an adequate excuse for the fact that they didn’t have anything written on any of the bits of paper in the office. But when I got back to the house, there was a message on the machine … “Mr Miers, did you loose something on your way back from SJC last night, if so, you better call and tell me.” Yippee – they found it.

When I went back the following morning, I found myself talking with the supervisor. His process innovation had been to apply a secret shopper mentality – to plant items in the planes that went for cleaning just to test the honesty and reliability of the cleaning company. As a result, all found items are handed in. As a result, a completely transformed customer experience. Like chalk and cheese. And when you think about it, the potential benefits of a BPM system to handle this sort of innovation are tremendous. Instead of having to go to the airport to physically get hold of someone it could be integrated into the AA portal. The gate staff could be notified, the cleaners informed of an item to look for, the supervisor gets to monitor whats going on … and so can the customer. Instead of a care-less attitude, it becomes a mechanism for building a relationship with the customer.

It is these sorts of opportunities to enhance the customer experience that really differentiates the firm – instead of having people like me whine on about poor service, they move me into the net-recommender category with something that is really very easy to automate.

I suppose the real question was whether AA has the management practices to first of all want to detect such innovations, and then distribute them to its other offices (they certainly could do with them in Austin). Whether or not such innovations make it all the way to full process support is not the point here - it is all about the management, and their attitude to process. 

A Process “A Ha” Moment - Two sides of the same coin - Orchestration and Choreography (and BPDM)

I was sitting in the Delphi BPIS Summit a couple of weeks back contemplating my closing keynote address and not completely listening to the speaker (Kevin Fickenscher) at the time who was doing a “call to arms” type of piece about how the world was changing (as if we didn’t know).

I shouldn’t sound disparaging, as the talk was actually very interesting. At one point he started to describe a concept he called “Simultaneity” (is there such a word I was thinking … having looked it up since, I can tell you there is).

He then went on to say that in Perot Systems they have literally thousands of associates working on a single client’s problem (system) at once. Really, what he was getting at was how things in the world often need to happen all at once, in parallel.

And it started a chain of thought – so how do you manage that (sort of problem). Or if you are say, Shell or Nokia with literally hundreds of different functions that need to collaborate on major projects; or indeed any large business attempting to deliver a consistent customer experience … just how do you manage that.

Ahhhh – Process. You need processes to help coordinate the various resources at your disposal. Of course!!

But the problem is that most people still think of process in terms of input output chains of activities borrowed from manufacturing. That notion of process doesn’t help you too much when you are talking about the coordination of multiple actors, operating in parallel.

And that chain of actors is increasingly up and down the value chain, no longer constrained to the familiar boundaries of the organization where command and control principles can apply.

What you need to do (as well) is to start thinking about processes as sets of “interactions.” This is the other side of the coin from the procedural notions of process that we are all so familiar with. Instead of solely focusing on the chains of activities with their (hopefully neat) sets of input-output documents, you also need to think about the protocols and agreements made between the actors. They represent the white space in between the functional silos, the hand-offs and commitments made from one party to another. Indeed, one could start to think about how a process is composed from fragments of interaction.

Having understood the interface requirements for your process, you can start to explore how your part of the business (value chain) wants to implement against that set of needs.

Really we are talking here about the difference between “Process Orchestration” and “Process Choreography”:

• Orchestration is a term used to describe the traditional notion of managed or directed execution, where activities are carried out, with branching and synchronization of different threads.
• Choreography is a more abstract notion of process (for most people). It is used to describe the “Interactions” of collaborating entities, each of which may have their own internal orchestration processes.

And this is where the emerging business process standards are starting to come to the rescue. The OMG “Business Process Definition Metamodel” (BPDM) provides the capability to represent the semantics of business process models, independently of the modeling notation. Think of it as a sort of “universal syntax” of process. The central idea is that BPDM is capable of supporting a mapping to the semantics of most common types of process model – whether that is BPMN on one side and Role Activity Diagrams or UML models on the other. As a result it enables the robust exchange of information between models of one type and other types of process models, while preserving the fidelity of the model content (as much as is possible).

At the heart of BPDM is support for both orchestration and choreography. This is going to become critical to modern organizations as the business boundaries change ever more quickly. It is self evident that businesses are constantly reorganizing, merging and splitting their operations, resulting in continuous changes in both the internal boundaries, and that which what owned or outsourced to both collaborators (in the supply chain) and the customer. Yet there is still a common process operating across the value chain. BPDM facilitates this evolving, permeable boundary by identifying and managing the common elements, enabling the modeler to easily transition between them.

Because of this sophistication, BPDM can support a very wide range of usage scenarios. For example, it enables high level, abstract “business capability models” used in the boardroom, to exchange information with lower level, procedural modeling notations used in BPM projects, and then on into process execution environments (BPM Suites).

BPDM will also facilitate the definition of complex inter-company interactions (and between the roles within the company). Such models could be created from scratch, or created through the composition of existing interaction fragments (from a library). The resulting model might then provide the terms of reference for each participants’ own internal orchestration model. In turn, this orchestration model could be teased apart to explore the business interactions that exist between the internal participants (internal roles) and/or used to generate a robust BPEL execution model that directly supported the firms agreed choreography with the other companies.

In this way, the process would not need to be completely ripped apart and redrawn every time there was a change of organizational responsibility. Roles (areas of responsibility) and their interactions could be modeled in an abstract way, then instantiated as needed to meet the requirements of the case in hand.

While most might think of BPMN collaboration diagrams to model interactions, a better approach is to use Role Activity Diagrams which focus on the interactions themselves and how a role changes state as a result of the actions and interactions that occur. So assuming we had tools that supported the BPDM package for BPMN and another tool that had mapped RADs to BPDM, it would be possible to translate between the two with clarity and fidelity. (BTW - the best reference on RADs is Martyn Ould’s book “Business Process Management - A Rigorous Approach”

So what does this mean in the real world of organizations like Perot Systems, Nokia or Shell – that business process standards, such as BPDM, will make it easier to model (and therefore understand) the simultaneity in a world where interaction has become as important as procedures (in some cases or more). It also makes it more straight forward to drive those processes using BPM Suites and report on the performance of the individuals and teams involved.

BPM Focus Joins The Blogging Generation

Seems I have finally succumbed to the blogging craze. I find that I am tracking so many anyway, and commenting liberally on the work of others, I might as well start doing it from my own space.

BPM Focus (BPMF) is a new member network formed by the recent merger of Enix Consulting and WARIA. The new organisation extends the traditional services offered by WARIA through a range of educational services focused around the BPM arena. The BPMF Learning Framework is a program of BPM Development & Deployment courses incorporating best practices for BPM project delivery and supporting techniques from the very best thinkers in the industry.

You will also find a range of BPM related white papers available on the site, including the acclaimed “Keys To BPM Project Success” paper (registration required).

BPM Focus is also heavily involved in work on Process Standards at the OMG, and provides a certain degree of “outreach” support for the work going on there. You may be interested to read my comment here responding to Sandy Kemsley on developing these standards.

You can expect perhaps a few postings per week on subjects around the BPM space.