What is Procurement Orchestration?

The idea of process orchestration is not new.  The ability to automate the coordination of digital processes arguably began with the introduction of cron for Linux in 1974, which simply allowed developers to trigger simple processes according to a pre-defined schedule.

Since that time, we have seen the introduction of relational databases and data warehouses, the broad adoption of RESTful APIs, and the introduction of low-code / no-code development platforms. These have made it possible to coordinate highly complex processes with relative ease. But at its core process orchestration today is not fundamentally different from what it was in 1974: the ability to automate the coordination of activities across systems, processes, and teams in order to achieve some well-defined business outcome. 

On the one hand, when we talk about procurement orchestration, all we mean is the application of general process orchestration principles and tools to procurement use cases. It's the automated coordination of people, processes, and systems to ensure employees get what they need without frustration. 

On the other hand, however, procurement has several unique characteristics that have strong implications for how orchestration is considered and implemented:

1. Complexity - As the adage goes, you have to spend money to make money.  Procurement processes affect and involve every function within an organization. They involve multiple levels of approval across various business units, they involve negotiating and contracting with external suppliers. They need to manage various kinds of risk, and they need to ensure alignment with business strategy which can change suddenly at any moment in response to shifting market conditions. What this means is that there is potential for huge improvements to operational efficiency (decreased spend, shorter cycle times) if systems are properly integrated and coordination activities are automated.
2. Expectations - A major reason that people are often frustrated with procurement is that they don’t understand it. Their only point of reference often comes from their personal lives, in which they have become used to hitting a ‘buy now’ button and awaiting delivery within 24-48 hours.  Why can’t business buying be this easy? On the one hand, frustration comes from a lack of understanding: the need to manage spend and mitigate risk means that the vision of a ‘buy now’ button for business is irresponsible except, perhaps, for that 30% of purchases that can be completed via catalogs.  On the other hand, however, they’re right.  A lot of what contributes to lengthy cycle times – and frustration - are manual and kludgy processes necessary to coordinate systems and collaborate across teams.  More often than not, these take the form of emails, instant messages, and spreadsheets. By more effectively orchestrating processes, we can get cycle times to a minimum and eliminate user frustration because every stage and step is both necessary and completed with utmost efficiency.
3. Budget - Despite the complexity and importance of procurement, as a function, it has traditionally had to work with pretty tight budgets.  For that reason, even though orchestration tools and technologies have been around for a long time, they have traditionally been expensive to license and require significant development effort (and cost) to implement and maintain. Procurement has been sourcing orchestration tools for many years, but the cost of these tools has meant that they have been largely reserved for mission-critical processes involving very high transaction volumes.  It is only now, with the decreased compute and storage costs and the broad availability of no-code development tools that procurement is now in a position to realize the benefit for themselves.

What this means for procurement orchestration (as opposed to process orchestration more generally) is that it needs to have a particular set of characteristics:

User Experience

The user experience (UX) philosophies of general-purpose orchestration platforms tend to fall into one of two categories: (1) customizable or (2) prescriptive.  When vendors talk about the benefits of a ‘pixel-perfect’ UX, they mean that the user interface (UI) can be customized so that it conforms 100% to a given design system, and that it can be tailored to meet the exact specifications of whomever is building an application. The problem with this approach – aside from the fact that UI can take a long time to build and is hard to upgrade because business logic is frequently built directly into the UI - is that the end user is not at the center.  Instead, what tends to be at the center are either existing design standards or the whims and preferences of the development team.  

On the other hand, where an orchestration platform has a prescriptive UI, development times are decreased, and technical debt is minimized, but there is no such thing as a general-purpose UX.  And, indeed, when you look at platforms that are meant to be use-case agnostic, their roots always show. If it was originally built as a ticketing system for IT service management, then it will tend to treat every use case as if it were a ticket. If it was originally built to support call center operations, then it will treat every user as if they are a customer service agent.

When you are a hammer everything looks like a nail.

The best approach to UX in procurement will be a prescriptive one, but one that is specifically built for procurement use cases. That way it ensures that experiences are optimized for the particular needs of procurement professionals, their partners in finance, and stakeholders who just want to request, review, approve, and process with ease. 

Of course, when we think about a UX built for procurement, it is important not to confuse it with UI. A user interface is an important piece, but many aspects of the overall experience will not involve a UI at all. In fact, much of what takes place in order to ensure an effortless experience takes place 'under the hood.' The important thing is that every part of the procurement experience, whether it involves a UI or not, puts the procurement user at the center.

No-code Built for Procurement

You don’t need a low-code platform for process orchestration.  We were orchestrating processes long before low-code was even a thing. A lot of modern business process management systems are low-code, but in this, they are built primarily for professional developers in order to improve their productivity. Despite marketing to the contrary, they aren’t particularly easy to use if you are not a trained and certified software developer.

But procurement departments don’t just need to orchestrate their processes once and for all. They require agility to improve processes, embed new business rules, and update policies in the face of external legislative conditions and changing business strategies. They need to be able to create and update workflows fast.  But they also need to limit costs, as very many procurement departments function on shoestring budgets.  As long as procurement is dependent on IT or system integrators to make every single change, not only will it mean that changes take a long time to execute (because IT is busy, requests need to be prioritized, and procurement is often deprioritized in the face of more mission-critical priorities), but it also means high development and maintenance costs that need to be carried by procurement.

To truly realize the promise of orchestration, a platform needs to be built for procurement from both end-user and administrator perspectives. They need to provide an out-of-the-box user experience that is already optimized for procurement use cases, AND they need to make it easy for procurement professionals to build and maintain workflows for themselves (in a way that is also well-governed and compliant with IT guidelines). 

A vital part of empowering procurement professionals to build and maintain workflows for themselves comes in the form of what one might call ‘procurement semantics.’ What this means is that an orchestration platform built for procurement should include a number of modules and templates that make it easy to drop in common workflow functions.  For example, they shouldn’t have to build and maintain logic for collecting international supplier documents and information when every country has its own well-documented requirements.  This should just be a module that a procurement pro can simply drop into a workflow, expect to work, and have confidence that it will be updated and maintained by the platform vendor as international changes occur. Integrations are another area where being built for procurement matters. Not every integration is created equal.  A platform built for procurement should include common integrations, and those integrations should be deep, demonstrating a deep understanding of the supplier object within an ERP, for example.

In summary, the promise of procurement orchestration is that it can decrease cycle times, improve visibility, reduce risk, and increase compliance. The only way to truly realize these benefits is through an orchestration platform built for procurement. What does it mean to have an orchestration platform built for procurement? It means a UX designed for procurement use cases, and it means a no-code platform with deep procurement semantics.