Skip navigation

I’ve mentioned before that the world of process understanding is changing and we’re seeing both companies and analysts wake up to the new paradigm.

Firstly the realization goes something like this:

  • The large majority of activities in businesses are not logged in any transactional system (ERP, CRM, BPMS etc)
  • Processes are combinations of both automated (in the transactional systems) and non-automated activities
  • To both delight customers and increase operational efficiency we need to understand, see and use both the automated and manual activities to allow us to manage holistic end-to-end processes
  • Modern companies have spent millions on understanding, managing, standardizing, etc.  the automated activities…
  • … they have spent orders of magnitude less on the manual ones
  • Thus there is a compelling need to apply the same level of rigor across the manual activities as well
  • Business Process Management should be defined as managing the processes across the whole enterprise, both manual and automated, as shown below:

There are very few people who dispute this perspective (SAP, Microsoft etc agree with this picture) and there is also little doubt that increasing the number of automated activities is beneficial. However the vast majority, if not all of the BPM vendors and experts are exclusively focused ‘below the line’ ‘ i.e. increasing the number of activities that are automated, see Phil Gilbert of IBM talking recently.

However laudable and necessary, it’s absolutely fundamental to understand, as evidenced by the picture above, that the contemporary ‘BPM’ vendor’s view of BUSINESS Process Management is incomplete. In order to manage all of the company’s processes you will need a stack of technologies; any sales person peddling one software to manage all of your BPM needs is either lying or doesn’t understand.

So, what do we need to manage the ‘other 80%’?

  • appropriate software
  • implementation methodology
  • a language
I’ll deal with these in  a later post.

I’m a regular listener to a number of the ‘netcasts’ (their word) from Leo Laporte’s TWiT network, and one of the contributors is often Brian Brushwood. Quite apart from the fact that you need to look at his website (fun, bizarre, clever, amazing) he is a very sharp guy with some astute observations.

One of the recent ones was his take on Twitter, I’ll paraphrase as I can’t remember the exact details however it goes something like this:

“History has, since the dawn of man, been written as an afterthought and from the very subjective viewpoint of a select few. Twitter however has totally changed the way that our ancestors will be able to understand the past as it is a crowd-sourced, real-time history book that is being written as we speak. This is therefore the first time in history that people will be able to look back and know what really happened”

Which is the best analysis I”ve seen of the Twitter phenomenon and wasn’t a perspective that had occurred to me at all.

Shwood’s got spiky hair and swallows tubes which then come out of his nose….

….it seems that your parents were right when they said that you can’t judge a book by its cover.

So why are people so utterly, collectively selfish in certain situations?

You’ve been away, on holiday, at university, living in another country whatever, and your loved ones come to the airport to pick you up. You want to see them, they you, totally reasonable and understandable.

But why must you stop, with your trolley overflowing with suitcases, at the exit straight after Customs where everybody is waiting behind the barriers, to hug and kiss them, blocking the way for everyone else??? You haven’t seen them for 6 months, can’t it wait another 10 seconds?

It never ceases to amaze how this utter disregard for other people manifests itself at every airport around the world, and how utterly pathetic I am in getting pissed off each time I encounter it…

I’m assuming, dear reader, that you aren’t one of these selfish souls and you will join me in the crusade against Airport Exit Blockers?

OK, this is a long post, tea and biscuits needed…

Reading Brad Power’s article, (what a name!!! Brad, you missed your calling, you should be a film star…), and I can’t help thinking there’s some key understanding that’s missing here, which, not incidentally, is also missing from virtually every other ‘expert’ that bangs on about process improvement.

‘Run before you can walk’ is a logical refrain and yet reading this piece on process improvement (yet another) it seems as though we are exhorting people to do exactly the opposite.

Standardization is the key word: If you have a workforce of, say, 10,000 people how do you know what processes they are actually executing today? I can virtually guarantee if you talk to any random employee in,  to take Brad’s  example Shell, and ask what they do they will be able to describe the processes they are involved in. Then ask them to show where it’s written down and they’ll struggle to find the documentation. When they eventually find it, the documentation will say something different from what they actually do. Oh and by the way let’s go and ask another employee who does the same job in a different location and you’ll get another answer again… and again… and again.

If you don’t believe me ask Carphone Warehouse; during their keynote presented at Nimbus’ IP09 event, they showed how big this problem was for them: they asked 20 of their branch managers each with more than 5 years experience how to reconcile sales contracts – each had a different answer!

This is a massive, apparently undiscovered issue  for so many businesses, and impacts critical functions within businesses (covered in a future post, however here we’ll stay with Brad’s process improvement focus).

The ‘running’ referred to earlier is the process improvement, the ‘walking’ is standardization.

Given that we can’t get people to work the way we want them to now, what is the point in trying to improve what are patently non-standard processes today? Which one of the many (unwanted) variations are we going to improve? Or are we simply going to think big thoughts in small groups and do our cool analysis and then abdicate responsibility for actually deploying the processes and then ensuring that people actually do them?

