Cómo redactar un RFP para un TMS: nuestra experiencia [+ 5 plantillas gratuitas]

Respondemos a RFP (solicitudes de propuesta) de software de gestión de transporte cada semana. Algunos son un placer de trabajar. Otros son una lección sobre lo que no se debe hacer.

Este artículo es lo que yo construiría si tuviera que llevar a cabo un proceso de selección de TMS desde cero hoy. Se basa en los RFP a los que hemos respondido, en los patrones que se repiten entre empresas y sectores, en lo que suelen incluir y en los errores más comunes que observamos.

Si eres especialista en compras, la mayor parte de esto te resultará familiar. Ojalá algo de lo que aquí se cuenta te ahorre al menos una ronda de aclaraciones innecesaria.

¿Qué es un RFP para un TMS?

Un RFP para un TMS (solicitud de propuesta) es un documento estructurado que se envía a los proveedores de software de gestión de transporte. Describe tu operación logística y pide a cada uno que proponga cómo su sistema la gestionaría, respondiendo al mismo conjunto de requisitos. El objetivo es la comparabilidad: las mismas preguntas, el mismo formato, el mismo contexto, de modo que lo que se recibe pueda analizarse en paralelo en lugar de leerse como cinco argumentarios de venta distintos.

No siempre es necesario. Un RFP se justifica cuando la decisión es compleja o cuando tendrás que defenderla internamente. Si tu operación logística es sencilla, una demostración del producto y una llamada con unos pocos proveedores serán suficientes.

¿Realmente necesitas hacer una licitación de transporte mediante RFP?

Equivocarse en esto es el error más caro de todo el proceso de selección de un TMS. Decide esto antes que cualquier otra cosa.

La clave no es el tamaño de tu empresa, sino la complejidad de tu logística.

Lleva a cabo una licitación de transporte estructurada mediante RFP si realizas envíos desde varias sedes, utilizas múltiples modos de transporte y necesitas que el sistema se integre con tu ERP. En ese caso, necesitas tener a todos los proveedores alineados, para que nada importante se escape. Los proveedores se conectan a los transportistas de maneras muy distintas: uno lo llama "nativo", el siguiente lo enruta discretamente a través de un tercero. En un proceso poco riguroso, no lo detectarás hasta después de haber firmado. Demasiado tarde.

Prescinde del RFP formal si gestionas una sola sede con un puñado de transportistas y ya sabes lo que necesitas. ¿Por qué? Porque en el momento en que lanzas un RFP, te sitúas automáticamente en el nivel de precios enterprise. 2 o 3 buenas demostraciones con preguntas concretas suelen conseguirte un sistema mejor, más barato y más rápido. Cuéntales a esos 2 o 3 proveedores qué envías y qué problema intentas resolver, y pídeles que te lo muestren en su sistema en vivo. En una hora tendrás la respuesta. Y si envías principalmente paquetería en lugar de palés o carga, puede que no necesites un TMS completo: el software de envío multiportador es una categoría diferente y más ligera, diseñada precisamente para eso.

Así que sé honesto sobre cuál de las dos opciones prefieres antes de empezar. Lanzar un RFP que no necesitabas es la forma más lenta y cara de comprar un TMS.

Lanzar un RFP que no necesitabas es la forma más lenta y cara de comprar un TMS.

Otra advertencia si decides seguir el proceso completo de RFP. Un proceso cargado de lenguaje de gobernanza, marcos metodológicos y exigencias de precio fijo puede llevar semanas de respuesta, y los proveedores que pueden asumir esa carga administrativa tienden a ser los grandes y consolidados. Así que si una plataforma más ágil y moderna te serviría mejor, un proceso excesivamente burocrático puede filtrarla silenciosamente antes de que llegues a ver una demostración.

El objetivo es encontrar la solución adecuada para ti. Diseña el proceso en torno a eso, no en torno a gestionar el proceso en sí.

El proceso de RFP para un TMS en 9 pasos

La selección de un TMS no tiene por qué ser complicada, pero sí necesita una secuencia clara. Saltarse pasos tiene un coste que se paga más adelante, normalmente durante la implantación, cuando los supuestos que deberían haberse aclarado al principio se convierten en sorpresas costosas.

Bien ejecutado, todo el proceso lleva entre 8 y 12 semanas. Menos para un alcance sencillo, y rara vez hace falta más.

Esta es la secuencia que funciona:

