Category Archives: Orchestration

Source-to-Pay+ is Extensive (P37) … Investigating Intake – Diving in to the Details

In our last three installments (Part 34, Part 35, Part 36) we noted that, when you are in Sourcing/Procurement, you need to intake requests, manage projects, and/or orchestrate your technology-enabled processes, depending on what the modules/suite you have do and don’t do and what your particular situation warrants. However, we also noted, that you won’t find a single platform that does everything you need to do, and you’ll be lucky to find a platform that does even half of it. And even then, it probably won’t do more than half of that well. That’s because, as we explained, these emerging platforms typically fall into the categories of Intake Management, Procurement Project Management, or Orchestration. In Part 35 we overviewed the core capabilities at a high level, but skipped the deep dive in an effort to get you the fledgeling vendor list (which is still quite small) so you could start getting familiar with who is out there and have an idea who to investigate when the time is right.

However, once you get a shortlist, you need to be able to evaluate where the platform is now relative to where it should be and what you will need. Thus, in this installment, and the next two, we are going to dive into each of these three product classifications (which, hopefully, will someday become one as you need all three sets of capabilities for successful orchestration). We’re starting with Intake, because the first step is to get the request.

Intake Management requires two sets of capabilities, one set that are requester stakeholder focussed, and one that are procurement buyer focussed, that must be connected and that are often two sides of the same coin.

For the Requesting Stakeholder:

Request Portal
This is the absolute requirement — an easy to access web-based enterprise procurement portal that anyone in the organization can access when they need to acquire something to do their job or satisfy a client. As per our initial discussion, the interface must be capable of being configured in a way that ensures that whatever information the buyer needs to fulfill the request will be collected before the requester can complete the request (such as high level categories, any budgets [codes] they have, whether or not any of the needs can be met with current contracts / catalog items, etc.). It must be incredibly easy to use, dynamically adjust the information requested to the minimum required for the product or service being requested, and support all of the other necessary requirements from the stakeholder perspective (that we are describing in this installment).

Process Visibility
Procurement is, or at least should be a process. Not just “I got a bid, negotiated a discount, and want to send the PO, so can you please approve it?” (even if one of the intake vendors seems to indicate this is an acceptable process! [It’s not!!!]). It should be multiple bids, comparison to current prices (or open market prices), negotiations with the best vendor(s), documentation of real reductions (not just a 20% reduction on a 25% markup because the sales person knows you have no clue of current market pricing, so they mark it up 25% to negotiate down 20% and make a killing off of your lack of knowledge), a proper contract, a PO tied to the contract, and an invoice management process that doesn’t pay the invoice until the goods are received and the prices are verified as matching those in the contract. And the stakeholder should be able to see once a request is assigned to a process, what the process is, and where the request is in the process at any time simply by logging in and selecting the request from their request history.

Asynchronous Messaging
The stakeholder should be able to ask questions of the buyer at any time, and be able to answer any questions asked by the buyer at any time.

S2P Platform Integration for Stakeholder Input
The Procurement process should be executed through the modules available to the buyer, which could include, but not be limited to, strategic sourcing, contract management, e-procurement, supplier management, spend analytics, accounts payable, etc. Wherever stakeholder review or input is needed for proposal review, order or invoice verification, approval, etc., the intake portal should integrate with, and allow a stakeholder to directly jump into, the module where, and when, needed to allow the process to continue smoothly and efficiently.

Budget Tracking
The portal either needs to track the budget(s) (remaining) that each of the users has control of, or access to, or integrate with the source to pay module that does the budget tracking. This way, when the stakeholder goes to make a request, they can see if there is budget available before submitting the request (and if there is not, make a budget request first as the Procurement Buyer may otherwise be required to reject the request).

Alerting
The portal needs to alert the stakeholder of any requests made by the buyer, or any requirements that need to be satisfied in the process, possibly through integrated source to pay modules, in order for the procurement process to continue. This should include the ability to configure the portal to send the stakeholder an email when something is urgent, as well as an ability to easily access all of the unaddressed alerts quickly and easily on every login.

For the Procurement Buyer:

Request to Process
Once the buyer analyzes a request and decides it is a valid request, the platform must make it incredibly easy to flip that request into a Procurement project, be it a (strategic) sourcing project, contract addendum/re-negotiation, a catalog buy, or another PO against a current (open) project. Literally select the option and one-click to project. (And, if the request is not valid, or the requesting stakeholder has no budget, be able to return it just as easily by selecting the pre-coded reason and one-click returning it.)

Sourcing / Procurement Workflow Process Definition
The platform must support the creation of procurement process workflows for each category of goods and services that the buyers need to acquire. These workflows must not only allow for the identification of the major process steps, but also the tools that will be used, and direct links into those tools.

