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
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…. 😉
Leave a Comment
You must be logged in to post a comment.
