Monthly Archives: December 2018

Domo Arigato, Mr. Roboto Patoron!

A decade ago, Sourcing Innovation published a piece on how Every Check Has a Cost which echoed a point made by Paul Graham that one of the big differences between big companies and startups is that big companies tend to have developed procedures to protect themselves against mistakes while a startup walks like a toddler, bashing into things and falling over all the time and, as a result, over time, gradually puts in place rules and procedures and associated checks and balances to prevent it from falling over itself, especially when the fall results in a mini-disaster (such as a contracted supplier going bankrupt).

Thus, as the company grows, it will invariably accumulate more checks, either as responses to disasters or as a result of hiring people from bigger companies who bring more checks with them for protecting against disasters which have not yet happened (and which may never happen).

But this isn’t necessarily a good thing. Unnecessary checks cost time to document,, implement, support, and maintain, especially if it’s for a situation unlikely to happen or a situation that, when it happens, will cost the company less than the cost of the check and balance it has to go through day in and day out. For example, like checking the references and solvency of an office supplies, furniture, or an off-the-shelf electronics provider. Who cares. One goes out of business, 10 more down the street.

Or mandating committee review and on-site demos for what should be a $10,000 piece of software. As described in our classic piece, the more expensive you make a sale, the more expensive that sale is going to be. If it costs a vendor $30,000 to sell you what should be a $10,000 piece of software, they’re going to charge you $50,000 — $10,000 for the software, $30,000 for the cost of sale, $5,000 for the additional support they expect, and an extra $5,000 to make up for the commissions they are losing spend all that time with you.

Similarly, it’s costly to have a manager check every purchase over $250 made by an employee just because someone decided that should be an arbitrary threshold.

Ten years ago we said review all your checks and balances and get rid of the ones that don’t make any sense or cost you more than they would save in the worst case.

But now we are saying don’t just get rid of those, get rid of ANY manual check that doesn’t add value the majority of the time — and replace it with an automated system check backed by RPA (robotic process automation) driven AI (assisted intelligence) that determines whether or not there is enough risk to warrant a manual check.

With good risk models, good training data (common situations when a “mandatory” check resulted in an approval, common situations where a “mandatory” check resulted in a denial, and exceptional situations where a “mandatory” check resulted in a request for more information by the approver), good budget/spend data, contract/catalog data (and preferred suppliers), and organizational hierarchies (with well defined roles), a system can not only easily map into (definite) yes / (definite) no / more information / forced manual review buckets and improve its knowledge of typical organizational purchase and approval patterns over time and reduce the number of manual checks to those situations that are truly risky or truly unclear. Which is, to be precise, the only time a check should be applied. (And over time, it will be able to suggest better and better check rules that help an organization understand what, and only what, it should truly be checking.)

And when you implement the right software to automate these mostly unnecessary checks (on the road to eliminating them), just like you can slowly take the foam off the table corners and the training wheels off the bike, you will grow up as a purchasing organization and, after finally finding a proper use for RPA and AI, you will say:

Domo Arigato, Mr. Roboto Patoron!

Be Wary of Marketplace Solutions for Procurement

Spend Matters is running a series on Marketplaces (Part 1 and Part II) because, sadly, they are making a comeback. Why does the doctor say sadly? Because Marketplaces were designed by (specific) point-of-sale sellers to serve end buyers. They were never designed as full-fledged solutions for Procurement Professionals.

And to understand that, we have to step back and understand what a marketplace is. Traditionally, a marketplace has been a physical area where a number of individuals with goods to sell gather together to present those goods to whatever buyers happen to wander through. And these goods can range from food items and bobbles through clothing and accessories to high end electronics and even personal transportation devices or animals and, literally, everything in between. And payment can be cash, credit, promissory notes, or other goods in trade. And it has been like this for thousands of years. All over the world. Persistent, temporary (one day a week), and transient markets still exist in every county to this day (although my American friends like to call them swap-meets and flea markets, for reasons that perplex those of us with more British and French sensibilities).

