Category Archives: SaaS

What is Spend Orchestration?

Spend Orchestration is all the rage. But what exactly is it?

Well, as we tried to point out in Demystifying the Marketing Madness for you, where we said it meant we don’t do anything different than all the other orchestration providers, but it sure sounds cool!, Spend Orchestration is essentially:

Clueless for the popular kids.

It’s a coming-of-age comedy where you have a slick looking, popular, over-funded new-age SaaS platform from fresh-out-of-college (dropouts) who want to do “good deeds” for the Procurement space by giving your Procurement department a “makeover” that connects all of your applications together so you can “manage your spend” and match stakeholders with the procurement professionals that can meet their needs (as the platforms try to justify their existence).

Upon implementation of the spend orchestration, there will be one fiasco, hardship, and falling out after another as you realize the platform doesn’t do anything if you don’t have core Procurement platforms for sourcing, supplier management, analytics, contract management, procurement, and invoice management/accounts payable … otherwise, it’s just intake to nowhere and orchestrating faster push and pull from your incomplete, outdated ERP/MRP. Also, without good platforms in place, it will just make it easier for the stakeholders to admonish you on a daily basis when your Procurement process doesn’t actually pick up the pace or perform more preferably. And you will be more jealous of your peers that skipped the orchestration platform and went straight for the S2P or P2P platform that actually solves some of your Procurement problems.

Now, eventually you will acquire the missing pieces (or these orchestration platforms will build basic functionality) and you will kiss and make up at a big fat Procurement Wedding like ISM or DPW, where they invite you on an all expenses paid trip to participate in their prestigious Power Procurement panel, but it will be a very rocky road on the way.

Our suggestion is that if a company comes knocking with “spend orchestration“, you tell them thanks and no thanks and save the comedy hijinks for the big screen. If you do need orchestration — which you won’t know for sure until after you’ve consolidated your applications, determined which are not easy to direct connect (due to a lack of [Open] APIs), which don’t allow easy access across the organization, and where orchestration might actually help — you want to get that orchestration from a company that has grown up, not one just starting it’s teenage high-school journey!

Orchestration Won’t Solve a Reckless Runaway SaaS Proliferation Problem!

In a recent LinkedIn Post, THE REVELATOR asked Why you need an Internal and External Metaprise Strategy for optimal Intake and Orchestration capability? and noted that:

Most large enterprises use between 10-25 procurement software platforms, with some complex organizations exceeding 25. Just for Procurement!
A 2022 study by Forrester Consulting found that large enterprises use an average of 367 software applications and systems.
A 2023 report by Zylo found that large organizations deploy an average of 660 Software as a Service (SaaS) applications.

Moreover, the doctor has seen stats:

as high as 87 individual SaaS products in a single department in larger orgs
exceeding 40 for Marketing or Sales … when you can’t find more than a half dozen apps that actually do something significantly different

All the doctor can say to this is that if the number of platforms you are using numbers is in the three digits, you don’t need orchestration, you need consolidation!

For example, Marketing and Sales is all lead generation/management and customer prediction/funnel/CRM. With no coherent strategy (beyond maybe SalesForce for CRM), every employee or team will purchase their own set of Apps and the organization will have 5 to 10 apps that more or less do the same thing with 90% overlap. And similar situations abound throughout the organization.

So yes, these organizations need a strategy, and that strategy should be to centralize app decision and management in each department to prevent unnecessary app sprawl. After all, each app you orchestrate costs you even more money than the app subscription cost (as the orchestration app will charge you based on the number of integrations, and how many of those it supports out of the box), which ends up ballooning your overspend to integrate apps you shouldn’t be using in the first place.

Which means that the first thing these organizations need is a SaaS App Optimization platform that can crawl their SaaS purchase and usage data, identify what’s used, identify more-or-less duplicate apps, and identify which app should be consolidated upon based on usage. This will not only reduce costs by over 30% once the unnecessary apps can be dropped (at the end of the current license or payment cycle), but increase productivity (as [cross functional] teams work in the same app ecosystem).

Moreover, this is just the tip of the overspend iceberg. Once the first round of consolidation is done, these organizations need to tackle SKU sprawl in their enterprise platforms, and their ERP, Cloud Host, and Back-Office Systems in particular where the common vendor strategy is to offer “bigger discounts” when the client purchases packages that contain modules they don’t need or more seats than they will actually use, which, even with the bigger discount percentage off of list price, are still designed to cost the organization more than they should be spending. To do this, they will need to use a vendor that are experts in enterprise software system purchases and know how to unbundle these consolidations and get you insight into market pricing on a SKU basis for hard-nosed fact-based negotiations.

