“You do things so much better in Europe” Huh?

This posting has its origins in a LinkedIn discussion I had with Dick Lee a couple of years ago. As far as I can remember, Dick was at pains to point out that European companies were much more advanced in BPM than companies in the US. At the time I disagreed, pointing out the notable lack of uptake of BPM (in an organizational and/or technical sense) in Europe, the reluctance in particular of middle management to get involved with something that hasn’t produced a thousand success stories at the very least and could therefore be only regarded as a nice but untested concept and last but certainly not least the tendency to cling to process modelling as a way of saying ‘look, I’m already doing something with my processes, what more could you possibly want?’.

At the time I developed this picture in my mind of two ski jumpers standing at the top of the jump where the US jumper would at least make an attempt at jumping (proudly following the Eddie the Eagle example – British, I might add) whereas the European jumper would take off his skies to explore and take measurements of the hill to determine if jumping could actually be done without any danger to body and soul – and then taking the results home for closer study.

Fast forward to the present day (with lots of project and client related visits to different countries in-between) and I’ve come to the conclusion that Dick and I were both right – although for different reasons.

I’m just going to take a look at three areas for now: Uptake and scope, skill development and process awareness.

Uptake and scope
My impression is that companies in the US are quick to pick up on new topics, turning them into marketable ideas and then failing to follow through on them. One of the main reasons as far as I can make out is that BPM in US companies has two extreme positions and practically no middle ground: Processes are (and have been for a long time) a top management topic but as an abstract concept only. The other extreme is the business analyst and operational level: Lots of work in the trenches of daily business but so buried beneath methods and tools that it fails to get noticed. Accountability for processes? Nada. Process organisation? Nada. Middle management as the link between business strategy and processes? Doesn’t exist.

By contrast continental Europe prides itself on its wait and see approach (nastier minds than mine would call it complacency or even ignorance) with the consequence that once they do pick up on an idea someone’s bound to come in to tell them that it’s old hat and they should be looking at what’s new instead.

The other noticeable difference is with the scope of processes. End-to-end processes have always dominated European thinking. So the disappointment with many vendor strategies of ‘start small and grow later’ is understandable: Successfully implementing a highly automated employee self-service process to request a new desk or to put in your application for a business trip is really nothing more than a proof of concept when viewed against initial management expectations – in particular when they’ve spent nine to twelve months on a process to decide what BPM tool to use.

From the many conversations I’ve had, it looks as if this end-to-end thinking is regarded as nothing more than an abstract vision by many US companies. Quick wins, low hanging fruit, automation of a few small steps is the leading approach. Only…there are very few examples where a process fragment can actually deliver a ‘win’ that would lead management to think in bigger chunks.

Skill development
It has never ceased to surprise me how well US business analysts are trained. Formal certification is much more important in the US than it is in continental Europe. And while the content value of some of these certification courses is questionable, they do provide a basis for development. By contrast, many European business analysts I know are more or less self-trained, depending purely on project experience to increase their skills. This forces many of them to become deep-dive experts and losing contact with the world around them. Process model administrators, librarians of process maps is what we have plenty of, but this is clearly a case of administration beating content.

The second area where I feel more should be done concerns the actual management of processes. It shouldn’t come as a surprise to anyone that managing a process requires other (or at least additional) skill than managing a department. And those who are tasked with managing process have other information, IT and action requirements that need to be addressed for them to get the job done. In the words of a former Chief Process Officer of a large telecom provider “Don’t ask process managers to manage processes, they are simply not qualified for the job”.

Process awareness
This is where I believe both ‘cultures’ are equally weak. Ask people to describe the process they are working in and they will either tell you about their tasks and speculate on what might lie upstream and downstream from them or they will point to their desktop pc and explain how the system they’re using works. But being aware of the content and context of processes, of how processes interact, how processes behave and indeed how processes make up the business is not something we get to see often.

The most obvious sign to me that process awareness is underdeveloped is that processes are often confused with projects. While a project has a limited lifespan, business processes really only begin to exist once projects are finished. Hard to understand why we pay so much attention to creation and then forget about existence.

So, start with being Eddie the eagle, which is where I’m right, but keep the next level in sight and make sure you are able to get there – which is where Dick is right. 

Btw, the differences I’ve pointed out in this post not only reflect how successful (or not) companies are at managing processes, they may also go some way to explaining why vendors find it so hard to develop the right messages. You may like to check this recent blog post by Adam Deane and the resulting comments to understand the difficulties vendors can face when they try to sell a solution to a problem nobody really wants to be aware of – though everyone knows it exists.

As always, Peters questions had that deceptive quality of innocence. Rereading the transcript though, it seems to me that several separate discussions are slowly coming together:

