Category Archives: Technology

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!

It’s Not Just Public Procurement Offices That Should Avoid Tech Fads

A recent article over on State Tech Magazine boldly stated that State Procurement Offices Should Carefully Avoid Tech Fads. And the headline, and author, was right. But it’s not just the public procurement offices that should be avoiding tech fads, the private sector offices should be avoiding them too. But more on this later.

The author noted that Artificial Intelligence is everywhere these days, and that news, advertising [and marketing] may leave you feeling [more than a bit] pressured to join the crowd and be an early adopter. But, as the article points out, and as THE REVELATOR would also be quick to point out, successful IT procurement inolves engaging with a comprehensive list of stakeholders, conducting thorough research and careful implementation planning, and, as THE REVELATOR reminds us on a regular basis, understanding what you need in the first place.

As the author notes, emerging technologies often present unforeseen challenges and novel issues that procurement offices must be aware of and prepared for. Failure to do due diligence can lead to embarassing or costly results. Not only do you have the extremely high failure rates with advanced tech projects, exceeding 85% according to Gartner, but, as the author points out, in the public sector technology breakdowns can have much more consequential impacts. The Air Canada lawsuit is just the first example of what is to come from the inevitable failures of AI not ready for prime time.

It’s not about the hype, it’s about the value the solution will provide, which includes, as the author notes, the total cost of ownership and longevity. The solution must fulfill the organizational need, not the hype. Otherwise, the total cost of ownership is high as no value is delivered while the longevity will be very limited.

But this should be just as true in the private sector. After all, a solution that could get you sued if it fails, that doesn’t solve the problem, that is worthless from the minute it is implemented, and that will paralyze you until a replacement is found and implemented is not something you should ever, ever want in private industry either. So don’t fall for the hype, and stay on the course that’s right — real solutions that solve real problems.

To Manage Innovation, Governments Must Fix Procurement … And Take Care Where AI is Concerned!

A recent article on Civil Service World noted two things that attracted my attention:

  1. To manage innovation, governments must fix procurement
  2. Too often, contracts in AI do not give governments powers to investigate algorithms or the data they are trained on. As a result, they risk taking the blame when things go wrong without the means to find out why.

Public Procurement is expensive. Very expensive. Given that it represents 12% of the annual GDP of an average developed economy, that is a huge amount of spend. Given that the overspend in most departments of most jurisdictions is likely as bad as in the private sector, which means, depending on the category, is likely in the 4% to 6% range at a minimum (based on the results high performing organizations see when implementing best-in-class processes and technology), that means a minimum of 1/2% of GDP is being wasted annually, but based on the fact that most public sector projects exceed initial budgets and timelines, we’d bet that the overspend is double that and at least 1% of the annual GDP. That’s a lot of waste — 770 Billion on the top 10 economies. Furthermore, that assumes that all of the spend is necessary and well planned. (There is likely considerably more savings with better demand planning, more operational efficiency, better project planning, etc. We’re just stating that the savings on committed spend alone is likely 10%.)

The article notes that despite the strategic importance of Procurement, it’s rarely seen as a priority and is more often treated as a standardized compliance function, rather than a tool for strategic investment and, in some cases, has become synonaomous with absurdity, due to an accumulation of rules so complex that even those administering them cannot interpret them creates the perverse incentive of doing the least risky thing to avoid individual liability. As a result, governments end up buying obsolete technologies that make them vulnerable, because innovation evolves so rapidly, and forces them to buy more. The cycle repeats, budgets balloon, and public capabilities diminish.

And, unfortunately, public procurement is a brick-and-mortar process, still more suited to bulk-buying precisely describable goods, accounting for them, and moving onto the next purchase. Innovation is different: you do not know today what is going to be possible tomorrow, even when you are the one inventing the tech. While governments work in one-off projects, innovation is made of ever-changing, always-fleeting products.

Furthermore, those in charge of procuring these technologies are not technologists. Public procurement is professionalized in only 38% of OECD countries, so even if officials had the incentive to experiment, they would not have the expertise.

To combat this, the authors of the article propose that Procurement systems should be like good software, fluid, flexible, and constantly evolving. However, as they note, this will take more than changing rules. As they note, it will take talent that are experts in what they are buying. It will take the treatment of Procurement as a strategic function, with clear lines for advancement for all personnel (as studies have shown that even a marginal improvement in skill can yield significant reductions in costs, times, and contracting complexity). Thirdly, they will need a federated data environment to make use of modern technology. (Especially if they want to use AI.)

This is just the start of what is necessary. There needs to be regular training. There needs to be specialization to different types of functions and purposes. There needs to be a rewrite of rules to focus on the right outcomes, not just a plethora of rules designed to prevent previously undesirable outcomes. There needs to be clear paths from buyer to public organization CPO to department head, not just paths of advancement within the Procurement function. There needs to be a focus on what’s best for the public being served, not best to minimize the risk to the buyer. And a willingness to accept that their may be a few mistakes made here and there as new buyers learn the ropes, while a willingness to weed out anyone that “makes a mistake” in order to give a contract to a supplier who is not the best fit (and do so in exchange for a kickback).

But most importantly, if they acquire AI technology, they also need to acquire the right to investigate the algorithms being used, the data it is trained on, the results of prior training, and the right to inspect any changes to the algorithms, data, and training. Otherwise, you can never trust any AI technology you might want to acquire.

Because governments need to apply the most appropriate AI-enhanced technology more than the private sector, but are the least likely to be able to use them properly.

Data Governance is Essential to Good Data Management …

… so why is there still so little of it in most organizations?

Good data is becoming ever more successful to business and Procurement success, especially if you want to use any any sort of predictive analytics or AI, but so few organizations have so little data governance, if they have any at all. With good data, you can get great insight into current operations, opportunities, and ordeals. Without good data, you have no clue what you’re buying or selling, what processes are going on at any point of time, or what problems are festering about to explode and cause major issues.

But good data is a rarity in most organizations, getting rarer by the day due to rapidly increasing data volumes (in excess of 400 million terabytes of data being generated daily across the globe), lack of controls in legacy systems, poor data processes, and lack of good IT talent with enough history to know what the data is, what it’s used for, and how to qualify it as good, or bad.

Why? Because organizations are putting systems in place before understanding what data those systems will need, where it will live, how it will be validated, how it will be maintained, how it will be archived, and how it will eventually be retired.

In most organizations, when they need data for an analytics-based project, the current answer is to get a “data warehouse”, “data lake”, or “data lakehouse”; dump all the organizational data to that warehouse, lake, or lakehouse; possibly run a simple AI-cleansing/enrichment algorithm, and hope for the best. However, this is not governance, and, in fact, exacerbates the problem more than it solves it. Now there are two copies of bad data, no strategy for pushing back any data that is cleansed, and if the data is changed in the source system before any eventual synch with the data warehouse, which data is correct? Chances are neither record is fully accurate, and any synch has to be done at the field level, if you have enough data to validate which field is correct (as you can’t just use time stamps, because if some data was updated by AI and unvalidated, it may not be right).

Governance is not just maintaining data in systems as you use it, occasionally validating it against third party databases or by manual review, and occasionally enriching it.

Governance is


  • defining what data the organization needs for its various functions
  • defining what data will be collected
  • defining what systems it will be maintained in, and, if the data is in multiple systems, which system is master
  • defining which data fields are critical and how they will be validated
  • defining when and how critical fields will be revalidated
  • defining the process for any data migration from master systems

And doing it


  • collecting the data
  • installing a new system
  • stating an analytics / AI project

NOT AFTER!

But how many organizations do that? Most don’t even do a proper RFP (taken in by the FREE RFP scam), even though the solution to good software (which is critical to maintaining good data) is an Affordable RFP.

Moreover, part of the RFP for any software solution should define the data management strategy as it impacts, and is impacted by, the solution.

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!