Depicting process interactions with external stakeholders is a standard stumbling block for BPMN newcomers.
A typical example:
There are a whole bunch of errors:
- “Supplier” pool should be modeled as a “black box”, i.e. not contain tasks. This is an external participant and we are not in position to arrange its work.
- “Create wish list” and “Get proposal” must be connected with a control flow (solid line with an arrow). Message flows that go to the “Supplier” pool and back do not suffice because without a control flow the “Get proposal” event handler won’t be activated therefore no proposals would be received.
- “Get proposal” event is essentially an automatic action, a “robot”, while a task on the supplier’s side would likely be performed by a human. But robots don’t talk to humans.
- Supplier may ignore our request, resulting in the purchasing process waiting forever.
Amazingly, this kind of diagram are typically produced by half-educated analysts; a naive analyst knowing only rectangles, arrows and diamonds would likely draw much better diagram:
I call this pattern “Find a Victim”, meaning “victim” within the organization.
Let’s forget about the notation for a while and switch to common sense to ask ourselves: how does our organization get something from external parties in real life? Well, via its own employees: purchasing managers communicate with suppliers, sales managers or client department employees talk with customers, etc. (I’m leaving automatic B2B scenarios out of scope). They communicate by phone, email or personally - from the process perspective we don’t really care. What does matter - the task “Contact counterparty” should be accomplished. (Well, “accomplished” means that an attempt was be made, not necessarily successfully. Hence the fork appears after the task that checks its result.)
As we can see, the example process can be successfully depicted with a minimal use of BPMN palette. But if the author has learned that there are also circles with the envelopes in BPMN and is eager to use them then he may be in trouble. It’s better to know BPMN either at very basic or very deep level.
A healthy minimalism is your friend: if you are able to depict a process with a minimum palette then it’s good for you! Never drag a BPMN element to the diagram just because you recently discovered it for yourself.
Before the end, let’s consider the use of black box pools - external entities. Should we depict the “Supplier” like this?
Again, be pragmatic - did the diagram become more clear? In my view, “Supplier” pool didn’t add much because we can figure out from the name of the task “Get supplier’s proposal” that there is a supplier around. Now if an element doesn’t make the diagram better then it makes it worse! Simply because extra elements clutter the diagram.
Modeling a counterparty graphically as shown in Figure 3 makes sense only if you follow an appropriate methodology. Within the “Outside-In” methodology for example we’d start not from the selling process (this is an inside-out view of our company) but from the buying process of our client (outside-in). It is postulated in this methodology that the quality of the process from the customer’s perspective is determined by the quantity and quality of his interactions with the process. To emphasize the importance of such interactions they use a special term - “Moment of Truth”. If one follows the Outside-In methodology then usage of a “Customer” or “Supplier” pool and message flows is a good idea because they’ll let visualize the process from customer’s perspective and show all moments of truth.
But most BPMN users didn’t hear about Outside-In and are not ready to accept these ideas. If this is the case then better forget about external entities and depict the process as shown in Figure 2.