Now think about translating this to the online world. You’d essentially be putting together an e-Bay where anyone can sell anything to anyone, but in addition to having to support payment in every online currency imaginable, you’d also have to support promissory notes or offline trading of merchandise, and, of course, implement mechanisms to track that. Does any marketplace support this? No. But this is not the real problem you need to be wary of Marketplaces as a Procurement professional.

The real reason is that they are NOT designed as Procurement solutions. A Procurement solution controls the universe of what’s available, at what price, to who, and when. This is essentially an integrated managed catalog solution. Now it’s true that modern Marketplaces are beginning to support this capability and allowing Procurement organizations who license an instance of the marketplace to restrict the catalogs, items, and have approval over the items and prices before they go into the catalog, but this isn’t really a marketplace, as sellers have limited control, no ability to negotiate, and no ability to provide better offers dynamically. So while it is more of a Procurement solution, it’s not really a marketplace.

Then there’s the issue that Procurement strives to use existing inventory and buy off of contracts, not from marketplace items, so you need a solution that will not allow a non-contract item to be bought when a contract one will do. Furthermore, you also need to buy non-catalog items and services and track those too, and will the marketplace do that?

And then you probably have the issue that you need to make different catalogs and items available in different locations if you are global, and restrict them to those specific solutions — so in addition to buying rules (no off contract items when there is an on-contract one and budget enforcement), you also need multiple view restrictions (or virtual marketplaces) in that single instance.

And then there’s the fact that you don’t typically pay item by item, you typically pay in bulk or monthly, as per a contract, or pay through another system. So you need more advanced accounting and payment tracking than will be found in a typical marketplace. And so on.

So, dear Procurement, be wary of a vendor that offers you a Marketplace solution for your maverick-spend or related Spend Management woes. Most of the solutions, which were really built for B2C, are not yet where you need them to be for B2B.

One Hundred Years Ago Today …

The UK began its effort to leave the dark ages with the first general election where women were permitted to vote and the first woman was elected to the Commons.

If only it would finish its exit of the dark ages in Procurement, which, sadly, in many organizations is still controlled by white males in their fifties.

While the doctor does not want to be stereotypical, he does want to be realistic — Procurement is simply better when there are multiple perspectives (and skills) at the table. And without the second gender, you’re clearly leaving half the perspective and skill off of the table (and that is simple, irrefutable, math).

M&A Mania – Will it Ever End?

As per our posts on Sourcing Innovation earlier this year, the M&A Mania has been in full swing for the past couple of years, and as per the acquisition news that came out Monday, it seems the mania hasn’t abated. But will it abate in 2019?

We hope so.

Sometimes M&A makes sense, but sometimes it’s too much too fast. The theory behind M&A is that it’s easier for the customer to have all the related solutions under one vendor’s roof than three, four or six when they need to build an end-to-end S2P support solution than to have to deal with six vendors when they have integration issues, support issues, or system errors.

It’s a great theory, but it doesn’t work any better in practice if all a vendor is doing is buying up smaller vendors to sell them under one roof. If all of the development teams are separate, all of the product management teams are separate, and all of the support teams are separate, you’re still trying to sync with six different groups in order to resolve integration issues, support issues, or system errors. What difference is it if they are under one roof, three roofs, or six? From your perspective, none at all!

The reality is that it doesn’t help you as a Procurement Practitioner at all if the solutions aren’t integrated, and we don’t just mean data-based end-point integration — where it’s easy to push data out of one tool and pull it into the next. It has to be a deeper integration that integrates process and workflow. And that type of integration doesn’t happen fast. It takes many months in the best of cases, and many years in the worst.

So when a vendor goes on a buying spree, without forethought as to how it’s going to integrate all those solutions into a cohesive platform in a reasonable amount of time, it’s just bringing the integration and support nightmare for its clients under one roof, and not adding any value.

The best M&A is when a company buys a company with a great complementary solution and then steps back, takes the time to get the teams fully integrated and the solution integrated at least at the process level with its solution (not necessarily deep workflow configuration but more than just end-point data integration), and only then thinks about the next acquisition.

