Last time, I started writing about a large RFx that I worked on with a customer a few years ago. If you haven’t read that posting, you should read it first, then come back to this one.

As you know from the first posting, the first part of the RFx process was to have the many suppliers agree to the contractual terms and conditions. Once this was accomplished, it was on to collecting the updated “catalog” pricing from the suppliers.

We put a lot of thought into the best way to collect the updated pricing. Some of the key requirements for this  process were:

- The products offered by the suppliers varied greatly among the suppliers. This resulted in the number of products offered by suppliers varying greatly from one to supplier to the next.

- The number of products offered by suppliers could be as few as just a couple to as many as a couple thousand. We needed a solution that would address both extremes.

- In adition to collecting pricing information from the suppliers, it was also very important for the suppliers to see the detailed specifications about the products. In total, we had about 15 different specifications that we wanted the suppliers to be able to view during the catalog refresh process.

- The pricing that we were collecting from the suppliers was more advanced than a simple unit price. We needed to collect “tiered” pricing from the suppliers, but not in the traditional sense of tiers represented by quanities, but “named” tiers where the names provided meaning to the suppliers (logically, these named tiers represented “markets”)

- We needed the supplier to be able to add line items to the RFx for any new products they sell that should be part of our catalog.

The first approach we considered for the designing the RFx was to use the basic RFx functionality of E-Sourcing, building up an RFx with the superset of line items (all possible products for all suppliers). We discarded this as a viable approach due to the significant variety in what products each supplier would see.

The second approach we considered was using a separate E-Sourcing RFx for each supplier. In many cases, this approach would probably have been quite good: we would have created line items on the RFx for the various products offered by the supplier, used the “specifications” capability of E-Sourcing line items to provide the important information out to the supplier, and used the “attributes” capability of E-Sourcing to collect the various tiers of pricing. Unfortunately, this method did not adequately address the requirement that we need to have the suppliers provide additions to their catalog for new products they now sell. That is, we needed a way for the supplier to add line items to the RFx for any new products. Based on this limitation and also the fact that managing 250+ separate RFx’s was a bit concerning, we decided against this approach as well.

The approach that we settled on was a bit unique, but due to the high degree of configurability of E-Sourcing, it was an approach that was easy to implement and deploy. We decided that using Excel for the manipulation of the data by the supplier was the best option. Most suppliers would have experience with Excel and those suppliers that offered large numbers of products (1000s) would feel a lot more comfortable working in Excel to provide the updated pricing. Excel also offered the ability for the supplier to add new products.

Our approach was unique in that we used a standard E-Sourcing data structure to manage the product line items and associated those data structures with E-Sourcing contracts. We then created a separete contract for each supplier (in draft status), published that contract to the supplier, and allowed the supplier to export the pricing in Excel from within the contract. When the supplier was complete with their pricing work, they would upload the Excel spreadsheet, which was then processed by us and re-loaded into the standard E-Sourcing data structure holding the line items. Line items that existed had their prices updated. New line items were appended to the data structure. We built reports over the data structure that allowed us to analyze the product pricing, comparing like products when necessary. Ultimately, this data structure was used in the contract to represent the awareded line items and pricing.

What was really great about the solution we developed is that it used all standard functionality of E-Sourcing. It demonstrated the powerful configuration capabilities of E-Sourcing that allowed us to model a unique event in a slightly different way, but without writing a single line of code.

Obviously, there are a lot of finer details about how we put this all together. Nevertheless, I hope this posting has given you some ideas and next time you might “think outside the box” when you have an event that has unique attributes that may not align exactly with the standard functionality and use model of E-Sourcing.