P2P's failure in so many cases has happened not because vendors stink -- yes, some products fail to deliver, like the old Tradex stuff that Ariba killed off long ago -- but because they haven't fully analyzed what they've bought and what specific problems they need to solve to achieve a specific outcome. More to the point, eProcurement has failed because procurement and IT groups all too often don't have a clue about what they really need, or what they're getting into (or the specific problem they're trying to solve) when they buy a particular solution. Take the case of content and catalog management for P2P.
As Pete Loughlin notes in his post referenced in Part 1 of this series:
"...catalogs are fundamental to e-procurement. They present users with the information that they need to make purchasing decisions. Whether it's a simple piece of stationery or a complex piece of IT, a full set of specs and options as well as a picture are the basic essential components. But in most cases, e-procurement catalogs aren't like that. First of all, the search functionality doesn't work ... Catalog data often falls into disrepair and users are often faced with long lists of part numbers or unhelpful technical descriptions of products that only an expert buyer can make use of. The effect is that requisitioners raise off-catalog orders which get escalated to the P2P operational team – delivering a process that is exactly the opposite of what e-procurement was meant to deliver!"
Let's step back for a moment and understand why this is the case. First off, many eProcurement tools don't ship with a decent cross-catalog search and content management capability, especially capability designed to let suppliers manage and update rich content that is then validated against rules with exceptions flagged for intervention. Any company buying a P2P toolset should know this (for one, this is the primary reason that SAP created so much shelfware with SRM over the early eProcurement years).
Organizations taking on an end state for the use of a technology tool without validating what a given solution ships with deserve exact what is coming to them. Anyone doing diligence on SAP SRM, for example, would know that strong adoption use cases are few and far between showing significant take-up across dozens of supplier managed catalogs without third-party catalog and content management toolsets provided by vendors such as jCatalog, Capgemini, Hubwoo, Vinimaya, WALLMEDIEN, and others. Yet not enough procurement organizations we speak with know enough to ask themselves this question in the first place: what will I need to enable the content I need -- and ultimately users to find the right things they're searching for -- given my environment?
So at the end of the day, I don't believe vendors are the ones who are "half-assed" -- at least in my book. It's the procurement and IT organizations that have failed to ask themselves what they need to do to achieve a desired outcome in the first place. If you don't know specifically want you want or need, don't buy it! Per the analogy in Part 1 of this series, arms dealers will always be arms dealers. And yes, you can kill yourself with the wares they hock -- as can others. Ultimately, if you want to solve the problem -- whether it's eProcurement or stopping childhood wartime violence in Africa -- target the solution and not the messenger or middleman who is literally just taking advantage of the situation. After all, if you shoot him, someone else will just step in to take his place.