Don't RFP, Just DIY

Here is something you won't hear from many BPM vendors: more than 50% of all BPM projects fail, and the few that succeed do not lead to any repeat sales 3 times out of 4. Across the board, BPM shows one of the poorest track records of any enterprise software category. What is to blame? A broken technology adoption process.

Up until now, most enterprise customers have selected BPM products through a traditional Request For Proposal (RFP) process. They compiled huge laundry lists of features suggested by analyst firms and enriched by all possible stakeholders in the organization, submitted them to a dozen vendors for initial selection, invited three of four for a bake-off, then selected the winner based on its ability to deliver a Proof of Concept in a relatively short period of time (typically three to five business days).

Of the three vendors invited for the PoC, one spent the entire week trying to install the product, another managed to get the product installed in a day or two, but could not complete half of the scenario that was submitted for implementation, and the winner got most of it done, with fancy dashboards to make it all very sexy. Average prize awarded to the winner? $250,000 to $500,000 in software licenses, and $500,000 to $2,000,000 in implementation services. Project outcome? When things went well, a set of pretty pictures hiding a whole bunch of code that customers will never be able to change on their own. When things didn't go so well (in most cases, they don't), millions of dollars spent, and not much to show for them.

What went wrong?

In a nutshell, customers learn very little if anything when asking BPM vendors to go through such an RFP and bake-off process. The reason for it is simple: most BPM 1.0 products are pretty much the same. They're more akin to technical frameworks than packaged products, and can only be used by highly-trained consultants usually working for the vendors. When compared against each others in the context of a bake-off, the winner isn't the vendor pitching the best product, but the one bringing the best consultant to the party. This highly-talented individual will be a master at discovering the hot buttons of all parties involved in the decision process, and do a great job at turning the customer's scenario into a beautiful demo, hacking fancy user interfaces around the clock, and showing how easy it is to change the process once everything has been put in place to support change requests that have been defined a priori. Essentially, this consultant has delivered a great performance worthy of the best illusionists, and the customer has been fooled into believing that they could do the same on their own.

Such a selection process usually takes 3 to 6 months. Once completed, the winning vendor deploys an army of consultants who will take the customer's broken processes and hard-wire supposedly-improved ones using the vendor's framework, and writing lots of code. The customer's involvement in the project will be limited to defining high-level processes (using process documentation tools that equate processes to boxes and arrows) and a few metrics. Unfortunately, the consultants hired for the job are nowhere near as good as the one who was sent for the bake-off, hence processes won't be implemented in such a way that changes could be applied down the road. And because the customer wasn't really involved in the processes' implementation to begin with, any hope that changes could be applied by the customer's staff directly is just wishful thinking. Once again, concrete has been poured, dried up, and is now solid as a rock. You thought that BPM would give your business agility? Think again.

BPM is not a magic wand that can let business people implement and change processes on their own. If it were, you would not have to pay expensive consultants to deploy these expensive BPM products, would you? BPM, or shall we say BPM 2.0, is a next-generation platform allowing business and IT to discover, design, implement, deploy, and optimize manageable business processes, together, better, faster, and cheaper than when using any other technology. But the only way for it to work is for business and IT to be involved, together, using the same tools, languages, and methodologies. And the only way BPM can bring agility to the business is when BPM is used by customers themselves. In other words, if you want it done right, Do It Yourself.

This is yet another reason why the COSMO model makes sense for BPM. Instead of going through an expensive and misleading product selection process, just pick a product based on industry standards (BPMN and BPEL) and available free of charge, send some of your staff to training to learn about these standards and best practices for customer-led BPM projects, start building a PoC on your own, get it deployed in a controlled production environment, make some changes to the process, see for yourself if it works or not, and if it does, and only then, call the vendor and buy a subscription for the product's commercial edition in order to get a single throat to choke should anything go wrong down the road. Doing so, you'll learn something of value, save your company a lot of time and money, and get the best out of BPM.

As one of our now-defunct competitors used to say: Go ahead, change!