Fundamentos del Modern Airline Retailing. Una serie de breves explicaciones sobre el MAR: la terminología, la estructura y qué cambia cuando las aerolíneas pasan de los PNR a los pedidos.
En las entradas anteriores se ha descrito el OOSD tal y como existe en teoría: el esquema, la estructura y los estándares. En esta entrada se aborda cómo es desarrollar realmente sobre esa base.
En resumen: es complejo, está en constante evolución y, con mayor frecuencia de lo que cabría esperar, la especificación y la implementación no coinciden.
El problema del sistema bilingüe
Uno de los principales retos a la hora de crear un sistema moderno de gestión de entregas es que los sistemas heredados no han desaparecido. Las compañías aéreas siguen utilizando sistemas basados en PNR, SSR y referencias de reserva de seis caracteres. Los servicios de asistencia en tierra, el equipaje y los sistemas APIS funcionan con identificadores heredados. No basta con sustituir el sistema antiguo por el nuevo; hay que mantener ambos al mismo tiempo.
Una posibilidad es crear lo que se podría llamar un sistema bilingüe: en lugar de traducir entre el sistema heredado y el nuevo, se mantienen ambas representaciones en paralelo dentro del mismo sistema. El sistema entiende los PNR y entiende los pedidos; puede comunicarse en ambas direcciones sin perder información.
En la práctica, la tendencia a la divergencia es real. El nuevo mundo tiene limitaciones diferentes —o, en algunos casos, ninguna limitación, mientras que el mundo anterior tenía límites estrictos—. Un vuelo puede tener 200 pasajeros. Una reserva PNR solía tener un máximo de 20. Un sistema que se construyó suponiendo 20 tendrá que reconstruirse eventualmente para gestionar 200. Mantener los dos mundos sincronizados el mayor tiempo posible da un respiro, pero no es una solución eterna.
Construyendo junto con OrMS
Hay un problema adicional: en muchas implementaciones, el sistema de gestión de pedidos y el sistema de gestión de entregas se desarrollan al mismo tiempo, por equipos diferentes, basándose en los mismos estándares en constante evolución. Cuando cambia uno, el otro tiene que cambiar también. Al final, se acaba desarrollando conjuntamente a partir de unas especificaciones en constante cambio, y cuando estas cambian (lo cual ocurre), ambas partes tienen que adaptarse.
Esto no es una crítica al proceso de elaboración de normas; es una reflexión sincera sobre lo que supone ser uno de los primeros en implementarlas. Las normas se diseñan en comités y se ratifican con el tiempo; los casos extremos y las contradicciones prácticas no siempre salen a la luz hasta que alguien intenta ponerlas en práctica.
Lo que no cubre la especificación
Algunas partes del panorama operativo quedan totalmente al margen del esquema OOSD, pero siguen formando parte de la realidad cotidiana del funcionamiento de un sistema de control de salidas. Los mensajes de horarios, los MVT, los SSIM y los ASM no forman parte del OOSD, pero un DCS sigue necesitando disponer de datos de horarios. Por ahora, eso significa seguir recibiendo mensajes similares a esos mensajes heredados del OrMS, incluso en una implementación que, por lo demás, sea moderna.
Del mismo modo, los acuerdos de interlínea y de código compartido añaden un grado de complejidad que el esquema aborda a nivel conceptual; existe una distinción entre la aerolínea responsable de la oferta, la compañía operadora y la compañía comercializadora, pero la aplicación práctica es confusa y, a menudo, debe resolverse caso por caso.
La distinción entre vendedor y proveedor de servicios de entrega
Un concepto que conviene comprender si estás desarrollando en este ámbito: el esquema distingue entre un vendedor (la entidad que ha añadido artículos a un pedido) y un proveedor de servicios de entrega (la entidad responsable de actualizar los códigos de estado de la entrega). Se trata de roles distintos con derechos de acceso diferentes. Los vendedores no pueden ver los artículos de los demás en un pedido. Un proveedor de entrega necesita tener visibilidad del pedido completo: todos los artículos, todos los servicios, independientemente de quién haya vendido qué, ya que es responsable de atender al pasajero durante todo su trayecto.
Si estás desarrollando un sistema de distribución centralizada (DCS), eres un proveedor de servicios de entrega. Eso significa que tu modelo de acceso, tus requisitos de datos y tus responsabilidades son diferentes a los de un sistema de venta.
P: ¿Ha planteado la implementación de OOSD retos importantes, como la incompatibilidad con el límite de pasajeros?
Sí. El estándar de pedidos no tiene límite de pasajeros, pero un sistema de control de reservas (DCS) heredado podría tener un límite máximo de 20. Ese es solo un ejemplo del tipo de desajuste que surge constantemente. Se encuentra en todas partes: en cómo funcionan los identificadores, en cómo se modelan los datos de horarios, en cómo se gestionan las reservas interlínea. La respuesta sincera es que construir este tipo de sistema es un proyecto de varios años, y gran parte del trabajo consiste en gestionar las diferencias entre el mundo antiguo y el nuevo.
P: ¿Se están documentando en algún sitio estos retos de integración y casos extremos?
Deberían hacerlo. Documentar las diferencias entre lo que dice la especificación y lo que realmente funciona en la práctica tiene un gran valor, tanto como recurso interno como para el sector en general. Lo irónico es que los equipos mejor situados para documentarlo son precisamente los que están demasiado ocupados desarrollándolo. Es una carencia conocida.