Last 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: