Software de operaciones de ferry: programación dinámica, yield y recuperación de incidencias

De todos los segmentos agrupados bajo el maritime comercial, las operaciones de ferry son las que más se alejan del manual. Un portacontenedores navega durante semanas; su ciclo comercial se mide en contratos trimestrales y coberturas FFA. Un petrolero pasa días en puertos de carga y descarga; el ritmo lo marcan las cláusulas de laytime. Un ferry de pasaje, en cambio, puede completar un ciclo comercial entero entre cuatro y doce veces al día, con rotaciones de treinta minutos, expectativas de pasajero de nivel retail, inventario perecedero en forma de asientos vacíos y metros de carril sin vender, y un riesgo meteorológico concentrado en ventanas estacionales estrechas. La física operativa es distinta, y el software que la sostiene debe serlo también.

Este artículo examina qué tiene que hacer realmente el software de operaciones de ferry — programación, yield, planificación regulatoria de carga y recuperación de incidencias — y por qué las plataformas genéricas, portadas desde contextos de contenedor o tanque, fallan al chocar con un día real de ferry.

La anatomía de un día de ferry

Un día representativo en una ruta costera o de short-sea puede empezar a las 04:30 con la firma del relevo de tripulación, la coordinación del bunker con la gabarra de puerto, la preparación de la cubierta de vehículos y la revisión final de los registros nocturnos de ruido y emisiones. A las 06:15 hay cola de pasajeros a pie; a las 06:45 la cubierta de vehículos carga según un plan de estiba que ya contempla pesos de semirremolques, segregación de mercancías peligrosas y prioridades comerciales del operador — viajeros frecuentes, transportistas a contrato, drive-up de última hora. La nave zarpa a las 07:00, vuelve a las 09:30 y debe partir de nuevo a las 10:00. Una rotación de treinta minutos, repetida de cinco a diez veces al día.

Dentro de esa ventana, el equipo operativo debe reconciliar:

• Desembarque y despeje de cubierta frente a disponibilidad del linkspan;
• Embarque de pasajeros a pie, pasajeros con accesibilidad y tráfico vehicular, a menudo por puertas distintas;
• Rotaciones de tripulación reguladas por las horas de descanso del MLC 2006;
• Bunker y recepción de residuos según MARPOL Anexo I, IV, V y VI;
• Reconciliación de slots de puerto, ya que la mayoría de terminales short-sea asigna ventanas que no pueden deslizarse sin efectos en cascada;
• Comunicación de pasajeros en tiempo real: cambios de puerta, retrasos, conexiones perdidas con tren o autobús;
• Briefings de seguridad, cierre del manifiesto y comprobaciones finales de estabilidad SOLAS antes del despacho.

Ninguna de estas actividades es exótica por sí sola. El reto es que están todas entrelazadas, todas en el reloj de los treinta minutos, y todas suceden en cada puerto de cada rotación, todos los días.

Capacidad y yield: dos inventarios sobre un mismo casco

Un ferry de pasaje vende dos productos fundamentalmente distintos en el mismo viaje. La cubierta de pasaje es un producto retail: butacas, camarotes, salas, a veces restaurantes y tiendas. La cubierta de vehículos es un producto logístico: metros de carril para coches, motos, furgonetas, autocares y, cada vez más relevantes, semirremolques de carga. Ambos tienen ingresos por metro cúbico distintos, elasticidades de precio distintas, curvas de reserva distintas y comportamientos de cancelación distintos. Las reservas de vehículo se firman antes y rara vez son no-show; las de pasaje, sobre todo de ocio, pueden moverse mucho en las últimas 72 horas.

El yield management construido para aerolíneas u hoteles trata el inventario como un pool homogéneo. El yield de ferry no puede. Un motor moderno modela los inventarios de pasaje y vehículos por separado y luego conjuntamente, porque interactúan: una carga pesada de mercancía reduce los metros de carril disponibles para coches, lo que limita el precio del próximo coche, que vuelve a la superficie de oferta mostrada al ocio. Algunos operadores añaden el inventario de camarotes como tercer eje en travesías nocturnas — y los camarotes, a diferencia de las butacas, se comportan más como habitaciones de hotel que como asientos aéreos, con un floor same-day muy firme.

