Practical process anti-pattern: NAP

No Aggregated Participant (NAP)

It was noticed that the use of swimlines forces to put too much details in the diagram thus making it not easy to understand. With swimlines there is no place for a group of "tiny" activities which are carried out by several participants (each of them already has her/her own swimline), or "aggregated participant".

Without swimlines the use of  "aggregated participant" may simplify complex diagrams.

This simplified diagram is very close the pattern IPS (Initial Process Skeleton, see my book www.samarin.biz/book) and the "Approve proposal" activity is similar to the pattern DAM (Delegation Authority Matrix - see http://improving-bpm-systems.blogspot.com/2012/07/practical-process-pattern-dam.html).

Actually, we follow the pattern DIP (Decompose In Patterns - see http://improving-bpm-systems.blogspot.com/2011/06/practical-process-patterns-dip.html ).

Thanks,
AS

Practical process anti-pattern: RID

The anti-pattern Ruined in Details (RID) was detected while looking at business processes documented by the users.  Often, the sequence of activities (or tasks) is the following:
...
Role B: receive documents from role A
Role B: do your work
Role B: send documents to role C
Role C: receive documents from role B
Role C: do your work
Role C: send documents to role D
...

Sure that receiving and sending documents are important, but those activities don't add the value. Indicating only value-added-value activities (e.g. "do your work") will make diagrams more compact and easier to understand.

Maybe this anti-pattern is a sign that there are problems with integration?

Thanks,
AS

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

Practical process anti-pattern: DOUM

Avoid the "DOUble Master" (DOUM) anti-pattern (section 5.6 of my book "Improving enterprise BPM systems")

As coordination can be carried out by an application or by a process engine, we have to be very careful to avoid the “double master” anti-pattern. At any moment in time there must be only one master responsible for the coordination of a particular process instance. (Of course, the coordination role may be delegated if appropriate.) This is analogous to a well-organised meeting where the chairperson decides who talks next.
Also well-coordinated work improves the security and integrity of data. It can be a useful design pattern to consider that only the person who has accepted a particular human activity can modify the business objects associated with that human activity. This is a dynamic granting/revoking of permissions which is synchronised with the process. Something like in the diagram below (which is not a valid BPMN as there are no "claim" and "unclaim" events defined).

The non-recognition of this anti-pattern can be very costly. We have observed a BPM solution which allowed the modification of data by a process engine, by an interactive application (i.e. by a human) and by a batch at the same time. The coordination of activities was based on data and, if necessary, the application or the batch could “correct” the process. The process engine was used mainly for the handling of three human activities, and the implementation of this solution (for a relatively simple business process) took several man-years.

Thanks,
AS