Category Archives: Technology

CombineNet IV: BoB’s Unique Talents

Disclaimer: This blog, including this post, is not sponsored by CombineNet (acquired by Jaggaer). 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.

Warning: This is a lengthy post.

In my last post, I outlined in some detail a problem that I felt not only required BoB (Best of Breed) but required CombineNet in particular for an optimal solution. What I did not convey is that not only are there other problems out there that I could have chosen, but there are a significant number of supply-chain related problems that often require BoB.

Today I am going to discuss six problems that generally require a BoB solution. This does not mean that you would necessarily require CombineNet (there are some other optimization vendors that can tackle a few of these), but that you would require a best of breed optimization solution (similar to that offered by CombineNet) to tackle these problems and be assured that the solution you achieved was optimal.

The problems I am going to discuss are:

  1. Distribution Network Design
  2. Large Combinatorial Problems
  3. Large Non-Homogenous Logistics Problems
  4. Non-Traditional Sourcing Problems
  5. Very Large (Traditional) Sourcing Problems
  6. Regret Minimization Problems

Distribution Network Design

Most large retailers or distributors have large distribution networks – often dozens of locations throughout a single country or region. However, this is generally not optimal. For example, in a talk at INFORMS given by a practitioner at APL Logistics, they described how they analyzed the distribution network used by JC Penney that had almost 60 DCS (and cost over 330M / yr to operate) and using in house proprietary meta-heuristic optimization algorithms, they deduced an optimal distribution network that had only 8 DCs, saved over 30M dollars, and, on average, shaved over a day off of standard delivery times! What the presentation did not dwell on (since INFORMS is an OR conference) is that these problems are usually humongous and insanely difficult to model, yet alone solve with your average off the shelf optimization problem (as bad as the multi-level make vs. buy problem discussed in my last post) and without a best of breed solution, your chances of finding the truly optimal solution are often slim.

Large Combinatorial Problems

Large pure combinatorial problems are much, much harder than large pure linear problems (which optimizer’s like IBM iLog’s CPlex can often cut through like a hot knife through butter on today’s high end machines) and significantly harder than general MIP problems. The reason is that these problems contain very large numbers of binary variables, and the best generic domain-independent techniques available are generally no better than greedy branch and bound, and for even a thousand binary variables, that could be 21000, or over a trillion evaluations. An example of a large combinatorial problem is a large marketplace auction where all the participants bid on fixed size lots which are non-decomposable. In other words, CombineNet’s (original) definition of an exchange.

How much better are best of breed solvers on large combinatorial problems? Let’s consider CombineNet’s best of breed solution customized for exchanges. According to CombineNet: “The resulting optimal tree search algorithms are often 10,000 times faster than the state-of-the-art general-purpose MIP solvers on the hard instances of real-world market clearing.” As I have expressed to CombineNet personnel directly, I doubt that this is the average case, but I know beyond a doubt that well defined algorithms can easily shave a factor of 100 or more off of solution time, and that this can be scaled up to almost 1000 on a multi-core machine with a smart parallel implementation. In other words, don’t always expect the best case, but the average case performance of BoB on these problems will demonstrate significant improvements.

Large Non-Homogeneous Logistics Problems

This is similar to a variation of the multi-level make vs. buy problem discussed in the last post. However, in this situation you are trying to optimally bundle your deliveries across product, and sourcing categories and choose the optimal carriers and distribution network independent of your suppliers. Given the non-uniform quotes (weight, volume, LTL, FTL), lot sizes, and various charges and surcharges often imposed by freight carriers, forwarders, loaders, unloaders, warehousers, etc., this problem can become really surly really fast on a large buy. Moreover, unlike the sourcing case where it often makes up a low percentage of your spend and a high order approximation is more than sufficient, when you aggregate your logistics across multiple categories, even a fraction of a percentage point can become significant.

Non-Traditional Sourcing Problems

Most Platform Optimization Engines are optimized for traditional sourcing problems – this means that they are generally not optimized for non-traditional sourcing problems. (Why should they be? Most of the problems you face are traditional everyday sourcing problems.) But every now and again you might have a non-traditional sourcing problem. One example – cell phone plan optimization. Cell phone plans are expertly crafted to be as confusing as possible to make sure the carrier maximizes profit at your expense. If you’re a small company, it probably isn’t worth the hassle trying to figure it out and standardize on a common carrier plan – the costs of manpower and resulting therapy costs will probably outweigh the savings, but if you are a large company, you can save hundreds of thousands of dollars, if not millions, with the right company wide plan (which will probably consist of different sub-plans for different groups and individuals, but all on the same corporate contract). That’s why Soligence has a solution just centered around cell phone plan optimization.

