Not a good law, not a good look for NZ

Simulation

Bruce Silver points out that business process tools do not do simulation well or usefully and lists some features that should be present in the BPM toolset to facilitate simulation.
This would be great but a simpler approach is to use the much more mature pure simulation tools (like Simul8 ). In that scenario, you can design your process using your favourite BPM modelling tool; transfer the model to the simulation tool adding the simulation properties and data; devise the optimal process under simulation and transfer the new model back to your process design tool.
The overall approach is summarised by this diagram from Simul8 but any product that exposes its data structure could be used in the same way.
Having a standard BPMN schema would help the simulation product people assist.

Project management vs. process manage...

Ayalew Kassahun raised an interesting question on the LinkedIn BP Group

For many it may be weird to imagine a world in which no distinction is
made between projects and processes. However, I think that every
process instance is a mini project. ... Just for sake of discussion I would suggest that it is more appropriate
to make no distinction between project and process management. In such
a world what will then be the consequences on management,
specifications and tools?

Firstly, I think that distinctions between process and project are hard to make outside the toolsets that attempt to specialise.

My interest is in business process management toolsets and I have been following much of the discussion about BPMN, BPEL and how the process model should end up being 'executed'. I am convinced that there is a need for a specification of the process that endures from the business idea through to technical execution of an instance of the process.

If we merge the concepts of process and project, I can see some real benefits in the process design world. For example, some analysis and modelling of the process can be done at the instance level rather than engineering a highly complex general model which attempts to deal with every possible eventuality. This alone has the benefits of redeucing impact of process design bottleneck and allows for a common way of dealing with business activities leading to common reporting, management. We would no longer have to treat activities differently if they were being handled through a PMO or through BAU.

However, in the BPM world, the toolsets are not very mature and some radical rethinking would have to take place.

Because the instance of a process/project could change during its life, then tools that do not have a tight relationship between model definition and execution will really struggle to deliver. The executing process will need to be changed through the business expression and not through some programmer intervention. So I would expect the run time BPM system to be executing a development of BPMN rather than a transformation in BPEL,JAVA or whatever.

Project management vs. process manage...

Project management vs. process management

Ayalew Kassahun raised an interesting question on the LinkedIn BP Group

For many it may be weird to imagine a world in which no distinction is
made between projects and processes. However, I think that every
process instance is a mini project. ... Just for sake of discussion I would suggest that it is more appropriate
to make no distinction between project and process management. In such
a world what will then be the consequences on management,
specifications and tools?

Firstly, I think that distinctions between process and project are hard to make outside the toolsets that attempt to specialise.

My interest is in business process management toolsets and I have been following much of the discussion about BPMN, BPEL and how the process model should end up being 'executed'. I am convinced that there is a need for a specification of the process that endures from the business idea through to technical execution of an instance of the process.

If we merge the concepts of process and project, I can see some real benefits in the process design world. For example, some analysis and modelling of the process can be done at the instance level rather than engineering a highly complex general model which attempts to deal with every possible eventuality. This alone has the benefits of redeucing impact of process design bottleneck and allows for a common way of dealing with business activities leading to common reporting, management. We would no longer have to treat activities differently if they were being handled through a PMO or through BAU.

However, in the BPM world, the toolsets are not very mature and some radical rethinking would have to take place.

Because the instance of a process/project could change during its life, then tools that do not have a tight relationship between model definition and execution will really struggle to deliver. The executing process will need to be changed through the business expression and not through some programmer intervention. So I would expect the run time BPM system to be executing a development of BPMN rather than a transformation in BPEL,JAVA or whatever.

BPMN - Hard to Code???

Bruce Silver continues the valuable discussion on BPMN semantics and challenges a perception that BPMN has vague semantics.
In the example chosen, I agree with Bruce that

• having flows from downstream activities BPMN is not best practice (in that it can lead to misunderstanding by the casual reader who may more be familiar with basic flowcharts)
• there is only one reasonable interpretation of the required execution of the BPMN and therefore it is not an example of "vagueness".

Looking at the definition of the Inclusive Gateway in BPMN 1.2 , I might accept a criticism that it is hard to read in English and may benefit from formalising.

9.5.3.2 Sequence Flow Connections
This section extends the basic Gateway Sequence Flow connection rules as defined in “Common Gateway Sequence Flow Connections” on page 72. See Section 8.4.1, “Sequence Flow Rules,” on page 30 for the entire set of objects and how they may be source or targets of Sequence Flow.

• To define the inclusive nature of this Gateway’s behavior for converging Sequence Flow:

If there are multiple incoming Sequence Flow, one or more of them will be used to continue the flow of the Process. That is,

• Process flow SHALL continue when the signals (Tokens) arrive from all of the incoming Sequence Flow that are expecting a signal based on the upstream structure of the Process (e.g., an upstream Inclusive Decision).

• Some of the incoming Sequence Flow will not have signals and the pattern of which Sequence Flow will have signals may change for different instantiations of the Process.

Note – Incoming Sequence Flow that have a source that is a downstream activity (that is, is part of a loop) will be treated differently than those that have an upstream source. They will be considered as part of a different set of Sequence Flow from those Sequence Flow that have a source that is an upstream activity (my emphasis).

However it is clear from the phrase "... expecting a signal based on the upstream..." and the note in the section above that the inclusive gateway in the example has no (merge) function in the event that a sequence flow from the downstream exclusive gateway is processed. The token from the loop back is the only one that can be 'expected' at the inclusive gateway.

It will only be hard to code, if the developers have started from a point of view that each node (activity or gateway) can be transformed into an executable form (or executed directly) in isolation. The developer must consider the source of the signals (Tokens) and the structure of the process as a whole.