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.
A post from the Improving It blog
Let us help you improve your business today. Visit www.consected.com
3 comments:
Hi Phil,
Good article, but I don't agree with your bottom line.
"Rationalization" and "a way of delivering work faster" are only two of the process problems.
A bit of code is always needed to spice up the forms and create custom reports. It might not be a lot of coding, or even highly skilled coding – but it is still coding.
http://adamdeane.wordpress.com/2010/03/09/bpm-no-coding-myth/
I think there's a good lesson to learn from "Lean" here- which is that technology should not get in the way of improving the process. And you can save a lot of $ if you first get the process right and then invest in the code/tech required to make it sustainable. (Often, unfortunately, Lean advocates forget the last part - investing in tech to make the process improvements stick, rather than trending back to previous norms over time).
Adam, Scott, I agree with both of you that a bit of code and focus on technology becomes necessary at some point. Unlike Lean suggests, BPM projects rarely go for a truly incremental / continuous improvement approach (in my experience anyway), as the business customer knows that it is unlikely they'll ever persuade IT to help them with Phase 2. So the try to do everything in Phase 1, leading to poor focus of resources, and half-hearted efforts at really architecting a solution to avoid these coding issues.
I have also experienced too many times the way just a little Javascript here, and a little there suddenly morphs into having the rules of the system enforced in the UI code. It produces a seamless effect for the end user, but makes even the easiest change to the system much harder.
There is an approach in UI design that users learn what not to do faster in a UI that tells them about their errors on submission, rather than at the entry of every field (although the learning curve is steeper). This is the reverse of modern user experience design, so I fear we will see more and more systems that do not separate their logic from their presentation, making them almost monolithic in nature.
Thanks, Phil
Post a Comment