Category Archives: Market Intelligence

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

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 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 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 titled “thinking of building your own e-sourcing system please don’t” 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.

Correlations are Good, Causations are Better, but Models are Best!

the maverick recently penned a great post on “Spurious Correlations, 150% Cost Savings and How to Justify Your Next Procurement Project” on Spend Matters that expounded upon the classic problem of second rate analysts, who didn’t read the classic post where the Brain gives Pinky a lesson in Statistics, using correlation to infer causation. If you listen to these analysts, you’ll find yourself in the same situation Roy Anderson was in when he was former MetLife CPO. Namely, the situation where if I added up all the promised savings from vendors and Aberdeen Reports, I’d be saving over 100% and suppliers would be paying me money! Not very likely, is it, but definitely the conclusion you’d draw if you stacked enough Aberdeen reports end to end!

After all, with enough data, you can find all sorts of near perfect correlations between (almost) completely unrelated data sets. For example, Pierre points out that if you go to tylervigen.com and check out the spurious correlations on the site, you’ll find out that there’s a near perfect correlation between

  • the number of people who drown after falling out of a fishing boat and the marriage rate in Kentucky (r=0.95),
  • the total number of computer science doctorates awarded in the US and the total revenue generated by arcades (r=0.99), and
  • the annual number of automotive suicides and the number of Japanese passenger cars sold in the US (r=0.94).

And while you might believe that computer science doctoral candidates spend all their free time in arcades, do you believe that buyers of Japanese passenger cars buy them to commit suicide or that somehow the marriage rate in Kentucky has something to do with the number of people who drown after falling out of a fishing boat? (I hope not!)

As Pierre notes, it’s important to have a good ROI model that really looks at the “R” and the “I” realistically. A model that uses ranges that allows you, as an analyst, to play around with assumptions and adjust the results based upon modifications to the assumptions. Procurement might want to be aggressive, but management might want to be conservative. Procurement might assume an abundance of supply, but Engineering, knowing that only a couple of suppliers are qualified to produce the refined raw materials needed, might want to assume a lack of supply based on the fact that these refined raw materials are becoming increasingly sought after. And so on.

Without a detailed model that captures all the cost components and the assumptions they are based on, Procurement can’t be realistic in its projections or its project requests. Analyst reports with benchmark data are a great starting point to identify where to look for savings, but the savings still have to be validated before a proposal is put forward.

Procurement is Doomed! Entombed! Marooned!

Apparently the recent Procurement Pub Debate, summarized in a recent post from Mr. Smith on “procurement pub debate arguments from the doomed side”, ended up with a win for the pro side. But the harsh reality, is that Procurement, at least as we know it, is doomed, ready to be entombed, and marooned on a desert Island. The pro side can be as blindly optimistic as they want to be, but it doesn’t change Procurement’s future.

As the supporters of the doomed side note, with modern web platforms:

  • it’s easy to buy what you want, when you want, for the price you want,
  • up-to-date market information lets you know how the price compares to other offerings on the market, and
  • peer reviews and opinion crowd sourcing lets you know how likely it is to fit your needs.

In other words, from an average employee’s point of view, who needs Procurement?

Furthermore,

  • inflation is back, so Procurement is not going to be able to negotiate significant cost reductions, or do much better than a market auction across a sufficient supply base,
  • risk is increasing, and organizations’ think it’s more important to focus on Risk Management in the Supply Base than Procurement, and
  • the market is becoming more digitized by the day and the organization would rather focus on expanding sales through the largest sales channel out there than worry about cost control as they see increased revenue as the quickest path to greater profit in a time of inflation.

So, despite the continued need of an average organization to insure that the organization can continue to acquire the supply necessary to meet customer demand, Procurement is increasingly being seen to be of secondary importance in an average organization and this trend is only going to continue. As it stands now, Procurement has peaked well below the level it should have reached. There is no future for Procurement. Unless, of course, it evolves. How? Stay tuned!