[tweetmeme source=”ashish_bhagwat” only_single=false]
This needs no introduction, BPM in the cloud is the new buzzword. Articles over articles have been written over the advantages of Cloud Computing, and BPM has had its share of glory under the sun. And bringing these two together makes all the sense, with the repeatedly made argument that cloud addresses some of the key concerns on initial investments.
However, I have my own reservations on using the term “BPM-in-Cloud”.
The closest that comes to what’s happening on the ground is “Process-Modeler-as-a-Service” [Not BPA in the cloud, again!] and “BPMS-Platform-as-a-Service” or “BPMS-platform-in-the-cloud”. And this trend is expected to continue for the next couple of years. The true BPM-in-the-cloud (even as it needs to be clearly articulated while BPM may mean different things to different people from technology platform -to- discipline -to- methodology -to- business tool & so on) seems still far away. We don’t have all the ingredients in place, and don’t expect in the next couple of years, to have any success with something like “Business-Process-as-a-Service” or “Business-Process-in-the-Cloud”, which should be a milestone for achieving BPM in cloud in true sense.
Here are some of the key reasons why I think BPM in the cloud is a little far away:
- The success stories of cloud and SaaS have been primarily in the areas where an end-to-end transaction can be defined specifically and managed outside the realms of the organization, and typically more related to an Application. Now, Processes are much more than applications, and BPM application (if at all there’s one) refers to the toolset used to help execute the processes that run across departments and applications. You’re not really using BPM if you’ve picked up an intra-departmental (siloed) or an application-specific process area.
- BPM involves various phases of the overall business management around a process area – Modeling, Execution, Monitoring, Improvement. For every one of these areas, toolsets exist and vendors in the area of BPA and BPMS are already developing the cloud capability but their focus on that front are more infrastructural or around the metadata to ensure multi-tenancy and informational security. In order for a single BPM platform to be able to be clouded, we would need a tie-in of all [or most core of] these phases in the cloud. [Otherwise expect a scenario where the operational data resides in the cloud but without the required analytics capability, requiring you to bring the sliced-&-diced data back to the client environment for analytics or a reverse remote access for the same. And this is just an example] All that would require current capabilities of BPM vendors developed further across the phases of BPM (leveraging CEP, Web 2.0, Social BPM, Analytics etc). Sounds like huge investments for vendors that only some of the biggies can probably afford.
- Most phases of BPM life-cycle are highly interactive with multiple departments across Business Owners, Operations and IT. So, we’re hoping that our collaboration tools are powerful enough to take care of some of these high-interaction scenario in a clouded environment. Or we need Social BPM to take an avatar and bless us quickly.
- I raised this question in an earlier post in my blog as to whether a process, before being clouded, would need to be at least “outsourceable”. Here, “outsourceability” would mean that process controls need not remain within the organization for most part. If you want to run the whole process in the cloud, this could come in handy. It’s another matter that most of us would be still happy if the BPMS and application is moved into the cloud while being accessed by the users from within the organization. But that won’t be called Process being clouded, in a similar sense as salesforce.com is able to move the transactions to the cloud completely. So, to take the point forward, even in something as mature as outsourcing of the processes, we have not seen end-to-end Business processes outsourced in mainstream businesses. Emphasis on End-to-end which is key for real applicability of BPM. As for processes with minimal human touch-points & more systems based transactions, it would be relatively easier to move it to cloud, while increasing the integration & information security challenges.
- And then, we have challenges on metering and billing. I see this as a big challenge since unlike transaction based pricing that some of the current cloud services offer, this one require a Process Instance or Incident or case based pricing. And most of these instances would go back and forth between the cloud and the client due to at least the decision-making involved. Plus, the complications of the SLAs governing those. And if you go for a user based or seat based pricing, it defeats the purpose in terms of objectives of BPM as well as cloud. You don’t want your KPIs to get so distorted over time that they are more governed by how much to pay the managing cloud vendor than which parameters are critical for your business process!
So, in my view an immediately acceptable outcome out of these cloud capabilities being built around BPA and BPMS platforms would be a faster proof of capability with a lower investment on silo-ed or simple processes, without the high-end expectations of turning around the business process efficiency. It’s much bigger effort on capability building and convincing for an enterprise-wide adoption of Clouded BPA or Clouded Process Modeling, let alone BPM in the cloud.