Category Archives: Market Intelligence

Don’t Forget The Big Four Questions to Ask During Any Mega-Acquisition

Four years ago, during the last big M&A Frenzy, SI published a post on The First Four Questions to Ask During Any Mega-Acquisition, that is still just as relevant today as it was four years ago.

And while it was direct, it’s a good idea to be direct because sometimes you need to let the vendor know you’re not in the mood for any shenanigans and if they bought your former vendor for the sole purpose of playing such shenanigans with you, you’re ready to walk (and execute that change of control agreement in your contract tomorrow).

1. How will you screw us over on price?

As we said before, every acquisition brings with it the promise of economy of scale and lower price, but it typically takes years to understand and take advantage of platform overlap, redefine responsibilities and organizational boundaries, and identify staff re-assignments. And since, in the interim, change management experts, process consultants, and other resources need to be brought on board, overhead goes up and costs go up accordingly.

Or, the mega vendor bought your vendor just to retire its solution and migrate your vendor’s client base to its more expensive solution. Even if the solution is superior, it’s not necessarily superior for you and you don’t necessarily want it or the higher price tag.

2. How will we get screwed over on quality of service?

As we said before, the biggest fish in the combined company gets the best resources. And even if your current organization was a big fish in the old company, that does not mean your company will be a big fish in the merged company. Your company might just be a medium sized fish that gets the “B” Team, if it is lucky.

The fact of the matter is your current support team could be re-assigned or let go, the new team might not know anything about your solution, and without the current team your service levels might not be met. And make sure to point out the service levels the new vendor is committed to during the conversation so both parties can be on the same page about expectations from day one.

3. How will we get screwed out of innovation?

As per our last post, will the merged company continue to develop the platform your company is dependent on or will you remain locked in to a multi-year deal as the technology platform you bought withers and dies?

If the company is not going to support the platform, make sure that they are aware of the “full data export in standardized format” clause you included in the contract (and that you expect it to be honoured when the time comes) and that you expect full integration support so you can augment what you have where your platform is lacking.

4. What new and interesting ways will we get screwed in the future?

What additional layers of complexity and confusion will the new, combined, legal team try to weasel into the contract renewal and how will that bite your organization in its backside down the road?

Longer contractual terms? Non-disparagement clauses? No ability to discuss platform shortcomings when trying to find a best-of-breed solution to plug the holes. No ability to buy a non-vendor module when the vendor has one. And so on.

Not every mega-vendor is out to screw you, but make sure from day one that they’re not and that you are on the same page.

And yes, this is confrontational.  But sometimes you have to stand up for yourself.

How Much Unmanaged Tail Spend Should You Have?

It’s hard to say, but it should be a lot less than you do. In most organizations, “Tail Spend” is 20% to 40% of total spend that should be managed by Procurement, but isn’t for various reasons.

It includes a whack of spend that includes, but is not limited to:

  • one-time buys for a new hire
  • short term buys to replace supply lost to a supply chain disruption
  • temporary services
  • one-time buys for a trade-show or event
  • one-time MRO buys for replacement parts
  • “small” purchases for recurring orders under a certain volume or cost
  • etc.

But how much of there really deserves to be there? In theory, none of it, but in practice, some of it will always be, but it should be less and less as time goes on … and certainly a lot less than 30%.


Let’s start with the above:

  • one-time buys for a new hire should be a standard kit, which shouldn’t change more than once a year, and since volume can be projected based on hiring patterns, any significant spend is good fodder for, and should be, either a sourcing event or a pre-negotiated catalog-based buy
  • if proper sourcing was done for a critical part or item, then it should be easy to switch supply to the secondary supplier with only a minor disruption
  • temporary services that recur should also be on a master contract that should be strategically sourced
  • trade-shows and events costs tens of thousands these days; if you’re holding the event, you should have an RFI to select the most cost effective venue and most of the items you buy are in bulk and should be auctioned or 3-bids-and-a-buy sourced
  • replacement parts could be put on a master contract when you buy the equipment that you know will need replacement parts; you can define a max price and have the option to buy or go to a third-party if a third-party alternative comes along in the future and have the spend at least partially managed
  • just because volume is only a few thousand or spend is under 100K or 1M does not mean the category shouldn’t be sourced; if there’s 15% overspend that’s 15K that could be captured even in a simple event that might only cost 5K of resource time or 150K that could be captured only in 15K of resource time; and if 2/3 rds of that could be captured by automation (automated auctions, etc.), why not?
  • etc.

The reality is that you should not have very much tail spend.

Be Sure to Check Out the Prophet‘s Treatise on Industry vs. Technology Analysts

Before you fall for the advice of an industry analyst when making a critical long-term S2P technology platform selection. (Just today I heard about a company four [4] years in to a six [6] year Ariba implementation. That’s right! Six years! Wowzers. I’m not even sure Slow Poke Rodriguez could do an implementation that slow! But I digress … )

You see, as the prophet clearly states in Industry Analysts vs. Technology Analysts, industry analysts provided company/solution-level analysis and evaluation while technology analysts provide product/module- and architecture-level focus and comparative solution analysis. That’s a big difference.

In other words industry analysts tell you about the stability and market acceptance of the company while technology analysts tell you about the stability and market appropriateness of the technology, as well as the future outlook of its effectiveness post-implementation. [Just because your hardware is obsolete the minute you open the box doesn’t mean your software should be.]

