Category Archives: SaaS

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!

If You Want Proper Solution Selection Advice — Hire the A-Team!

In 1972, a crack commando unit was sent to prison by a military court for a crime they didn’t commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, still wanted by the government, they survive as soldiers of fortune. If you have a problem, If no one else can help and if you can find them. Maybe you can hire, The A-Team.

Forty years ago, if you had a problem, you could hire the A-Team, and get a solution. They did what they were supposed to. That’s because there were only a few solutions; developers, implementors, and consultants worked under the same roof on the same team; and, due to the high price tag, the vendors worked hard on delivering enough value to keep their clients and get referrals for new clients.

But then the World Wide Web was invented in 1989 and by 1999, corporations were starting to embrace it not only for online business but for app delivery. SaaS startups burst onto the scene and we went from a few options to a few dozen to a few hundred options for standard office applications within a decade. At the same time, many doubled down on development, not implementation or integration, and implementation shops sprung up. Then consultancies decided that, no matter where they started (strategy, finance, operations management, etc.) they were all going to be technology advisory experts and opened big technology consulting and implementation shops, because they had the size, and the cash, to hire lots of warm bodies fresh out of university desperate to work for a renowned firm.

This is where and when solution selection and advisory began to break down. First of all, the consultants had no deep knowledge of the solution. Second, they had no deep knowledge of the domain. Third, the selection and advisory consultants had little understanding of the implementation requirements. And, due to a lack of deep economic and supply chain knowledge, they all ignored the increasing complexity of global business, the increasing complexity of the software solutions designed to support global business, and the increasing complexity of interaction across platforms and systems.

That’s why you need … The A-Team!

THE BRAINS

First and foremost you need someone who understands the big picture. The domain, the core processes that power the business functions, the levels of operational maturity and how to assess them. Someone who knows how to get to the core of the problem and what is needed in a solution and can lead the team to successful execution. This person ensures the focus is on what’s needed, which is often different than what you might think you want. That the inputs to each successive phase of the selection process are the right one. That the requirement strands flow from initial collaborative root problem identification all they way through final solution implementation and integrations. Someone who ensures every step of the process is designed to maximize your chance of success while being as efficient as possible. Someone who’s always thinking about you.

THE SMOOTH TALKING FACE MAN

Secondly, you need someone who can converse with all of the stakeholders in their language, put their fears at ease, and foster the necessary collaboration between themselves and the solution selection A-Team to help ensure a successful project. Someone who can is capable of securing the data and resources that are needed when they are needed and navigating the tough scenarios when vendors who don’t want a fair and unbiased selection process decide to get down and dirty and bypass the CPO and go straight to the CFO or CEO with fear tactics or unreasonable ROI promises. Someone who’s always there when the client needs someone to be there.

THE HOWLING MAD CRAZY TECHIE
(WHO CAN BUILD AND OPERATE ANYTHING)

You need someone who has a deep understanding of the technology to identify vendors that supply tech that match your should haves, to help you script the demos, to rip apart the RFX responses and demo claims, and give you real, unbiased, solution — and not marketing — based advice. Understanding that goes well beyond the limited knowledge you get as a solution implementor where all you do is set configuration options. You need someone who was trained in tech (not operations, or psychology, or “business” or whatever else gets them into consulting), who built tech from the bottom up, who understands not only what stacks can deliver but what algorithms can deliver, and can assess not only what the tech does now but what it will actually be capable of with further development (as many vendors will claim anything you need is on the roadmap, even though they know that they are not capable of building some of the promised technology as their architecture just wasn’t built to support it).
In addition, this is someone who has spent a large amount of time reviewing and studying every solution they can get their eyes and hands on, not just a small set of clients or the big vendors that dominate every big firm analyst map. Some who loves tech and has lived tech their entire career from even before they entered university/college and through at least a decade of hands on experience (and at least five years of broad space review and experience).

THE TOUGH ONE

When the going gets tough, you need someone who can do the heavy lifting and brute force the project to conclusion. The critical support person who helps the brains with all the stakeholder interviews, ensures the crazy techie has everything he needs, makes sure the vendors get their responses in on time, and runs the project, through fear and intimidation if it comes to that, but usually with a strong, silent, honest-to-goodness resolve to get the project done right, no matter what. Someone who pities the fools not wise enough to engage the services of a team who’s only goal is solving your solution selection problem and moving on to the next engagement after a job well done (and not trying to find ways to hold you hostage and add endless billable hours to the project). Someone who alone has more heart then you will find in entire implementation teams.

But if you don’t believe me, go ahead and keep hiring The F Team. You might be part of the 12% they succeed for (or 6% if its a Gen-AI project). That’s at least a one in ten chance of success for a regular technology selection and implementation and one in twenty chance of success for a Gen-AI technology selection and implementation. Still better odds than the lottery, right?

Myself, I’d prefer odds of success of at least 4 in 5. But, as they say, you do you.

The Seven Step Process for Vendor Assessment and Selection

In our last posting we told you that solution selection is a seven stair methodology, and that the vendor assessment step was itself a seven step process. It’s not just as simple as taking a vendor pool, pulling five names out of a hat, and issuing an RFP, even though some consultancies would like you to believe that it is. But all that does is get you to a wrong conclusion fast.

