Category Archives: SaaS

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;

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!