Having bugged out of the Agile BPM session, I arrived late to Michele Cantera’s discussion of whether software as a service is a viable option for process improvement projects. She covered off some of the same material as the SaaS and BPM session in February, but there was some new information as well. I won’t repeat the material from that session on the topic of BPM SaaS delivery and multi-tenancy models, so you might want to go back to that post and check that out as background for this. Go ahead, I’ll wait.
One interesting bit, based on 2007 estimates, segmented the BPM SaaS adopters into four categories:
- Pragmatists, forming 49% of the market, who are replacing departmental on-premise applications but don’t have an enterprise-wide scope.
- Beginners, 40% of the market, who are replacing low-end software tools with simple utility applications. These are often small or medium businesses who don’t want to grow an IT department.
- Masters, 10% of the market, who are weaving SaaS applications into their enterprise-wide application portfolio.
- Visionaries, a mere 1%, who are actively replacing on-premise applications with SaaS wherever possible.
She showed these plotted out on two axes: comprehensive strategy versus IT ability to execute. Pragmatists are low on comprehensive strategy but high on IT ability to execute; beginners are low on both, masters are high on both, and visionaries are high on strategy but low on ability to execute (since they don’t need to have internal IT skills). I really like this segmentation, since I think that it provides a good way to characterize SaaS customers in general, not just SaaS BPM customers.
She went through the list of current BPMS SaaS vendors, split out into business process modeling, process-based applications, and BPMS as a service. The SaaS modeling vendors are Lombardi, Metastorm and Appian; BPMS as a service is offered by Appian and Fujitsu. Process-based applications are typically offered by companies who have taken a commercial BPMS and built a specific vertical application on top of it; the underlying BPMS is not necessarily offered as SaaS directly, and in most cases, the BPMS vendor is not the one providing the service (with the exception of DST, whose BPM product grew from their own mutual fund back-office application), since most of them are not in the vertical applications market. There are going to be more entrants into all of these spaces in the near future, as well as changes to the multi-tenancy models offered by the vendors; you’ll want to keep your eye on what’s happening in this space if you’re considering BPM via SaaS, and start to consider how you’re going to handle process governance when your business processes aren’t running on your own systems any more.
She also showed a chart of different SaaS services types (BPO, application outsourcing, hosting, traditional ASP/SaaS model, process-based applications using BPMS/SaaS, BPMS as a platform, BPMS as SaaS-enabling platform) mapped against operating characteristics (operational cost, degree of customization, process agility, cost of process agility, number of suppliers): for example, BPMS as a platform has high process agility, whereas a traditional ASP/SaaS application that likely doesn’t include a BPMS has low process agility.
There was a list of do’s and don’ts of using SaaS for process agility, such as using BPMS via SaaS for pilot projects in order to make the business case for on-premise systems. Of course, if you do that, you might just find that you like the SaaS model well enough to stick with it for the long run.