Is it even possible to design intelligent process?

Kicking the bucketEarlier today, I read something that made me snort on my afternoon coffee. Not just because it was funny, but because, to me it had some additional insight that I thought was worth sharing with you, especially when you think about Intelligent Processes and how they can be crafted for a BPM initiative.

Here it is:

Two men walk into a bar. The first man says, “I’ll have some H2O.” The second man says, “I’ll have H2O, too.” The second man dies.

I think that behind that unfortunate kicking of the bucket, there was a good cause. A real good cause indeed, that could make both the bucket and the man proud of the way destiny dealt its blow. Or kick, if you like.

The poor bucket must have initially felt a shock from a sudden unprovoked jolt as the man connected his kick. As it flew through the air in the bar, FAQs like ‘Why? WHY ME?’ must have surely popped up in its mind. But ironically, moments after it landed, it was surely filled with a sense of pride over its abruptly formed dents, which am sure it endeavoured to wear just as a war hero would wear his scars. For, like I said, the cause was good.

And the man. Yes, the one that died, whose name was not BPM. He would have been proud of himself if he were alive to know why he died if he had been dead instead of alive. Well. Whatever. You get the point.

I am badly digressing. I seem to be making this more and more about death, when in fact I mean it to be about something quite the opposite, about making things come alive – about BPM. I digress often. Thankfully, this time, I checked myself before it maxed.

But let’s focus here and let me take you back to the bar scene and ask you this: Who is responsible for the poor man kicking the bucket?

You are probably thinking it was the man’s own doing. He brought the bucket on himself to kick, you say. Maybe he should have said “I’ll have the same, please” A simple “Me too” could have in fact worked much better. At least there wasn’t anything dangerous called Me2.

But I urge you to play out in your mind the few moments before the leg made contact with the bucket, sending it tossing it in the air. If we look at the situation in the bar from a Life of Pi BPM project perspective, the Bar tender becomes the Process Consultant and the two men, the clients.

Apparently, the client – the one that croaked – did not state his need clearly and instead was actually creating a room for misunderstanding. A room so massively huge and utterly dark, that no one realizes that everyone is in there – business users, IT teams, the management, product vendor, implementation partner and the SI – everyone’s in there, groping their way around. And no party knew who else was in there besides themselves, giving them all a chance to blame it on something vague and outlandish like say (gasp!) Business-IT gap! The fools.

So, in the light of all this drama, the BPM fanatic that I am, I sprang into action. I jumped into the joke and chatted up the bartender, while taking copious notes on my little notebook.

Me: “Hi there, Bartender!”
Bartender (breaking into a nice big smile): “Hello there, how can I help you?”
Me: “Can I have a double Caorunn Gin and Tonic”
B: “Thank you, you too. Tuesday is fine”
M: ”Eh? Err…, I said I want a Gin and Tonic, and make that Caorunn”
B: “I can try. Where do you want it to run to?”
M:” Huh? I don’t understand”
B:” No Problem. Where do you want the cow to run?
M:”I said Caorunn. UGH. Nevermind. One Gin and Tonic please”
B: “ Sure! coming right up”

After some smart investigation and top notch analysis on my part, the pieces were falling in place. The Bartender happened to be a ‘seasoned professional with 8+ years industry experience’ (he could never do fractions or count in months or be specific). Turned out, he was the best man in the Bar. He was Employee Of Month for 3 years, even though during the first 2 years and 9 months, he was the only employee that faced clients. The rest were all in the kitchen sweating it out, but no one ever saw them nor even knew they existed. The bartender was the only man everybody knew and talked with. He was great with clients. He was able to read and write and talk. Despite ear-numbing loud bar music, he was able to understand alien accents and write down notes (mostly key words) very fast. So when a new customer walked in, he knew when to flash his smile and when to start nodding and when to make certain specific sounds like “Oh.” and “Oh!”. He was apparently a sort of a role model for his probing questions like “Oh?” and “Really?”.

As I discovered, to the normal eye he appeared to be keenly listening and engaging in a bonding, and, I daresay, eliciting conversation, but to the trained eye, he was only going through the motions, and all through that, his specially trained ear heard only a mumbling prattle, but was all the time alert for key words – like 1, 2, 3; or single, double; or whiskey, gin, beer and so on. Sometimes a customer would come up with a request that was difficult to understand – like H2O2. Immediately he did what any Employee Of The Month does best – NOT bat an eyelid. He knew how it worked. At this point during our chat, he gave a big pause, then leaned to me, and lowered his voice to a hushed, conspiratorial tone and offered me a great tip should I ever become a bartender myself, “Don’t ask the customer to clarify or repeat his requirement. That would so seriously expose your ignorance about stuff served in other bars that aren’t served at your own bar. Write it down in your notebook! Figure out a way to deliver what they want. Make it happen. Stretch. Go that extra mile. Deliver. Delight!”

I could almost feel the man’s intense passion and belief electrifying the bar area.

