To code or not to code?
Many BPM vendors are trumpeting their low or no-code solutions. But just because something is user-friendly, is it a good idea to let anyone take the controls?
The advantages of no/low-code BPM are that the people who own the process are the ones able to design a solution, such as the vendors. Without specialist knowledge acting as a gatekeeper, this approach is in danger of creating a diffuse collection of solutions.
If you are nervous about BPM applications running out of control, consider centralising them. A single point of information for BPM tools is useful when processes conflict with one another, as these conflicts can be managed and a strategy can be put in place to deal with it. As conflicts cause friction in a process, this is a natural opportunity for BPM to lead the way forward and increase efficiency. This approach requires oversight and is not likely to happen easily by evolution.
The problem is that the skills to create code are not necessarily the same skills required to create an optimal process: technologists' skills don't always tally with those of the best gatekeepers. Businesses realise that putting the capability in the hands of people who have a deeper understanding of the process is ultimately of more value; the resulting processes can be overseen centrally and added transparency is a benefit to the organization as a whole.
The answer is to manage the BPM users and the technologists so that they compliment one another.
Before implementing your technology ask:
- Who would be the best person to use this tool?
- What level of oversight should they have - and who should deliver this?
- How much technical support is required - and at what stage of the process?