BTW you would be amazed (or quite possibly shocked, horrified, reduced to fits of giggles – take your pick) if you knew what we have actually heard time and again in global companies; i.e. process practioners, BPM ‘experts’, who do not believe that it is their job to deploy, and then sustain process changes. This is core reason why companies are disbanding their BPA practices, referred to in an earlier post.

Let me spell it out: there is no point in trying to improve process unless you standardize first. In order to standardize you must have a process platform to allow you to do that. It needs to make working through process part of people’s day jobs otherwise the standardization you want won’t happen. And I don’t mean the output from a technical BPA tool or Powerpoint exported to your intranet; we all know that doesn’t work.

In doing the process discovery and making the decisions on to which existing process to standardize, you will make improvements simply by reducing huge inefficiencies of lots of people doing the same thing in different ways. Best Buy Europe saw a 5% improvement simply from this standardization.

Clearly you could use some improvement techniques during this process, fine, but you must have some way to deploy and embed the changes made.

I had a surreal experience a few years ago at a conference in Philadelphia. A fantastic presentation from the head of internal consulting at Coca-Cola, which, in my eyes rapidly degenerated into farce at the end: When asked what the key KPI was for her consulting group she said (I’m not kidding),

“how quickly we can fix a process issue that we’ve already fixed before”.

Asked for clarification she said that her team would use PI techniques in a certain part of the operation, improve things and then move on. Over time the ‘improved’ part of the business would drift back to old ways and they would be called in to fix it again. This was such standard practice that the time taken to re-fix was her core KPI…

The utterly frightening thing was her calm, normal demeanor and the fact that everyone nodded sagely as though this was OK. I was frankly astounded, even more so when I to spoke to her afterwards and couldn’t get her to see that this acceptance of the status quo was complete madness; “insanity is doing the same thing time and time again and expecting a different result”.

One other point Brad makes (although in fairness he may simply be repeating what he thinks the BPM religion believe) is

“Shell Oil’s downstream (refining and retail) businesses have rolled out a global implementation of enterprise software SAP with standard global processes”.

Let’s be clear: deploying ERP does not standardize business processes. In most organizations no more than about 20% of activities are automated in ERP and process automation software, and given that the vast majority of processes require both manual (no transactional system involvement) and automated activities, ERP/BPMS software can only automate a small fraction of the whole. Anybody who tells you otherwise is either sadly misguided or a SAP salesman…

…. I just want one to look at:

Which is the only conclusion I can draw from his comments regarding Centres of Excellence etc. in, amongst other places, this really good presentation he made last year.

But instead of ridiculing his stance I actually think it’s totally understandable and probably very similar to most BPM “experts”. To paraphrase the immortal Donald Rumsfeld (no, strike that; the world absolutely doesn’t want him around for ever…), “you don’t know what you don’t know”.


Here’s my thinking; If you’ve come from the world of BPA and BPMS/process automation, (which is the enormous majority of people in the process space, so I think this probably applies to pretty much every BPM commentator), then you are unconsciously incompetent to talk about massive deployment of process into an organisation.

The 4 stages of learning:

unconscious incompetenceyou don’t know what you don’t know. This applies in skiing all the time; people go off piste/into the backcountry with no idea of whether what they’re doing is dangerous or not.

conscious incompetence you know that you don’t know. I remember this feeling the first time I went into the African bush and wanted to go to an adjacent camp on foot. I knew that I didn’t know if walking there was dangerous or not.

conscious competence I know how to do it but I have to concentrate. Learner drivers.

unconscious competenceI can do it without thinking. Experienced drivers.

BTW I’m only using the word ‘incompetent’ in the nicest possible way😉

What I mean is that BPA/BPMS projects are focused on small centralized groups building processes. A few people with brains the size of a planet doing desperately clever things in small groups. If the content is deployed outside the group then it is done in a very structured manner. And that means that the people involved (the BPM specialists referred to above) have no notion of what devolving the creation and deployment of process content out to tens or hundreds of thousands of people is about and the challenges it holds. They don’t know what they don’t know, but frighteningly are giving advice nonetheless.

Well we (Nimbus) do, warts and all; we have hundreds of implementations with a central repository and thousands of people accessing and creating content on a daily basis. And here’s a bit of advice for free; unless you have a well structured CoE you will have chaos and little or no value. We have seen a (fortunately small) number of our clients, big, sometimes global companies, ignore our advice and do exactly what Phil is suggesting with his seductive tag-line, “the democratization of process”, i.e give people easy and powerful tools to use and somehow it will all be alright…

And it might sound warm, fuzzy and attractive to western sensibilities but I can tell you it is an utter mess. You get exactly what Phil is proposing; loads of people building content, really getting into it, communicating like mad, and guess what? No value and ultimately frustrated people. This is one case where out of the chaos no beautiful order emerges…

Whatever software you use you should absolutely be collaborating, devolving process creation, using social tools and principles.

However please, for your own sake, don’t do it without sensible strong governance…

