Selecting a BPMS

Janelle Hill of Gartner gave a short presentation on selecting a BPMS. Some of her points:

• The coolest BPMS may not be appropriate. Take advantage of the model-driven development environment that is appropriate for your business people rather than just what’s the most fun for the developers. A typical feature-function evaluation may not be the best way to go about it, since the functionality can vary widely while providing the same business capability.
• A BPMS is a suite of technologies for supporting the entire lifecycle of process improvement: discovery, modeling, execution, monitoring and optimization. It’s a platform that includes both design-time and runtime. She showed the classic Gartner “gears” diagram showing all the components in a BPMS, and pointed out that you probably don’t need to do a deep dive into some of the components such as business rules, since that’s typically not the deciding factor when selecting a BPMS. A BPMS is a composition environment rather than a full development environment, where the components are used together to graphically assemble pre-existing building blocks from outside the BPMS together with some functionality built within the BPMS to create a process application. As a composition environment, the registry and repository are important for being able to locate and reuse assets, whether created inside or external to the BPMS.
• A BPMS is not the same as a SOA suite: the latter is used to create services, while the former consumes those services at a higher level and also provides user interaction. As I’ve said (usually in front of my service-oriented friends), a BPMS provides the reason that the SOA layer exists.
• A BPMS provides visibility, adaptability and accountability particularly well, so you should be considering how a BPMS can help you with these business capabilities.
• If business (or a combination of business and IT) need to be able to manage process change, or processes change frequently, then a BPMS is a good fit. If process changes are purely under the control of IT and the processes change infrequently, then more traditional development tools (or an ERP system) can be considered. She talked about frequently changing processes as being served by systems that are built to change, whereas those with less frequently changing processes as being built to last, but pointed out that “built to last” often translates to brittle systems that end up requiring a lot of workarounds or expense changes.
• She presented Gartner’s top four BPMS use cases: a specific process-based solution, continuous process improvement, redesign for a process-based SOA, and business transformation. Their latest MQ on BPMS has more information on each of these use cases; if you’re not a Gartner customer, it’s available through the websites of many of the leading BPMS vendors.

She then moved into some specific evaluation criteria:

• Know your dominant process patterns: straight-through, long-running with human involvement, dynamically changing processes flows, or collaboration within processes. She categorized these as composite-heavy, workflow-heavy, dynamic-composite-heavy and dynamic-collaborative-heavy, and showed some of the tools that they provide for helping to compare products against these patterns. She stated that you might end up with three different BPMS to match your specific project needs, something that I don’t completely agree with, depending on the size of your organization.
• Don’t pick a BPMS because it’s a “safe” vendor or enterprise standard, or because of price, or because the developers like it.
• Do pick a BPMS because it enables business-IT collaboration, because its capabilities match the needs of a defined process, it supports the level of change that you require, and it interoperates well with your other assets.
• Do an onsite proof of concept (POC), 2-3 days per vendor where your people work side-by-side with the vendor, rather than relying on a prepared demo or proposal. She had a lot of great points here that line up well with what I recommend to my clients; this is really necessary in order to get a true picture of what’s required to build and change a process application.
• Check for system scalability through reference checks, since you can’t do this during the POC.

She ended with some recommendations that summarize all of this: understand your requirements for change to determine if you need a BPMS; understand your resource interaction patterns to define the features most needed in a BPMS; ensure that your subject matter experts can use the tools; and have a POC to evaluate the authoring environment and the ease of creating process applications.