CW

if BPMN Collaboration pools are named after participants and each pool represents an ‘implicit’ process. What is the best practise for naming the collaboration model itself … if each pool contains its own process? … and where is the implicit pool process name captured? (Where process flows shown in each pool – white pool … not one process flow pool + black box pools).

There is another post ( https://www.ariscommunity.com/users/ie101/2018-09-19-start-events-aris) suggesting use of only one white box pool per diagram - in which case I understand the model name would represent the process of that white box pool ... however it appears the BPMN spec/notation does allow for multiple white box pools in a collaboration diagram - and it's naming models where that occurs that I'm asking about.

Thanks in advance 

by M. Zschuckelt
Posted on Tue, 10/23/2018 - 23:42

Hello,

an "ARIS model" is not a BPMN construction, but a canvas to organize BPMN and other modelling artefacts. So what you put in an "ARIS model" together is up to you.

It may be valuable for certain purposes to show multiple white-box Pools on the same canvas to explain the collaboration between processes in detail.

I am not sure, what you want to express with 'implicit process'. Here is my view: When you design your process landscape you make decisions how you define intermediate results of your overall business process which are useful to describe the value creation process. You segment your processes such that each creates exactly one of these results. Such segments have a delimitation, which is symbolized by the Pool border. The Pool is the graphical representation of the Participant object. BPMN describes the world as a system of interacting processes, which are in that sense the "participants" in the model.

So even external parties your organization interacts with are participants, because they have processes that communicate with your processes through the exchange of messages. The only difference between their processes and your processes is that you are not interested in how they do their business and how they design their processes. That is why you always leave the Pool representing their process empty as a black box pool, and only message flows to and from the border of their Pool ever occur as a detail about these Participants' behaviour. You simplify the other's Process as a single Participant, e.g. "Supplier".

Now everything inside your own organization is potentially relevant to be modelled by you in white-box Pools. You define your scope of your modelling effort yourself and apply segmentation principles as outlined above. So when you do the segmentation you also take into consideration the aspect of governance: Who will sign off a process model - who takes ownership? Will that person be able to understand the process as a whole and believe it is correct and take responsibility?

So one thing becomes obvious: It is useful not to put multiple white-box Pools in one ARIS model where you have different ownerships. An ARIS model is a useful container to take responsibility for (through sign-off or however you want to document it in attributes).

It could be that you have a different process owner for each segment/process. In that case - following the last consideration - you would only have one white-box Pool in each ARIS model. And from there it is a perfectly valid demand to name the ARIS model the same as the Pool/Participant that is described in detail as a white-box Pool in that model.

Even before BPMN occurred it has been a convention and best practice to name any ARIS model that explains an object in detail or focuses on the context of an object the same as that object in focus. Additionally the model is "assigned" to that object with the ARIS assignment mechanism, which allows you to navigate from any occurrence of that object to the detail model. That is why I recommend to assign each BPMN collaboration model to the single white box Pool inside it and name it the same as that white box pool.

What about the overall process? Each white-box Pool interacts with external and internal Participants through message flows. Since I demanded to have only one white-box Pool on a single canvas you should depict the other Participants as black-box Pools even the internal ones. But make sure to use an occurrence copy of the Participant that you created for the model where it is explained as white-box. This way you get the assignment icon on your black-box Pool occurrence and can navigate to the corresponding model with the white-box Pool. You have to take care that the message flows between the two Pools occur in both ARIS models or your overall model will be inconsistent. You can write semantic checks to assist you in that.

To sum it up: It is perfectly okay to model multiple white-box Pools in a single model. It is correct BPMN syntax. It is another question how you sensibly organize an enterprise process repository in ARIS. I explained my best practice recommendation. It avoids canvases spanning entire office wallpapers nobody wants to explain, read, maintain or take responsibility for, even if you segment it with the means of Pools and message flows between them. Also the mesh of message flows is a lot easier to validate, if it does not entangle itself with lots of other message flows on the canvas on the way to the proper place in the partner white-box Pool. Even if a single process owner takes responsibility for multiple models it is useful to follow through with this convention for the sake of simplicity and to be able to use the assignments from Participant to white-box model for navigation.

When you have special needs to show two (or more) white-box Pool interactions in a single model, create it as occurrence copy from your "master" models, consolidate the message flows between them and throw the model away when it has fulfilled that need. You don't want to maintain the same information twice.

Regards, M. Zschuckelt

0
by Charlie Winterburn Author
Posted on Mon, 11/05/2018 - 16:34

In reply to by M. Zschuckelt

Thanks for your response - makes a lot of sense and I was coming to the conclusion that for each BPMN collaboration model with one single white box Pool inside it and name it the same as that white box pool. Where 2 or more white-box pool interactions in a single model - your suggestion seems very sensible also... and that those would be context/ throw away - not part of the main process library. Thanks Again.

0
by Charlie Winterburn Author
Posted on Mon, 11/05/2018 - 16:35

In reply to by M. Zschuckelt

Thanks for your response - makes a lot of sense and I was coming to the conclusion that for each BPMN collaboration model with one single white box Pool inside it and name it the same as that white box pool. Where 2 or more white-box pool interactions in a single model - your suggestion seems very sensible also... and that those would be context/ throw away - not part of the main process library. Thanks Again.

0

Featured achievement

Genius
You like to help others solve their problems by answering questions.
Recent Unlocks
  • KF
  • KH
  • RG
  • Profile picture for user Vee_ARIS
  • Profile picture for user smarty
  • PacMan

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