TMS: qué es y cómo funciona un Transportation Management System

En resumen

TMS significa Transportation Management System. Sin embargo, no existe una lista universal de funciones que un software deba tener para poder llamarse TMS. En el mercado, el término se utiliza para productos muy distintos: desde herramientas relativamente sencillas para planificar viajes hasta plataformas empresariales que gestionan la contratación de transportistas, licitaciones, tarifas, redes internacionales, auditorías de costes, seguimiento, documentación e integraciones con ERP y sistemas de almacén.

Para una pyme, la cuestión no es «¿necesito un TMS?», sino qué procesos necesito controlar y con qué grado de complejidad. Una empresa con cinco camiones que recibe pedidos por correo electrónico tiene necesidades muy distintas de las de un operador logístico que compra transporte a cientos de transportistas o coordina varios centros europeos.

Qué significa realmente TMS

En términos prácticos, un TMS es un sistema de información dedicado a la gestión del transporte. Puede respaldar una o varias fases:

solicitud → pedido → planificación → asignación → ejecución → seguimiento → documentos → costes → cierre → análisis

La profundidad varía mucho de un producto a otro. Un sistema puede limitarse a planificar transportes propios; otro puede elegir automáticamente entre distintos transportistas según la tarifa y el servicio; otro puede gestionar rutas multimodales, citas, SLA, facturas y conciliaciones.

Por eso, dos ofertas llamadas «TMS» pueden tener precios, plazos de implantación y destinatarios completamente distintos.

El ciclo operativo que puede gestionar un TMS

1. Captación de la demanda

Los pedidos pueden llegar mediante introducción manual, archivos, API, EDI, ERP, portales de clientes u otros sistemas. La primera tarea es convertir solicitudes heterogéneas en datos utilizables.

2. Planificación

El sistema combina destinos, franjas horarias, capacidad, restricciones, disponibilidad de vehículos y conductores o disponibilidad de los transportistas. Los sistemas más sofisticados pueden incluir motores de optimización; en los más sencillos, la planificación sigue siendo principalmente visual y manual.

3. Asignación

El viaje se asigna a un vehículo/conductor interno o a un transportista externo. Si se compran servicios de transporte, pueden entrar en juego tarifas, licitaciones, clasificaciones de proveedores y reglas de contratación.

4. Ejecución

La oficina, el conductor y los socios deben compartir estados y cambios: recogido, llegado, cargado, en ruta, entregado, incidencia, etc.

5. Documentos y prueba del servicio

El sistema puede vincular el pedido, los documentos de transporte, el POD y los adjuntos. Sin embargo, la presencia de un documento en el TMS no significa que sea automáticamente correcto desde el punto de vista jurídico, fiscal o técnico.

6. Costes y control

Los TMS más avanzados comparan el coste previsto con el coste real, las tarifas, recargos, peajes, servicios adicionales y las facturas recibidas de los transportistas.

7. Análisis

Los volúmenes, la puntualidad, los costes por ruta, el uso de recursos, las incidencias, el rendimiento de los transportistas y otros KPI pueden convertirse en datos de gestión en lugar de reconstrucciones manuales al final de mes.

Los módulos más habituales

Un TMS puede incluir:

• gestión de pedidos;
• datos maestros de clientes, centros y transportistas;
• planificación de viajes;
• asignación de vehículos/conductores;
• contratación y licitaciones de transportistas;
• gestión de tarifas;
• seguimiento o integración con seguimiento externo;
• gestión de citas;
• documentos y POD;
• control de costes y auditoría de fletes;
• facturación o integración contable;
• paneles y KPI;
• portal de clientes/proveedores;
• API, EDI e integraciones con ERP/WMS;
• gestión de excepciones;
• funciones de optimización.

La pregunta correcta durante una demostración no es «¿tienen esta función?», sino cómo funciona en el proceso concreto de la empresa y qué datos requiere.

TMS, software de gestión del transporte, FMS y telemática no son sinónimos

Software de gestión del transporte

Es un término genérico. Puede indicar un software centrado en la organización administrativa y operativa de una pequeña empresa: clientes, pedidos, conductores, camiones, plan diario y estados.

TMS

Suele indicar una plataforma con mayor profundidad en la planificación y el control del transporte y, en contextos empresariales, en la gestión de redes, transportistas, tarifas e integraciones.

FMS / Fleet Management System

Está más orientado a la flota: vehículos, mantenimiento, consumos, vencimientos, uso y, en su caso, conductores y costes del vehículo.

Telemática

Recoge información procedente del vehículo o de dispositivos: posición, kilómetros, datos CAN cuando están disponibles, diagnóstico, eventos de conducción y otras señales. Un TMS puede recibir estos datos, pero no es, por definición, un dispositivo telemático.

ERP

Gestiona procesos empresariales más amplios: contabilidad, compras, ventas, administración, almacén y control de gestión. Un TMS puede ser un módulo del ERP o un sistema independiente integrado con él.

Para una pyme es normal utilizar varias herramientas. El problema surge cuando nadie sabe qué sistema es la fuente oficial de cada dato.

Cuándo resulta útil un TMS complejo

La complejidad tiende a estar justificada cuando aumentan algunas variables:

• cientos o miles de pedidos;
• muchos puntos de carga/descarga;
• transporte comprado a numerosos transportistas;
• tarifas y recargos complejos;
• red nacional/internacional;
• varios modos de transporte;
• SLA y KPI contractuales;
• fuerte necesidad de integración con ERP/WMS;
• procesos de licitación y contratación;
• necesidad de una auditoría sistemática de costes.

