Author Archives: thedoctor

The Top Barriers/Roadblocks to Success/Challenges in Procurement

Each and every year, and even throughout any given year, there are a flurry of executive or specific supply chain and procurement focused surveys and papers that are published by the big consultancies, analyst firms, and vendors. Their goal, accompanied by an often repeatable theme, is to inform readers as to existing and future procurement and supply chain challenges and what the most successful companies are doing to overcome such challenges.

Depending on the origination of such surveys, that being management consulting, systems integration or technology providers, there are usually technology enablement themes and perspectives with the technology of the day in the spotlight. As a result, these surveys and papers include the inevitable themes of the growing gap between industry leaders and laggards and the need to close such gaps.

And, of course, a closing summary that says the reader needs the technology of the day or the consulting services around the technology of the day that, lo and behold, no one can provide better than the publisher of the survey and the report on the survey.

These studies keep coming year after year because the core issues are still not being adequately addressed by the systems and services your organization is using. Since these core issues keep persisting year after year — sometimes exploding with a vengeance when an unexpected natural disaster or pandemic strikes, a war breaks out, or a fan of the Gilded Age believes that tariffs are the cure-all and starts global trade wars — the big consultancies, analyst firms, and vendors can keep writing about them.

So, we’re going to address these core issues that underlie your problems, explain what they are, help you understand why they keep coming back, and thereby give you some of the foundations to start attacking them. In each of the 10 articles that follow we’ll outline the (history of) the core problem, help you understand why it continues to persist, and give you at least one key insight to help you transition to the right mindset to start dealing with it appropriately.

As indicated in our last post, there are 10 barriers to success that keep cropping up in the surveys and studies again and again (and did so multiple times in the last 5 years). These are:

  • Siloed Ways of Working/Outdated/Inefficient Processes ([00], [03], [04], [10], and [16])
  • Category/Market Complexity/Saturation/Volatility ([00], [03], [09], [10], and [14])
  • Lack of Funding/Budget ([00], [03], [10], [16], and [20])
  • Org and/or Tech Execution Support Capability ([00], [10], [13], and [16])
  • Quality/Supplier Reliability/Continuity ([02], [09], [10], and [19])
  • Lead Times/Supplier/Carrier Issues &
    Supply Chain Visibility/Network Complexity ([02], [09], [13], and [14])
  • Data Integration/Management/Analytics ([03], [10], [13], and [14])
  • Talent Gap ([00], [03], [06], and [10])
  • Competing Priorities/overcommitment/buy-in ([00], [10], and [20])
  • Insufficient Business-Wide Support/Resistance to Change ([00], [03], and [10])

(See our last post on You Don’t Need To Read Another State of Procurement Study for the Next 5 Years! for the references and links to the 21 surveys, studies, and papers that were re-read and combed through in detail.)

These are the 10 we’ll discuss in upcoming posts! Stay tuned.

You Don’t Need To Read Another State of Procurement Study for the Next 5 Years!

Earlier this year, Deloitte released their annual Global CPO Survey which was again done in collaboration with Pierre Mitchell of Spend Matters which included, among other things:

  • Top Barriers/Roadblocks to Success/Challenges
  • Major Procurement Risks with High or Moderate Impact
  • Primary Concerns/Strategic Priorities for Procurement Leaders
  • Significant Skill Competency Gaps/Support Needs

just like every Deloitte CPO Study that came before and, moreover, every Hackett (which now owns Spend Matters), Kearney, CapGemini, E&Y, PwC, Everest, etc. study that has come before for at least the past five years. I know, because:

  1. I’ve been reading them.
  2. I went back through 15 of them in detail and a few other related papers published in the same timeframe and pulled out each of these for all of them.

Now guess what? They’re all more-or-less the same with only about 20% to 30% divergence. With respect to the 20 papers I went back through in detail, for the Deloitte

  • top barriers, of the 10 quoted in 2 or more of the papers, 7 are in the Deloitte study,
  • major procurement risks, of the 7 quoted in 2 or more of the papers, 5 are in the Deloitte study, and
  • primary concerns, of the 13 quoted in 2 or more of the papers, 8 are in the Deloitte study.

Moreover, if we were to abstract the barriers, risks, and concerns one level and start looking at the underlying systems or processes that would need to be addressed, the similarities would be even more significant.

More importantly, they aren’t changing much year to year, and aren’t going to change much for the next decade at least.

A year ago I penned a post where I pointed out that before you get all excited to learn about trends for fall conference season, with the exception of:

  • Gen-AI being the new fluffy magic cloud
  • Fake-take (sorry, intake) being the new dangerous and dysfunctional dashboards

the majority of trends that have been discussed for the past year are the same trends that were discussed ten years ago (and I have the blog history to prove it, especially since I didn’t purge over half of my blog on a site upgrade and migration 2 years ago).

This is because the core purpose, and thus the core priorities, challenges, and risks, of Procurement haven’t changed in decades. The systems have evolved, the processes have become more complicated, and the global supply challenges haven’t been this bad since the nineties, but the core HAS NOT changed (and, to be fair, has NOT changed since the first manual was published in 1887 and has NOT changed much since cross-continental trade began thousands [and thousands] of years ago).

