One of the most consistently valuable and widely read types of information about BPM and enterprise IT in general is the user story. Sometimes called a "case study," sometimes called a "success story," such tales always seem to gain a lot of traction among others pursuing or considering BPM or other IT initiatives.
Except, it seems, for some, at least, when that user happens to be an IT vendor.
After numerous conversations with IT decision-makers at user and vendor enterprises, and with more analyst relations people, public relations people, and users than I can remember, I've concluded there are two types of people in the world. There are those who believe that any user experience can be useful, even if that user is also a vendor. And there are those who believe that anything and everything that comes from a vendor is immediately suspect, even if it comes from IT decision-makers at that vendor company.
I believe that each side has some good points – but that generally, we have more useful things to learn from vendors than we have reason to distrust them, especially where experiences related to BPM and IT are concerned. After all, if we are in fact trying to build and deploy the most effective BPM solutions possible, shouldn't we try to learn from everyone's relevant experiences? If there is anything about vendor experiences in these areas that automatically disqualifies those experiences from further consideration, I have no idea what it might be.
(A similar debate has raged – or at least burbled along consistently – for years regarding anonymous user stories. "Anonymous stories lack credibility," argue some. "What they say and have to teach us is more important than who they are and where they specifically work," argue others, including me. Just so you know.)
Here's the thing. Proven practices and experience-based decisions are far more important to the success of BPM efforts than any particular technological choices. And in some three decades of watching this space, I have yet to see a serious vendor successfully try to hold itself up as a credible "reference account" and avoid scrutiny by always-skeptical users. Users typically recognize BS from vendors immediately, and discount it appropriately, whether they say anything out loud about it at the time or not. And the serious, credible vendors I've encountered know all of this, and comport themselves accordingly.
If your enterprise is already or considering doing business with a BPM vendor, you should ask that vendor to show you how it is using its own solutions, and how its own BPM experiences have driven development of those solutions. If you're already or considering doing business with a vendor too small to use its own solutions, you can still ask about the experiences its founders and leaders have had or seen at other enterprises. And any credible candidate vendor should be able to connect you with at least one customer with experiences worth sharing, even anonymously. Call me overly cautious, but I find it hard to recommend purported "solutions" that can't yet be shown to have actually solved something, somewhere. Even if "somewhere" is the place where the solution itself was developed.
But as the title of this rant indicates, this is in fact a test. I want to know what you think of vendors as credible sources of user experiences, and of the value of user experiences generally to other users' BPM efforts. So please tell me – via e-mail or comments posted here, anonymously or otherwise. And I want to hear from you whether you're a user, a vendor, or just a mildly interested observer/instigator. This is a debate that hasn't gone away in 30 years, so let's see if we can't add anything interesting to it!
Michael Dortch has been an analyst, 'information entrepreneur,' speaker, and writer about IT and 'the real world" for the past 30 years. After almost 10 years at the Robert Frances Group (RFG), Michael begins a new position with Aberdeen Group in September.
Dennis Byron is an analyst with ebizQ, focusing on Open Source Software as well as Business Process Management technologies.
