El proyecto de reforma y revitalización que salvó a Japan Airlines

En 2010, Japan Airlines (JAL) vivió un punto de inflexión cuando se declaró en quiebra y, posteriormente, anunció un plan de reestructuración que incluía una renovación muy necesaria de su sistema informático.

Desde 1967, JAL utilizaba el sistema de reservas y venta de billetes JALCOM, creado con Assembler sobre un mainframe de IBM. Sin embargo, estos sistemas funcionaban con sistemas operativos extremadamente antiguos, por lo que era solo cuestión de tiempo que dejaran de recibir soporte. El sistema obsoleto de JAL acabó convirtiéndose en un obstáculo en el año 2000, por lo que un equipo de revisión llevó a cabo una investigación de productos sobre sistemas de servicio al pasajero (PSS) de los principales proveedores. Sin embargo, la cuestión se pospuso ante problemas más urgentes, como la fusión de la aerolínea con Japan Air System en 2002 y el deterioro de su situación financiera. Irónicamente, cuando la empresa se declaró en quiebra, los retrasos en las inversiones en TI aumentaron aún más los costes, por lo que se dio prioridad a una solución urgente para todo el sistema con el fin de controlar la situación.

Así fue como comenzó el Proyecto Sakura. En abril de 2011, se creó el departamento de promoción de sistemas de pasajeros (PSPD), inicialmente formado por 10 personas, dependiente de la sede central de gestión de rutas, del que formaba parte Hitoshi Sugihara, actual director del departamento de Planificación Digital CX de JAL, quien desempeñó un papel fundamental en el Proyecto Sakura.

“Teníamos problemas porque el sistema se había convertido en una maraña debido a las repetidas modificaciones, lo que dificultaba la implementación de nuevas medidas o medidas relacionadas con el mercado”, explica Sugihara. “El punto de inflexión se produjo cuando British Airways vendió su filial de sistemas a Amadeus, después de que nosotros compráramos el software de British Airways y lo modificáramos nosotros mismos. Como resultado, dejamos de contar con el respaldo de BA y nos resultó difícil mantener el sistema por nuestra cuenta”.

Al año siguiente, el departamento de planificación de TI de la sede central de planificación corporativa se convirtió en la sede central de planificación de TI y se estableció un sistema en el que el PSPD evaluaba los proyectos desde una perspectiva operativa, mientras que la planificación de TI analizaba los enfoques desde una perspectiva técnica.

Decisiones sobre los servicios en la nube

La política básica para el nuevo sistema era utilizar servicios en la nube con una trayectoria probada en el servicio a aerolíneas extranjeras, centrándose en las reservas y la emisión de billetes para vuelos internacionales.

“Cuando investigamos soluciones en 2011, no pensábamos en migrar a la nube”, afirma Sugihara. “En aquel momento, tanto si se trataba de Amadeus como de cualquier otro proveedor, utilizábamos un formato SaaS seguro, intuitivo y de bajo coste, en el que el sistema estaba conectado a una red en un centro de datos en algún lugar del extranjero”.

A principios de 2012, enviaron una solicitud de propuestas a proveedores de TI y, tras evaluar su eficacia en otras aerolíneas, finalmente se decidieron por el servicio en la nube Altea de Amadeus.

“Conocíamos la estructura del sistema de British Airways y la de Altea era compatible con la nuestra”, explica Sugihara. “Amadeus ya era líder en el sector y se había expandido a nivel mundial de diversas formas. Queríamos responder con flexibilidad a las particularidades del mercado japonés y, al mismo tiempo, consolidarnos como estándar global, por lo que elegimos Amadeus, que había experimentado numerosas transiciones, había establecido sus propios métodos y contaba con una documentación sólida”.

Hay alrededor de 100 tipos de sistemas periféricos relacionados con los pasajeros conectados a JALCOM, de los cuales unos 70 están conectados a Altea. Por ejemplo, se creó un sistema de retransmisión denominado Passenger SOA Platform para convertir los formatos de datos de estos sistemas al formato Altea.

Dado que Altea puede incorporar las especificaciones únicas de la empresa anfitriona, JAL consideró la posibilidad de personalizarla internamente. Sin embargo, cuanto más intentaban estimar las horas de trabajo, más requisitos surgían. Como resultado, Amadeus se negó, alegando que no aceptaría proyectos que superaran la estimación inicial.

Movilización del Proyecto Sakura

El director del proyecto Sakura, Yoshiharu Ueki, nombró a Nishihata Tomohiro responsable de la renovación del PSS en 2014 y se encargó del mantenimiento de JALCOM. Como antiguo responsable del departamento de ventas web, estaba familiarizado con los sistemas back-end y front-end, por lo que era la persona ideal para desarrollar un nuevo sistema.

Tomohiro sucedió a Ueki como director del Proyecto Sakura y trasladó a 50 miembros del proyecto del departamento de planificación de TI al PSPD. El equipo estaba formado entonces por unas 100 personas, pero llegó a tener más de 300 en su momento álgido, con unas 200 procedentes de JAL Infotec, el departamento de planificación de TI, la filial aeroportuaria JAL Sky y la filial de centros de atención telefónica JAL Navia. A estos se sumaron otros 150 de empresas asociadas como Nomura Research Institute (NRI), posteriormente adquirida por IBM Japón, y Sigmaxyz.

