We use the phrase “it’s not rocket science” a lot at AirFaas. But then again, for a rocket scientist, or at least companies that build rockets, they probably do a lot of procurement-related tasks and admin that isn’t exactly rocket science either. So, let’s imagine for a second that we are all indeed rocket scientists, building complex machines and needing to request the materials or parts from other such experts. To do this we would likely need to send a request for quotation, or RFQ.
The purpose of this post isn’t to compile a list of do’s and don’ts – though I do love a good list! The point is to offer my own take on the topic. In general, wise minds agree, that a good RFQ is a document, or a series of documents, that get the attention (and offers) from high-quality vendors that meet predetermined criteria. It needs to be compiled of an exact array of information that you can easily find from multiple sources online.
Is this a good explanation of a good RFQ then? I don't think that simply ticking all the boxes, or filling out a template with high-quality information and supporting documents is enough. A good RFQ should offer more than just being a document or series of documents that convey accurate data. This data, both sent and received, has great value even after the tender decision has been approved!
I think that a good RFQ should support the decision-making process in a wider context. It should act now, and in the future, as defined justification for the processes that follow - one of the first in a sequence of events. It can also act as a useful step in finding, selecting, and approving new suppliers, and managing the following relationship.
A RFQ should also be accessible, securely stored, and linked to the rest of a project all the way to the point where a nonconformity has been reported. Even after the validity date of a RFQ has passed the data it represents is still valid and shouldn’t be disregarded. Your project data does not have a shelf life, nor does the justification for your decision-making process.
Working with RFQs in a way that connects to other parts of your business seems like a no-brainer to me, but most procurement people don’t have the option of an integrated system that links strategic to operational data. Procurement data, more often than not, is created in files with templates and archived to a cloud location. To summarize, a RFQ should be a well define document, but more importantly, it should be linked to the business flows that precede and succeed it. It should, along with the quotations it generates, be stored, easily accessed, and linked to the project as a whole. This is because it both serves as justification in the decision-making process and acts as the first point of contact with new and old suppliers alike. So maybe it’s not rocket science, but then again what is?