Category Archives: SaaS

Center-Orchestrated Procurement Requires Unique Platforms

In our last few articles, we’ve been writing a lot about the need for center-orchestrated Procurement due to the current global trade environment. As a result of this, a number of policies, processes, and platforms will need to change for a modern global Procurement organization in order for it to be efficient, effective, and even endorsed.

While the core platform requirements don’t change, the unique requirements for the platform are different. When you only have to serve yourself, whatever works for you is good enough. But when you have to serve a diverse base of global users, who have to adhere to a diverse spectrum of global requirement, what works for you is sometimes completely irrelevant.

Then there’s also the fact that center-orchestrated procurement, by definition, requires:

  • orchestration — if the platform can’t orchestrate data streams, workflows, and users, it’s not sufficient
  • common data model — every platform must support the common data model in the central data store to allow for easy data integration and cross organization analytics
  • centralized supplier onboarding — there needs to be a central supplier master and management platform
  • “excellence” — if the platform can’t encode and distribute best practices across the global organization, it’s not the right platform
  • standards — efficiency comes from standardization to the extent possible, if the platform doesn’t support that, it’s no good
  • supply chain awareness — it needs to integrate with the logistics, supply chain, and PLM systems in order to allow for organizational aware sourcing and procurement
  • knowledge management — it should capture all of the knowledge needed to run the orchestrated workflows effectively
  • global risk management — all of the risks must be identified, tracked, mitigated and managed centrally

Breaking this down, you can see that before any sourcing or procurement platform, it needs to support:

  • real orchestration support — it needs a fully defined API that allows all data to be pushed in or pulled out, functions to be executed, and workflows to be configured; it can be a standard REST API or MCP, but it has to be orcehstratable
  • centralized common data model and data federation platform — that can support all sourcing and procurement data collected and generated by all systems with the ability to define the external system mappings as appropriate; this doesn’t mean the organization dumps everything into a lake / warehouse / lakehouse, but builds the foundation for federated data analysis as the best analytics platforms can pull in the data needed on demand when they have a common data model to work off of (pre-defined mappings from the global organizational systems, and a designation as to which system is “master” for any specific piece of data — which means the data model specifies, for each datum, the master system)
  • centralized supplier onboarding — the central supplier master should support global supplier onboarding; if it can’t be localized as needed (language, accessibility, etc.), then it needs to support fine-grained orchestration that will allow a local platform to mimic the global requirements and feed all of the data into the central system
  • excellence — any platform used for centralized operations need to support the creation of specialized workflows for each region, location, and project; moreover, the specialized workflows need to inherit the global requirements while supporting the regional and local overrides with minimal effort; nothing should have to be defined twice and no unnecessary work duplicated
  • standards — the platform needs to support multiple authentication, security, and privacy standards and implementations to meet global requirements; remember, different countries will require different security protocols, login protocols, privacy requirements, government platform integrations, etc. — the global platforms you select must support switching them in and out as needed by the locale
  • supply chain awareness — the platform needs to understand your supply chain data model and be capable of integrating with your supply chain platforms to integrate the required data to make supply chain aware decisions
  • knowledge management — the platforms must capture more than process, they must capture the decision making frameworks used to select and execute the processes and do the required analytics; for the categories, they must cover the strategy; for the suppliers, the soft evaluation criteria based on the objective and subjective rankings; for Procurement process selection — catalog vs. RFQ vs. tail-spend provider — the logic used; etc.
  • global risk management — a solution for identifying, tracking, and monitoring changes in global risk criteria and alerts and pushing out relevant information to the appropriate regions and locations through the tools the end users actually use (using the built-in orchestration capabilities)

In other words, the platform has to be a lot more adaptive, layered, and customizable than most platforms in use today.

… 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!)

Remember When The Worst We Had To Worry About Was The Patent Pirates?


Those were the good old days
Those were the good old days
The years go by, but the memory stays
And those were the good old days

Good Old Days, Weird Al Yankovic, 1988

Twenty years ago, echoing the great Dave Stephens of Procurement Central fame, we cried about the software patent pirates plundering away your hard earned revenue as they scooped up patents from failing enterprises (or enterprises not willing to enforce them) for pennies on the filing dollar, and then sued any decently sized company that was offering software that sounded like it was covered by one of the patents in their hold, threatening to bankrupt the company with an expensive lawsuit that would be dragged out endlessly if the threatened company didn’t pay a patent licensing fee for a totally bogus patent claim. It worked well, until they got greedy and went after bigger fish who fought back and made it costly for them to make bogus claims.

When that was the worst corporate theft we had to worry about, in hindsight, it really wasn’t that bad.

Considering that today the Big AI players are stealing all of your copyrighted and corporate data and using it to train their systems in the best case, then using those trained systems to output similar derivative works for their profit in the average case, and allowing shareholders and foreign governments to access it in the worst case, the patent pirates don’t sound so bad — you had to have similar software for them to even consider targeting you!

The posts on your private sites, the published articles in major publications, and the books that took you years to write are being sucked into these LLMs without a penny of royalty to you or your publisher. If you’re an artist, they’re stealing your entire catalog from Youtube, Spotify, etc. to train their music generator app to output music that sounds like you (just with worse lyrics, off tones, and no heart or soul), and if you’re a corporate enterprise — everything on your website, in your emails, and in your private meeting notes for meetings you send your AI assistants to for note-taking purposes. Once they speech-to-text those meetings, all of the output is fed into the LLM training archive for “future improvement” before it is summarized and fed back to you.

Now, if that AI platform is owned by a company based in the USA, it doesn’t matter if the instance you’re using in the EU is hosted in the EU — US law gives them the right to access all your data at any time. And if you’re an American accessing DeepSeek … all that data is passing though Chinese government servers!

So not only are they using your information without your consent and without compensation, since the majority of the big players are in the US, they are using it without any repercussions as the US Federal Government put a 10-year moratorium on AI legislation, basically allowing these companies to steal all your data without consequence for the next decade! Because, even if they say it’s “just for training”, we all know that training data leaks out of LLMs with the right prompts in the right circumstance. There is no safe “just for training” instance, so if the data is your copyright, they’re giving it away for free. And if the data is your trade secret, its a trade secret no more!

And there’s nothing we can do! Our only hope is for every major publishing house and media company that does business in every country outside of the USA and China with copyright and IP protection legislation to launch lawsuits in those countries against these global AI companies that are stealing their IP and copyright and serving it up outside the US. Force them to defend hundreds of suits across the global stage, while lobbying other governments to create stronger protections and mandate consent before using content, and penalties for violating the law equal to at least 10X what the fair market value of the content is. Since the market won’t bankrupt these companies that shouldn’t exist based on the fact they lose more every year than 99.9% of businesses generate in revenue, let the media industry and legal systems do it.