Simple modelling problem that has me stumped

[Darkwing]

Hello,

I have what seems to me to be a problem that I should be able to
solve, but my mind is failing me at the moment. Your help would be
appreciated.

See http://dl.dropbox.com/u/49414518/Drawing2.png for the incorrect
model I am trying to correct.

The requirements are: my process (a part of a change management
process) needs to accommodate "standard" and "minor" types of change.
These change types are mutually exclusive. For "standard" changes the
process is to complete task 21, then task 24. For "minor" changes the
process is to complete task 21 and 8 in any order (actually done in
parallel), before starting on task 24.

The problem is: with the way I have represented the process a standard
change will perform task 21 then get stuck waiting for task 8 to
complete.

The question is: how can I model the requirements differently so that
the diagram is syntactically correct?

Thanks ahead of time for any sugestions.


Phil

[Roy]

If your BPMN tool support reusable tasks then the solution becomes
easy, when you split for standard vs minor you flow to a second
instance of task 21 that flows to 24 when complete..

[David Sanders]

Maybe put another standard/minor gateway after task 21.  Or if it's not essential to be parallel, for better readability you could just use a gateway to branch off to task 8.  Or then again if you don't care about having duplicate tasks just have a separate task 21 come off the standard/minor gateway.

--
You received this message because you are subscribed to the Google
Groups "BPMN Forum" group.
Public website: http://www.bpmnforum.com
To post to this group, send email to BPMN...@googlegroups.com
To unsubscribe from this group, send email to
BPMNforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/BPMNforum?hl=en_US?hl=en

[Thomas Hildebrandt]

Hi Phil,

This seems like a legitimate process to use the slightly controversial inclusive gateway (http://en.q-bpm.org/mediawiki/index.php/Gateway)

That is,

1) remove the diamond where you branch according to simple and standard (possibly replace it by an
Activity where the decision between simple and standard is made)
2) replace the parallel split and join gateways with the inclusive gateway and only enable the bottom flow if the decision was that the case is simple.

The inclusive gateway is controversial because the join has a non-local semantics (it is not known locally how many tokens to wait for) see e.g

http://www.itu.dk/~drc/pubs/wsfm2010.pdf

But in this example the flow is so simple that it seems like a good excuse for using it ;-)

Best
Thomas Hildebrandt
Head of the Process and System Models Research group
www.itu.dk/research/models
IT University of Copenhagen
Sendt fra min iPhone

[Graham, Laura L]

An easy solution is to change the parallel merge to an inclusive merge. The inclusive merge waits for all active paths and will not time out waiting for an activity to complete if it hasn't been initiated.

--
You received this message because you are subscribed to the Google
Groups "BPMN Forum" group.
Public website: http://www.bpmnforum.com
To post to this group, send email to BPMN...@googlegroups.com
To unsubscribe from this group, send email to
BPMNforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/BPMNforum?hl=en_US?hl=en

Disclaimer Confidentiality Notice: This e-mail, and any attachments
and/or documents linked to this email, are intended for the
addressee and may contain information that is privileged,
confidential, proprietary, or otherwise protected by law. Any
dissemination, distribution, or copying is prohibited. This
notice serves as a confidentiality marking for the purpose of
any confidentiality or nondisclosure agreement. If you have
received this communication in error, please contact the
original sender.

[Darkwing]

Thanks to everyone who responded so promptly, including Pavle who
responded directly.

In summary the advice has been either to duplicate the tasks that the
standard change sequence needs to include, or use the inclusive-or
gateway. I like the latter approach but I can see why Thomas
Hildebrandt says it is controversial. In fact because of this I have
decided to take the safer and more obvious, though less elegant,
option of the duplicate tasks.

Thanks again to everyone.


Phil

[Graham, Laura L]

The inclusive gateway merge can be used to wait for ALL active paths before allowing a token to be passed along to activate the following activity.  When you have a combination of an exclusive split and a parallel split, the best way to remerge is with an inclusive gateway.   See visual below.  From the spec “A control flow token arriving at an inclusive gateway MAY be synchronized with some other tokens that arrive later at this gateway….” 

 

 

 

 

Thanks,

and please note my NEW CELL number below.

 

 

Laura Graham
Manager, Business Process Management (BPM)

laura....@navistar.com
2701 Navistar Drive,

Bldg 9-213-06
Lisle, IL 60532
Phone:  331-332-3022
Cell:  630-210-5742

 

 

From: bpmn...@googlegroups.com [mailto:bpmn...@googlegroups.com] On Behalf Of Johannes Büschel
Sent: Wednesday, July 04, 2012 8:02 AM
To: BPMN...@googlegroups.com
Cc: bpmn...@googlegroups.com
Subject: Re: [BPMN Forum] Simple modelling problem that has me stumped

 

Hello Laura,

I am a little bit confused about your given solution. In my understanding the following would happen with a minor case:
- the split activates task 8 and 21
- they are both performed
- the token from the task which is ready first comes to the inclusive merge and this activates its output and activates task 24
but
- if the second task is ready the inclusive merge would be activated as well and send a new token on its output

That would result in performing task 24 a second time, wouldn't it?

Thanks in advance.
Johannes

[Roy Thompson (OMR Methods)]

@Graham, your proposed solution requires intuition and if simulated would not produce the desired result.

 

To solve this modelling situation I would remove Task 21 from the exclusive gateway altogether because it is always executed.  The solution below shows the controls visually and requires no intuition or explanation, in fact, a simulation would prove that this executes the correct tasks for the two change type conditions.

 

If you want to be even more explicit then an AND gateway should show that there are two paths that are followed when Determine Change Type is completed.  Personally, Task 21 is not dependent on Determine Change Type and could be started after whatever precedes Determine Change Type.

Roy

 

 

---

From: bpmn...@googlegroups.com [mailto:bpmn...@googlegroups.com] On Behalf Of Graham, Laura L
Sent: Monday, July 09, 2012 4:32 PM
To: bpmn...@googlegroups.com; johannes...@googlemail.com
Subject: RE: [BPMN Forum] Simple modelling problem that has me stumped