Dave French, on his blog Dave Thinking Aloud, added to these comments with a nice post Keep the coding out of BPM. The point he makes here is essential:
It would be nice to see BPM solutions architected with clear separation between presentation, data-handling, business decisions, rules and process flow logic. Coding is required somewhere along the way but we should all understand where and who is responsible for it.In a phase 2 solution, code may become unavoidable, as a solution tries to blend in better with the environment and infrastructure of the organization. The approach of 'separation' that Dave mentions finally helps me get over the argument of the role of business and IT in BPM solutions.
One argument says, 'BPM should avoid burdening IT with business solutions'. The other side says, 'business people don't want the hassle of producing solutions, and it is careless to exclude IT'. Dave's comment, could be a great way to clear that up.
If a process improvement solution can be created, deployed, run and improved by a willing and able business team, IT should not have to get involved, and that benefits everyone. As soon as any type of coding becomes necessary, the 'systems' nature of a BPM solution reveals itself, and IT needs to be involved to think through and deal with the ramifications.
I'm sure many BPM practitioners would argue that a process improvement solution without code is probably Mickey Mouse. I'd suggest that almost any phase 1 process should be at that level, until the business understands better whether there is value in going beyond the mouse, or whether they risk getting a duck.
Too many process solutions bet big up front, with complex integration, coded rules, and fancy UIs - when the original problem remains that the process just needed a bit of rationalization and a way of delivering work faster. If the business team can't do that without ITs involvement, they picked the wrong tool to use.