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

and

• 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”

Why?

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

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

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?

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!

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…

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

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


]]> http://markcotgrove.wordpress.com/2011/05/05/lets-have-an-argument/feed/ 10 markcotgrove http://markcotgrove.wordpress.com/2011/04/22/jamie-oliver-teaches-two-things/ http://markcotgrove.wordpress.com/2011/04/22/jamie-oliver-teaches-two-things/#comments Fri, 22 Apr 2011 13:41:49 +0000 markcotgrove http://markcotgrove.wordpress.com/?p=154 ]]> Firstly his core message, which is spot on and for the record I believe it is frankly both astonishing and almost criminal that governments and parents don’t address this.

His second message I’m sure is unintentional, however from my perspective it’s this:

“It doesn’t matter if you’re dyslexic and/or not particularly technically strong as a presenter – if you’re passionate people will listen”

I’m sure I’m not alone in having sat through too many presentations  with extremely capable people who are ever so eloquently boring me to sleep, even if I’m interested in the content…

I would give this piece of advice to anyone who is public speaking:

I frankly don’t care about what you’re saying unless you’re passionate about it!!


]]> http://markcotgrove.wordpress.com/2011/04/22/jamie-oliver-teaches-two-things/feed/ 0 markcotgrove http://markcotgrove.wordpress.com/2011/04/22/why-mapping-as-is-can-be-quite-a-good-idea/ http://markcotgrove.wordpress.com/2011/04/22/why-mapping-as-is-can-be-quite-a-good-idea/#comments Fri, 22 Apr 2011 13:29:07 +0000 markcotgrove http://markcotgrove.wordpress.com/?p=134 ]]> If this doesn’t frighten you and/or make you extremely skeptical about so-called ‘experts’ then I don’t know what will, however I promised to tell the story in an earlier post …

Names and places have been removed to protect the innocent.

We were introduced to a large hospital group that was about to implement SAP. The CIO was an ex SAP person, IBM Global Services was the SI and numerous people from SAP were involved in the project;  it was apparently one of the largest implementations to date into a healthcare business and accordingly had a very high profile.

The short answer from our meeting with the CIO was the following:

• can absolutely see that approaching the implementation this way makes complete sense…
• ….can completely see how this would help our company…
• …can’t possibly do it as we’ve already signed the contract with IBM GS and we can’t modify it now

We graciously retreated and waited for them to call back.

18 months later….

IBM GS have gone home with a ‘successful’ implementation to the contracted ‘on-budget, on-time’. The client has been left with a disaster…..

IGM GS have, in their wisdom, decided not too confront the as-is/to-be issue and therefore haven’t actually realized that a hospital is a hospital and the core processes is the same everywhere, PIPOHA (patient in, patient out, hopefully alive). They decided that since there were 9 different regions (same country, same laws, no sound reason for much process variance) they should therefore implement the system in 9 different ways…

Would it be cynical of me to suggest that it was in fact in their interest to do this as it would clearly result in many more chargeable days? (bear in mind that this would have been decided before contract signature and therefore the budget would have reflected this).

Unsurprisingly the call back arrived.

The client invited us back in to try to help sort out the mess as they had a system that nobody was using and had cost multiple millions to implement, (one of the IT group joked: “It’s the most expensive holiday booking system I’ve ever seen”). SAP had given them an estimate of the training rollout which was incredibly time consuming as they had to train differently in each region (it was measured in years!).

In short – Nimbus Control was deployed as a process layer on top of the SAP system displaying end-to-end processes with both the manual and automated steps shown and the training was delivered dramatically faster.

But that’s not really the point of the story.

Had IBM GS actually had the client’s best interests at heart they would have mapped as-is first and would have realized  that each region was in essence the same and that they only needed one instance of SAP to support the whole company.

Of course this would have meant that their consulting days would have reduced dramatically as well…


]]> http://markcotgrove.wordpress.com/2011/04/22/why-mapping-as-is-can-be-quite-a-good-idea/feed/ 5 markcotgrove http://markcotgrove.wordpress.com/2011/04/21/magic-wand-or-the-usual-crap/ http://markcotgrove.wordpress.com/2011/04/21/magic-wand-or-the-usual-crap/#comments Thu, 21 Apr 2011 15:41:59 +0000 markcotgrove http://markcotgrove.wordpress.com/?p=101 ]]> My colleague Chris Taylor recently returned from a Nepalese hiking holiday with some useful and relevant perspectives on the old thorny issue of ‘as-is’ versus ‘to-be‘, inspired bizarrely by hiking boots!!

I thought I’d weigh in briefly as I’ve seen lots of companies struggle with this issue. On balance I’d agree with Chris and I’ll state a few additional reasons  to what Chris has already mentioned (read his post to get the rest of what I think):

• gaining buy-in for process change is hugely important, we all know that. Presenting a crap ‘as-is’ process is a fantastic way to gain shop-floor buy-in to change, as people are metaphorically smacked in the head about how bad the existing process can sometimes be. It becomes apparent to everybody that change is required and the resistance frequently magically vanishes.
• baselining processes change is usually not easy to do however is often crucial to further process initiatives within an organization. If you can show a valid and valuable ROI on completed process change your internal business case is dramatically simpler to get by the people holding the budget. Obviously mapping ‘as-is’ gives you the tool to help this business case.
• IT implementations -I’ll explain in another post a real world example where mapping as-is would have potentially saved literally millions

You’ll note above that I said ‘on balance’, let me clarify: In an ideal world I think it is absolutely the right thing to do, however most of us don’t live in one. I’ve seen countless situations where senior executives will not be convinced as they want the ‘magic wand’ picture as quickly and as cheaply as possible.

Sometimes we need to be pragmatic, which might mean lying  being economical with the truth…. a ‘skunk works’ workstream building a certain amount of as-is in order to baseline, hidden from prying financial eyes, can be immensely valuable to the ongoing project/program and to your chances of being able to continue…


]]> http://markcotgrove.wordpress.com/2011/04/21/magic-wand-or-the-usual-crap/feed/ 1 markcotgrove