Operadores citados como contexto de industria — DFDS, Stena Line, Brittany Ferries, Grimaldi, GNV, Moby, Trasmediterránea, Baleària — han pasado años calibrando la lógica yield para sus mezclas de ruta. El patrón común es un modelo en capas: una price ladder estratégica por ruta y temporada, una capa táctica que reacciona al ritmo de reservas y un floor en tiempo real que evita la canibalización del freight contratado.

Programación dinámica y recuperación del calendario

El horario publicado es, en la práctica, una aspiración. Un COO sabe que cualquier día una fracción de salidas será tocada por algo: una previsión de fuerza ocho, una alarma del servomotor, un cierre de puerto por una escala de crucero, un desembarque médico. La pregunta no es si la incidencia ocurrirá; es con qué velocidad la operación se reestabiliza.

El software de programación dinámica debe cubrir tres horizontes distintos:

1. Diseño estratégico, donde los horarios anuales o de temporada se construyen contra previsiones de demanda, slots de puerto, turnos de tripulación y ventanas de mantenimiento;
2. Re-planificación táctica, en las 24-72 horas previas a la salida, cuando datos de viento, defectos mecánicos o reservas comerciales pueden justificar cancelar, fusionar o mejorar salidas;
3. Recuperación en tiempo real, cuando una salida ya se ha caído y el operador debe reproteger pasajeros, redirigir mercancías, reposicionar tripulaciones y recuperar el horario el mismo día o el siguiente.

Lo más difícil es la recuperación en tiempo real. Exige que la plataforma mantenga una foto viva del estado de toda la flota — bunker, lastre, horas de tripulación, autorizaciones de puerto, manifiestos de pasajeros y vehículos — y genere planes factibles en minutos, no en horas. El software portado del shipping de contenedores, donde una nave retrasada simplemente se rebufera contra la siguiente ventana de puerto, no tiene un concepto nativo de esto; allí la recuperación se mide en días, no en minutos.

Optimización del load factor sin romper la estabilidad

Todo operador comercial quiere llenar el deadweight residual. En un ferry, el límite que cede en último lugar no es comercial: es regulatorio. La SOLAS Capítulo II-1 regula la estabilidad en avería de los buques de pasaje, y su marco probabilístico post-2009 — junto con el Stockholm Agreement para ferries RoRo de pasaje del Noroeste de Europa — impone límites duros sobre cómo se pueden cargar las cubiertas de vehículos respecto a los compartimentos de pasaje y la subdivisión estanca. Un trimado comercialmente atractivo puede ser operativamente ilegal.

Un buen software de planificación de carga para ferries no se limita a optimizar la estiba por centro de gravedad y trimado. Codifica la documentación real de estabilidad en avería del buque, trata el loading computer como fuente de verdad y se niega a publicar planes de estiba que rompan el envolvente aprobado. Encima añade lógica comercial: segregación de mercancías peligrosas según IMDG, carga de riesgo en cubiertas weather, ganado en cubiertas ventiladas, planificación de tomas de refrigerados y asignación de carriles que minimice los movimientos de shunting al desembarque.

Para ferries propulsados con GNL, el IGF Code añade otra capa: comprobaciones de compatibilidad de bunker, zonas de detección de gas alrededor del manifold y límites operativos sobre el bunker simultáneo al embarque de pasaje. Nada de esto está en el software pensado para estibar boxes en un portacontenedores de 12.000 TEU.

MARPOL, EEXI y CII: presiones específicas del ferry

Los ferries están expuestos ambientalmente de forma distinta a las flotas de larga distancia. Su intensidad puerto-a-puerto hace que una cuota alta del consumo total de combustible ocurra en maniobra, atraque y transición a cold ironing. La frecuencia de sus escalas produce una exposición desproporcionada a la regulación local de calidad del aire en ciudades portuarias — Génova, Barcelona, Marsella, Dover, Helsinki — donde la presión municipal sobre emisiones es más dura que la regulación de mar abierto.

El EEXI se aplica una vez. El CII se aplica anualmente, y las bandas de rating son duras para operadores short-sea cuyo denominador en distancia es pequeño. Los operadores responden con cold ironing, hibridación a baterías, slow steaming en piernas flexibles y mejoras de eficiencia operativa que dependen de datos de viaje detallados: estado de mar, deriva, precisión de ETA, tiempos de espera. El software debe capturarlos por pierna, atribuirlos correctamente y alimentar tanto el reporting regulatorio (EU MRV, IMO DCS) como la lógica comercial — porque un downgrade de banda CII puede cambiar el caso comercial de toda una ruta.