1. Análisis de mercado. Antes de escribir un solo requisito, dedica tiempo a entender qué hay disponible. El mercado de TMS ha evolucionado mucho en los últimos cinco años: existen buenas plataformas enterprise, buenas plataformas para el mercado medio y soluciones SaaS de software de gestión de transporte genuinamente capaces que no existían hace cinco años. Elabora una lista larga de 5 a 8 proveedores de TMS que merezcan ser considerados.
2. NDA. Envíalo pronto. Compartirás datos operativos como volúmenes, nombres de transportistas y detalles de sistemas internos, y un NDA firmado antes de enviar el RFP es una práctica estándar que protege a ambas partes.
3. RFI (opcional). Una breve solicitud de información tiene sentido si tu lista larga es amplia y quieres filtrar antes de invertir en un proceso de RFP completo. Limítala a una página: contexto de la empresa, capacidades clave, rango de precios aproximado. Lo suficiente para preseleccionar sin pedir a los proveedores que escriban ensayos.
4. RFP. El documento central. Proporciona a cada proveedor lo que necesita para hacer una propuesta precisa. Más sobre esto en el siguiente capítulo.
5. Ventana de preguntas y respuestas. Inclúyela siempre. Los proveedores tendrán preguntas, y las respuestas suelen mejorar todas las propuestas que recibes. Gestiona el proceso por escrito y comparte todas las preguntas y respuestas con todos los proveedores simultáneamente. Así el proceso se mantiene limpio y comparable.
6. Preselección y presentaciones. Puntúa las propuestas escritas e invita a 2 o 3 proveedores a presentar. La presentación debe incluir una demostración en vivo del sistema basada en tus casos de uso reales, no una demo genérica. Si un proveedor no puede mostrarte tu escenario en su sistema, eso ya es información útil.
7. Segunda ronda (si es necesario). Para una decisión compleja, una sesión más profunda centrada en aspectos concretos —seguridad, integración, condiciones comerciales— vale la pena. No la programes a menos que tengas preguntas reales pendientes.
8. Decisión y contrato. Alinéate internamente antes de negociar. Ten claros tus requisitos irrenunciables, tus compromisos aceptables y tus líneas rojas.
9. Incorporación. El proceso no termina con la firma. Los mejores resultados de un RFP incluyen un plan de incorporación acordado antes de firmar el contrato.

Calendario de RFP para TMS que puedes copiar

Duración aproximada según el alcance:

• Una sola sede sencilla: 6 a 8 semanas (puede que no necesites un RFP completo).
• Varias sedes + integración con ERP: 8 a 12 semanas.
• Global, con múltiples entidades e integración compleja: 12 a 20 semanas, probablemente con dos rondas de presentaciones.

Descargar la plantilla de calendario de RFP (.docx)

Qué incluir en el documento de RFP para un TMS

El documento de RFP es tu herramienta más importante en todo este proceso. Un buen documento de RFP hace gran parte del trabajo de evaluación por ti, así que mantenlo enfocado. Un RFP conciso de 10 páginas supera a uno de 30 que intenta abarcarlo todo.

1. Carta de presentación y objetivo

Una página. Quién eres, qué buscas, por qué ahora. Sé directo. Los proveedores no necesitan una declaración de visión; solo necesitan entender tu problema operativo.

2. Calendario

Un cronograma claro con fechas reales: emisión del RFP, fecha límite de preguntas y respuestas, entrega de propuestas, ventana de presentaciones, decisión. Los proveedores planifican su esfuerzo de respuesta en función de esto. Los calendarios vagos generan propuestas igual de vagas.

3. Contexto de la empresa y de la operación

Aquí es donde la mayoría de los RFP fallan, y es la diferencia entre propuestas comparables y una ronda de aclaraciones. No te limites a describir tu negocio: describe tu operación logística. Cuántas sedes. Cuántas entidades jurídicas. Qué modos de transporte (paquetería, LTL, FTL, aéreo, marítimo, ferroviario). Qué regiones. Volúmenes aproximados. Sistemas actuales. Lo que se considera "bueno" también varía según el sector: los requisitos para fabricantes de electrónica, maquinaria, productos químicos o impresión y embalaje no son los mismos. Este es el contexto que los proveedores necesitan para elaborar una propuesta precisa. Si no proporcionas suficiente detalle aquí, pasarás dos semanas respondiendo preguntas de aclaración que podrían haberse evitado por completo. Este apartado tiene su propia sección más adelante, en el siguiente capítulo.

4. Requisitos funcionales

