Thanks Max for a good post which is commented below from my "managing by business processes (BPM) methodology" (www.samarin.biz/book and http://improving-bpm-systems.blogspot.com/).
I disagree with you that BPM == "flow-charting". Certainly, BPM may use several coordination techniques – see http://improving-bpm-systems.blogspot.com/2012/07/coordination-techniques-in-bpm-social.html
Also, I disagree with you that "adaptive processes" are not possible in BPM – see http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html
I agree with you that BPM as discipline and BPMS are very different things. In my experience, they can be perfectly used within a proper architecture (i.e. “to think big”).
My experience relative “The NINE Contradictions in BPM Implementation Principles” (BTW, what is the origin of those principles?) is below.
- If BPM would be capable of being business-driven then there is no need for executive enforcement.
AS: It is possible to be business-driven if BPM is properly architected.
- If the implementation of processes would really happen through users there is no need for governance.
AS: It is for business to decide. Some governance is always necessary, maybe business one not IT one.
- As business users can maybe draw a flow-diagram but can’t make it executable, the BPM stages are all performed by experts, actually reducing agility.
AS: Not necessary “reducing”, as the IT agility maybe higher (thanks to the architecture) than the business agility.
- Both BPM methodology and BPMS ignore that users understand processes in terms of content and context and not in flow-diagrams.
AS: Not at all. Processes are positioned as the help for the users to carry out their work including also the handling the content.
- To change business culture is a long term prospect and collides with short ROI time frames.
AS: BPM applications are the best example of agile projects. The ROI is great.
- What kind of culture change should be necessary to motivate people to follow flow-diagrams all day.
AS: Again, disagree that BPM == “flow-diagrams”
- To reduce scope creep and ensure ROI, governance limits end-user requirements and achievable quality.
AS: IT governance or business governance? In any case, late changes of user’s requirements are very welcome.
- A holistic BPM methodology is then fragmented over many different software products for implementation.
AS: Yes, BPM is vendor-driven so far.
- As the fragmentation requires governance, any change requires long-term planning and therefore reduces actual business agility.
AS: The architecture enables the agility.
- If a BPMS is chosen to match current needs and maturity level then it has to be replaced frequently as the business matures.
AS: The architecture also helps with this.
Obviously there are several different BPMS, few BPM methodologies, a huge number of BPM implementations, but still missing parts are BPM reference model and BPM reference architectures.