Another example, as conveyed to me by Paul Martyn himself (CombineNet’s Chief Marketing Officer and premiere evangelist on the CombineNotes blog) is energy utilization optimization. If you are a large corporation that produces energy for your production operations and consumes it from the grid, whether you realize it or not, you have a sophisticated form of an energy trading problem. If you can produce enough extra energy to add to the grid, should you, and when? If you have the potential to store energy, then adding energy to the grid at peak hours and only siphoning off extra energy at non-peak hours could slash digits off of your energy bill. Furthermore, shifting your operations so that your maximum energy utilization only occurs at non-peak hours could also save you bags of money. Considering this isn’t a traditional energy trading model, traditional production model, or traditional operations research planning model, its easy to see why you might have to call on BoB.

Very Large (Traditional) Sourcing Problems

POE, especially a well designed and implemented POE that uses real optimization technology as its underpinnings, excels at traditional sourcing problems. It’s what POE was built for. That being said, POE is built on off-the-shelf optimizers, and off-the-shelf optimizers are designed for general purpose needs. That means that they will hit their breaking points before a custom designed best of breed solution, even though they improve every year. For example, leading solvers can easily crunch MIP problems with hundreds of thousands of variables and pure LP problems with millions of variables, but once your MIP problems contain millions of variables and your LP problems tens of millions of variables, you’ll start to notice a performance degradation, which could be rapid and considerable when you get close to the underlying solver’s breaking point. When your encounter the odd problem that is this large, a best of breed solution that also integrates domain intelligence can save you a lot of time and rapidly increase your chance of finding the optimal business solution in the finite timeframe that you have to make a decision.

Regret Minimization Problems

Most of the time you know the problem you need to solve, the associated constraints, and the associated costs. But every now and again you don’t. For example, you need to rationalize your supply base but do not know the optimal number of suppliers. In most products, you have to choose a number or run multiple scenarios with different numbers and then take the best one. Although this approach can be effective, it doesn’t help you understand why a certain solution is best or guide you to the best solution. A best of breed solution that manages the search algorithm can not only guide you to a potentially optimal solution but inform you of nearby solutions that are invalidated by your soft or uncertain constraints. This is very difficult for a platform optimization engine – since it generally cannot guide the search. The best it can do is run different scenario formulations, show you nearby answers, and identify constraint conflict sets. It’s a good approach, but for a strategic problem, the more you know, and the faster you know it, the better you are.

By now, you’re probably asking does BoB have the upper hand? Well, even though BoB can solve a slew of problems that POE cannot and it’s always theoretically possible to tone down a solution, whereas it’s not always theoretically possible to built up a solution, the reality is that, as I’ve said before, when it comes to optimization, one size does not fit all and using a sledgehammer on a finishing nail is not always effective. Furthermore, these are not your everyday problems. It often takes years to realize the savings from distribution network redesign, reverse auctions and sealed bid negotiations are generally not combinatorial exchanges, you do not redesign your transportation network after every sourcing event, most of your sourcing problems are traditional, most of your sourcing problems are of a manageable size with proper strategic sourcing, and if you don’t know what your constraints should be on a regular basis, you have deeper problems you need to solve first. That’s why an upcoming post will focus on POE, the everyday hero, in more detail. When combined with this post, you should have a better understanding of where each technology can be helpful to you.

Disclaimer II: Although this blog, including this post, is not sponsored by CombineNet and the author is not employed by, contractually engaged with, or affiliated with CombineNet, the author is going to report, in full disclosure, that CombineNet did allow the author to use one of their free registrations at INFORMS (of which they were a sponsor), as well as buying the author lunch.

Riding the Rails with Coupa

As you may recall, Sourcing Innovation was one of the first blogs to bring you a detailed preview of Coupa, the revolutionary new enterprise open-source e-Procurement application from Silicon Valley. One of the most interesting aspects of this technology is that it is being built on Ruby on Rails (RoR), as discussed by co-founder Dave Stephens on his blog Procurement Central [WayBackMachine].

