Monthly Archives: February 2018

Why’s it all about the platform when it should be all about the power?

As we all know, the last year has been all about the M&A frenzy as the big try to get bigger by gobbling up any player with any modules they don’t have or any player with customer bases in a region they aren’t in, and doing so in a manner that doesn’t always make sense to analysts. As the doctor indicated in his post last month on Surviving a M&A: The Customer Perspective, acquisitions should lead to synergies and do so from a customer, solution, and/or operations perspective.

Preferably, an M&A should culminate in synergies of all kinds. Why? An M&A that doesn’t synch on an operations perspective doesn’t reduce overhead costs, and that means you don’t get any economics of scale, which is something all the traditional textbooks say is the first thing you should look for. If there are no customer synergies, then there are no cross-sell or up-sell opportunities, and that’s typically the next thing the textbooks say you should look for.

And, especially in our space, if there are no solution synergies, then a lot of money is wasted, as the point of the acquisition should be to build a better, or at least, a more complete platform. Otherwise, one company is paying a lot of money for something that will just get tossed in the bit bucket because supporting non-synergistic platforms gets too expensive too fast and the non-synergistic pieces will get sunsetted faster than the sun in Alert, Nunavut in late February.

So why doesn’t the recent M&A Frenzy make a lot of sense to the doctor? Not only has a fair amount of it been lacking in obvious synergies, but a lot of it has been to simply expand platform offerings, without focussing on the power of the solutions being bought or how the acquisitions will help the platform.

The past year has seen the acquisitions of traditional catalog providers and leading spend analytics and optimization providers. In some cases, the power is limited … and in other cases the power is limitless. But in the majority of cases, to date, the integration has been pretty limited. It’s been more or less just plugging a module into a whole without an analysis of not only the power of the solution but how the solution could enhance the rest of the platform in new and innovative ways.

For example, let’s take optimization. Just plugging it into a S2P platform is pretty good, especially given the dearth of optimization solutions on the market today, but is it great? How do you take an offering to market that the market will understand is better than the other leading vendors which have optimization? After all, if it’s just the same process — construct RFI, send it out, get data, pump into model, get result, make award, push into contract management — what’s better from the perspective of an average Joe? But if you have an advanced Procurement solution, can plug it into the catalog and analyze not only the cost, but the total cost if the order can be piggy-backed on other orders from on-contract suppliers who can add it to forthcoming shipments, give you contract-level discounts, etc. that’s value. And if you are looking to assemble a standard kit for a new hire, can run all the various combinations and determine which variant is best over a given time frame, that’s value too.

And a catalog solution can enhance sourcing if it supports punch-out and integrated search and anytime a buyer is considering sending out an RFI, can be integrated to identify current market pricing and source suppliers from the data within the catalog and in punch-out sites. If the buyer compares this pricing to current pricing, this can let the buyer know if going to market will likely be good (if market pricing is significantly less than current organizational pricing) or bad (if market pricing is significantly higher and the best option is just to extend the contract with the incumbent if pricing will stay about the same).

At the end of the day, Procurement is about generating value — and if the platform addition doesn’t generate additional value, what’s the point?

BFC or IND? Which is better? And Why Does Procurement Care?

If you want to increase market share, the standard strategies employed by marketing typically fall into the:

  • BFC: Better, Faster, Cheaper bucket and the
  • INP: Innovative New Product bucket

In the first case of BFC, you pick a product out there (which could be one of your own) that people like, and figure out how to make it better, faster, cheaper and sell them a must-have upgrade.

In the second case of IND, you pick a product (like a cell phone) and figure out how to revolutionize it (like a smart phone) or how to add a feature (like facial recognition) that no one has yet and make it a must have.

In the first case, if the company makes a version of the product, Engineering picks the preferred supplier and starts a collaboration to try and take cost out of production while adding quality and features. In the latter, they undertake research into current products, production processes, and material requirements and try to find a design and a production process that can lower costs and improve quality or attractiveness to the market.

In the second case, a brainstorm is done to figure out what the market would want that might be possible, R&D is called in to see if it can be made a reality, Engineering is called in to get some production data for costing, research is done to see if the market will bear it, and a decision is made.

Sounds like it’s all Marketing, R&D, and Engineering — so why do you care? Because if the stakeholders involved decide something can be produced at cost X, they are going to expect you to beat that cost, whether or not its reasonable.