Vendor selection takes time, sometimes longer than you want, but when you get the right solution, it’s always worth it in the end. Here’s the process outline.

1. RFI Creation

The first step is to create an RFI that accomplishes two things:

  1. verifies the vendor has the necessary must-have functionality to meet core needs
  2. collects the necessary information for rapid fire vendor elimination so you don’t waste time on a vendor that the business can’t accept

2. Collaborative RFI Review

Once the consultant or the analyst does their initial review, does their initial scoring, draws their initial conclusions and documents the rationale, the next step is to work through the RFI collaboratively with the client to make sure that every vendor invited back is not only acceptable to the client, but both parties understand the reason why vendors were cut.

3. Qualifying Demo

Before the full RFP, a demo verifying the promised must-have functionality must be taken to make sure what was written is currently in production and that the vendor truly understood the requirements. This can be considered phase two of the rapid fire elimination phase and strengthens the reasoning for any vendors pushed forwards.

4. RFP Creation

The next step is to create a full RFP that:

  • goes beyond the core and includes questions related to the should-have and value-add functionality appropriate to your needs (not some random feature list)
  • allows all organizational requirements for vendor onboarding to be evaluated
  • allows for an assessment of the depth and breadth of services and training provided by the vendor
  • contains additional questions designed to elicit the input necessary to answer any questions that come up from the RFI and initial demo review
  • address all of your business requirements (not just the ones that permit rapid fire vendor elimination)

5. Collaborative RFI Review

Once the consultant or the analyst does their initial review, does their initial scoring, draws their initial conclusions and documents the rationale, the next step is to work through the RFI collaboratively with the client to make sure that the client’s final two/three vendors are not only appropriate, but all of the strengths and weaknesses that can be assessed are understood.

6. Deep Demo Specifications

You need to give each vendor their own demo script that you want them to execute because it’s your problems you need to see solved, not their best whizz-bang features that look good but function poorly.

7. Decision

After the consultant provides their deep dive analysis of the demo and their overall vendor assessment, using all the information at your disposal, you make a decision that you believe will best serve your organization.

In other words, it’s a methodical, deliberate, process that takes what it takes because that’s the only way to ensure you get the right solution. But it will be worth it because the right solution will bring an ROI of at least 5X while increasing efficiency between three-fold and ten-fold once adopted, but the wrong solution will be an albatross around the necks of every employee that depends on it.

Assisted Solution Selection is a Seven Stair Methodology

… and skipping any step breaks the strands that are necessary for success.

And the process is a lot more involved than most consultants or analysts believe it is. But first, let’s outline the steps the consultant or analyst has to walk through if they want to reverse the odds and give you an 80% chance of success vs. an 80% chance of failure.

1. Real Need Identification

We’ve all forgotten the wisdom of Richards and Jaggaer, and the realities of life. You Can’t Always Get What You Want but if you try sometimes you just might find that you get what you need. But you have to try. And so does any consultant or analyst who purports their desire to help you.

2. Holistic Solution Requirement Assessment

This is NOT technology. Not even close. This is identifying what results would define a solution, what processes would get you there, and what resources — people AND technology — are needed to get there.

3. Organizational Maturity

The solution has to be appropriate for the organizational, and technical, maturity of the organization. If someone has only ever ridden a horse to get from point A to point B, you can’t drop them in a Boeing 737 cockpit during mid-flight and say “good luck”. But that’s what happens in the vast majority of technology solution identifications and implementations — an organization running off of email, spreadsheets, and word documents is being told to upgrade to a modern best-of-breed AI-orchestrated source-to-settle platform with advanced optimization models, multi-stage analytics, twelve-step supplier onboarding and evaluation, 360 risk and compliance, multi-channel procurement, AI powered payments, and features with no apparent use. The solution has to be matched to the organizational capabilities with an future upgrade plan consistent with the rate the organization should be capable of maturing.

4. Vendor Pool Selection

The vendor pool has to be a set of vendors that meet all of the core requirements identified in the holistic solution requirement assessment, in a manner appropriate for the client’s organizational maturity. Clients should NEVER have to evaluate whether a vendor meets the core requirements, but how it meets the requirements; what should, nice-to, and value-add functions are included in their offering; and how they can effectively be a partner, and not just a provider, to your organization.

5. Vendor Assessment Process

A seven step process that centers the RFP and helps the client make the right selection.

6. Project Assurance

Processes that stop at the selection of the vendor can cut the chances of success in half. Implementors don’t understand how the conclusion was reached, vendors don’t understand the client’s unique situation, and neither are incentivized to ensure success. Independent, unbiased, project assurance is key.

7. Post Implementation Monitoring, Advisory, and Training

A successful implementation does not guarantee success — that requires adoption, continued utilization, and results. That might require training, that might require ongoing support, that might require additional advisory. There’s no success until an ROI is achieved.

Moreover, each of these steps needs to be powered by an appropriate model and methodology that is standardized, domain appropriate, and continually enhanced by firm knowledge and best practice. Not just a seat of your pants assessment entirely dependent on the individual’s knowledge and experience.

Furthermore, each of the models and methods used in each step has to build on the outputs of the models and methods of the last step so that each implementation requirement can be traced all the way back to a need and each need can be traced all the way forward to an implementation requirement. If you can’t trace complete “strands” from end-to-end, you can’t expect success.