Peter Schoof started a conversation recently by asking 'Is Zero Code the Future of BPM?' The conversation has included a lot of ideas.
I have been a fan of the idea of zero code for a number of years for several reasons, here are a couple.
- Typically, the services portion of a BPM project can cost more than the software.
- It is difficult for process owners to tweak or alter a process on their own so it can take weeks for the change to take place.
Why is zero code a good idea?
Over the last decade, more and more companies don't like the idea of spending more on services than they do on the software. It only makes sense for BPM vendors to address this by making BPM easier to implement.
If a process owner sees a way to alter a process to make it more efficient, they have to get IT involved. This can be costly and it can take a while. It is far more efficient to put it in the hands of the business process owners
Why it may not be an achievable target?
Integration to other software or other data sources will always be an issue that is difficult to configure rather than code.
Still, zero code is a good idea.
From the BPM vendor point of view - They need to find ways to reduce the services component of their BPM sale. Zero code is a reasonable goal.
From the process owner's point of view - They want more control over their processes. If process improvement is a goal, then it is a good idea to remove the impediments to improvement. Very often IT is an impediment.
Vendors seem to be working towards less coding [zero code], only time will tell.