RFI, RFP y RFQ: la locura en supply chain
Con los años, Lokad ha ganado algo de notoriedad, y hemos obtenido el privilegio de formar parte de un número cada vez mayor de RFI (request for information), RFP (request for proposal) y RFQ (request for quote) relacionados con optimización de supply chain. Aunque agradezco que se considere a Lokad lo suficientemente notable como para estar preseleccionado en esas iniciativas – y ser rutinariamente elegido también – no puedo evitar contemplar la pura locura que subyace en esos procesos.

He estado desconcertado durante mucho tiempo por las prácticas extrañas que prevalecen en el ámbito del software empresarial 1. Más recientemente, también propuse un enfoque en el que creo firmemente que es superior en todas las dimensiones a los enfoques tradicionales 2. Sin embargo, hoy, me gustaría desglosar algunos de los elementos francamente extraños (si no abiertamente insanos) de los RFP que he observado. En resumen, los RFP 3 son cientificismo en acción. Una perspectiva, una actitud y un proceso que imitan, a los ojos del público en general, lo que se espera que sea un emprendimiento “científico”. Sin embargo, en la práctica, los RFP son tan científicos o racionales como una sesión espiritista.
Para empezar, las listas de preguntas recopiladas en los RFP son, sin falta, tanto largas como sin sentido. Estos documentos son invariablemente el producto de un comité que intenta complacer a todos enumerando todas las preguntas que cualquiera podría imaginar. Peor aún, siempre que se incorporan expertos – generalmente consultores – para revisar o mejorar la lista, el catálogo de preguntas se infla por un orden de magnitud.
Si bien el dicho no hay preguntas malas podría ser un principio válido para una escuela primaria, es francamente perjudicial cuando se trata de una gran empresa y su supply chain. En términos simples, en el mundo real, las preguntas malas pueden acarrear costos en dólares debido al tiempo perdido, la atención mal invertida y costosos compromisos realizados para evitar herir sensibilidades. Existen varias clases de estas preguntas 4, y a continuación identificaré siete de las más comunes y esbozaré sus deficiencias.
- Preguntas flojas. Ejemplo: ¿La solución sigue las mejores prácticas de seguridad? Estas preguntas simplemente hacen perder el tiempo a todos. Ningún proveedor de software empresarial, en su sano juicio, va a dar una respuesta negativa a una pregunta así.
- Preguntas estúpidas. Ejemplo: ¿La solución gestiona MOQ (cantidades mínimas de pedido)? Estas preguntas generan confusión. Gestionar los MOQ es trivial; lo difícil es realizar cualquier tipo de optimización en presencia de MOQ.
- Preguntas “inteligentes”. Ejemplo: ¿Cómo racionaliza la solución las divergencias en forecast con respecto al plan original en presencia de faltante de stock? Presumo que estas preguntas (aparentemente precisas, pero en realidad vagas) están destinadas a impresionar a los colegas, pero simplemente añaden una capa adicional de confusión, que pronto se verá agravada por la respuesta igualmente florida del proveedor de software empresarial.
- Preguntas con trampa. Ejemplo: ¿La solución ofrece la posibilidad de gestionar y ajustar los perfiles de estacionalidad? Estas preguntas interfieren con la neutralidad del proceso y generan preguntas implícitas adicionales. La pregunta de ejemplo implica que la estacionalidad debe abordarse a través de “perfiles” (¿por qué?) y que se debe involucrar a los usuarios finales (¿por qué?).
- Preguntas ambiguas. Ejemplo: ¿La solución permite la introducción de KPIs? Esta clase de preguntas exacerba los malentendidos. Lo que constituye un KPI (indicador clave de rendimiento) está en el ojo del observador; es poco probable que el proveedor y el cliente compartan los mismos criterios al respecto.
- Preguntas tangenciales. Ejemplo: ¿Puede la solución recalcular en tiempo real sus sugerencias de reabastecimiento? Estas consultas sirven para distraer de los temas centrales. La noción de “tiempo real”, en el ámbito del software empresarial distribuido, conlleva discusiones largas y demasiado técnicas que en última instancia son irrelevantes si las cifras de reabastecimiento son basura desde el principio.
- Preguntas intimidantes. Ejemplo: ¿La solución cuenta con la certificación ISO/IEC 27001? Este tipo de preguntas da poder a las partes equivocadas. Las certificaciones, en el software empresarial, otorgan poder a los organismos certificadores y su ecosistema, mientras que no aportan absolutamente nada de valor para la empresa cliente.
Esperar que se pueda elegir al proveedor adecuado haciendo las preguntas equivocadas tiene prácticamente el mismo sentido que esperar que un cálculo sea correcto utilizando cifras iniciales incorrectas. Sin embargo, este parece ser el enfoque habitual adoptado por la mayoría de las grandes empresas cuando se trata de software empresarial.
Para empeorar las cosas, muchos RFP incluyen una columna de “Conformidad” - o algo por el estilo - junto a la columna de “Respuesta”, pidiendo al proveedor que se autodiagnostique su propio grado de cumplimiento con la pregunta. La idea de que un producto de software pueda ser compliant con una pregunta es desconcertante. Sin embargo, en la práctica, las preguntas de los RFP están tan llenas de sesgos que la columna de “Conformidad” sí tiene cierto sentido, aunque de una manera extraña y retorcida.
También debo señalar que (¿casi?) todos los documentos de RFP reflejan, en su propia presentación, una falta de cuidado bastante brutal. Cada párrafo viene acompañado de horribles errores ortográficos. Hay preguntas duplicadas y números de preguntas duplicados. El tamaño de la fuente cambia de manera inelegante de 6 a 20 y retornos de línea al azar inundan el documento. En cuanto a las preguntas, es incluso peor, ya que los RFP suelen estar formateados como hojas de cálculo de Microsoft Excel - repartidas en varias pestañas, cada una de las cuales tiene sus propias columnas de “Pregunta” y “Respuesta”, además de un par de otras para remate (como el ejemplo de “Conformidad” mencionado anteriormente). El formato de hoja de cálculo no tiene ningún sentido en el contexto de un RFP. La experiencia de usuario – ya sea escribiendo o leyendo un contenido de varios párrafos dentro de una celda de una hoja de cálculo – es miserable; aún más cuando hay cientos de preguntas, como suele ser el caso.
Como si eso no fuera suficiente, considere que las herramientas de e-procurement, utilizadas con frecuencia para llevar a cabo estas farsas, fueron forjadas en el noveno círculo del infierno. Estas herramientas representan las peores encarnaciones del software empresarial, siendo cada una pionera en maneras de rebajar las expectativas: poco responsivas, con un diseño descuidado, una experiencia de usuario inane, y cargadas con retrasos de bugs sin resolver al estilo de Tolkien. Mediante el uso de tales herramientas de e-procurement, la locura burocrática se lleva al once 5.
Es ingenuo pensar que la forma es intrascendente mientras haya sustancia. La forma de un RFP, por espantosa que sea, garantiza que adentrarse en las preguntas, y mucho menos en las respuestas, sea un gran ladrón de tiempo. Como resultado, las personas que deberían liderar el proceso de selección – ejecutivos como el director de supply chain – se repliegan y delegan en “expertos”, tales como gerentes de procurement o terceros. Los gerentes de procurement normalmente tienen poca visión de lo que constituye una solución razonable para su propia empresa. Mientras tanto, los terceros, introducidos como facilitadores del RFP, están incentivados a hacer que el proceso sea lo más laberíntico posible.
Algunos podrían argumentar que un RFP es un mal menor comparado con el soborno descarado que ocurriría en su ausencia. En otras palabras, los RFP, por defectuosos que sean, siguen siendo la opción más segura para preservar la integridad de la empresa y su proceso de selección. Sin embargo, esta es una afirmación bastante extraordinaria y, por lo tanto, requiere pruebas extraordinarias. De hecho, se plantean preguntas respecto al tipo de fraude que se supone deben prevenir los RFP y, en consecuencia, cuán efectivos son en esta misión. Sinceramente, la idea de canalizar un gran proceso de selección a través de una hoja de cálculo igualmente grande y desordenada hace que el proceso sea “más honesto” parece, a primera vista, un gran salto. (Perdone mi escepticismo.)
Mis propias observaciones anecdóticas del mundo del software empresarial indican que muchos grandes proveedores de software recompensan generosamente a las personas que solían estar en posiciones de influencia, en lo que respecta a RFP, contratándolas una década después. El antídoto a esta (mala) práctica es sencillo: identificar a los proveedores que juegan este juego y prohibirlos de plano 6. Realísticamente, los RFP no hacen nada contra el tipo de soborno visionario que existe en el mundo del software empresarial.
Así, mi análisis es el siguiente: cualquier cosa que haga que el proceso de selección de proveedores sea más burocrático de lo estrictamente necesario, a su vez, hace que el proceso sea más vulnerable a actores malintencionados. Esta proposición puede replantearse desde una perspectiva de seguridad informática: la burocracia aumenta la superficie de ataque del proceso de selección de proveedores, ya que distribuye la confianza (y, por ende, la vulnerabilidad) sobre capas de personas en las que no se justifica la confianza en cuanto a este proceso se refiere.
A pesar de todos estos problemas, los RFP son prevalentes en el software empresarial. Sin embargo, en privado, la mayoría de las personas - al menos aquellas que no viven a base de RFP - admiten que el proceso tiene poco sentido, lo que hace que la prevalencia de los RFP sea aún más desconcertante. La explicación más simple que puedo proponer es que los RFP son una forma elaborada de señalización de virtud corporativa 7. En la era de las tecnologías de la información, admitir que una decisión importante puede tomarse basándose únicamente en una conjetura educada no es aceptable, y se percibe como simplista, poco sofisticada y francamente poco científica. El proceso de RFP puede no aportar nada de valor para la empresa, pero sí aborda a fondo el ángulo de la señalización de virtud.
-
Una guía para compradores de software empresarial, Joannes Vermorel, agosto 2013. ↩︎
-
Investigación de mercado adversarial para software empresarial - Lección 2.4, marzo 2021, Joannes Vermorel ↩︎
-
A efectos de concisión, en esta entrada el término “RFP” se refiere colectivamente a RFI, RFP y RFQ. ↩︎
-
Todos los ejemplos listados en esta sección son preguntas reales de RFP que hemos recibido durante los últimos 12 meses. ↩︎
-
Como regla general, cuando se utiliza una herramienta de e-procurement, tanto Lokad como su cliente potencial desperdician el equivalente a varios días-hombre haciendo lo que equivale a enviar un correo electrónico con un adjunto PDF a 5 destinatarios en CC. ↩︎
-
LinkedIn facilita relativamente la identificación de proveedores de software que contratan a personas que convenientemente solían estar en el lugar correcto en el momento adecuado. Sin embargo, tener toda la información relevante en exhibición pública hace que este tipo de corrupción sea aún más astuto, ya que ni siquiera requiere una comunicación explícita entre las partes; basta con un entendimiento tácito. ↩︎
-
Otro beneficio colateral incidental de los RFP podría ser la dilución de la responsabilidad, ya que los RFP, por diseño, involucran a bastantes personas en el lado del cliente. ↩︎