In Part I we recapped Sourcing today, in Part II we did a deep dive into the key requirements of the review step as it is today, and then in Part III we did a deeper dive where we explained that while some steps were critical for a sourcing professional to undertake, others, while necessary, were a complete waste of skilled talent time as the majority of the tasks could be automated. Then in Part IV we began our deep dive into the needs assessment phase which we completed in Part V. This was followed by a deep dive into strategy selection in Parts VI and Part VII. And upon review of these two steps, we’re still at the point where some tasks have to be done by humans whereas others can be mostly automated. But is this true across the entire sourcing cycle? Let’s dive into the communication step.
In 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
The communication step starts with the identification of standard protocols that will be followed throughout the rest of the process in all communications with suppliers, whether initiated by the buyer or the supplier. Once the protocols are identified, they need to be implemented in all mechanisms that will be used to communicate to suppliers so that they can be enforced to the extent possible by the systems that will be used. For example, if notifications will be sent out within 72 hours of receiving a submission or making a decision, the platform can either automate notifications or automate alerts.
The supplier e-communication capability step seeks to identify the suppliers ability to use e-communication, and to use it effectively. This will require reach out to suppliers to identify what they have in terms of technical skills, internet bandwidth, and Supply Chain e-Commerce systems (can they accept EDI, XML, etc.) and their ability to support modern requirements such as digital signatures and block chain.
The level of detail requirements step determines what level of detail will be required in each communication that will be sent out as part of the process. For example, in the RFI step, you may need to send out details on filling out the RFI, requirements for completeness, supported file formats for certificates, etc. In the award step, you might detail what will, and will not, be included in a (lack of) award notification. And so on.
In the response timeframes step, the buyer determines what the response timeframes will be not just for pre-defined step, but for responding to supplier questions and unsolicited supplier communications. And for dealing with unexpected communications, such as failure during an auction, suppliers not responding on time, and so on.
All this sounds like it’s all human driven, but is it? And it sounds like it’s pretty quick and simple compared to the last few steps, but is it? I guess that’s what Part IX is for!