Benoit J. LheureuxLast week I sat with ½ dozen attendees of our Gartner Business Process Management Summit here in San Diego at one of our so-called “Analyst / User Roundtable” discussions. With just a little facilitation this lively group of folks from diverse industry backgrounds came up with a simple set of guidelines for determining “When to Use a BPMS” (Business Process Management Suite) to implement business processes (versus simply implementing processes via composite applications, SOA choreography or traditional integration middleware.)
The result: consider using a BPMS for processes with the following characteristics:
· The process is distributed, i.e., spanning multiple applications
· The process involves complex rules
· If the process is complex overall
· If you have a need to monitor the process
· The process requires improvement
· If many instances of the process will be deployed
· If you have sufficient availability of legacy interfaces to support the process
We concluded that the way to use this list is to apply these criteria to your own list of internal company processes, using the criteria to eliminate processes that don’t fit the criteria, and thus are unlikely to produce a sufficient ROI when deployed via a BPMS versus other approaches. We also concluded that ETL (extract transform load) and other point-to-point style of integration projects were not very good candidates for BPMS technology.
Some form of these guidelines have no doubt been produced many times before, and likely often have been more rigorously vetted (see Gartner’s own Two Factors That Help Identify the BPMS ‘Sweet Spot’ – login required). But having advised clients pretty often on “When to Use (or Not Use) a BPMS” in the past, I thought this was a pretty reasonable set of guidelines. If we missed anything obvious, please post your thoughts.
Category: BPM Tags:
3 responses so far ↓
1 Djebar Hammouche August 18, 2009 at 2:41 am
Some comments (mainly from business perspective)
· The process is distributed, i.e., spanning multiple applications
>> spanning multiple organisations locations or actors
· The process involves complex rules
refactore it, simplify it before implement ?
· If the process is complex overall
· If you have a need to monitor the process
in particular for marketing/audit reasons
· The process requires improvement
find gap between IT and business and plan benefits chaznges
· If many instances of the process will be deployed
in particular, in case of localization (i.e. for local compliances).
· If you have sufficient availability of legacy interfaces to support the process.
sometimes this was the first step to build services (reuse from legacy system)
But you forget one or more arguments :
–Outsource (off site ) one or more steps/tasks outside core business will be outsourced
–new fusion process : coordinate between two org entities to provide a customer outcome
– virtual enterprise process : compose new services/bp from existing services/bp
best regards
2 Benoit Lheureux August 18, 2009 at 11:52 am
Very helpful post, Djebar
In particular I agree w/your observation that processes which span organizations (not just applications), whether new fusion or simply complex, long-running cross-enterprise processes definitely qualify.
3 Doing B2B? E-Commerce? Cloud computing? Don’t forget – its about PROCESS October 7, 2009 at 12:50 pm
[...] Janelle Hill and I had a great conversation with some nice folks of an international B2B / Ecommerce services provider that attended my session and wanted to explore options for their increasing need of BPMS technology (including process modeling and a rules engine) specifically so they could deploy configurable ecommerce projects with scale for their customers. We agreed that for complex, high-value and fast-changing processes that can be leveraged across multiple B2B communities, BPMS technology would be a great addition. But that for more static, less-complex processes that traditional application development is still fine. Its important to apply BPMS technology judiciously — I’ve blogged before on the issue of when — and when not — to use BPMS technology. [...]