Hi Tony,

I agree that it's necessary to diagram non-sequentlal processes, particularly at the bigger picture perspective, as you nicely put it.  It's important to note, however, that the common 'swim-lane' diagram used for sequential process modeling is not the only type of process model available.  As I noted, BPMN is just the notation standard - it doesn't dictate the diagram format.  Here is a link to a site that shows several different flavours of process models at different levels of abstraction - all using BPMN notation:

http://bpmnpop.sourceforge.net/presypackages/packages.html

Sorry that this site is not quite fully constructed...  If you look at the 'Local process environment' example, it shows how a single process can be defined at a high level with key information such as performance measures, inputs, outputs, trigger events, etc.   The 'Process overview' shows how processes relate to each other.  The 'Roles/Relationships/Communication channels' gives yet another view - this one from a stakeholder role perspective.  These are just some examples to show that process modeling is definitely not limited to sequential process flows or swim-lane diagram types.  Note that this site also includes the typical swim-lane as just one of many process diagram types.

And I'm a big fan of DFD's too - but it's just one of many very good tools & techniques that each offer their own value.  Thanks for the input & exchange of ideas - always fun!

Sandy

Hi Sandy:

We believe alot more in common than I initially thought.  The single process displayed under the "Local Process Environment" for example, has "needed info" and "results".  DFD's call such inputs and outputs (note: DFD inputs and outputs are not limited to data.  They can be, for example, tooling or an end product.).  Your diagram's "conforms to" and "metrics" can be conceptually viewed as data inputs required to accomplish a process, and, therefore, could be DFD inputs.

Regarding the "Process Overview"  diagram, I do see an issue if the need is to decompose each of the process boxes down lets say six levels.    Without the logical, natural partitioning  per level uniquely offered by a DFD "interview the data flows" approach, deep decomposition can be very difficult.

Regarding my comments about the BABOK:  It does not talk at all about the non-sequential nature of systems at higher levels of abstraction.    The overall unawarness of such within the BA community makes it difficult for the majority to see the value of your higher level diagrams and DFD's.  Many believe that all process modeling - all levels of abstraction - can be done using a sequence based technique.

Tony

Rebecca,

I surmise that you may want to model your end-to-end processes. Many businesses have end-to-end processes, sometimes also referred to as core processes, like procurement-to-pay, quote-to-cash, invoice-to-banking or in the case of insurance claim-to-pay.

For a few examples, have a look at Bizagi at http://www.bizagi.com/index.php?option=com_content&view=article&id=171&Itemid=186

I think they have one for Underwriting and one for processing a claim, which are pertinent to your industry.

Warm regards,

K

PS. Give KIMBO a tinkle, KIMBO knows!