Adventures in BPMN?

Keith Harrison-Broninski is undertaking an adventure in BPMN to demonstrate its shortcomings and to promote an alternative approach to descibing business processes.

... I will take simple scenarios drawn from everyday knowledge work and
show how BPMN cannot express these situations. I will also show how
easy they are to express in the Human Interaction Management notation ...

Unfortunately, he chooses to ignore the rules and semantics of BPMN (it is not just a set of Visio shapes) and so detracts from his argument. There are plenty of issues with using BPMN but a good starting point is to use what is there at BPMN 1.1 correctly. For clarity, I have reproduced the offending diagram below:

This diagram shows the following incorrect BPMN expressions

• Messages (dashed arrows) originating at gateways
• Messages between activities in a POOL (the saleperson, technical consultant amd account manager are LANES)
• Use of message as a sequence flow
• Loops

I think that the BPMN that expresses the ideas behind Keith's drawing is:

Note that the loops continue (perhaps indefinitely) while the proposal is not OK.

Keith asks a number of questions that purport to show that BPMN is inadequate for his purpose

What are the goals responsibilities of each player?

How can the salesperson know what the others are looking for?

etc

None of these questions are relevant to the business process and the purpose of BPMN. Overloading an expression of sequence, orchestration and choreography with specification of the activities, policies and human interactions will confuse rather than communicate. There are plenty of other modelling artifacts that can be employed in an enterprise architecture to complete the picture.