Moreover, when they have the option of BFC vs INP, they will often choose based upon their market projections of profit which comes down to their views on cost. So if you can’t meet the cost, the organization will lose and will be blamed. But more importantly, they can overestimate one cost and make the wrong choice, where you could win big, or, even worse, they can overestimate the supply market when there are really only two or three suppliers, all at capacity, and all without the time to do the necessary production line upgrades. Not only do you have a cost issue in the latter situation, but you also have a supply base issue.

Procurement needs to be at the table as part of all BFC and/or INP product considerations, especially when pricing and projections of market AND supply market are being made. Only Procurement can bring the proper knowledge, calculations, and projections for the company to make the right bottom line decision. And while Procurement will likely want to, and probably should, stay out of discussions of what the market will want, what R&D can do, etc., it can’t stay out of the cost and projection discussions. Otherwise, it’s the organization that will get burned in the end — even though it’s not at fault.

How Do You Identify a Truly Stellar Supplier

Assuming one exists, how will you know one when you find one?

Five years ago, we asked how do you identify a stellar supplier? One way, as we pointed out, was to find a supplier that actively self manages. A supplier which measures, tracks, and even reports its own performance against SLAs and KPIs, accepts — and even helps to identify — the corrective actions it needs to take, actively works to not only meet expectations but exceed them, and communicates as soon as something happens that could threaten a KPI, SLA, commitment, or expectation.

Then, if you find multiple candidates, find a supplier that wants to collaborate. Find a supplier who will work with you to jointly identify opportunities for efficiency improvements and cost reductions and help keep costs down for all. This is even better. But is it as good as it gets?

No. You want a supplier who will open its books, at least so far as what it’s costs are that affect you. And what you can do to bring those costs down. That dives into its overhead costs and lets you know if energy, manpower, or cost of capital (if it needs to borrow to meet daily cash flow needs until you pay for finish goods 30 days after shipment) and what it could use from you to lower costs — such as faster payments, help with de-regulated energy negotiations, or production line improvements and lean initiatives to keep manpower costs steady. And into raw material costs, and where it needs more volume or negotiating leverage to keep costs down.

And then a supplier that helps you identify your tier 2 supply chain risks. What good does it do for a buyer to know it’s tier 1 risks when most disruptions begin further down the chain — and when the only way to possibly recover against them is to get early warning. A truly stellar supplier also works with you to put in place systems that will allow the supplier to report on potential disruptions in its supply chain (when raw materials don’t show up in time, when the quality of components it gets goes down, etc.) so you know when trouble might be brewing and, if your supplier needs help, when you can help it to prevent troubles later.

A truly stellar supplier doesn’t hide its risks and costs from you — it shares the and allows you to work with it hand-in-hand in lean efforts to create truly stellar supply chains.

Keep Your Self Driving Car. I’ll Still Choose Good Ol’ Alfred Every Day of the Week!

As the doctor pointed out back in 2014, calling #badwolf on self-driving cars is well-founded. Just last month we had more accidents involving self-driving cars (from Tesla and GM) where a Tesla “ploughed into the rear” of a fire engine in Culver City and where a GM car collided with a motorcycle in San Francisco.

And when you get injured, as in the case of the motorcycle driver, who do you sue? If the car is self-driving, then there’s no driver, just source code. Source code isn’t an entity, so all you’re left with is suing GM, as the cyclist whose motorbike was hit with the GM car is doing (as per this article in Engadget and this article in Popular Science). But is it the company? When technically it’s the software — written by who knows how many employees who used who knows what from open source to speed up development, which was again contributed to by who knows how many authors?

But you can’t sue software, it’s not an entity, at least not a legal one, and that can’t happen at least until we grant it intelligence … and the right to own assets. So, it’s GM, but are they liable under the law? And, if not, how can the individual in the vehicle, not driving, be held liable?

And what happens if the “AI” becomes artificially intelligent and decides to “improve its own code” or the code gets co-mingled with the company’s “sentiment analysis” technology and all of a sudden gains a strong “dislike” for the self driving cars of the competition and, using it’s limited action-reaction processing algorithms, determines the best course of action is to “crash into the competition cars”. What then? We’re driving cars with a “kill” switch we have no control over!

And we’ll never know if there is one! With 99M+ lines of code in an average self-driving car OS, how would you ever find the kill switch until it triggered? And if it triggered en-masse, all of a sudden we have Maximum Overdrive on a global scale! Are you ready for that? the doctor is not!