Monthly Archives: July 2015

Why You Should Not Build Your Own e-Sourcing System, Part IV Decision Optimization

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)!

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.


Complex MCNF Model.
And, compared to the model you need, this is the easy button. Still think you can do it in-house?

Why You Should Not Build Your Own e-Sourcing System, Part III e-Negotiation

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.

Why You Should Not Build Your Own e-Sourcing System, Part II Spend Analysis

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 why only those organizations with the core business of software development and delivery specializing in Sourcing or Source-to-Pay should even consider the possibility. We also agreed with Mr. Smith that any other organization that even considered the possibility was

  • 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 worse than the Smug cloud that ruined South Park because, of the 11 greatest supply chain disasters of all time, 8 were caused by technology failures and 6 by software platform failures!)

But we know this isn’t enough to convince the smuggest and most deluded from considering the notion. So we’re going to dive in and address some of the difficulties that will have be conquered, one primary module at a time, starting with spend analysis.

Even though every vendor and their dog thinks they can deliver a spend analysis system these days, the reality is that most vendors, including those with a lot of database and reporting experience, can’t. If vendors with significant experience in data(base) management and reporting can’t build a decent spend analysis system, what makes you think your organization can?

A spend analysis solution must be:

  • Powerful
    and support multiple spend analysis cubes, with derived and range dimensions, stored in public and private work spaces;
  • Flexible
    and support multiple categorization schemes, vendor and offering families, and user defined filters and drill downs;
  • Manageable
    with user defined data mappings and cleansing rules, hierarchical rule priorities, and easy enrichment;
  • Open
    and easy to get data in, out, and mapped; and
  • Informative
    with built-in report libraries, a powerful report builder, and an intuitive report customization feature.

This is not easy. Let’s start with flexibility. Most vendors probably have their goods and services mapped against UNSPSC, which your buyers of domestic goods are familiar with, but globally traded goods are probably mapped against HTS, which your tax division wants, your organization probably has its own GL codings that are required to keep Accounts Payable happy, and none of these categorization schemas are suitable for real spend analysis. As a result, you probably need to maintain at least four separate categorization schemas (for buyers, traders, accounts payable, and real analysts). If you think you can easily achieve this by slapping a report builder on top of an open source relational database, think again.

Let’s move on to power. One cube is never enough. If you’re an organization of reasonable size, doing year over year spend analysis over a reasonable time frame, you’re looking at millions, if not tens of millions of transactions. If you believe that you can dump all of that in one cube, and make sense of it, assuming you can design a system that can even build that cube without crashing (it’s big data, remember), you’re probably living in ImaginationLand (which is a very dangerous place to be).

We cannot forget about openness. The data you need will not live in the Spend Analysis system. It will live in the ERP (Enterprise Resource Planning). It will live in the Accounts Payable System. It will live in the TMS (Transportation Management System). It will live in the WIMS (Warehouse Inventory Management System). It will live in the VMS (Vendor Management System). And so on. Every one of these systems will have a different schema, it’s own data master, and, probably, duplicate vendor and product entries with various spellings of the name, locations, and so on.

Nor can we forget about manageability. It must be easy to map, normalize, clean, and map all of the data that is pushed into the system — by hand. AI doesn’t work. Every organization uses its own classification and shorthand, every department uses its own variations on the theme, and no system can figure out every error a human can make. All AI systems do is pile on rules until there are more collisions than correct exception mappings. That’s why a spend analysis system not only has to support multi-level rules, but help the user define appropriate multi-level rules and understand, when a transaction is mis-mapped, which rule did the mapping, what exception rule is required, and how broad that rule should be.

This leaves us with the need to extract useful information that can be used to identify real saving or value generation opportunities. No canned set of reports can do this. Standard reports can indicate where we can begin to look, but simply knowing a spend is high, or higher than market average, does not indicate why (locked in prices, bundled in services, quality guarantees, maverick spend, supplier overcharges) or what factors, if addressed would decrease spend.

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

