Hello,
I was hoping to get your advice on the topic of connecting ARIS business process models (level 4 - Enterprise BPMNC collaboration Diagram) “vertically” from one to another. I’m trying to facilitate users’ request to be able to “easy go from process A you’re currently viewing, to follow up process B. That is where end event of process A is a stat event of process B”. I came across one option of doing it, where pool of process A is connected to pool of process B, like on the print screen attached. This option has one issue – end event changes to type “message” whereas it is not always the desired type. Is that the best way to go with within BPMN 2.0 convention (I know EPC has other ways, but we have to stick to BPMN 2.0) or would you be able to suggest a better option?
Hello Kamil,
indeed, that is the way it's meant to be in BPMN. It's called "Collaboration" diagram because it describes "distinct" processes that collaborate (though the distinction is created in the mind of the designer and those assigning process ownership to stakeholders). I illustrated this in a reply to a post some years ago: https://www.ariscommunity.com/users/pennyb/2016-05-02-use-occurrence-copies-process-interfaces-signal-events
The example I showed used a collaboration between intermediate events, but it applies just the same to start and end events or any other combination of sending and receiving message events. In BPMN there is no sequence flow across a pool border - only message exchange. In EPC the process interface is merely a tool you use to stitch multiple process canvases together. In BPMN the intention is to define a real interface with a defined message exchange.
Actually this can be very user friendly: I assume in your diagram the assignment behind the Pool of process B leads to the Collaboration model of Process B. For consistency the model of process B needs an incoming message flow from process A (which should be represented by a black box pool symbol having an assignment to the model you posted). Also consider not to reuse the start and end events as occurrence copies, because there is no such concept in BPMN. If you avoid this you also avoid the ownership problem for the event, which you inevitably have in EPC. Consider that "Invoice sent" and "Letter received" (or "Invoice received") may represent different stakeholders' views on the same message exchange. There may even be a gap in time between the two events, so there are a few reasons why the sending and receiving events should be treated as distinct events.