Category Archives: SaaS

The Pundits Agree. Winter is Coming!

In a recent LinkedIn Post, THE PROPHET, a year late to the party (see the SI and Procurement Insights archives, and our Marketplace Madness post in particular), finally announced that Winter is Coming: The Great Procurement (and Broader) Legacy SaaS Rationalization and that it is going to be a very cold winter that will be Swift. Brutal. And very, very final.

There’s too many companies that took too much funding at too high a valuation with nothing to show. PE firms will be dropping these companies faster than a hot potato into boiling lava pits to focus on the companies in their portfolio with current year-over-year growth in hopes of making some of their losses back. Too many companies started without doing any research and literally built the 10th AP clone, SXM clone, RFX clone etc. of a dozen already existing solutions. (Just check the mega map if you don’t believe me.) In a race to the bottom (which helps no one), they’ll lose due to their lack of a bank account as they slash prices too deep in hopes of getting customers. Too many applications took a silo focus, didn’t build Open API centric, and the hurdles of plugging them in will be too much or too costly, and no matter how good the tech is, they won’t get bought.

And then Agentric AI will thin what remains (but not lead the cull as THE PROPHET predicts, because these AI solutions still cost money, and sometimes a lot of it, and for what they cost you can hire a real expert and not a fake one, license a few augmented intelligence tools for a quarter of what these over hyped Agentric AI platforms are charging (because they raised, and wasted, too much cash and have to recoup that before they become the next hot potato dropped into the lava pit by their PE investors), and have a super-human employee who does the work of an entire team, error free (with little to no risk of that skilled employee getting you sued as a result of a conversation, installing a back door for hackers on your systems, shutting down your systems for days, costing you 10X on a purchase due to a dot transcription error, or increasing your internal fraud [link]).

And for some of these companies, it’s already too late to pivot. For others, there are actions they can do. THE PROPHET offered some:

  • risk over-cutting
    (if done smartly)
  • consumption-based models
    (which will be more attractive to some potential customers)
  • challenge the team to earn their existence
    (but that doesn’t necessarily mean prompting GPT like a pro: you don’t want junkies)
  • redefine the sales org
    (a better playbook is key, and it needs to be differentiated)
  • Skip the Fairy Dust and Buzzwords
    (Hear! Hear! I’ve been shouting that for years! Unfortunately, not sure most of the companies out there know how to do that though! I know for a fact only the squirrels have been listening to me, and they are getting very tired of that rant. They like variety. Basically, it’s been a long, long time since marketing focussed on education and value and startups priced based on that.)

And that’s just the tip of the iceberg. SI has posted entire series on:

Failures from those who raised too much and offer too little will be coming fast and furious. This needs to be repeated. You need to be very careful which vendor you buy from and what protections you have in place if they don’t make it. (In particular, there must be a “we own our data” clause which gives you the right to all of your data and the right to export all of it into a standard file format at any time, and that specifies your data includes rules and workflow configurations and the right to export those too — for example, in spend analysis, it’s not just the data, it’s the rules that create the cubes; in invoice processing, it’s the workflow and approval rules … you won’t be able to migrate to another system quickly if all you have is the transaction data, the data that defines the processes and rules is just as important. And if you can’t export all of your data, rules, templates, etc., at any time, then don’t buy the system!)

However, while the app consolidation will be brutal, as will the renegotiations if you want to be one of the apps that make it (now that organizations are realizing they don’t need 17 apps for S&M and probably shouldn’t have 17 apps in any function, including Procurement), Agentric AI (especially at 20K a month when you can hire a REAL person for 1/4 of that) will not replace people en masse (but AI-enabled technology will). Teams will be cut and replaced by two individuals who can use next generation augmented intelligence solutions that can truncate months of research and analysis to a few days and allow strategic decisions to be made in hours, not weeks, and shifts to be made seemingly overnight while eventually allowing 99% of all tactical data processing to be automated through evolving rules and workflows under expert guidance.

Moreover, at the end of the day, relationships are not built on 1s and 0s, and they are needed now more than ever. So not only will we have skilled technologists, but skilled relationship managers. (While everyone else who does nothing but push e-paper 90% of the time or code spreadsheets will slowly be eliminated.) Of course, this means if you don’t understand optimization, analytics, statistics, game theory, economics, and logic, or you’re not an expert in relationship management, you’re screwed, but everyone had a chance to study STEM in University (and skip the woke liberal arts) and learn the technical skills for the first set of jobs.

So this also means if the platform is not enabling this next generation of employees to become more and more productive over time, its lifespan is probably short.

So get focussed in your diligence efforts on solution acquisition if you don’t want your platforms disappearing out from under your virtual feet, and if you need help, call an expert!

Who Needs The Beef?

For those of you who have been following my rants, especially on intake-to-orchestrate (which really is clueless for the popular kids as it doesn’t do anything unless you already have all the systems you need and don’t know how to connect them), you’ll know that one of my big qualms, to this day, is Where’s the Beef?, because while the intake and orchestrate buns are nice and fluffy and likely very tasty, they aren’t filling. If you want a full stomach, you need the beef (or at least a decent helping of Tofu, which, unless you are vegetarian, won’t taste as good or be quite as filling, but will give you the subsistence you need).

And you need filling. Specifically, you need the part of the application that does something — that takes the input data (possibly properly transformed), applies the complex algorithms, and produces the output you need for a transaction or to make a strategic decision. That’s not intake-to-orchestrate, that’s not a fancy UI/UX, that’s not an agent that can perform transactional tasks that fall within scope, and that’s NOT a fancy bun. It’s the beef.

But, apparently, at least as far as THE PROPHET is concerned, (bio) re-engineering is going to eliminate the need for the beef. Apparently, the buns are going to have all the nutrients (or data processing abilities) you need to function and do your job.

In THE PROPHET‘s latest analogy, today’s enterprise technology burger consists of:

  • the patty: (not to be mistaken for the paddy) which combines enterprise technology and labour (which means it really should be the patty [labour] and the trimmings [technology] in this analogy)
  • the upper bun: and
  • the lower bun: which collectively provide you a way to cleanly get a grip on the patty

But tomorrow’s enterprise technology burger will consist of:

  • the upper bun: which will be replaced by a new type of technology that fuses co-pilots and agentic systems to power autonomous agents and replaces the patty [labour] and part of trimmings
  • the lower bun: which will represent the next generation data store and information supply chain and build in “self-healing” technology for data maintenance and replace the other part of the trimmings

… and that’s it. NO BEEF! Just two co-dependent buns that are destined to fuse into a roll … and not a very tasty one at that. Because this roll will, apparently, operate fully autonomously and never get anywhere near you, leaving you perpetually hungry.

Now, apparently, not all parts of the patty (with its complex amino acid chains and protein structures) will be capable of being (bio) re-engineered into the buns right away and the patty won’t disappear all at once, just shrink bit by bit over the next decade until there’s nothing left and the last protein structure is absorbed (or replaced by a good enough AI-generated facsimile — they can do that now too). In THE PROPHET‘s view, legacy systems of record (ERP/MRP, payment platforms, etc.) will be the last to be replaced, and those will survive along with the legacy labour to maintain them until they can finally be split up into components and absorbed into the bun.

In other words, in THE PROPHET‘s view, you don’t need the patty, and, more specifically, you don’t need (or even want) the beef. I have to argue this is NOT the case.

1. You Need the Beef

Thinking that the patty can be completely absorbed into the buns is what results from a lack of understanding of enterprise software architecture best practices and software development in general.

The best architecture we have, which took years to get two, is MVC, which stands for

  • Model: specifically, data model, which should be at the bottom (and could be absorbed into a data bun)
  • View: specifically, the UI/UX we interact with (and could be absorbed into a soft, warm, sweet smelling sourdough bun)
  • Controller: the core algorithms and data processing, which needs to be its own layer that supports the UX (and allows the UX to reconfigure the processing steps and outputs as needed) and can be cross-adapted to the best available data sources (that need to be remain independent)

Moreover, even Bill Gates, who predicts AI will have devastating effects across all industries, realizes that you can’t replace coders, energy experts, and biologists, and, by extension, jobs that require constantly evolving code, organic structure, and energy requirements to complete. So you will still need labour that creates, and relies on, highly specialized algorithms and expert interpretations of outputs to do their jobs. That also means that, in our field, strategic sourcing and procurement professionals cannot be replaced but tactical AP clerks are on their way out as AP software automatically processes 99% to 99.9% of invoices with no human involvement, even those with missing data and errors, handling the return, correction, negotiation, etc. until all of the data matches and costs are within tolerance.

2. You Want the Beef!

The whole point of modern architectures and engineering is to minimize legacy code / technical debt and maximize tactical data processing and system throughput (and have the system do as much thunking as possible, which is what it’s good at). If you try to push too much into the lower bun, you don’t have separation of data and processing, which means it’s almost impossible to validate the data as it’s not data you’re getting, but processed data, which means that the system might be continually pushing wrong data to the outer bun, even with good data fed in, due to a bug deep in the transformation and normalization code. But your automatic checks and fail safes would never catch it because you’ve turned what should be a crystal (clear) box into a black box! If you try to push too much processing into the upper bun, you have to replicate common functionality across every agent and application, leading to a lot of replication and bloat that consumes too much space, uses too much energy, and makes the systems even harder to maintain than the legacy applications of today.

So while the burger of tomorrow might be different with a much leaner, more protein rich, patty (with less sauce and unhealthy trimmings), and the bread might be a super healthy natural yeast-free multi-grain flat bread, making for a smaller (and possibly less appetizing burger from a surface view), it still needs to be a burger and anyone who thinks otherwise has joined the pretty fly Gen-AI in hallucination land!

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;