En estos casos, la plataforma no sirve solo para «ver el plan», sino que pasa a formar parte de la arquitectura de información de la empresa.

Cuándo puede estar sobredimensionado

Una microempresa con cinco o diez camiones puede tener un problema muy concreto: pedidos dispersos, cambios por WhatsApp, planificación en Excel y llamadas continuas a los conductores. Para resolverlo no es necesariamente útil introducir:

• un proyecto ERP de seis meses;
• configuraciones tarifarias complejas;
• un motor de licitaciones;
• un almacén de datos;
• decenas de roles y flujos de trabajo;
• consultoría especializada para cada cambio.

Un software demasiado grande puede desplazar el problema: de la falta de estructura a la dificultad de utilizar esa estructura.

El criterio debería ser la complejidad mínima suficiente: cubrir bien el proceso real de hoy y dejar espacio para crecer, sin comprar años de funciones que no se utilizarán.

Datos e integraciones: la parte que realmente cuesta

El software es solo un componente. Una parte importante del trabajo de un proyecto TMS se refiere a los datos.

Antes de la implantación conviene establecer:

Datos maestros. ¿Quién depura clientes, direcciones, vehículos, conductores, transportistas y códigos duplicados?

Fuente del dato. ¿La dirección del cliente nace en el CRM, el ERP o el TMS? ¿Quién puede modificarla?

Identificadores. ¿El pedido, el viaje y el documento tienen códigos coherentes entre sistemas?

Importaciones. ¿Los archivos existentes tienen columnas estables o cada cliente utiliza un formato distinto?

API/EDI. ¿Qué flujos son realmente necesarios? ¿En tiempo real o por lotes?

Errores. ¿Qué ocurre si una integración no recibe un pedido o lo recibe dos veces?

Histórico. ¿Cuánto pasado hay que migrar? ¿Todo, solo los datos maestros o los últimos meses?

Propiedad. ¿La empresa puede exportar sus propios datos en un formato reutilizable?

Una mala calidad de los datos no se resuelve automáticamente con un TMS: simplemente se transfiere a un sistema más caro.

Documentos digitales y eFTI: por qué la interoperabilidad importa cada vez más

El Reglamento (UE) 2020/1056, relativo a la información electrónica sobre el transporte de mercancías (eFTI), crea un marco europeo para permitir que los operadores económicos pongan determinada información reglamentaria a disposición de las autoridades competentes en formato electrónico a través de plataformas y servicios conformes con el marco eFTI.

La Comisión Europea indica el 9 de julio de 2027 como la fecha a partir de la cual el marco eFTI será plenamente aplicable y las autoridades de los Estados miembros deberán aceptar la información compartida electrónicamente por los operadores a través de plataformas eFTI certificadas. Desde 2026, las plataformas y los proveedores pueden prepararse para operar según la hoja de ruta prevista por la Comisión.

Esto no significa que a partir de 2027 cada pequeña empresa deba comprar un «TMS eFTI». Sin embargo, significa que, al elegir hoy un sistema destinado a durar años, tiene sentido preguntar al proveedor:

• cómo exporta los datos;
• si dispone de API;
• cómo gestiona los estándares y la interoperabilidad;
• qué planes tiene respecto a la evolución de eFTI;
• si las posibles funciones declaradas «eFTI compliant/certified» están realmente respaldadas por la certificación requerida, cuando sea aplicable.

La digitalización europea avanza hacia datos estructurados e intercambiables. Por ello, un archivo cerrado del que resulta difícil recuperar los propios datos es un riesgo mayor que antes.

Cómo evaluar un TMS sin dejarse guiar por la demostración

Una demostración muestra casi siempre el recorrido ideal. En cambio, la evaluación debería utilizar casos reales de la empresa.

Pida al proveedor que simule al menos:

1. un pedido normal;
2. una recogida con dos entregas;
3. un cambio después de la asignación;
4. un conductor no disponible en el último momento;
5. un pedido importado de Excel;
6. un documento que falta;
7. una entrega tardía;
8. un viaje cancelado;
9. un error de integración;
10. la exportación completa de un periodo de actividad.

Después mida:

• cuántos pasos son necesarios;
• cuánta información se vuelve a introducir;
• quién debe intervenir;
• qué ve el conductor;
• qué permanece en el histórico;
• cómo se recuperan los errores.

Lista de comprobación

• ¿Qué proceso queremos mejorar primero?
• ¿El producto está pensado para una flota propia, un cargador o un transitario?
• ¿Gestiona realmente nuestro tipo de pedido?
• ¿Requiere módulos que no utilizaremos?
• ¿El plan es comprensible para los operadores?
• ¿Los conductores y los vehículos están vinculados a los pedidos?
• ¿Existe un histórico de cambios?
• ¿Los datos se pueden exportar en formatos reutilizables?
• ¿Las API están incluidas o son de pago?
• ¿Qué integraciones son estándar y cuáles son proyectos?
• ¿Qué costes existen además de la licencia?
• ¿Cuánto tiempo requiere la implantación?
• ¿Cómo se gestionan las copias de seguridad, la seguridad y la continuidad?
• ¿Qué funciones están realmente disponibles hoy y cuáles están en la hoja de ruta?
• ¿Cómo se aborda la evolución de eFTI?