Una tabla con lo que el sistema debe hacer, priorizada por importancia: imprescindible / recomendable / deseable (Excel es perfectamente válido). Pide a los proveedores que respondan a cada requisito con su nivel de cobertura: a) nativo, b) de terceros, c) mediante personalización, o d) no disponible. Esto es lo que hace que las propuestas sean comparables. Más adelante se explica cómo construir esta lista.

5. Criterios de evaluación

Indica a los proveedores cómo tomarás la decisión: funcionalidad, precio, enfoque de implantación, referencias, seguridad, equipo. Comparte la ponderación si estás dispuesto a hacerlo. Cuanto más transparente seas, mejores serán las propuestas.

6. Modelo de precios

Solicita un desglose completo: suscripción, implantación, tarifas por transacción, soporte y cualquier otro concepto. Pide una factura de muestra si es posible. Las estructuras de precios varían mucho entre proveedores, y los costes ocultos tienen la costumbre de aparecer tarde. Intenta identificarlos cuanto antes.

7. Formato de respuesta

Indica a los proveedores exactamente cómo quieres que estructuren la propuesta y, si les proporcionas plantillas, exige su uso. Las propuestas comparables te ahorran días durante la evaluación, y el formato está completamente en tu mano.

Descarga la plantilla del documento de RFP para empezar desde la estructura completa descrita arriba:

Descargar la plantilla del documento de RFP (.docx)

La información operativa que la mayoría de los RFP para TMS omiten, y por qué es la más importante

Este es el capítulo que desearía que leyera primero todo el que redacta un RFP para un TMS.

Respondemos a muchas licitaciones de transporte. Casi todas las propuestas que elaboramos requieren una ronda de aclaraciones, y rara vez es porque los requisitos no estuvieran claros. Es porque faltaba el contexto operativo: volúmenes, estructura de sedes, red de transportistas, sistemas actuales.

Los RFP que han requerido una ronda completa de aclaraciones casi siempre tienen algo en común:

Hemos visto empresas invertir semanas en elaborar criterios de evaluación y listas de requisitos, para luego enviar un RFP que no menciona cuántos envíos procesan al mes.

Sin esa información, los proveedores hacen suposiciones. Y cuando hacen suposiciones, las propuestas llegan genéricas, los precios no son definitivos y no hay nada sólido que comparar.

Por ejemplo, un fabricante global con 10 almacenes y SAP necesita una propuesta completamente distinta a la de un distribuidor con una sola sede que gestiona su logística en hojas de cálculo. Si un proveedor no puede distinguir cuál de los dos eres, se cubre las espaldas, y acabas con propuestas que no se comprometen a nada.

La solución requiere una tarde. Responde a estas diez preguntas en el RFP antes de enviarlo.

1. Organización y alcance. ¿Cuántas entidades jurídicas y sedes están incluidas en el alcance? ¿El despliegue es simultáneo o por fases? ¿Con qué independencia operan las sedes: contratos de transportistas separados, equipos separados?
2. Volúmenes de envíos. Número de envíos mensuales y diarios por sede, tanto en promedio como en picos. Cualquier estacionalidad. Desglose entre envíos entrantes y salientes.
3. Desglose por modo de transporte. ¿Qué proporción corresponde a paquetería, LTL, FTL, aéreo, marítimo? ¿Qué modos están creciendo? ¿Cuáles son los más críticos operativamente?
4. Red de transportistas. ¿Cuántos transportistas hay por sede y por modo? ¿Se comparten entre sedes o se gestionan localmente? ¿Hay transportistas estratégicos que deban priorizarse, o transportistas designados por el cliente que no puedes cambiar?
5. Geografía y rutas comerciales. ¿Qué regiones están en el alcance? ¿Qué rutas son más importantes: nacionales, transfronterizas, intercontinentales? ¿Puertos o centros logísticos clave?
6. Situación actual. ¿Cómo se planifican, gestionan y rastrean los envíos hoy? ¿En el ERP, hojas de cálculo, portales de transportistas, correo electrónico? ¿Cuáles son los principales puntos de dolor del proceso actual?
7. Configuración financiera. ¿Quién paga el transporte: una entidad o varias? ¿Hay números de cuenta de terceros o de clientes? ¿Cómo se registra y valida hoy el coste del flete?
8. Modelo de negocio. ¿B2B, B2C? Si es mixto, ¿en qué proporción? Los requisitos operativos y de sistema difieren de forma bastante significativa.
9. Panorama de integraciones. ¿Qué sistemas deben conectarse al TMS: ERP, WMS, CRM? ¿Hay integraciones de transportistas existentes que mantener? ¿Qué nivel de automatización se necesita desde el primer día?
10. Calendario y restricciones. ¿Hay una fecha objetivo de puesta en marcha? ¿Algún hito interno —cierre de ejercicio fiscal, temporada alta, migraciones de sistemas— que afecte al calendario?