Only once the organization’s platforms have been consolidated and optimized should the organization embark heavily into orchestration, as this is the only way to ensure they don’t do unnecessary work or pay unnecessary costs.

In the Software World, It Is Never Build vs. Buy!

In a LinkedIn post, THE REVELATOR asks “Why is the build versus buy debate a moot exercise?”.

The answer to this question is super simple.

If you are NOT a software^* company, it is NEVER build. NEVER, EVER. Especially since “Build” typically means outsourcing to a Big X who are typically specialist implementors, not builders, and will just have to outsource to a Dev Shop and add a high margin to manage that outsourced project for you IF they want to get it right. (Just Google “Accenture Hertz Lawsuit” to see what happens when they get it wrong, so the smart Big X really do add a layer between you and an outsource Dev Shop in South America, Eastern Europe, or India … and trust us when we say that the last option ain’t always great either!) In the end, the project will cost 5X to 10X, take significantly longer than you expect, and rarely deliver entirely what you want.

The debate today should be “assemble vs. buy”, because the most you should do is determine whether its best to go with one provider who provides some functionality across the board for a function, but maybe not as deep as you want in certain areas, or if you want to assemble a slew of best of breed modules that go deep everywhere you want deep. In the latter case, you are deciding whether you are going to select a slew of best of breed modules from a slew of vendors and oversee the integration yourself (one time cost plus incremental costs on the update of each component solution) or go with an “orchestration” solution (and its year over year SaaS fee) vs. just selecting one of the same old Big Suite providers that will handle everything (with a fee to match).

The only thing that remains correct about the “build” vs buy debate is that you need to maintain the “build” mentality, in that you may have to lego-block “build” from a collection of best-of-breed modular solutions. However, the “build” will never be a build from scratch, just a build from components, the same way we used to assemble our own desktop systems.

^* and even if you are a software company, if the type of software needed is not the type of software you build, and there is a reasonable SaaS solution, you should go with that;

Myth-busting 2025 2015 Procurement Predictions and Trends! Part 11

Introduction

In our first instalment, we noted that the ambitious started pumping out 2025 prediction and trend articles in late November / early December, wanting to be ahead of the pack, even though there is rarely much value in these articles. First of all, and we say this with 25 years of experience in this space, the more they proclaim things will change … Secondly, the predictions all revolve around the same topics we’ve been talking about for almost two decades. In fact, if you dug up a Procurement predictions article for 2015, there’s a good chance 9 of the top 10 topic areas would be the same. (And see the links in our first article for two “future” series with about 3 dozen trends that are more or less as relevant now as they were then.)

In our last instalment, we continued our review of the 10 core predictions (and variants) that came out of our initial review of 71 “predictions” and “trends” across the first eight articles we found, in an effort to demonstrate that most of these aren’t ground-shattering, new, or, if they actually are, not going to happen because the more they proclaim things will change …

In this instalment, we’re again continuing to work our way up the list from the bottom to the top and ending with “AI”.

AI

“AI” is the only “prediction” or “trend” that would not have appeared ten years ago. (Ten years ago it would have been “analytics”, the favourite precursor technology.) There were 10 predictions across the eight articles, and this was the only category where they were not in synch (because the technology, as well as the usage thereof, is not only still evolving but not well understood). Given the vendor hyper-focus on AI (and especially Gen-AI) over the past few years, it is yet another “prediction” or “trend” that is not new, as we are still in the (over)hype(d) cycle, but one that should be adequately addressed as it’s where we have the biggest gap between expectation (pushed by the vendors and the analyst firms and the consultancies) and reality.

Before we go any further, here were the ten predictions from the articles:

Advancements in AI and Automation
AI: overhyped or underestimated?
AI and The Digital Transformation Revolution will Continue
Artificial Intelligence in Procurement
Automation and Artificial Intelligence
Digital Transformation, Automation, and AI
Focus on AI Talent in Procurement and Skill Upgrading
From AI adoption to AI adaption
Integration of AI and Advanced Analytics
We’ll Evolve from AI Adoption to True Integration

They range from continued adoption to adaption to analytics enhancement to seamless integration to true advancement in underlying technology, and with the exception of continued, mostly unbridled, and definitely unresearched, adoption, they are more-or-less all off the mark.

