El estándar OTA: Una historia sobre protocolos e integraciones

0

En el mundo de las integraciones es fácil encontrar casos en los que cada empresa quiere usar su propio protocolo y en donde no encuentras un estándar que haga fácil la interconexión de sistemas. Así, los sistemas de integraciones se convierten en auténticas torres de babel en donde la comunicación con cada partner sigue un lenguaje diferente. ¿Por qué no se llega a un estándar en esos casos? Muchas veces se intenta, pero la realidad es que pocas veces se consigue.

En este artículo repaso el caso particular de las comunicaciones para la venta de hoteles, y muestro los que creo que son los motivos por los que al final cada empresa tiene su propio estándar.

Introducción

En el mundo de la hostelería es habitual que la venta de una habitación se realice en una empresa o punto diferente al del propio hotel. Agencias de viajes, tour operadores, páginas web, son sólo unos de los pocos puntos desde lo que hoy podemos comprar esas habitaciones. Los hoteles suelen tener un sistema central (CRS – Sistema de Reservas Computerizado) que integran con sus puntos de venta. ¿Cómo es esa integración? Muy compleja, con infinidad de protocolos y lenguajes diferentes. Es tan compleja que hoy en día existen empresas que únicamente se dedican a esa integración, los llamados Channel Managers. ¿Por qué es tan compleja? Vamos a dar un breve repaso histórico y lo aderezaré con mi propia experiencia, para ver cómo se ha llegado a la situación actual.

Un repaso a la historia

Antes de la segunda guerra mundial lo habitual era reservar los hoteles directamente. Si había algún intermediario éste solía tener contacto directo con el hotel. A mitad del siglo XX comenzaron a aparecer los tour operadores. Éstos hacían un contrato con los hoteles, a través de los cuales podían crear paquete en los que el cliente final podía comprar no sólo la habitación, sino todo lo relacionado con su viaje (transporte y servicios en el destino). Los contratos no solían requerir una comunicación fluida entre hotel y operador, por lo que la integración no era problema.

A finales de los 80, las compañías aéreas se vieron en la necesidad de crear un sistema de interconexión con las agencias de viajes, ya que la competencia forzaba a una variabilidad de precios, que no podía comunicarse a las agencias por los canales tradicionales. Así nacieron los GDS (Sistemas de Distribución Mundial). Un GDS, con terminales en las agencias, les permitía estar conectadas directamente con las compañías aéreas. Poco tardaron los GDS en ampliar los productos que podían ofrecer a las agencias, y a principios de los 90 comenzaron a aparecer grandes cadenas hoteleras.

En los primeros años de los 90, las agencias podían vender una reserva de hotel principalmente de dos maneras, a través de un GDS o por el catálogo de un touroperador. Los tour operadores tiraban de catálogos de precios, que no necesitaban integración. Los GDS’s si que se integraban, pero como eran pocos (principalmente 4) todavía no podemos hablar de torre de babel.

El aumento de puntos de venta.

A mediados de los 90 comenzaron a aparecer múltiples actores en el negocio, como las agencias de viajes on-line. El auge de Internet es uno de sus principales motivos. Aumento de actores y todos ellos quieren tener conexión con los CRS’s de los hoteles. Comienza a gestarse el caldo en el que cada uno comienza a desarrollar sus propios protocolos para comunicarse.

Unos intentan basarse en las comunicaciones de los GDS, pero pronto todos comienzan a sumarse a la moda del SGML y el XML.

El primer intento de poner orden

A finales de los 90 todo el mundo comienza a ser consciente de que es necesario un estándar, por lo que comienzan los intentos para desarrollarlo. Por un lado se desarrolla HITIS, específico para la industria hotelera. Y por otro lado se desarrolla OTA, que trata todo tipo de integración en el sector turístico.

El problema al que se enfrentaban estos estándares es el poder dar cabida a todos los modelos de negocio existentes. Intentaré explicarlo con un ejemplo muy concreto. Existen sistemas en los que el precio de una habitación es siempre el mismo, sin tener en cuenta cuantas personas entran. En otros sistemas este precio es el de una persona, más unos suplementos. Y en otros, cada combinación de posible ocupación de la habitación tiene un precio diferente. Además entra en juego el tipo de régimen (sólo alojamiento, desayuno, media pensión, …) que en algunos casos es un suplemento y en otros un conjunto de precios diferentes. ¿Cómo hacer un lenguaje estándar que de cabida a todos estos modelos?. Pues creando lo que yo llamo un pseudo-estándar. Un estándar tan abierto que es cualquier cosa menos un estándar.

El segundo intento de poner orden

OTA se estableció como el estándar de referencia, pero no cubría todos los casos, y las empresas tiraban fácilmente de las extensiones (las famosas TPA_Extensión que luego os describo) para cubrir esas carencias. Visto esto, llega otro actor a los estándares, el HTNG, que no es más que intentar poner orden sobre OTA. Es decir, es una guía más restrictiva a la hora de aplicar OTA. Un intento por acotar más el estándar. Pero con importantes opciones abiertas todavía.

El resultado

Las compañías más fuertes en el negocio no tuvieron problemas para imponer su propio estándar. La necesidad del resto para conectarse les aseguraba que todos hablasen con ellos el mismo idioma. Las más débiles intentaron adoptar estos estándares en un intento por reducir la complejidad de sus integraciones. Pero fue bastante en vano, ya que cada implementación de estos estándares era completamente diferente.

Al final lo que tienen hoy la mayoría de compañías en el sector es un complejo sistema de integraciones. De hecho han proliferado los llamados channels managers, que a través de una única integración permiten conectarse con múltiples agentes.

