Category Archives: rants

Stop Buying ORCestration. You need Orchestration!

In our last article we told you that the majority of today’s platforms attempting to unify the Procurement application space for you are not Orchestration platforms but ORCestration platforms, integrating your applications in a manner that is forceful, ugly, and impure, to say the least. Definitely not what you need in a modern orchestration platform.

A real Orchestration platform is:

–> Light

They aren’t adding another bulky SaaS platform with its own deep stack requirements, vendor maintenance requirements, data store requirements, and rules engine which must not only be maintained separately, but replicate data and rules across the apps it connects. It’s a truly next gen platform, built up from only the (micro) services necessary to connect the apps and accomplish the tasks. It’s a composable container community, not a 100 room palace with no option in between.

–> Cheap

Next generation platforms, built on modern distributed architectures, and built to work behind the scenes (not in front) to allow the users to access the ecosystems they need to access through the applications they are comfortable with, won’t be million dollar applications. They’ll be a fraction of that as the organizations will be buying just a configurable framework, that they can configure themselves as needed, and not a full, heavy, SaaS application with all of the required support infrastructure just to keep it operational (regardless of whether it integrates any applications or not).

–> Flexible

Workflow can be built up, torn down, and put back together on the fly, as required to support evolving processes. Intake, UI, and integration can all be defined, and redefined, as processes evolve, new applications enter the landscape, and old applications leave. The organization is not restricted to a fixed intake screens with limited configuration, predefined workflows, or limited data formats.

–> Open

Built on composable micro-services, that are fully documented and compatible with modern stacks, they allow anyone to build the necessary integrations, workflows, and data manipulations necessary for true process orchestration. They also support the definition of contexts that allow them to be natively compatible with the data structures of the applications they are integrating. And one definitional mistake won’t bring down the whole platform because it’s not a monolithic megalith built on a house of data cards.

–> Real-Time

Not only are data pushes and pulls accomplished in real time, but the orchestration platform will automatically propagate data updates to all apps that maintain a copy of the data. Moreover, when an input the orchestration platform is an initiator of a process, the entire process will be executed without explicit instructions as each output will trigger the next step and serve as the input for that step.

–> Execution

Real orchestration platforms don’t connect apps in workflows, they execute workflows, and they do so dynamically based upon the inputs and outputs of each step. They adapt, and when transactions occur that cause exceptions that require human intervention, they learn from those interventions and dynamically construct new exception workflows on the fly, ensuring that no specific exception ever has to be manually dealt with twice.

–> Blockchain

It will support blockchain at the core, allowing not only for the integration and processing of arbitrary data records, but for immutable data objects to be input, created, and output — with a full history of what app did which change when. That’s a lot more than you can say about today’s ORCestration platforms.

–> Multi-Protocol

Not only will the orchestration platform be composable from the core up, but the building blocks will be designed in such a way that they can be composed to support all of the standard, obscure, and emerging protocols that might need to be supported. As a result, the platform will be able to integrate not only current apps, but emerging apps as well.

–> Organizational

A true orchestration platform is designed to support organizational processes and applications, not just Procurement, allowing the input (signal) data to come from any organizational system and be pushed to any other organizational system, bridging the gap between sales orders, POS demand signals, and demand planning and supply chain (re)order and logistics systems. True orchestration finally tears down the technology walls holding Procurement back, vs. today’s ORCestration platforms which just strengthen their foundations.

–> Secure

Not only are these platforms built on security at the core, recognizing both security standards AND security policies, including the security policy of each application that is orchestrated by the platform. This means that when a user initiates an action, it only executes if they have the appropriate (data) access in all of the applications on the orchestration platform that are needed to complete the action. No hoping, or praying, that the ORCestration platform encoded the right security checks in its native workflow.

–> Policy (Aware)

As per our last point, modern orchestration platforms will understand the concept of policy at the core, and not just for security — for compliance as well! The orchestration platform will integrate with all of the applications that contain encodings of the organizational compliance requirements, understand those compliance requirements in their native contexts, and ensure that all processes are completed in a compliant process.

–> Collaborative

The core of the orchestration backbone is designed to not only support application collaboration, but user collaboration across the organization, and even with connected parties in the supply chain, through the native support of internet communication protocols as well as all standard application messaging protocols. Collaboration will never be easier than with a true orchestration platform.

