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

Ovum CIO Industry Congress – observations from a none CIO…

I was asked to participate in the panel for a Q&A session at last week’s Ovum CIO Industry Congress in London. Which I thought slightly ironic, as any of our IT team back at Nimbus will tell you that I’m, ahem, not the most techie person on the planet…

It was a well attended event with over 200 delegates and was very illuminating to me despite that fact that there were unintelligible acronyms liberally sprinkled around most of the presentations…

The title of my session was Business Process Optimization and had originally been planned as an Ovum analyst session which due to illness had to be modified. Rob Hailstone (Senior Analyst) did a great job of stepping at the last minute and presenting the key planned slides in about 5 minutes and then moderating the panel Q&A session.

I’m not quite sure what the attendees expected, as the planned presentation would have been deep in the weeds automated process optimization stuff, which, although I’m sure would have been interesting to the techies present, would have had me asleep in the first 5 minutes (I’d had an early flight ).

As it was the 3 of us on the panel had a much more human perspective on process and together with the audience had a great discussion on a number of topics, including the thorny ‘as-is’ vs. ‘to-be’ debate that I’ve weighed in on before as has my colleague Chris Taylor.

The consensus in the room, including us panellists, seemed to be that there is no ‘fits all’ answer to this, most of us can present both sides of the argument although in most cases, in an ideal world you would map as-is. However last time I checked most of us don’t live in an ideal world and therefore you have to balance the constraints of the project situation.

Another thing that struck me was that there was lots of talk about social capabilities in the enterprise. Obviously the social trend is massive on a personal basis however what’s happening in the enterprise? And more to the point, as a CIO how do you square the circle of control that you traditionally have sought in your IT architecture to the freedom that’s dictated to an extent by the new social paradigm?

The CIOs present seemed to be collectively scratching their heads about this however based on conversations I heard plus presentations attended I think there is a wave of specific social capability in the enterprise that’s coming and our CIOs are going to be embracing it. Obviously there are already social tools int he enterprise it’s early adopters picking this up at the moment and i’m sure that there are lots of ponderings about how best to deploy these technologies to different parts of the enterprise.

I think it’s going to be absolutely fascinating to see what will happen when social is normal in the enterprise in the same way that it is in our personal lives?

Some further food for thought… #BPM #Process

So my challenge did elicit some good discussion, and also the note on Taylorism on the following post (thanks Regis ) prompted some further thinking on my part.

Firstly, and I think most importantly dear readers, although we may differ on our definitions of BPM, you need to understand my definition to ensure that you understand my thoughts. And I think from reading some of the comments  we are at odds as to the scope of the topic on which we’re trying to communicate!!

“communication is not what you say, it’s what the other person hears…”

Max’s reply to one of the comments on his blog illustrates this nicely:

“…what I see from Social being tacked onto orthodox BPMS today I wonder how that would happen with all the complexity and bureaucracy needed ….”

I however, am NOT talking about BPMS; I am NOT restricting my use of the term ‘process’ or ‘BPM’ to mean just the automation of processes.

I blogged here about it so I won’t repeat myself in detail, suffice it to say that in my mind BPM should mean exactly what it says; Business Process Management, i.e:

“the management of all of an organization’s processes”

NOT  something like this which (euphemistically) appears to be most people’s definition:

“management of those processes that we can automate in some kind of system, typically called a BPMS”

Clearly the second definition is a subset of the first, but also implies much more structure (a transactional IT system) and is what I think Max and other commentators rail against when they talk about the rigidity of the systems.

Let’s also pick up the comment about Taylorism above. As a brief FYI it was considered to be the first real attempt to apply science to management thinking, had apparent influences from reductionism and suffered from a similar backlash (as did scientific reductionism) as evidenced by Regis’ comment.

However, as in most things in life, a black and white perspective doesn’t serve us here as there is no question that a certain amount of reductionism in analysis and Taylorism in design is extremely useful in creating more efficient business processes. Indeed these  ideas have without doubt had an enormous impact in improving operational efficiency over the last century.

The big question (;-)) however is how much to apply to which processes in an organization. Max, I think we disagree on some things however on this we can totally agree;

“I propose the best businesses are those where the innovative powers come from within and from the bottom of the hierarchy – from its people!“

