Why Proof of Concept is better than RFI
In the process of choosing the best software supplier for logistical flows many companies today still relies to the traditional Request For Information (RFI) despite the emerging, more effective method Proof of Concept (PoC).
Choosing software is critical. Software that does not conform to an organization's operational needs and challenges can generate a loss of millions of money. Against this background , this text will focus on why RFI is an outdated method of choosing a software supplier and focus on PoC that can adapt the supplier's software directly to your organization and business challenges. (applies also to Request for Proposal (RFP) and Request for Quotation (RFQ), for simplicity, we refer to RFI in this post.)
5 disadvantages of RFI
The strategy behind RFI is simple in theory. Create a list of requirements and select the provider that meets most requirements, unfortunately it does not work so in practice, as anyone who implement RFI process knows. Below are examples of the most common problems with RFI.
Functionality instead of business goals. Everyone must know what the business goals are for the RFI to work, if you have previous experience in supply chain projects you know that is not the case.
Detailed list of requirements. The list of " must have " can contain several requirements from several different teams where the list can quickly grow long, but which is not really necessary. The requirements can omit the capacity you did not know you needed and instead contain features that are not needed.
Too universal. A RFI can take hundreds of hours to create, to save time and labor some organizations borrow one RFI from another. No two suppliers are alike, and no two companies have exactly the same needs as the other.
Forecast accuracy as the end goal instead of tools. An organization often focus on what they know and what no one knows anything about is also lost in RFI as a blind spot. That an organization concentrates on the right measurement values is something that RFI assumes. For example, RFIs in the supply chain often emphasize the accuracy of the forecast. In volatile supply chains , forecasts themselves are always incorrect. The longer forecast horizon, the more inaccurate they are. When optimizing the supply chain, forecasts should be seen as a tool, not as an end point.
Waste of resources. To create an RFI can take hundreds of hours and to evaluate the response may take even longer , only to result in minimal differences among suppliers. Loose interpretations of a function is a risk for the customer who often becomes an advantage for the suppliers.
Running a Proof of Concept as a test drive is a better way to evaluate a software for logistics flows. While RFI sounds good in theory, PoC works in reality . Many stakeholders want to see evidence of what software can do for them and that it works in reality.