–> Resilient

Since it’s not just another megalithic SaaS app, but instead a (micro-)service platform built up from building blocks, one failed integration and even one failed block will not bring down the whole platform, the rest of the platform and apps will still work.

–> Process (Focussed)

Modern orchestration platforms are designed to support organizational enterprise processes end-to-end, not departmental functions end-to-end. They can integrate and orchestrate any application in the organization’s software ecosystem (all 1,000+ in a large enterprise) as well as any partner systems the organization has access to.

–> Exception (Orientation)

Modern orchestration is designed to quickly identify exceptions, invoke exception processes, and ensure humans are only involved for a here-to-forth unforeseen exception. Moreover, it will allow for the human instructions and guided process to be automatically captured and encoded to make sure that humans never have to teach the system twice.

Unlike yesterday’s ORCestration platforms, today’s (and tomorrow’s) true orchestration platforms are built on modern technology stacks, and future-proofed for tomorrow’s applications, not just yesterday’s.

It’s Orchestration, NOT ORCestration!

In fiction, Orcs are generally described as a brutish, aggressive, ugly, filthy, repulsive malevolent race of corrupted monsters, embodying the “hell-devil” (orc-néas) of Old English literature. Ever since Tolkien popularized them in his Middle Earth as the servants of Mordor, pretty much every work of fiction has described them the same way. Even though Tolkien himself said they understood morality, they tended to only apply it to themselves as they saw fit in their constant state of corruption, a theme that is echoed to this day even in Dungeons and Dragons and Warcraft (which are the fictional works most of today’s generation will associate Ocs with). While some may strive to be moral and better than others of their kind, they still remain warlike and barbaric by our civilized measurements.

As a result, to be ORCish is to be brutish, aggressive, and even repulsive in one’s actions and to be ORCestrative is to organize things in a way that is forceful, ugly, and impure.

Which precisely describes the majority of today’s platforms attempting to unify the Procurement application space for you.

Today’s ORCestration platforms are:

–> Heavy vs. Light
They add yet another bulky system to your stack that takes months to implement, must be constantly maintained, comes with its own data store and rules engine, requires its own user licenses and management, and exacerbates the app proliferation problem you’re trying to solve with yet another app.

–> Costly vs. Cheap
Many of these platforms charge on a per user basis, with fees that can easily be $250/user/year or more JUST for basic intake. If everyone in a large organization needs their own user license, which is, FYI, the only way to achieve true intake and enterprise wide orchestration, an average large organization will be spending 1.25 Million a year for what is essentially Middleware 3.0 with Intake! It might be saving you a few Procurement or ERP licenses, but, as all the fake Christians like to say, you’re just taking money from Peter to pay Paul. Good job!

–> Rigid vs. Flexible
Most of these platforms are very rigid in terms of workflow, configuration, intake process, UI configuration, integration options, etc. Most of them only permit certain actions (intake, process reporting, etc.) to be initiated through the platform. Instead of increasing organizational flexibility, you limit it.

–> Closed vs. Open
Some of these platforms are so rigid (and inflexible) that they won’t even allow partners to do new application integrations because if it’s not done just right, it could all crumble like a house of cards. Classically, middleware was supposed to open up opportunities, not close them down!

–> Batch vs. Real-Time
In most of these platforms, data transfers between the platform and the apps are typically done on a batch schedule and if you need data in an app right away, you have to a manual push-pull. Heck, even classical RPA works better!

–> Routing vs. Execution
All the majority of these platforms do is route requests and data packets from one application to another, requiring a (moderate to large) number of third party applications to do anything at all. You could replace their core function with a last generation workflow engine at a fraction of the cost without sacrificing that much actual functionality!

–> EDI/API vs. BlockChain
Not only is most data shared in batch after being routed using traditional workflow, but it can only be accepted, processed, and routed if it is shared in a classical data exchange format. Forget about integrating it with any modern systems that use blockchain for traceability or e-payments. Just Fuhgeddaboudit.

–> Single vs. Multi-Protocol
Not only are the majority of these platforms limited to classic EDI/APIs for data interchange, but they tend to run off of a single protocol for network and stack integration. This not only limits them to one stack, but prevents them from being forward-compatible with next generation technology that will need to support multiple stacks (LAMP, MEAN, MERN, Django, etc.), multiple classic protocols (including HTTPS, DHCP, ICMP, SNMP, etc.); specialized protocols like BGP and OSPF; and emerging protocols like MCP.