Integrated Approval Workflows
The more costly the acquisition, the more checks and balances and approvals that are needed. Some of these will be possible in the modules used, and some won’t. But they need to be captured in a tool with secure audit trails so that anyone at any time can ensure that the process was followed, the checks were made, the necessary approvals acquired, and everything is above board.

Project Management Integration
While an intake platform must allow for process workflow definitions with major steps, it does not necessarily include extensive project management capability, which will be needed for complex acquisitions. Thus, unless it contains extensive project management capability (which we will describe in our next installment), it must support integration with a project management module.

Policy Tracking
All Procurements should not only follow a process, but be guided by a policy that dictates the acceptable processes for a (category of a) good or service, the considerations that must be made, the requirements that must be met, the approvals that must be made, and so on. If these are not tracked in a central location, they will be lost. The intake tool is where these should reside, as they should also be available to stakeholders who have questions.

Alerting
The portal needs to alert the buyer of any requests made by the stakeholder, or any requirements that need to be satisfied in the process that are waiting on the buyer, possibly through the integrated source to pay modules, in order for the procurement process to continue. This should include the ability to configure the portal to send the buyer an email when something is urgent, as well as an ability to easily access all of the unaddressed alerts quickly and easily on every login.

A good intake module will, of course, do even more than this, but as with all of the previous modules we covered in our series, we consider this the bare minimum set of functionality that an intake module should support.

Next up: Procurement Project Management in Part 38.

Source-to-Pay+ is Extensive (P36) … Here are some Intake/Orchestration Vendors

As promised in our last installment, Part 35, here is a partial, starting list of intake/orchestration vendors that provide one or more of the following capabilities:

  • Intake management (and requester/stakeholder visibility into the process)
  • Project/process management throughout the source-to-pay cycle
  • Orchestration between multiple applications

As with other every list, we must inform you that this list is in no way complete (as no analyst is aware of every company — and sometimes a new company launches its first product, or a new product literally after one of these lists goes up), is only valid as of the date of posting (as companies sometimes go out of business and acquisitions happen all of the time in our space), and does not include vendors which have project management limited to just one (or more) of their internal modules.

As with our lists of e-Procurement Companies (in Part 7), Spend Analysis Companies (in Part 12), Sacred Cow Companies that do, or support, customized “spend” analysis on Marketing, Legal, and SaaS (in Part 13), Supplier Management Companies (in Part 20), Contract Management Companies (in Part 25), and e-Sourcing Companies (in Part 30), and Invoice-to-Pay/Accounts Payable Companies (Part 33), we provide the company name, URL and LinkedIn URL if available, headquarters country, and list other offerings we are aware of.

Remember that if we say Source-to-Pay, it means that vendor offers modules that cover (baseline) Sourcing, Supplier/Vendor Management, Contract Management, Spend Analytics, e-Procurement, and Invoice-to-Pay/Accounts Payable. As to whether or not SI would consider these modules meeting the majority of baseline functional requirements, you will have to check the previously published starting vendor lists in those areas and other prior coverage on SI (if available).

Do your research, and reach out to an expert for help if you need it in compiling a starting list of relevant, comparable, vendors for your organization and your needs. For many of these vendors, good starting points might be the Sourcing Innovation archives, Spend Matters Pro and Gartner Cool Vendor write-ups if any of these sources has a write-up on the vendor.

And while this list is currently (much) smaller than the other lists, as it’s pretty easy to find at least 60 vendors for any core module you want in Source to Pay, and we barely cracked the twenties with this list, we don’t expect it will stay that way for long!

Shout-out to The Revolutionary and The Procurement Dynamo for their thoughts on what vendors might fit into this emerging category!

Finally, a second reminder that inclusion on this list DOES NOT imply Sourcing Innovation is recommending the vendor.

Company LinkedIn
Employees		 HQ (State) Country I P O Other Offerings / Notes
Arkestro 98 California, USA O e-Sourcing
Celigo 720 California, USA O Integration Platform, App Marketplace
Cirtuo 40 Austria P Category Management, Supplier Management
Focal Point 26 Georgia, USA I O
Graphite Connect 66 Utah, USA I Supplier Management
Ivalua 912 California, USA I P Source-to-Pay
Kissflow 528 Delaware, USA O e-Procurement, I2P/AP
LevelPath 22 California, USA O
Mercell Negometrix ?? Netherlands I e-Sourcing, Supplier Management, Contract Management, e-Procurement
Omnea 16 United Kingdom O
Opstream 13 New York, USA I New York, USA
Oro 60 California, USA I Supplier Management
Pega 6081 Massachusetts, USA O
Pipefy 580 California O
Qntrl 16 India O
ServiceNow 23,206 California, USA O e-Procurement
Spend HQ Per Angusta 53 France O Spend Analysis, ESG
WorkFridge InGeek 7 India O
ZFlow 8 California, USA O
Zip 351 California, USA I e-Procurement, I2P/AP
Zycus 1607 New Jersey, USA I P Source-to-Pay