• Case management as a method to deal with processes for which traditional BPM with its pre-defined control flow has never really worked may deliver a more complete vision of the kind of process support needed.
• Social BPM, while not identical with case management, uses a similar foundation and framework: often ad-hoc, case-driven, communication intensive, unpredictable, goal-driven and relying on employee empowerment
• The glue keeping it all together and manageable is governance. Not longer an optional extra (‘we’ve treated ourselves to a bit of luxury and appointed a head of governance, but we’ll keep him as far away from operations as possible’), governance will be the make or break factor. It needs to be understandable, enforceable and adaptable.

Enjoy the podcast and do leave a comment.

What follows next will probably be similar to a conversation I had last week with a person who – at least by title – is responsible for a decent part of the processes of a major european financial institution.

Me: So you’re the guy to talk to about processes?

Him: Well, officially yes. But for the next 2 years I’m tied up in a non-related project, so I can’t really help you.

Me: OK, so who do I talk to instead?

Him: If it concerns processes, you’d need to talk to every single team leader, plus the heads of department and don’t forget the governance and compliance folks.

Me: How many people would that be?

Him: Uh, about 600.

(It was then that I decided to at least have some fun, seeing that this conversation wasn’t getting me anywhere)

Me: The reason I’m calling is that I wanted to offer you the process equivalent of the holy grail and I just wondered who best to talk to and by the way, I’ll be meeting your CIO next week.

Him: Can’t really help you I’m afraid. Everyone at the bank is doing their own thing with processes.

Me: Why?

Him: Because they’re important.

Me: Oh right. So … you’re not interested in the holy grail, you can’t point me towards someone whose job it is to be interested but all the same processes are important? Doesn’t that strike you as weird?

It was at this point that we decided to change the subject. He wasn’t trying to get rid of me, he just couldn’t help me.

Now I wonder how the aliens would have reacted. Would they have continued to talk about the weekends football results like I did or would they have gotten on their spaceship again, taken to the skies from where we would then have heard the quiet order: “Prepare laser and EXTERMINATE”?

Images (thanks for those childhood memories):
Tardis: http://strangebuttrueradio.blogspot.com/2011/05/eastbourne-east-sussex-england-tardis.html
Daleks:    http://tardis.wikia.com/wiki/Evolution_of_the_Daleks

Recent tweetjams on process management had ‘social’ as the most often used buzzword, vendors are actively putting the social sticker on their BPM products, analysts are calling customer integration the do-or-die challenge and everyone is suddenly feeling very good about it all. And yes, a pat on the back is indicated: let us not forget that not so long ago many companies had a policy not to allow messaging systems connected to the outside world and using social networks during office time could lead to severe repercussions for employees.

But are we really on the road to social processes? It’s easy to say yes when you only provide an obscure definition of ‘social’ or just refer to examples. Does including a Tweet button make a product ‘social’? Is a company Wiki ‘social’? Personally I’d say no, but the way a Wiki is fed and used might be.

The make or break argument for me has always been how much room we allow for the customer in our processes. This is less of a technology issue – in fact it runs contrary to fixed functionality technology – and more a question of changing the mindset. And regardless of how much talk there is about social BPM, very few companies are actually addressing the mindset change.

They are missing out on the all-important WHY and just sticking to the HOW.

Here are some examples of what we see on a regular basis at the Process TestLab and what you might like to check at your own company:

• Take a survey among process managers and ask them to list the customers of their processes. Chances are they will give you a blank stare or guess at some internal recipient of his process results.
• Ask them to point out the customer role in their process models and most likely you will see them right at the start and (hopefully) at the end of the process.

Spontaneous, dynamic or even erratic customers are no part of our approach to processes. Taking a purely internal view makes it so much easier to predefine our processes and put the customer in his place. Reality of course is different: If your customer doesn’t like or accept the provided process he will cease to be your customer.

So maybe it’s time to rattle the cages. We have recently started to include customers at our validation runs – with surprising results. What usually happens is that every participant is assigned a process role (e.g. sales rep., clearance team member etc.).  Our validation system then generates process instances and the server routes the instances from participant to participant, following the logic as described in the process design. The participants can work on the assigned tasks, enter data, in fact they can do everything necessary to evaluate the process logic. The objective is to validate processes in a situation as realistic as possible without our clients having to implement the process first.

To make this even more realistic, we – even though we’re only the facilitators – take over the role of the customer in the process and start to behave as customers do: sometimes sticking to our assigned roles, sometimes providing only half the data, sometimes asking for shortcuts … in short, we try to inject our own input into the process. As a rough estimate, around 80% of our clients were unable to deal with these variations in customer behaviour even though they had a standard process in place. In most cases they even felt unable to define ad-hoc solutions to deal with the customer requirements.

