Locura de RFI, RFP y RFQ en la gestión de la cadena de suministro

Joannes Vermorel

A lo largo de los años, Lokad ha ganado cierta notoriedad y hemos tenido el privilegio de formar parte de un número cada vez mayor de RFI (solicitud de información), RFP (solicitud de propuesta) y RFQ (solicitud de cotización) relacionados con la optimización de la cadena de suministro. Aunque estoy agradecido de que Lokad sea considerado lo suficientemente “notable” como para ser preseleccionado en esas iniciativas, y seleccionado rutinariamente también, no puedo evitar contemplar la locura absoluta que subyace a esos procesos.

Durante mucho tiempo me he sentido desconcertado por las prácticas extrañas que prevalecen en el ámbito del software empresarial ¹. Más recientemente, también propuse un enfoque que creo firmemente que es superior en todas las dimensiones a los enfoques convencionales ². Sin embargo, hoy me gustaría analizar algunos de los elementos francamente extraños (si no completamente insanos) de las RFP que he observado. En pocas palabras, las RFP ³ son cientificismo en acción. Una perspectiva, una actitud y un proceso que imitan, a los ojos de una audiencia general, lo que se espera que sea una empresa “científica”. Sin embargo, en la práctica, las RFP son tan científicas o racionales como una sesión de espiritismo.

Para empezar, las listas de preguntas recopiladas dentro de las RFP son, sin excepción, largas y sin sentido. Estos documentos son invariablemente el producto de un comité que intenta complacer a todos enumerando todas las preguntas que a todos se les ocurrieron. Peor aún, cada vez que se involucra a expertos, típicamente consultores, para revisar o mejorar la lista, el catálogo de preguntas se infla en un orden de magnitud.

Si bien el dicho no hay preguntas tontas puede ser un principio rector válido para una escuela primaria, es francamente perjudicial cuando se trata de una gran empresa y su cadena de suministro. Francamente, en el mundo real, las preguntas tontas pueden tener costos en dólares en tiempo desperdiciado, atención malgastada y compromisos costosos realizados para evitar herir sentimientos. Hay varias clases de tales preguntas ⁴, y a continuación identificaré siete de las más comunes y describiré sus deficiencias.

• Preguntas perezosas. Ejemplo: ¿La solución sigue las mejores prácticas de seguridad? Estas preguntas simplemente desperdician el tiempo de todos. Ningún proveedor de software empresarial en su sano juicio va a proporcionar una respuesta negativa a tal pregunta.
• Preguntas estúpidas. Ejemplo: ¿La solución gestiona las cantidades mínimas de pedido (MOQ, por sus siglas en inglés)? Estas preguntas generan confusión. Gestionar las MOQs es trivial; lo difícil es realizar cualquier tipo de optimización en presencia de MOQs.
• Preguntas “inteligentes”. Ejemplo: ¿Cómo racionaliza la solución las divergencias de pronóstico con respecto al plan original en presencia de faltantes de stock? Presumo que estas preguntas (aparentemente precisas, pero en realidad vagas) están destinadas a impresionar a los colegas, pero solo agregan una capa adicional de confusión, que pronto se verá agravada por la respuesta igualmente floridada del proveedor de software.
• Preguntas tendenciosas. Ejemplo: ¿La solución ofrece la posibilidad de gestionar y ajustar perfiles de estacionalidad? Estas preguntas interfieren con la neutralidad del proceso y plantean preguntas implícitas adicionales. La pregunta de ejemplo implica que la estacionalidad debería abordarse a través de “perfiles” (¿por qué?) y que los usuarios finales deberían estar involucrados (¿por qué?).
• Preguntas ambiguas. Ejemplo: ¿La solución permite la introducción de KPIs? Esta clase de pregunta agrava los malentendidos. Lo que constituye un KPI (indicador clave de rendimiento) está en el ojo del espectador; es poco probable que el proveedor y el cliente compartan los mismos sentimientos al respecto.
• Preguntas tangenciales. Ejemplo: ¿Puede la solución recalcular en tiempo real sus sugerencias de reabastecimiento? Estas consultas sirven para distraer de los problemas principales. La noción de “tiempo real”, en el ámbito del software empresarial distribuido, implica discusiones largas y demasiado técnicas que son en última instancia irrelevantes si las cifras de reabastecimiento son basura desde el principio.
• Preguntas aterradoras. Ejemplo: ¿La solución está certificada como ISO/IEC 27001? Este tipo de preguntas le dan poder a las partes equivocadas. Las certificaciones, en el software empresarial, otorgan poder a los organismos de certificación y su ecosistema, sin aportar absolutamente nada de valor para la empresa cliente.

