Cuando una empresa decide implementar un ERP, el primer paso suele ser elaborar un RFP (Request for Proposal). En teoría, este documento permite recopilar necesidades de cada área, comparar proveedores y tomar una decisión informada sobre la tecnología que soportará la operación del negocio.
Sobre el papel parece un proceso ordenado y racional, sin embargo, en Veyron destacan que en la práctica ocurre algo muy distinto. Según un estudio académico publicado en Intelligent Automation & Soft Computing, basado en análisis de datos de procesos de procurement, entre el 30% y 35% de las licitaciones presentan señales de favoritismo hacia un proveedor.
El RFP suele construirse a partir de información proporcionada por distintas áreas de la empresa, cada una describiendo sus procesos, necesidades y problemas. El resultado es un documento que aparenta ser muy completo, pero que muchas veces está construido sobre diagnósticos parciales, percepciones internas o incluso sesgos organizacionales. Y ahí comienza el verdadero problema.
Cuando todos creen que el problema está en otro lado
En muchos proyectos de ERP, cuando se recopila información para un RFP ocurre una dinámica bastante común: cada área describe los problemas operativos desde su propia perspectiva: Finanzas puede señalar que la información llega tarde o con errores; Operaciones puede argumentar que los procesos administrativos ralentizan la ejecución; o Ventas puede sostener que los sistemas actuales no permiten responder con rapidez al mercado.
Cada área tiene razones legítimas para defender su posición. El problema es que, al reunir todas esas visiones en un documento, el RFP termina reflejando síntomas aislados, no necesariamente la causa estructural de los problemas.
Esto genera un sesgo importante. El documento que debería ayudar a entender el negocio termina siendo una colección de requerimientos funcionales que intentan resolver problemas que tal vez no han sido correctamente diagnosticados. En otras palabras, se intenta elegir tecnología sin haber entendido realmente cómo funciona la organización.
El riesgo: construir decisiones sobre datos que nadie ha cuestionado
Cuando un RFP se construye a partir de percepciones departamentales, aparece un riesgo adicional: la falta de certeza sobre la calidad de la información.
Las empresas suelen asumir que los procesos documentados son correctos o que los datos que circulan entre áreas son confiables. Pero en muchos casos nadie ha revisado realmente si esos procesos siguen siendo eficientes o si los datos reflejan la realidad operativa.
Esto provoca que el proceso de selección de un ERP se base en una pregunta equivocada: qué sistema puede adaptarse mejor a nuestra forma actual de trabajar. Sin embargo, esa forma de trabajar puede ser precisamente parte del problema. En lugar de cuestionar el modelo operativo, el RFP termina institucionalizándolo.
La solución: entender primero el negocio
Antes de comparar sistemas o funcionalidades, las empresas necesitan algo más fundamental: entender cómo funciona realmente su operación. Esto implica analizar procesos completos, revisar flujos de información, entender dónde se generan inconsistencias de datos y, sobre todo, identificar qué parte del modelo operativo ya no escala con el crecimiento de la organización.
Este ejercicio no se trata de asignar culpables entre departamentos. De hecho, ese enfoque suele ser contraproducente. El objetivo es construir una visión compartida de cómo funciona el negocio y dónde están los verdaderos puntos de fricción.
En el mundo empresarial, ese análisis es lo que permite entender qué procesos deben cambiar antes de elegir la tecnología que los soportará.
El ERP no debería comenzar con un RFP
El RFP no es necesariamente una mala herramienta. Puede ser útil cuando existe claridad sobre los procesos del negocio y sobre los objetivos que la organización quiere alcanzar. El problema aparece cuando el RFP se utiliza como punto de partida.
Si la empresa aún no ha entendido sus propios procesos, si los datos operativos no han sido cuestionados o si cada área describe los problemas desde su propia perspectiva, el documento puede terminar amplificando esas mismas confusiones.
Antes de elegir tecnología, las organizaciones necesitan algo más importante: una comprensión clara de cómo funciona su negocio. Solo cuando esa conversación ocurre, el RFP deja de ser un documento lleno de requerimientos y se convierte en lo que debería ser desde el principio: una herramienta para elegir la tecnología adecuada para un modelo operativo que ya tiene sentido.
Porque, como si se tratara de fútbol, antes de cambiar jugadores conviene entender cómo está jugando el equipo.
