E-sourcing was a big deal right before the Internet bubble burst, but as the B2B / e-sourcing vaporware companies went belly-up, pretty much so did e-sourcing.  There were still some hanger-ons and the bigger companies (SAP) were making headway, but it wasn't until the past couple of years that e-sourcing began advancing again.  Reverse auctions are what drove the latest e-push, and it seems that e-sourcing tools have taken a more modularized versus ERP approach of the past.  A good example of this modularization / specialization are e-RFx tools, which seem to be gaining popularity.

There are a lot of advantages to using an e-RFx tool, but there are also a large number of disadvantages.  In fact, many advantages of an e-RFx tool can be a disadvantage based on who you ask.  For example, an e-RFx tool facilitates closed-ended questions better than open-ended questions.  Sure, you shouldn't be asking essay-based questions in the first place because they're impossible to normalize for comparison purposes, but part of the reason for issuing an RFP is to get vendor "input," and not to just answer Yes / No or multiple choice questions.  In that way, I think e-RFx tools are better for RFQs than RFIs or RFPs, but that's just my opinion.  There are other flaws, like a vendor having to "learn" the e-RFx software that you happen to be using versus what everyone else is using.

But, in a nutshell, e-RFx tools do a pretty good job of automating the RFx process.  Where the tools fall down, in my mind, is the most critical, important part of the RFx process--whether automated or manual--and that's the requirements part.  One of the supposed advantages of an e-RFx tool is online collaboration, which includes your customers inputting their requirements for the RFx online.  Getting customers to give well-developed requirements for an RFx in a face-to-face format is hard enough.  I have to imagine that getting customers to "collaborate" online when it comes to inputting requirements is actually going to be even harder.  Just like that IT saying "garbage in, garbage out," an RFx is only as good as the requirements it contains.  Automating an RFx that has crummy requirements is the same as putting lipstick on a pig; it might look pretty, but it still stinks.

A very few e-RFx vendors offer "templates," which include some requirements for certain commodities.  In my mind, that's where an e-RFx vendor can provide real, tangible value-add beyond automating the easy-to-automate process of an RFx.  And this is where I think e-RFx vendors should concentrate some of their resources if they want to grab market share.  What I envision is a slice-and-dice repository full of requirements, based on commodity, that a purchasing professional can pull into an e-RFx to get customer input.  Sure, some of the requirements won't at all be applicable or will be too generic, but when it comes to requirements, it's almost always easier to edit someone else's requirements than it is to develop your own from scratch.  Very frequently, I scour the Internet to find sample RFx materials as a source for building my own.  If I can do that manually, why can't a comprehensive repository of requirements be developed?

To really facilitate this repository, a vendor would need some sort of categorizing schema and would also need for its customers to plow their self-developed requirements back into the repository.  Again, a few vendors are offering templates, but they need to kick it up a notch if they want their e-RFx technology to really provide value-add for purchasing professionals.

If your customers think an e-RFx tool is going to make life easier for them, it will, but only to a certain extent.  The onus is still on your customer to provide you with the requirements you need to properly source their deal.  You can cajole them, you can cuddle them, or do whatever else works to coax the requirements out of your customers, but an e-RFx system isn't going to help you with that part of the RFx process.

Played: 16 | Download | Duration: 00:03:55