El concepto de pseudo-estándar

La mayoría de agentes involucrados no quería tener un universo lleno de integraciones diferentes y llegar a tener un estándar común a todos. Algo como el HTML, que permite que cualquier navegador y servidor web se comuniquen sin problemas. Pero no se ha logrado.

Como digo, estos estándares debían dar cabida a todos los posibles modelos de negocio que tuviesen las empresas. Así que en muchas ocasiones un mensaje es realmente un conjunto de opciones que se pueden escoger. Dependiendo de lo que se escoja, el mensaje cambia. Por lo que cada empresa, al coger unas opciones diferentes, está usando realmente un estándar diferente.

Además los estándares debían estar preparados para casos raros y lo que pudiese venir. Para ello incluyeron extensiones, o lo que es lo mismo, comodines en los que todo vale. En el estándar OTA hablamos de las TPA_Extensions. Se trata de unas etiquetas en las que puedes poner lo que quieras. Así si algo del estándar no te gusta, o no ves donde poner ese dato que necesitas, añades una TPA_Extensión y solucionado. ¿Qué tiene eso de estándar? Ya te lo digo yo, nada.

Además tienen un efecto que a mí particularmente me molesta bastante: confundir a negocio. No hay nada peor a que te venga negocio pidiendo una integración con un tercero diciendo “no habrá problema porque su estándar también es OTA como el nuestro”. Por mucho que le expliques que su OTA es “otra OTA” diferente a tu protocolo, parece que les cuesta entenderlo.

Resumiendo, queriendo abarcar todo, han conseguido no estandarizar nada.

La reacción de los grandes

Durante 2009 trabajé en Planeta Web, una empresa dedicada al desarrollo web en el sector turístico, principalmente el hotelero. Planeta Web pertenecía a Turistec, un cluster de empresas tecnológicas de baleares relacionadas con el sector turístico. Así que, indirectamente me tocó participar en un proyecto promovido por Turistec: el proyecto CAVAL. CAVAL intentaba crear un estándar de comunicación mucho más concreto que OTA, HITIS o HTNG, sin dar tanta libertad a la implementación. CAVAL fijaba un modelo de precio y obligaba al partner a adaptarse. El objetivo era claro, conseguir un estándar real de integración para el sector turístico.

Por supuesto, un pequeño grupo de empresas en Baleares no fue capaz de conseguir la adopción del estándar, por lo que a día de hoy muy pocos lo utilizan (por no decir ninguno). Pero lo traigo para poder contaros una reunión a la que asistí.

A finales del 2009 se celebró un cafeTec, un evento organizado por Turistec que consistía en un desayuno temático al que se invitaba a personas relevantes en el tema. El de ese día fue sobre el proyecto CAVAL, y se invitó a los responsables de TI de dos grandes cadenas hoteleras con base en Mallorca. Cuando se les contó el proyecto la respuesta de las cadenas fue negativa. Primero porque enseguida vieron que se trataba de un proyecto con acta de defunción desde el primer día. Pero segundo, y más importante, porque no querían que naciese un estándar de ese tipo. El hecho de que la integración fuese tan compleja suponía una barrera de entrada importante. Las grandes cadenas ya habían hecho el gasto en desarrollar todas estas integraciones, y les daba una ventaja competitiva frente a quien no había hecho ese gasto. Que apareciese un estándar suponía que esa barrera desaparecía, cosa que no les interesaba.

Resumiendo, las empresas con recursos salen beneficiadas en este caos, porque les permite destacar frente a las pequeñas, que no pueden entrar a jugar.

El pulso de los protocolos

Otro factor importante es la fuerza de cada empresa en el sector. Cuando dos empresas quieren integrarse, la más fuerte suele imponer su implementación del estándar. Y si es suficientemente fuerte ya no será una implementación del estándar, sino su propio estándar. Booking o Expedia, por ejemplo, tienen sus propios protocolos. No necesitan acogerse a ningún estándar. Son tan fuertes en el sector que obligan a todos los demás a integrarse con ellos. Para ellos esta situación es ideal, ya que se utiliza su protocolo en todas sus integraciones. Esto implica tres cosas importantes:

  • Por un lado sólo mantienen un lenguaje, con lo que los costes de integración no son tan elevados.
  • Por otro, ese lenguaje es a imagen y semejanza de su modelo, por lo que la integración es más simple.
  • Por último, controlan su propio protocolo, con lo que si en un momento necesitan adaptarlo, lo adaptan, y el resto se adapta a ellos.

Para estos grandes jugadores los estándares son del todo indeseables. Primero por la barrera de entrada que suponen a los competidores, y segundo porque un estándar no lo pueden controlar.

Casos similares

Este caso de las integraciones en el sector hospitalario no es único, y lo encontramos en otros sectores. Por ejemplo, en el sanitario, en el que el protocolo HL7 es el pseudo-estándar de referencia, y en el que encontramos los mismos problemas y las mismas motivaciones.

Resumen final

En contra de lo que pudiese parecer lógico, el número de lenguajes utilizados no para de crecer. Cada uno intenta imponer el suyo propio y la posibilidad de tener un estándar real común a todos, parece algo utópico. Aparecen los pseudo-estándares, que realmente no solucionan mucho, con lo que el problema sigue ahí.

Pero como muchas veces se dice en el mundo de las TI: “Si no fallase nunca nada, nos despedirían”. Este caos nos proporciona trabajo. En esta torre de babel, los que trabajamos en el mundo de las integraciones tenemos trabajo para rato.

IntegraciónOTA

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios