En esta serie semanal de preguntas frecuentes, Ink analizarán cómo las aerolíneas están pasando al modelo Modern Airline Retailing, explicando lo que esto significa para la prestación de servicios, los cambios que implica y los pasos prácticos que permiten que la transición sea fluida.
En el número 1, hablamos del cambio del PNR y la gestión basada en billetes a los pedidos.
En estas preguntas frecuentes, Víctor Alzate, director de Producto, y Ben Waymark, vicepresidente de Arquitectura de Producto, explican cómo se comunican sus sistemas operativos con su sistema de pedidos. Quién le informa de que un cliente está listo para volar, cómo se refleja ese estado en el pedido y qué ocurre con el equipaje en ese proceso.
Nos centramos en cinco preguntas:
- ¿Cómo funcionará «Ready to Fly» entre las distintas aerolíneas? ¿Se basa en el DCS o en los pedidos?
- ¿Hay alguna diferencia entre«registrado y no se presentó»y«no se registró y no se presentó»en lo que respecta a los reembolsos?
- ¿Qué significa en la práctica«múltiples sistemas de gestión de entregas por servicio»?
- ¿Cómo se prestan los servicios desde Orders a DCS y otros sistemas operativos?
¿Qué pasa con el equipaje? ¿Está listo para plataformas modernas como BIX?
P. ¿Cómo funcionará «Ready to Fly» entre las distintas aerolíneas? ¿Se basa en el DCS o en los pedidos?
En primer lugar, los términos:
- DCS (Departure Control System): sistema que gestiona el check-in, el embarque y la asignación de asientos en el aeropuerto.
- DMS (Delivery Management System, sistema de gestión de entregas): sistema que incluye puertas de acceso a salas VIP, control de salidas, gestión de tiempos mínimos de conexión y recogida de equipaje, así como todas las funciones de un DCS.
- DC: módulo de control de salidas dentro del sistema DMS, que ejecuta funciones DCS heredadas.
- OrMS: sistema de gestión de pedidos, el sistema que almacena los pedidos, los servicios y su estado.
- Minorista: la aerolínea o socio que vende la oferta al cliente y es propietario del pedido.
- Proveedor: la aerolínea que opera el vuelo.
En una configuración de minorista y proveedor, el minorista es el propietario del pedido, pero el proveedor gestiona el vuelo. El DCS o DMS del proveedor es el sistema que conoce:
- ¿Quién se ha registrado?
- ¿Quién ha superado las comprobaciones necesarias?
- ¿Quién ha sido aceptado para viajar y ha embarcado?
Sin embargo, «Ready to Fly» también debe estar visible en el OrMS del minorista, ya que impulsa:
- Lo que el cliente ve en la aplicación o el portal
- Si un servicio se considera prestado a efectos de las normas sobre reembolsos e ingresos.
- Lo que se comunica a los socios y en el acuerdo
Así que la división es:
- El proveedor DCS / DC es la fuente de información operativa fiable en el aeropuerto.
- Proveedor OrMS es el registro del proveedor del pedido.
- El minorista OrMS es el registro del minorista del mismo pedido.
Un modelo viable sería el siguiente:
Por lo tanto, la respuesta a «DCS u OrMS» es:
- El evento comienza en el DCS / DC del proveedor.
- La «fuente de verdad» para los productos y servicios de la aerolínea es OrMS.
- «Listo para volar» no debería ser un concepto exclusivo del control de salidas que nunca llega al pedido.
Cuando un proveedor aún no cuenta con un OrMS adecuado, se puede intercalar una pequeña capa de integración que escuche los eventos de control de salida y los convierta en actualizaciones de pedidos para el minorista. Sin embargo, a largo plazo, lo ideal es que el centro de distribución se comunique con el OrMS y que los OrMS se comuniquen entre sí entre las distintas aerolíneas.
P. ¿Hay alguna diferencia entre«facturó y no se presentó»y«no facturó y no se presentó»en lo que respecta a los reembolsos?
Sí, debería. Si su proceso no los distingue hoy en día, su política es ineficaz.
Hay dos situaciones básicas:
Escenario 1. El cliente facturó, pero no embarcó.
- La aerolínea reservó el asiento.
- Se inició el trabajo operativo: se podrían revisar las maletas, cargar el catering y actualizar las listas de seguridad.
- Los cambios de última hora pueden alterar el vuelo.
Escenario 2. El cliente nunca se registró y no se presentó.
- Hay menos trabajo operativo.
- El asiento podría liberarse antes.
- Tienes menos costes y menos interrupciones.
En un modelo basado en pedidos, puede realizar un seguimiento por servicio:
- Estado del check-in
- Estado de embarque
- Si realmente se prestaron servicios relacionados, como el transporte de equipaje o la asignación de asientos.
- Cuando ocurrieron estos acontecimientos
Esto significa que las normas sobre reembolsos y vales pueden tener en cuenta:
- «¿Se registraron?»
- «¿Subieron a bordo?»
- «¿Qué servicios se prestaron realmente?»
En lugar de un simple«ticket utilizado o no utilizado», tienes opciones más precisas:
- Sin registro y sin presentación: se permiten créditos parciales en algunos servicios.
- Registrado y no presentado: normas más estrictas, porque realmente se ha prestado parte del servicio.
Por lo tanto, si tu herramienta de reembolso sigue ignorando el estado del registro y la entrega, ahora se trata de una elección consciente, no de una limitación estricta del sistema de pedidos.
P. ¿Qué significa en la práctica«múltiples sistemas de gestión de entregas por servicio»?
En lenguaje sencillo: un servicio puede ser prestado por varios sistemas.
Tomemos un caso sencillo:
Un pasajero vuela de A a B. Lleva un equipaje de mano, una maleta facturada, un asiento pagado y acceso a la sala VIP.
Incluso para ese viaje, intervienen varios sistemas operativos:
- El control de salidas se encarga del check-in y el embarque.
- Un sistema de equipajes o módulo DMS gestiona el equipaje facturado.
- Un módulo de gestión de asientos o DMS gestiona la asignación de asientos.
- Un sistema de sala de espera valida el acceso.
- El servicio de catering o un sistema de comidas por encargo previo pueden preparar comidas especiales.
En el mundo del PNR (registro de nombres de pasajeros), se une todo esto con:
- Elementos PNR y SSR (solicitudes de servicios especiales)
- Billetes y EMD (documentos electrónicos diversos)
- Muchas integraciones personalizadas punto a punto
En un mundo ordenado, la idea es diferente:
- OrMS tiene una visión completa de la Orden y sus servicios.
- Cada sistema de entrega solo necesita ver las piezas que tiene que entregar.
Por lo tanto,«múltiples sistemas de gestión de entregas por servicio»significa:
- Un único servicio en la orden, por ejemplo,«equipaje facturado para el pasajero 1 del vuelo 123», puede ser visto y actualizado por varios sistemas.
- Todos hablan con OrMS, no directamente entre ellos.
- OrMS es el lugar que conserva el historial y el estado actual.
Esto evita que cada sistema invente su propia verdad parcial sobre lo que se entregó.
P. ¿Cómo se prestan los servicios desde Órdenes hasta Control de salidas y otros sistemas operativos?
Hoy en día, para muchas aerolíneas, los billetes y los cupones son los que impulsan la entrega. Los sistemas de control de salidas y de equipajes comprueban el estado de los billetes y las observaciones del PNR.
En una configuración basada en pedidos, la entrega se gestiona a partir del pedido. OrMS sabe:
- Quiénes son los viajeros
- Qué vuelos y servicios han comprado.
- Cuáles son las normas para cambios, reembolsos y entregas.
El flujo queda entonces así.
- Pedido creado y almacenado en OrMS. OrMS contiene los pasajeros, vuelos, asientos, equipaje, servicios complementarios, condiciones y pagos.
- Los sistemas operativos preguntan qué deben entregar, o se les indica. Hay dos patrones:
- Pull: DCS/DMS pregunta a OrMS«¿qué necesito entregar para este pasajero o este vuelo?».
- Push: OrMS envía«esto es lo que debe entregar»a DCS/DMS u otro sistema cuando se producen determinados desencadenantes, por ejemplo, cuando se abre el registro.
- Los sistemas operativos informan sobre lo que ha sucedido.
Ejemplos:- DCS/DC envía«pasajero facturado»,«pasajero embarcado»,«cambio de asiento».
- El sistema de equipajes envía«maleta etiquetada con el número X»,«maleta cargada»,«maleta pérdida en la conexión».
- El sistema de sala de espera envía«cliente utilizó la sala de espera a la hora Y».
- OrMS actualiza el pedido y comparte ese estado. OrMS toma esos eventos, actualiza el pedido y, a continuación:
- Actualiza la aplicación o el sitio web del cliente.
- Ingresos y contabilidad.
- Impulsa la reprogramación, la gestión de interrupciones y el análisis posterior.
En lugar de que los eventos operativos queden encerrados dentro de cada sistema local, se vinculan con la Orden. Eso es lo que significa en la práctica«entrega con Órdenes».
P. ¿Qué pasa con el equipaje? ¿Está preparado para plataformas modernas como BIX?
El equipaje está desordenado hoy principalmente porque:
- Los sistemas de equipaje suelen funcionar con sus propias bases de datos y mensajes.
- La relación entre una bolsa y el producto vendido es débil.
- Los socios se esfuerzan por compartir una imagen clara entre las aerolíneas.
En un mundo basado en pedidos, el modelo de datos ya admite lo que necesita el equipaje:
- Puede describir las franquicias de equipaje, tanto por pieza como por peso.
- Puede transportar el equipaje de varios pasajeros en un solo viaje.
- Puede almacenar servicios como equipaje adicional o artículos especiales como productos transparentes.
- Puede vincular las maletas con pasajeros y vuelos específicos.
Para una plataforma como BIX (Baggage Information Exchange), la ventaja es:
- En lugar de hacer conjeturas a partir de los billetes y los PNR, puede leer en los pedidos qué equipajes están permitidos, pagados y previstos.
- Puede enviar eventos, por ejemplo,«bolsa cargada»o«bolsa retrasada», de vuelta a OrMS.
- OrMS puede mostrar el estado exacto del equipaje a los clientes y socios.
La principal limitación ahora no es la norma en sí misma, sino su adopción:
- Las aerolíneas deben conectar las plataformas de equipaje al mismo flujo de eventos que el control de salidas.
- Los proveedores deben aceptar los pedidos y los servicios como entradas, no solo los mensajes heredados.
Si su plan de actualización de equipaje no tiene en cuenta en absoluto los pedidos y las órdenes de compra, solo está actualizando la interfaz de usuario de un silo, no solucionando el problema de integración.
¿Por qué los sistemas de control de salidas y equipajes deben comunicarse con los pedidos?
Esta es la parte menos glamurosa de las ofertas y los pedidos, pero es donde residen el riesgo y el valor.
Si lo ignoras y simplemente «envuelves» tus antiguos flujos:
- Las normas de reembolso seguirán siendo inflexibles, ya que no pueden ver lo que realmente ocurrió en cada servicio.
- Las discusiones con los socios continuarán, porque nadie tiene un historial impecable de entregas.
- Sus equipos seguirán realizando tareas manuales, leyendo pantallas DCS y PNR, y luego introduciendo las decisiones en una interfaz de «Pedidos».
Si haces el trabajo duro:
- «Listo para volar» tiene un significado claro, compartido entre DCS/DMS y OrMS en todas las aerolíneas.
- La lógica de reembolsos e ingresos puede utilizar el estado real del servicio en lugar de conjeturas.
- Los sistemas de equipaje, sala VIP y socios pueden comunicarse con Orders sin esperar a que se sustituya todo el sistema.
Tu elección: o bien los pedidos se convierten en el lugar donde reside la verdad de la entrega, o bien se convierten en una fina capa que cubre la misma fragmentación de siempre.
Autor
