Readers of this column understand that getting the most out of business process management demands more than simply documenting, analyzing, and reshuffling your key processes. Whether or not the process is “broken,” you can still make it operate more efficiently, maintain it more easily, change it more quickly, and measure its performance more objectively by using an integrated suite of software expressly designed for that purpose: a business process management system (BPMS).
There is certainly no shortage of candidate software. Some industry analysts quote a figure over 150 vendors in the business. That number seems absurdly high, but it’s fair to say there are at least a couple dozen viable BPMS offerings, in addition to software components that could be custom-integrated in a build-your-own BPM suite. The problem is how to select from the wealth of available technology.
Vendors, as is their habit, make an intelligent buying decision as difficult as possible. In their marketing collateral and websites, they all sound identical. They all tout the same benefits statements – efficiency, flexibility, agility, compliance, performance visibility – and give the same brief nod to “industry standards.” Similarly, as they try to maximize their placement in the analysts’ magic quadrants and waves, they all tick off the same list of features. And if you ask a vendor what kind of process its BPMS focuses on or was specifically designed for, they invariably say, “We can handle any kind of process.”
But, in fact, BPMS offerings are diverse in the extreme. In reality, each is optimized for a particular class of business processes and a particular set of process designer skills. Probably because the technology is new, BPMS vendor marketing departments are reluctant to “confuse” buyers by clarifying these differences. So they cast their net broadly. But are they really helping themselves? They are certainly not helping the buyer.
Would you buy a car this way? Sure, a BMW Z3 roadster can be used to haul lumber – one or two boards at a time – but that’s not really its most important use case. And a big Dodge truck could be used to ferry the kids to school, but that’s probably not its key use case, either. Auto manufacturers don’t try to sell product by saying, “It gets you from point A to point B quickly and safely.” Because the public understands the category in general, the buying decision is usually based on finer distinctions.
We’ll get there eventually, but for now, what’s a practical approach to selecting a BPMS? Here are three guiding principles.
- Look for a BPMS that fits your process type, or “use case.” We’ve already admitted that the vendors don’t do this for you, but it’s not all that difficult to figure out yourself. The 2006 BPMS Report, which will be available for free through BPM Institute starting in November, describes six distinct process types, differing in instance volume, intensity of human interaction, intensity of application integration, need for business rule management, content management, and automated event and exception handling. While every BPMS finds a way to at least check off the boxes for human workflow, integration middleware, business rules, content management, etc., they differ wildly in emphasis and richness of specific features and capabilities. Use case analysis is a good way to understand their proper weighting in your buying decision.
- Use case analysis means you have to start by understanding in detail your own process type. If you’re looking for a BPMS to be a service shared by multiple business processes in the organization, you need to think about the range of process types you need to accommodate, and whether you want them all to leverage the same BPMS. Understanding your process use case leads you to look at specific BPMS features not as simple checkoff items but as a suite of capabilities that can be either richly developed and central to process management or minimally implemented, intended for use on an exception basis.
- Look for a BPMS that fits your modeling and implementation lifecycle. As a high-level benefits statement, all BPMS vendors claim they do this. But again, they don’t all mean the same thing. Some provide a single modeling environment shared by business analysts and executable process designers. The same process model used for simulation analysis and optimization is refined with implementation detail to make it executable, so the implementation is always in sync with the business model. Others view that as going too far, and strive instead for a “clean handoff” from business to IT. In those products, analytical modeling and executable modeling take place in separate tools, with translation of data models and exchange of process information between the tools performed transparently under the covers.
Whether through a shared environment or clean handoff, business and IT need to collaborate not just in the initial modeling and requirements definition, but continually throughout process operations to deal with performance management and change. Each BPMS is based on a particular set of assumptions about the technical skills of business analysts and process designers, and how they collaborate in the process lifecycle. It is important to make sure those assumptions match the reality of your corporate culture.
Check out comparable reference implementations Have you ever heard a vendor not claim to be ultra-scalable, reliable, or quick to deploy? Of course not. And in BPMS, there are simply no industry-wide standards you can use to compare vendor claims for these kinds of things. You need to rely on anecdotal evidence. If you subscribe to an analyst firm, they can often provide this, cases where the BPMS implementation either worked out well or did not. But by far the best form of due diligence here is to check out a vendor’s reference implementations yourself.
Once you are down to a short list, you need to ask vendors to provide customer references you can contact, ideally in applications similar to your own (i.e., same use case and collaborative process lifecycle). Then you need to call them, or better yet, actually arrange to visit the implementation, and find out the real facts – how long did it really take, what was the business/IT collaboration really like, what things needed custom programming after all, how agile was the development process after all? This is required due diligence. You simply have to do it. But it’s really the last step.