An article on GigaOm ( prompted this thought; is BPA dead?

Of course it isn’t I hear you say, most of the companies in the space are growing (albeit slowly), Gartner has a Magic Quadrant, heck my company has just bought some BPA software!

That may all be true, however for different but related reasons I think that it might be ‘dead’ in a tangentially similar way to the ‘dead’ companies written about in the article.

Why? Well for a number of reasons:

  • what is the size of market for BPAnalysis? I emphasis the word analysis deliberately because that’s really where the heritage, the thinking and the philosophy  of the BPA toolsets has come from. However, really…. the number of people actually doing analysis on business process in most companies is a tiny percentage of the company’s popoulation. Not to say that it isn’t useful, simply that analysis isn’t an end in itself it’s a means to an end. What do I mean? Well the best most perfectly honed process in the world is of absolutely zero value if the X thousand people in the company concerned aren’t actually doing it. Therefore analysis only has value if the result is actually deployed/used, otherwise it’s a waste of money and time.

    And therefore it’s hardly surprising  that BPA tools that were conceived and built for the A bit aren’t actually very good at the deployment bit. Show me an operational i.e. used deployment of ARIS or Casewise to, let’s say, 10,000 people…

    Many companies (I could point to at least 10 global companies off the top of my head) are waking up to the fact that analysis for analysis’ sake is pointless and adds no value. They are/already have disbanded their BPA groups and thown away countless man/woman-years of work.

  • BPA is being subsumed into BPMS Look at the acquisitions in the last couple of years and you’ll see that many of the standalone BPA vendors have been swallowed, presumably with the aim of simply becoming the precursor software to the BPMS. and in many cases the BPA software revenues are a tiny part of the whole, witness Software AG and the revenue that the ARIS toolset adds to the whole…..
  • The Gartner BPA MQ is on it’s way out This is unconfirmed and may not actually happen but apparently there are loud voices inside Gartner that have seen the writing on the wall and that the next BPA MQ will be the last.


What appears to be happening is that the world is waking up to a picture of enterprise process that looks different and has a different set of requirements…. to be discussed in a future post.

There’s me sitting in Beijing talking to 2 people from one of our clients, a massive Chinese bank. Slightly odd (to my western sensibilities, don’t take this as any kind of slur) almost military type people, very straight-backed and not even the merest inkling of the tiniest possibility of the smallest chance, that a smile could even begin to ponder approaching their lips…

For a whole 1.5 hours. (which seemed a lot longer…)

However there is always something to learn and this is what I got…

Apparently in many Chinese organisations the whole of concept of a cross-functional process is as alien as it is to some western companies (still…) however their problem is much bigger. You can define a cross-functional process and attempt to implement it, however feedback and any changes you might need to make are going to be painful:

If you’re a middle manager and you see something that should change, you absolutely can’t go and talk to your colleague in the next silo down the process, you must escalate to your silo head, who in the fullness of time may deign to communicate it to your colleague’s silo head, who may in turn pass the info to your colleague. Clearly the message may have become distorted by then (insert your own favourite chinese whispers joke) and may never even reach it’s intended target.

All of which poses some (!) organisational challenges to process collaboration and improvement, but also to collaboration features in software which are probably designed (by western companies) to assume that collaboration is a many-to-many construct. Therefore nobody’s action list gets too big.

The comment from one of my Chinese colleagues was that they were finding it difficult to use the collaborative functionality as about 5 people were getting actions from about 1 million employees….

So I’m reading Bruce Silver’s blog about something to do with BPMN method and style or some-such and it strikes me that they (the BPMN zealots) are really fighting a losing battle.

Why? Because they haven’t understood that to be sure of winning your battle you need to understand your competition, then define your battle field and terms of engagement very carefully. If you don’t, you risk trying to fight too big a war that you just can’t win, ask any military type.

Let me explain with a historical analogy: Esperanto…

Explanation over.

BPMN is, regardless of what the OMG (oh my god?) say, a graphical programming language. If you don’t believe me I won’t labour the point, just read some of the definitions of the objects (anybody fancy an intermediate boundary interrupted compensation event?).

So why-oh-why would you try to take a language designed for silicon-based intelligence, artificially simplify it (BPMN Lite or whatever it’s called) and then say that carbon-based lifeforms should use it as well? Makes no sense at all.

Esperanto didn’t work – translators and interpreters still make a pretty good living – guys learn the lesson!! you will never get the countless millions of normal business people to learn a completely new language, just because you want them to, sorry.

BPMN people, listen up: your battlefield should be limited to getting all the BPMS folks to buy-in to your language, imlement it and use it as a standard for the cool  silicon-based stuff that they build. Trust me, that is a big enough battle to be fighting anyway, but it is one that you could win.

You can’t win the ‘everybody’ battle so stop trying, you only confuse the issue and annoy normal business people (like me for example… :-))

P.S. a word about what the carbon-based language could be in a later post.


Get every new post delivered to your Inbox.