Vital to achieving buy-in for your OpenText MBPM (formerly Metastorm BPM) migration is the ability to demonstrate project control and transparency - a good framework will assist in arriving at a compelling business-case.
The drivers for migration are many and varied - from changes in legislation, achievable improvements in efficiency (and therefore profits) or shifts in the business landscape that mean you can take advantage of new features. It may simply be that you recognise that ‘orphaned’ software (solutions and platforms left behind as those surrounding them evolve and are replaced) becomes a ticking bomb as the months and years pass.
Whatever the reasons, you will need to understand the implications, time scales and costs of the migration as far as it is possible to do so. Three major components make up a successful strategy, and whilst the detail beneath these components is important, they are mostly tactical details, rather than strategic objectives.
Estimation
Unsurprisingly, the majority of the information contributing to estimates is the component elements of a process. A creating an itinerary of each process ’ building block is by no means comprehensive, but it is representative of the overall solutions in place, so begin by listing the following for every process:
- Forms
- Flags
- Stages
- Dynamic Roles
- Client Script
- Server Script (JS.net and vbscript)
- Admin Forms
- Actions
Just the process of listing these elements can begin to give you a feel for the size and complexity of the job in hand. Whilst every instance of BPM is unique, each process is likely to take as little as an hour or as much as 6-7 days, and viewing your processes in this manner will help you decide where your hotspots lie.
This review may also have suggested areas in which improvements are required, or in which the new features of Metastorm BPM v9 can be ‘slip streamed’ into your processes and solutions. Use three filters to compare your existing BPM landscape to your BPM needs; are you going to Migrate, Re-Engineer or Add new functionality/processes? Be mindful of unnecessarily extending the migration project, but some benefits are easily obtained by marginal additional expenditure of effort over the usual migration and testing phases.
Planning
Plan for a stringent test programme, both for the newly-migrated processes and repository, and for User Acceptance testing of new or amended functions.
Training and Documentation may be important, especially if significant re-working of the UI is to be undertaken, or functions such as collaboration are to be incorporated.
Execution
Added to the mix next is the creation of the various environments (Test, Dev, Failover and Live etc). This may be relatively swift if your infrastructure has ready-to-populate virtual machine images, and this element probably has the advantage of being carried-out in parallel with any other migration work, as platform teams are often separate and distinct from your development team.
