Blog Posts Process Management Process Modeling

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).

Summary

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!!