The importance of being Simple @BPM @process

Tom Molyneux has just written a guest piece on Chris Taylor’s blog that I wholeheartedly applaud both for its message and the simplicity with which it is delivered…

With due thanks to Oscar Wilde for the title inspiration, this is a bugbear of mine that I see in many situations and constantly rail against, that is: people/industries delighting in using impenetrable language, abstruse words, deliberately complicated syntax, all with the express intent of showing just how clever they are, how difficult their subject is, and thus underlining their importance.

Which from my perspective does the absolute opposite; I find it childish and frequently ridiculous but it happens everywhere, and nowhere is it more prevalent than in the IT industry. To be fair I understand that there is often a big helping of job protectionism in this, but also what appears to be a desperate need for certain people to demonstrate their IQ. The person shall remain nameless (I don’t want to be accused of flaming) but there is a well known blogger in the process space who is a perfect example of the, “I understand most of the words you’ve written but have no idea what you’ve actually said” reaction to their blog posts….

However apart from the personal issue I have with this tendency, there is a much more important one which Tom eloquently points out, in the BPM world and talks to a point that I’ve frequently made in my posts. There is a need for two linked but different process descriptions in any organisation, and most companies haven’t yet understood the simplicity required in one of them…

Let me recap/reiterate the point: there MUST be two process descriptions in an organisation; one to define the executable processes for the process automation, the other for the humans to have both a complete end-to-end understanding and also to actually do the non-automated activities.

The problem is therefore twofold:

  • the process practitioners that create and manage the description driving the process automation, often think – horribly wrongly – that process is process therefore why can’t you have one language for everything


  • it is those same practitioners that drive the process creation for the human descriptions and they either deliberately or unconsciously forget the key learning that Tom highlights, i.e. “if stuff isn’t simple people won’t do it”


Well I think that there is some job protectionism going on; “I need to show that this is difficult to justify my daily rate/salary”, but also that people simply (pun intended) haven’t understood Richard Thaler’s basic truth:

“My number-one mantra from Nudge is, “Make it easy.”

It is widely understood that frequently the best communicators in life are those people that can make complex subjects simple, whereas I often see the direct opposite in the BPM world.

My lesson for all you BPM practitioners out there: if you are creating process descriptions that your end-users don’t understand and don’t use, then YOU are wrong not them!

And that in a nutshell is why in my experience the vast majority of end-user focused process projects fail.

P.S. Obviously it would make me feel suitably smug if you had to look up the meaning of some of the the words above…. 😉

So which language should we use then? #BPMN, #BPM

I’ve threatened (!) to blog about this before and haven’t got around to it, however I really do believe that we (the BPM community), need to clarify some thinking around the ‘process language’ question.

I’ve alluded to this before,  (BTW I apologize if the word ‘zealot’ displeases you; it appears to have a negative connotation in the US that it doesn’t here and in no way was meant as a negative comment) and I’m certain that my views are misunderstood, but far importantly that the BPM community as a whole isn’t thinking very clearly about this.

I am of the opinion that organizations’ efforts to deploy process is being actively harmed by this lack of clarity and it is hurting all our efforts to promote company wide process management.

Here’s the argument as I see it:

The company-wide process landscape

Firstly this conversation needs to be framed by reference to a diagram that I’ve introduced in a another post but that I’ll include again here for clarity:

Briefly it is saying that the majority of an organization’s activities don’t (and won’t/can’t) touch an enterprise app or process automation engine and that most processes are a combination of both manual (by this definition) and automated activities. Notwithstanding IBM’s message of automating processes that today are managed ‘over email’, this point doesn’t change; they are simply raising the automated/manual line a little bit.

So without question we have two different environments where the audience for the process information couldn’t be more different; humans and machines. It makes complete sense therefore that the requirements for the language used for each would be very different.

Below the line – automated activities

It’s a given that we need a standard language to allow interchange between toolsets etc., I don’t believe there’s any disagreement here.

This needs to be a graphical programming language that is sufficiently abstracted to allow business analysts to use it without being computer scientists. Given that we don’t need many business analysts (as a percentage of the company’s employees) the training that is necessarily required for BAs to be able to exploit the language should be manageable, both from a cost and logistical viewpoint. The ideal is for BAs and a subset of the end-users concerned to be able to build a process diagram , verify it and export to the automation engine for it to execute.

