The Eclectic Zone

[tweetmeme source=”ashish_bhagwat” only_single=false]

I read with immense interest, the point made by Theo on how salesforce.com fluked the BPM model right and Jim’s post on Heathrow airport case study.

There are two reasons I found these interesting. One, both of the above make a similar point on what makes up an effective BPM solution and Two, and more importantly, none of the two might have actually started off as a solution qualified as a BPM solution.

The second point is very important and probably one of the most important questions that we all, in BPM community need to delve on. I have seen many a successful BPM solution that has been more so in hindsight. And a lot of hyped up solutions/initiatives that started off as BPM solutions ended up as duds.

So, how do we qualify a solution as a BPM solution or a problem as screaming out for a BPM solution? Sample some of these:

• A bank looking to unify their customer experience on sales and services across the product catalog. In the stack, apart from the portals & collaboration technologies, we have an important placeholder for workflows, orchestration, & integration. Vendors in the short-list – Platform, Case Management, Pure-play BPMS, & other internet channel vendors with backend capability on integration and workflows. This one doesn’t go to the BPMS vendor. Is this a case for BPM, you bet! Why would a BPMS vendor lose out? Hmm… (And interestingly, it happened in at least two places with the same scenario playing out again, with the same result and similar conclusions)

• A telecom giant from one country and an infrastructure behemoth from another form a venture to offer telecom services in one of the two countries. The Telco brings in the processes from experience, and starts laying down everything from scratch (almost) in the new place. The series of workshops ensue around processes, the scenarios, the best practices, the technologies; and finally around the vendors that could come down and get those running in possibly a record time with their off-the-shelf solutions. Process models are created in Word, Visio, Power point and whatever made sense for program teams. The flows would go everywhere, from Siebel CRM to Oracle stack to Kennan. Launch happens, everyone is happy. Successful story for BPM? You did processes, yes, very well… and did you use any of the BPM (or supporting technologies), actually in hindsight. But does anyone look at this as BPM? In hindsight, some do. Well, did they qualify it as BPM at any point of time? No.

• A very successful directories publishing company, facing immense demand & cost pressures thinks of an innovative way to get their artwork done (all of us would have seen the different types of ads that appear in the yellow pages, a lot of them have artwork involved – the kind one would get professionally designed from ad agencies). Once the sales rep closes a particular requirement with a customer, the scanned copy of the sketch, along with a bundle of requirements and specification is outsourced to a more cost-effective studio, across continents. The collaboration happens for thousands of those artworks, with varied degrees of complexities and in time for the publication to be done for the city. This happens for every city and state covered by the company across the year with calendared publication. Central to this collaboration is a strong workflow engine combined with an equally strong content management system. All done in-house over two years. BPM? Oh, yes! Did they call it so, now they do 8 years after they did it!

• An Insurance company, after years of establishment and successful operations, decides it needed to re-define the processes. Redefine? Well, know what’s happening on the ground, across divisions-across geographies, record everything, find out what could be done better, and do some refinement. Sounds simple? No, scary actually if you consider the hundreds of ‘identified’ processes – not to count variations. But, wait, you have these BPA tools & all of our technologies that would make this easier to collaborate and work out the models across the geos and divisions. Well, BPM to the rescue. One year down the line they were still drooling over this, trying to make some headway. But, in the mean-time, some one, in one of the divisions went ahead and published the process models using PowerPoint, SharePoint and some tweaking with .NET? Everyone jumps, calling it an achievement. Successful for sure, call it BPM – in hindsight. Was this one done the way we like calling it BPM technology or methodology, still drooling…

• A big telco decides to re-architect its whole stack. Yes, the whole stack. Huge program, crossing multiple towers, with two distinct towers dedicated to the BPMS, Integration and Process Definition. A deeply involved exercise on platforms short-listing ensues and decisions made. One of the leading Integration vendor and another leading pure-play BPMS vendor selected. The methodologies, architecture, design, process implementation – all follow and with some brilliant minds involved, 1 year hence they go live with bunch of processes. A whole bunch of BPM practices followed, and whole bunch of them just scrapped or left in a bin (leading to some noise by hard-core BPM folk but work went on). All goes well – esp. in the context of the ambitious plans involving lot of bravado. BPM? Yes. In intent, in Design, in execution, and in result. Is it publicized as much as one? No.

Few more examples are doing a ticker in my head, but I think these are sufficient for me to come to the point that I’m making. It’s not so important to qualify something as BPM, for it to be a successful BPM implementation.

We see a whole lot of energy being spent (within the customer/vendor/SI/consulting organizations, and among analysts & BPM community) on qualifying the initiatives as BPM, identifying the best practices and trying to enforce them. I’m not saying that it’s not important to identify and follow the best practices. But, what’s important is to remain true to the BPM drivers and objectives. And that is, to make an impact on customer experience and measurable parameters that really matter. If you do that, you will end up doing what’s best for the objective, call it BPM then if you wish! Pre-qualification of a problem (as a BPM candidate) or solution (as BPM implementation) isn’t as important as it seems, in hindsight.