Is it time to say goodbye to RFIs?

Supply chain software is changing. So should the purchasing process. 

As someone who has worked in supply chain for over 20 years, I’m very familiar with Requests For Information (RFIs) and Requests for Proposals (RFPs). It’s been the way to conduct a competitive tender since I can remember. RFIs tend to work well for certain industries (like government) or for purchasing equipment and industrial assets, but they often fall short in helping supply chain teams select a new software vendor. In this blog post, I’ll explore why and offer a helpful alternative.  

Why RFIs Fall Short 

RFIs are typically structured using a “tick box” approach – vendors are measured up against loads of features and functionalities and are asked whether their solution fits them or not. Procurement then pulls together a summary file with the vendors’ different scores for the supply chain decision maker to evaluate. There is valuable time and effort put in by both the supplier and the purchasing party. But often, this work ends up being useless, not to mention tedious.  

As Lora Cecere writes, “RFPs and PowerPoint presentations are the worst way to buy decision support technologies like supply chain planning.” “Most companies ask the wrong questions and consequently have the wrong discussions.” Let’s take some examples. 

A typical RFI question is: “can you copy and paste data from Excel into your solution?” If the company includes this in an RFI, it’s probably because its team can’t manipulate data very easily. Vendors completing the RFI will give them a Yes or No but their core issue will remain. A better question would be: “can your solution enable me to manipulate large amounts of data in a straight-forward way?” 

Other questions I see include: “How many statistical models does your tool support?” “Are there limits to the number of models?” “Can a user customize the statistical model?” The answers here might be Yes, Yes with customization or No. But as a vendor, you’re left guessing the underlying capability the company needs. Do you need a lot of models to develop a statistical forecast? Why do you want users to be able to customize models? Is it because the current tool you use needs a lot of fiddling and adjusting? Or simply that you’ve seen on vendors’ websites that they stress how many models they use and how configurable these are so you think this must be important? These questions tell you very little about whether the solution will support what you want to achieve.  

A focus on features also loses sight of your organization’s maturity level and whether that fits the given solution. I have received many RFIs that list tons of functional requirements. When I see these, I think “wow, these guys must be really advanced if they need all of this functionality.” But when I engage with the company, they’re still using T-cards to do their production scheduling. I cannot stress the importance of considering your current maturity level and skill set. It helps to start by looking at your business scope and want you want to achieve. 

A focus on features loses sight of your organization’s maturity level and whether that fits the given solution. – Tweet this

Focus on the business scope and what your business wants to be able to do  

Let’s continue to explore the question about the number of statistical models, mentioned in the example above, and turn that into a capability instead. A capability-driven question would likely start as follows: ”We want the most appropriate model selecting for a given demand profile…” If you start with the end objective in mind, you stop being prescriptive about the how. Taking the capability as the starting point provides a pathway to engage with vendors and have dialogues about the right questions.  

Consider another example. If you’re looking for inventory software, a high–level capability might be: we want to manage inventory. The next level down might be:  

• Define inventory policies 
• Plan and optimize our inventory 
• Manage stock in the warehouse and manage spare parts 

The final level of capabilities will likely include:  

• Capture current inventory levels 
• Capture current supply plans 
• Calculate buffer levels 

All of these describe a business process focused on an outcome and are not prescriptive as to the features required or the how. Preparing a capability model like the one above, helps the business explore what is it they’re trying to do and why. It turns the whole buying process into something very valuable. It allows for exploration and gives you a much better picture and framework of what you need when you come to evaluate options. It also allows you to test the understanding or subject-matter knowledge of the vendor, giving them an open forum to present how their solution supports these capabilities.  

Bottom line: Think twice before you put in time and effort into an RFI   

I often wonder if the tick box RFI culture is in part responsible for the feature’s arms race we have seen in supply chain software. The result of it has been overburdened software with a features list that ticks all the boxes but which most customers will use less than 20% of. Worse yet, users are often confused by all the redundant functionality, so they don’t adopt the new technology and revert to spreadsheets. Instead of handling software selection with a generic RFI, start with your business scope and build a capability model. Then invite vendors to demonstrate how they support your goals. 

Instead of handling software selection with a generic RFI, start with your business scope and build a capability model. – Tweet this