A problem with this approach is that these requirements and the ‘ auto-scoring weight’ applied to each is almost certain to change once the bid analysis gets underway.

Auto-scoring based on a pre-set list of requirements can help when conducting very basic analysis (price, incumbency values, etc.), but for more strategic spends, with many (potentially competing) stakeholders, and strategies that go beyond simply buying something (should I be buying parts or assemblies, materials or finished product, labor or expertise), there is significant value to being able to create new requirements/rules on the fly, and analyze these requirements with a variety of ‘weights’ as new information and options are uncovered and new priorities emerge. Baking these requirements and their corresponding scoring weights into your process or esourcing tool before the sourcing event begins can severely limit your analysis flexibility and drive you to the wrong conclusions.

http://blog.sourcinginnovation.com/2007/12/06/the-doctor-on-technology-rfps-dont-put-the-cart-before-the-horse.aspx

This strategy might work for sourcing screws, but for complex commodities it is a dangerous trap. My company declines to answer a large number of RFPs because we can tell up front, just by looking at the RFP and its narrow-minded perspective, that our “automated score” won’t get us past the first round. The prospective customer has already (foolishly) narrowed his choices and his questions to the point where he cannot even consider our approach.

I’m also amused at “Build Data Collection Requirements with the End Result in Mind.” This sounds terrific, but in a complex RFP situation, you don’t know, and cannot know, where the data will take you. Rather than spending endless hours in committee meetings trying to decide what questions to ask, why not run a quick RFI round to figure out where you stand, and what data and solutions you might be missing?

The same incremental approach holds for data analysis. No fixed data schema can anticipate the queries and data organizations that will be needed in future, so no matter what you do, the data warehouse you build will be inadequate. Assume that you will need to create new schemas and new datasets on the fly, on a more-or-less continual basis, or your grand vision for data analysis will falter.