Re: BPM vs. BPMS: How To Think Big and Act Small

This is a reply to http://isismjpucher.wordpress.com/2012/08/27/bpm-vs-bpms-how-to-think-big-and-act-small/ blogpost.

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. 

At the same time, I agree with your “ ...the following is needed to make BPM work” list.

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.

Thanks,
AS