We aren’t done yet … we dive deeper into the capabilities required starting in Part 37.

Source-to-Pay+ is Extensive (P35) … Do I Intake, Manage, or Orchestrate?

In our last installment, Part 34, we noted that, after working through our series, many of you would likely have selected a number of best-of-breed solutions to meet your various need as opposed to a suite (due to unique capabilities that were attractive to you, attractive price points, quick setup times, etc.). And after selecting a few of these, you got to wondering “what’s the best way to integrate these and make sure that, once I have a full set, they support my source-to-pay processes end-to-end in a seamless fashion“. The point of these solutions is to control costs in an efficient, and effective fashion, and this requires effective management of requests, communication, projects, and/or processes.

Plus, even if you selected a suite, even when you finish implementing the last of the six core modules we’ve covered to date in our series, that’s just the beginning … since you will eventually have to enrich your data, deal with ESG/CSR, integrate with services management, asset management, logistics and supply chain management and support other features these core modules won’t have in order to get to the next level of enterprise buying.

In other words, you need to intake requests, manage projects, and/or orchestrate your technology-enabled processes, depending on what the modules/suite you have does and doesn’t do and what your particular situation warrants. Let’s discuss what each of these capabilities are and what a few core features are (especially since you won’t yet find a platform that does it all and does it all well, at least not yet, as intake and orchestration are rather new solutions).

Intake Management

Often known as intake-to-procure or intake-to-pay, this type of solution focusses on allowing anyone in the organization who has a procurement need to make a request which goes to Procurement, get visibility into that request, and know it will get done because the solution allows a buyer to turn a request into a procurement project. Key capabilities:

Configurable Enterprise Procurement Request Portal ANY Employee can Access
In order to make a procurement request for whatever they need, be it resupply of the local office supply closet, special materials and promotional items for an event, short-term services, a restock of materials needed for MRO, or new products for resale to meet (new) client needs. And the interface must be capable of being configured in a way that ensures that whatever information the buyer needs to fulfill the request will be collected before the requester can complete the request (such as high level categories, any budgets [codes] they have, whether or not any of the needs can be met with current contracts / catalog items, etc.).
Request to Project
Once the buyer analyzes the request, they must be able to flip that request into a Sourcing Project, a re-negotiation/Contract Addendum with a current supplier, a catalog buy, or a PO-against a current contract (or whatever else is needed) in order to begin the process of filling that request (or, if the request is not valid, deny it and flip it back with a rejection or a request for modification into a request that would be acceptable).
Process Visibility and Messaging
At all times, the buyer must be able to see where the request is: in queue, approved, being sourced/procured, order placed, goods arrived, invoice paid, process done; etc.

Project Management

The capability to manage a project from beginning to end, no matter how many steps it has, how many modules are required, how many approvals are needed, how many obligations need to be tracked, and how many milestones need to be completed.

Standard Project Management Functionality
The ability to create phases, milestones, tasks, owners, obligations, and track progress throughout the project timeline is a core must. Basically, what you would expect any other project management tool to do.
Links into the appropriate modules from each step of the project.
If all you can do is define and track project steps, you might as well use an open source project management tool. It’s only useful if it allows you to jump into the right screen of the right tool for where you currently are in the process.
Configurable approval flows
The platform should enforce verifications that obligations are met, milestones are completed, and quality is acceptable before projects are allowed to advance.

Orchestration of Processes

The capability to easily integrate as many modules as you need into a configurable workflow that suits your specific organizational processes.

Easy Self-Serve Module Integration
A buyer should be able to select the supported applications that they own, enter their license codes, and it should automatically integrate with the orchestration tool. In addition, they should be able to integrate additional modules easily with
Low-Code Integration
Where a buyer can define the API link, the core data tables/objects, the entry screen links, and that is sufficient for pushing data into the application / extracting processed data out, launching the application, and integrating the new module into process workflows at a high level.
Workflow Automation
The entire idea of process orchestration is to support the right workflows to support the various sourcing, contracting, onboarding, procuring, developing, payment, and other source-to-pay projects the procurement organization needs to undertake.

Of course, these platforms should do more and have more, but these are the core foundational requirements to be classified as an intake, project management, or orchestration solution.

