Disclaimer: This blog, including this post, is not sponsored by CombineNet. The author is not employed by, contractually engaged with, or affiliated with CombineNet. Any and all opinions expressed herein are solely those of the author. Furthermore, the opinions expressed herein should be contrasted with the opinions of other educated professionals before the reader forms his or her own opinion. Finally, the author is neither endorsing nor dissenting the use of CombineNet’s products or services – merely trying to spread awareness on the importance of optimization and the relative uniqueness of an offering like that of CombineNet. This disclaimer holds true for each post in this multi-part series and will be repeated.

Yesterday we recounted The Story To Date, and in response to the statements of CombineNet’s representatives that their product is designed for “everything in the bucket sourcing”, their optimization is easily accessible, their speed allows for more scenarios to be run in the same time frame – increasing the probability of a successful event -, they are now a hybrid of BoB (Best of Breed) and POE (Platform Optimization Engine), offering their clients the best of both worlds with their preconfigured templates, and even Jay Reddy, founder of MindFlow, openly acknowledged CombineNet’s optimization capabilities were without peer I noted that the reality was, more or less, (much?) better than it was (but easy is a relative term), definitely, more or less (but that’s not necessarily a bad thing), and pseudo revisionist history.

Today I’m going to indirectly address these issues by tackling CombineNet’s post The Make vs. Buy Dilemma, which was in response to my comments on their Analytics Support Negotiations posting.

In this post, Paul Martyn endeavors to offer a specific example of make versus buy to illustrate the saving potential an optimization-enabled sourcing process can unlock to demonstrate how Expressive Bidding unleashes savings and offers new insight into supply plans.

In this example, Paul uses the example of a seat assembly to illustrate that in addition to:

• sourcing the individual components and assembling them (make)
• sourcing the assembled components (buy)

one can take a hybrid approach where one considers

• sourcing bundles of parts in combination with individual parts.

In his example, Paul illustrates a situation where sourcing individual parts (make) costs $129, sourcing the final product (buy) costs $120, but sourcing subassemblies, which may consist of the odd individual part, only costs $92.

Although this was a very good post, and one of the clearest posts out there on the power of optimization, it did not quite meet its goal because this is a problem that could be more than adequately solved by way of a leading platform optimization engine, such as Iasta’s, although it would take three scenarios instead of one (and possibly a few extra milliseconds of solve time), and a problem that could have been solved with a single scenario using an unreleased version of MindFlow’s optimizer, the former leader in the platform optimization engine category. In other words, it might take the right approach, a little creativity, or a little extra work, but some make vs. buy analysis can be done with platform optimization engines.

Does this mean that you don’t need best of breed? Not necessarily. There are problems that the platform optimization engines cannot solve. However, these tend to fall into two categories: deep and complex or highly specific. However, as it was defined, this was not one of them. But Paul was closing in on the right path, and tomorrow we will discuss a problem that you would be (very) hard pressed to solve using a platform optimization engine.