I recently commented/ interacted with several people in the Business Process Management (BPM) online community. I’ll try to recap here all my recent contributions in this and the next few posts (just as a way for me not to forget about them):
Choosing the first process to implement (Adam Deane blog, 22/9/2010)
I basically agree with the post: the approval processes are the Hello World! examples for BPM (and are the most used in teaching, in fact): easy to understand, design and demonstrate.. and can quickly gather consensus among the stakeholders.
Not so sure about tasks that are poorly defined: understanding can be different between the people (also within the customer enterprise)and could lead to delays and fights between the roles (our experience). How to deal with this?
The BPM sweetspot (Adam Deane blog, 6/10/2010)
I fully share the view of this post.
I would also add another reaction by customers when they finally see the running process execution:
– WOW! look at that. Nice form, nice dashboard! Hey, wait a minute! Why do you have an input field for time with “:” instead of “.” as a separator? Mmm, and why this form is missing all the 27 fields we actually need for our credit card request management?
My point is: yes, execution is more intriguing, but it also leads to identifying process issues and problems. Most of them are absolutely useless (especially when you are doing a demo!).
But when you come to build real apps, you can also get feedback like:
– Look, you missed an activity (or a dependency) here. And these two should be switched.
– Well, this is interesting (would say the BP analyst). But wait, why you didn’t point it out when we discussed the models?
– Welllll, basically I didn’t notice.
My bottom line: execution is not just the sexiest thing, sometimes is also the most useful for interacting with the customer (even if you are an analyst).
Who is a business user? (Adam Deane blog, 23/10/2010)
I agree BPMN should not be blamed.
On the topic at large, let me point to my comment to another of your nice posts: “The BPM sweetspot” (http://adamdeane.wordpress.com/2010/10/06/the-bpm-sweetspot/).
My thesis is: it’s good to have business process models, to have a notation, to standardize it, to make people (analysts and experts) use it.
But I’m fully with you: you cannot expect ALL the kinds of users to adopt it.
I think each user needs the right tool. For some it can be BPMN (full), for some it can be a simplified notation, but for some (typically the end users) it must even be a running prototype of the application. In our experience this let us identify a lot of process issues that no customer ever spotted in the BP models (although in principle they were able to understand the notation).
Following the rules (BPMS Watch, Bruce Silver blog, 5/10/2010)
Dear Bruce,
I really appreciate your work in education and consolidation of BPMN (I read your book and I read with much interest also your recent online decalogue for BPMN design).
I have mixed feelings on the target users of BPMN: business users can for sure understand and design BP diagrams (if we assume usage of a “baseline” version of BPMN), but as you (and the other comments) abundantly demonstrate, it’s already a big challenge to end up with a reasonably well-formed and sense-making model.
However, this is only the first step.
The actual challenge would be to get value from these models: models should help improving processes, identifying requirement mistakes or other issues, possibly automatically executing/prototyping processes, and effectively documenting.
The question is: given the difficulty to reach the first objective (correctness), do you expect that the actual value will ever be achieved?
Our experience is that BPMN models are of huge value for process designers and engineers, but when it comes to getting feedback from the stakeholders (business users,…) nothing worked better than interacting upon running prototypes.
We recorded precise measures of our activities and productivity.
The good news was that we were able to automatically generate such prototype from BPMN and thus achieve quick redesign cycles.
(we presented our experience at BPM 2010, Hoboken, NJ too)
