Talk:Privacy issues
The hashing approach, while it brings some interesting benefits, makes me a bit nervous on a couple of fronts. My main concern is the limitations that it seems to impose on the RFP: as Bbenz notes, because hashing requires that both seeker vendor hash the exact same string it works well for something like a specific product code, but far less well for more abstract requests.
Taking the examples from the taxonomy page, hashing might manage a request for a Blackberry 7130c relatively easily, but requesting a cell phone based on features (must have bluetooth and EDGE support), or price (must cost $250 or less) becomes non-trivial very quickly...the data dictionary required just for cell phones would be pretty hairy. Hashing also makes RFP-offer matching absolutely binary: either a vendor has an exact match for the RFP or not, no possibility of a vendor offering a good deal on something very close to, but not exactly, what is defined in the RFP. [This "all or nothing" model may be desirable for some; in my head, though, VRM allows vendors some latitude in what they offer, with a combination of seeker-side offer evaluation and a reputation system combatting the potential for abuse.]
I also worry about the increased importance of a third-party authority that I think I see coming from this model. If we're hashing, there needs to be a single, authoritative source defining the language and grammar of every term that can be used in an RFP; returning to the taxonomy examples, until that source provides or confirms the definitive way to say "I want a cell phone that costs less than $50 and is AIM-capable," it's effectively impossible to make that request. The central authority becomes absolutely critical to the VRM process, which scares me a bit.
[Note: I'll happily agree that defining a data format for RFPs/offers that is structured enough to be easily parseable but open enough to allow making all (or most) of the necessary kinds of statements isn't all that much more appealing an option. I just think that it's a much more forgiving approach for when the inevitable typos/errors creep in, and that it would require less maintenance and overhead.]
Looking forward to hearing what others think... --whitneymcn 02:56, 4 January 2007 (EST)
The third party doesn't usually have to define the data dictionary
In my experience, there is usually already a way to define items that are the focus of transactions within an industry, be it products or services, and many of those formats ae already in sharable forms, such as XML. A third party (or parties) could be part of this solution, but I see them more as facilitators providing the common method by which the data is hashed by the customer and the vendor, not determining the format of the data itself.
One possibile example: The customer part of the system (not that I'm purposely avoiding defining these too much at this point...) could find the data format of the product or service request from the vendor part of the system to define what they want (could be a format registry, etc.), in my example, cell phone service. The customer part of the system would use this format as part of the RFP, which would be enclosed in a standard transport format when hashed (I want to say XML doc segment here but I'm resisting pinning down the format just yet). Only vendors offering that type of service as identified in the format of the request could query and respond to those requests.
On the subject of third parties, (if there is a need for third parties in VRM), IMHO, the most important function would be vendor control. Without some way to identify real vendors, I could see "agencies" popping up to handle queries, claiming to be in every business in the universe, then reselling the quotes to whoever pays for them. The result would be basically a faster, electronic form of the advertisement model we have now; getting lots of offers for lots of stuff you don't need or want, not related to what you asked for in the first place. Or getting 30 offers for the same 1 thing, with a margin tacked on by middlemen (for example, 30 offers for cell phone service from retail storefronts, offshore cyber sweatshops and moonlighting day-traders in their home offices, all of which are actually just reselling the same cingular plan)....But maybe I'm wrong here, I'd definitely like to hear thoughts on how VRM vendors could be controlled without third party policing.
As for RFPs containing really vague items, now wer'e talking customer control.....In any RFP scenario I've ever been involved in (and this is bitter experience talking here :) ), one of the few responsibilities of the customer is to have a fairly clear idea of what they want before they send out an RFP. IMHO the same would be true for VRM RFPs....In order to submit a lucid VRM RFP, basic product and service decisions would have to be made by the customer before the RFP is submitted. That way the vendor can provide appropriate responses to the RFP. As there will be minimal contact between the customer and the vendor befor a VRM-based purchase is made, IMHO, this is as critical as vendor control....And the customer part of the VRM system would definitely have to manage this. This definitely needs more discussion too....