–> Departmental vs. Organizational
Today’s platforms are being sold as the answer to your Procurement needs by providing you with an interface to all of your Procurement systems — that have already been integrated. But here’s the problem — just integrating your Procurement systems doesn’t meet all your needs! The inventory is in the inventory management system, the lead time in the logistics system, and the forecast in the demand planning system, and these are all part of the supply chain systems. All today’s platforms do is force your existing best of breed applications into a hodge-podge frankensuite. You might as well stick with a mega source-to-pay suite and buy a license for everyone in the organization, especially since some of them were built with intake in-mind (as long as you buy a license for every organizational user).

–> Insecure vs. Security-Aware
Of course the platform comes with its own security, on its SOC2 certified servers, with a secure log-in for every user, but that’s the only security it recognizes. It doesn’t recognize the security of any of the applications that are integrated, beyond the API access key. This means that all of the data available to the platform through the key is available to all of the users of the platform, whether or not they should have access to that data, unless the security policies are replicated in the platform.

–> Rule-Based vs. Policy Aware
Not only do each of the connected applications have their own security protocols for data access, but their own policies for compliance. With regards to some data, such as third party personnel profiles or employee communications, not only is the data restricted to certain people, but they must have reasonable cause to view it, assert that cause, and possibly log the proof of that reasonable cause. Also, some pricing data must be restricted to authorized parties to prevent unauthorized disclosure to competitors, etc. The majority of these platforms can’t even implement basic policies yet alone enforce (compliance) policies in the apps they integrate.

–> Autonomous vs. Collaborative
While all of the applications are integrated to the fancy middleware, they still all function autonomous, usually unaware what other platforms are connected, who needs to use and is using the data and outputs of the platform, and where the inputs come from. All they know is that some piece of mysterious middleware shoves data in, executes API calls, and pulls data out. They don’t know where it’s going, how many copies are being made, and how, and even if, those copies are being maintained. The autonomous aspect of each connected application amplifies the data nightmare of the Procurement organization as well as the readiness for next generation Procurement.

–> Brittle vs. Resilient
Most of these platforms are constructed like traditional SaaS apps and have al the same weaknesses. When they go down, they go down, and so do all their connections. Like the One Ring, they are invincible until the One Ping overloads the stack and they come crashing down.

–> Function vs. Process (Focus)
Business run on processes, but these ORCestration platforms still focus on pushing data into, executing through API, and pulling data from functions. The better platforms support end to end Procurement functions, but they are still only functions, because the whole point of Procurement is to support the organization, which means that the process goes beyond the four walls of Procurement. They need to elevate the functions in the apps they connect into process flows, but they’re not doing that.

–> Task vs. Exception (Orientation)
The whole point of software is automation and freeing the user from tactical data processing and thunking that computers are great at so they can do the more strategic and relational work that computers are poor at and can’t do at all! Considering automation in these platforms requires users to manually define workflows, including workflows for exceptions, one by one, they don’t do a very good job of empowering the user.

Today’s ORCestration platforms are the engineering equivalent of trying to fix a break in a line with spit, glue, and duct tape. It might work for a bit, but it’s not going to take much force for the “fix” to fall apart!

Technology is the MOST Wasteful

In a comment to a post on LinkedIn, THE REVELATOR asks: “What things or products should be built to last but aren’t, and why?

The answer to what is simple. The technology products we use everyday. Our smartphones, tablets, and laptops.

There are no cross-platform standards (beyond a few cable standards the EU finally implemented to stop Apple from forcing you to buy a new charging cable and wired earbuds with every f*ck1ng iPhone release), no modular design because vendors want lock in, 2 to 4 year upgrade cycles, and the ability to sell you something lighter and thinner, even though it doesn’t matter beyond a point. If we could upgrade the memory, storage, AND CPUs, we could double or triple device lifespans since we’re pretty much hit the limits for bus speed as well as scale.