In our next installment [Part 36], we’ll provide you with a list of the solutions available today.

Source-to-Pay+ is Extensive (P34) … But How Do I Orchestrate Everything?

You’ve worked your way through the S2P series and are working your way through finding the initial solution(s) that you need and putting together a plan to select, implement, integrate, train on, and utilize those solutions as part of your daily processes. Since you’ve selected a number of best-of-breed modules (because you realized that you don’t necessarily need a suite, that no suite is best in class across all of the modules, and many of the modules only need endpoint connectivity because you’re not jumping back and forth when you’re within the process of that module), you’ve started wondering about the best way to integrate them (beyond data-based endpoint integration), and, more importantly, how to manage the projects around them (especially since it’s very likely that you won’t find general purpose S2P project management in any of the modules, as even suites can be lacking in this regard).

[Even if you selected a suite, you should still read on to find out just what that suite should be doing to make sure you are getting maximum value, especially since, and we’re sorry to tell you this, the 6 basic modules that form the core process are just the beginning — you will still need data enrichment, ESG/CSR, integration with services management, asset management, inventory management, logistics and supply chain, and other features these core modules won’t have in order to get to the next level of enterprise buying once you get through the first two rounds of opportunities.]

That really depends on

  • what S2P project tracking/management capability you have in the modules you bought (i.e. if the spend analysis module came with a savings tracking module that allowed you to define and track all sourcing/procurement projects at a high level, that may be enough, or it may not)
  • how much insight / visibility stakeholders need into the process status (some modules may provide them with the free/read-only access they need, some may not)
  • how much of your work comes from (one-off) requests vs. corporate purchasing mandates (i.e. are you mainly purchasing bulk products for resale, bills of material for engineering, etc. or are you purchasing a lot of start-up kits for new-hires, one-off requests for conferences/events, special BoMs for build-to-order, etc.)

If i) the spend analysis module contains basic project management in it’s saving tracking component ii) the stakeholders only need visibility during the selection and award phase of e-Sourcing, and they have that through the e-Sourcing module and iii) the team does very little one-off purchasing as they are supporting a manufacturing operation that has low turnover and only goes to the same old shows every year, then chances are customized end-point integration between the modules will be enough.

But, if i) the only “project” tracking is in the e-Sourcing tool and it ends at the award identification, ii) the stakeholders need visibility into the award process, contract negotiation cycle, and current/outstanding POs, and iii) there is a lot of one-off purchasing that needs to not only be tracked, but the status regularly communicated, then you may need a solution to integrate them in a process-oriented workflow and provide visibility into where each purchase request and project is to the appropriate stakeholders. These solutions are typically known as “intake” (and often marketed as intake-to-procure or intake-to-pay) or “orchestration” (and typically marketed as “procurement orchestration” or “sourcing orchestration”) solutions and are starting to pop-up rather regularly now.

The first solution, the granddaddy, of these was Per Angusta, which was recently acquired by SpendHQ. Founded in 2012 to manage the source-to-pay workflow, Per Angusta built one of the first open API frameworks to allow it to integrate with best-of-breed solutions on the market across the Source-to-Pay cycle, and to allow those best-of-breed companies to easily integrate with it proactively. By the time of its acquisition, it integrated with over two dozen best-of-breed solutions (and even a couple of suites) that allowed organizations to incrementally build their source-to-pay workflow in the order that made sense to them, and then easily integrate all of those solutions through one integration to Per Angusta.

It was more-or-less by itself for the first half of its existence, but since then options have cropped up to help you orchestrate the process, some within existing vendors (to provide an interface to the organization and orchestrate their various modules) and some new solutions to solve the orchestration process (and some of these vendors are now building core procurement/payment capabilities if they started as “intake” solutions).

So what are these solutions? And what do they do? We’ll tackle the latter question in our next installment [Part 35] (and then provide a list of vendors in the installment after that).

Do You Have a Procurement FocalPoint?

Last month we asked where’s the procurement management platform primarily because we now have a plethora of procurement-centric applications but very little integration between them. However, once you tackle that issue, you have the secondary issue of all these applications, but often no clear starting point and, even worse, no way for an average organizational employee outside of Procurement to interact with Procurement beyond an inbound email to “please get this for me” and the eventual, possibly many months later, outbound email to “we got it, it’s finally here … it will be on your desk tomorrow“.

This is a big problem, even in organizations that supposedly have market leading source-to-pay suites. While all the modules are connected, and the integrated workflow will guide a buyer from project selection to sourcing to supplier selection to award to contracting to supplier onboarding to order creation to receipt creation to invoice confirmation and payment approval and loop back to the order creation until pending contract expiration when the contract can be renewed, renegotiated, or
revoked and the sourcing process started all over. This is great, but for predefined sourcing projects on encoded categories only!

