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.