Metastorm ProVision to Metastorm BPM Exchange Process Pod Review
Metastorm provide a conversion utility that creates Metastorm BPM files from Metastorm ProVision Workflow models. This is a potentially very valuable tool, if it could turn your ProVision Workflows into workable Metastorm BPM executable processes. In order to avoid naming confusion we shall refer to the Metastorm BPM product as e-work (its previous name).
In our experience, it is extremely rare that a process model will convert directly to an executable process. It will always need some redesign and optimisation before being fully effective. Add the need to create a coherent data model to support the processes, and integration with other systems, and you have a significant amount of work and potential for error. This is especially true for those new to e-work.
Having tried the approach adopted by the Exchange 'Process Pod', we have noticed that there are significant problems that would need to be overcome:
The concept of 'Stages' do not exist in ProVision. This is perfectly understandable, as the concept does not really exist in BPMN, which ProVision attempts to conform to (but only to a certain extent, see our ProVision review). This means that Stages in e-work have to be generated from Activity names on ProVision. This can inevitably lead to some confusion, as Stages should really describe the state of the 'Folder' (an adjective), and Actions the activity performed (a verb). Compounding this, the Exchange tool actually puts the action after the stage of the same name. In our experience it makes more sense to lead to it. A typical example would be the 'Accept' action moves the Folder to a stage named 'Accepted'. The Exchange will in fact create a Stage called 'Accept' and an action leading from it called 'Accept'. Although this can be rectified, it will inevitably cause confusion to newcomers to e-work.
Sub-Workflows in ProVision are generated as map segments in e-work. Map Segments are not easily modified to fit the containing Map, and elements cannot easily be copied to other maps. The resulting process will therefore be difficult to modify, thus invalidating one of the greatest strengths of e-work, agility.
You are forced to adopt a global conversion for decision points to user actions or system actions. This does not fit many processes, as most are a combination of both. The results would be much more intuitive if you were able to specify this for each decision point. I suspect it could be difficult to use, but the option might be useful.
The concept of timers, even as far as BPMN is concerned, does not seem to be employed in ProVision workflow models. You are able to set all sorts of timing metrics for simulation, which is very powerful, but not timed events. If it did, these could in theory be adapted to timed actions in e-work, which could be very useful. Flagged actions as triggers do not exist either, as far as we can see. It seems that Triggers in ProVision Workflow models can only be used to instantiate a Workflow, not to affect it later.
To try the concept out for ourselves, we attempted to create a simple process in ProVision and then convert it to e-work. To start we created what we determined to be a very simple generic process in e-work. We then attempted to create a Workflow model in ProVision that as nearly as possible matched the concept we created in e-work. We then converted that to e-work using the Exchange tool approach. These are the models we ended up with:
Desired Process in e-work
Model in ProVision
ProVision Workflow converted into e-work
It is reasonably clear that the conversion result, although potentially workable, is nowhere near optimised. The effort to convert this to the ideal is possibly more than the effort for an experienced e-work practitioner to create the process from scratch. If the practitioner is not experienced, there will almost certainly be problems anyway, in our experience.
This test is just about the simplest process we could imagine. We feel that if you tried this with a process of any complexity, say 10 to 20 stages, you will have much more of a problem to resolve. This is not to say it cannot be done, or that it will not save time, but it will definitely require some skill as an e-work developer. In any case, the exchange tool is not going to convert all your ProVision workflows to e-work processes at the touch of a button.
We see a great potential for the tool to allow you to prototype a process (as we do in our methodology). You can take a complete ProVision Process model and convert it to e-work processes and 'try them out' in an executable environment. This can, in our experience, give you detailed insight from a user perspective that no amount of modelling can ever achieve. That in itself makes the tool very valuable.
As an instant conversion tool, we do not think it will be of major benefit. Experienced e-work developers will still have a great deal of work to do, and inexperienced developers will get confused at best, and badly misled as to how best to use e-work at worst. As a method to allow you to prototype the process using an executable process, we think it could be invaluable. You would probably be better off doing the conversion to an automated solution manually to create an optimised solution.
For anyone considering this migration path, we would strongly urge you to try the conversion process with a representative process and examine the results in the execution environment carefully.