I'm modeling a process in which a contract is being made and send out, this contract though can be send to many different receivers. Do I have to make a pool for every receiver or can I just put all the names in one pool like so?
business A / Business B / Business C.
I couldn't really find it in the specifications.
Thanks in advance!
Hi Ruben,
I agree with Carsten Pitz. One more thought: Receivers (represented by Pools) of messages are processes. Only in the case of external parties, of which you generally do not intend to model their processes, you make an abstraction of all "their processes" in a single black box pool named "Supplier" or "Customer" for example. For all your internal receivers of the contract, you will specify the exact process that is supposed to consume the message. And if you observe to use the ARIS concept of occurrence copies of pool and message objects (not required or even existent in the BPMN standard), it even becomes possible to implement consistency checks that messages sent are actually consumed by the receiver.
Regards, M. Zschuckelt
Thanks a lot for the answer Carsten.
I will keep your advice in mind!
I have two more, simple questions. Do you always need a message flow when you model a send task? And kan you put a message flow from a user task to another pool and then have it return from the pool back to the user task? As to model a conversation between two people.
Thanks in advance!
Kind regards,
Ruben Jonkers
You're right! I could of course use a general name. I have a lot of black boxes in my processes which can be any number of people/companies, which makes it a little complicated for me since I'm very new to BPMN.
Regards,
Ruben Jonkers
Hi Ruben,
I would not model any real names of business partners, let's say "ABC B.V.", as pools. They are likely to change over time, unless they are members of your group of companies or your whole business model depends on it (e.g. franchise license). Even then you might use abstractions, such as "country sales organization", but: Only use such abstractions, if modelling their processes is outside of your project scope. The conversation you sketched with an external pool is feasible, if that is an external party in that sense. If it is internal, consider taking that step inside your pool on a different lane, if you decided that lanes represent roles. In the latter case there might be just a different department playing a role in your process, so there is no need for modelling message flows, because it is all part of your process and the pool as a whole represents your process.
Regards, M. Zschuckelt
Hi Ruben,
the answer depends on your objective.
What is your objective?
While UML is mostly used according case 1, BPMN mostly is used according the cases 2 and 3.
On case 1:
In this case you draw a completely informal sketch. The BPMN is merely a source for shapes and edges. Your BPMN tool is used more or less like a vector drawing tool with predefined shapes and edges.
As a result you draw the elements required to illustrate your idea only. In your very case you draw sending and receiving tasks without a message flow if this is sufficient to illustrate your idea.
On case 3:
You have to create a formal model with all details. In your case you not only have to model the message flows. You also have to model the data interchanged by those messages.
On case 2:
Case 2 is in between. Consequently the resulting collection of diagrams is semi-formal.
As you might recognized I used the word model in case 3 only. The rationale is, a model is only used in case 3. It helps for case 1 and 2, but it is not required.
Regards
Carsten Pitz
Carsten Pitz on
Hi Ruben,
the BPMN specification does NOT restrict the name of a pool in any way. As a result you are free to name the pool "business A / Business B / Business C".
But nevertheless I highly discourage you from mixing different user groups in one pool. Simply because experience shows you will pay the price later. When you further refine your processes or new requirements occur and as a consequence you have to refactor the processes a good traceability within the model pays out.
In your very case you have several receivers of a message. I would model this explicit, because it is easier to grasp and maintain. If the different user groups further on share the same process to process this message I would model the common process separately and reference it as a sub process.
Regards
Carsten Pitz