While this is not a full history, and I may be a few models, and maybe even a year, off, the original Pentium* was 66 MHz in 1993. It wasn’t until 2001, with the Pentium III, that we hit 1 GHz. But shortly after, the Xeon hit 2 GHz (and it could be overclocked to 3.6 GHz, but not recommended). Then around 2005/2006, we got 3.X GHz base speed with the high end Pentium D and Pentium Extreme. And the speeds really haven’t increased since (even though the cost of speed has decreased over time).

However, our mobile devices aren’t designed to support any of these upgrades (and the chips are not designed to be backwards architecture compatible to force you to upgrade every few years).

The reality is that our devices could last three times as long, but without planned obsolescence, which is the answer to the why, they couldn’t collectively take us for extra trillions they don’t need (since they just waste it on stock buybacks and Gen-AI anyway).

This isn’t the only example. Many things we make could be improved, and some things could be improved tenfold, but if bulbs were made to the highest quality standard, we’d never buy another lightbulb for our lamp in our lifetime, and probably waste a lot of good shoelaces (as we have been trained to toss them with a sneaker).

And the worst part about this is that this planned obsolescence seems to inform the vast majority of enterprise software design as well.

*And it’s still All About the Pentiums!

Procurement And Supply Chain are Drowning in Wannabes

We see it daily on LinkedIn.

Twenty-something founders on LinkedIn claiming their Configurable Agentic Gen-AI Enhanced Systems (CAGES) (with marketing messaging coming straight from the A.S.S.H.O.L.E.) will solve all your problems, although they don’t have a clue what those problems really are, and even if you told them, they wouldn’t have a clue themselves how to solve your problems because they have no real knowledge of, or experience with, Procurement or Supply Chain.

New-Age Influencers barely out of college giving themselves nicknames like the Supply Chain Sovereign or Sourcing Sorcerer and promising you best practices and deep insights in your daily email but who have never stepped foot outside of the big consultancy and don’t know anything beyond the 7 year old playbook they were given.

Advertisements from the Big X Consultancies or “Next-Gen Analyst/Services Firm” promising to replace your workforce with AI Agents, despite the 95% failure rate (as only 5% of AI projects have led to a return, which is 2.5 times worse than a traditional technology project, where a whopping 12% are now delivering a return), and somehow do so cheaper (despite the soon to be exponentially rising costs of LLMs as compute costs go through the roof due to a lack of energy to power them and water to cool them).

As so astutely pointed out by Mr. Koray Köse’s in his recent article on how our supply chains are literally drowning in wannabes who mistake theory for expertise, when the gap between their theory and reality could never be wider!

In theory, Procurement is easy. In theory, Supply Chains are smooth well oiled machines where I order X from you, and you ship it to me. In reality, nothing could be further from the truth!

Nothing makes the point clearer than when Mr. Köse points out that most of these so called “experts” could not pass his Economic Order Quantity (EOQ) exam question, which is totally correct, as I will dive into in a future post. (This is because, among other things, 1. the classic “textbook” formula isn’t always right, 2. doesn’t understand volume breaks and supplier economies of scale, and 3. requires you to be able to do actual math and logic to figure it out.)

Mr. Köse’s excellent article reminded me, as Bob Ferrari and I pointed out in a joint series in late spring on how Legacy Sourcing and Planning Solutions Struggle with Supply Chain Challenges, Direct Procurement is Failing. There are three big reasons for this:

  1. Direct Procurement CAN NOT be cut off from supply chains, as we outlined in detail in our 7-part series.
  2. Everything Mr. Köse’s addresses in his post!
  3. Most Analysts and Consultants fall into this fake “visionary” and “guru” category as well! (They’ve never worked in supply chain or worked hand in hand with experts with decades of experience trying to build useful solutions for those experts to use. One of the best example of this is when these f6ckw@ds use third party analyst firm studies to tell you that your headcount is too low or too high or your tech investment too low or too high without having an actual clue what your company actually does or what your Procurement and Supply Chain personnel actually do. [These Masters of Business Annihilation believe they can manage off of a spreadsheet when, again, nothing could be further from the truth. There’s a reason that the first Gilded Age was ruled by Engineers, they actually knew how to run a company! All today’s financiers can do is take a company with stratospheric profit potential and have it come-apart mid-flight, with Boeing being a prime example — if Engineers were in charge, planes wouldn’t be falling apart in the sky AND the revenue and profits would be a lot smoother!])

Over the summer, Bob and I reviewed over 40 recent studies from the past 5 years from big analyst firms and consultancies on the state of Procurement & Supply Chain — and they all have the same two things in common:

  1. they all tell you about the same barriers/roadblocks, risks, concerns/priorities, and talent gaps that are facing Procurement and Supply Chain
  2. they don’t tell you what to actually do to solve these issues (except, of course, “drop Agentic Gen-AI in” because that will “auto-magically solve everything“) because they don’t have a clue how to address these real world problems!

(Right now we’re trying to figure out how to write our next series, or maybe book, on how you actually address the issues with real process and real supporting technology to get results, assuming, of course, you have real talent that’s been-there, done-that and not these tech-bro AI hipsters that literally can’t create a PO [or even read a contract without putting it through faulty AI first]. It’s quite challenging because, apparently, no one has actually tackled writing something truly helpful before in our joint space and we’re struggling on how to make it useful and digestible in the age of marketing sound-bites!).

The reality is that, just like Procurement has not changed since the first handbook was published 136 years ago, neither has Supply Chain! While Mr. Köse doesn’t explicitly say this, he does allude to the fact that we’ve had global trade for THOUSANDS of years and we’ve always had the same challenges (that revolve around geo-politics, risk, cash-flow, and trust) — it’s just that we’ve replaced paper with digital bits and found new ways to make it more complicated. However, the processes, goals, and realities are the same — and you’d know that if you ever actually worked in or supported global supply chains (and not just pretended you understood what they were to try and sell your shiny new tech toy)! If you don’t understand this, you’re going to continue the 25 years of project failure (where the technology project failure rate is now at an all time high of 88%) and possibly be the next great tech-led supply chain disaster!

Finally, Mr. Köse was right again! Orchestration really is just clueless for the popular kids, selfies included!

P.S. If you haven’t figured out yet that you should be following Mr. Koray Köse on a weekly basis, then figure it out now. You might think that some of his forays into geopolitics or broader supply chain is not all that relevant to your daily Procurement tasks, but the reality is that if you don’t keep up with what’s going on in the world and how that could impact your supply chains beyond tier 1, you’ll be in for a real shock to the system. This is because, when you least expect it, a critical product or component won’t show up, the supplier will be unresponsive, and you’ll have no notice that you immediately need to find a replacement (but because that supplier controlled a significant percentage of market share, there won’t be one). Unlike Billy Idol’s shock to the system, yours won’t feel so good when this happens. (But if you keep up with major events, you can identify those that may impact your supply chain, verify or disqualify, and then start working on mitigations for those that might impact you significantly before it’s too late.)

Why Big Analyst and Big X Consultancies SUCK …

In a post on LinkedIn a while back, THE REVELATOR indicated that the real reason Gartner sucks (and that their stock dove 30%) is because, at the end of the day, they aren’t very good at tying advice to outcomes (and likely don’t even attempt to do it at all most of the time in ProcureTech). But in all fairness, that holds true of all the Big Analyst firms and Big X Consultancies. Also look at Forrester and IDC reports — it’s always the same old vendors or the hype of the day, whether or not that hype is delivering any value whatsoever. (And the answer is “very little” for intake and orchestration — because you can’t orchestrate an empty pit and if you attempt to orchestrate an elementary music class, be prepared for the migraine of your life — and essentially none for Gen-AI, with MIT pointing out that only 5% of deployments are delivering any value whatsoever.)

But it’s not just the Big X analyst firms. It’s the Big X consultancies as well! Now, I know you are saying “but surely they do better, they are consultants, they do projects, they have best practices, and they’re paid for results” and while that is all true,

  1. they’re not all experienced consultants (and the number of juniors on many projects is scary — I’ve heard too many stories about a PE firm trotting in a McKinsey or Accenture* after a big acquisition (because it’s their standard acquisition playbook) to optimize and rightsize operations who come in with a team of 20, of which only two actually provide value beyond what the company already knew. One of the biggest companies in our space literally marched them all out at the end of the day and told them NEVER to come back because when it came to ProcureTech expertise, they identified one individual (the project lead, who they’d likely never see again) who was sharp and got it and would definitely be able to add value if entrenched in their operation, one (his right hand man) who was smart, hardworking, and capable of learning fast and who might be able to add value, and 18 juniors who didn’t know anything that wasn’t in the 7 year old playbook on Procurement handed to them when they started, a playbook this company had rewrote multiple times over the years)
  2. they don’t all have deep relevant project experience in Procurement (or whatever business function you’re bringing them in for) in your Industry
  3. their “best practices” are super generic so they can be applied across the board, which means they are not tailored for your industry and definitely NOT tailored for you (so they are not best)
  4. and they are paid on promises of results, which sometimes don’t materialize

