Motores de reservas: comprar o crear?

Wed, 07 Oct 2009 16:18:05 +0000

Entendemos como motores de reservas aquella tecnología que nos permite poner a disposición de terceros (vías web, xml, etc) nuestra disponibilidad de habitaciones, permitiendo que se pueda hacer la reserva.

El términio es muy amplio y la solución técnica que le podemos dar no es única. En este artículo trataré de explicar un poco qué alternativas tenemos a la hora de elegir un motor de reservas y los condicionantes que nos pueden llevar a elegir una solución u otra.

A la hora de elegir una solución debemos plantearnos el porqué lo hacemos: si queremos una solución para salir del paso o queremos una solución que nos de flexibilidad. Si necesitamos vender sólo nuestro producto o bien necesitamos, como en el caso de las agencias, vender disponibilidad de camas de un gran número de proveedores.

Veamos las principales alternativas:

Página estática

Listamos las posibilidades en nuestra web y el cliente rellena un formulario. Todo el proceso se realiza manualmente y no hay control de cupo y sí un procesamiento totalmente manual de la reserva.

Pongo esta opción por completitud, pero es la menos aconsejable, pero obviamente es la más rápida de desarrollar y mantener.

El iframe

Un iframe es una página dentro de una página. Es la solución que cuesta menos de poner en producción ya que se limita a unas pocas líneas de código HTML dentro de nuestro portal web. Si no tenemos portal obviamente habrá que crearlo.

Es la solución que presenta más desventajas desde el punto de vista de la hipoteca tecnológica (el precio que pagamos a la larga por elegir una solución), de dependencia del proveedor y por posicionamiento.

Hay que tener en cuenta que es el proveedor del iframe el que tienen el motor de reservas y lo aloja en sus servidores. Nosotros no tenemos control alguno sobre ni sobre el iframe ni nuchas veces sobre los resultados que aparecen.

El grado de integración que podemos tener con el iframe es mínimo, ya que recordémoslo, se trata de una página que no es nuestra y que por tanto tendremos únicamente lo que el proveedor del iframe nos proporcione.

En tema de posiciamiento de nuestra web el iframe representa un gran problema, ya que recordémoslo nuevamente, el iframe no forma parte de nuestra página, y por tanto no vamos a poder posicionar nuestro portal de modo tant eficiente como si todo el contenido fuese nuestro.

En resumen:

tiempo de puesta en producción: bajo
control: poco
dependencia del proveedor: alta
personalización: baja
indexabilidad: nula
desarrollo y mantenimiento: sólo contenido

Servicios XML

El motor de reservas sigue estando controlado por un proveedor externo pero este nos proporciona un interfaz xml con el que comunicar con él. Algunos proveedores XML pueden servirnos todo su contenido o bien únicamente contenido con contrato o cupo propio, por lo que también pueden ser una solución para cadenas y pequeños TTOO que no deseen mantener un motor propio.

El desarrollo de la aplicación web es más costoso ya que se necesita hacer una transformación entre los datos que nos suministra el proveedor (texto en XML) y la web y normalmente añadirle reglas de negocio para la presentación de resultados y precios. Se deben aplicar optimizaciones adicionales para agilizar los tiempos de respuesta de nuestra web y añadir una capa adicional de código que nos independice el XML del proveedor de las funcionalidades de nuestra web, de este modo si cambiamos de proveedor XML sólo tendremos que cambiar una pequeña parte de la web.

El grado de integración que podemos tener en nuestro portal web es muy alto, ya que el proveedor se limita a ofrecernos información de disponibilidad y nosotros decidimos qué y como lo presentamos. El posicionamiento por tanto no está limitado por la tecnología XML que utilizamos.

El grado de depenencia con el proveedor es alto, pero tomando algunas precauciones (como la de añadir una capa de procesamiento intermedia) podríamos dado el caso, cambiar de proveedor sin tener que empezar totalmente de cero. También estamos limitados por la interfaz de acceso que nos proporcione el proveedor (la API XML) y por el flujo que tenga del proceso de compra.

En resumen:

tiempo de puesta en producción: medio
control: alto
dependencia del proveedor: media
personalización: alta
indexabilidad: alta
desarrollo y mantenimiento: mapeo del xml y contenidos

Motor propio a medida

Tener un motor propio nos da control total sobre nuestro producto. Podemos elegir qué y cómo vamos a vender y cómo vamos a poner nuestro producto en la web o si vamos a permitir conexiones de terceros.

El motor puede estar optimizado para nuestro tipo de negocio, de modo que se tendría un motor con optimizaciones diferentes para hoteles de costa que para hotels de nieve. Al estar desarrollado a medida podemos alcanzar cotas de rendimiento y adaptación mucho más altas que en cualquiera de los dos casos anteriores.

Mantener un motor propio nos permite desarrollar nuevos productos e ir construyendo nuestra plataforma de venta a medida.

Todo esto tiene un coste, y no es tan solo el precio, tener un motor a medida propio sólo tiene sentido si pensamos invertir en la web al 100% y junto con el área de marketing ir desarrollando nuevas vías de negocio y fidelización de clientes.

Es importante que mantengamos el control del código fuente del motor (del programa), en caso contrario no tendríamos la flexibilidad que estamos buscando y mantendríamos una dependencia alta con el proveedor. Por ejemplo, si nuestro departamento de programación no tiene tiempo para desarollarlo de manera interna, podemos externalizar el desarrollo y asegurarnos de que el proveedor transfiere el código fuente y el conocimiento de cómo está hecho a nuestros desarrolladores.

El motor será todo lo complicado o sencillo que nuestro negocio requiera. Puede ser una simple tabla con las camas o un completo sistema de disponibilidad y ofertas.

En resumen:

tiempo de puesta en producción: medio o alto
control: muy alto
dependencia del proveedor: baja (si hay transferencia de código y conocimiento)
personalización: alta
indexabilidad: alta
desarrollo y mantenimiento: desarrollo y contenidos

Independientemente de la solución que elijamos, tenemos que verificar que podemos acceder a las estadísticas de reservas, que podemos exportar los datos que introducimos y ver si hay alguna posibilidad de que el sistema elegido se pueda comunicar con nuestro backoffice de gestión principal.

Éste es uno de los problemas principales: la venta web no se comunica con el backoffice de gestión y eso hace que haya un trabajo manual y rutinario que se podría evitar. A la hora de cambiar el backoffice convendría pedir siempre al vendedor sobre las posibilidades de importación de datos de venta y facturación del mismo. Un backoffice que permita la importación de datos en un formato estándard (texto plano, csv o xml por ejemplo) nos permitirá en un futuro integrar mejor las reservas que vengan de la web sin que tengamos que tener un programa que lo haga todo, pero eso es un tema que dejaré para otro día.

Cada una de estas opciones representa una apuesta mayor en la comercialización web y una implicación mayor de nuestros departamentos de IT (o de los partners que tengamos) y de los departamentos de marketing y ventas. Cuanto mayor es la apuesta mayor es el riesgo, pero también son mayores los beneficios.

Desde la blogosfera actualmente hay un movimiento importante contra el recorte ministerial en I+D, la frase que apunta Ricardo Galli también nos puede servir como conclusión en este apunte:

"Desde la revolución agraria las sociedades más desarrolladas no fueron las que podían comprar las herramientas, sino las que tenían los conocimientos y recursos para construirlas. Por ello en los países más desarrollados aproximadamente el 80% de la financiación de I+D proviene de fondos públicos. EEUU invierte en I+D casi el triple del PIB que España, la media europea es el doble, y algunos paises europeos casi cuatro veces más. Las tijeras no generan atajos."

Para comprar sólo necesitas dinero, pero te quedas sin el conocimiento.

Desde el punto de vista de control de negocio y mínima hipoteca tecnológica mis soluciones preferidas son el XML y el motor propio, pero obviamente cada uno conocerá mejor que nadie su situación. Espero que este apunte pueda servir para valorar las alternativas y encontrar la que mejor se adapte a las necesidades de cada negocio.

Presentación

Mon, 28 Sep 2009 18:03:22 +0000

Bienvenidos a este, mi primer apunte en la comunidad Hosteltur. Como primer apunte que es, creo que es conveniente hacer las presentaciones y explicar un poco el porqué del nombre del blog y la temática del mismo.

Mis datos personales más básico los podéis encontrar en mi perfil, de todos modos el perfil más completo se puede encontrar haciendo una búsqueda por aaloy, antoni aloy o bien por trespams en Google. Es lo que se llama la identidad digital.

Como podréis ver mi perfil profesional tiende a la tecnología, orientada y focalizada desde siempre en el sector turístico. Mucha de la gente que he visto en Hosteltur son profesionales del sector hotelero, mi visión es un poco la opuesta: la del TTOO, y más concretamente la de IT del TTOO, aunque también he estado involucrado en proyectos más típicamente hoteleros.

Trespams es también el nombre del blog personal que mantengo sobre gestión de proyectos y programación web. Me pareció buena idea mantener el mismo nombre, ya que aunque la temática del blog de Hosteltur no estará dedicada a programadores y jefes de proyecto, sí que tendrá que ver con la tecnología.

Se habla mucho de marketing, de web 2.0, de posicionamiento, etc. tanto que muchas veces nos olvidamos que antes de llegar ahí hay que recorrer un camino previo: tener la infraestructura necesaria tanto en sistemas como en software para soportar todo eso.

Tomemos por ejemplo el marketing o el posicionamiento. No hay duda que tenemos que invertir en ellos, pero la inversión será mucho mejor si:

Tenemos una web con capacidad de venta. Parece obvio pero todavía hay muchas web que son únicamente presenciales y es prácticamente imposible comprar.
Nuestra web está optimizadad para ser encontrada. Nuestra inversión en publicidad y marketing será mucho más rentable si hemos pensado desde cero nuestra plataforma de venta para que sea rápida, semántica e indexable.
Podemos responder rápidamente a los cambios. El negocio turístico es uno de los más dinámicos que existen, debemos poder responder a los cambios rápidamente, el "time-to-market", el tiempo desde que se tiene la idea a que se comercializa debe ser mínimo.
Podemos escalar rápidamente. Es decir, debemos estar preparados para no morir de éxito.

En próximos apuntes trataré de las tecnologías que nos permiten avanzar en el negocio, en el porqué de cada tecnología y en cómo evitar lo que se conoce como "hipotéca tecnológica", es decir, evitar que nuestras decisiones actuales en materia de tecnología nos lastren de manera irremediable el futuro.

Me gustaría que este blog fuese un espacio de comunicación abierto, se aceptan ideas, comentarios, críticas y opiniones. Intentaré no ser muy aburrido cuando hable de tecnología.

Nos leemos.

trespams Comunidadhosteltur.com

Motores de reservas: comprar o crear?

Presentación