RFI, RFP and RFQ madness in supply chain

Joannes Vermorel

Over the years, Lokad has gained some notoriety, and we have earned the privilege of being part of an increasingly large number of RFI (request for information), RFP (request for proposal) and RFQ (request for quote) related to supply chain optimization. While I am grateful that Lokad is considered notable enough to be shortlisted in those initiatives - and routinely selected as well - I cannot help but contemplate the sheer madness that underlies those processes.

I have long been puzzled by the bizarre practices that are prevalent in the realm of enterprise software ¹. More recently, I also proposed an approach that I strongly believe to be superior in every dimension to mainstream ones ². However, today, I would like to unpack some of the frankly bizarre (if not outright insane) elements of RFP I have observed. In a nutshell, RFPs ³ are scientism in action. A perspective, an attitude, and a process that mimic, in the eyes of a general audience, what a “scientific” undertaking is expected to be like. However, in practice, RFPs are about as scientific or rational as a seance.

For starters, the lists of questions collected within RFPs are, without fail, both long and nonsensical. These documents are invariably the product of a committee that attempts to please everyone by listing all the questions everybody could think of. Worse, whenever experts are brought in – typically consultants – to review or improve the list, the catalogue of questions gets inflated by an order of magnitude.

While the saying there is no such thing as a bad question might be a valid guiding principle for a primary school, it is downright harmful when it comes to a large company and its supply chain. Bluntly, in the real world, bad questions can carry dollar costs in time wasted, attention misspent, and expensive compromises made to spare feelings. There are several classes of such questions ⁴, and in the following I will identify seven of the most common and outline their shortcomings.

• Lazy questions. Example: Does the solution follow the security best practices? These questions simply waste everybody’s time. No enterprise software vendor, in their right mind, is ever going to provide a negative response to such a question. 
• Stupid questions. Example: Does the solution manage MOQ (minimal order quantities)? These questions add confusion. Managing MOQs is trivial; it’s doing any kind of optimization in the presence of MOQs that is difficult. 
• “Smart” questions.  Example: How does the solution rationalize forecasting divergences to the original plan in the presence of stockouts? I presume these questions (seemingly precise, but actually vague) are intended to impress colleagues, but they merely add an additional layer of confusion, soon to be compounded by the software vendor’s equally florid response.
• Loaded questions. Example: Does the solution offer the possibility to manage and adjust seasonality profiles? These questions interfere with the neutrality of the process and beg additional implicit questions. The example question implies that seasonality should be approached through “profiles” (why?) and that end-users should be involved (why?).
• Ambiguous questions. Example: Does the solution allow for the introduction of KPIs? This class of question exacerbates misunderstandings. What constitutes a KPI (key performance indicator) is in the eye of the beholder; the vendor and the client are unlikely to share the same sentiments in this regard. 
• Tangential questions. Example: Can the solution recompute in real time its replenishment suggestions? These queries serve to distract from core issues. The notion of “real time”, in the realm of distributed enterprise software, entails long, overly technical discussions that are ultimately irrelevant if the replenishment figures are garbage to begin with.
• Scary questions. Example: Is the solution certified as ISO/IEC 27001? Such questions give leverage to the wrong parties. Certifications, in enterprise software, give power to certifying bodies and their ecosystem, while doing absolutely nothing of value for the client company. 

Expecting that the right vendor can be chosen by asking the wrong questions makes about as much sense as expecting a calculation to be correct while using incorrect initial figures. Yet, this appears to be the go-to approach adopted by most large companies when it comes to enterprise software.

To make things worse, many RFPs include a “Compliance” column - or something along those lines - next to the “Answer” column, asking the vendor to self-diagnose their own degree of compliance with the question. The idea that a software product could be compliant with a question is baffling. However, in practice, RFP questions are so full of biases that the “compliance” column does make some sense, albeit in a bizarre, twisted way.

I should also point out that (almost?) all RFP documents reflect, in their own presentation, a rather brutal lack of care. Every paragraph comes with horrid spelling mistakes. There are duplicate questions and duplicate question numbers. The font size inelegantly shifts from 6 to 20 and haphazard line returns litter the document. Question-wise, it’s even worse as RFPs are typically formatted as Microsoft Excel spreadsheets - spread over several tabs, mind you, each one of which has its own “Question” and “Answer” columns, plus a couple of others for good measure (such as the “Compliance” example listed above). The spreadsheet format makes zero sense in the context of an RFP. The user-experience – be it writing or reading a multi-paragraph piece of content within a spreadsheet cell - is miserable; even more so when there are hundreds of questions, as is usually the case. 

As if that weren’t enough, consider that e-procurement tools, frequently used to conduct these charades, were forged in the 9th circle of hell. These tools represent the worst incarnations of enterprise software, with each one pioneering ways of lowering expectation: unresponsive, sloppy design, inane user-experience, and saddled with Tolkien-length backlogs of unfixed bugs. Through the use of such e-procurement tools, the bureaucratic insanity gets turned up to eleven ⁵.

It is naïve to think that form is inconsequential as long as there is substance. The form of an RFP, atrocious as it is, ensures that delving into the questions, let alone the answers, is a massive time sink. As a result, the people who should be spearheading the selection process – executives like the supply chain director – step back and delegate to “experts”, such as procurement managers or third parties. Procurement managers usually have little insight into what constitutes a reasonable solution for their own company. Meanwhile, third parties, introduced as facilitators of the RFP, are incentivized to make the undertaking as labyrinthine as possible.

Some might argue that an RFP is a lesser evil compared to the outright bribery that would occur in its absence. In other words, RFPs, as defective as they may be, remain the safest option to preserve the integrity of the company and its selection process. However, this is quite an extraordinary claim and, thus, requires extraordinary evidence. Indeed, it begs questions regarding the sort of fraud RFPs are supposed to prevent and, consequently, how effective they are in this mission. Candidly, the idea that channeling a large selection process through an equally large and haphazard spreadsheet makes the process “more honest” seems, on its face, quite a stretch. (Pardon my skepticism.) 

My own anecdotal observations of the enterprise software world indicate that many large software vendors generously reward people who used to be in positions of influence, RFP-wise, by hiring them a decade later. The antidote to this (mal)practice is straightforward: identify vendors who play this game and ban them outright ⁶. Realistically, RFPs do nothing against the sort of forward-thinking bribery that exists in the world of enterprise software.

Thus, my analysis is as follows: anything that makes the vendor selection process more bureaucratic than is strictly necessary, in turn makes the process more vulnerable to malicious actors. This proposition can be rephrased from a computer security perspective: bureaucracy increases the attack surface of the vendor selection process, as it spreads trust (and thus vulnerability) over layers of people that have no reason to be trusted as far as this process is concerned.

Despite all these issues, RFPs are prevalent in enterprise software. Yet, in private, most people - at least those who don’t make a living out of RFPs - admit that the process makes little sense, which makes the prevalence of RFPs all the more puzzling. The simplest explanation I can summon is that RFPs are an elaborate form of corporate virtue signaling ⁷. In the age of information technologies, admitting a major decision can be made based on nothing more than an educated guess isn’t acceptable, and is perceived as simplistic, unsophisticated, and downright unscientific. The RFP process may not bring anything of value for the company but it does thoroughly address the virtue signaling angle.