RJ

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!

by Carsten Pitz
Posted on Tue, 08/16/2016 - 13:33

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

0
by M. Zschuckelt
Posted on Tue, 08/16/2016 - 14:06

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

0
by Ruben Jonkers Author
Posted on Tue, 08/16/2016 - 14:11

In reply to by M. Zschuckelt

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

0
by Ruben Jonkers Author
Posted on Tue, 08/16/2016 - 14:09

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

0
by Carsten Pitz
Posted on Tue, 08/16/2016 - 20:26

In reply to by Ruben_Jonkers

Hi Ruben,

the answer depends on your objective.

What is your objective?

  1. is it to create diagrams to illustrate an idea (refers to: UML as a sketch)?
  2. is it to create diagram as a blueprint for a realization ( refers to: UML as a blueprint)?
  3. or is it to create a model to realize the work flow (refers to: UML as a programming language)?

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

0
by M. Zschuckelt
Posted on Tue, 08/16/2016 - 18:02

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

0

Featured achievement

Rookie
Say hello to the ARIS Community! Personalize your community experience by following forums or tags, liking a post or uploading a profile picture.
Recent Unlocks

Leaderboard

|
icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon icon-lock