Dos plantillas para RFI y RFP sobre supply chain software
La mayoría de las organizaciones no compran supply chain software cada año; cuando lo hacen, el proceso a menudo se ritualiza como un RFI seguido de un RFP. En mi libro Introduction to Supply Chain, sostengo que estos rituales no son la mejor manera de elegir software. Un breve ejercicio adversarial de investigación de mercado—basado en tus propios datos y enfocado en resultados medibles—tiende a ser más rápido, barato y más fiable. Sin embargo, muchos equipos aún enfrentan mandatos de adquisiciones que requieren un camino RFI/RFP. Este artículo ofrece dos plantillas listas para usar—primero un RFI, luego un RFP—que preservan el espíritu de la evidencia y los resultados incluso dentro de un proceso formal.
Si eres nuevo en los acrónimos: un RFI (request for information) se utiliza típicamente para explorar el panorama de forma amplia; un RFP (request for proposal) se utiliza para seleccionar entre una lista corta para un alcance concreto. Ningún documento, por sí solo, garantiza buenas decisiones; lo que importa son las preguntas que haces y las respuestas que aceptarás.
Cómo usar estas plantillas
- Trata el RFI como un filtro: elimina soluciones que no puedan expresar resultados en dinero, que no manejen la incertidumbre de forma explícita o que no operen de manera segura sin supervisión humana constante.
- Trata el RFP como una prueba: exige una definición clara del problema, una lógica de decisión explícita, evidencia de parallel‑run y un modelo comercial alineado con los resultados—no con tiempo en pantalla.
RFI — un filtro breve y conciso (12 ítems)
1) Objetivo económico en dinero claro
Pregunta. ¿Qué objetivo financiero optimiza tu producto en producción? Por favor, exprésalo en términos de dinero (p.ej., margen después de las bajas y cargos de capital de trabajo), no en porcentajes.
Por qué es importante. Los KPIs en porcentaje (nivel de servicio, forecast error) no son un resultado; lo que importa es el beneficio y el efectivo. Si un proveedor no puede hablar en términos de dinero, no puede arbitrar compensaciones.
Buena respuesta. “Por SKU‑ubicación‑día calculamos el margen bruto esperado menos los costos de mantenimiento, el riesgo de obsolescencia, las penalizaciones y un cargo de capital; elegimos acciones que mejoren el beneficio neto esperado a lo largo del horizonte.”
2) Decisiones, no dashboards
Pregunta. ¿Qué decisiones operativas produce de forma automática tu software en estado estable (p.ej., líneas de compra, transferencias, órdenes de producción, cambios de precio), y con qué granularidad y cadencia? Proporciona los porcentajes típicos de decisiones no supervisadas de despliegues en vivo.
Por qué es importante. Los informes son útiles; las decisiones mueven stock, capacidad y efectivo.
Buena respuesta. “Reabastecimiento: ~99.95% de las líneas emitidas sin supervisión a nivel de SKU‑ubicación; ~0.05% marcadas para revisión según reglas explícitas. Cambios de precio propuestos diariamente a nivel de artículo con justificación en dólares.”
3) Incertidumbre manejada explícitamente
Pregunta. ¿Cómo representas la incertidumbre para la demanda, los tiempos de entrega y la confiabilidad de la supply chain? ¿Transmites rangos/probabilidades a la decisión, o colapsas todo a valores puntuales + factores de seguridad?
Por qué es importante. La economía de la supply chain ocurre en los extremos; las decisiones basadas en conjeturas de un solo punto son frágiles.
Buena respuesta. “Mantenemos distribuciones empíricas para la demanda y el tiempo de entrega, actualizamos diariamente y optimizamos contra la distribución completa (no solo las medias).”
4) Parallel‑run antes del cut‑over
Pregunta. Describe tu práctica estándar de parallel‑run (“dual‑run”) antes del go‑live. ¿Qué artefactos diarios se capturan? ¿Qué califica como una recomendación “nonsensical” y cómo se elimina antes del cut‑over?
Por qué es importante. El parallel‑run es la forma más rápida de detectar, de manera segura, problemas en el modelo y la semántica.
Buena respuesta. “Ejecutamos el alcance completo a diario, registramos las emisiones y las explicaciones por decisión, clasificamos anomalías, corregimos las causas y requerimos cero líneas nonsensical durante 10 días hábiles consecutivos antes de hacer el cambio.”
5) Lógica de decisión programable
Pregunta. ¿Cómo se redacta y mantiene la lógica de decisión (lenguaje/DSL)? ¿Quién puede modificarla y con qué rapidez?
Por qué es importante. Las supply chain reales son idiosincráticas; las casillas de verificación no las abarcan.
Buena respuesta. “Un script compacto y legible (de pocas centenas de líneas) mantenido por un supply‑chain engineer; cambio pequeño típico: menos de 1 día desde la solicitud hasta el despliegue con control de versiones.”
6) Flujo de datos limpio y reproducibilidad
Pregunta. ¿Operas a partir de snapshots diarios inmutables (con marcas de tiempo y checksums), o a partir de bases de datos en vivo mutables/marts ‘cleansed’? ¿Puedes reproducir cualquier ejecución pasada bit‑por‑bit?
Por qué es importante. La reproducibilidad es la diferencia entre depurar y adivinar.
Buena respuesta. “Snapshot diario a una ‘closing bell’ fija; CSV/Parquet fiel al esquema; cada ejecución vinculada a versiones de datos + código para una reproducción exacta.”
7) Explicación por decisión
Pregunta. ¿Qué explicación acompaña a cada decisión emitida? Enumera los impulsores financieros que revelas y un ejemplo del formato.
Por qué es importante. No confiarás en lo que no puedas explicar a operaciones y finanzas.
Buena respuesta. “Cada línea muestra los impulsores principales con signo/magnitud: margen esperado, costo de faltante de stock, costo de mantenimiento y la restricción que limitó la elección.”
8) Condiciones de parada de seguridad
Pregunta. ¿Bajo qué condiciones tu motor deja de emitir decisiones y recurre a operaciones manuales?
Por qué es importante. La seguridad no es un banner en el dashboard; es una parada automática.
Buena respuesta. “Se detiene ante la ausencia o desactualización de tablas clave, cambios anómalos en las distribuciones o contradicciones (p.ej., capacidad disponible negativa). Notifica al responsable con pistas sobre la causa raíz.”
9) Frontera con sistemas de registros
Pregunta. ¿Eres el mismo proveedor que nuestro ERP/WMS? En caso afirmativo, ¿cómo aseguras una frontera limpia entre el procesamiento de transacciones y la toma de decisiones intensiva?
Por qué es importante. Los sistemas integrados a menudo heredan las limitaciones de la capa de transacciones. Además, es fundamental poder “desenchufar” ya sea el sistema de registros o el sistema de inteligencia; las dos soluciones no deben estar agrupadas.
Buena respuesta. “Tiempo de ejecución independiente; leer snapshots, escribir órdenes/precios a través de una interfaz reducida. Bases de datos estrictamente independientes para segregar las cargas de trabajo transaccionales de las analíticas.”
10) Medición del uplift en dinero
Pregunta. ¿Cómo mides el impacto frente a la línea base una vez en vivo? Por favor, describe los indicadores financieros y el diseño de comparación.
Por qué es importante. Si no puedes medir el uplift, no puedes gestionarlo.
Buena respuesta. “Paquete mensual con uplift de beneficio neto desglosado en ganancias de margen, reducción de bajas y capital liberado; línea base a partir de meses de dual‑run y sitios de control.”
11) Alineación comercial con los resultados
Pregunta. ¿Qué opciones de precios vinculan las tarifas al volumen/calidad de decisiones automatizadas y/o al uplift medido?
Por qué es importante. Pagar por asientos incentiva el trabajo manual; pagar por resultados incentiva la calidad de la automatización.
Buena respuesta. El proveedor cobra poco por la instalación. La mayoría de las tarifas se posponen hasta que la solución demuestre su capacidad para generar decisiones sin supervisión rentables.
12) Roles y propiedad
Pregunta. ¿Qué roles del cliente se necesitan para asumir la propiedad de la lógica, el flujo de datos y los parámetros financieros?
Por qué es importante. Un equipo pequeño y responsable supera a comités difusos.
Buena respuesta. “Un responsable designado para la lógica de decisión, un administrador de datos para el snapshot diario y un socio financiero para mantener los parámetros monetarios.”
RFP — una prueba concreta y comprobable (20 ítems)
1) Declaración del problema en tus propias palabras
Pregunta. Escribe dos páginas que reformulen nuestro desafío sin promocionar tu producto. Enfatiza lo que está en juego (dinero y riesgo), las incertidumbres, las decisiones a automatizar y las restricciones.
Por qué es importante. No puedes resolver lo que no has formulado claramente.
Buena respuesta. “Una narrativa precisa con números, restricciones e incertidumbres, no de marketing.”
2) Modelo económico
Pregunta. Describe el modelo monetario que usarás: unidad de análisis, horizontes, cómo tratas los costos de mantenimiento, las bajas, las penalizaciones y los costos compartidos.
Por qué esto importa. Las decisiones reflejan cómo valoras los trade‑offs.
Buena respuesta. “SKU‑location‑day con cargo de capital mensual; curva explícita de bajas según la antigüedad; penalizaciones por entregas tardías valoradas por carril; costos compartidos asignados por generadores de actividad.”
3) Objetivo y restricciones (formales)
Pregunta. Proporciona el objetivo en matemáticas/pseudocódigo y enumera las restricciones duras vs blandas. Explica cómo la incertidumbre ingresa en el objetivo.
Por qué esto importa. La precisión aquí previene meses de ajustes desalineados posteriormente.
Buena respuesta. “Maximizar el beneficio neto esperado durante T días sujeto a límites de capacidad/crédito; restricciones blandas (MOQs, mínimos de presentación) valoradas con penalizaciones explícitas.”
4) Modelado de la demanda y tiempos de entrega
Pregunta. Detalla tu enfoque para la demanda intermitente, promociones, canibalización y la variabilidad en los tiempos de entrega. ¿Con qué frecuencia se actualizan los modelos?
Por qué esto importa. Las largas colas y los cambios de régimen son la norma. Los modelos de series temporales son seguramente insuficientes.
Buena respuesta. “Modelos probabilísticos generales de alta dimensión actualizados diariamente sin recorte de valores atípicos.”
5) Acciones admisibles y palancas
Pregunta. Enumera lo que el motor puede hacer (comprar/mover/producir/preciar), a qué granularidad y cadencia, y las palancas disponibles (tamaños de lote, carriles, sustituciones, escalones de precio).
Por qué esto importa. La calidad de la optimización está limitada por el conjunto de opciones.
Buena respuesta. “Reorden diario en SKU‑location; transferencias inter‑DC semanales; lotes make‑to‑order ≥ X; escalera de precios con Δ=Y.”
6) Saber cuándo esperar
Pregunta. ¿Cómo decides entre actuar ahora versus posponer una decisión?
Por qué esto importa. Esperar puede ser la acción más rentable.
Buena respuesta. “Actúa solo cuando la ganancia financiera esperada supere el carrying cost + risk premium + el valor de la información al esperar un día.”
7) Enfoque algorítmico y escalabilidad
Pregunta. Describe tu optimizador (heurísticas, programación matemática, búsqueda de políticas) y cómo evitas explosiones combinatorias mientras respetas las restricciones acopladas.
Por qué esto importa. Los modelos de juguete elegantes a menudo se desmoronan a gran escala. Los solucionadores deterministas (ej: MILP) también se desmoronan ante la incertidumbre.
Buena respuesta. “Selección voraz en el beneficio marginal bajo restricciones, con un solucionador estocástico focalizado para sub‑problemas restringidos; probado para funcionar en N=50M item‑days/noche.”
8) Lógica de decisión de ejemplo
Pregunta. Proporciona un fragmento redactado o flujo (entradas → transformaciones → selección → salidas) de un cliente similar.
Por qué esto importa. Una lógica legible es una lógica mantenible.
Buena respuesta. “Flujo de una página con nombres de campo, métricas intermedias y el esquema de write‑back.”
9) Explicación por decisión (ejemplo)
Pregunta. Adjunta un ejemplo de ‘explain’ para una línea de pedido y un cambio de precio. Muestra los principales impulsores con signo y magnitud.
Por qué esto importa. Sin esto, terminarás debatiendo opiniones, no impulsores.
Buena respuesta. “Una tabla compacta: +$12 expected margin, −$5 carrying cost, −$7 faltante de stock evitado; restricción vinculante: la capacidad del muelle de entrada.”
10) Plan de ejecución paralela y criterios de salida
Pregunta. Propón un plan de ejecución paralela diario con artefactos, flujo de trabajo de triaje y un criterio de salida cuantitativo.
Por qué esto importa. Quieres una puesta en marcha científica, no ceremonial.
Buena respuesta. “30 días hábiles de ejecuciones diarias; triaje por severidad; salida cuando 0 líneas sin sentido durante 10 días consecutivos.”
11) Paradas de seguridad y alertas
Pregunta. Enumera las condiciones que detienen las emisiones, cómo se enrutan las alertas y cómo se seleccionan las opciones de respaldo.
Por qué esto importa. La fiabilidad supera el tiempo activo ciego.
Buena respuesta. “Detenerse en tabla obligatoria faltante, chequeos de cordura fallidos o deriva extrema de parámetros; enrutar al propietario asignado; reanudar solo después de chequeos verdes.”
12) Detección de deriva semántica
Pregunta. ¿Cómo detectas cuando el significado de un campo cambió aguas arriba (por ejemplo, cambios de unidad, nuevos códigos)?
Por qué esto importa. Los cambios semánticos silenciosos generan los peores errores.
Buena respuesta. “Versionado de esquemas; monitoreo de distribución; recomputaciones canary; cuarentena automática de entidades sospechosas.”
13) Contrato de alimentación de datos (“snapshot”)
Pregunta. Especifica los archivos/tablas diarios, el tiempo límite, los formatos y la validación que requieres. Incluye checksums y manejo de fallos.
Por qué esto importa. Las uniones claras previenen integraciones frágiles.
Buena respuesta. “Descarga diaria a las 6am UTC; recuentos a nivel de fila, manifiesto hash; rechazar‑con‑reporte en caso de discrepancia.”
14) Gobernanza de las anulaciones
Pregunta. ¿Cómo se registran, auditan y convierten las anulaciones humanas en mejoras de la lógica?
Por qué esto importa. Las anulaciones deberían disminuir con el tiempo.
Buena respuesta. “Cada anulación es un ticket con códigos de razón; revisión semanal; los patrones aceptados se convierten en cambios de lógica en la siguiente versión.”
15) Plan de medición de impacto
Pregunta. Define los KPIs financieros y el diseño comparativo para medir el impacto a los seis y doce meses después de la puesta en marcha.
Por qué esto importa. No se puede discutir con una métrica con la que se acordó de antemano.
Buena respuesta. “Incremento del beneficio neto con descomposición (margen, eliminaciones, capital); sitios de control vs tratados; consciente de la estacionalidad.”
16) Seguridad y minimización de datos
Pregunta. Describe el acceso con mínimos privilegios, la retención de datos y el aislamiento entre entornos.
Por qué esto importa. Los fallos de seguridad borran todas las ganancias.
Buena respuesta. “Solo lectura para snapshots; sin PII a menos que esté justificado; retención de 90 días. Ningún becario toca la producción.”
17) Rendimiento a escala
Pregunta. Proporcione tiempos de ejecución esperados y supuestos de hardware para nuestro orden de magnitud (SKUs, sites, transactions).
Por qué esto importa. Overnight debe significar overnight.
Buena respuesta. “Para <100M item‑days: 50 minutos garantizados; asignación elástica de cloud resources.”
18) Extensibilidad más allá del primer alcance
Pregunta. ¿Cómo agregará nuevas categorías, channels o países sin reescribir desde cero?
Por qué esto importa. El piloto de hoy se convierte en la plataforma de mañana.
Buena respuesta. “Lógica central compartida + módulos locales para restricciones y parámetros; el nuevo alcance típicamente agrega archivos pequeños e aislados.”
19) Términos comerciales alineados con los resultados
Pregunta. Ofrezca al menos una opción donde las tarifas se alineen con el volumen de decisiones automatizadas y/o el incremento financiero auditado. Explique el proceso de auditoría.
Por qué esto importa. Los incentivos moldean el comportamiento.
Buena respuesta. “Tarifa fija + componente de éxito calculado a partir de la fórmula de uplift acordada y auditable; hojas de cálculo transparentes y ejecuciones reproducibles.”
20) Lo que no hará
Pregunta. Enumere algunas actividades populares que intencionalmente excluirá (con razones).
Por qué esto importa. Decir “no” es un signo de disciplina en ingeniería.
Buena respuesta. “No a los gemelos de vanidad; no a concursos de ‘accuracy’ desvinculados de resultados financieros; no a demostraciones únicas en datos de juguete.”
Nota de cierre
Si puede evitar un RFI/RFP de gran envergadura, hágalo: una carrera de investigación de mercado enfocada y adversarial—sobre sus datos—le llevará a obtener evidencia más rápidamente. Si no puede, las dos plantillas anteriores aún inclinarán el proceso hacia decisions and money, que es el objetivo principal del software de supply chain.
