Where BPM sorts of solutions can be very powerful is when you have somewhat technical domain experts who can’t code, but can model or read a business process diagram. Spreadsheet wizards tend to find this kind of pseudo-coding easy. I walked through an accountant responsible for our sales commissions how to use Process Builder (Salesforce tool) and sent him some documentation to reference. It took him a couple weeks, but he automated a lot of the headache in that process without me having to spend the time to learn the domain in depth to code up a solution. I’ll have to rebuild that piece pretty soon anyway (it is a Salesforce tool after all), but it has provided a lot of value in the mean time, and now I have something to reference when scoping the long-term solution out.
Poorly/cheaply/quickly built applications can run into the issue of requiring a developer resource to make changes to processes, and that can be very problematic for a business. It can get worse when the business hacks together some other solution with spreadsheets and now the source of truth is spread-out (pun intended). As much as I dislike solutions like Salesforce, they do allow for quick, point-and-click changes which is something that Rails/Phoenix approaches which require a developer resource aren’t very good at unless the change is designed for.
BPM / declarative business process modeling solutions would be good for communication and frequently changing domains. That being said I think the line where a business should just call up an experienced consultant and have them build it is sooner than typical.
