Moe's SOA & BPM Blog

There is the assumption that the behaviour of people involved in a business process is predictable and consistent. Too many business analysts (mainly Dark Knights –see earlier blog) still expect a manual process step to be carried out by staff in the same way, over the same period of time, with the same outcome, regardless of the context in which the are working. I’m not talking here about process constraints or business rules, I’m talking about some of the irritatingly human foibles that blight the best laid plans of (computer) mice and men.

For instance, imagine you are a call centre agent (don’t mock, this could you be soon too) faced with a new ‘improved’ customer service screen to enter their phone call actions. Last week you had a nice green 3270 character-based screen where you could type and tab through each screen in less time than the call took. Your shiny new screen has been WIMP’d (Windows, Icons, Menus and Pointers) so that you now click directly on the relevant field and pick from a predetermined list of outcomes ‘to make your job easier’. As Any Fule Kno (anyone who has done data entry) a good typist will fly through the green screen faster than you can say ‘computer says no’. Point and click screens require advanced spatial awareness to master (something the sat-nav generation never picked up), and then make it difficult to use by restricting choices to a scrolling drop down list that never fits what you want to say.

Surprisingly, these staff are expected to produce the same output in the as quick (or quicker) than before. In practice the time increases, or the quality goes down or, more likely, both. This doesn’t seem logical to the Vulcans who have designed this new process, but to the humans remaining it can be all too obvious.

Sadly, there is still too little user input in the requirements gather for process and system change that takes place. Even in the highly vaunted Six Sigma and Lean Management methods and practice, there is still an (unspoken) assumption that the staff are just automatons that don’t need to worry their pretty heads about how the process should work because the Black Belts know better and will condescend to show them best practice.

Typically the requirements are agreed with the departmental manager who has only the vaguest idea about how the work is actually done. The manager may understand inputs and outputs for their part of the process, but they probably don’t know about Doris ringing accounts hourly to sort another badly keyed order to ensure it gets processed.

So don’t look surprised when you tell your staff of the marvellous new system that you are putting to help them is met with less than total enthusiasm. You are not helping them, you are just changing one unsuitable system (for which they had figured out the workarounds) for another unsuitable system (that is broken in different ways that will take them weeks to work around).

The V-signs you are getting behind your back are not for Victory…

John “Robbie the Robot” Moe

One of the key roles in process improvement these days is one that has been around in various incarnations since man could first spell process. The humble Business Analyst (often shortened to Bus Anal to amuse the sniggering classes) was originally a role taken on by someone blessed with common sense and the ability to communicate, who was stuck between a bunch of users, who didn't know what they wanted, and a bunch of techies, who tended to deliver something clever (but not necessarily useful) because they could.

This facilitation and translation role proved, on the whole, to be a less worse way of running projects than the traditional 'chuck the requirements over the wall and see what comes back' approach in common use then (and, in many cases, now).

Emboldened by their modest successes, these Business Analyst Professionals (BAPs - stop sniggering!) decided to carve out a lucrative niche for themselves, based on their mystical powers of communication between the vague users and the pedantic developers.

However, some of the Anals soon started turning to the dark side and increased the mysticism of what they did by inventing their own language (what is a Use Case?) and methods (Elicitation??), which obscured the users from the developers, who found themselves without a direct communication channel to the delivery team. (Remember: even techies have feelings, when it computes). This led to the BAPs becoming Dark Knights using their position to impose a filter through which the information was passed, to which they would add their own interpretations, beliefs and prejudices. Not that this was not usually intentional, but a natural consequence of the communication chain that had been created.

Luckily, other BAs understood their potential to promote the greater good - by increasing the communication between users and IT, not reducing it. They reasoned that the more business and technical folk discussed the challenges and options directly, the more likely the optimum solution would be reached. Of course, to do this, they had to find a way for both parties to speak the same language, to reduce ambiguity and frustration on all sides. These Supermen (including Superman, Supergirl, Superdog, but not silly old Superboy) worked selflessly to facilitate effective workshops, using graphical tools to ease understanding and provide clarity, which allowed all parties to communicate through common process models.

So here we are at the beginning of 2009, in a world controlled by the Dark Knights and Supermen. Which costume is your BA wearing?

John 'Comic Book Guy' Moe