One of the beautiful things about reverse auctions is that they condense bid collection elements during an actual event to simple numbers and/or the decision to lower a bid by a certain percent. In contrast, the flexibility inherent in bid collection approaches that do not require an apples-to-apples bid but instead permit suppliers to submit alternatives (e.g., I'll bid on "this" but not "that", I'll bid on "this" with these added volume discounts, I'll bid on "this" and "that" using a partner to supply "that") is significantly greater. And so is the computing processing load.
For this reason, many of the early sourcing optimization tools worked better in theory vs. practice (unless you could wait around for hours to run a particular set of constraints and award scenarios). My colleague Peter Smith observes that when "you're running optimisation/market informed sourcing exercises, where the system's processing capacity is being used in a value-adding manner to analyse and optimise possible sourcing outcomes across multiple variables, [underlying horsepower is essential]. In such cases, the provider's ability to access the required processing power and capacity is critical."
So where was the processing power in this case given that Emptoris/IBM was running the event on its own servers regardless of whether they were using optimization or not (attachment collection and integration can also be taxing on computing capacity)? The answer, from what we've heard unofficially through the grapevine, was that the UK government did not necessarily budget for the necessary processing capacity when the original deal with Emptoris was inked. Indeed, it appears the system could have scaled up. But the government was not necessarily willing to pay for added scale to ensure adequate response and uptime for such a massive event.
In Spend Matters view, perhaps the better contracting model would have been for the UK government to host the Emptoris application itself and added server capacity on its own, or to have paid for the type of flex capacity that smaller competitor Trade Extensions enables via the Amazon Cloud.
Emptoris has invested quite a bit in scalability and architecture in the past. Dating back to September of 2010, Friday Rant: Emptoris Echos -- Cloudy With a Chance of Software, we opine that what Emptoris was calling ECHOS (Emptoris Cloud Hosting Operating System) at the time took a rather unique approach to flexible configuration and deployment approaches (cloud, or at least a variant of it, included):
The flexibility inherent within an architecture that simplifies deployment in behind-the-firewall [i.e. ECHOS], hosted or hybrid modes while also delivering the ability to rapidly scale-up CPU and general computing/network capacity with burst capabilities in a similar way to the Amazon cloud -- e.g., in this case for very large sourcing events with tens of thousands of line items and three or four constraints in an advanced optimization scenario -- is actually, at least in part, a true cloud infrastructure model based upon the more technical definition, even if Emptoris is taking a bit of marketing license by wrapping all of its architecture now under the cloud moniker.
Still, perhaps the Amazon cloud approach and modularity of individual deployment approaches (reference Trade Extensions, above), might be most appropriate going forward for situations like the UK government wanting flex capacity:
With the new Amazon cloud service, you can run them [sourcing scenarios] in parallel (i.e., complete all 100 in 20 minutes). In this context, customers pay based on what amounts to actual CPU usage. For every CPU second that a request consumes (e.g., a solve request) it is five euro cents. Now, these numbers might at first seem to add up fast, but remember that a typical scenario is solved in 20 seconds or less. The virtualization and cloud design extends to how Trade Extensions has architected its optimization capability that, as it has in the past, is not reliant on any one solver. Trade Extensions can use and substitute ILOG/CPLEX (IBM), XPRESS and Gurobi solvers based on the task at hand. Many other providers in the sector are locked into a single solver.
Alas, perhaps the greatest lesson learned from this event failure won't necessarily make the procurement trade press headlines (which might prefer to simply point fingers at Emptoris/IBM). The true lesson is that non-technical procurement users and executives tasked with buying toolsets within a certain budget should leave the technical specifications and requirements definitions to the IT professionals to ensure the limits of a particular configuration do not fall short of their requirements.
Last, it's important to place this single bid failure in context – regardless of where one wishes to point the finger. GPS' procurement transformation leveraging a combination of Emptoris (sourcing) and BravoSolution (spend analysis) technology on the tools level represents a material leap forward, and e-sourcing solutions like Emptoris are providing significant value across other bids for the UK government. This is benefiting not only UK tax payers but also, we hope, diverse (small and medium-sized) suppliers as well, who are gaining access to business they might not otherwise had the opportunity to bid for.