Why a Software Proof of Concept (POC) Is Better than an RFI

A proof of concept (POC) is an increasingly common method to select the best supply chain software vendor for your company, yet many supply chain practitioners still lean on the traditional RFI (request for information) tool. Software selection is risky. A poor choice can cost an organization millions of dollars as they limp along on a product that doesn’t fit their business or help them solve their core challenges. This post will examine why the RFI has become an outdated tool for software selection and look at how a software POC can help your organization choose the best supply chain planning solution by aligning directly to your business challenges. (Note: the same challenges apply for RFP (request for proposal) and RFQ (request for quotation methods, but for simplicity, we’ll just refer to RFI in this article.)

Seven Ways RFIs Fall Short

The premise behind the RFI is simple: Create a list of software requirements and choose or shortlist the vendor that checks the most boxes. Unfortunately, anyone who has ever been through the RFI process knows it’s not that easy. Here are some of the most common issues with RFIs:

#1 Emphasizes features over objectives. RFIs start by assuming everyone knows which features will help the organization meet its business objectives. Scratch that. An RFI assumes everyone knows what the business objectives are. If you’ve been through a supply chain project before, you know that’s not always the case.

#2 Loooong list of requirements. If multiple teams are involved in creating the RFI – and in a supply chain project they usually are – this indiscriminate list of requirements can grow very long very fast. The problem is, that long list probably included features not required to address your business challenges–and may omit the capability you really need.

#3 No prioritization. Narrowing down an RFI into something usable can involve intense negotiations as business leads battle over which features are “must-haves.” To avoid conflict – and get home in time for dinner – people give in. Eventually, the RFI ends up top heavy with far more features in the must-have column than not.

#4 Too generic. Since creating an RFI from scratch can take hundreds of hours, many software selection teams start with pre-built RFIs or one borrowed from another organization. No two supply chains are exactly alike, so why assume every organization has the same requirements?

In the same way, using an RFI as a way to “narrow the field” of potential planning vendors may overlook–or eliminate–your best-fit solution. Solid online research and structured interviews with potential vendors are a better way to accomplish that initial shortlisting exercise.

#5 Blind spots. An RFI can leave the organization with a blind spot as the team focuses on what they know. For example, an SOP may define how forecasting is done in the organization; therefore, the RFI focuses on features that enable that approach. There may be a better way to approach forecasting, but it’s not captured in the RFI because no one has any experience with it.

#6 Focus on the wrong metric. RFIs also assume the organization is focusing on the right metrics. Using forecasting as an example again, supply chain RFIs often emphasize forecast accuracy. In volatile supply chain environments, forecasts are inherently inaccurate. The longer the forecast horizon, the more inaccurate they are. In supply chain optimization, forecasts should be seen as a tool, not an end point.

A well-structured proof of concept can generate stakeholder buy-in far better than even the most extensive features checklist.”
— Henrik Sufke, Global VP, SC Planning – Ecolab

#7 Poor use of resources. As noted above, creating an RFI from scratch can take hundreds of hours. Evaluating responses can take almost as long and result in very few distinguishing factors between vendors. One of the reasons for this is that filling out an RFI is an exercise in creative writing for most vendors. They’re looking to check as many boxes as they can, so they can make it to the next round. Loosely interpreting the definition of a feature works to their advantage.

A POC Test Drive: A Better Way to Evaluate Supply Chain Software

Many supply chain professionals are skeptical of RFIs. They want to see evidence that the software works as described and will deliver on its promises. Henrik Sufke, Global VP, SC Planning – Ecolab, recently explained to me why a POC was the preferred choice for his company. “A well-structured proof of concept can generate stakeholder buy-in far better than even the most extensive features checklist.”

In my next post, I’ll go deeper into how to run a successful POC. In the meantime, if you’re still working through your selection process, reach out to us and we’d be happy to explain our proof of concept process in more detail.