Pregunte a un operador urbano cuántos sistemas hacen falta para explotar su red y la respuesta casi nunca es uno. Suelen ser cuatro o cinco: localización de vehículos, planificación de servicio y turnos, información al viajero, algo para el depósito o el taller, y con frecuencia un contrato aparte para el equipamiento embarcado.
Cada una de esas decisiones fue razonable cuando se tomó. El conjunto produce una estructura en la que el operador, y no el proveedor, absorbe el trabajo de integración cada vez que algo cambia.
Dónde está el coste real
Las licencias son la parte visible, y normalmente la menor. El coste está en otros cuatro sitios.
Mantenimiento de integraciones. Cada par de sistemas que intercambia datos es una interfaz que alguien mantiene. Cinco sistemas pueden significar seis o siete interfaces activas, y cada una se rompe por su cuenta, habitualmente después de una actualización del lado del proveedor de la que nadie avisó.
Reconciliación de versiones. Cuando la planificación, la localización y la información al viajero mantienen cada una su propia versión de una expedición, alguien tiene que decidir cuál es la correcta. Ese trabajo no aparece en ningún presupuesto y aparece todos los días en el puesto de control.
Doble captura de datos. El caso más caro es la incidencia. Una desviación se registra en el sistema de explotación, se comunica al viajero en otro y se justifica ante la administración en un tercero. Tres entradas para un mismo hecho. El día que la red va mal, dos de las tres no se hacen.
Responsabilidad diluida. Durante una incidencia, un conjunto fragmentado produce una conversación entre proveedores en lugar de una solución. El proveedor de localización señala al flujo de datos, el del flujo señala al de pantallas, y el operador es la única parte con una obligación real frente a la autoridad.
El síntoma que revela el problema
Hay una prueba rápida. Coja una desviación de itinerario del mes pasado y cuente cuántas personas y cuántas pantallas fueron necesarias para que quedara registrada, comunicada al viajero y documentada para el reporte.
Si la respuesta es más de una persona o más de una pantalla, el coste de la fragmentación ya se está pagando. Simplemente está contabilizado como tiempo de personal en lugar de como coste de software.
Qué cambia con un modelo de datos único
Unificar no es tener un único proveedor con varias facturas agrupadas. Es que la expedición que planificó el planificador sea el mismo objeto al que se asigna el vehículo, el mismo que el regulador ve desviarse, y el mismo que alimenta el flujo en tiempo real hacia el viajero. Sin paso de traducción, no hay lugar donde las versiones puedan separarse.
Eso produce cuatro efectos concretos.
Un solo punto de entrada por incidencia. El regulador introduce la desviación una vez. Pantallas, aplicación, avisos y flujos públicos se actualizan desde el mismo evento. Es la diferencia entre una comunicación que funciona el día difícil y una que solo funciona el día normal.
Adherencia horaria sin cálculo intermedio. Si el sistema conoce el plan y la posición, el adelanto o el retraso es un dato, no un informe.
Un histórico consistente. Una sola fuente para responder qué pasó, cuándo y con qué consecuencia. La justificación ante la administración deja de ser un proyecto trimestral.
Una única formación. Reguladores, planificadores y responsables de depósito aprenden una interfaz. En un contexto de dificultad para cubrir puestos, el coste de formación de cinco herramientas no es un detalle.
Cuándo unificar es la decisión equivocada
Tratar la unificación como dogma es la forma de terminar atrapado en una plataforma fuerte en un área y débil en tres.
Es la decisión equivocada cuando una capacidad especializada es realmente el núcleo del negocio y ninguna plataforma integrada la iguala. La optimización compleja de turnos multi-depósito bajo varios convenios colectivos es el ejemplo habitual. Si ahí está el margen, comprar una versión más débil dentro de una suite es un retroceso disfrazado de simplificación.
También lo es cuando la plataforma no permite recuperar los datos propios en un formato abierto. Un sistema unificado del que no se pueden extraer los datos históricos no ha reducido el riesgo, lo ha concentrado.
Y lo es cuando la unificación es solo comercial. Algunos proveedores venden un contrato único sobre productos que adquirieron por separado y nunca fusionaron. Se obtiene una sola factura y los mismos problemas de integración, ahora detrás de un soporte que tampoco ve entre sus propios módulos.
Preguntas para separar unificación real de unificación comercial
- ¿La plataforma se construyó como un sistema o se ensambló por adquisiciones? Preguntar cuándo se lanzó cada módulo y si comparten un mismo modelo de datos.
- ¿Cuántas veces se introduce una incidencia? Verificarlo en demostración con una desviación real, no en una diapositiva.
- ¿Qué estándares se generan de forma nativa? GTFS y GTFS-RT determinan si se puede seguir conectando con sistemas de la administración y calculadores de terceros sin desarrollo a medida.
- ¿Se puede recuperar el histórico completo, y en qué formato? Pedir una exportación de muestra antes de firmar.
- ¿Qué no hace la plataforma? Un proveedor solvente tiene una respuesta clara. Quien afirma cubrir todas las funciones está describiendo una hoja de ruta, no un producto.
El orden que funciona
Casi ningún operador puede sustituir cinco sistemas a la vez, ni debería intentarlo. La secuencia que funciona es empezar por la capa de datos de explotación, porque es la que alimenta todo lo demás: posición continua asociada a la expedición planificada.
Después depurar los datos de servicio. Ninguna predicción ni ningún informe es mejor que el horario y las paradas contra los que se compara.
Después la información al viajero sobre ese mismo flujo de eventos, no al lado.
Y dejar deliberadamente fuera una o dos especialidades reales, con una interfaz abierta que las mantenga conectadas. La unificación bien hecha casi nunca es total.
Si quiere ver qué aspecto tiene una explotación urbana con planificación, regulación e información al viajero sobre un mismo modelo de datos, y dónde caerían las fronteras con sus sistemas actuales, el equipo de Pysae puede recorrerlo con los datos de su red.