Nada de esto es difícil de escribir. Pero cambia por completo lo que recibes a cambio.

Descarga la lista de verificación de información operativa para convertir estas diez preguntas en una tabla que puedes insertar directamente en tu RFP:

Descargar la lista de verificación de información operativa (.docx)

Cómo redactar los requisitos funcionales del TMS

Los requisitos funcionales son el núcleo del RFP. Si los defines bien, obtienes una imagen clara y comparable de lo que cada proveedor puede y no puede hacer. Si los defines mal, puedes pasar semanas descifrando respuestas que todas dicen "sí".

El objetivo no es la lista más larga, sino la más honesta.

Prioriza sin contemplaciones: imprescindible, recomendable, deseable

No todo lo que quieres tiene la misma importancia. Usa tres categorías y cíñete a ellas:

1. Imprescindible (I): no negociable. Un proveedor que no puede cumplirlo queda descartado, independientemente de lo demás que ofrezca.
2. Recomendable (R): importante, pero puedes aceptar una solución alternativa o una promesa de hoja de ruta a corto plazo.
3. Deseable (D): bueno tenerlo, pero queda por detrás de todo lo anterior.

La mayoría de las listas tienen demasiados requisitos imprescindibles. Si todo es crítico, nada lo es. Sé honesto sobre qué impediría realmente que el sistema funcionara para ti, y marca solo esos como imprescindibles.

Pide a los proveedores que clasifiquen la cobertura funcional: nativa / de terceros / mediante personalización

Para cada requisito, pídeles que respondan con una de estas opciones:

Esta columna es donde las propuestas ganan o pierden tu confianza. Un proveedor que responde con honestidad y escribe no disponible cuando es verdad te muestra cómo se comportará como socio. Un proveedor que responde nativo a todo también te está diciendo algo importante.

Sé específico en la pregunta

"¿El sistema admite precios de transportistas?" te dará un inútil "sí". "¿Puede el sistema calcular el precio del flete para cada transportista, incluidos los que no tienen API de precios, y mostrarlos en paralelo por envío?" te da algo que puedes evaluar de verdad.

¿Dónde termina el ERP y dónde empieza el TMS?

Una de las fuentes de confusión más habituales en las evaluaciones de software de gestión de transporte es dónde termina el TMS y dónde empieza el ERP.

Los procesos financieros como la codificación contable, el coste de aterrizaje y la auditoría de fletes suelen gestionarse en el lado del ERP, con el TMS alimentando los datos al ERP. Eso es normal y a menudo la configuración correcta. Pero hay que dejarlo claro. Cuando un proveedor responde "gestionado mediante integración con ERP" en uno de tus requisitos imprescindibles, profundiza en qué significa exactamente eso para tu implantación, y quién lo desarrolla.

Especifica el objetivo, no la solución técnica

Describe lo que necesitas conseguir, no cómo debe lograrlo técnicamente el sistema. Los requisitos excesivamente prescriptivos descartan buenas soluciones por razones equivocadas. Deja a los proveedores margen para mostrarte una forma mejor que la que tenías en mente, porque a veces la tienen.

Una lista honesta y priorizada de 30 requisitos te dirá más que una hoja de cálculo de 150 líneas donde todo es crítico y todos los proveedores han marcado todas las casillas.

Un conjunto inicial de requisitos de TMS para adaptar

La mayoría de los compradores que se enfrentan a esto por primera vez quieren un punto de partida para la lista, así que aquí tienes un ejemplo basado en nuestra experiencia, ya categorizado, que puedes adaptar a tu operación. La lista completa está disponible para descargar en la hoja de puntuación que encontrarás más abajo; esto es suficiente para hacerse una idea de su estructura.

Descarga la hoja de puntuación de requisitos funcionales, ya elaborada con prioridades y una columna de cobertura por proveedor:

Descargar la hoja de puntuación de requisitos funcionales (.docx)

Cómo comparar el coste de un TMS (y elaborar un modelo a tres años)

