Category Archives: Orchestration

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!

Stop Being Clueless. It’s Time for Revenge of the Nerds!

Last week we tried to further demystify the marketing madness for you by clarifying that spend orchestration is essentially Clueless for the popular kids.

This is really important because there is no difference between a “spend” orchestration and a plain old “regular” orchestration provider, and neither provides any value whatsoever if you don’t have any spend management (i.e. procurement) systems in place to actually process the spend. Otherwise, the best you get is intake to nowhere … which just provides your stakeholders yet another avenue to ask “where’s my stuff” and another reason to say “I thought this new system was supposed to make you more efficient” and get more impatient when their stuff doesn’t arrive any faster.

In other words, unless you have a hodge-podge of best-of-breed systems that cover most, if not all, of the source-to-pay process, that don’t interconnect, and the systems are old and don’t support multiple roles (or charge full license fees for each user, even a 99% read-only role, that access the users), there is no value in an orchestration, as we’ve said many times (including in our post on how Marketplace Madness is Coming.

What you need is not spend orchestration but spend defenestration — you need to throw any and all unnecessary spend out of the window, and that requires spend investigation, need verification, negotiation, observation, and payment verification. That requires spend analysis, demand forecasting and management, fact-based market insight, adherence to contracts and plans, proper procurement platforms, and proper payment validation platforms.

Moreover, it requires proper utilization of these platforms. And that requires Human Intelligence (HI!), skill, and deep (deep) Procurement knowledge. Geek skill and Procurement nerdiness. The nerdiness to use a best-in-class spend analysis and seek out the opportunity that a pre-packaged analytics routine will never find (because you’ve already stared at that report ten times and found nothing after the second time [wonder why?]). The nerdiness to examine the forecasts and use best-in-class forecasting techniques on real (and up-to-date) sales and market demand data. The nerdiness to pour through market cost data for materials, standard overhead costs, energy costs, water costs, differential costs for different production models, and cost models presented to you by third parties and the supplier to pinpoint the right the model, the right data to feed it with, and the true production cost at different volume levels — and then use this in a fact-based market data negotiation. Then, when you cut an agreement, the nerdiness to make sure it is encoded in the right systems and properly executed on as well as the nerdiness to follow the market over time and detect any inflections that would require you to change direction. And, finally, the nerdiness to make sure the platform is configured to properly m-way match every invoice, detect any attempts to fraudulently change the amount, terms, and payee, and only pay for goods and services received on the agreed upon schedule. In other words, if you want to truly succeed at Procurement, forget about the Clueless — It’s time for the Revenge of the Nerds!

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.

Don’t Zip Through the Zip-sponsored Spend Matters authored Intake and Procurement RFP! [2024] (Collected Links)

Don’t Zip Through the Zip-sponsored Spend Matters authored Intake and Procurement RFP!

Please note this is NOT coverage of Zip. See this post for Zip solution coverage!

BONUS

BONUS 2