Esperar que el proveedor correcto pueda ser elegido haciendo las preguntas incorrectas tiene tanto sentido como esperar que un cálculo sea correcto mientras se utilizan cifras iniciales incorrectas. Sin embargo, este parece ser el enfoque 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 “Cumplimiento” - o algo similar - junto a la columna de “Respuesta”, pidiendo al proveedor que autodiagnostique su propio grado de cumplimiento con la pregunta. La idea de que un producto de software pueda ser “cumpliente” con una pregunta es desconcertante. Sin embargo, en la práctica, las preguntas de RFP están tan llenas de sesgos que la columna de “cumplimiento” 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 con horribles errores de ortografía. Hay preguntas duplicadas y números de pregunta duplicados. El tamaño de la fuente cambia inelegante de 6 a 20 y los retornos de línea al azar llenan el documento. En cuanto a las preguntas, es aún peor, ya que los RFP suelen tener formato de 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”, más un par de otras por si acaso (como el ejemplo de “Cumplimiento” 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 escribir o leer un contenido de varios párrafos dentro de una celda de 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, consideremos que las herramientas de e-procurement, frecuentemente utilizadas para llevar a cabo estas farsas, fueron forjadas en el noveno círculo del infierno. Estas herramientas representan las peores encarnaciones del software empresarial, cada una de ellas pionera en formas de bajar las expectativas: diseño descuidado y sin respuesta, experiencia de usuario inane y cargadas con listas de errores sin corregir de longitud tolkieniana. A través del uso de estas herramientas de e-procurement, la locura burocrática se eleva a once ⁵.

Es ingenuo pensar que la forma es inconsecuente siempre y cuando haya sustancia. La forma de un RFP, atroz como es, asegura que adentrarse en las preguntas, y mucho menos en las respuestas, es una pérdida de tiempo masiva. Como resultado, las personas que deberían liderar el proceso de selección - ejecutivos como el director de la cadena de suministro - se apartan y delegan en “expertos”, como gerentes de adquisiciones o terceros. Los gerentes de adquisiciones suelen tener poca idea de lo que constituye una solución razonable para su propia empresa. Mientras tanto, los terceros, presentados como facilitadores del RFP, tienen incentivos para hacer que la tarea sea lo más laberíntica posible.

Algunos podrían argumentar que un RFP es un mal menor en comparación 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, plantea preguntas sobre el tipo de fraude que se supone que los RFP deben prevenir y, en consecuencia, qué tan efectivos son en esta misión. Francamente, la idea de canalizar un gran proceso de selección a través de una hoja de cálculo igualmente grande y caótica para hacer que el proceso sea “más honesto” parece, a primera vista, bastante exagerada. (Perdón por 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 ocupar puestos de influencia en relación con los RFP contratándolos una década después. El antídoto para esta (mala) práctica es sencillo: identificar a los proveedores que juegan este juego y prohibirlos por completo [^proveedores]. Realísticamente, los RFP no hacen nada contra el tipo de soborno de pensamiento avanzado que existe en el mundo del software empresarial.

Por lo tanto, 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 maliciosos. Esta proposición se puede reformular 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 lo tanto, la vulnerabilidad) entre capas de personas que no tienen motivo para ser confiables en lo que respecta a este proceso.

A pesar de todos estos problemas, los RFP son frecuentes en el software empresarial. Sin embargo, en privado, la mayoría de las personas, al menos aquellas que no se ganan la vida con los RFP, admiten que el proceso no tiene mucho sentido, lo que hace que la prevalencia de los RFP sea aún más desconcertante. La explicación más sencilla que puedo encontrar es que los RFP son una forma elaborada de “señalización de virtud” corporativa [^virtud]. En la era de las tecnologías de la información, admitir que una decisión importante se puede tomar basándose en nada más que una suposición educada no es aceptable y se percibe como simplista, poco sofisticado y totalmente no científico. El proceso de RFP puede no aportar nada de valor para la empresa, pero aborda a fondo el ángulo de señalización de virtud.