Hello Everyone,
I am not getting solution, how to show synchronized activities between two lanes via BPMN 2.0 collaboration model.
Basically we have two different interconnected system like SAP and other IT system, and I wanted to model our process under which these two system belongs. So basically I have two lanes under one pool.
If I change something in SAP it automatically reflects or updates in other IT system. I can manage for one activity but there are lot more activities which updated simultaneously in two systems. Using data store option seem to be one solution. But do you have any alternative solution which make process model simple?
And finally, do we have any kind BPMN framework like camunda BPMN framework, where I can show top level process model, then operational process model and then to different backend IT processes for same process but in hierarchical way.
Thanks!
M. Zschuckelt on
Hello,
to answer your last question first. The only hierarchy BPMN allows is as follows: Use "Sub-process" in Collaboration diagram and detail the sub-process in the expanded process. In ARIS the details are modelled in a Process diagram, which does not allow Lanes (because the expanded sub-process symbol does not allow Lanes in BPMN specification).
So the way to go for your case - answering your first question - is: The task "do my update" is a single step in your process (why should it be two, since one does not occur without the other?). Model "do my update" as a sub-process. The detailed process contains two steps "Do my update in SAP" and "Do my update in the other system". These steps can occur sequentially (connected with a sequence flow) or simultaneously (not connected), whichever you prefer.
Note: In the collaboration diagram you only have one lane left. Consider using that for the role performing the update instead of the systems.
For higher level processes consider to use Value-added chain diagrams.
Another consideration: BPMN was meant for process modelling. So ideally "Do my update" should simply be an atomic service task and whatever orchestration is necessary to "do my update" should be part of the service specification, i. e. update in SAP, update in System B, update in System C. This way you don't need to change the process, when you retire System C. And this saves you all the effort of sub-processing where there is no real "process".