"¿Cuánto cuesta un TMS?" es la pregunta que los compradores más quieren que se responda y que los proveedores más evitan. Pero la cuota de suscripción rara vez es tu coste final. Para una empresa mediana con varias sedes, la implantación y la integración pueden superar al importe de la cuota mensual en el total a tres años, y esa es precisamente la partida sobre la que los proveedores son más vagos. La habilidad está en estructurar la pregunta de modo que las respuestas sean comparables y el coste real quede a la vista.

Como orientación aproximada, un TMS en la nube para el mercado medio suele oscilar entre unos pocos cientos y varios miles de euros al mes, mientras que los sistemas enterprise tradicionales van desde decenas de miles hasta más de un millón al año, con implantaciones que pueden alcanzar seis o siete cifras. Es un rango muy amplio, y por eso un modelo comparativo real importa más que cualquier cifra aislada. Para hacerte una idea de lo que cobran los proveedores reales, consulta nuestra investigación sobre los principales proveedores de TMS.

Componentes del precio de un TMS

Casi todos los presupuestos de TMS son alguna combinación de estos elementos:

Elabora un modelo de costes a tres años antes de comparar

Un proveedor de TMS que parece barato en la suscripción puede resultar el más caro una vez que se suman la implantación, las tarifas por transacción y la incorporación de transportistas. Pasa a todos los proveedores por el mismo modelo:

Coste a 3 años = implantación + (suscripción anual × 3) + (tarifa por envío × volumen anual × 3) + soporte + complementos de transportistas e integraciones previstos.

Usa tus volúmenes reales, no el ejemplo ordenado de un proveedor. Esa tabla suele reordenar la lista de preseleccionados.

Vigila los distintos componentes del precio, no solo la tarifa base

Algunos proveedores fijan precios bajos en la suscripción y los recuperan con tarifas por transacción o por transportista. Eso no es necesariamente malo, pero cambia quién es el más barato a medida que creces. Si tu volumen está aumentando, un modelo por envío puede superar rápidamente a uno de tarifa plana. Pide una factura de muestra y las condiciones de suscripción para comparar lo que realmente pagarás, no una tarifa de titular.

Una pregunta que vale la pena hacerle a cada proveedor: ¿las nuevas integraciones de transportistas están incluidas o se facturan cada vez? Algunas plataformas de TMS cobran entre 5.000 y 10.000 € por cada nueva integración de transportista y tardan meses, mientras que otras desarrollan nuevas integraciones sin coste adicional. Para una empresa mediana que va incorporando transportistas con el tiempo, esa única respuesta puede mover el total a tres años más que toda la línea de suscripción.

Cómo evaluar las propuestas de TMS más allá del precio

Las propuestas ya están sobre la mesa. Todas parecen razonables, la mayoría dice que sí a tus requisitos y los precios están en un rango similar. ¿Y ahora qué?

En este punto, los equipos suelen caer silenciosamente en el precio, porque todo lo demás parece más difícil de comparar. No lo hagas. Esto es lo que realmente las diferencia.

1. Conectividad con transportistas.

Para un TMS, la conectividad con transportistas es la base. ¿Cómo se conecta realmente el proveedor a los transportistas: mediante integraciones directas por API/EDI, a través de agregadores de terceros, o simplemente no (pedidos por correo electrónico y PDF independientemente de sus capacidades tecnológicas)? ¿Qué ocurre cuando necesitas un transportista que aún no tienen, cuánto tiempo lleva y cuánto cuesta?

Un proveedor con conectividad directa y profunda con los transportistas es algo muy distinto de uno que enruta todo a través de una capa intermedia. La diferencia se nota en la fiabilidad de los pedidos, en la calidad del seguimiento y en si puedes añadir un transportista sin abrir una nueva negociación comercial cada vez.

2. Armonización del nivel de servicio de los transportistas: esto importa más de lo que la mayoría de la gente cree.

Los transportistas no son iguales en sus capacidades digitales. Algunos tienen APIs sofisticadas que cubren precios en tiempo real, predicción de ETA, validación de direcciones, generación de etiquetas y eventos de seguimiento detallados. Otros te envían una confirmación de pedido por correo electrónico y ahí termina la conversación. La mayoría de las redes de transportistas tienen ambos tipos a la vez.

Eso se convierte en tu problema en el momento en que conectas tu ERP o WMS al TMS. Si tu integración espera recibir un conjunto completo de datos de cada transportista —confirmación de pedido, enlace de seguimiento, etiqueta, estimación de coste— pero algunos transportistas no pueden proporcionarlo, obtienes excepciones, procesos manuales y lagunas en tus datos. Un transportista débil rompe la coherencia de todo el flujo de trabajo.