I found a few minutes with his boss who was mostly offshore in the back room. He admired worshiped the bartenders commitment and customer focused drive and in fact was in awe over a recent incident when he fought bar policy to procure 3 litres of H2O2 and had it delivered to a demanding customer, even though it wasn’t a standard item on the menu list. And why? Just so that he can delight that one customer! He called such people in his team ‘stars’. If only he could get more such employees!!

Meanwhile, the other man – the man who survived the bar and who was served H2O was stunned with the developments and immediately called for a project review meeting an investigation. The bartender, his boss, the alive client and few others discussed the situation for days and came to the following conclusions:

  1. Insufficient maturity and engagement on part of the business – They were asking for the wrong things and stating the wrong needs to the vendors. Boiling the ocean must be avoided at all costs.
  2. Governance was necessary and QA needed to be tightened prior to UAT release to avoid unnecessary dents in buckets.
  3. Organization change management might be necessary – business users needed better sensitized to the BPM way of things. They certainly needed to be trained to stomach change more efficiently.
  4. In that big dark room, the vendor was groping flirting with the business in unacceptable ways, and the SI was flirting with IT in equally unacceptable ways.

Because of the enthusiasm showed by the bartender, he was retained as an important member for all future initiatives – especially since he had the crucial knowledge and context of past failures.

After my investigation, I jumped out of the joke and wondered what really stood in the way of Intelligent BPM in this episode.

If you really look at it, it was always the Bartenders job to understand what exactly the two men who walked in really wanted – and in fact if his task was to design an Intelligent Process and deliver intelligent BPM, his job was to really ensure the customers understood their own need better so they can articulate it as accurately as they could. Or should. I am sure you see that in your own assessment of the situation.

But then, put on that old Yann Martel hat again and your assessments and conclusions will change again.

- The two men who walked into the bar could have been product vendors. The bartender could be the SI/implementation partner

- The two men who walked into the bar could have been product vendors. The bartender could have been the IT or Business depending on who was in charge of budgets and product selection.

- The Bartender could have been internal IT gathering requirements from business, before asking the implementation partner to mix the drink.

- The two men could have been internal IT giving distracted requirements to their implementation partner.

As you can see, there is no end to how you can interpret this scene. There indeed can be many ways to interpret failure.

But the fundamental question remains: Who is to take responsibility for the poor man kicking the bucket?

The answer really is not ‘who’. What really caused the dent in the bucket was a conspicuous lack of intelligence. All around.

The best way to ensure delivery of Intelligent BPM is to first of all make sure it is not seen as a joke to start with. You need to begin with intelligence.

It takes a certain basic common denominator of intelligence on the part of vendor, SI, implementation partner, business, IT, and management to really deliver Intelligent BPM. However, no matter what view your Yann Martel hat gives you, demand collective intelligence from the orangutan, the zebra, the hyena, and the tiger, as well as the boy.

Ensure that and then snap your fingers. Outcomes will follow.

Tags: , , , , , , , , , ,

No Responses to “Is it even possible to design intelligent process?”

  1. July 28, 2013 at 8:32 am #

    A HOLE IN MY BUCKET

    I must confess that when I saw the picture I thought you were about to launche into the circular HOLE IN MY BUCKET song

    http://www.youtube.com/watch?v=yD-ffhvefsw

    However, you have nevertheless hit the vast gap between NEEDS and WANTS ….Customers, Vendor, Investors, Academia and Governments pass each other like ships in the night because of failure to dialogue clearly.

    Here are excepts from paper that I’ve recently submitted for publication
    :
    Drucker’s insight is that: “The aim of marketing is to make selling superfluous’ - by which he meant that, if you really find an unmet need and do a good job of providing a solution, you don’t have to do much selling.“

    For Caterpillar, processes, based on long experience, a vision of the business future and superior delivery are sustainable competitive advantages in the field service business. Capture of that knowledge as models, and creation of subsequent systems from such models, is the route in which we are already engaged

    Tom Peters writes about ‘Wanted but not Needed’.

    Meanwhile Clayton Christensen writes about ‘Needed but not wanted’.

    The theme of my submitted paper (co-Authored with my ten-year Mentor Professor Emeritus Gunnar Sohlenius on the application of Axiomatic Design to mobile processes) is getting Customer Needs and Functional Requirements right.

    Wants v. Needs …..It’s AXIOMATIC (=OBVIOUS) that this is where the trouble starts!

    Best wishes from Sweden
    Brian
    Alias Sir George the Dragon Slayer
    Knighted in Canadian Dragons’ Den 2009

  2. July 29, 2013 at 5:04 am #

    Brian, Thanks a lot for this comment. Look forward to reading this paper when it goes live. :)

  3. July 29, 2013 at 7:52 am #

    The best way to “develop intelligent processes” is to use intelligent process developers.

    Invariably, these are the staff in functional units and (for bridging processes across units) IT.

    The problem is they often lack the time, or they have trouble “thinking process”, even though they know every step and how it relates to other steps, so nothing wrong with bringing in a “facilitator” to help.

    See “The facilitator is coming!” at http://wp.me/pzzpB-aG

Leave a Reply