Creating a Request for Proposal (RFP) for a Radio-Frequency Identification (RFID) system is quite different from purchasing off-the-shelf software. The integration of RFID with the physical and digital world presents unique challenges in terms of understanding radio wave behavior, workflows, and software integration.
Unfortunately, many businesses are using standard RFP documents and submit proposals that don’t meet the specific needs of their business. This results in incorrect vendor pricing, missed deployments, and failed implementations. When preparing an RFID RFP, there are a number of pitfalls to avoid when selecting a solutions integrator.
Why is focusing solely on hardware the most common RFID RFP mistake?
Many customers simply think of RFID as a hardware transaction, specifying pages of their RFP requirements for tag frequencies, antenna gain, reader specifications, etc. Although hardware is significant, the real benefit of an RFID installation will come from the software and integration.
The RFP misses out on the middleware, that middle layer of software that clears out duplicate radio signals and transforms them into meaningful data, and you’ll end up with a system that will overload your back end with noise.
One of the key areas to consider heavily in a strong RFP is the vendor’s data filtering and edge processing capabilities, as well as its ability to integrate easily with your current Warehouse Management System (WMS) or Enterprise Resource Planning (ERP) system.
How does omitting physical environmental details ruin vendor proposals?
The technology of RFID uses radio waves, which, due to their physical nature, are extremely vulnerable to interference. The worst thing any business can do is not specify their facility’s environment in the RFP. RF signals are disrupted by metal shelving, liquid containers, inventory density, packing, and extreme temperatures.
These details are left out, and vendors will quote what the ideal laboratory conditions are, only to be caught with a lot of overspending when the system doesn’t work perfectly on the warehouse floor. Your RFP should thoroughly outline the layout of your facility, materials to be tagged, and require a comprehensive site survey from vendors prior to the deployment plan.
Why is prescribing the exact technology a bad idea?
It is often the case that buyers write the RFP stating exactly what technology they want, for instance, “Passive UHF Gen2 tags,” but don’t really know whether it is appropriate for their use case.
You’ll be locking out seasoned vendors from providing you with some better alternatives because you’ve already got the solution written down in your books. In some cases, your use case may need to use Active RFID or Bluetooth Low Energy (BLE) instead of passive tags for real-time location tracking (RTLS).
Describe your operational problem (e.g., “We need to be able to locate forklifts in real-time to within 5 metres”) and leave it up to the vendors to propose the best, most tailored technological solution for the problem.
What is the danger of writing vague KPIs and success metrics?
If you can’t quantify the objective, such as “we want to increase inventory accuracy,” you won’t have a starting point to work from when discussing inventory accuracy with a vendor. If the success criteria are subjective, vendor answer sheets will not be effective in scoring their responses [2]. You need to have specific, measurable Key Performance Indicators (KPIs) in your RFP.
Be specific on your objective: “Decrease dock door receiving time by 40%,” “Increase cycle count on the retail floor to 99.5%,” or “Avoid out-of-stock events on the retail floor.” Once you have defined your KPIs, you will have a clear idea of what your system should be able to achieve, and you can then determine the ROI you can expect from your vendor(s).
Why is failing to require a Proof of Concept (PoC) or pilot phase risky?
Don’t create an RFP that calls for a full-scale enterprise deployment right away. There is a lot of tuning and positioning of the antennas and software to get RFID to work, as they must interact properly to detect and capture the events.
Not conducting a pilot phase is a huge operational risk. Your RFP should explicitly ask for a plan that includes a Phased Approach, with the initial phase being a local Proof of Concept (PoC). This way, you can check out the technology, do a trial run with the integration, and test the accuracy before investing much in a facility-wide implementation.
Why is omitting long-term support and SLA requirements a costly oversight in an RFID RFP?
RFID systems are deployed in physical wear-and-tear areas such as busy warehouses, manufacturing floors, and retail stores. Antennas are broken, cables wear, software updates need security patches, and tag supplies must be continually restocked. One common pitfall for buyers is to only consider the up-front price of the equipment and neglect to account for the ongoing support and services.
The absence of detailed Service Level Agreements (SLAs), maintenance schedules, and terms of warranty for the hardware means that you are leaving your operation susceptible to costly downtime.
Conclusion
The key to a successful deployment is a well-written RFID RFP. Transmitting your operational issues, environmental information, and prioritizing software integration, rather than hardware alone, enables vendors to create solutions that address your specific needs and deliver high ROI for your company.
FAQs
What are the essential components of an RFID RFP?
A good RFID RFP should contain all details of the company’s background, a problem statement, clear Key Performance Indicators (KPIs), a detailed description of the physical environment, existing software infrastructure (WMS/ERP information), requested service level agreements (SLAs), and a request for a phased deployment.
Should I invite dozens of vendors to respond to my RFP?
Don’t send an RFP to too many vendors; otherwise, your evaluation team will be overwhelmed, and the higher-quality integrators will be put off. The preferred approach is to use a shortlist of candidates in a Request for Information (RFI), followed by the production of a detailed RFP for a small number of vendors (3-5) who are very qualified.
Why do I need to share my budget in the RFP?
When you don’t define a budget, you end up with a solution that’s very over-designed or under-powered. By giving the vendor a range of realistic budgets, they can determine what hardware and software development they can provide that best meets your budget.