It’s at this stage that companies begin to realize that they have a choice: Either become ‘social’ by enabling employees to become solution providers for their clients or to stick to predefined processes with predefined actions and ‘standardized’ customers.

My prediction is that companies clinging to the second option are the ones most likely to buy social and become even more ‘unsocial’ because they continue to ignore the customer while companies going for the first option will be social – though they’ll have a lot of mindset change activities on their plate. 

The effect is overwhelming: Whereas before people had to struggle with interpreting abstract process models, now they can understand the logic and dynamics of a design by working ‘in’ the process rather than by looking at the model. Imagine taking the design template of a new car for a test drive and you get the general idea.

But how does process validation at the Process TestLab work?

Let’s take the most common case that a project team has developed a new process which needs to be validated before it goes into the next phase. Our approach makes it very easy:

1. Process design models and descriptions are sent to the Process TestLab
2. At the Process TestLab, we transfer your process designs onto our validation system. This usually takes only a few days.
3. Next, we set up a temporary validation environment at the clients site. Not to worry, all it amounts to is a room into which we place our validation server and a network of terminals. Setup usually takes no more than a couple of hours.
4. Then the actually process validation by the client takes place. Every participant is assigned a process role (e.g. sales rep., clearance team member etc.).  Our validation system then generates process instances and the server routes the instances from participant to participant, following the logic as described in the process design. The participants can work on the assigned tasks, enter data, in fact they can do everything necessary to evaluate the process logic.
   Our job at this stage is simple. We just guide the validation team through the process and record any upcoming discussions. After all, our clients are the experts on their own processes.
5. During the validation runs, we automatically record the audit trail of the process and add any comments made by the participants. This way, our clients receive a complete documentation on what aspects of a process may require changes and in which context these items came up.
6. Finally, we dismantle the validation environment and generate the final validation report for our clients.

Thus, with a minimal amount of time spent, our clients

• have validated their processes by having actually worked in them instead of only looking at the description,
• have avoided the pitfall of interpretation,
• have jointly identified areas to sign off on and areas that require additional work,
• have created a group consensus on the process design.

Our approach lets our clients quickly ensure the integrity, workability and above all usability of a process design without them having to it implement it on their IT. As we all know, this helps avoid unnecessary costs [2] and helps reduce the time needed to implement and roll out the process. Best of all, as quick as our validation process is, you can use the Process TestLab in parallel to your projects. It doesn’t even conflict with your project schedule. And thanks to our mobile validation enviroment, we can support our clients anywhere in the world.

Links:

[1] Visit the taraneon website

[2] This short animation explains how process validation can help you avoid unnecessary effort and cost

Unfortunately, the process problems connected to getting my daily dose of caffeine don’t stop with the recognition of my own process. There is also the issue of interpreting processes – a particularly grave problem when it concerns my espresso.

Lately I’ve started to ask waiters about how they make a double espresso before ordering one. Usually I get a straight answer and then the fun begins. I suggest you try this experiment. Once the waiter has given you an answer, ask him to check with the person actually working the espresso machine. Chances are, the waiter will return with a second answer, different from the first.

You may wonder why we regard this as a process problem. On the face of it, the process is clearcut:

1. Customer: Order double espresso, 2. Waiter: Take order, 3. Waiter: Transfer order to Barrista, 4. Barrista: Produce double espresso, 5. Waiter: Collect double espresso from Barrista, 5. Waiter: Serve double espresso to customer, 6. Customer: Enjoy – Or not!

Easy? Easy! But I probably won’t be getting what I want.

What I expect from a double espresso is twice the amount of espresso beans and the usual amount of water: Double espresso. Can’t imagine how anyone could fail to understand the meaning. I do realize though that the usual interpretation is ‘double the water and double the espresso’, in other words, press the button for a single espresso twice in a row. I’ve also come across bars and restaurants where they have machines that are programmed to produce a large weak espresso, i.e. a single espresso made with twice the amount of water. The sub-process in this case would of course be different but the result might also be called a double espresso.

So imagine what the person designing espresso machines will make of the requirement for a double espresso. Does he just envisage the single espresso button you press repeatedly?  Or should his design also include the capability to separately select the amount of coffee and water? In reality, he’s in the same position as an IT department. There’s something he can do that conforms to his interpretation of the requirements. But how should he know that you actually meant something else entirely? Chances are, he’ll go ahead and build the machine … and get it wrong.