Which means we don’t need any more annual surveys on these issues (every 5 years would be more than enough, and even then you might find that the only movement is related to the hot tech of today vs. the hot tech 5 years ago, as I did when I did the exercise last year).

However, to make abundantly clear why these barriers, risks, priorities, and skillsets, are not going to change, we’re going to explore them in the months ahead so you never have to read the exact same report all over again (at least for five years).

We hope you enjoy.

P.S. These are the 21 papers that I reviewed and may be referenced in this ongoing series. There are many more examples over the last 5 years if you look, but it’s really hard to keep reading essentially the same content, especially after you’ve done so 21 times!

Jeez. How do I select a vendor NOT likely to screw me over? (Calculating Relative Corpoate Debt [RCD])

i.e. The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part IV)

We know what you’re thinking.

After reading your three-part exposé (group) on the most important clause in your (Procure) Tech (SaaS) contract, I’m pretty sure I’m going to be screwed to some extent on a significant number of my SaaS contracts. How can I minimize the chances of this happening?

Do your diligence and limit your pool to vendors with the right vendor profile.

This means you have to go beyond a deep analysis of:

  • the product, and does it do what you need
  • the platform, and will it support growth
  • the services capability, and can they implement and integrate the system without resorting to third parties
  • the consulting/training capability, and can they provide basic help when you need it

which is where most people stop. And then you have to go beyond Legal and Risk Management’s staples of

  • legal status
  • financial stability
  • legal jeopardy
  • brand sentiment

because that’s not enough either! All that does is tell you the likelihood of being screwed over today, it does nothing to tell you the likelihood of being screwed in the next 6 months, 18 months, or 3 (to 5) years, which will be typical contract duration for a SaaS app of moderate complexity and significant importance.

So how do you figure that out? Well, there’s no golden rule or single predictor guaranteed to always work, as anything can happen to the best and worst of companies over time, but there is one highly correlated factor to SaaS company success you need to compute because, when it’s low, chances of crisis (that lead to your company getting screwed) are high.

What is that factor?

Relative Corporate Debt*

In a (PE/VC/etc.) investor funded company, where msi = “months since investment”, this is defined as:


1.4^((60-msi)/12) * revenue
————————————
investment valuation

In a private company, this is defined as:


annual revenue
———————
annual operating cost
 

If this is less than 1, you’re taking a risk!

In the second case, for a private company that isn’t yet profitable, unless you can plot a trend line over the past year and a half on a quarterly basis that sees the vendor reaching profitability within a year and a half, you’re taking a big risk as loans and founder savings tend to only take a company so far. (And if the ratio is greater than 1, the company is stable and has a good chance of staying that way if it has a solid solution that improves annually.)

In the first case of an investor funded company, you need to understand that a provider that just raised 7, 10, 15X its current annual revenue is not a guaranteed winner. In fact, it’s not even guaranteed to be stable in the long term! One needs to remember that most investors expect a return within 5 years, and many of the bigger firms will expect a return within 3 years (and will slash operating expenses, i.e. headcount, to get it, especially if they bought it to flip it to a bigger investor down the line). This means that the investors who invested amounts at these ridiculous valuations are hoping it’s the next unicorn and expecting exponential growth.

But exponential growth is very hard to obtain!

First of all, exponential growth either requires creating a whole new market, which takes time, or displacing a lot of established competitors, which also takes time … especially if the majority of customers are still locked into those competitors for years. In the first case, it also requires businesses creating whole new budgets and then taking money away from other functions, which takes time. Plus, in both cases, it requires the company to create a broad and deep platform capable of displacing mature providers who might have spent a decade or more on their products, and that also takes time. Just like 9 women cannot have a baby in 1 month, there is a limit as to how fast even the best teams can create broad and deep software that is better than the last generation, scalable, secure, and reliable. (Given that [almost] half [or more] of AI code has been found to contain [significant] security flaws in multiple studies, AI code is not going to accelerate development as much as the AI players want you to believe. Sometimes it slows things down!)

Moreover, even once the market is ready (as a result of existing contracts expiring, millions of dollars spent on marketing to normalize the new player, millions more on development that might be enough to displace customers where the existing solution was bloatware), there is not only the resistance to change to overcome, but the reality that a provider can only take on so many customers so fast and support them adequately.

Despite what the investors want to believe, and what the C-Suite might promise, most back-office installs aren’t just “flipping a switch” and require a lot of time and effort by the provider to load data, integrate with the key back-end systems, configure the systems to the client’s needs, train the client’s personnel, monitor the system and usage during the first few months to make sure everything goes according to plan, etc. That means a provider can only handle so many new customers a month. Moreover, you can’t just add people at will to handle support needs because those support people will need to be trained and that will also require time from existing personnel, which will then have less time to support the clients.