Hay dos formas en que los distintos proveedores de software de gestión de transporte abordan esto, y vale la pena decidir cuál prefieres antes de leer una sola propuesta:

• Un TMS más ligero transmite lo que cada transportista proporciona, y será tu problema gestionar las lagunas en tu ERP o mediante trabajo manual. Integración más sencilla, pero más excepciones que gestionar por tu parte.
• Un TMS que normaliza los datos y cubre las lagunas por sí mismo: calcula el coste del flete a partir de tu tarifa de flete cargada cuando no hay API de precios; estima el plazo de entrega cuando no hay ETA proporcionado por el transportista; genera etiquetas de envío cuando el transportista no puede producirlas; cuando no tienen seguimiento, permite a tus transportistas introducir manualmente los hitos de seguimiento, y más. El software cubre las lagunas en las capacidades técnicas de tus transportistas, y tu ERP ve una estructura coherente.

Al evaluar las propuestas, pregunta directamente a los proveedores: ¿cómo gestionáis a los transportistas con capacidades digitales limitadas? La respuesta te dice mucho sobre la madurez real de su plataforma.

3. Honestidad sobre la integración.

Presta mucha atención a cómo describen los proveedores el alcance de la integración (quién hace qué). Una propuesta que dice claramente "el desarrollo del lado del ERP es responsabilidad vuestra; esto es lo que nosotros proporcionamos y cómo lo apoyamos" es más fiable que una que insinúa una "integración perfecta" sin explicar qué parte gestiona cada uno. Las sorpresas en la integración son una de las razones más comunes por las que los proyectos de TMS se disparan en tiempo y presupuesto.

4. Enfoque de implantación.

Un enfoque por fases —primero la validación operativa manual y después la automatización— suele entrañar menos riesgo que un lanzamiento de todo a la vez. Así puedes confirmar que el sistema funciona para tus flujos de trabajo reales antes de apoyar toda tu operación en él. Desde nuestra experiencia, los proveedores que proponen esto sin que se lo pidas suelen haber pasado ya por una puesta en marcha complicada. Los que presentan automatización total desde el primer día, a menudo no.

5. Referencias

Pide referencias de empresas con operaciones similares, no solo de tamaño o plantilla similar. Una referencia de un distribuidor con una sola sede no es especialmente útil si gestionas una operación de fabricación multisede con integración SAP. Y haz las preguntas concretas: "¿Cómo fue la incorporación de los transportistas?" "¿Cómo fue el proceso de integración?" "¿Qué ocurrió cuando algo no funcionó como se esperaba?"

6. La propuesta en sí.

La forma en que un proveedor de TMS responde a tu RFP es un anticipo de cómo se comportará como socio. ¿Respondieron a tus preguntas directamente, o lo envolvieron todo en matices? ¿Señalaron las lagunas con honestidad, o afirmaron cobertura total en cada requisito? ¿Demostraron que entendían tu operación, o te enviaron una versión ligeramente modificada de su presentación estándar?

Una propuesta que admite no disponible en dos puntos y explica por qué vale más que una que dice sí a todo. La verdad la descubrirás de todas formas. Mejor durante la evaluación que en el momento de la puesta en marcha.

Descarga la matriz de evaluación de proveedores para puntuar a los proveedores según criterios ponderados:

Descargar la matriz de evaluación de proveedores (.docx)

La ronda de presentaciones de proveedores de TMS

Las propuestas escritas te dicen lo que un proveedor afirma. Las presentaciones te dicen si puede respaldarlo.

En esta fase deberías tener una lista corta de 2 o 3 proveedores. El objetivo de la ronda de presentaciones es someter la propuesta a una presión real y comprobar si el sistema funciona ante tus escenarios concretos.

Pide una demostración en vivo, no una presentación ensayada

Una presentación ensayada es una secuencia preparada que muestra el sistema en su mejor momento. Una demostración en vivo es tú diciendo "muéstrame cómo gestionarías este envío, desde nuestro almacén en los Países Bajos, con nuestro transportista, a nuestra tarifa acordada", y observar lo que ocurre realmente.

Prepara 2 o 3 escenarios reales de tu propia operación antes de la reunión: un pedido de salida estándar, un envío que necesita un presupuesto spot y algo complicado, como un envío retrasado o un transportista que no proporciona seguimiento. Cuando un proveedor sigue intentando volver a la presentación pulida en lugar de ejecutar tu escenario, eso ya es tu respuesta.

