- 11 December, 2008 04:23 PM EST
- How BPM Could Have Saved One Man's Thanksgiving
After taking my son and his entourage of friends to karate practice last night, I had to drop off my car for service. One of my good friends picked me up and then launched into the trials and tribulations going on in his latest project at work. (Being an analyst is a bit like being a doctor – with one difference, instead of asking you about health problems, people ask you about IT problems.)
My buddy is a developer at a large financial services institution and he lives to code. His company has recently outsourced much of its transfer agency work, except for certain trade exceptions that the outsourcer hands off to an in-house trade control group. These exceptions are then processed manually.
Several months ago, my friend and a few others were tasked with automating the process flow for these trade exceptions. The first step involved a series of interviews with the business users in the trade control function, in order to capture requirements. Interviews were also held with the outsourcer to understand what data would be provided when the exception trades were returned to the in-house staff. The IT team designed the solution on paper and then went back to the in-house trade control group to walk through the solution and to determine whether the solution would meet business requirements. The trade control group signed off on the requirements.
This solution involved a lot of overtime on the IT team's part – particularly during Thanksgiving week, which really annoyed my friend's wife. (Let's just say my friend's wife had already clued me in on the Thanksgiving problem.) What I was not aware of was a new problem -- the solution may need to be withdrawn and totally revamped because it doesn't meet business user requirements. In other words, this guy's family Thanksgiving got squeezed for a less than effective solution. Furthermore, this all could have been avoided with BPM.
My friend, being the typical developer type, did not understand why the trade control group thought the original solution design would meet their needs. He was adamant that the solution design was not presented to them in techno-weenie terms. I patiently explained than exception handling tends to involve a great many process paths, many of which are undocumented, are handed down by oral tradition. The business users can't possibly "grok" the solution implications of all these permutations.
More importantly is lack of process context. The in-house trade control group gets these exception trades back from the outsourcer. They are accompanied by lots of data, but there is no way to tell what process steps that exception has already been through, and what the data means as a result. If ever there was a clear case of when process visibility was vital, this is it!
After hearing all of this, I launched into my BPM pitch – since I had a captive audience, stuck in the car with me. My friend insisted that neither IT or the trade control group will go for a model-driven approach. I asked him what his alternatives are? Just do it again the same way and end up in the same situation. I went on and on about the merits of BPM, and my friend turns to me and says, "well, all BPM is a better way of communicating with business users," Yep, you betcha. That's one of the biggest benefits.
Friend:. So I wouldn't be coding, I'd develop the solution via A MODEL?
Me: "yep, pretty much."
Friend: "Nobody really uses this BPM stuff for back-office processes. Give me some examples."
Me: I give him five examples from recent MQ reference check calls.
Friend: Silence.
Friend: "I need to look into this BPM thing. Send me some pointers to those reports your write."
So today, I have unleashed another BPM evangelist on an unsuspecting IT department. Let's see what happens.