The analyst firms are still overhyping this technology to the max (despite continuing to publish studies that 85%+ of technology projects fail)). At least six (6) in seven (7) vendors are overhyping (Gen-)AI to the max, if not nine (9) in ten (10). The Big 3 (Google, Microsoft, and, of course, “Open”-AI) are promising miracles for all who adopt their technology. It’s being marketed as the ultimate panacea, the magic elixir of your dreams, and the silicon snake oil that actually works (among other things). And when you combine the facts that most people don’t have the mathematical and technological background to understand what a given “AI” technology is and, as Bertrand kindly pointed out, humans are biologically wired to be lazy, most are happy to close their eyes, cover their ears, sing “la la la la la la”, and buy in to the BS promises hook-line-and-sinker. So, whether the technology is right or not (and we’ll give you a hint, it usually isn’t), they’ll buy it. (And then blame the vendor when it fails to deliver, who will blame the consultant for improper implementation and training.)

So how accurate were these predictions? Did any hit the mark? Come back for Part 12!

Enterprises have a Data Problem. And they will until they accept they need to do E-MDM, and it will cost them!

This originally published on April (29) 2024. It is being reposted because MDM is becoming more essential by the day, especially since AI doesn’t work without good, clean, data.

insideBIGDATA recently published an article on “The Impact of Data Analytics Integration Mismatch on Business Technology Advancements” which did a rather good job on highlighting all of the problems with bad integrations (which happen every day [and just result in you contributing to the half a TRILLION dollars that will be wasted on SaaS Spend this year and the one TRILLION that will be wasted on IT Services]), and an okay job of advising you how to prevent them. But the problem is much larger than the article lets on, and we need to discuss that.

But first, let’s summarize the major impacts outlined in the article (which you should click to and read before continuing on in this article):

Higher Operational Expenses
Poor Business Outcomes
Delayed Decision Making
Competitive Disadvantages
Missed Business Opportunities

And then add the following critical impacts (which is not a complete list by any stretch of the imagination) when your supplier, product, and supply chain data isn’t up to snuff:

Fines for failing to comply with filings and appropriate trade restrictions
Product seizures when products violate certain regulations (like ROHS, WEEE, etc.)
Lost Funds and Liabilities when incomplete/compromised data results in payments to the wrong/fraudulent entities
Massive disruption risks when you don’t get notifications of major supply chain incidents when the right locations and suppliers are not being monitored (multiple tiers down in your supply chain)
Massive lawsuits when data isn’t properly encrypted and secured and personal data gets compromised in a cyberattack

You need good data. You need secure data. You need actionable data. And you won’t have any of that without the right integration.

The article says to ensure good integration you should:

mitigate low-quality data before integration (since cleansing and enrichment might not even be possible)
adopt uniformity and standardized data formats and structures across systems
phase out outdated technology

which is all fine and dandy, but misses the core of the problem:

Data is bad (often very, very bad), because the organizations don’t have an enterprise data management strategy. That’s the first step. Furthermore this E-MDM strategy needs to define:

the master schema with all of the core data objects (records) that need to be shared organizational wide
the common data format (for ids, names, keys, etc.) (that every system will need to map to)
the master data encoding standard

With a properly defined schema, there is less of a need to adopt uniformity across data formats and structures across the enterprise systems (which will not always be possible if an organization needs to maintain outdated technology either because a former manager entered into a 10 year agreement just to be rid of the problem or it would be too expensive to migrate to another system at the present time) or to phase out outdated technology (which, if it’s the ERP or AP, will likely not be possible) since the organization just needs to ensure that all data exchanges are in the common data format and use the master data encoding standard.

Moreover, once you have the E-MDM strategy, it’s easy to flush out the HR-MDM, Supplier/SupplyChain-MDM, and Finance-MDM strategies and get them right.

As THE PROPHET has said, data will be your best friend in procurement and supply chain in 2024 if you give it a chance.

Or, you can cover your eyes and ears and sing the same old tune that you’ve been singing since your organization acquired its first computer and built it’s first “database”:

Well …
I have a little data
I store it on my drive
And when it’s old and flawed
The data I’ll archive

Oh, data, data, data
I store it on my drive
And when it’s old and flawed
The data I’ll archive

It has nonstandard fields
The records short and lank
When I try to read it
The blocks all come back blank

I have a little data
I store it on my drive
And when it’s old and flawed
The data I’ll archive

My data is so ancient
Drive sectors start to rot
I try to read my data
The effort comes to naught