Vinny, I think Kmajoos has answered this one - and thank you Kmajoos!
One thing I would add is from a BA perspective that the 'and' construct is not defining that processes must run at the same time (that is a design decision) - what they are defining is that there is no requirement for them not to run at the same time: the only dependencies they have are
- for precondition (in effect) the same trigger (the 'and' gateway)
- for post condition that a process cannot start until 2 or more preceeding processes have completed whether or not they run at the same time (when they don't run at the same time this is a usual suspect for process bottlenecks).
This is still all about defining process dependency requirements (which is all that process diagrams do) and not how it will be designed - my plan as a BA is just to say to the designers "I know exactly what the users require and here are the processes dependencies defined in a BPMN diagram. What is the design that best meets these dependecy requirements?". The designers now just have to worry about the best way to meet the requirements and not what the requirements were in the first place, which is how it should be...
Guy
Greeting Guy and Vinnie,
1: My take on the AND-Split (gateway) is, every path eminating from the gateway runs in parallel.
Consider this. Lets say the start event creates a token (call it T). At the AND-Split (gateway) T is split into sub-tokens T1, T2, T3 etc. You need one subtoken for each path you have eminating from the AND-split. These subtokens can progress at different "speeds", some may start and complete later than others. The AND-Join waits for all the sub-tokens to arrive so that it can JOIN them together to recreate the original token T.
A good resource for this kind of thing is the Van der AAlst website.
See http://is.tm.tue.nl/research/patterns/patterns.htm
To see the AND-split (parralel-gateway) in action watch http://is.tm.tue.nl/research/patterns/download/swf/pat_2.swf
for the AND-JOIN watch http://is.tm.tue.nl/research/patterns/download/swf/pat_3.swf
I trust the above helps a bit
warm regards
K
Thanks for the articulate explanation, K. That, coupled with the following from your link, confirms that the way I thought it worked was correct. That site is a nice resource, by the way!
"Description A point in the workflow process where a single thread of control splits into multiple threads of control which can be executed in parallel, thus allowing activities to be executed simultaneously or in any order."
Regards,
vinny
"...that is a design decision..." That is well-put, Guy. Why would a stakeholder require, 'These processes must execute at the same time'? All that the stakeholder cares about is that the tasks complete before continuing with the rest of the process, and that the tasks were triggered as they defined.
Thanks again, Guy!
Vinny,
As a BA its worth your while to go through each of the 21 Van der Aalst patterns. Some of these patterns, but not all, are replicated in the White Article at the BPMN.org site.
Looking back at your original post - you were right!
I've replicated your later diagram with a slight variation. 1) there is only one "update worksheet" activity and 2) the "Request information" activity amongst other things also asks the programmer to create a spreadsheet.
The reason I think you duplicated the "update worksheet" in your diagram was the notion that you MUST complete one activity at a time. Not so, you can do a little updating of the worksheet, get some fee data, then do some more updating etc.
I've used the Free Bizagi Modeller to create the diagram.
warm regards,
That's a fantastic suggestion --if that was one spreadsheet to which I was referring. I mocked that model up quick --so quick that I neglected to explicitly state that those were two separate worksheets. Had that been one worksheet, you're suggestion would've been perfect.
Thanks a lot for taking the time to critique and improve my diagram!!!!
brought to you by enabling practitioners & organizations to achieve their goals using: