Category Archives: AI

If You Can’t Do The Job Without Tech …

Then you can’t do the job with tech.

I’ve said it before and I’ll say it again. If you can’t do the job without tech, then you can’t do the job with tech.

All tech does is automate tasks and workflow processes and allow you to speed them up by a factor of 10 to 1,000,000 plus (depending on the tasks and workflow processes).

It doesn’t make tasks or processes better or worse (unless you Gen-AI, which typically makes it worse) — just faster (unless, of course, you change the process when you implement the tech and make the task or process better or worse).

Now, you’re probably asking why it’s not enough to design the process and simply install the tech. That’s because there’s a difference between designing a process and executing a process. Anyone can design a process at a high level given a highly set of requirements. Not anyone can execute. Among those, even less can execute it effectively.

Only those who can execute it effectively are fit to do the job, regardless of what tech the organization has or does not have. That’s because, if you don’t know how to do the job without tech (and certainly without AI), you don’t understand what the job really is. Business was conducted for thousands of years without modern tech, and computers only became generally available in big business in the 80s and mid-size businesses in the 90s and small businesses in the 2000s. That means everything you do today with modern tech was once done without modern tech (and, 150 years ago, without any tech that we would consider modern at all).

That understanding means you understand the core of the function. You know what has to be done, how, where the time suck is, what can be automated, how, and why. You also know how to verify correct automations has been implemented, and where the results require human interpretation, review, and decisions — and, if necessary, make those interpretations, review, and decisions.

Without that understanding, you can’t properly make use of tech and you definitely can’t make use of AI. Sure some tasks might be 10 to 1,000,000 times slower (and sourcing optimization will be out of the question, just a few bid comparisons), and you shouldn’t do them by hand unless necessary, but the point is you need to be able to — otherwise, you can never judge what the system does. Iin the age of hyper-fast LLM hallucinations, only good human decisions will allow your organization to succeed.

The Procurement Knowledge Devolution

The internet was supposed to kick off the procurement knowledge revolution, allowing Procurement pros to quickly:

  • find out about best practices
  • get commodity and market pricing for products and services
  • build reasonable (should) cost models
  • find out about new suppliers, carriers, and consulting partners
  • research new products and services
  • hold truly global sourcing and procurement events in real time
  • effectively communicate with, manage, and develop suppliers
  • etc.

For twenty years, that’s what it was. Procurement departments who learned how to use the internet properly for research, deployed the right SaaS to support their processes, and identified the right data for their processes were successful in their endeavours.

But then came Gen-AI LLMs, chatbots were replaced with chat, j’ai pété‘s and clod‘s, and knowledge was replaced with whatever content the LLM generated. Maybe it was correct, maybe it was mostly correct, and maybe it was a 100% fabrication — a hallucination if you please. The problem with LLMs is that they are NOT intelligent. They are essentially super sophisticated multi-level cross-connected deep neural nets that go beyond classification to generation of responses built up from sub-responses built up from deep training on incredibly large data sets.

Therein lies all of the problems. It generates built on random probabilities. Those are dependent on what’s in the training data set, what questions were asked, what results are reinforced, and how it’s used. If the training data is bad and full of bad data and falsehoods, the chances of incorrect, and even dangerous, responses being generated are quite high. If the training was biased, the output is likely to be very biased. And if it’s not “trained to please”, the models are fundamentally designed to “learn to please”, so if computations that are a complete lie will increase utilization of, and faith in the model, that’s what will happen.

Moreover, every vendor is now believing the hype from the big LLM players, treating the technology as real Artificial Intelligence (when it should be called Artificial Idiocy), and trying to plug it in everywhere … promising that it will provide their clients with true natural language interfaces, agentic tech, and even BS AI Employees. Those who are adopting it are literally getting dumber by the day. Not only has the cognitive impairment, atrophy, and potential long-term decline from regular use been well documented, but the failure rate has been well documented as well with MIT and McKinsey studies demonstrating success rates of 5% and 6% successfully. Most pilots are being abandoned, sometimes before they even begin, because the tech isn’t even good enough to put into employee’s hands for the tasks the overpriced Big X consultancies claimed the LLMs would be perfect for.

Furthermore, even when organizations are smart enough to ignore Gen-AI, over-automating using the most advanced last-gen (A)RPA and AI technologies will still give Procurement teams a false sense of security and, due to their very low error rate, as time goes on, the team’s skills will go rusty and their ability to deal with true exceptions quickly disappear, especially as the old Pros (get forced to early) retire and the younglings have never dealt with exceptional situations.

The age of AI hype has ushered in a knowledge devolution faster than any age that has come before.

I hope the profession can survive it!

Why it’s just easier to do your job in the Age of AI

Every year articles make the rounds on how to do nothing at work or look busy to either slack off or keep your annoying cow-orkers away so you don’t end up having to do their work too. Now, a few in 2006 really annoyed me and I decided to point out how stupid they all were by selecting one in particular and pointing out just how stupid it was because it was harder and more work to follow the advice then to just do your job for your 35 hours a week you had to work.

But I’m not here to tackle another inane article about how to slack off or avoid responsibility, because hopefully by now you’re not dumb enough not to fall for it, especially since smart managers (and workforce monitoring solutions) aren’t either.

I’m here to tell you why it’s just easier to do your job in the age of AI than to try to use AI to do it for you.

1. You’ll have to tell the AI what you want at least 3 times. Maybe 10. Or More.

Gen-AI LLMs should be called Artificial Idiocy. There’s nothing intelligent about them. They don’t understand anything. It’s all a Grand Illusion. Automated puppet-theatre … and we’re the suckers born every minute for using it.

As a result, they produce a lot of good sounding text that sounds close to what you need, but upon further review, always misses one or more key points of your request … until you repeat it and rephrase it ten times ten different ways and your strive to perfection slowly reduces to anything acceptable whatsoever.

2. You’ll still have to edit the final outputs and execute the work in the tools it can’t drive because they don’t have the APIs for the LLM to execute.

So, after spending hours trying to get it to output the perfect report and process, you have to go edit, finish, and execute that process. Spending as much time as if you just skipped the AI in the first place.

3. You have to deal with the consequences of the errors you miss.

If you’re using a modern Procurement system which is AI-first and allows external AI to drive it, a request to “restock the supply room at the lowest cost” can result in ten times the amount of printer ink, paper, pens, and cleaning solvent you go through in a year because it hit a volume break at the production plant and skipped the intermediate supplier, ignoring the fact that you have to rent a warehouse for the truckloads of cleaning solvent you just ordered for your office building (even though you only use one floor — it assumed you wanted enough for the twenty story office building).

You’ve spent too much, have no room for the inventory, and have to explain to your boss why ordering years worth of office supplies was a good idea.

4. You have to explain the AI bill that was five fold what you planned.

While also explaining that it was your idea, not the AI’s, to screw everything up.

It’s always easier, and less risky, to use your Human Intelligence, and not the AI, to get your job done.

… so What’s the Real Future for Procurement Tech?

Yesterday we pointed out that SOFIA Killed BOB and Replaced POE with a Black Box Agent, which forces us to ask what’s the real future for Procurement Tech?

As we noted in our last post, twenty (20) years ago the debate was BOB (Best-of-Breed) vs POE (Platform Oriented Enterprise — a [mini] Suite solution).

It was a real debate — best-of-breed modules gave you what you wanted and delivered value, but a slew of disconnected modules is not very productive. (Mini) Suites solved the dis-connectivity problem, but came with their own problems. Given that most were quickly built out on top of one or two core modules, and modules beyond those were barely MVP (that even startups would be shy releasing), you were sometimes lucky to get the 60% to 80% functionality the vendor promised.

SOFIA ((Solution Orchestration Framework Integration Architecture) was supposed to end the debate. Real orchestration solutions that would allow organizations to BYO-BOB (bring-your-own-best-of-breed) for any and all modules they wanted to construct their ProcureTech (and, hopefully, SupplyTech) platforms, but fell short. Part of the reason is that they started as intake to make the big suites usable, and didn’t start building a true, native, orchestration architecture — making it difficult for them to quickly and easily orchestrate the plethora of platforms that customers throw at them. The other part of the problem is that the majority of (classic) SaaS platforms weren’t built to be orchestrated, and, frankly, can’t be.

And using AI-first tools to quickly vibe-code the most common MVP modules customers want that can be “orchestrated out of the box”, doesn’t solve the problem. It just devolves the solution into a classic POE solution (but with less security — one of the big flaws of vibe coding). So SOFIA isn’t solving anything either.

Now, if you ask GAIN, the future is “AI Employees” (which aren’t real). Like any LLM-based solution, they will work great until a Grade A Hallucination results in buying millions of dollars of the wrong product, selecting a sanctioned supplier, or sending money to a dark-web criminal organization. Then it won’t. (At first, it will just order 3,000 pairs of gloves for an automated cafe for a lone worker, because it’s cheaper. LLM-based AI has already done that. Look it up.)

Probabilistic AI (where hallucinations are a core function that CANNOT be trained out) is not the answer and should never be used for more than suggestions.

So what is?

An enterprise SaaS platform rebuilt on a proper intake and orchestration platform (that supports rules-based agentic automation, i.e. [A]RPA) that was originally built to be domain independent and just solve the data and workflow integration challenges. In other words, if Coupa rebuilt on Tonkean (which won’t happen for so many reasons), that could be close to the answer. Zip and Oro were built too quick or too focussed to be the answer. It will be true orchestration platforms you don’t yet know that get acquired by tier-2 suite players with a lot of tech debt that rebuild on those orchestration platforms (that also built native intake) which can seamlessly integrate with next-gen SaaS platforms with secure, full, open APIs that allow for full data push and pull and programmatic function and workflow execution.

In other words, it will be domain specific SOFIAs. Not POE (which is too limited) and not Fake AI Employees.

The question is, who will create theirs first?

SOFIA Killed BOB and Replaced POE with a Black Box Agent …

What’s the real future of Procurement Tech?

Twenty (20) Years Ago, we asked What about BoB? when the debate in ProcureTech between BOB (Best-of-Breed) vs. POE (Platform Oriented Enterprise) was getting drowned out by the emerging suite players.

Did you go out and assemble your own suite of best-of-breed modules to suit your needs, and then pay the consultancy integrators big bucks to integrate them, or simplify your life, settle for a 60% to 80% solution and buy a suite that gave you an all-in-one solution (and bypassed difficult and expensive integration requirements) that was hopefully strongest where your core needs were?

It was a valid hot debate because most suites were centred on one (or two) strong modules that the firm was founded on, with the other modules either hastily built to what the firm considered an MVP so that they could sell a (mini) suite or acquired (and partially integrated) so they could have a suite, even though some of the modules were loosely connected (and sometimes even built on entirely different UX philosophies with noticeably different user interfaces).

Furthermore, twenty years ago, the bigger the suite was, the worse or more disconnected part of the suite was. In the beginning, most vendors started as e-Sourcing or e-Procurement and mini S2C and P2P suites were built up around those modules, respectively. S2P suites were usually built by one mini-suite vendor acquiring another (or, in rare cases, a CLM or SXM vendor realizing they needed both and getting the help of an investment firm). You had frankensuites built from three (3) primary solutions (and, in some cases, fattened up by additional acquisitions over time), which felt as disconnected as they were to use. However, the one-vendor-throat-to-choke and one-implementation-team comforted the C-suite and those purchases were easier than trying to get permission to acquire a bunch of best-of-breed solutions and then write a big cheque to an integration consultancy that you hope can get the solutions to all work together, at least until major solution upgrades, in which case the consultancy will have to come back and upgrade the integration.

Then orchestration came along and SOFIA (Solution Orchestration Framework Integration Architecture) was supposed to settle the debate once and for all. With modern orchestration solutions, you were supposed to be able to bring your own best-of-breeds, integrate them all with modern orchestration, and either use their native intake, or bring your own, to open up their solutions to everyone who needs access. That was the theory. The practical reality is different.

I’m not sure if it’s still the case, but for years, neither you nor your consulting and integration partners could integrate your own solutions with Zip — Zip had to do it internally because it was too complicated and needed to be done a specific way. Oro, first designed to make Ariba usable and then to make other major last-generation suite solutions usable, provided you with a similar situation — partner solutions are pre-integrated and easy to onboard, other solutions took time. Then there’s Tonkean, now part of Coupa, that could integrate anything if they did it and you gave them the time to do it. Time being the key word. (They were essentially assembling an application for you … no quick out-of-the-box configuration!)

None work(ed) out of the box, and there’s two reasons for that.

The first is that you can’t quickly MVP generic orchestration solutions that are flexible, powerful, easy to use and work with today’s SaaS — the Enterprise has to be carefully thought out and designed and the coding talent needed is not the script-kiddie drop out talent that many (AI-first) firms are employing.

The second is that most platforms, frankly, weren’t even built for integration, which means that they definitely weren’t built for orchestration. Modern orchestration requires more than the ability to push some data in, and pull some data out. First of all, it requires the ability to push all data in and pull all data out. Secondly, it requires the ability to programmatically trigger and execute functions and workflows from external sources. Most platforms don’t support that (well). As a result, orchestration platforms don’t work. If the platform doesn’t have, and completely expose, its API (through secure channels to apps with appropriate security credentials), orchestration is not truly possible.

As a result, most of the big orchestration providers are trying to use AI-first tools (and vibe coding, which, as we’ve made clear many times, only produces vibes that are please to the smug sniffing coders who use it, not good code) to quickly code their own S2P apps and modules, and essentially reverting to a POE (2.0) solution — internalizing their orchestration solution as a platform oriented enterprise to build a next-gen classical suite solution. (Oxymoron intended!)

But is that the future? (Hopefully not!)