The Proof is in the Pudding?

Following up on my post last week on what goes into the making of a BPM project, let’s talk a little more about Proof of Concepts (POCs). To truly gain traction from Discovery to Automation and to zero in on the right BPM software, a POC showing your vendor’s competency on a number of issues is essential. It’s simple really – Don’t Invest till you Test!

When it comes to evaluating a POC, there are the usual suspects

-         - Time to delivery from start to finish

-         - Sustainability (does the vendor have the bandwidth and skill to support optimization over a long time period)

-        -  Human reaction to change

-        -  Ability of the product to react to change

But apart from these the most critical test of concept is the scope of the POC. A scope bound POC which is a sub set of the actual BPM project offers enormous clarity to the process owner.  More importantly, as a BPM customer you should be cognizant of your exact BPM requirement before evaluating vendors ... the idea is to map the software to your needs rather than spend time and money on a POC to reinforce its inherent strengths.

A BPM customer should drive the outcome of a POC and test for compatibility with existing IT environments among other things. Introduce scenarios that test vendor agility and response to process change – indication of a strong services team means that you gain from the vendor’s BPM project experience when it comes to building a new application around the product.  For a BPM vendor of course, a well defined POC directly translates to cost efficiencies and in depth understanding of the client’s requirement.


Invest more technical resources in rolling out a POC and you have yourself a sustainable BPM customer who views you more as a BPM partner and less as a software vendor.