The harsh reality is that, in IT and SaaS, most companies CANNOT grow at more than 40% year-over-year and maintain aggressive platform growth and leading customer support. Any growth beyond that leads to development slowdowns, significant interruptions (to complete failures) in customer support, and other missteps.

Doing the MATH, this means that a company can’t realistically grow more than 5X in 5 years without making some sacrifices along the way, which, in IT/SaaS, typically means SACRIFICING YOU! And that’s what the formula captures! Realistic growth expectations against current revenue and whether it will hit investor expectations in time!

So this means that if the provider accepts funding at a valuation that is significantly more than 5X, their chances of meeting the investor expectations are not good (unless, of course, they significantly raise prices on the renewal, which will also screw you), and that means your chances of great support will steadily decrease as time goes on and your chances of being one of the customers that eventually gets screwed (even if there was no ill intent or false promises when they signed you) increases.

Moreover, if the provider accepts funding at a valuation of more than 7X, their chances of meeting the investor expectations are really (really) bad. If they can more-or-less double functionality and increase the average annual sale price by about 50% within a year or so, then they can make 7X, but beyond that, there’s usually no way to make the math work in a manner that can be expected to satisfy the investors!

So do the math first. If the investment multiple is too high, or the company too far from profitability, it doesn’t matter how good it, or the solution, looks. If you want stability in your purchase, you need to walk away. If the situation changes in a couple of years, there’s no reason you can’t look at them again if the provider you go with ends up not doing everything you wanted. After all, if you ensured the contract had the IT’S MY DATA clause, and tested it rather promptly after implementation, nothing stops you from switching.

And this clearly demonstrates yet again why the IT’S MY DATA clause is the most important clause and any vendor who can’t, or won’t, guarantee full access to all of your data all of the time is not one you should go with.

Furthermore, and this is the kicker, chances are good that any vendor who is confident not only in their solution but in their ability to keep improving their solution will happily guarantee this. And who’d you rather? A vendor that feels the need to lock you in to a proprietary solution that holds your data hostage in order to keep you as a customer or a vendor that is so confident you’ll stay with their solution after mastering it that they give you the access codes to their competitor’s suite? I know who I’d rather!

* (which is not the same as relative debt in estate law by the way!)

The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part III)

In Part I we told you that

  • while you might think there is no single most important clause as there are a lot of important clauses, especially if you ask around,
  • liability or penalty clauses are quite important, or that
  • termination matters

the reality is that

  • there is a most important clause, and it’s not what you think,
  • liability is worthless if collecting costs more than you get, and
  • you can’t terminate if you don’t have another choice!

We also told you that, after signing the contract, there is a good chance you will be screwed to some extent, whether or not the provider intends it. Between:

  • psychopathic salespeople who will promise anything to sign the deal (and off to their next job before the reckoning comes),
  • investor owners that are going to limit/cut support when unreachable sales targets are not hit, forcing the C-Suite to pick and choose who to screw over,
  • the fact that your vendor will likely be acquired (because if it’s not, it’s likely to go out of business since there are almost 10 times the number of vendors we need in ProcureTech), and
  • the fact that a struggling vendor with the best of intentions will take on too much and be forced to leave some customers high and dry

the chances are, like it or NOT, that you are going to be screwed. (And possibly doomed and entombed by the proprietary software using proprietary data formats that you probably shouldn’t have bought.)

This means there is one clause that overrules them all:

IT’S MY DATA … AND I CAN, AND WILL, GET IT ANYTIME I WANT IT!

Then we made it clear in Part II that while you might think it’s your data, you’ll think again when something happens 6 to 18 months down the road and you need to get it out. Chances are that, unless the developers give you a full database dump (in an underlying schema you have no documentation for, using encryption you have to acquire third party software for), you will be limited to exporting a few reports, and small transaction or record sets at a time. (Unless, of course, you include a clause mandating this, test it after all of your data has been imported and you have run a few events/processed a few thousand transactions to augment it, and penalty and termination clauses with damages and real teeth if this critical requirement is violated.)

But what we didn’t make clear is:

YOUR DATA IS MORE THAN JUST YOUR DATA

It’s also your configuration!

–> Who is using the software and what access rights they have.

–> What processes and workflows they are using.

–> And, most importantly, how those processes are configured!

Now, we’ll be brutally honest here and say that while you can’t expect to be able to import these settings into the next app you get for the same purpose, because every app is slightly different with slightly different configuration capabilities, workflow, etc.

It is very likely this is the only documentation you have of:

  • who is allowed to use the software and what they are permitted to do
  • what processes and workflows you are following
  • what approval processes you are using and who is actually approving
  • and so on.

In other words, it is very likely that the ONLY documentation you have on your processes and practices is in the tools you are using, and, more specifically, in the configurations. Thus it’s absolutely essential you be able to export those as well. Even though you will have to manually recreate them when you switch platforms, it is still better to have documentation on what you were doing, and who was doing it, than none at all. Plus, you can then analyze your processes and find opportunities for improvement with these records!

So make sure that when you select an app you can get your data, and we mean all of your data, at any time before you sign on the bottom line. That way, no matter what happens, you’ll never really be screwed.