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.