Cuestiona las lagunas

Todas las propuestas de TMS las tienen. Ve directamente a los puntos donde un proveedor respondió de forma parcial o donde tienes dudas, y quédate ahí. No les dejes volver a algo que funciona a la perfección. ¿Cómo funciona esto exactamente? ¿Quién hace qué? ¿Qué ocurre cuando no funciona como se esperaba?

Reúne a las personas adecuadas

Por parte del proveedor de TMS, las personas que presenten deben ser las que realmente trabajarán en tu implantación, no solo el equipo de ventas. Pídelo explícitamente. Por tu parte, incluye a alguien de TI (si la integración está en el alcance) y al menos a una persona que vaya a usar el sistema a diario. Hacen preguntas distintas a las de compras, y necesitas ambos tipos de preguntas.

Segunda ronda, solo si es necesario

Para una decisión compleja, una segunda sesión centrada en temas específicos vale la pena. Ejemplos de temas a tratar:

• Seguridad y protección de datos: solicita un informe de pruebas de penetración o documentación de seguridad si tu equipo de TI o de seguridad de la información lo requiere
• Arquitectura de integración: una sesión técnica entre tu equipo de TI y el del proveedor
• Condiciones comerciales: revisa el contrato, el SOW y los supuestos línea por línea antes de entrar en negociaciones formales

No la programes solo para repetir la primera reunión con más personas en la sala. O resuelve preguntas abiertas concretas, o no tiene sentido celebrarla.

Confirma los compromisos por escrito

Cualquier compromiso que un proveedor asuma en la reunión y que no figure en la propuesta escrita debe confirmarse por escrito antes de continuar. Los compromisos verbales no sobreviven a las negociaciones del contrato. Si un proveedor de TMS dice "sí, podemos hacer eso" sobre algo importante, envía un correo electrónico ese mismo día y pídele que lo confirme.

Contrato y SOW (declaración de trabajo) del TMS: qué revisar antes de firmar

Has elegido a tu proveedor. La mayoría de los equipos "respiran aliviados" en este punto. Yo te recomiendo que no lo hagas, porque aquí es donde los detalles que todos pasaron por alto durante la evaluación se convierten silenciosamente en tu problema.

Alinéate internamente antes de negociar

Ten claros tus requisitos irrenunciables, tus compromisos aceptables y tus líneas rojas antes de que empiece la conversación. Cambiar los requisitos a mitad de la negociación cuesta tiempo, erosiona la confianza y, en ocasiones, te hace perder al proveedor de TMS que realmente querías. Resuélvelo internamente primero y luego negocia.

Entiende qué estás comprando: SaaS, no una licencia

Las plataformas de TMS modernas son suscripciones SaaS, no licencias de software. Te suscribes a un servicio que el proveedor aloja, mantiene y actualiza, no compras un sistema en propiedad. Eso cambia lo que el contrato debe cubrir: condiciones de suscripción, rescisión, propiedad de los datos y derechos de exportación, compromisos de disponibilidad, tiempos de respuesta del soporte. Las plantillas de contratación estándar no fueron escritas para este modelo, así que asegúrate de que las tuyas estén actualizadas.

El SOW importa tanto como el contrato

La declaración de trabajo especifica qué se entrega, por quién y cuándo: configuración de la cuenta, incorporación de transportistas, soporte a la integración, formación y los criterios de aceptación que indican que la implantación está realmente completada. Si no está en el SOW, no está incluido, independientemente de lo que se haya dicho en una reunión o en un correo electrónico. Lee la sección de supuestos con especial atención. Ahí es donde el alcance se define de forma condicional. Si tu lista de transportistas resulta ser mayor de lo indicado, o tu ERP necesita un formato de integración no estándar, la sección de supuestos decide si eso es una conversación rápida o una solicitud de cambio con precio.

Sé explícito sobre lo que queda fuera del alcance

Desarrollo a medida, formación presencial, migración de datos, trabajo de integración en tus sistemas, cambios en el lado del transportista. Estos conceptos suelen tener precio aparte. Dejarlo por escrito antes de firmar elimina la fuente más común —y más evitable— de fricciones durante la implantación: dos partes que asumieron cosas distintas sobre lo que estaba incluido.

Acuerda el plan de incorporación antes de firmar

No después. La priorización de transportistas, el calendario de configuración, los hitos de integración, los criterios de puesta en marcha: cierra todo esto mientras aún tienes capacidad de negociación. Un proveedor que no puede darte un plan de incorporación claro en la fase de contrato te está diciendo algo que querrás saber antes de comprometerte.