This is a bold move considering that RoR is still a relatively new technology that is essentially unproven in the enterprise application market beyond the corporate website, but one that could pay off big time for Coupa when you consider the rapid development time enabled by RoR as compared to other enterprise platforms such as Java and .NET (where WORA* does not apply). Personally, I’m still a big Java fan, but I can see RoR becoming the platform of choice in a couple of years for a number of reasons:

  • faster development time
    following the mantra of “convention over configuration”, RoR sacrifices flexibility for convenience, allowing developers to do more, quicker, and better within the framework provided which makes basic assumptions that significantly decrease the amount of configuration required
  • MVC architecture
    unlike most enterprise frameworks that have preceded it, RoR was built on the MVC architecture from the ground up and has built in object-relational mapping capabilities
  • full stack framework
    whereas some platforms require extensions from multiple vendors, Rails provides all of the components commonly needed by most web-based systems
  • designed for reusability
    RoR adheres to the DRY (Don’t Repeat Yourself) philosophy and its framework was designed to allow every piece of knowledge in the system to be expressed in just one place
  • preconfigured application structure
    RoR automates the creation of project structure and automatically creates all files and components needed by default (no need for a fancy IDE to automate these tasks for you)
  • simplicity
    rails wasn’t designed to do everything, and its focus on the common features used by a majority of programmers a majority of the time removed much of the complexity inherent in many application frameworks; note that this does not limit its capability, as it includes a robust extension mechanism to allow development teams to add (only) the capabilities they need
  • strong community uptake
    a large number of developers, especially in the open source community, are latching onto RoR as their development environment of choice as it overcomes the shortcomings of web scripting languages such as PhP and the impracticality of J2EE for (rapid) web-based development
  • XML compliant
    so if you need to integrate with a non RoR app, no problem!
  • rapidly maturing environment
    just like Java, RoR is rapidly maturing from a neat language for cool web page development to a full fledged enterprise application development platform – I’d say it’s pretty close to Java 1.2 in terms of lifecycle, which is where Java truly became a solid language for application development

In other words, instead of jumping onto someone else’s bandwagon, Coupa has decided to jump into the driver’s seat and lead the charge in the development of eProcurement applications.

And if you want to join the RoR movement early, but don’t know where to begin, consider checking out www.daveastels.com, especially if you are in the NorthEast, for courses, resources, and best practices consulting.

*WORA: Write Once Run Anywhere

Six Sigma IV: Achievement

The recent Insight from Aberdeen Group, “Technologies Enable Six Sigma” (now Aberdeen Access Members Only) does a great job at demonstrating why we need Six Sigma, or 99.9997% accuracy, and why 99.9% accuracy is not good enough. At a 99.9% quality level, in the United States alone, this would mean:

  • no electricity for nearly an hour each month
  • unsafe drinking water once per week
  • 2,000 lost articles of mail per hour
  • 2 short or long landings at most airports each week
  • 20,000 wrong drug prescriptions per year
  • 500 wrong surgical procedures a week

The insight also makes it a point to note that Six Sigma is not just for manufacturing, since the metrics can apply universally. Whether you measure bad parts coming off an assembly line, or errors made in processing orders, a process is a process and a defect is a defect.

Based on a recent study, the insight notes an interesting fact – those companies that measure PPM (parts per million) and DPMO (defects per million opportunities) achieve better performance than those that simply measure defect rates in terms of %good or %defective. Although none of the Best in Class performers achieved true six sigma quality, those that measured PPM and DPMO were very close to five sigma performance (99.98%).

Why? I think it is partly due to the lessons offered in the Aberdeen Insight, “what gets measured, gets managed” and Six Sigma relies on accurate and accessible data which requires the proper technology, and partly due to psychology. We’ve been trained by the media’s overuse of statistics to accept 99% as very good and 99.9% as excellent and 99.99% as absolutely fantastic. After all, Ivory is 99.99% pure, and we’re supposed to accept that to be as good as it gets, but the reality is this is barely five sigma, which we know to be unacceptable in any critical operation.

As implied in the lessons learned, Aberdeen found a direct correlation between the application of technology and Best in Class performance. In all but one category of IT solutions (non-conformance reporting), adoption rate increases with performance. Although this does not decisively prove cause and effect, there is a strong correlation between top performers and supporting technology, and what’s more important – a detailed cause and effects analysis or being in the “better” pool?

Of course, six sigma is more than just measuring defect rates. Six Sigma employs a structured approach to problem-solving and requires the management of projects which have the potential of having significant impact on the business. To maximize the benefits of these projects, it is necessary to provide an infrastructure that facilitates the adoption of Six Sigma across the organization, manage individual projects, share information effectively and manage financial information in such a way as to gain acceptance on an enterprise-wide basis. While, strictly speaking, tools such as spreadsheets and generic desktop tools, and even pencil and paper, can assist in early stages of Six Sigma implementation, standardization and collaboration are necessary to achieve the next level of benefits.

By implementing project management tools that support collaborative efforts and provide workflow automation, Six Sigma practitioners are able to focus on the analytical aspects of the methodology to drive to true results.

