In Part I, where we noted that Mr. Smith was right in his recent post on “thinking of building your own esourcing system please don’t” 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)!

Realizing this isn’t enough to convince the smuggest and most deluded from considering the notion, we are diving in and addressing some of the difficulties that will have to be conquered, one primary module at a time, ending today with Decision Optimization.

The simple fact alone that there have never been more than seven software providers on the market at any time selling a true strategic sourcing decision optimization (SSDO) platform, compared to the dozens that have offered spend analysis and the hundreds that have offered some form of e-Negotiation should be enough to make you cower in the closet and pee your pants. But if it isn’t, let’s start by examining the requirements for a true SSDO platform, as outlined in the e-Sourcing wiki-paper.

- solid mathematical foundations
- true cost modelling
- sophisticated constraint analysis
- what-if capability

As *the doctor* clearly said in the wiki-paper, the *tool must be based on a sound (correct) and complete algorithm (capable of analyzing every possibility, not just statistically relevant or likely possibilities) that analyzes an accurate representation of the problem and not a (heuristic) simplification thereof. Generally speaking, a decision support tool built on mixed integer linear programming or constraint programming techniques will meet these rigid requirements and provide true decision optimization while tools based on heuristic techniques, evolutionary methodologies, or simulation models will generally not meet these requirements*. In other words, you need top notch A+ mathematical knowledge and computing theory knowledge in the operations research, logistics, and sourcing domains, and these individuals are very few and far between. We’re talking a rarity of about one in ten million. Do you really think that individual is in your basement wasting his life doing your IT support? Really?

True cost modelling is more than just breaking a cost component down into a list of factors and asking for a value. Many cost factors are dependent upon sophisticated calculations, such as fuel surcharges based upon the distance and the weight or contingent labour charges with overtime calculations, expenses, etc. Complex formulas will need to be supported, and the logic just to determine the proper evaluation sequence will be quite sophisticated in itself.

And what-if capability is more than just making a copy of a scenario and changing a cost or a constraint, it’s the ability to compare scenarios side-by-side and understand the driving forces behind the cost and the award. Why is the constrained scenario 10M more than the unconstrained scenario? Which constraints are driving the costly award? What is the true cost of a constraint — it’s not just dropping the constraint and seeing how much is saved. That’s the cost of the constraint when all other constraints are present. It’s really the cost of the constraint against the unconstrained scenario. And so on.

But this pails in comparison to constraint support. As per the e-Sourcing wiki-paper, (at least) four constraint types are required, and these are not easy to define (and definitely not easy to build in a real instance of a model against a real sourcing event). For example, complex constraints cannot be implemented by a simple equation (pair). Some constraints require four, seven, eleven, or more related equations in a group of equations to be implemented. And these equations have to be consistent with every other equation in the model, of which there could be tens or hundreds of thousands thereof.

In other words, building the model is an almost mythical feat. There’s a reason there’s never been more than seven vendors offering a true strategic souring decision optimization solution and that the rarity of individuals who can even attempt to do so is at least one in ten million. Sometimes building a strategic sourcing decision optimization model requires as many as six impossible things before breakfast on a daily basis. The definition of a simple model of decent complexity requires about 10 pages of intertwined equation (template)s. They make modern MCNF (Multi-Commodity Network Flow) models look like elementary school math in comparison. In other words, they are about ten times the complexity of the following single page MCNF model (taken from D. Hejazi’s PhD thesis), which is enough to earn you a PhD.

*is*the easy button. Still think you can do it in-house?