The Modelling-to-BPM cycle

I attended a webinar last week about Proforma and Workpoint, and I have to say that the “for more information” slide at the end of the presentation is the best one that I’ve ever seen in all my years of corporate presentations. Dan, that may not be your picture on the slide, but kudos. Update: screenshot of the slide removed at the behest of Workpoint, who claim that the slide that I saw on the screen didn’t exist in their slide deck.

The topic of the webinar was Bringing BPM and BPA Together (replay available on Feb 7th), and it focussed on how you can do your complex modelling, analysis and simulation in Proforma’s ProVision, then export/import your way over to Workpoint’s BPMS for execution.

I found this particularly interesting because it highlights the divide between the BPMS vendors who (attempt to) provide everything to do with process under their own banner, and those that rely on partner relationships through a best-of-breed approach.

At the Proforma user conference last year, one of the speakers asked the audience how many of them were exporting their process models to a BPMS for execution. Out of about 150 people, only a couple of hands went up, which surprised me (as I discussed in my post about that presentation, Is Anyone Executing Those Processes?). ProVision doesn’t yet support XPDL, and many of the BPM vendors are just getting onboard with XPDL themselves so haven’t been ready to accept process models from a modelling tool, but there has been integration done between ProVision and some number of BPMS using their Proforma’s XML-based interchange format, CIF. Presuming that many of the companies using ProVision are also using a BPMS, this seems to imply that someone is taking the process models created in ProVision and recreating them manually in the BPMS. So why is this happening? Is it a technology disconnect (BPA and BPM can’t exchange models) or a human disconnect (modellers/architects and BPM jockeys don’t exchange models)?

Proforma and Workpoint are obviously trying to buck this trend by promoting how much better things can be when you use the strengths of both of their products. I’m a fan of this approach if you’re using a full enterprise architecture modeller like ProVision as opposed to a process-only modeller, since you can do all of your EA models in it and your process models become part of the larger picture. I’m headed off to the ARIS ProcessWorld conference later this week, so I may discover more of the advantages of a process-only modeller, too.

It makes sense for smaller BPMS vendors like Workpoint (whose product I am completely unfamiliar with, except for last week’s webinar) to leverage relationships with modelling vendors like Proforma to fill in the gaps in their product, although larger vendors who are side-slipping into the BPM space are also going that gap-filling route, such as we see with the OracleIDS Scheer relationship.

At the other end of the spectrum are the mainstream BPMS vendors, particularly those categorized as “suites” or “pure-play” (depending on which version of which analyst report that you read), which include modelling, simulation and all manner of process analysis as part of their product. Although you can’t escape having a process modeller (and likely simulation) in your BPMS in order to be considered a serious player, I’m still left with the feeling that there’s a lot to be gained by using a tool that is both more specialized in process modelling — in order to be able to capture non-automated steps, for example — and provides a broader enterprise architecture modelling scope.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.