More On Vendor Relationship Management (VRM)

This post continues where this one, which gives a bit of background on VRM, leaves off.

In a December, 2006 SuitWatch piece in LinuxJournal, Doc Searls writes that there are a number of parts of VRM, which include:

• Data Independence – “Individuals needs to own and control their own data, independent of vendors”
• Customer-Centricity – “Customers are at the center — at the inside — and relate outward toward any number of vendors”
• Reputation, Intention and Preference – “All three bear on relationships, and there is an enormous amount that can be done with each of them.”

Of these three areas, the one that I see as key (and, of course, the hardest one to implement) will be the adoption of true customer-centricity in the marketplace. Why is this the hardest problem? Because, although there are some technical components, this is much more of a “soft” problem, one of culture and mindset, rather than a problem of RFCs and technology. Doc continues that we need to think about:

“…the inside-out nature of relationships between customers and vendors. That is, customers are at the center — at the inside — and relate outward toward any number of vendors. The idea is not to take the old top-down few-to-many pyramid of vendor-controlled markets and turn it upside down, with customers now on top. Instead, we equip customers with the means to function in more ways inside marketplaces, at the center of relationships with any number of vendors.”

With this, I strongly agree.

However, one of the other areas of concentration that Doc proposes is the idea of a “personal RFP.” On the concept of the personal RFP, Joe Andrieu writes:

“I think what we are actually seeing is more of allowing people a way to post a personal digital RFP… which will require some sort of shared API. Interestingly, corporations could also use a digital RFP, since it is all the same to the marketspace.”

There is also now talk of creating a Firefox plugin for personal RFPs. (In fact, there’s already the beginning of a spec.)

To this, I need to say “whoa, cowboys.” Take a step back from the keyboard. There are two reasons for this.

Reason One: Immediately diving into code is going to take us exactly down the same path that CRM did, and focus on the technology, instead of the people.

Remember that little “R” thing in the middle of both CRM and VRM? The one that says “relationship?” Finding a better way to have vendors compete solely on price does not a relationship (or even a conversation) make. It’s simply a different way to do transactions. (My thoughts on the “transactions to communities” path here, from August, 2005.)

Focusing on the transaction alone doesn’t help.

Reason Two: Before diving into creating a new technical spec, step outside and look around a bit.

Don’t reinvent the wheel. A lot of this work has been done, and can be leveraged. Electronic connection between buyers and sellers has been going on for a long time, first via EDI, then using these fancy Interwebs and XML. For example, RosettaNet has been working on these problems for nearly a decade. (Disclosure: I served on the RosettaNet solution provider Board of Directors back in the day.)

For example, what is being described in the Firefox plugin spec is, essentially, a request for a quote from a series of providers. Well, hey, lookie-here!

Partner Interface Process 3A1: Request Quote

“The ‘Request Quote’ Partner Interface Process™ (PIP®) enables a buyer to request a product quote from a provider, and a provider to respond with either a quote or a referral. If referred to another provider, the buyer may request a quote from that party. The prices and product availability reflected in a quote may be influenced by an existing or potential relationship between a buyer and provider.

Quotes may:

• Involve one or more items, fixed price quotes or negotiated prices, configurable or stand alone product.
• Include freight and tax information.
• Be reconciled with purchase orders.
• Support ship from stock and debit credit claims.

Should this transaction not complete successfully, the requesting partner executes PIP0A1, ‘Notification of Failure.'”

I want to be clear. I’m not saying that we don’t need technology to do this. I actually feel that technology is critical to making this work. But cart-something-something-horse. Let’s talk to some customers (hey…that’s us!) and find out what’s really needed, and what we want the capital-R-relationships to look like before we start coding.

So, in other words, I’m very hopeful for the direction that VRM is going. I’m looking forward to rolling up my sleeves and helping out in any and every way possible. At the same time, I’m going to be that nagging voice of the human customer, doing my best to ensure that the effort doesn’t solely dive into a series of technical warrens.

I’m going to do my best to ask us all to continually remind each other what brought us here in the first place.