Furthermore, what’s going to give you more reliable insight into a potential platform — information gathered by phone-based customer discussions, powerpoint presentations, and the odd customer survey — or — ground-up technology evaluation through interactive, in-depth, live product demonstrations focussed around granular RFI questions and important platform elements. If you trust an industry analyst, the best you’re going to get is second hand insight from happy customers where the blush is still on the rose and a review of the UI — from static screen captures in a powerpoint presentation. Not good. Not good at all.

For more insight on what makes a technology analyst, and just how rare they are, check out the prophet‘s article. FYI: as far as the doctor is concerned, the chances of encountering a true technology analyst is less than 100 to 1. Especially when you consider the educational and experiential background needed. (FYI: operations, MBA, psychology, history, etc. are NOT the right backgrounds to understand algorithms, software architectures, and modern technology at a deep technical level.)

Digging into the S2P Tech Foundations

In our post yesterday in what makes a good foundation for S2P Tech, we noted that if you wanted to have any hope of “future-proofing” your platform, then it was critical that you acquired a platform with the following four capabilities.

  • Configurable Workflow preferably with RPA support
  • Open / Extensible API that supports integration into and out of your platform
  • Dynamically Extensible Data Model that can be extended by the customer
  • Globalization Support for language, currency, data location, and more!

And we gave some preliminary reasons, but today we’re going to dig into some of the issues that really concern us.

  • Changing Governmental Regulations as governments introduce e-commerce, they are introducing e-invoicing requirements that can change your P2P flow (like requiring invoices to be sent through government servers or payments sent through government servers) and as governments introduce more regulatory compliance, the ability to report the complete origin story of a product, to the source of each raw material, is going to require more cross-platform and cross-enterprise data collection
  • Data Bifurcation as more and more platforms proliferate across the supply chain, the data will continue to proliferate as well … and without the ability to connect all the platforms, the data will exist in separate islands
  • Increasing Supply Chain Segmentation across more and more companies across more and more companies across more and more global users
  • Platform Obfuscation because the platform can’t keep up

These issues are the main drivers for the foundational platform requirements we outlined yesterday. Without

  • Configurable Workflow
    the platform won’t keep up with changing government regulations as it won’t be able to adapt the process
  • Open/Extensible API
    the platform won’t be able to manage the data bifurcation or prevent platform obfuscation as it won’t be able to adapt as required to manage the data tracking or integrate with new modules as they come online
  • Dynamically Extensible Data Model
    as future data requirements dictated by future regulations and future applications can’t be predicted in advance
  • Globalization Support
    as your next supplier could be in a different country, on a different continent, with a workforce whose primary language is one you haven’t dealt with yet … and that could be tomorrow!

Now, these aren’t the only issues we’re worried about, but they are big ones and they are guaranteed to materialize — soon (and before your contract comes up for renewal) — which is why we’re really concerned about them, and about insuring you get the right platform for the long term.

What is a Good Foundation for S2P Tech?

A couple of weeks ago in our posts on What Elements Should You Be Looking For In A Platform (Part I and Part II) we outlined some of the key platform requirements we are looking for in the new Spend Matters SolutionMap (where Sourcing, SXM, Analytics, and the vast majority of Common Platform requirements were defined by the doctor) to give you a hint, but it’s a lot to take in.

And might be more than you need today when you just need to solve a few major pain points and advance on your S2P journey, especially if you still don’t have any dedicated modern technology or are still on Procurement 1.0 when most of your peers are on Procurement 2.0 and the leaders are starting on the Procurement 3.0 journey. (As per another recent post, while there’s a lot of talk about Procurement 4.0, we won’t see it for another 8 years based on history. 1.0 started around 97 with FreeMarkets and the emergence of stand-alone players. 2.0 started around 2007 with the first mini-suites [S2C or P2P]. 3.0 began around 2017 with the rise of the true [mega] S2P suites and integration that allowed for the pursuit of value where the whole is greater than the parts. 4.0 will began around 2027 based on the rate of historical development.)

But it’s not necessarily more than you will need in time. Especially if you want to reach the height of Procurement 3.0 with your peers when it materializes later next decade.

But we do recognize that you won’t need it all today. So what do you really need to look for in the first go-round? Especially if you can’t have it all or can’t become enough of an expert to evaluate it all?

While the most important capabilities do depend on the specifics of the technology you’re buying and the problem you need to solve, there are a few general capabilities that need to be there regardless, and these * capabilities in particular must be there in every solution you buy if you want to have any hope of “future-proofing” your platform.

  • Configurable Workflow
    Preferably with RPA support. Let’s face it, whatever process you use today won’t be the process you use tomorrow, especially as you mature in your processes and best practices, the partners you work with change, and governmental regulations continue to change the way you have to report.
  • Open / Extensible API
    that supports both 3rd parties integrating with your platform and the development of interfaces to integrate with third party platforms through their open API. Your platform will never do everything, no matter how much you want it to. It’s software, not sorcery. So the ability to extend it with ease is critical.
  • Dynamically Extensible Data Model
    that you can do, not a third party or the provider. Because you never know every piece of data you’re going to need until you need it.
  • Globalization Support
    including the ability for a user to select their language and overrides, the organizing to define new currency exchanges and projections, and IT to define where the application instances are hosted and where the data is stored (which may need to be segmented for a global organization)

This is not to say that other technical requirements are not important, but that without these, the life expectancy of your platform is limited, to say the least.