For more information on Six Sigma, I refer you back to parts I through III of the series which appeared on e-Sourcing Forum [WayBackMachine] back in September.

  • I: An Introduction
    II: Innovative Quality
    III: Value Based Strategic Sourcing

CombineNet Communiqué III: Differences

Disclaimer: This blog, including this post, is not sponsored by CombineNet (acquired by Jaggaer). 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 discussed CombineNet’s post “The Make vs. Buy Dilemma” and indicated that although this was a very good post … 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 and indicated that there are problems that the platform optimization engines cannot solve.

We noted that Paul was on the right path with the make versus buy example. This was primarily because there were three options at different levels of complexity:

  • source individual components (make)
  • source assembled components (buy)
  • source sub-assembles

and each of these options could define a sophisticated model on its own.

Now we’ll shift from make vs. buy to logistics, and, specifically, transportation network design. Consider a buyer who needs to transport product from a supplier’s facility. The buyer often has at least three options: let the supplier transport the product from their facility to the buyer facility, let a third party transport the product from the supplier’s facility to the buyer’s facility, or have the supplier transport the product to a centralized distribution center and then have a preferred third party transport the product to the buyer’s facility. Sounds easy, doesn’t it? Sounds like something we could probably do by hand since there will only be a small number of legs associated with each lane, each with a small number of costs and besides shipping costs, we only need to consider tariffs.

Now consider a buyer who needs to transport product from fifty supplier facilities. Instead of having at least three choices, you now have at least one hundred and fifty choices. Now you might be thinking that you could simply solve for each supplier location separately, which you could easily do with most platform optimization engines, but this is not likely to be the optimal solution since (a) there will likely be discounts from suppliers and freight carriers if sufficient volume is allocated and (b) if intermediate DCs are used, then products from the same category can be bundled and better rates obtained.

Of course, you might note that although most sourcing models either assume that the supplier is providing freight or that a single carrier is being used, at least one provider will soon offer a model where you can simultaneously associate multiple freight options with each product and that an intermediate distribution center is just another option (with adjusted costs) and that such a model could, with the proper formulation, costs, and adjustments likely handle such a model. Well, yes and no. It could handle a basic representation, but we haven’t considered bundling concerns – not all products from a centralized DC can be shipped on the same truck, multiple freight brackets and discounts – which could greatly increase the computational complexity, and the fact that the best solution in the design of an international transportation network might involve using multiple levels of centralized distribution centers. Even though a platform optimization engine with a really good embedded model could probably handle bundling reasonably well by way of grouping and exclusion constraints and freight brackets and discounts by way of appropriately implemented discounts and penalties, the reality is that your standard embedded sourcing, or even logistical model, is not going to be able to fully handle a dynamic multi-level transportation network.

So does this mean that best of breed wins out? Not necessarily. You’re not going to redesign your transportation network for every sourcing event. In fact, you’re probably not going to make significant changes to your network more than every couple of years. In addition, most of the time your problems are not going to be anywhere near this level of complexity.

So does this mean that leading platform optimization engines are your best choice? Not necessarily. As I indicated in my first post, on a high value category, even a couple of extra points can mean millions of dollars.

The answer is that if you are a large company, you probably need to follow the advice of the SpendFool and use both – they are not mutually exclusive. Use your (super-charged) honda-powered platform optimization engine from your leading Software-as-a-Service provider for your average sourcing event, since this is probably your highest ROI, but bring in the big lear-powered jet for your high-value complex events with very large numbers of decisions that need to be made simultaneously, particularly those that involve network design or really complicated make versus buy decisions (where you are not just considering a seat but the sourcing of the BOM for an entire car – and once you know what you are going to make versus what you are going to buy, you can probably revert to the honda-powered platform for the individual sourcing events). (As for how often will you need the lear jet, that depends on your specific needs. If you’re not sure, I would start with the honda and see how far it takes you, or, better yet, bring in a third party with expertise in optimization and market offerings to help you decide.) In my view, there’s plenty of room in the market, and plenty of need, for both BoB and POE because, when it comes to optimization, there really is no one-size-fits-all and the best you are going to find is a one-size-fits-most for any category of problems that you have.

Is the story over? Not by a mile. This series is titled CombineNet Communiqué and the next part of this series* will discuss their (public) solution offerings now that we’ve illustrated a scenario where a platform optimization engine might not be enough.

* After a brief hiatus.

CombineNet Communiqué II: Comparisons

Disclaimer: This blog, including this post, is not sponsored by CombineNet (acquired by Jaggaer). 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.