When I worked at AMR Research, one of the interesting challenges we faced as analysts was dealing with the many systemic issues between providers and practitioners. These included dealing with product development, product support, upgrades, licensing, promised vs. actual dates on product roadmaps – and much, much more.
Having had enough of it, my old boss Bob Parker worked with a bunch of our practitioner clients (and some providers) to develop a software buyer’s bill of rights. It got a little traction, but soon fell by the wayside as folks went back to their old habits. That was in 2002. Four years later, an analyst at Forrester named Ray Wang picked up the mantle and “re-introduced” the concept (I don’t think he even ever cited or credited Bob, but I’ll assume ignorance was bliss here) and took it to a new level (see here and here). While Ray touted many of the same concepts, he also added much more content, particularly in the area of SaaS, including a seminal paper on buyers’ rights that can be downloaded here and a detailed assessment here. Although some of the critical rights are more like wish list items, the document is a “must read” for any buyer or seller of SaaS based solutions. Buyers should evaluate what requirements are important to them; providers must prioritize which capabilities will or will not be offered (and why).
A “Procurement” Bill of Rights
I won’t re-invent the wheel in the excellent work done before – and the SaaS rights are certainly applicable to procurement solutions. However, the procurement solutions market has some nuances, and it has changed quite a bit with the evolution of “XaaS” (i.e., not just SaaS, but also the PaaS and IaaS environments being used to deploy the applications), service oriented architectures, supplier/business networks, social media, and the like.
In this new environment, there are emerging paradigms and challenges that have not only commercial implications, but also the potential to affect broader business valuations to providers and practitioners alike. For example, if a buyer’s account at a supplier network was breached (not too hard to do through phishing and other means), then you could find out a fair amount of data. And some of it might be fairly sensitive and strategic (e.g., identifying where and what upstream oil & gas exploration equipment and services are needed to discover a new energy reserve). So, this is not just about pushing RFQs and POs.
Unfortunately, many of the paradigms being put forward by certain providers looking to advance their own particular business models (e.g., supplier network revenues rather than software product revenues) generally conflict with some of the aforementioned rights, and it’s important to put a procurement lens on them and get specific on their relevance.
So, I’ll offer only a few incremental basic rights in the context of the procurement market, and then let you, the readers, chime in with others that you might have. In this first post, I will outline one of the procurement rights, and then follow up in a secondary post for the rest.
Right No. 1: Buy an enterprise-class application that can link to multiple suppliers and supplier networks – not be a component of a commercial network itself.
While buyers of procurement applications do appreciate the value of external services to enhance the functionality of technology applications, what they most want is enterprise application functionality that meets their needs, along with having flexibility to connect that application to various service providers such as supplier networks of different types.
In other words, you want the best on-ramp or “handset” that connects to different networks. To use a smartphone analogy, you might want the best Android device from Samsung, Motorola, HTC, LG, etc., but expect them to work on your favorite telecom network (Verizon, T-Mobile, AT&T, etc.). Both ecosystems have healthy competition and are agnostic to each other – allowing choice. When an enterprise application provider casts one of its application suites to be “part of the business network,” buyers lose this foundational piece of buyer choice.
We have no issue with an enterprise applications provider creating a business network, but only if the network provides value-added services for content, connectivity, partner discovery, etc. – not core application services. Doing the latter basically makes the application provider a competitor to a potentially rich ecosystem of value-added network partners – and it makes the network a competitor to all the on-ramp applications that customers might want connecting to the network (e.g., niche industry applications). A provider might think that SaANS (Software as a Network Service) is “sticky,” but so is bubble gum on the street, and both leave similar distaste in your mouth as a buyer (unless you’re Will Farrell in Elf). SANS (Software As a [business] Network Service) basically means “without choice,” which is rather fitting.
Additionally, running a private application in a public cloud environment does not abdicate the responsibility for the key data security and privacy requirements inherent in provisioning an enterprise application. I’ll dive into this in my next post in this series and discuss how a few major providers stack up (spoiler alert: SAP will not do well).