Cómo tres proveedores conectan la oferta, el pedido, la entrega y la liquidación sin una pila monolítica.
El comercio minorista de las aerolíneas se describe a menudo como un destino futuro. La oferta, el pedido, la entrega y la liquidación (OODS) tienen cuatro ámbitos que deben estar vagamente vinculados, pero estrechamente coordinados. En este proyecto conjunto, Turkish Technology, Ink y Sutherland demuestran cómo es cuando deja de ser teoría.
El mismo pedido se distribuye entre tres sistemas. Turkish Technology es la división tecnológica de Turkish Airlines y se encarga de la parte de ofertas y pedidos del proyecto conjunto. Ink las operaciones aeroportuarias. Sutherland reconoce los ingresos en función de lo que se ha entregado realmente.
Cómo se comporta un flujo OODS de extremo a extremo como un único recorrido
Oferta. Turkish Technology fabrica el producto y fija el precio.
La interfaz comercial de la aerolínea presenta una oferta contextual. Un itinerario familiar con vuelos, equipaje, equipamiento deportivo, sala VIP u opciones combinadas. El viajero ve una propuesta combinada que se adapta a su viaje.
Este es el dominio de la oferta. La aerolínea controla los productos, los precios y las normas. La oferta se crea a partir de un catálogo de productos y un gestor de existencias que conoce:
- ¿Qué se puede vender en esta ruta y con este transportista?
- ¿Qué combinaciones están permitidas?
- Cómo se vinculan los servicios auxiliares a los vuelos y los pasajeros
Nada en este paso depende de los sistemas aeroportuarios ni de la contabilidad. Se trata de una capa de oferta limpia que cualquier sistema de pedidos compatible puede utilizar.
Orden. La tecnología turca convierte la aceptación en un único registro.
El cliente acepta la oferta y realiza el pago. Detrás de la confirmación hay un pedido con los vuelos como un elemento del pedido, cada servicio complementario como un derecho explícito, con una clara vinculación entre pasajeros, segmentos y servicios.
Este es el dominio del Orden. El Orden es el único lugar que sabe lo que se ha prometido. Está construido según los estándares modernos del comercio minorista, lo que permite que se pueda compartir.
Desde aquí, la aerolínea expone el pedido y su contexto a través de API. Los socios no tienen que adivinar qué se vendió ni reconstruirlo a partir de los billetes. Simplemente leen el pedido y sus artículos.
Entrega. Ink el lado del aeropuerto contra la Orden.
En el dominio Ink, aparece la misma orden. Los agentes ven a la familia y sus vuelos, los artículos comprados previamente y cualquier servicio opcional que aún esté disponible para ofrecer en el aeropuerto. Sistema de entrega que permite realizar el check-in y la facturación del equipaje, imprimir etiquetas y tarjetas de embarque, y embarcar a los pasajeros. Las líneas de estado pasan de «reservado» a «listo», luego a «en curso» y finalmente a «entregado» a medida que se completa cada paso.
Este es el dominio de entrega. Ink propietario de la lógica comercial ni de la contabilidad. Consume el pedido de Turkish Technology y emite eventos operativos.
Por cada acción que se realiza en el aeropuerto, Ink el estado de la entrega y envía esas actualizaciones a la aerolínea. La secuencia es sencilla:
- Cuando puede comenzar la asistencia en tierra, los servicios pasan de «planificados» a «listos».
- Cuando se realizan el check-in, la entrega de equipaje y el embarque, pasan a «progreso».
- cuando el vuelo se cierra tras la llegada, pasan a «entregado».
La vista propia de Turkish y la aplicación del cliente se actualizan a partir de estos eventos de entrega. Los canales comerciales, operativos y de clientes permanecen alineados en el mismo estado del pedido.
Liquidación. Sutherland utiliza los eventos de entrega para reconocer los ingresos.
En la plataforma financiera de Sutherland aparece el mismo pedido. Los contables ven cada partida, con su precio contractual, los eventos de entrega asociados y el estado actual de reconocimiento. El sistema contable realiza un seguimiento para determinar si los ingresos siguen diferidos o se han obtenido tras la finalización de la entrega. Las partidas de ingresos pasan de «diferidos» a «reconocidos» a medida que los eventos de entrega confirman el cumplimiento.
Este es el dominio de liquidación. Sutherland no es propietario de la lógica operativa ni de la ejecución de la entrega. Consume los eventos de pedido y entrega compartidos por la plataforma de gestión de pedidos.
Los libros auxiliares de contabilidad, los informes financieros y los registros de auditoría se crean a partir de estos mismos eventos de entrega. Los acuerdos comerciales, la ejecución operativa y los libros financieros permanecen alineados en el mismo estado del pedido, lo que proporciona a las aerolíneas un reconocimiento de ingresos en tiempo real y una visibilidad financiera continua a medida que se ejecuta la cadena de suministro.
Lecciones aprendidas
Equipo de tecnología turco:
«La colaboración con Ink Sutherland demostró que los módulos OOSD modulares y basados en estándares de Turkish Technology pueden ofrecer una experiencia minorista totalmente integrada sin depender de sistemas heredados. Al exponer API de pedidos limpias y alineadas con la IATA, permitimos que socios como Ink Sutherland se conectaran a la misma fuente de información y operaran de manera coherente en todo el proceso de entrega y liquidación. La agilidad de nuestras plataformas internas, que abarcan la creación de ofertas, la gestión de pedidos, el catálogo de productos, la gestión de existencias y nuestro adaptador de modo dual, quedó patente en la velocidad, la flexibilidad y el control que proporcionaron a lo largo de todo el flujo de trabajo de principio a fin. La aplicación Concept Channel también demostró su valor como entorno de pruebas para la innovación, ya que nos permitió validar ideas antes de escalarlas a integraciones reales. En última instancia, el proyecto reafirmó que la modularidad, la interoperabilidad y el cumplimiento de los estándares del sector son factores clave para construir un ecosistema de venta minorista de aerolíneas preparado para el futuro y favorable a los socios».
Lo que demuestra este flujo OODS
La oferta y el pedido pueden funcionar como un módulo.
Una aerolínea puede ser propietaria de los dominios de ofertas y pedidos y seguir compartiendo lo importante con sus socios. El catálogo de productos, los precios y la estructura de pedidos se exponen de forma clara a través de API. Cualquier sistema de entrega que comprenda el modelo puede conectarse.
La entrega es una capa independiente e intercambiable.
La entrega se centra en la ejecución de servicios en el aeropuerto. Dado que funciona a partir del pedido, y no de un registro local propio, puede integrarse en cualquier sistema de pedidos que cumpla con los estándares. Si la aerolínea cambia su proveedor de ofertas o pedidos, no es necesario reconstruir desde cero la capa de entrega.
El asentamiento utiliza eventos
El sistema de contabilidad no intenta deducir el momento en que se producen los ingresos a partir de horarios o cupones de billetes. Escucha los eventos de entrega que reflejan lo que realmente ha ocurrido con cada servicio. La contabilidad se basa en el cumplimiento real, no en suposiciones.
Multifabricante. Un flujo OODS.
Ningún proveedor gestiona el conjunto completo. La oferta, el pedido, la entrega y la liquidación se implementan mediante diferentes proveedores, unidos por contratos y API. El flujo sigue comportándose como un sistema coherente.
Para una aerolínea, eso es lo fundamental. Hoy en día, es posible lograr una arquitectura OODS integral con un enfoque modular. Se puede comenzar en un dominio, incorporar socios en los demás y ampliar desde la «oferta» hasta el «registro en el libro mayor» sin necesidad de realizar grandes cambios.
Reserve su llamada para volver a ver la demostración completa.
Autor