It’s not great for any category not already encoded and typically strategically sourced, and it’s atrocious as new product and service needs arise within the organization, as new hires need new assets for onboarding, as customer requirements change and the organization needs to adapt rapidly and source new products or services to meet new, or one-off, needs. There’s no intake, and no collaboration with the organizational stakeholders Procurement is there to serve.

And that’s a huge problem. That’s why you’re seeing a few companies talking about “intake”, “orchestration”, or “PPM” (which stands for either Procurement Performance Management or Procurement Process Management, depending on who is talking about it) because, without this capability, a Procurement platform will never be complete or support the organization.

Following the introductory post on the procurement management platform, we lamented and celebrated that Per Angusta was going away and being integrated into SpendHQ as the foundations of a new PPM. It’s a great start, but today the focus of SpendHQ is on managing the existing workflows and creating visibility into existing projects — and savings tracking is limited to integrated projects. However, when it comes to intake support and project tracking for arbitrary organizational needs, that’s not there yet.

However, there are other players which are strong here, and one of those players is Focal Point, which was built from the ground up as an intake-to-orchestrate solution that is capable of

  • capturing all organizational requests for Procurement and Procurement-related activities,
  • assigning those requests to customizable workflows using either built in automation rules or manual (re-)assignment,
  • allowing an end-user to see exactly where any request is in the process at any time,
  • allowing for in-platform communication between the stakeholder and Procurement,
  • integrating with any external tool through jump-out/jump-in to support the process, and
  • supporting whatever approval chains are required, among other intake and orchestration functions.

The tool was built to solve the most significant problem the founders repeatedly saw as CPOs and implementers of various leading sourcing solutions — little to no intake management or general purpose procurement process orchestration. And it does it incredibly well. The visual workflow construction is extremely usable, and the wizards that power both the process, form construction, and form completion automatically extend and compress the form as needed based upon user selections and actual needs, making for a very smooth flow.

All of the workflow elements and steps support deep conditional logic, allowing the organization to create as many branches as possible but ensuring that the end user making a request, and the end buyer assigned to deal with that request, only see the relevant paths and only need to enter the relevant information to be guided by the platform.

There can be as many intake types, with associated branching workflows, as the organization needs, each can have the appropriate level of automation, and, most importantly, each can have as many milestones as needed to walk the process through at a high level, allowing the requester to easily see at a high level where the process is, and then, if interested, dive into the detailed workflow within the current milestone to get a more accurate picture of where the process is.

The only thing the platform doesn’t do is actual sourcing, supplier management, contract management, analytics, procurement, or payment management. It expects the organization to have tools for this already and integrates into the appropriate modules in those tools as needed to accomplish the workflow in progress.

In terms of getting up and running, Focal Point typically has a fully fleshed out, functioning, and integrated instance that captures all of the organization’s workflows up and running within 90 days, even if the organization is a multi-(multi-)billion dollar organization, which is Focal Point’s target market size. This is because it’s typically the 1B+ organizations that have a lot of tools, and a lot of stakeholders, but no way to manage those tools effectively or to give stakeholders any visibility into where their requests are and how their spending is being managed.

The reason it typically takes 90 days is that, unlike many sourcing suite providers, who just flip a virtual switch and drop an empty SaaS suite on you and say “good luck“, Focal Point fully configures the platform as part of their statement of work. This includes:

  • working with the organization to understand all of their requirements and current workflows
  • encoding all of those intake workflows with milestones, task-breakdowns, and existing platform jump-outs
  • integrating any existing procurement system you need to complete the workflow
  • creating a UAT instance and allowing for at least one iteration and approval before it goes live
  • training your team on how to use the system and maintain the workflows

So even though Focal Point has obviously achieved efficiency in terms of workflow creation and customization, external platform integration, and implementation project management, it takes time for an average organization to collect and document their existing processes and requirements and for FocalPoint (or a third party consulting organization if that is the customer’s preference) to fill in the gaps, so it’s not possible to get it much below 90 days. But when you think about the fact that they have fully implemented a 10B+ organization in that timeframe, when some major suite players will take 18 months working with a consulting partner to fully implement those solutions, that’s an incredible time to value, which is generated day one when every request flows into the tool; gets tracked, assigned, and executed; and stakeholders have full visibility into the process and can intervene if necessary.

Focal Point solves the problem it was built to solve, fills the hole the vast majority of sourcing and procurement solutions make, and does it incredibly well. If any part of this post resonates with you, the doctor encourages you to check them out.