Right now the big players have made so many acquisitions that the doctor thinks they are all at full capacity to manage integrations, and in a couple of cases, maybe beyond. So he certainly hopes that the M&A Mania winds down, at least until there is settling across the space.

Plus, any company that acquires too many solutions too rapidly puts itself at risk of acquisition by someone bigger still. Just look at what happened to CA Technologies — the Acquirer became the acquired … by a hardware company! The last thing we want is a big S2P play to be acquired by a big hardware or generic platform vendor that doesn’t understand the space.

Don’t Throw Away That Old Spend Cube, Spendata Will Recover It For You!

And if you act fast, to prove they can do it, they’ll recover it for free. All you have to do is provide them 12 months of data from your old cube. More on this at the end of the post, but first …

As per our article yesterday, many organizations, often through no fault of their own, end up with a spend cube (filled with their IP) that they spent a lot of money to acquire, but which they can’t maintain — either because it was built by experts using a third party system, built by experts who did manual re-mappings with no explanations (or repeatable rules), built by a vendor that used AI “pattern matching”, or built by a vendor that ceased supporting the cube (and simply provided it to the company without any of the rules that were used to accomplish the categorization).

Such a cube is unusable, and unless maintainable rules can be recovered, it’s money down the drain. But, as per yesterday’s post, it doesn’t have to be.

  1. It’s possible to build the vast majority of spend cubes on the largest data sets in a matter of days using the classic secret sauce described in our last post.
  2. All mappings leave evidence, and that evidence can be used to reconstruct a new and maintainable rules set.

Spendata has figured out that it’s possible to reverse engineer old spend cubes by deriving new rules by inference, based on the existing mappings. This is possible because the majority of such (lost) cubes are indirect spending cubes (where most organizations find the most bang for their buck). These can often be mapped to 95% or better accuracy using just Vendor and General Ledger code, with outliers mapped (if necessary) by Item Description.

And it doesn’t matter how your original cube was mapped — keyword matching algorithms, the deep neural net de jour, or by Elves from Rivendell — because supplier, GL-code, and supplier and GL-code patterns can be deduced from the original mappings, and then poked at with intelligent (AI) algorithms to find and address the exceptions.

In fact, Spendata is so confident of its reverse-engineering that — for at least the first 10 volunteers who contact them (at the number here) — they’ll take your old spend cube and use Spendata (at no charge) to reverse-engineer its rules, returning a cube to you so you can see the results (as well as the reverse-engineering algorithms that were applied) and the sequenced plain-English rules that can be used (and modified) to maintain it going forward.

Note that there’s a big advantage to rules-based mapping that is not found in black-box AI solutions — you can easily see any new items at refresh time that are unmapped, and define rules to handle them. This has two advantages.

  1. You can see if you are spending where you are supposed to be spending against your contracts and policies.
  2. You can see how fast new suppliers, products, and human errors are entering your system. [And you can speak with the offending personnel in the latter case to prevent these errors in the future.]

And mapping this new data is not a significant effort. If you think about it, how many new suppliers with meaningful spending does your company add in one month? Is it five? Ten? Twenty? It’s not many, and you should know who they are. The same goes for products. Chances are you’ll be able to keep up with the necessary rule additions and changes in an hour a month. That’s not much effort for having a spend cube you can fully understand and manage and that helps you identify what’s new or changed month over month.

If you’re interested in doing this, the doctor is interested in the results, so let SI know what happens and we’ll publish a follow-up article.

And if you take Spendata up on the offer:

  1. take a view of the old cube with 13 consecutive months of data
  2. give Spendata the first 12 consecutive months, and get the new cube back
  3. then add the 13th month of data to the new cube to see what the reverse-engineered rules miss.

You will likely find that the new rules catch almost all of the month 13 spending, showing that the maintenance effort is minimal, and that you can update the spend cube yourself without dependence on a third party.