Recuperación de incidencias y comunicación al pasaje

El pasajero ferry de 2026 espera lo que recibe del tren y del corto radio aéreo: información de incidencia en tiempo real, reprotecciones automáticas, reembolsos sin llamadas y re-acomodo con sensibilidad a la accesibilidad. Los estándares ATOC en el Reino Unido y el Reglamento UE 1177/2010 de derechos de pasajeros marítimos fijan el suelo legal; la reputación comercial fija uno más alto.

El problema es que la incidencia ferry rara vez es limpia. Un tren cancelado simplemente no sale; una salida ferry cancelada deja semirremolques en muelle, pasajeros a pie sin enlaces y vehículos cuyos conductores ya pagaron hotel en destino. La recuperación exige que la plataforma:

• Reproteja pasajeros entre las salidas afectadas, respetando asignación de camarotes y necesidades de accesibilidad;
• Reposicione vehículos y semirremolques de carga, con manejo explícito de mercancías peligrosas y unidades refrigeradas;
• Coordine con autoridades portuarias, operadores de linkspan y proveedores de transporte onward;
• Genere automáticamente los expedientes de compensación del Reg. 1177, no como tarea manual de back office tres semanas después;
• Comunique proactivamente, en el idioma y canal que prefiera el pasajero, con contenido sustantivo — no plantillas genéricas de disculpa.

Bien hecho, esto convierte un evento de fuerza mayor en una historia comercial defendible. Mal hecho, produce los incidentes en redes sociales que los operadores hoy temen más que al regulador.

Lo que el buen software de ferry hace y el adaptado de contenedores no

El patrón ya es visible. El software nacido para flotas de contenedor o tanque, vendido luego a operadores de ferry con un módulo de pasaje añadido, falla en cinco frentes recurrentes:

• Horizonte temporal: asume ciclos comerciales en días o semanas, no en rotaciones de treinta minutos;
• Modelo de inventario: trata la capacidad como homogénea, no como superficie yield conjunta de pasaje, vehículos y camarotes;
• Estabilidad y seguridad: no tiene modelo nativo de estabilidad en avería SOLAS, zonas de gas IGF o asignación de carriles RoRo bajo segregación IMDG;
• Incidencias: carece de las primitivas de recuperación de schedule en tiempo real que un COO necesita a las 06:00 de una mañana de fuerza ocho;
• Experiencia de pasaje: no tiene concepto nativo de accesibilidad, compensaciones del Reg. 1177 ni comunicación multilingüe.

El software de ferry purpose-built parte del supuesto opuesto: que el día de ferry es la unidad atómica, que pasajero y semirremolque comparten casco pero no lógica comercial, y que la recuperación de incidencias no es un camino de excepción sino una capacidad central.

De herramientas a sistema operativo

Los operadores ferry más sólidos que observamos en Europa y el Mediterráneo están dejando atrás la era de herramientas separadas de scheduling, yield e incidencias unidas por hojas de cálculo y calendarios compartidos. Están consolidando sobre un único sistema operativo de registro desde el que trabajan COO, route managers, port operations managers, revenue y customer service. El beneficio no es un dashboard único. Es que los mismos datos — manifest, estiba, horas de tripulación, bunker, meteo, slots — gobiernan cada decisión, de modo que un re-routing táctico de las 11:00 y un ajuste yield de las 14:00 no se contradigan a las 17:00.

Llegar a ese punto es un programa de varios años, no una compra de software. Pero el retorno se mide: load factors más altos a igual riesgo yield, recuperación más rápida, menor exposición regulatoria y una experiencia de pasaje que aguanta bajo presión.

El módulo Ferry de SupaMaritime está construido específicamente para este segmento — operadores de pasaje y RoRo en rutas costeras, short-sea y mediterráneas — y se integra con los módulos SupaMaritime más amplios para agencia y flotas merchant. Los puntos de acceso localizados también están disponibles en /ferry, /it/ferry, /fr/ferry y /de/ferry. Para operadores que evalúan por dónde empezar, el primer paso práctico rara vez es un reemplazo total de plataforma; es una revisión enfocada de los puntos donde el toolchain actual falla en un día real disrupted, y una roadmap que corrige primero los modos de fallo más caros.