Just like I keep saying it’s not the analyst firm, it’s the analyst, it’s not the consulting firm, it’s the consultant, and the sad reality is that the bigger the firm, the smaller the percentage of senior experienced talent in that talent pool, as the best talent who don’t make partner (and then have to focus more on managing and selling than project delivery) are constantly recruited by clients, consultancies, and even tech companies or the ones able to go out and join/build niche consultancies. There ends up not being enough senior, experienced, talent to go around and you’re essentially playing the lottery that one of these resources will end up full time on your project.

Since these consultancies want to be outcome focussed, in an effort to do that with more junior people, what ends up happening is they end up writing the advisory playbooks as metric focussed — what percentage of spend is on personnel in a best in class, what percentage of spend is on tech in a best in class, and what is the typical breakdown of headcount and tech spend by module or platform. Then, they tell you:

  • your headcount spend is too low, so you need to go out and hire X people in Y roles because, well, metrics and statistics and that will help because of scripted reasons (more sourcing pros mean more events mean more savings, more supplier managers mean better quality, etc.)
  • your headcount spend is too high, so you need to fire X people in Y groups because they must be tripping over each other and/or bringing your profit margin down
  • you aren’t spending enough on tech, so go spend 10 Million on Gen-AI and that will automagically fix everything
  • you are spending too much on tech, so go out to bid for a new ERP, S2P suite, orchestration platform, etc. because you obviously didn’t go to market right when you bought your current tech

Not realizing that

  • the headcount needs differ in every industry AND every company
  • the tech needs differ by industry, company, and process
  • it’s not spend, it’s ROI per spend

and this means

  • you might only need one supplier data manager in commodity indirect because there’s always three more suppliers waiting to supply you the same thing
  • but you might need ten supplier relationship managers in direct, each managing a different supplier (pool) producing a different, custom, component for your advanced engineering or biomedical device
  • you might not need best in class optimization backed sourcing for indirect because automated auctions will get you market price every time
  • but you might need best in class optimization, analytics, and market should-cost modelling platforms to get a grip on your direct sourced custom designs
  • and sometimes spending more on headcount and tech than across-the-board “average” yields a significantly better return because your quality stays high, stockouts only occur during global disruptions, your data processing is 95% automated freeing your staff to focus on strategic issues, etc.

But what can we expect from fresh grads with little mentorship (who are rushed into Gen-AI “training”) who get all of their insights from these Big Analyst firms that

  • publish quadrants and waves that are completely unrelated to reality for the majority of companies with the same 10 to 20 large vendors every year that only work for select large enterprises (and the other 40 to 80 vendors continue to be completely ignored),
  • constantly push and promote context-free (Gen-)AI, despite one of these firms publishing a now buried/deleted study a few years ago that stated 85% of AI projects fail and the recent MIT study that tells us, no, in fact, 95% of these projects fail to deliver any value, and
  • unless you get one of the few analysts who actually gets it, employ playbook-based responses to inquiries that don’t have any context (because the analysts don’t have any time to create tailored recommendations to context because they spend too much time doing basic data collection where 80% of it could be captured in a survey monkey tool [or 95% by a well trained SLM {or, better yet, classical semantic tech with provable accuracy rates} that could map free text to standard process needs and vendor solution categories for easy verification and correction by a true human expert]).

The reality is that until

  • big analyst firms and big consultancies admit their flaws,
  • start tying actual outcomes to the standard projects/recommendations they made, and
  • start analyzing and using these results to tailor recommendations to their clients that have a good chance at actually delivering value

these firms, and their standard recommendations, are going to continue to suck and your chances of success are going to remain at 12% for standard projects and 5% for Gen-AI projects.

Sad, but true.

* not realizing that the reason the company was such an attractive acquisition target in FinTech/ProcureTech was because they already knew all the best practices that the big firms have in their playbooks and were employing them effectively; these Big X tend to do well on average companies that are not best in class or deep in modern process or technology