What are the mostly used connection types in BPMN and VACD diagrams? Since the list of available connection types is pretty long, I appreciate someone would like to give guidance on this. Thank you
Best Reply
Hello Olaf,
in VACD diagrams there are two connection types between functions (called a little bit misleading "value added chain" or "process" for the single function) you can choose: "is process-oriented superior" to model hierarchies and "is predecessor of" to model a sequence of functions. For all other connection types between functions and additional elements like organizational elements, IT systems, products and so on there are no defined rules and you are free to use what is appropriate for your project. A lot are self explaining. I personally doesn't care too much about these types, as I do no enhanced reporting based on these types within a VACD. If you want to do this you have define the rules for your company.
For BPMN, what I recommend to use as far as possible as it is standardized in opposite to a VACD, you have the sequence flows for modelling the sequence of flow elements where the properties ("activates", "creates", "leads to" and so on) are set automatically by the ARIS methode. What ARIS is doing here is not defined by the BPMN specification and you cannot change it. The BPMN specifiation knows controlled (i.g. by a gateway) and uncontrolled flows, default sequence flows and conditional sequence flows. The last two have a special semantic (I think you know) you can use for modelling. More is not provided and is not needed from my point of view.
Regards
Klemens
5 Replies
-
Hello Olaf,
in VACD diagrams there are two connection types between functions (called a little bit misleading "value added chain" or "process" for the single function) you can choose: "is process-oriented superior" to model hierarchies and "is predecessor of" to model a sequence of functions. For all other connection types between functions and additional elements like organizational elements, IT systems, products and so on there are no defined rules and you are free to use what is appropriate for your project. A lot are self explaining. I personally doesn't care too much about these types, as I do no enhanced reporting based on these types within a VACD. If you want to do this you have define the rules for your company.
For BPMN, what I recommend to use as far as possible as it is standardized in opposite to a VACD, you have the sequence flows for modelling the sequence of flow elements where the properties ("activates", "creates", "leads to" and so on) are set automatically by the ARIS methode. What ARIS is doing here is not defined by the BPMN specification and you cannot change it. The BPMN specifiation knows controlled (i.g. by a gateway) and uncontrolled flows, default sequence flows and conditional sequence flows. The last two have a special semantic (I think you know) you can use for modelling. More is not provided and is not needed from my point of view.
Regards
Klemens
-
Hi Klemens,
Hi Olaf,If I am not mistaken, the connection names were changed with the (latest) release?
What was previously:
is process-oriented superior ==> is now ==> aggregates
is predecessor of ==> is now ==> triggers
Despite this, I fully agree with what Klemens said.
Best,
Veronika
-
Hi Klemens, hi Veronika,
Thank you for your replies. Setting up rules for our company - this is what I want to achieve. It sounds comfortable that ARIS picks something automatically. Is this always "automatically right"? (That's more of a rhetorical question.)
I don't know whether it's a curse or a blessing. At the end it matters to me that the modellers are aware of what ARIS picks and why and that they take conscious decisions.
-
Hi Olaf,
the list is only as long as you allow it in the method filter you give to your users. It is a strong recommendation to define your method conventions in a method filter. Otherwise - indeed I assure you in no time your modellers will have made a mess with the usage of arbitrary connection types. Just give them the 1, 3, or 5 connection types they may need in every situation you want to cover with the modelling. Only expand the method if you want to expand your use-case. And then accompany that expansion with proper training to the users what they should use it for.
When you will have trained your users in what to use in cases where you allow more than one connection type, you can sleep peacefully.
-
Hi Olaf,
To make concious decisions, it requires a high maturity for modellers- I would, as suggested by M. Zschuckelt use a filter so that the user doesn't have a choice other than what is allowed ;)
Best,
Veronika