In this series we are doing a deep dive into the sourcing process today, and, in particular discussing what is involved, what is typically done (manually), and whether or not it should be that way. We have already completed our initial discussion of the initial project request review phase, the follow up needs assessment, and the strategy selection phase and are in the communication (identification) step. At first glance, it looks like this is an entirely strategic human-driven step with little option for tactical automation, but is this the case?
As per our last post, the communication step of the typical sourcing process, we have the following key sub-steps that typically have to be completed:
- Standard Protocols
- Supplier e-Communication Capability
- Level of Detail Required
- Response timeframes
Let’s start with the standard protocols. At some point a human has to establish the standard (organizational) protocols, but how much do they change from event to event for a product or service or category or across products and services within a category (or across similar categories)? Not much. There’s no reason that once an event is created a system can’t find the closest event or category that’s ever been done, extract the communications protocol that was used, present it to the buyer, allow the buyer to accept all, or part, and if only parts are accepted, find and recommend the next best parts, and then allow the user to edit the closest parts to make it all fit. A great platform will make it extremely quick and easy to create a standard communication protocol and framework, and even quicker to set up automation using templates, timers, alerts, and other capabilities of modern Source-to-Pay platforms.
When it comes to supplier e-Communication capability, once the buyer has an e-mail, the platform can send out the surveys to those suppliers that are new and, more importantly, suck in profiles from other events from suppliers that have recently responded. And if the response is over a year old, automatically resend it to the supplier for verification. There’s no reason a human has to do very much at all. This is a step primed for platform automation.
The level of detail required step, like the standard protocol step, is another step where a human has to make an initial decision at the organization, category, or product level, but once that decision is made, and captured, there’s no reason a human ever has to make that decision again (unless an event happens that indicates the decision no longer fits). The system should be able to extract the right guidelines and templates to help the humans through the proper supplier communication protocols and responses and allow the buyers to focus on the strategy, not the minutia.
Finally, with respect to response timeframes, the system can query organizational guidelines, decisions from previous events, and typical average response times and present the buyer with suggested response timeframes. It also enables the buyer to alter any suggestions quickly and easily so that the buyer can produce all the internal guidelines and disseminate them in a quick and easy fashion and spend more time on the preceding strategy step and the following analysis step.
In other words, we again see that, without proper system support, a buyer will waste much of their time on tactical processes, non-strategic data collection, and making the same tactical decisions over and over again and Sourcing really has to change.