In Part I, where we noted that Mr. Smith was right in his recent post over on Spend Matters UK where he pleaded with those organizations, and particularly those organizations in the public sector, who thought they could build their own e-Sourcing system not to, we gave a host of reasons on why they should not because, like Mr. Smith said, they are

• going to waste OUR money building it,
• waste exorbitant amounts of money keeping the system up to date and compliant with ever-shifting legislation, and
• only feed those dangerous delusions at best (and possibly create an epic disaster as 8 of the 11 greatest supply chain disasters of all time were caused by technology failures, and 6 as a result of software platform failures)!

But we know this isn’t enough to convince the smuggest and most deluded from considering the notion. So we are diving in and addressing some of the difficulties that will have be conquered, one primary module at a time, continuing with e-Negotiation, which encapsulates e-RFX and e-Auction.

An e-RFX system has the following key requirements:

• Flexible Construction
• Fine Grained Security & Auditing
• User defined weighting factors for comparison

And an e-Auction system has the following key requirements:

• Flexible Lotting
• Configurable reverse auctions with multiple parameters
• Real-time Distributed Communication with Fault Tolerance

Let’s start with the flexible construction requirement for RFX. Since there are dozens of vendors with decent e-RFX solutions on the market, one may fool oneself into thinking that this is easy. And while it is easier to build an e-RFX solution than just about any other Sourcing (or Supply Management) platform, if usability is a goal, it’s still not simple or straightforward. Qualification questionaries could contain a dozen sections with dozens of questions each. Advanced tabbing and pagination with dynamic expansion and compression depending upon answers and level of detail needed is an absolute must. Moreover, most supplier organizations will require input from multiple people to complete the RFX (sales, finance, production, etc.) and will need to assign parts, but not all, of the RFX to different individuals so fine-grained roles-based security will be required on the supplier side as well as the buyer side with organization, department, and user level settings and overrides.

Now let’s jump over to the flexible lotting requirement for e-Auctions. Sometimes a buyer wants to put a single product (such as laptops when an entire department is due for upgrades) out to bid, sometimes the buyer wants to put an entire category (such as office supplies) out to bid, and sometimes the buyer wants to bundle products and services (such as MRO parts and installation services). And sometimes the buyer wants to put all of these lots into a single multi-round auction. Capisce?

In addition, both platforms will require the ability to define user-defined weightings against each survey response and bid so that the buyer can compute a weighted score for each supplier or lot. And these won’t always be simple — especially if the buyer wants to weight a fuel surcharge based upon product weight and supplier region. That’s not a simple modifier, that’s a formula. And these formulas can get pretty complex in complex tenders created by a sophisticated buyer.

Moving back to the auctions, we also have the requirement that the auction must be customized each time against a host of parameters that will include, but not be limited to, bid floors and ceilings per item and lot, minimum decrements, automatic time extensions, minimum time between bids for a single supplier, and so on. Furthermore, all of this must be evaluated in a system that supports …

Real-time Distributed Communication with Fault Tolerance. In an e-Auction, multiple bids are coming in at the same time, multiple updates must be pushed out at the same time, and formulas and weightings must be calculated and updated in real time so each supplier sees their true relative rank, and not just their true relative bid. This might sound easy-peasy, but you have to remember that even the average CS graduate has trouble with programming for concurrency. (Remember, the doctor was an academic in his former life and knows this to be true. Most Universities care more about $$$ than knowledge conveyed, most untenured professors care more about publishing, as opposed to perishing, than teaching, and most tenured professors are worn out and just don’t care. As a result, as long as the program is able to read the test data and create the right output, in one case, that’s enough for a pass. It’s sad, but true.)

And while this is just a high level overview of the challenges, the hope is still that it is sufficient enough to convince you that development is not an easy task and not an idea that the average organization should remotely entertain.