I’m no expert but it seems that BPMN fulfills these criteria, is becoming the de facto standard and therefore is a good choice.

The business analyst therefore must have a deep appreciation of how the business operates; indeed in my experience the best BAs are technically trained normal business people, rather than IT people who have had some ‘business’ training.

The vast majority of the business end-users however never need to see this process description at all. As mentioned, a subset will work with the BAs to create/validate what is to be built, that’s all. The end-users are actually the audience for the eventual automated process and therefore the BPMS’ user interface is way more important to them.

Above the line – manual activities

Here we have a completely different set of requirements; remember that normal, non-process expert humans are the audience here. At a basic level they need to to understand how to do their jobs. Period.

The process descriptions here need to be the simplest, easiest way for people to find the information to do their jobs. If you don’t capture process sufficiently simply and make it available in a personalized manner this part of  your process program will fail.

This process documentation (electronic operations manual) requires an extremely simple process view with ‘click to access’ the relevant documents, spreadsheets, videos, etc. to help them perform their activities. The graphical representation of the processes should be so simple that it doesn’t require training to understand. Bear in mind that we have 5000, 50,000, 500,000 employees that need to see and use this information on a regular, sometimes daily basis.

Any training requirement at all is a massive overhead.

Two languages

I can’t see how it’s possible to disagree therefore with the view that we need very two different descriptions of process for these two audiences. Nobody in their right mind would build process information that is destined for normal end-users in a graphical programming language, and the simple end-user view of the process won’t execute in an automation engine.

Ah hah!! some of you may say; you can use one language, BPMN for everything!

But in reality I’d argue that’s not true: the subset of symbols that are used in what I’ve heard called BPMN Lite do not provide you with an executable process. For that to happen, some highly trained person needs to take that process description and modify it.

In essence therefore you actually have two languages, (even if they’re both called BPMN), because you need a translation from one to the other to fulfill the need for which each is designed.

There is no way around this: regardless of what you’re calling them, you need two languages. You’ll notice that I’ve defined the difference between two languages as the need for translation between them. (Actually a linguist would call them LSPs, a language for specific purposes, which can be derived from the base language) but regardless of the semantics, the practical upshot is that you need human intervention between the two.

Which language ‘above the line’?

So if BPMN is the de facto language ‘below the line’, the question then is which language is best suited for ‘above the line’, or the process descriptions that are designed for human consumption. It seems to me that we have 3 major candidates:

  • BPMN Lite (apologies if the name isn’t right but it works for this discussion),
  • EPC (event driven process chains)
  • UPN (universal process notation).

The closest I can find for a definition document for EPC is Wikipedia, the UPN description document is here, BPMN here.

All 3 are non-proprietary notations, EPC and UPN are most often associated with Software AG ARIS and Nimbus Control respectively, however can be used by anybody with any software.

I’m not going to go into an exhaustive examination of each, suffice it to say that in my experience both BPMN Lite and EPC are in some ways too complicated to be used widely for business end-users, in other ways they don’t contain the information required.

Both appear to have come from too technical a heritage to really cut it as a human focused language. If the proof of the pudding is in the deployment (sic…) then I’m not aware of any examples of either EPC or BPMN Lite being used on a daily basis as the staple process description in an electronic operations manual deployed to tens of thousands of people.

You might think that I would say that given my Nimbus link however I have no commercial axe to grind here, as mentioned anybody can use any of these languages FoC with any software.

I’m simply trying to bring some clarity of thought to this issue as I see companies trying to standardize on one process language when in fact it’s a futile exercise to begin with. You must have two languages and a way of managing the exchange of content between them which involves intelligent humans.

The decision of which two languages to use is clearly yours, however as a business user, don’t be brow-beaten into using BPMN simply because your IT department wants to standardize on it. In essence by doing that they are enforcing two languages, one for them one for you, without being aware if it and the consequence (no process adoption by your end-users).


Two dramatically different  audiences can’t be served adequately by one language, there is always translation required between the two.

Assuming that you use BPMN ‘below the line’, you need to make an informed decision of which language you are going to use ‘above the line’ (human focused, manual activity process descriptions) and ensure you build a translation mechanism between the two with appropriate governance.

So you see I’m not anti BPMN at all!!

For BPMN to succeed the zealots need to understand what it can’t do

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.