and therefore building process structures that stifle people’s innovation and ideas are worse than useless.

However, (again black-and-white thinking doesn’t serve us) to therefore say that standardization is blanket wrong is unthinking dogma driven from principle, rather than the informed result of some sensible thinking.

The Customer Operations Director of Best Buy Europe said;

“Standardization liberates people”

meaning that removing the operational pain of not having the easy, standard process information to hand about how to do things , directly related to the Customer Journey, freed people up and gave them more time to interact better with their customers. The results have been not short of astonishing in terms of Customer Satisfaction scores, volume of sales etc, as I mentioned in the original ‘argument‘ post

Standardization therefore doesn’t disempower people, on the contrary, if done right, it empowers them!

It’s about time somebody put some numbers to this

Mike blogged on these shockingly high numbers produced by IBM, Gartner et al and all I can do is applaud the fact that people are starting to wake up to what the lack of well managed end-to-end processes is costing us all.

And I mean us all; inefficiencies in the private sector mean products cost us more, in the public sector they mean higher taxes (and I know all too well what an inefficient public sector is like, I live in France.. ).

I find it astonishing that more companies don’t count the cost of process inefficiency; just because something might be difficult to measure and/or intangible does that mean it’s OK for management to abdicate responsibility for it?

Here’s a true anecdote from one of the vanishingly rare organizations that has tried to count the cost of this, which might illustrate the point:

A couple of years ago I was sitting with the Operations Director and Finance Director of a UK central government agency, budget of some £6 billion. The Ops guy said;

“We have a problem with process standardization. we have about 5500 people doing the same things in countless different ways”

When prompted to put a figure on the inefficiency he said;

“We did a quick and dirty project which highlighted that we were wasting between £300-500 million per year”

Gulp!

How many Boards of Directors would turn a blind eye to between 5-8% of physical stock somehow going missing from company warehouses every year??

Just because we can’t see process inefficiency doesn’t mean it’s not there…

Brown cardigans or bull…..?

TPN is spot on, there is an awful lot of brownness or bull@~*# in the business world in general and I wholeheartedly agree that we should challenge the status quo!!

Craig; coffee on you last time, beer on me next, I’ll let you know when!

let’s have an argument…

Prompted by a comment on an earlier post I pondered this for some time, not wanting to be close-minded, as the opinion that Max Pucher expressed frankly astonished me. I  spoke to a number of other people and they were all of the same opinion as me so I thought, what the hell, let’s start an argument, they’re usually good fun and can elicit some really good discussions that can move the thinking on.

Skirmishing over here’s the first salvo:

Max says:

“Standardization is fine for manufacturing, but you can’t standardize people and how they interact.”

Oh Max, you couldn’t be more wrong. You absolutely can and more importantly you absolutely should. Let me however add a disclaimer: I’m not suggesting that we impose rigid, unchangeable processes with no flexibility or required variance for locality, product etc., simply that there is a best way to accomplish anything and that operating efficiency demands that we implement it.

It is true that “there is more than one way to skin a cat” however – ask any sheep shearer – there are only one or possibly two most efficient ways. Just because we’re talking about human interaction does not mean that we can’t standardize how things should happen.

As an example, we have a client who, prior to Nimbus’ involvement, had a huge problem in their complete customer service operation, ranging all the way through the customer journey from retail to contact centre to back office, (100% human to human interactions) with lack of standardization.  By standardizing their operations based on the Nimbus Control platform they now have:

• saved hundreds of £millions in costs
• removed uncertainty of operation therefore increasing the amount of time sales focused people can sell, increasing sales by tens of £millions
• increased customer satisfaction scores in direct proportion to usage of the system
• dramatically increased the buy-in and involvement of the more than 7000 staff involved

This does not remove the requirement for humans to act as humans, is not making them robots, it is simply removing the basic problem that all companies have which is getting the right information to the right people at the right time. If you can solve that problem you can gain massively as evidenced above.

To push the argument further: how do you ensure compliance with external regulation, manage operational risk and business controls unless you have standardization of operation? Briefly; you can’t, and this is driving wholesale uptake of this thinking in heavily regulated industries as getting this right isn’t simply a matter of money saved or earned, it can make the difference between (company) life and death. I’ll deal with this in a later post.

Comments please, the more vehemently expressed the better!!