Why You Should Not Build Your Own e-Sourcing System, Part I

In a recent post over on Spend Matters UK, Mr. Smith (who went to Washington, as per Buy, Buy, Buy, Once Bitten Twice Shy) asks you to please, please, please not build your own e-Sourcing system because, apparently, a few public sector organizations have this crazy idea that they can build their own and that it can compete with best-of-breed solutions on the market today.

Wow! Today’s best of breed systems have been built on fifteen-plus (15+) internet years of development, implementation, integration, and customer support experience by seasoned professionals who have had numerous bouts with weariness and wisdom. (And since we all know that internet years are measured in cat years, that’s really ninety-plus years of experience.) How could any average organization, especially in the public sector which is typically behind in technology and running on the B-Team (since unionized pay scales typically mean that they can’t afford the A-Team that commands private sector pay scales) really think they can come up with anything close?

In addition to Mr. Smith’s arguments that, especially in the public sector, you 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 (until the Smug reaches critical mass and puts us at risk of a disaster of epic proportions),

there are dozens of reasons NOT to build your own e-Sourcing system, or to even think that there is the slightest of chance you could build your own.

In addition to the standard reasons of:

  • Lack of Sourcing Domain Experience
  • Lack of Software Design Skills
  • Lack of A-Team Software Development Talent

in Sourcing, you also have to deal with the traditional software challenges of:

  • Big Data
  • Real-Time Requirements in a Distributed System
  • Variable Workflows

as well as a host of challenges in each of the main, traditional, areas of:

  • Spend Analysis
  • e-Negotiation (RFX & e-Auction)
  • Decision Optimization

which, to make it abundantly clear that no public and private organization should even remotely consider building their own e-Sourcing system, will be discussed in detail in the next three posts. Unless your core business is a software development and delivery organization specializing in Sourcing or Source-to-Pay, when it comes to building a modern e-Sourcing system to meet the needs of the organization and identify savings and value, just don’t do it. Put those Nike’s back in the closet and break out those Carolinas.

Spend Analysis Solution Selection: What to Look for in Software and Services

As the author penned in Spend Visibility: An Implementation Guide,

“Almost any attempt by an organization to analyze spending patterns is likely to be fruitful, especially if there hasn’t been a serious prior attempt. It is easy to find thousands of breathless testimonials about a particular product or method — independent of the quality of the product or method — because almost any product or method will find savings if a spend visibility initiative has never been launched before. In the land of the blind, the one-eyed man is king“.

This simple fact has confused end-user organizations and analysts for many years. In fact, it has convinced most spend visibility vendors (and most analysts) that spend visibility is a fundamentally simple process of mapping Accounts Payable spend, and then drilling for dollars.

But Nothing Could Be Further From The Truth!

What is not so obvious is that this initial burst of savings is short-lived; and that many of the “quick saves” that result are unsustainable.

Especially if an organization does not select the right solution in the beginning that will allow it to define, and implement, a strategy that will allow it to identify continued savings year-over-year after the initial burst of savings are captured.

However, there’s no reason for an organization not to select the right software or services, because, it’s easy to select the right solution once you are informed. If you don’t know where to start, the next Next Level Purchasing Association (NLPA) members only webinar on July 28, 2015 @ 8:30 am PDT, 11:30 am EDT, and 16:30 pm BST, will provide you with a starting point as you evaluate software and services providers.

Specifically, this webinar will focus on helping an organization identify:

  1. key features of a spend analysis platform,
  2. critical requirements for successful services, and
  3. what to look for in a full-service solution

so that the organization may achieve spend analysis success. In particular, the kind of success that will generate a year-over-year average savings of 10%+.

Space is limited, and only NLPA members will have the opportunity to attend this webinar hosted by the doctor of Sourcing Innovation, but Basic Membership is Free, so there’s no reason to miss out. Sign up today, and very shortly you’ll receive the notice of the upcoming webinar that will allow you to register for this very informative webinar.