Después de firmar: implantación e incorporación del TMS

La mayor parte del riesgo real llega después de la firma. Tres factores determinan cómo va.

1. Migración de datos

Contratos de transportistas, tarifas, libretas de direcciones, historial de envíos. Decide pronto qué necesitas migrar, qué hay que limpiar primero y quién es responsable del trabajo. Los datos de origen desordenados son la razón más habitual por la que la fecha de puesta en marcha se va aplazando. Limpia los datos antes de migrarlos, no mientras los migras.

2. Secuencia de incorporación de transportistas

No conectas todos los transportistas el primer día. Prioriza por volumen y criticidad, pon en marcha y valida los más importantes, y luego amplía desde ahí. Aquí es exactamente donde el enfoque por fases que preguntaste durante la evaluación demuestra su valor.

3. Adopción por parte de los usuarios

Las personas que gestionan envíos cada día tienen que querer usar el nuevo sistema. Involucra a al menos una de ellas desde la fase de RFP en adelante, fórmala adecuadamente durante el período de hipercare (incorporación) y asegúrate de que el flujo de trabajo diario sea genuinamente más rápido que lo que hacían antes. Un despliegue técnicamente impecable que el equipo simplemente no usa sigue siendo un despliegue fallido.

10 errores comunes en los RFP para TMS

Los patrones que vemos con más frecuencia, todos en un mismo lugar:

• Sin contexto operativo. El más grave. No se proporcionan a los proveedores volúmenes, estructura de sedes ni red de transportistas. Una ronda de aclaraciones y precios no definitivos están garantizados.
• Todo es imprescindible. Cuando cada requisito es crítico, la columna de prioridades no sirve de nada y no puedes distinguir un elemento decisivo de uno deseable.
• Calendario vago. Sin fechas, los proveedores no pueden estimar su esfuerzo, y las propuestas llegan igual de vagas.
• Especificar en exceso el cómo. Prescribir la implementación técnica en lugar del resultado operativo descarta buenas soluciones por razones equivocadas.
• Ignorar el límite entre ERP y TMS. Asumir que el TMS gestiona procesos financieros que en realidad corresponden al ERP, y darse cuenta a mitad de la implantación.
• Decidir solo por precio. Elegir en función de la cuota de suscripción sin un modelo a tres años, o sin valorar la conectividad con transportistas y la honestidad sobre la integración.
• Una presentación ensayada en lugar de una demostración en vivo. Ver la secuencia pulida del proveedor en lugar de hacer que el sistema pruebe tus escenarios reales.
• Referencias que no se parecen a tu operación. Fijarse en los logotipos impresionantes, cuando esas empresas pueden tener operaciones logísticas que no se parecen en nada a la tuya. Pide referencias similares a ti y pregúntales cómo fueron realmente la incorporación y la integración.
• Dejar la incorporación para después de la firma. El plan que negocias con capacidad de negociación es mejor que el que negocias sin ella.
• Un proceso demasiado pesado para el proveedor adecuado. La carga burocrática puede filtrar precisamente las plataformas modernas que mejor te habrían servido.

Plantillas gratuitas de RFP para TMS

Hemos elaborado cinco plantillas a partir de los RFP a los que respondemos, para que no tengas que empezar desde cero:

1. Plantilla del documento de RFP. La estructura completa de esta guía.
2. Hoja de puntuación de requisitos funcionales. Priorizada, con una columna de cobertura por proveedor.
3. Lista de verificación de información operativa. Las diez preguntas en formato de tabla.
4. Matriz de evaluación de proveedores. Puntuación ponderada entre proveedores.
5. Plantilla de calendario de RFP. Actividades, fechas y responsables.

Descarga el paquete completo: las cinco plantillas, gratuitas y sin necesidad de registrarte. Toma lo que te sea útil e ignora el resto:

Descargar el paquete completo de plantillas de RFP para TMS (.zip)

Cargoson es un software de gestión de transporte utilizado por fabricantes y distribuidores medianos en Europa y Norteamérica. Respondemos a RFP como el que estás a punto de redactar con frecuencia, así que si prefieres hablar sobre tus requisitos antes de empezar a escribir, estaremos encantados de ayudarte a pensar en ello, sin ningún compromiso.

Reserva aquí una consulta gratuita de 30 minutos

Lleva a cabo el proceso bien y habrá valido cada hora invertida.