OK, so this is trivial compared to the grand BPM strategy you’re currently following. But would you like to guess what the most frequently used task in process models is? The one that everyone seems to want to include in their process designs and which is never questioned? It’s: CHECK DATA. Sounds good, sounds important and let’s admit it: checking data can never be really wrong.

But what does it actually mean? Ask the question, lean back, enjoy the ensuring heated discussion and discover why process validation helps you not only understand the structure and logic of a process but also its meaning. And you may also discover one of the reasons why less than 20% of process projects deliver according to expectations. ‘Reading’ the process model is no substitute for actually experiencing the process. At the Process TestLab we can let you work in your process before you start to implement it …. and we serve a double espresso according to your personal specifications.

I do wonder how this will play out. inubit has always been very present in the german BPM market. It’ll be interesting to see if Bosch will maintain inubit’s market presence or if it’s an acquisition aimed at securing products and skills for mainly for Bosch’s internal use.

How many processes are there in one company?

This may sound like a stupid question, but we have a discussion with a process manager of a client going on about the sheer number of processes in his company. So, regardless of how you define a process, a sub-process, a series of tasks and regardless of how big the company is…. I’d be grateful if you’d start throwing some numbers at me. Is BPM looking at a single-digit number of processes, double-digits or even more?

72 comments later we seem to have reached a point on which we can safely start summarizing. Fortunately, fellow LinkedIn member Robert Starinsky has done the hard work and filtered all the input we received to come up with the following comment which nicely summarizes the discussion thus far:

“After a month of commentary, I’m not sure we’ve really answered your question directly through this forum – but we have touched upon the sheer complexity of the task of completing a comprehensive process analysis/inventory for any given organization. Here’s a sampling of the ‘process counts’ which have been mentioned:

JD noted the APQC generic cross-industry process classification framework defines 12 Business Process Categories (5 Primary, 7 Support), 62 Business Process Groups, 265 Business Processes and 797 process internal activities.

Titus noted the ISO has six (6) mandatory procedures – the minimum which an organization must have, including processes for (1) Internal Auditing, (2) Corrective Action Planning, (3) Preventive Action Planning, (4) Control of records, (5) Control of documents and (6) Control of non-conformance.

Russell noted his firm has defined a basic series of 24-30 processes related to product development. Russell further noted there are many other areas of a business outside of product development that would add to this process count.

Marcelo noted his business process improvement project within the IT value chain alone yielded 102 processes of 20 or more activities each.

Perhaps Marcelo and Karl have offered the most practical advice here. Karl noted that organizations have as many processes as they need to have to build/maintain customer satisfaction while Marcelo notes the number of value chain processes of any organization regardless of their industry, will depend on the level of abstraction that is used to map those processes. In the final analysis as Marcelo noted the number of processes in an organization doesn’t matter; what matters is the quality of the process maps produced and how well these maps show the current state of the business process and where the enhancement opportunities are.

No matter what methodology one might choose to employ to inventory, count or discover processes, in the end a relatively few number of high level processes will likely yield a much higher level of supporting sub processes, tasks, activities or business functions (or whatever it is your methodology calls them).

An organization is as complicated as we want to make (describe) it. I often use a recent Starbucks commercial to explain the concept of a value chain – see: http://www.youtube.com/watch?v=yN9_WT9l7xo.
I refer to this spot as ‘the 60 second value chain’. I should add that my students love this spot and it really helps their understanding of the value chain and of primary and supporting business activities (processes). I would add this commercial summarizes the thoughts on value chains and customer related processes from Karl and Marcelo quite well.”

If anyone thinks that BPM can be done without creating a common understanding of processes, this discussion should set you thinking. It’s not a question of right or wrong, but of creating a commonly accepted starting point inside your company.

Final thought if you’re in the mood: Start counting your processes top-down using your companys process methodology. Afterwards do the same bottom-up. Did you get matching figures? Does the methodology still make sense?

“We can’t spend time and effort on trying to avoid process errors as all our resources are tied up with correcting the mistakes we made in the past.”

It’s been nearly a week since that statement was made by the process owner of a very large company. I’ve finally decided that I must have heard him correctly. Now I’m just wondering if he’s aware of the difference between movement and progress.

Nevertheless, confirmation coupled with an approving pat on the back could be a bit of an overkill:

Am I in danger of being told in future by a process-aware waiter that I have ‘successfully enjoyed my meal’? Huh, does that lead the way to a couple of other options like:

• You have successfully liked this item
• You have unsuccessfully liked this item
• You have sucessfully disliked this item
• You have unsuccessfully disliked this item

I’m sure, the makers of business rules engines will have a field day with this.

Note to self: Research the importance of language and choice of words in BPM.