Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #1 
I notice this is now out, dated November 2010.

I also notice that it seems to be very little different from the original Metastorm ProVision to Metastorm BPM Exchange Process Pod That I reviewed.

My problem then, and my problem still, is that the tool seems to lack a basic understanding of Metastorm BPM. See image 1 that is derived from the ProVision model in image 2.

The main issue I have is that what I would refer to as 'Actions' are translated to stages, and vide versa. Take for example the 'Submit Order' Stage, and the 'Prioritized Order' and 'Approved Order' Actions! I cannot see that the Metastorm BPM process as converted from ProVision has any chance of surviving without major reconstruction, probably even a rewrite.

Now, I know why this is, and I pointed it out in my review many years back. It is because the typical 'model', and that includes ProVision, does not have the concept of a Stage. I've discussed this with the boffins at QUT who almost certainly have the highest level of understanding of BPM concepts concentrated in one establishment, and they concurred. In fact, in their own open source BPM tool YAWL, they introduced a kind of 'looping' wait state to simulate it!

I find it sad that we have been told for years by Metastorm that "round-tripping" is being performed by their customers from ProVision to Metastorm BPM and back, and the same old mistakes are being made in the initial conversion, let alone the lack of any kind of round-tripping at all.

It may be, of course, that I do not understand Metastorm BPM, or what is meant by 'Round-Tripping', or even by 'conversion'. I wait to be enlightened....

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
dwelliott

New Member
Registered:
Posts: 1
Reply with quote  #2 
In my humble opinion, Metastorm have taken a strange view on PV/BPM integration.  I think that the PV workflow is not analagous to the BPM map. I prefer to think of the BPM map stages as being equivalent to "States" in the statechart model, and the actions as "events" that move objects between these states. The business workflow in PV can then reference those events where the workflow and the BPM solution that supports it touch each other. Without this sort of process you would have to have a BPM stage for every single activity in the workflow which is un-necessarily complicated.

David
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #3 
Quote:
Originally Posted by dwelliott
I prefer to think of the BPM map stages as being equivalent to "States" in the statechart model, and the actions as "events" that move objects between these states.

You are correct. It is not just your preference, it is EXACTLY what the Process Map IS.

It was designed originally as a State Transition Diagram, and evolved from there.

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!