Building BPM: simulate or integrate?

I have been tracking Ismael Ghalimi's IT|Redux blog more closely, as the BPM2.0 dicussions are quite insightful. Anyway, he has a post that talks about the need for process simulation within BPM tools and projects. Although I agree in principle, I had this haunting feeling - I was involved in a couple of painful projects where this would not have worked.

Here is the comment I fired at Ismael.

Ismael, as ever there are many words of wisdom in your post. Here are my thoughts based on some front-line experience in different organizations.

Over the last 10 years I have worked with a variety of mainstream workflow/BPM tools - plus some product specific ones that were still reasonably strong. Having simulation out of the box would have made a few of the projects easier but for others it is unlikely it would have made us aware of some of the rat-holes we were going down early on.

Several years on from a painful project I have realized that simulation is NOT needed for many processes (i.e. less than 30 human interaction steps). Since the issue we had in many cases was not the logic or sequence of the process, but in fact the backend system integrations (and the UI).

In reality we should have worked backwards, proving the integrations first against a dummy process, ensuring that we could get at and alter the data in the backend ‘legacy’ systems and understanding the impact this would have. This would have avoided the need for many of the simulation requirements, since when it came to the real process we could run a test instance of the real workflow engine. More importantly it would have demonstrated up front that the legacy system internally controlled large portions of the process, which if we were not careful we would only duplicate (possibly incorrectly) within the BPMS.

So I would propose the methodology for BPM where legacy systems are involved:

1. prototype the integration first
2. test with an abstract process
3. ensure that the legacy systems can handle the proposed integration
4. identify constraints based on internal processes enforced by the legacy system
5. refine the process given these limitations
6. finally start testing the process with some real world and simulated data

I know that this seems like a brutal approach for some projects, so I’m interested in your thoughts based on your experience!

Hopefully you will be able to see a good discussion on Ismael's original post

Also, check out a (newly) related discussion around a challenge Ismael threw out to the BPM world.

Technorati tags: Financial Services Technology New Account Opening BPM integration process simulation