Automate... or die

I was reading David McCoy's recent Gartner blog suggesting that BPM professionals might consider using the term "business process automation" to describe what we do. I would say yes.

If one can visualize or imagine the possibility of radical transformation that includes the elimination of unnecessary steps, this cannot but help model for continuously improvement. And as someone who has spent decades on McCoy calls a “BPM that involves model-to-engine delivery” I agree that giving businesspeople the ability to automate is very significant. 

Indeed, pragmatic automation is what provides the financial-return to fund any aspect of BPM in these challenging times. During this recession breaks we are seeing that modeling or merely tracking BPM projects are being deferred, but we continue to see significant investment (and rapid payback) from BPM initiatives that deliver automation. By starting without process automation capabilities, organizations may find they don’t fully understand how business-driven automation could enable their vision.  It would be like starting a Master Data Management initiative without ever having exercised a relational database.  

It would be really easy to miss functional opportunities or take true advantage of the potential of BPM. So perhaps the best thing to do would be to consider automation a core capability of BPM - and give vendors that lack automation the challenge of adding it.  This would position all of BPM as the businessperson’s tool for definition, automation and continuous improvement and would allow a clear picture to emerge – where BPM brings modeling and automation to marry with the technical disciplines or platform/SOA.  This would allow all constituencies the chance to contribute  to their fullest – and reduce the need for more acronyms.

McCoy is also right when he says that 'BPM' now means too many things to too many people. It is the elephant surrounded by blind pundits. Depending to which part of the elephant you are hanging on to, the definition changes. It also seems that some of the discussions about BPM are rather too quick to say what it is not – for example, that a BPM should not be asked to include complex event processing, or business rules, or customer interaction management, or, as we have just discussed, process automation. Why not? The vision for BPM should encompass complex event processing, business rules, customer interaction and automation. Now that is an elephant worth getting to know.