trespams

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.