In our three installments last week (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, we are going to continue our 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 concluding with Orchestration, because once you have accepted the request and defined the project, you need to execute it.

Orchestration is, in essence, the integration of as many modules as you need into a configurable workflow that suits your specific organizational processes for the procurement at hand.

Easy Self-Serve Data Stream / Partner 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. It should be a single click to integrate a supported data stream (once purchased).

Low-Code Integration for Arbitrary Source to Pay+ Modules
It should be almost as trivial to integrate non-partner source to pay modules which have a well-defined (open) API simply by defining the API link, the buying organization’s unique keys, data mappings from the orchestration platform to module data tables/objects, entry and specific task links, etc. that is sufficient for pulling data from preceding modules into the application, pushing data out required for metrics and successive modules that are required in the procurement process, launching the application, quick-linking to a specific screen, and integrating the module into the appropriate process workflows.

Workflow Automation
The entire idea of process orchestration is to support the right workflows to support the various sourcing, contracting, onboarding, procuring, payment term analysis, and other source-to-pay projects the procurement organization needs to undertake. It should fully automate the workflow defined in the intake module and/or the project defined in the procurement project management platform.

Smart Progress Tracking
The orchestration module should automatically track where every single process is and when a buyer comes in, take the user to the right screen corresponding to the current step of each procurement process it is managing. It should also push the required data for process and project tracking into the intake and procurement project management modules that will allow those platforms to automatically track the current project process.

Effectiveness KPI Tracking
Whereas a procurement project management module should track the efficiency of the procurement projects, orchestration should track the effectiveness. For a sourcing project, what was the identified savings? (It should track the prior cost per unit, the estimated demand for the next year & contract term, and the identified cost per unit.) For a contract renewal, what were the cost/service/quality/etc. gains? For a catalog procurement, what was the cost savings over the prior (non-catalog) procurement? For an analysis, what opportunities were identified in what time frames? And so on.

Predictive Analytics Integration
The platform should be capable of integrating with a platform capable of doing predictive analytics around expected process times, expected performance (savings, etc.) outcomes, and other metrics the user might want to consider before kicking off a project.

Rule-Based Automation
The platform should support rules-baed automation that will allow parts of the process to be fully automated within certain constraints. For example, if it’s a sourcing project, the RFQ, once defined, can automatically go out to approved vendors, when the quotes are returned, the lowest cost quote(s) accepted, the contract draft auto generated, and so on.

Data Flow Definition
It should be trivial to define the data flows between the different source to play modules that will be used in a given procurement process.

This completes our deep-dive of the intake management / procurement project management / orchestration modules that exist today, and that we listed in Part 36.

In our three installments last week (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, we are going to continue our 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 continuing with Procurement Project Management, because the next step is to manage the project, which could go beyond the existing source to pay modules the organization currently has.

Procurement Project Management is exactly what it sounds, the project management of a procurement. It’s essentially project management, tweaked to support Procurement vs. just a generic project. Whereas intake has capabilities for the buyer and the stakeholder, project management is primarily geared towards the buyer.

Phases, Milestones, Tasks, Owners, Obligations, Tracking
The ability to create phases, milestones, tasks, owners, obligations, and track progress throughout the project timeline — all the standard project management functionality — as previously indicated, is a core must. Basically, anything you would expect any other project management tool to do — including team management, GANTT charts, etc. etc. etc. must be supported.

Standard Project Templates
Just like intake management must support Sourcing / Procurement Workflow Process Definition, the procurement project management module must support the definition of standard project templates for each of these processes such that there is a template for every category of good and service being sourced that can quickly be instantiated as needed for each procurement project undertaken.

Customizable Approval Flows
Depending on the category, the amount, the vendor, etc. etc. etc. the approval flow that is required may be slightly different from the default flow for the category, good, amount, vendor, etc. The module must support the definition of the customized approval flow, which can be role based, user specific, or both; parallel, serial, or both; or even process step dependent. And this approval flow must be seamlessly embedded in the project workflow, ensuring that a project does not advance when one or more approvals are needed.

Deep links into Sourcing/Procurement Products
If the procurement project management module is not capable of being integrated into the modules and tools used to execute the project, it’s not procurement project management — it’s just a regular project management tool and you might as well use the cheapest freeware/shareware project management tool that you can find as it’s not providing any value from a Procurement perspective. It must support integration into the modules that are used to execute procurements, and not just a shallow link. It must support a deep link directly into the current screen that represents the current step of the process. It must also support data pulls for metrics, alerts, and necessary pushes into subsequent modules and steps.

Dynamic Project Shifting
If, at some point, the buyer decides that the procurement should follow a different process, or, due to quotes (and likely costs) being higher than expected, the need to introduce new (potential) suppliers into the process, or the need to accelerate the acquisition, the module should make it as easy as possible to convert the current project plan into the new/modified project plan, by automatically populating the new project plan with all of the existing project configuration that can be reused. Requirements, team members, approvers, etc. etc. etc. that are capable of being ported should be. In addition, it should note that the procurement process was modified and link back to the original process that was followed, and where the buyer was in the prior process prior to the shift.

Efficiency KPI Tracking
The platform must track metrics around how long different processes generally take, down to the individual milestone and step, as well as the configuration settings and parameters (such as category, contract length, etc.) that will allow the metrics to be sliced and diced into specific metrics meaningful for a precise subset of procurement processes.

Issue Alerting / Exception Dashboards
Just like an intake management platform should alert the stakeholder and the buyer when there is a question, issue, or requirement that needs their attention, a procurement project management platform must alert the buyer not only when something needs to be done, but when a certain process step is taking longer than was allocated or than the average process time for that step in similar projects. It must make it easy to see all of the outstanding alerts applicable to the buyer and/or a particular process, as well as any exceptions that arise during a project that could cause a delay, whether or not they are to be resolved by the buyer (so that the buyer can see if they need to contact a stakeholder to see if that stakeholder needs help to keep the project moving).

A good procurement project management 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 a procurement project management module should support.

We still have Orchestration, so come back for Part 39.

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.