“Inicialmente, el plan de reorganización de la empresa identificó que la TI estaba obsoleta en varias áreas, por lo que el departamento de planificación de TI solicitó la ayuda de NRI para revisar todo el sistema”, añade Sugihara. “Uno de los aspectos del plan era actualizar el PSS, por lo que NRI se incorporó en la fase inicial, pero cuando llegó el momento de poner en marcha el plan, IBM Japón, que había trabajado en el sistema POS en el pasado, comenzó a participar más activamente”.

IBM se encargó de actualizar los sistemas periféricos de JALCOM y de gestionar el proyecto, mientras que Sigmaxyz se encargó de la gestión del proyecto para personalizar Altea. Sin embargo, a medida que avanzaba la introducción del PSS, surgió un problema relacionado con el complicado sistema de tarifas de los vuelos nacionales, que se divide en descuentos y protocolos de reserva que no se ajustan al estándar mundial.

“Nos costó mucho incorporar las características únicas de los vuelos nacionales en Altea”, afirma Sugihara. “Así que se nos ocurrió un sistema llamado Clase J, que permite a los pasajeros mejorar su clase en el aeropuerto. Al final, pensamos en lo que podíamos hacer además de las soluciones de Amadeus y se nos ocurrieron algunas ideas ingeniosas”.

Un cambio cultural

Afrontar los retos sin miedo al fracaso ayudó a desarrollar una nueva mentalidad en JAL. A medida que el proyecto se acercaba a su fase final, uno de los principales problemas era la transferencia de los registros de nombres de pasajeros (PNR) y los datos de los billetes electrónicos. En ese momento, JALCOM tenía aproximadamente 4,5 millones de PNR y unos 9 millones de billetes electrónicos. Para llevar a cabo este cambio a Altea sin errores, se utilizó el sistema de transferencia de datos JAMP para recopilar los datos de JALCOM e integrarlos con las direcciones de correo electrónico recopiladas en otra base de datos en una sola para facilitar su manejo.

La migración de datos comenzó dos meses antes del lanzamiento real y todos los datos acumulados en JAMP, excepto los vuelos cancelados y los posteriores a la fecha de lanzamiento, se enviaron a Altea. A continuación, las diferencias se transfirieron en dos o tres entregas y el 99% de los datos que debían migrarse se premigraron a Altea.

A finales de 2017, se cerró el sistema existente y se llevó a cabo con éxito el cambio.

“Era extremadamente importante saber cómo transferir alrededor de 13 millones de datos al nuevo sistema, y Amadeus estaba transfiriendo los datos unos tres días antes», afirma Sugihara. “Pero pensamos que era demasiado arriesgado, así que le pedimos a Amadeus que realizara una prueba simulada en condiciones similares, lo que denominamos una variación de preproducción, y la hemos incluido en los proyectos de transferencia posteriores”.

Formación operativa generalizada

Para poder seguir utilizando el nuevo sistema, sigue siendo necesario formar a los usuarios sobre su uso y los riesgos que conlleva. En JAL, aproximadamente 10.000 empleados utilizan Altea para realizar reservas, emitir billetes, facturar y otras tareas. Dado que no era posible formar a todo el mundo a la vez, se creó un manual provisional y, con el paso de los años, esa función ha pasado de un equipo de 12 personas a unos 500 responsables de formación in situ procedentes de aeropuertos y centros de atención telefónica que se reunieron en la sede central de JAL para impartir sesiones de formación de 10 días.

“Cuando impartimos la formación a las personas que ya trabajaban en el puesto, había algunas que siempre trabajaban en rutas nacionales y otras que siempre trabajaban en rutas internacionales”, explica Sugihara. “Existe una brecha entre ellos y, en la fase inicial, el personal expresó su preocupación al respecto. Pero mantuvimos conversaciones exhaustivas con los responsables y los acercamos al estándar global”.

En ese momento, se hizo todo lo posible por eliminar las mejoras funcionales que nadie iba a utilizar y las funciones que nadie encontraba útiles, y un año después de la puesta en marcha del PSS en las rutas internacionales, también se lanzó un PSS personalizado para los vuelos nacionales tras mucho esfuerzo en los aeropuertos nacionales.

“Las aerolíneas que se han centrado tradicionalmente en las operaciones suelen adoptar un enfoque defensivo”, afirma. “Pero al asumir retos sin miedo al fracaso, creo que han sido capaces de desarrollar una mentalidad que les permite sobrevivir en un entorno competitivo difícil”.

Como resultado, otras empresas japonesas similares a JAL están actualizando rápidamente sus sistemas heredados de caja negra.

“El Proyecto Sakura es un ejemplo representativo de un proyecto a gran escala que adoptó el enfoque de ajuste a los estándares para que las operaciones cumplieran con los estándares globales”, afirma Daisuke Nishimura, presidente de DNTI, que ofrece apoyo para la transformación digital basándose en el ejemplo de JAL. “Los proyectos a gran escala convencionales se desarrollan utilizando la metodología en cascada, pero los únicos momentos en los que los usuarios utilizan realmente el sistema son en las fases de definición de requisitos y aceptación. Con la cascada, la distancia entre los usuarios y el sistema es demasiado grande, y la definición de los requisitos es insuficiente en la fase de aceptación, lo que hace imposible clasificar las solicitudes de los usuarios y da lugar a un sistema enorme. Creo que el desarrollo conforme a los estándares de JAL, con la participación de todos, fue un reto eficaz para resolver estos problemas”.