OpenApps – Invat·tur - Instituto Tecnológico Hotelero5.2 – eCommerce (capacidad de venta...

OpenApps – Invat·turInnovación para la mejora de la competitividad y la rentabilidad del

Sector Turístico de la Comunitat Valenciana

El PROYECTO

2

“Desarrollo estratégico de conceptos y herramientas horizontales de transferencia tecnológica para el desarrollo de capacidades y modelos de negocio turísticos que incrementen decisivamente la competitividad y rentabilidad del destino Comunitat Valenciana y de las empresas y profesionales que lo conforman”.

Nuestra PROPUESTA

OpenApps es un proyecto liderado por la Conselleria de Turisme y el Invat·tur, con el objetivo de poner en acción una serie de iniciativas para dar respuesta a los desafíos a los que se enfrenta el sector, y a los cambios que se han producido en la demanda a lo largo de los últimos años.

El desarrollo acelerado de capacidades que nos exigen dichos cambios, nos lleva a plantearnos, entre otras áreas prioritarias de actuación, la búsqueda de soluciones innovadoras y con impacto a corto, medio y largo plazo, en las áreas de Promoción, Marketing, Distribución y Fidelización, en la doble vertiente estratégico/táctica, así como en la dotación de las herramientas tecnológicas que las vertebren.

Nuestra PROPUESTA (I)

4

Con este objetivo, la Conselleria de Turisme a través del Invat·tur pone en marcha un proyecto dinamizador y con un enorme potencial de transformación en el sector, que nos debiera llevar a unos niveles de competitividad y rentabilidad muy superiores y sostenibles a los que de otra forma podríamos anticipar en estos momentos.

Durante los meses de Oct-Dic 2009 un equipo combinado de técnicos de la Conselleria de Turisme, Asociaciones Sectoriales, ITH y consultores estratégicos y tecnológicos, se unen para definir los parámetros de éxito enfocados a la mejora inmediata de la competitividad, rentabilidad y sostenibilidad de las empresas turísticas de la Comunitat Valenciana.

Nuestra PROPUESTA (II)

5

1 – Gestión de Producto2 – Gestión de Distribución3 – Módulos de Yield/Revenue/Pricing4 – Gestor de Canales de Distribución5 – Generador de Webs avanzadas:

5.1 – Conexión al CRS (central de reservas)5.2 – eCommerce (capacidad de venta online)5.3 – Elementos 2.0 (acceso a redes sociales)5.4 – Metabuscadores (buscadores de oferta)

Nuestra PROPUESTA (III)

6

El resultado de estos esfuerzos se materializará en:• Una Estrategia de Promoción, Marketing y Distribución integral para los destinos,

productos, servicios y empresas de la Comunitat Valenciana. • Un análisis que incluya las mejores alternativas para la conversión del tráfico de

las webs institucionales en ventas efectivas.• Una plataforma tecnológica que ofrezca:

Así, el empresario (desde los apartamentos turísticos a las AAVV, pasando por hoteles, campings, alojamiento rural, restaurantes, oferta complementaria, etc.) podrá disponer de una serie de herramientas que le permitan acceder y gestionar de mejor forma su inventario con adecuadas estrategias de revenue, la gestión propia de los CRSs (Central Reservation Systems) e IDSs (Internet Distribution Systems) y/o la creación de webs avanzadas.

Pero, al mismo tiempo, se le ofrecen las claves para comprender comportamientos y repercusiones de la nueva forma de enfrentarse al momento vacacional que tiene el viajero.

Además, al ser las herramientas en código abierto, permitirá un entorno de mejora constante y acorde con las nuevas dinámicas en las que están inmersos los viajeros.

Nuestra PROPUESTA (IV)

7

Objetivos del Proyecto

OBJETIVOS DEL PROYECTO (I)

• Dotar al sector de una estrategia comercial común como destino, que nos permita multiplicar los resultados de los esfuerzos comerciales de todos los agentes turísticos basados en la coordinación y en navegar en una misma dirección.

• Definir los puntos estratégicos que nos ayuden a incrementar la competitividad del sector turístico valenciano e impulsar la comercialización de la oferta del sector en Internet.

• Mejorar la distribución, comercialización y posicionamiento online de las empresas que forman el sector turístico valenciano.

• Capitalizar el tráfico generado por la promoción institucional dirigido a la página www.comunitatvalenciana.com así como a aquellas páginas institucionales que quieran incorporarse a la iniciativa.

9

OBJETIVOS DEL PROYECTO (II)

• Dotar al sector de una serie de herramientas tecnológicas, formativas y de gestión, que nos permitan tener una mejor visibilidad de toda nuestra oferta turística, un mayor control de nuestra comercialización y como resultado un aumento de competitividad y rentabilidad de nuestra propuesta de valor turística.

• Crear las herramientas adecuadas y garantizar su evolución constante ayudando al sector a estar al día y a afrontar los retos del turismo del S XXI.

• Desarrollar el análisis funcional, técnico y arquitectura de las aplicaciones objeto del proyecto.

• Hacer extensiva la solución tecnológica al mayor número y diversidad de la oferta turística: alojamiento, vuelos y transportes, agencias de viaje, servicios de ocio, cultura y actividades, restauración, etc.

10

OBJETIVOS DEL PROYECTO (III)

• Establecer las bases para el desarrollo de una comunidad de profesionales y desarrolladores de software libre, que recoja las necesidades y requerimientos del sector, y que trabajando de forma conjunta bajo una estrecha colaboración, conviertan esta plataforma tecnológica en un modelo de competitividad que pueda ser reconocido como un conocimiento exportable.

• Convertir al proyecto OpenApps - Invat·tur en punto de referencia para el desarrollo de aplicaciones informáticas en el ámbito turístico y situar a la Comunitat Valenciana en posición de liderazgo de la gestión integral de destino, siendo Invat·tur el motor de todas estas iniciativas que impulsan la transformación de nuestro sector turístico.

11

Talleres de Trabajo Sectoriales

La “fase cero” del proyecto OpenApps – Invat·tur

TALLERES de Trabajo SECTORIALES - OBJETIVOS

• Conocer y compartir la idea del proyecto y poder reflexionar y debatir sobre las estrategias de futuro vinculadas.

• Abrir escenarios nuevos de debate y discusión.

• Recoger las necesidades del sector privado y administraciones públicas para diseñar la mejor solución estratégica.

• El sector ha de conocer, reconocer y participar del valor generado por el proyecto.

13

TALLERES de Trabajo SECTORIALES – ESTRUCTURA

• Se desarrollarán dos jornadas, una de presentación y otra de cierre dirigida a los líderes sectoriales públicos y privados para presentar el proyecto y las conclusiones.

• Entre ambas, se celebrarán varios workshops especializados atendiendo a los distintos agentes turísticos, organizados por subsectores, para explicar el proyecto y definir las necesidades y expectativas.

• Duración de workshops de presentación y cierre: 3 horas

• Duración de workshops especializados por agentes: 4 horas

14

WORKSHOPS SECTORIALES – DINÁMICA DE SESIONES

INFORMACIÓN

FORMACIÓN

PARTICIPACIÓN

Justificación estratégica. Objetivos, alcance e implicaciones.

Conceptos básicos de gestión comercial y de gestión integral del destino.

Identificación de oportunidades, necesidades y amenazas o posibles áreas/factores de bloqueo. Incorporación de elementos estratégicos, tácticos y de funcionalidades de la plataforma tecnológica relevantes para los diferentes subsectores.

15

Presentaciones

Documentos

Cuestionarios

Proyecto INVAT·TUR Estrategia TECH Desarrollo

Implantación

Áreas de atención inmediata para la competitividad y rentabilidad del

destino y empresas turísticas.

“Si tuviera toda la financiación necesaria. ¿Qué acciones de promoción,

marketing y fidelización, ventas y tecnología priorizaría?”

El CONOCIMIENTO Turístico Valenciano como activo estratégico. ¿Cómo lo

convertimos en algo vivo, enriquecedor y exportable?

16

WORKSHOPS SECTORIALES – CONTENIDOS

El Proyecto – Fase 0 Invat·tur - Oct/Dic 2009

El Proyecto – Desarrollo – 2010 – 2012

TALLERES de Trabajo SECTORIALES – INPUTS/OUTPUTS

Hacia el SECTOR

Desde el SECTOR

Gestión Comercial

Gestión Integral Destino

Palancas de negocio y tech para la distribución

online

La estrategia de competitividad del destino

Necesidades y Oportunidades

Capacidades existentes y a desarrollar

Necesidades de funcionalidades y

formación sobre tech

17

CALENDARIO de Talleres

18

DICIEMBRECIERRE – Líderes Sectoriales

15 Diciembre – 3 horas

OCTUBRE

APERTURA – Lideres Sectoriales6 Octubre – 3 horas

Oferta Hotelera13 Octubre – 4 horas

Agencias de Viajes I20 Octubre – 4 horas

Oferta Complementaria27 Octubre – 4 horas

Restauración27 Octubre – 4 horas

Agencias Viaje II20 Octubre – 4 horas

NOVIEMBRE

Alojamientos Rurales3 Noviembre – 5 horas

Apartamentos17 Noviembre – 5 horas

Campings24 Noviembre – 5 horas

Instituciones Turísticas28 Octubre – 4 horas

Otros elementos de información del proyecto

OpenApps – Invat·tur

La PLATAFORMA TECNOLÓGICA (esquema básico)

20

• El elemento básico es un CRS (Central Reservation System) que permita la gestión de inventario de todo el producto turístico desde un único repositorio.

• El segundo punto clave es la conectividad de acceso a los principales canales de distribución globales y dar a las AAVV la posibilidad de integrarse y sacar el máximo provecho del sistema.

• La herramienta ofrecerá módulos básicos de gestión de inventario a nivel propiedad/empresa, con funcionalidades de revenue, yield, pricing y CRM (Customer Relationship Management.

• Integrado en el sistema habrá un generador de páginas web avanzadas, con capacidad de eCommerce, metabuscador y elementos de redes sociales.

La COMUNIDAD de DESARROLLADORES

21

• El mantenimiento y desarrollo de las herramientas tecnológicas vertebradoras de la generación de capacidades y transformación turística en la Comunitat Valenciana, debe convertirse en una fuente de oportunidades y no en una lucha permanente contra la presión de la obsolescencia de la misma.

• Esta oportunidad tiene un eje de impacto en el sector, que podrá seguir apalancando nuevas dinámicas de cambio orientadas a mejoras de competitividad y rentabilidad mediante desarrollos tecnológicos adicionales.

• Una implantación amplia (que genere una mínima masa crítica), un modelo de participación y acceso al código, y un buen sistema de incentivos nos permitiría desarrollar una comunidad global de desarrolladores y profesionales turísticos como embrión de una plataforma de conocimiento práctico con una clara vocación de liderazgo nacional y mundial. Esta comunidad podrá:

1. Desarrollarse sobre una existente tipo “Ruby on Rails” (*)

2. Ser una creación propia que surja dentro del Invat·tur y se expanda desde ahí

3. Ser el embrión de una red de comunidades a desarrollar en diferentes destinos

(*) Entorno de desarrollo tecnológico basado en código abierto que se ha convertido en un importante estándar y ha dado lugar a un pujante comunidad de desarrolladores en las más diversas áreas y sectores. www.rubyonrails.org.es

El proyecto OPENAPPS y el INVAT·TUR

22

INVAT·TUR se convertirá en elInstituto de referencia en investigación, innovación y tecnologías aplicadas al Turismo.

El liderazgo del proyecto OpenApps –junto a otras iniciativas– hará que INVAT·TUR sea reconocido nacional e internacionalmente por su contribución en el desarrollo de soluciones tecnológicas que favorezcan la anticipación y adaptación del sector turístico de la Comunitat Valenciana a los cambios del mercado.

Además del carácter vanguardista de los servicios prestados y la identificación y desarrollo de líneas de I+D+i en Turismo.

INVAT·TUR – OBJETIVOS (I)

• Generar y transferir conocimiento al ámbito del Turismo.

• Desarrollar líneas de actuación en I+D+i adaptadas a las necesidades del sector turístico.

• Favorecer una cultura de innovación en la gestión turística.

• Favorecer la colaboración de instituciones públicas y privadas en el desarrollo de actuaciones de I+D+i.

• Desarrollar una inteligencia de mercados útil para la toma de decisiones en el ámbito de la gestión turística.

23

INVAT·TUR – OBJETIVOS (II)

• Facilitar la anticipación/adaptación de la oferta turística valenciana a las tendencias del mercado turístico.

• Transferir conocimiento a las empresas y organizaciones turísticas, facilitando el acceso de todo el sector turístico a los conocimientos, servicios y tecnologías más avanzados.

• Colaborar con organismos públicos y privados de investigación de diferentes ámbitos geográficos en actividades de I+D+i.

• Reforzar la presencia del turismo en los programas de investigación básica y aplicada.

24

INVAT·TUR – ÁREAS DE ACTUACIÓN (I)

Inteligencia de mercados: se dirige a generar un mayor grado de conocimiento, cuantitativo y cualitativo, de los mercados turísticos.

Vigilancia tecnológica: analizar las posibilidades de adaptación al turismo de las novedades tecnológicas, transferencia de la información al sector y contribuir a la aplicación de innovaciones que repercutan positivamente en la oferta turística valenciana.

Apoyo a la I+D+i: generación y puesta en marcha de una serie de programas de apoyo a la I+D+i.

Proyectos: desarrollo de proyectos de I+D+i de manera autónoma o en colaboración con otros centros de investigación y las empresas turísticas.

25

INVAT·TUR – ÁREAS DE ACTUACIÓN (II)

Internacionalización: se integrará en redes y proyectos internacionales con relevancia para el sector turístico valenciano.

Comunicación, cooperación, y transferencia de resultados: se pretende realizar un intercambio permanente de información con el sector con la finalidad de detectar necesidades y transferir resultados, apoyado por la creación de un entorno profesional 2.0.

26

PLAN DE ACCIÓN – Principios Generales

• El proyecto OpenApps – Invat·tur se desarrollará a lo largo de los años (2010 - 2011), y debe ser una iniciativa sectorial en la que todos los agentes de la Comunitat Velenciana hagamos un ejercicio de liderazgo, reinvención, colaboración y participación, de forma responsable, continuada y con el máximo nivel de compromiso, a la altura de los desafíos y oportunidades que tenemos por delante.

• Es por ello que en esta “Fase 0" de definición del proyecto (Oct-Dic 2009) dedicaremos todos nuestros esfuerzos a informar sobre conceptos, objetivos y alcance del proyecto, y a involucrar a líderes sectoriales, profesionales del sector e instituciones con responsabilidad turística, con el fin de recabar consideraciones, requerimientos, sugerencias, enfoques, que se puedan incorporar al proyecto para que, de forma efectiva, este sea una verdadera palanca de transformación y reinvención de nuestro sector que nos permita un liderazgo sólido para los próximos años.

27

PLAN DE ACCION – Líneas Generales

El plan de acción se desarrollará en la siguiente secuencia:

28

CUESTIONES CLAVE – ÁREA de PARTICIPACIÓN

29

PREGUNTAS

• ¿Áreas de atención inmediata para la competitividad y rentabilidad del destino y de cada subsector?

• Si tuviera toda la financiación necesaria, ¿qué acciones de promoción, marketing y fidelización, ventas y tecnología priorizaría?

• El CONOCIMIENTO Turístico Valenciano como activo estratégico, ¿cómo lo convertimos en algo vivo, enriquecedor y exportable?

• ¿Qué aspectos y estrategias de gestión prioriza en su negocio? ¿dónde considera que ha de mejorar el sector en este sentido?

• ¿Qué oportunidades y amenazas ve en la aplicación de estas tecnologías a su negocio?

30

CONTACTO

Con el fin de gestionar y dar respuesta a sus dudas, sugerencias, comentarios y planteamientos de una forma continua y directa a lo largo de esta FASE 0 del proyecto, ponemos a su disposición la dirección de correo:

[email protected]

31

Tourism Revolution @ Work

www.comunitatvalenciana.com

www.ithotelero.com

www.mindproject.net

http://www.comunitatvalenciana.com/

http://www.ithotelero.com/

http://www.mindproject.net/

2

ÍNDICE DE CONTENIDOS

Página

1. Introducción 3

2. Metodología y objetivos 4

3. Aplicaciones de Software Abierto 6

3.1. Solución estratégica 7

3.2. Comunidades de desarrollo 8

4. Elementos de Software 12

4.1. Visión Global 12

4.2. Sistemas de Central de Reservas 14

4.3. Sistemas de Gestión 18

4.4. Sistemas de Gestión de Canales 21

4.5. Sistemas de Creación y gestión de páginas Web 24

4.6. Orquestador 26

5. Elementos de Hardware 29

5.1. Servidores 29

5.2. Conectividad 30

5.3. Ordenadores 30

6. Opciones de gestión y desarrollo 30

6.1. Software como producto 30

6.2. Software como servicio (SaaS) 33

6.2.1. SaaS público 34

6.2.2. SaaS privado 36

6.2.3. SaaS privado + código público 39

6.3. Comparativa de opciones 41

7. Plan de Trabajo Tech 2010-2011 42

Anexo 1. Aportaciones Workshops 45

Anexo 2. DAFOS de Alternativas TECH y estimaciones costes 54

3

1. Introducción

Este documento define la estrategia tecnológica del proyecto OpenApps, con el

enfoque de impulsar y dinamizar una tecnología que vertebre la transformación

del modelo competitivo turístico de la Comunidad Valenciana. Una transformación,

que parte por dar respuesta inmediata a las necesidades a corto plazo de

comercialización y distribución de las empresas turísticas, para que

posteriormente sirvan como generadoras de las nuevas dinámicas que se

requieren en el escenario turístico actual.

Nuevas dinámicas que deben poner en valor la diversidad turística como fuente de

ventaja competitiva para la diferenciación, así como la personalización y creación

de productos turísticos de alto valor añadido. Esto implica, especialmente,

capacidad de conexión e interrelación entre la oferta para el desarrollo e impulso

de la “larga cola” de la distribución del producto turístico valenciano. Para ello, es

preciso entender a la tecnología y, en concreto a Internet, como el espacio

relacional que va a permitir generar las dinámicas basadas en la cooperación y

colaboración que se necesitarán en este nuevo modelo competitivo.

En este sentido, la atomización y fragmentación del sector turístico, una debilidad

en el modelo competitivo actual, debe tener a la tecnología del proyecto OpenApps

como vertebrador para transformar esa debilidad en una fortaleza que haga

irrelevante la oferta de los destinos emergentes que compiten vía precios y hagan

de la conexión múltiple entre las empresas “fragmentadas”, un poderoso escenario

competitivo, diverso y personalizado, imposible de “copiar”.

De esta forma, es preciso enfatizar que la importancia del proyecto no radica en la

tecnología, sino en su uso e implantación en TODO el sector turístico y, por

supuesto, en su capacidad para maximizar la conectividad entre todas las

empresas y los canales de distribución.

En definitiva, este documento se convierte en la guía estratégica de cómo la

tecnología del proyecto OpenApps se puede y debe convertir en la gran estructura

que canalice y posibilite la transformación del Ecosistema Turístico de la

Comunidad Valenciana.

4

2. Metodología y objetivos

Según el convenio firmado por la Agencia Valenciana de Turismo, el Invat.tur, el

ITH y MindProject, se definieron como objetivos tecnológicos del proyecto, los

siguientes:

• Definir los puntos estratégicos que ayuden a mejorar la competitividad del

sector turístico valenciano e impulsar la comercialización de la oferta del

sector en Internet

• Hacer extensiva la solución tecnológica al mayor número y diversidad de la

oferta turística: alojamiento, vuelos y transportes, agencias de viaje,

servicios de ocio, cultura y actividades, restauración, etc

• Seleccionar las herramientas adecuadas y garantizar su evolución a bajo

coste.

• Desarrollar la descripción funcional, técnica y de arquitectura de las

aplicaciones objeto del proyecto.

• Ofrecer las máximas garantías de que los objetivos que se definan sean

alcanzables en el espacio de tiempo establecido.

• Establecer las bases para el desarrollo de una comunidad de profesionales y

una comunidad de desarrolladores

Para desarrollar una estrategia tecnológica y guía de acciones, se estableció una

metodología basada en:

• Análisis

• Comparativa

• Opciones de desarrollo

• Toma de decisiones

• Plan de acción

Para las distintas fases, se usaron las siguientes fuentes:

• Documental.

5

Para la misma se analizaron la documentación del proyecto y

documentación secundaria proveniente de las fuentes accesibles en

Internet.

• Trabajo con el sector

Estructurado a través de 9 workshops sectoriales:

o Hoteles

o Agencias de Viajes receptivas

o Agencias de Viajes emisoras

o Restauración

o Apartamentos

o Campings

o Instituciones turísticas

o Alojamientos rurales

o Oferta complementaria

y 4 sesiones especiales con los subsectores de:

o Restauración

o Agencias receptivas (x2)

o Campings

Además, se ha trabajado con una Comunidad Online

(www.openappsinvattur.ning.com), que ha servido de espacio de relación

permanente. La Comunidad cuenta con 167 personas inscritas.

Las aportaciones de estos trabajos con el sector, se encuentran recogidos en

el Anexo 1

• Comunicaciones con expertos

Dado el carácter innovador y pionero del proyecto, se ha optado por incluir

un proceso de carácter cualitativo que permita al equipo director del

proyecto asentarse y reflexionar conjuntamente con un grupo de expertos

sobre los posibles escenarios óptimos para el desarrollo del OpenApps.

Los expertos consultados han sido:

6

o Pablo Deeleman. Ingeniero Superior. Project Manager y Consultor de

Negocios electrónicos de Koalab

o Andrés Karp. Project Manager y Community Manager de Dinamiclab.

Presidente de la Asociación de Desarrolladores Web de Alicante.

o Dr. Jacques Bulchand. Ingeniero Superior Informático. Profesor de

Sistemas de Información de la Universidad de Las Palmas de GC. Ex

director de la Oficina de Software Libre de la ULPGC.

o Cristina Jiménez. Ingeniero Superior Informático. Directora Técnico

de Desarrollos Tecnológico E-pyme

o Dr. José Juan Hernández. Ingeniero Superior Informático. Profesor de

Programación de la Universidad de Las Palmas de GC

o Dr. Sergio Alonso. Matemático especializado en Ciencias de la

Computación. Director de la Oficina de Transferencia de Resultados

de Investigación de la Universidad de La Laguna y director del

departamento de Promoción y Gestión de la Innovación de la

Fundación Empresa Universidad de La Laguna.

3. Aplicaciones de Software Abierto

El software o código abierto es el término con el que se conoce tradicionalmente al

software distribuido y desarrollado libremente. No debe confundirse este concepto

con el desarrollo de aplicaciones a partir de software libre. En definitiva, no es lo

mismo desarrollar software abierto que desarrollar aplicaciones con software

abierto. La vocación de este proyecto es la de construir un marco de aplicaciones

de promoción y distribución turística (en adelante OpenApps) que,

independientemente del entorno con el que éste se desarrolle, cumpla los

siguientes requisitos:

• OpenApps debe poder ser redistribuido o incluso comercializado

libremente.

• El código fuente de OpenApps se encuentra disponible y accesible

públicamente, sin coste.

7

• Se pueden desplegar trabajos o aplicaciones derivadas a partir de

OpenApps que también puedan ser redistribuidos.

• Las redistribuciones de modificaciones o módulos integrables en OpenApps

desarrollados por terceros puedan ser distribuidos libre o comercialmente,

sin perjuicio de que el código fuente original permanezca libremente

disponible de forma gratuita.

• La licencia de OpenApps no debe restringir otro software: No se puede

obligar a que algún otro software que sea distribuido con OpenApps deba

también ser de código abierto.

• No se podrá efectuar discriminación alguna a que cualquier persona o

grupo pueda obtener, modificar o redistribuir, comercialmente o no, su

propia versión de OpenApps.

Estas líneas maestras definen la esencia de OpenApps como marco de aplicaciones

turísticas de código abierto, en donde lo relevante no es cómo se ha desarrollado el

núcleo de dicho marco, sino la disponibilidad y accesibilidad total e ilimitada al

mismo por parte de cualquiera que así lo desee: agentes turísticos,

desarrolladores, investigadores, etc.

3.1. El Software Abierto como solución estratégica

La opción del desarrollo de un proyecto que se base en Software Abierto, no es

una propuesta basada en modas o en marketing. Lo que subyace a ese

concepto, tiene la base de ser una respuesta estratégica a cuatro necesidades

clave:

• Anti-obsolescencia tecnológica: Las funcionalidades de cualquier

aplicación de promoción o comercialización turística muestran un elevado

riesgo de obsolescencia, así como de inadaptación a las necesidades y

expectativas sectoriales fruto del mero paso del tiempo. El desarrollo de un

marco de herramientas de software turístico, sustentado en una base de

código abierto libremente disponible, y apoyado en una comunidad de

desarrolladores, evangelizadores y entusiastas, garantiza el

8

enriquecimiento del mismo con un caudal permanente de nuevas

aportaciones, mejoras y adaptaciones tecnológicas y funcionales. Dichas

aportaciones prolongan la vida útil y el retorno de inversión de dicho marco

de aplicaciones turísticas en un contexto de constante readaptación al

mercado, garantizando la permanencia en la vanguardia de la promoción y

distribución turística a sus usuarios.

• Utilidad competitiva: La tecnología y el código en sí mismo no aportan

valor. La capacidad de lograr que estos realmente sean implementados,

usados y mejorados por la mayor cantidad de empresas supondrá el éxito

de OpenApps. Un marco de aplicaciones de software turístico de código

abierto libremente accesibles y redistribuibles abre la puerta a que un

sinfín de usuarios, agentes turísticos, integradores y tecnólogos apoyen y

promuevan la integración de OpenApps en el tejido empresarial, actuando

como evangelizadores independientes de éste a nivel formativo, consultivo

y de soporte. Ello redunda además en una oferta aún más amplia de

proveedores y recursos a disposición del mercado.

• Innovación: La capacidad de generar nuevas aplicaciones, no planificadas

por el proyecto, que permitan innovaciones permanentes, se logra con una

propuesta de desarrollo funcional ágil y sencillo por una comunidad de

desarrolladores con visión emprendedora, siendo esto posible únicamente

al eliminar las barreras de entrada, transformación y redistribución al

código y elementos que conforman OpenApps. Todo ello puede dar lugar a

un ecosistema de aplicaciones inéditas e innovadoras no previstas en la

concepción y funcionalidad original del proyecto.

• Conocimiento: La capacidad de generar conocimiento útil y eficiente para

la mayor cantidad de empresas en su toma de decisiones, se puede lograr

en base a Aplicaciones Abiertas

Por lo tanto, dar respuesta a estas cuatro necesidades, serán los objetivos de la

forma en la que orientar la apertura del proyecto OpenApps.

9

3.2. Comunidades de desarrollo

Cualquier proyecto de aplicaciones abiertas requiere de Comunidades para su

correcto desarrollo. Es decir, de estructuras colaborativas donde grupos de

personas comparten elementos en común, y de la cual nace una identidad

común que socializa a sus miembros. Es importante entender el concepto de

Comunidad para aceptar la dificultad que conlleva la creación y puesta en

marcha de una. La proliferación de herramientas online de Comunidades

distorsionan el valor real de las mismas, que no radica en el medio en con el

que se conectan, sino la identidad que les une. Por ello, las Comunidades

conllevan un comportamiento y gestión de socialización que debe ser tenida en

cuenta para saber qué tipo de Comunidad es la óptima para dar respuesta a los

objetivos del proyecto, asegurando el mayor éxito del mismo.

En el desarrollo de aplicaciones abiertas, podemos diferencias dos tipos de

comunidades de desarrollo:

• Según el objeto compartido:

• De código fuente: lo que se comparte es el código integro de las

aplicaciones, para la creación de nuevas. Si bien su flexibilidad es

total, el trabajo con el mismo conlleva un nivel de conocimiento

mucho mayor el alcance y el impacto de una Comunidad es menor.

Así como la mayor dificultad de desarrollar la Comunidad con un

nivel de éxito considerable. Los retos de dinámicas asociados a

involucrar a un grupo de programadores para trabajar sobre un

código específico, son de una complejidad muy alta y, quizás no sean

alcanzables a proyectos turísticos. Sin descuidar esta opción, no

debería de ser el centro de desarrollo del proyecto OpenApps, por el

bajo impacto a corto y la alta complejidad y dificultad de éxito a

largo.

• De aplicaciones: se comparte un interfaz de programación (API), lo

suficientemente versátil para que se generen nuevas aplicaciones de

forma permanente por un grupo de programadores, que necesitan

menos tiempo, recursos y conocimiento, lo que mejora el impacto y

alcance en el corto plazo. Además, con esta perspectiva, permite

10

generar dinámicas de incentivo y formación más accesible, que

permita la generación, gestión y dinamización de una Comunidad de

desarrolladores. En este sentido, este enfoque es el que entendemos

principal para el éxito y liderazgo del proyecto OpenApps.

• Según el ciclo de vida:

• Comunidades ad hoc: son comunidades que se crean e impulsan para

un proyecto en concreto. Conllevan una dificultad y complejidad muy

alta, que no siempre puede ver sus frutos, por no siempre

correlacionarse los objetivos de los promotores con los de la

Comunidad. No obstante, permite amoldar desde el principio la

orientación de la Comunidad y, si ésta es aceptada por los miembros,

se logra un paso muy importante en su evolución.

• Comunidades existentes: con ellas, se minimiza el coste y dificultad

de la gestión de lograr dinámicas de Comunidad (que pocas veces se

logran), por formar parte de Comunidades que ya existen y que

mantienen esa dinámica. En este caso, el reto consiste en incluir el

objeto del proyecto en las dinámicas actuales, y que los usuarios la

acepten.

Dentro de las aplicaciones que debe contener la Comunidad de OpenApps,

definimos:

1. Wiki formativa, conteniendo tanto información destinada a integradores

como a partners comerciales.

2. Blogs, con la posibilidad de que integradores y evangelizadores puedan

abrir el suyo propio, cohabitando con los blogs de los propios

evangelizadores institucionales.

3. Foros de discusión, habilitando espacios de discusión comercial,

empresarial y técnica, con una especial atención a la dinamización por parte

de los Community Managers de la agencia delegada de la gestión del

proyecto cuyo objetivo será precisamente crear agentes activos en la

audiencia existente. En definitiva, convertir a los participantes en agentes

de soporte.

11

4. Centro de conocimiento, orientado exclusivamente a servir de repositorio

de respuestas rápidas a las cuestiones más frecuentes en la integración

comercial o técnica del proyecto, pero cuya relevancia les merece la

presencia en un espacio propio de referencia rápida.

5. Descarga de documentos técnicos, permitiendo la descarga (y por tanto

redistribución y viralización) de documentos y manuales detallados

orientados especialmente al ámbito de integradores.

6. Programa de calificación, ofreciendo la posibilidad de optar a un

distintivo de calidad, a modo de certificación de conocimiento y

compromiso, a los agentes más activos de la comunidad, generando

reputación y significación en el ámbito de la propia comunidad y en la

proyección empresarial de cada uno, en la línea del programa MVP (Most

Valuable Professional) de Microsoft.

7. Descarga de código, centralizando en la propia comunidad el acceso a las

últimas distribuciones de código habilitadas, incluyendo el correspondiente

changelog e issue tracker. Naturalmente la descarga debe poder integrarse

con los principales sistemas de repositorio y control de versiones actual,

con especial atención a GIT y Subversión.

8. Noticias, si bien esta sección puede sobrellevarse desde uno de los blogs,

con vocación de oficialidad, que integren el ecosistema de bitácoras de la

comunidad.

Puesto que un objetivo de OpenApps es convertirse en un estándar

internacional, se debe buscar una fórmula mixta que desarrolle una Comunidad

con dinámicas existentes y “ajenas” al concepto territorial de la Comunitat

Valenciana (para maximizar su aceptación nacional e internacional), pero que

cree el “hub” más importante y promotor a raíz del proyecto y con la marca

OpenApps by Invattur. De esta forma, como veremos en el estudio de la opción

seleccionada, OpenApps (como marca del Invattur) debe asociarse o promover

alguna Comunidad global y ser el principal impulsor e incentivador de que la

Comunitat Valenciana y sus programadores sean los desarrolladores más

dinámicos, a fin de que las aplicaciones promovidas por Invattur dentro de ese

entorno, sean las más usadas a nivel mundial.

12

4. Elementos de Software

En este apartado, vamos a describir el software inicial del proyecto OpenApps,

desde una perspectiva global de utilidad al sector turístico. Posteriormente, nos

centraremos en los sistemas más relevantes, para hacerles una descripción técnica

y funcional que permita a cualquier profesional turístico entender la importancia y

objetivo del mismo desde una visión global. Posteriormente, a modo de ayuda para

entender el contexto actual de aplicaciones, aportamos unas comparativas de

tipologías de aplicaciones. Dicha comparativa, se basa en tipos de software que

tienen una funcionalidad estratégica distinta que puede ser relevante en la toma de

decisiones del apartado 6. Cada tipología la hemos representado con una marca

comercial para ayudar a la visualización de las opciones por parte del lector. No

necesariamente son esas marcas las propuestas para formar parte del OpenApps,

pues dicha selección deberá hacerse en una fase posterior en base a las opciones

de desarrollo elegidas y a criterios y apuestas tanto tecnológicas como de mercado.

4.1. Visión Global

La propuesta de valor inicial que el software de OpenApps aportará al sector

turístico, se basa en:

• Permitir el acceso a la comercialización propia, con página Web, de

TODAS las empresas turísticas de la Comunitat Valenciana.

• Permitir el acceso a la comercialización conjunta de TODA la oferta de la

Comunitat Valenciana, tanto por producto como por destino.

• Minimizar los costes de acceso y oportunidad para la máxima

distribución en todos los canales posibles de TODA la oferta de la

Comunitat Valenciana.

• Permitir una gestión del cliente y del conocimiento, profesional y

competitiva, a TODAS las empresas turísticas de la Comunitat

Valenciana.

13

Para ello, el software se orquestará sobre 4 sistemas técnicos y funcionales

fundamentales:

• Sistema de Centrales de Reservas (CRS): en el gráfico descrita como

“Agrupaciones de Producto, Centrales de Reservas Destino y

microdestinos”

• Sistema Gestión (PMS + CRM + BI): en el gráfico descrita como “Gestión

de Producto”

• Sistema de Gestión de Canales (Consolidador B2B + Channel Manager):

en el gráfico descrita como “Distribución a través de Canales externos”

• Sistema de Creación de Páginas Web Avanzadas (CMS + e-Commerce):

en el gráfico descrita como “Distribución Directa”

14

4.2. Sistema de Central de Reservas

Las Centrales de Reservas, CRS por sus siglas en inglés (Central Reservation

Systems), son sistemas que centralizan las ventas de diversas unidades de

negocio (normalmente hoteles) en un mismo interfaz, normalmente una web.

Los CRS son usados normalmente por las cadenas hoteleras para vender

conjuntamente sus propios hoteles. A medida que Internet ha ido

transformando el mapa de la distribución turística, otros actores, como los

propios destinos, han ido incorporando CRS en sus políticas de

comercialización. Para ello, se requieren sistemas más flexibles y dinámicos

15

que permitan trabajar no sólo con una tipología de negocio, sino con toda la

diversidad de un destino (alojamientos, restauración, alquileres, ocio,…).

A su vez, la transformación del escenario competitivo del turismo, que se

orienta hacia la búsqueda de la diferenciación y personalización, está haciendo

que la creación de productos temáticos –predefinidos o personalizados ad hoc-

sea una apuesta necesaria para cualquier estrategia de destino turístico.

De esta forma, el proyecto OpenApps no puede únicamente plantear el

desarrollo de un sistema de CRS tradicional, sino que debe adelantarse a las

tendencias que le permita dar un paso de mejora competitiva. Así, el sistema de

CRS que se propone para el proyecto, deberá contemplar la posibilidad de:

• Ser multidestino

• Ser multiproducto

• Permitir las ventas cruzadas de diferentes servicios turísticos

• Permitir la comercialización de los propios servicios turísticos

Esto nos hace describir un CRS para OpenApps, que se estructure como un

agregador de base de datos, y que permita conectar y combinar la oferta en

distintas web que actúen, bien como CRS o bien como Web propia (que

veremos en el punto 4.5). Por lo tanto, no es estratégicamente un avance el

desarrollo de una única Central de Reservas, sino en el logro de un Conector de

Oferta que permita el desarrollo de múltiples, diferentes y personalizadas

Centrales de Reservas.

16

Las Centrales de Reservas, normalmente desde una extranet propia alojada en

una URL, gestionan la información que cada unidad de negocio, de forma

manual, oferta a la venta. Esta información suele ser:

• Tarifas de las habitaciones/servicios

• Cupos de las habitaciones/servicios

• Tipos de las habitaciones/servicios

• Disponibilidad de las habitaciones/servicios (incluyendo la política de

release, uso/estancia mínima y máxima, ocupación requerida, etc.)

• Información genérica del establecimiento turístico o unidad de negocio

• Características de las habitaciones/servicios

• Modalidad de pago de las habitaciones/servicios (depósito previo, pago

íntegro anticipado, pago a la llegada, pago a la salida)

• Información sobre la reserva

• Información de geolocalización

• Información del destino

17

No obstante, como veremos en el siguiente apartado, es objetivo del proyecto

tener integrado este proceso desde el propio sistema de gestión, evitando

cualquier acción manual en el CRS.

Para estudiar las opciones actuales que hay en el mercado, proponemos tres

sistemas que describen tres tipologías y modelos de CRS:

• Tipo 1, Kubik. Describe a los software de sistemas de reservas hoteleros

desarrollado por empresa privada, implementado en sistemas como

Flamingo Hoteliers. Otras aplicaciones de este tipo: OpenRMS

• Tipo 2, Destinum. Describe a los software de generación dinámica y

cruzada de centrales de reservas multiproducto.

• Tipo 3, Segittur. Describe a los software de centrales de reservas

multiproducto y desarrollado de forma pública.

La comparativa la hacemos en base a los siguientes parámetros:

• Posibilidad de Software Libre (SL). Describe si el CRS puede ser liberado

y ofrecido como SL en la aplicación resultante de OpenApps

• SaaS (Software as a Service). Describe si el CRS puede ser ofrecido como

servicio y, por consiguiente, permitir que su difusión e implementación

en el sector sea máxima

• Multiproducto. Describe si el CRS admite todo tipo de unidades de

negocio y sus combinaciones o sólo una tipología, como alojamientos.

• Multidestino. Describe si el CRS admite la creación de combinaciones de

distintos ámbitos territoriales

• Venta cruzada. Describe si el CRS admite la posibilidad de combinar la

venta de empresas entre ellas mismas

• Creación autónoma de CRS. Describe si el CRS permite la creación de

múltiples CRS de forma sencilla y sin necesidad de programación.

• APIs. Describe si el CRS ofrece la interfaz de programación para poder

desarrollar aplicaciones sobre ella.

18

Posibilidad

Software

Libre

SaaS

Multiproducto

Multidestino

Venta

Cruzada

Creación

autónoma

de CRS

APIs

Tipo 1 Sí No No Sí No No Sí

Tipo 2 Sí Sí Sí Sí Sí Sí Sí

Tipo 3 No Sí Sí Sí No No No

4.3. Sistemas de Gestión (PMS + CRM + BI)

Los sistemas de gestión tradicionales del sector turístico son los Property

Management Systems (PMS). No obstante, se circunscriben principalmente al

subsector hotelero. Estos sistemas, de una complejidad y estructuración muy

alta, son desarrollados por numerosas compañías de forma internacional,

existiendo una alta variedad de los mismos. Son sistemas fundamentalmente

costosos para los hoteles, donde pivotan toda su gestión y, sobre todo, son

sistemas propietarios cerrados, con un alto (por no decir imposibilidad en la

mayoría de los casos) coste de apertura. Es decir, los PMS son sistemas que

nacieron, al igual que los GDS, hace ya más de dos décadas, y han ido

evolucionando sobre su propia estructura, en muchos casos altamente rígida y

que por ello no han logrado ir a la misma velocidad que el sector.

La función principal de los PMS es la gestión del inventario de las habitaciones

(en los casos de los hoteles), de los clientes y los ingresos en los distintos

puntos de venta del hotel. Normalmente, suele incorporarse un CRM (Customer

Relationship Management) para una mejor gestión de la relación con los

clientes y, cada vez más, sea hace necesario la incorporación de un sistema de

Inteligencia de Negocios (BI, Business Intelligence) que permita el

conocimiento del mismo de una forma competitiva.

19

Un proyecto como OpenApps, que no se orienta únicamente al subsector de

hoteles, sino que tiene el objetivo de dotar de las capacidades tecnológicas a

TODAS las empresas turísticas, debe de valorar la forma óptima que permita

incorporar un sistema de gestión adaptado a todos. Y sobre esto, tener la

posibilidad de conectar cualquier otro sistema actual, ya implantado en las

empresas, al Conector de Oferta (CRSs) de OpenApps.

Dentro de la gama de PMS, no hemos encontrado ningún sistema libre que nos

permita hacer un planteamiento de opción sobre el mismo. De esta forma, y

teniendo en cuanta que las necesidades de gestión de la inmensa mayoría de las

empresas no requieren de más de un 10% de las funcionalidades de un PMS

estándar, entendemos que el Sistema de Gestión ideal para OpenApps debe ser

desarrollado como evolución e integración de algún otro sistema.

Además, tenemos que sí existen interesantes software de CRM y BI que pueden

ser un complemento perfecto y acelerar considerablemente la creación y

desarrollo de un Sistema de Gestión óptimo para OpenApps. En concreto,

algunas aplicaciones CRM pueden ser Sugar CRM, OpenBravo, Compiere,

20

OpenCRX e Hipergate. Aplicaciones Business Intelligence, especial relevancia

tiene Pentaho.

Puesto que no tenemos constancia de aplicaciones adaptadas a convertirse en

el Sistema de Gestión de OpenApps, valoramos dos opciones de desarrollo:

• Tipo 1, Sistemas de Gestión Genéricos: sistemas ERP, que permitan la

adaptación a las particularidades de gestión turística a la que se le

añaden CRM + BI. Compararemos esta tipología usando el caso de

OpenERP.

• Tipo 2, Sistemas de Gestión Turísticos: que nacen de los CRS (ver

apartado anterior) que permitan la evolución de funcionalidades básicas

que lo conviertan en un Sistema de Gestión lo suficientemente óptimo

para la mayoría de las empresas y al que se le añaden CRM + BI.

Aunque tratamos de forma integrada (PMS+CRM+BI) en OpenApps el concepto

de “Sistema de Gestión” para un mayor entendimiento global, es de destacar

que ambas opciones que se presentan deben ser modulares, pudiendo conectar

por separado tanto el PMS, el CRM y el BI. Es decir, se propone una solución

modular conectada (y que permita conectarse con otras aplicaciones

existentes), no integrada.


• Flexibilidad. Describe si el Sistema de Gestión es lo suficientemente

flexible para adaptarse a cualquier requisito

• Coste. Describe el nivel de coste que tiene el desarrollo del Sistema de

Gestión.

• Tiempo. Describe la duración que tiene el desarrollo del Sistema de

Gestión.

• Posibilidad de Software Libre (SL). Describe si el Sistema de Gestión

puede ser liberado y ofrecido como SL en la aplicación resultante de

OpenApps

• APIs. Describe si el Sistema de Gestión ofrece la interfaz de

programación para poder desarrollar aplicaciones sobre ella.

21

• SaaS (Software as a Service). Describe si el Sistema de Gestión puede ser

ofrecido como servicio y, por consiguiente, permitir que su difusión e

implementación en el sector sea máxima

Flexibilidad

Coste

Tiempo

Posibilidad

Software

Libre

APIs

SaaS

Tipo 1

5

4

4

Sí

Sí

Sí

Tipo 2

3

2

2

Sí

Sí

Sí

(0=muy baja; 5=muy alta)

4.4. Gestión de Canales (Consolidador B2B + Channel Manager)

Los canales turísticos son la forma que tiene las empresas turísticas de

distribuir de forma amplia su oferta. Existen multitud de canales, aunque

podemos enfocar la descripción en:

• Agencias de Viajes Onlive (las tradicionales cuyo negocio es presencial),

• Agencias de Viajes Online,

• IDS (Internet Distribution System), que se encargan de distribuir la

consolidación de oferta que se hace previamente -bien por

consolidadotes online, TTOO o bien por Agencias Receptivas- en

distintos actores u otras agencias de viajes.

Una de las grandes transformaciones que ha impulsado Internet y el nuevo

mapa de la distribución turística es la minimización del coste de oportunidad

que se deriva del cupo. Esta práctica, habitual y necesaria hasta nuestros días,

no hace más que alinear las estrategias del sector a la concentración y a acuciar

la debilidad de los más pequeños. Algo paradójico cuando la estrategia

aceptada de mejora de nuestra competitividad en relación a destinos

22

emergentes es la huída de la estandarización y la puesta en valor de la

diversidad, diferenciación y personalización. Por este motivo, el minimizar el

coste de oportunidad originado por los cupos y hacer accesible a TODAS las

empresas la posibilidad de ser vendido por cualquier canal, fomentando así la

“larga cola” de la distribución y de la creación de producto turístico, no es una

funcionalidad más, sino que es un eje fundamental para la mejora de la

competitividad del destino y para poder reorientar la política de producto

hacia una de valor añadido.

Por la amplia y variada tipología de la oferta objeto de OpenApps, hemos

diferenciado dos procesos de Gestión de Canales complementarios:

• Consolidación B2B (o modelo de distribución PULL) para la

contratación de oferta turística por parte de Agencias de Viajes, sobre

todo aquellas de menor tamaño que les ayude a orientar sus propias

estrategias de negocio hacia la segmentación y personalización. Dicha

contratación la hemos planificado de dos formas:

o Manual para la contratación por parte de las Agencias Onlive,

donde acceder a la venta de producto turístico diverso.

o Automatizado por XML para las Agencias de Viajes Online, que

quieran incorporar la variedad de la oferta turística que

actualmente no se encuentra disponible en ningún canal de

distribución.

El consolidador B2B, debe ser una funcionalidad conectada en el

Conector de Oferta, activándose en base a nuevos perfiles propios

relacionados con los Agentes de Viajes.

• Channel Manager (o modelo de distribución PUSH) para gestionar la

distribución de la oferta que cada empresa ya haya negociado con sus

IDS, para poder actualizar y gestionar toda la información en una única

vez y desde su mismo propio entorno de gestión. Las conexiones con los

IDS pueden hacerse de dos formas:

23

o Tipo 1: conectadas directamente con el Conector de Oferta

o Tipo 2: a través de sistemas de terceros como Travelclick, Dingus

o Booking Booster

Ambas opciones son complementarias, siendo la conexión directa,

óptima para los principales IDS y optando por los sistemas de terceros

para poder a conectarse al máximo número de IDS restantes. Los

sistemas de terceros llevan emparejados costes adicionales que pueden

ser fijos (por unidades de negocio conectadas) o variables (un % sobre

transacción). Aunque este requisito debe ser negociado y OpenApps

puede ser un negociador por volumen, la opción del coste fijo

(aproximadamente 150€ mes/unidad de negocio) es una barrera muy

alta para la mayoría de las empresas. El coste variable puede rondar en

torno al 3% de las transacciones.

En la comparativa, incluimos la posibilidad de conectar directamente,

junto con tres servicios externos, y la hacemos en base a los siguientes

parámetros:

• Coste OpenApps. Describe el nivel de coste que tiene activar el

desarrollo de activación de la conexión de cada canal.

• Coste empresas. Describe el nivel de coste que tiene cada una de

las empresas conectadas al Channel Manager.

• Tiempo. Describe la duración que tiene activar el desarrollo de

activación de la conexión de cada canal.

Coste

OpenApps

Coste

empresas

Tiempo

Tipo 1

3

0

3

Tipo 2

2

3

2


24

4.5. Sistema de Creación y gestión de páginas Web (CMS + e-Commerce)

Aunque la presencia en Internet es cada vez más distribuida y no depende de

una web para poder informar, comunicar y distribuir por la Red, sí se precisa

que cualquier empresa pueda tener su propio escaparate online y poder vender

en el mismo sus productos. Algo que aún, en la mayoría de las empresas

turísticas, queda muy lejos.

Para ello, se requiere de Sistemas de Creación y gestión de páginas Web de

forma sencilla y sin necesidad de programación. Son los Content Management

System (CMS) que trabajan bajo SaaS.

Estos CMS deben conectarse con el propio OpenApps para poder integrar en las

Webs los sistemas de reservas de las propias empresas y, en su caso, activar las

ventas cruzadas a través del Conector de Oferta.

25

Los CMS que deben formar parte del OpenApps, deben contener, al menos:

1. Creación de páginas a medida, customizables al 100% con el “look&feel” del

agente turístico en cuestión, pudiendo crear una estructura propia de

navegación "on the fly".

2. Posibilidad de edición de redirecciones y construcción de URLs “SEO-

friendly”.

3. Posibilidad de mostrar contenido multimedia propio.

4. Servicio de consumo y cacheo de librerías de cliente más comunes, con

objeto de acelerar el servicio de documentos mediante el repositorio

común, al estilo de Google Code.

5. Posibilidad de conectarse con el Conector de Oferta de OpenApps y el resto

de canales de forma directa

6. Soporte para la integración mediante subdominio seleccionable y/o desde

dominio propio mediante configuración de zona CNAME en servidor DNS

del agente turístico.

7. Protección SSL 128bits incluida (exclusiva para los agentes que integren su

servicio desde un subdominio, a través de un certificado wildcard).

8. Posibilidad de incorporar widgets de terceros, a través de una API pública.

26

Sistemas de CMS hay muchos libres, flexibles y de una altísima calidad. Vamos a

diferencias entre:

• Tipo 1: CMS globales, altamante extendidos como Wordpress, Joomla,

Magnolia, OpenCMS y Apache Lenya.

• Tipo 2: CMS específicamente turísticos, como Kubik o Destinum


• Flexibilidad. Describe si el CMS es lo suficientemente flexible para

adaptarse a cualquier requisito

• Coste. Describe el nivel de coste que tiene el desarrollo del CMS.

• Tiempo. Describe la duración que tiene el desarrollo del CMS.

• E-Commerce. Describe el nivel de incorporación de sistema de

comercialización turística integrado en el CRS

Flexibilidad

Coste

Tiempo

e-Commerce

Tipo 1

5

1

1

3

Tipo 2

2

1

1

5


4.6. Orquestador

Un orquestador es un software de conectividad (middleware) que permite que

funcionen distintas aplicaciones distribuidas, sobre plataforma diversas y

diferentes.

Aunque hemos ido enumerando los sistemas que componen OpenApps, la

estructura que permite la conexión y/o integración en su caso, es la del

Orquestador. Es decir, es el orquestador la “pieza” clave del sistema, que

27

además va a permitir desarrollar e incentivar un modelo de Comunidad de

aplicaciones.

Las funciones de un orquestador suelen ser diversas, desde la automatización

de procesos de negocio hasta la coordinación de servicios Web. El modelo de

orquestador, permite conectar los distintos sistemas, presentes y futuros, a

través de Web Services, haciendo irrelevante la heterogeneidad de las

plataformas a conectar. Esto permite una flexibilidad muy alta en la vida de

OpenApps, además que permite la consideración del mismo como un

“Marketplace” de los desarrollos de la Comunidad.

Esto indica que el sistema puede complementarse con cualquier sistema que

una empresa ya esté funcionando, en cualquiera de los cuatro sistema

descritos. Simplemente, se deben conectar a través de Web Services y se

podrán complementar perfectamente.

Para comparar orquestadores, planteamos dos opciones tipo:

o Tipo 1: Orquestador genérico, tipo JBPM, altamente flexible y muy

especializado en la gestión de procesos

o Tipo 2: Orquestador turístico, proveniente de la evolución de CRSs con

conexión con el resto de sistemas, tipo Destinum.


• Flexibilidad. Describe si el Orquestador es lo suficientemente flexible

para adaptarse a cualquier requisito

• Coste. Describe el nivel de coste que tiene el desarrollo del Orquestador.

• Tiempo. Describe la duración que tiene el desarrollo del Orquestador.

Flexibilidad

Coste

Tiempo

Tipo 1

5

3

3

Tipo 2

3

1

1


29

5. Elementos de Hardware

A continuación, hacemos unas propuestas técnicas, analizadas a fecha

Noviembre 2009, que deberán revisarse antes de implementación

5.1. Servidores

• Estado inicial (lanzamiento del proyecto, primeros 12-18 meses)

o Servidor de alta disponibilidad, con redundancia y sistema de

alimentación ininterrumpida.

o Procesador Intel® Xeon® E5502, 1.86Ghz, 4MB Cache, 4.86

GT/s QPI

o 8GB de Memoria para 1 CPU, DDR3, 1066MHz (2x4GB Dual

Ranked UDIMMs)

o RAID5 3x300GB, SATA, 3.5-inch, 7.2K RPM Hard Drive (Hot Plug)

• Estado posterior (despliegue y uso intensivo del proyecto) – Mínimo 4

servidores (2 para el sistema, 2 para los datos), en configuración de alta

disponibilidad, con parejas situadas en localizaciones distintas y

conectados por una línea de alta velocidad

o 2 Servidores de alta disponibilidad, con redundancia y sistema de


� Procesador Intel® Xeon® E5502, 1.86Ghz, 4MB Cache,

4.86 GT/s QPI

� 8GB de Memoria para 1 CPU, DDR3, 1066MHz (2x4GB

Dual Ranked UDIMMs) RAID5 3x300GB, SATA, 3.5-inch,

7.2K RPM Hard Drive (Hot Plug)

o 2 Servidores de alta disponibilidad, con redundancia y sistema de


� Procesador Intel® Xeon® E5502, 1.86Ghz, 4MB Cache,

4.86 GT/s QPI

� 8GB de Memoria para 1 CPU, DDR3, 1066MHz (2x4GB

Dual Ranked UDIMMs)

� RAID1 2x160GB, SATA, 3.5-inch, 15K RPM Hard Drive

(Hot Plug)

30

5.2. Conectividad

Los servidores deberán estar conectados a Internet por una línea de alta

capacidad simétrica y con caudales garantizados para asegurar una calidad de

servicio a los establecimientos. Sistema autónomo con bloques propios de

direcciones IP y con conectividad redundante y diversificada a Internet.

Múltiples enlaces con velocidades totalmente aseguradas a través de diferentes

carriers, lo que permita prestar servicios IP con los mejores anchos de banda y

con las menores latencias.

5.3. Ordenadores

Equipo conectado a Internet sin necesidad de mayores funcionalidades

específicas (preferible que no sean netbook). Es decir, portátiles o equipos de

sobremesa con características estándares del mercado. Por ejemplo:

o Core 2 Duo de Intel a 2.26 GHz

o 2 GB de memoria

o Disco duro de 160 GB

o Acceso DSL de 1MB o superior a Internet

o Navegador con soporte Javascript 1.2 (MSIE7+, Opera9+, Mozilla2+ y

Google Chrome)

6. Opciones de gestión y desarrollo

En este apartado, vamos a proponer y describir cuatro opciones de gestión y

desarrollo del proyecto, con sus posibles fases, hitos y fortalezas y debilidades.

6.1. Opción 1: Software como producto

31

Esta opción consiste en que el Invat.tur solicita un producto: el Sistema

OpenApps para ponerlo en manos de una Comunidad de desarrolladores, que

se encargarán de llevarlo a las empresas.

Para ello, Invattur solicita el desarrollo del sistema y posteriormente pone

estos productos a disposición de la comunidad en modalidad de software libre,

permitiendo que cualquier empresa que lo desee lo pueda descargar, en su caso

adaptar y ofrecer a los establecimientos turísticos que lo deseen.

El acceso a las empresas es a través de los productos que los proveedores

ponen en el mercado fruto de las adaptaciones o puestas en valor del código

desarrollado.

Las aplicaciones resultantes se encuentran distribuidas en base a distintos

proveedores, y se conectan con el CRS de la Comunitat Valenciana a través de

XML, que actúa sólo como un interfaz comercial (es decir, no es propiamente

un CRS sino un agregador)

La estructura visual de las fases del proyecto sería la siguiente.

32

El mapa de ruta de los hitos del proyecto, para los años 2010-2011 seria:

• HITO 1: Desarrollo del sistema

o 1.Análisis: 4 meses

o 2.Diseño: 2 meses

o 3.Programación: 5 meses

o Resultado: código libre del sistema

• HITO 2: Desarrollo de la Comunidad de Desarrolladores

o 1.Forja: 2 meses

o 2.Constitución formal de la Comunidad: 1 mes

o 3.Comunicación programadores: 1 mes

o 4.Programa incentivo lanzamiento “líderes comunidad”: 1 mes

o 5.Programa testeo: 3 meses

o Resultado: producto en el “mercado” por, al menos, 3

proveedores

• HITO 3: Penetración en el empresariado

o 1.Comunicación y campaña de “venta”: 1 mes

o 2.Acompañamiento y formación: 5 meses

o Resultado: 100 empresas usando el sistema

• HITO 4: Desarrollo CRS Comunitat Valenciana

o 1.Análisis: 1/2 mes

o 2.Diseño: 1/2 mes

o 3.Programación: 1 mes

o Resultado: CRS Comunitat valenciana

• HITO 5: Campaña dinamización comunidad

o 1.Incentivo módulos específicos: 1 mes

o 2.Desarrollo módulos específicos: 5 meses

o 3.Difusión módulos específicos: 2 meses

o Resultado: 3 módulos nuevos de valor para el Ecosistema

• HITO 6: Expansión de la Comunidad de Desarrolladores

o 1.Comunicación “otros destinos”: 5 meses

o 2.Concurso programadores internacionales: 3 meses

o Resultados: 2 CCAA impulsando el sistema

33

Esta opción tiene un modelo de gestión distribuido, que recae en manos de los

propios proveedores que crean los productos y los ponen en el mercado

(pagando cada empresa según el proveedor). De esta forma, el Invat.tur se

“libera” de cualquier carga de gestión tecnológica, siendo su labor la de

dinamizar e impulsor de iniciativas que generen “movimiento” inicial en la

Comunidad.

En esta propuesta, detectamos las siguientes Fortalezas y Debilidades.

FORTALEZAS DEBILIDADES

El código está liberado íntegramente, lo

que permite una flexibilidad máxima

Se generan muchas aplicaciones, lo que

puede llevar a la confusión, la

complejidad de la gestión operativa y la

puesta en práctica

Se potencia la puesta en el mercado de

proveedores tech y productos

tecnológicos de proveedores de la

Comunitat Valenciana

La capacidad de penetración en el tejido

empresarial es limitada, pudiendo

quedarse “fuera” muchas empresas,

sobre todo aquellas más débiles

comercialmente

Se incentiva desde el inicio a los

programadores

Las adaptaciones requieren de un

conocimiento alto de programación y

una alta dotación de recursos, lo que

limita la capacidad de innovaciones

ágiles de utilidad y mercado

El Invat.tur se “libera” de gestión y

mantenimiento

6.2. Software como servicio (SaaS)

A continuación proponemos las siguientes tres opciones desde una perspectiva

de Proyecto Software como servicio. Es decir, entender OpenApps como un

34

sistema “en la nube” que da servicio a las empresas, lo que permite su plena

difusión. Las distintas opciones que planteamos, se basan en la propiedad de

quién da el servicio y la forma de apertura del mismo, bien en base a APIs o

bien en base a Código.

6.2.1. Opción 2: SaaS público

Esta opción consiste en que el Invat.tur solicita el desarrollo del sistema (y,

en su caso, el mantenimiento del mismo) y posteriormente lo ofrece en un

SaaS que el Invat.tur gestiona. Aunque el desarrollo y el código es del

Invat.tur, la apertura a la Comunidad de Desarrolladores comienza a través

de las APIs. Esta opción permite que los nuevos desarrollos puedan

integrarse (y en su caso venderse como servicios premium) dentro del SaaS,

convirtiéndose en un OpenApps Store.



• HITO 1: Desarrollo del sistema en SaaS



35

o 3.Programación 4 meses

o 4.Testeo Beta: 2 meses

o Resultado: SaaS del sistema

• HITO 2: Penetración en el empresariado









• HITO 4: Desarrollo Comunidad Emprendedores Tech

o 1.Desarrollo Forja de API: 2 meses

o 2.Comunicación, difusión y dinamización: 2 meses

o 3.Concurso e incentivos: 3 meses

o Resultado: 4 nuevas aplicaciones usando el sistema, al menos

una de Monitorización de Conocimiento

• HITO 5: Desarrollo de la Comunidad de Desarrolladores

o 1.Forja: 2 meses



o 4.Programa incentivo lanzamiento “líderes comunidad”: 1

mes

o Resultado: 2 mejoras y/o adaptaciones

• HITO 6: Expansión de la Comunidad de Desarrolladores




36

Esta opción tiene un modelo de gestión que requiere una alta capacidad de

recursos especializados por parte del Invat.tur, que se convierte en una

“empresa” de servicios de software, lo que implica:

• Mantenimiento de servidores

• Mantenimiento del sistema

• Adaptación de nuevos desarrollos

• Gestión de operaciones y de clientes/proveedores



Máxima penetración en el tejido

empresarial turístico, por no requerir

inversión y ser un coste variable

Poca flexibilidad en la adaptación del

sistema en las primeras fases

Capacidad de gestión coordinada Poca concienciación del concepto SaaS

por estar en Web externa

Agilidad de nuevos desarrollos ágiles y

de utilidad

Poca agilidad y “dudas de futuro” por

ser la gestión del SaaS de un ente

público

Incentivo de innovaciones en el SaaS

como “mercado de nuevas aplicaciones”

Se asegura que todas las empresas

tengan siempre la “última versión”

6.2.2. Opción 3: SaaS privado

Esta opción se diferencia en la anterior, en que Invat.tur sólo encarga que

una empresa proveedora gestiones el SaaS, lo que requiere de que algún

proveedor detecte un valor y posibilidad de negocio en ese servicio, para

37

asumir él mismo la mayoría de los desarrollos. Es una opción muy ventajosa

económicamente al Invat.tur, si bien deja el proyecto en manos de un

proveedor. No obstante, la opción de que sea un proveedor quien gestione

el SaaS, es un modelo óptimo para el Invat.tur y el sector. Por ello, esta

opción requiere de un contrato muy estricto por parte del Invat.tur en

relación con el proveedor, que contemple la posibilidad de que el Invat.tur

pueda acceder a la compra del código (en su última versión) en cualquier

momento e, incluso, que lleve emparejada el paso a la opción 4 (que

veremos en el siguiente punto) en el plazo de 2 años.

Con esta opción, no se libera el código, sino únicamente la API, que es el

núcleo de la Comunidad OpenApps.



• HITO 1: Negociación con el proveedor SaaS y puesta en marcha


o 2.Programación específica: 3 meses

o 3.Testeo Beta: 1 mes


• HITO 2: Implantación y penetración en el empresariado




38








o 2.Comunicación, difusión, formación y dinamización: 5 meses

o 3.Concurso e incentivos según prioridades: 3 meses

o 4.Puesta en marcha de la OpenApps Store: 3 meses



Esta opción tiene un modelo de gestión que recae netamente en la empresa

proveedora del SaaS, “liberando” al Invat.tur, que tiene como labor de

gestión la de dinamizar e impulsar la comunidad de emprendedores, así

como la de lograr la plena penetración del sistema a través de la formación.











de utilidad

Coste de dependencia de un proveedor





Gestión por una empresa especializada

39

y con necesidad de capitalizar su

inversión

6.2.3. Opción 4: SaaS público con gestión privada

Esta opción se diferencia de la 2 en que la gestión del SaaS del Invat.tur lo

desarrolla una empresa privada, mediante una concesión.



• HITO 1: Desarrollo del sistema en SaaS



o 3.Programación 4 meses

o 4.Testeo Beta: 2 meses


• HITO 2: Implantación y penetración en el empresariado


40










o 2.Comunicación, difusión, formación y dinamización: 5 meses

o 3.Concurso e incentivos según prioridades: 3 meses

o 4.Puesta en marcha de la OpenApps Store: 3 meses



Esta opción, al igual que la anterior, tiene un modelo de gestión que recae

netamente en la empresa proveedora del SaaS, pero donde el Invat.tur

mantiene la propiedad y, además tiene la labor de dinamizar e impulsar la

comunidad de emprendedores, así como la de lograr la plena penetración

del sistema a través de la formación. Esta opción puede tener una variable

que influirán en el coste, y es la relacionada con la propiedad de los datos y

clientes por parte de la empresas proveedora (durante el tiempo que dura

la concesión) o por parte del Invat.tur. De esta forma, la opción 4 la

podemos desglosar en dos subopciones:

• Opción 4a: La propiedad de los datos de la gestión de la

concesión son de la empresa proveedora (aunque incluya

opción de cesión de uso al Invat.tur)

• Opción 4b: La propiedad de los datos de la concesión son del

Invat.tur


41










de utilidad





42

6.3. Comparativa de opciones

Para comparar las cuatro opciones que hemos planteado, usaremos los

siguientes parámetros por entender que son los que mejor reflejan los

argumentos para la toma de decisiones.

Opción 1

Producto

Opción 2

SaaS

Publico

Opción 3

SaaS

Privado

Opción 4 a

SaaS

Público/Gestión

Privada incl.

datos

Opción 4 b

SaaS

Público/Gestión

Privada no incl.

datos

Alineamiento

estratégico

Consistencia

tecnológica

Facilidad para

innovación/evolución

permanente

Coste

Plazo

Recursos

Externos/Internos

Sencillez del Modelo

de Gestión

Impacto sectorial 1

año

Después de la tabla comparativa y a tenor del feedback recibido por la AVT y el

Invat.tur, la opción 3 con un contrato de transformación en dos años al

modelo 4a o, en su caso 4b, es la propuesta que usaremos para definir el

calendario de trabajo para la estrategia tecnológica y de la Comunidad del

43

proyecto OpenApps. En este entorno, cobra mayor importancia, al menos a

corto plazo, el desarrollo de APIS por encima de la apertura íntegra (de todos

los módulos) del código fuente. Es la estrategia del desarrollo de las APIS la que

dará sentido a la Comunidad de Desarrolladores de OpenApps.

7. Plan de Trabajo Tech 2010-2011

En este apartado, una vez seleccionada la opción que se va a optar para desarrollar

y gestionar la tecnología y la Comunidad del OpenApps, procedemos a diseñar el

calendario de acciones y el Plan de Trabajo para llevar a cabo el proyecto durante

el 2010-2011.

Para una mejor gestión de las fases del proyecto, desglosaremos las acciones en las

dos áreas claves del OpenApps que tienen incidencia directa con este documento,

dos ejes, con sus respectivos subproyectos:

• Plataforma tecnológica

o 1. Selección de proveedor/es. Negociación comercial y condiciones de implantación.

o 2. Desarrollo y entrega del código y puesta en marcha del SaaS o 3. Proceso de implantación en las empresas turísticas de la

Comunidad Valenciana. o 4. Formación técnica específica

� Profesionales turísticos � Tecnólogos

o 5. Desarrollo de conectividades directas con sistemas de gestión y

canales de distribución vía protocolos XML.

• Comunidad de desarrolladores

o 6. Desarrollo y Gestión de APIs y Forjas o 7. Priorización, gestión, promoción y dinamización de desarrollos y

aplicaciones. o 8. Mantenimiento del código central (core code) o 9. Gestión del “OpenApps Store” para la comercialización de módulos

y aplicaciones no predefinidas en el proyecto

44

Implicaciones Plazo Coste

1 Acción que requiere de personal propio y un

asesoramiento a la negociación. Alto nivel directivo y

político

1 mes 12.000€

2 Acción que requiere de trabajo permanente de la

empresa proveedora para poner en marcha el SaaS,

con un contrato de cesión del código en dos años.

6

meses

400.000€

3 Acción que requiere de un proceso de implantación

secuencial en las empresas turísticas, previo testing

de un piloto

2

meses

30.000€

4 Acción intensiva de implantación de un circuito

formativo de la herramienta a las empresas y a

tecnólogos

6

meses

80.000€

5 Acción para desarrollar las conexiones directas con

los 10 principales IDS y los 4 principales PMS

6

meses

100.000€

6 Acción que requiere el desarrollo de la forja de las

APIs y, en su momento, de la Forja del código, pata la

construcción del inicio de la Comunidad

2

meses

30.000€

7 Acción que requiere el trabajo con los empresarios y

los tecnólogos para dinamizar los nuevos desarrollos

a implementar

14

meses

150.000€

8 Acción de mantenimiento y actualización de

versiones del código central de dos veces a año

3 (1

cada

6

meses

45.000€

9 Acción que requiere la dinamización y puesta en

marcha de la OpenApps Store para la incentivación

de desarrollos no planificados en la acción 7 y 8 que

puedan ser monetizados por tecnólogos

5

meses

80.000€

45

Anexo 1. Aportaciones Workshops

Cada aportación está encuadrada en una clasificación según se especifica a continuación con el fin de facilitar la segmentación del trabajo y la mejora de las reflexiones al respecto. Al final de cada aportación se señala entre paréntesis el grupo al que pertenece. -TEC - Aplicaciones y desarrollos tecnológicos -EST - Desarrollos estratégicos y conceptuales así como todos aquellos elementos de gestión integral del destino -COM - Planteamientos, acciones y herramientas de gestión comercial -FOR - Necesidades identificadas de formación y desarrollo de capacidades -MIS - Miscelánea (cualquier otro elemento que no encaje en los anteriores)

TEC - Aplicaciones y desarrollos tecnológicos

-Necesidad de un gestor de contenidos o repositorio estático e integral en la plataforma (TEC) (COM) (Hotelero)

-Aplicación de Business Intelligence que permita el análisis el análisis de los mercados tanto a nivel local como global (TEC) (EST) (Hotelero)

-Herramienta que permita crear comunidades de forma fácil, rápida y gestionable tipo Ning ((TEC) (COM) (Hotelero)

-Herramienta capaz de gestionar el precio dinámico simplificando la gestión del mismo y eliminando intermediarios que no aporten valor (COM) (TEC) (Hotelero)

-Gestor de reviews que salve la mala gestión que de ellos hacen páginas como Tripadvisor (TEC) (EST) (COM) (Hotelero)

-Algún tipo de herramienta que ayude a la gestión interna (comunicación, cuadros de mando, informes, gestión de calidad) (TEC) (Hotelero)

-Información en tiempo real de la disponibilidad de trasportes en un y hacia un destino determinado. (TEC) (Hotelero)

-Muestran gran interés en las herramientas de Revenue que puede aportar OpenApps-Invattur, para conseguir una adecuada gestión de los canales. (TEC) (COM) (AAVV)

-Se propone geoposicionamiento como funcionalidad fundamental en la plataforma para acceder más fácilmente a la oferta una vez en destino. (TEC) (Restauración)

-Que el CRS pueda permitir el darse a conocer al resto de actores turísticos, permitiendo que a través de sus webs informen a los clientes de las posibilidades de restauración de cada destino, e incluso poder ofrecer información de menús a precio cerrado (menú del día, menú degustación, jornadas gastronómicas de un producto concreto, etc), les permitiría darse a conocer y a los alojamientos y

46

agencias de viajes dar información que permita captar mas clientes o, mejor incluso, otro tipo de clientes. (COM) (TEC) (Restauración)

-Hay una clara dificultad de las instituciones en medir el resultado de la promoción institucional, porque al final quien realiza la transacción es el empresario, por lo que no se puede cuantificar. En este sentido, la herramienta permite cuantificar y poner indicadores que facilitarán esa labor. (TEC) (Instituciones)

-Se integra un cuadro de mando en la herramienta que permite tener una mejor información del mercado, una mejor gestión del marketing con una serie de analíticas macro y un CRM de clientes que favorece el Business Intelligence. (TEC) (COM) (Instituciones)

-Posibilidad de aprovechar el potencial de los dispositivos móviles - incluidos los GPS de los coches o de los teléfonos - como herramientas de promoción y comercialización cuando el cliente está en el destino (TEC) (COM) (Instituciones) -Algunos establecimientos están utilizando programas de gestión integral que, reconocen, es poco utilizado en términos generales, sobre todo por falta de tradición y formación en la utilización de este tipo de herramientas. (TEC) (Rural) -La utilización de Rural Gest como canal de comercialización y para temas de gestión le es muy cómodo al sector y ofrece la posibilidad de conectarse a los canales y tener presencia propia de venta. Esta herramienta es perfectamente compatible con Open Apps. (TEC) (Rural)

-Apuntan a algunas funcionalidades interesantes y que ya están operativas en algunos establecimientos:

-Generador de Web, con un gestor de contenidos capaz de trabajar sobre etiquetas meta, para que los usuarios más avanzados cuenten con la posibilidad de trabajar el SEO; (TEC) (Rural)

-El programa de gestión de la Asociación Montaña de Alicante funciona con bases de datos en Acces y con Excel, todo bajo un entorno muy parecido a Windows, intuitivo y simple, el ocupante del alojamiento que en muchos casos no tiene que ser el cliente final también es registrado en la base de datos, de esta forma estamos creando una base de datos de clientes y otra de ocupantes del alojamiento, eso va muy bien a la hora de fidelizar y sobre todo que solo se hace el trabajo una vez. por otra parte esta la base de datos de artículos con control de stok, planning de habitaciones, etc....y por supuesto se hace el albaran, se factura y se controlan pagos y cobros (TEC) (Rural)

-Es necesario contemplar garantías de pago en cancelaciones cuando el cliente llega a través de intermediario. En la plataforma tiene que disponer de una funcionalidad de solicitud de depósito de garantías personalizable y parametrizable por establecimiento, temporada, etc… (TEC) (COM) (Apartamentos)

-Debe existir un sistema de carga de contenidos vía XML, porque hacer uno a uno es inviable. (TEC) (Apartamentos)

47

-Channel Manager propio de la plataforma? Al corto plazo se promueve la idea de comisionar con un uno externo para comenzar antes la comercialización. A medio/largo se contempla el desarrollo del channel manager propio. (TEC) (COM) (Apartamentos)

-Beneficios que ofrece la plataforma al sector: (Apartamentos) -contenido enriquecido y dinámico, (MIS) -posibilidad de complementar las aplicaciones que ya utilizamos con otras, (TEC) -nuevas posibilidades de gestión de producto, (COM) -acceso a más canales de comercialización a través de un CRS más completo. (TEC)

-Se pregunta si la plataforma contará con un portal… ¿cómo se va a poder realizar la venta cruzada? Apuntan a una funcionalidad de Comunidad Interna de proveedores. (TEC) (COM) (Of. Complementaria)

-Se considera interesante la creación de una base de datos del CRS que permita a los profesionales de la oferta complementaria localizar a posibles partners y que les facilite la creación de ese posible producto. (TEC) (COM) (Of. Complementaria)

-¿Puede haber alguna aplicación en la plataforma que ayude a hacer marketing interno? (TEC) (EST) (Of. Complementaria)

-Se plantea la necesidad de que la herramienta cuente con una BBDD abierta y modificable a todas las empresas participantes, donde poder realizar consultas de clientes, fugitivos, terroristas, etc. (TEC) (Camping)

-La herramienta debería disponer de funcionalidades estadísticas, presentándose éstas en comparativas y diagramas. (TEC) (Camping)

-Se sugiere la idea de establecer alguna función de “compatibilidad / Afinidad” entre empresas participantes, para de este modo encontrar más fácilmente posibles empresas colaboradoras con altos grados de afinidad o compatibilidad. (TEC) (COM) (Camping)

-Sería bienvenida una herramienta de Business Intelligence para conseguir un mejor conocimiento del cliente. (TEC) (COM) (Camping)

COM - Planteamientos, acciones y herramientas de gestión comercial

-Necesidad de un gestor de contenidos o repositorio estático e integral en la plataforma (TEC) (COM) (Hotelero)

-Herramienta que permita crear comunidades de forma fácil, rápida y gestionable tipo Ning ((TEC) (COM) (Hotelero)

-Herramienta capaz de gestionar el precio dinámico simplificando la gestión del mismo y eliminando intermediarios que no aporten valor (COM) (TEC) (Hotelero)

48

-Desarrollar el Backoffice, de modo que integre herramientas de facturación y gestión de cobros para facilitar y dinamizar la gestión de estos elementos. (COM) (Hotelero)

-Generador de reglas de negocio segmentable que permita gestionar el precio y el canal de un modo segmentado con criterios no sólo de producto o canal, sino de tiempo, conectado a la aplicación de Business Intelligence. (COM) (Hotelero)


-Hay debate en torno a la pregunta de si es mas conveniente que la plataforma se rija por un modelo de Prepago o de Postpago, se detecta la conveniencia de que se realicen indistintamente, sin limitaciones, si bien aclaran la necesidad de un callcenter en el caso de prepago. En el caso de la opción post pago, habría que realizar un depósito para garantizar la reserva. Así mismo, las políticas de cancelación tendrían que ser definidas, debido a las casuísticas de todos los hoteles participantes. (COM) (Hotelero)

-Inquietud en los incoming ante la posibilidad de que el proveedor utilice la plataforma OpenApps-Invattur para “saltar” la intermediación y gestionar directamente con la emisora del origen. (COM) (AAVV)

-Muestran gran interés en las herramientas de Revenue que puede aportar OpenApps-Invattur, para conseguir una adecuada gestión de los canales. (TEC) (COM) (AAVV)

-¿Es mejor el prepago o el postpago? No hubo una conclusión definitiva, aunque se comentó que el postpago puede generar problemas de descapitalización. De todos modos es un debate que sigue en la comunidad OpenApps-Invattur. (COM) (AAVV)

-Posibilidad de incorporar todo el producto de los incoming en la plataforma tecnológica que actualmente se está vendiendo en el canal tradicional, incluida la oferta de fuera de la Comunidad Valenciana. (COM) (AAVV) -Se clarifica que el proyecto no incluye las campañas de comercialización y marketing online que cada empresa, asociación o colectivo deberá realizar por su cuenta. En este sentido, se informó que la Conselleria de Turisme tiene una línea de apoyo establecida tanto para empresas como asociaciones precisamente para acciones de marketing online. (COM) (AAVV)

-Tener en cuenta una serie de variables a la hora de crear los productos que debamos subir al CRS: Variable I: Inventario (mesas) Variable II: Fecha Variable III Producto gastronómico (Paquetes gastronomitos, jornadas, tipología, etc) (menus) Variable IV: variable abierta (observaciones,…) (COM) (Restauración)

-Son importantes las acciones de Marketing Online para atraer tráfico a la plataforma. (COM) (Restauración)

49

-Uno de los valores de Open Apps es que ofrece valor añadido, necesitando transformar los recursos en producto para comercialización. Producto concreto + complementos (COM) (Restauración) -Habría que determinar cómo se establecerán los filtros en los metabuscadores ¿por tipología, por producto, por ingredientes, clasificación oficial, etc? (COM) (Restauración) -La plataforma debe contar con la posibilidad de tener una herramienta de revenue para diferenciar la oferta en diferentes segmentos de tiempo. El sector de la restauración lo ve como una herramienta muy útil. (COM) (Restauración)

-También se estima interesante la posibilidad de facilitar la cooperación conjunta para la organización de jornadas temáticas gastronómicas, como la feria de la tapa, colaboración entre empresas no restauradoras, etc. (COM) (Restauración)

-Importante la venta cruzada entre establecimientos alojativos y el canal de restauración. (COM) (Restauración)

-Sería interesante estructurar la plataforma para poder aprovechar la BBDD de clientes, y disponer de información previa a la reserva. El problema está en cómo conseguir los datos del cliente antes de consumir el producto (COM) (Restauración)

-Que el CRS pueda permitir el darse a conocer al resto de actores turísticos, permitiendo que a través de sus webs informen a los clientes de las posibilidades de restauración de cada destino, e incluso poder ofrecer información de menús a precio cerrado (menú del día, menú degustación, jornadas gastronómicas de un producto concreto, etc), les permitiría darse a conocer y a los alojamientos y agencias de viajes dar información que permita captar mas clientes o, mejor incluso, otro tipo de clientes. (COM) (TEC) (Restauración)

-Una de las mejores utilidades de la plataforma Open AppsInvattur es que permite hacer múltiples combinaciones de producto a bajo coste. (COM) (Instituciones)

-Un error reconocido por las instituciones es que hasta ahora se ha hecho más hincapié en el destino que en el producto y el cliente. (COM) (Instituciones)

-Se integra un cuadro de mando en la herramienta que permite tener una mejor información del mercado, una mejor gestión del marketing con una serie de analíticas macro y un CRM de clientes que favorece el Business Intelligence. (TEC) (COM) (Instituciones)

-Se muestra la necesidad de convertir el tráfico de las distintas páginas institucionales en tráfico útil y reservas. (COM) (Instituciones) -Posibilidad de aprovechar el potencial de los dispositivos móviles - incluidos los GPS de los coches o de los teléfonos - como herramientas de promoción y comercialización cuando el cliente está en el destino (TEC) (COM) (Instituciones)

50

-Apuntan a algunas funcionalidades interesantes y que ya están operativas en algunos establecimientos:

-CRM de clientes para trabajar la fidelización, mediante campañas de e-mail marketing, etc... Tener un histórico de clientes, donde podamos saber, cuantas veces han venido, cual son sus costumbres, caprichos, gustos, manías, es fundamental para llevar la fidelización a niveles muy profesionales, establecimientos como los nuestros pueden llevarlo a cabo; (COM) (Rural)

-Herramienta de facturación con volcado de datos a herramientas tipo "Contaplus". (COM) (Rural)

-En materia de comercialización se planteó la conveniencia de definir el producto turismo rural genérico pero también el desarrollo de producto atendiendo a nicho. (COM) (Rural)

- Quedó clara la desintermediación que tiene el sector de alojamiento extrahotelero, con cuotas de hasta el 90% en algunos casos. Las posibles salvedades se dan en destinos urbanos como Valencia capital, donde la utilización de canales de touroperación online como es el caso de HotelBeds es más alta, aunque la tendencia es a utilizar estrategias de revenue para dinamizar la oferta, por lo que este tipo de herramientas es muy interesante. (COM) (Apartamentos)

- El producto VILLAS consideran que también debe entrar dentro de la definición de la oferta alojativa extrahotelera. (COM) (Apartamentos)

- La diversidad del producto alojativo en la comunidad valencia puede ser una gran oportunidad como reclamo turístico. Debería reflejarse en la comercialización. (COM) (Apartamentos)

- El cliente final sigue demandando el producto extrahotelero, al margen del touroperador. Es fundamental la comercialización y distribución directa, pues más del 50% de los clientes entran por canal comercial directo (web propia, teléfono, etc.) (COM) (Apartamentos)

- El turismo extrahotelero urbano de Valencia sigue dependiendo mayoritariamente de la intermediación, vía Hotelbeds.com. Lo que hace fundamental facilitar canales de enganche a esos intermediarios. (COM) (Apartamentos)

- Solución al problema de los no Shows, para evitar la pérdida oportunidad de venta de camas. (COM) (Apartamentos)

- Es necesario contemplar garantías de pago en cancelaciones cuando el cliente llega a través de intermediario. En la plataforma tiene que disponer de una funcionalidad de solicitud de depósito de garantías personalizable y parametrizable por establecimiento, temporada, etc… (TEC) (COM) (Apartamentos)

- La plataforma ha de informar sobre la política de cancelaciones, pagos y garantías, estancias mínimas y horarios de entrada y salida. (COM) (Apartamentos)

51

- En las webs propias, se barajan ratios de conversión en torno al 3%-4%. Son altas, por lo que un buen apoyo de un programa de creación y gestión de producto sería muy interesante. (COM) (Apartamentos)

-La gestión de las plazas aéreas es un punto crítico de la gestión. (COM) (Apartamentos)

-Channel Manager propio de la plataforma? Al corto plazo se promueve la idea de comisionar con un uno externo para comenzar antes la comercialización. A medio/largo se contempla el desarrollo del channel manager propio. (TEC) (COM) (Apartamentos)

-Creación de paquetes cerrados de otras ofertas combinados con el apartamento, y como posibles ventas cruzadas cuando el cliente cierre la reserva del apartamento. (COM) (Apartamentos)

-Beneficios que ofrece la plataforma al sector: (Apartamentos) -contenido enriquecido y dinámico, (MIS) -posibilidad de complementar las aplicaciones que ya utilizamos con otras, (TEC) -nuevas posibilidades de gestión de producto, (COM) -acceso a más canales de comercialización a través de un CRS más completo. (TEC)

- Las reservas se hacen al 50% en origen, por lo que es buena una herramienta de comercialización como Open Apps (COM) (Of. Complementaria)

-Se pregunta si la plataforma contará con un portal… ¿cómo se va a poder realizar la venta cruzada? Apuntan a una funcionalidad de Comunidad Interna de proveedores. (TEC) (COM) (Of. Complementaria)

- Se solicita involucrar también a los Ayuntamientos, de forma que puedan informar a los potenciales clientes de todas las festividades, actos y eventos que tienen lugar periódica o puntualmente. (COM) (EST) (Of. Complementaria)

- Algunos de los participantes no se encuentran muy cómodos con la denominación “Oferta Complementaria”, pues en su amplitud pierde significado. Open Apps puede servir para la creación de producto visibilizando esa oferta disgregada. Ya ha habido algún alojativo extrahotelero que en la Comunidad Open Apps ha ofrecido la posibilidad de crear un producto conjunto. (COM) (Of. Complementaria)

-Se considera interesante la creación de una base de datos del CRS que permita a los profesionales de la oferta complementaria localizar a posibles partners y que les facilite la creación de ese posible producto. (TEC) (COM) (Of. Complementaria)

-Se sugiere la idea de establecer alguna función de “compatibilidad / Afinidad” entre empresas participantes, para de este modo encontrar más fácilmente posibles empresas colaboradoras con altos grados de afinidad o compatibilidad. (TEC) (COM) (Camping)

-Necesidad de estrategias de comunicación para mejorar la imagen y el conocimiento del sector. Posible utilidad de Open Apps? (COM) (Camping)

52

-El sector estaría interesado en que Open Apps le permitiera compartir conocimiento e información no sólo dentro de su sector, sino con todo el sector turístico. (COM) (Camping)

-Sería bienvenida una herramienta de Business Intelligence para conseguir un mejor conocimiento del cliente. (TEC) (COM) (Camping)

EST - Desarrollos estratégicos y conceptuales así como todos aquellos elementos de gestión integral del destino

-Aplicación de Business Intelligence que permita el análisis el análisis de los mercados tanto a nivel local como global (TEC) (EST) (Hotelero)


-El sector reconoce una serie de beneficios que el proyecto va a generar. Un acceso directo al producto, con distintos niveles de tarifas y distintos niveles de acceso. Ahorro en tecnología. Desarrollo de nuevos productos turísticos, integrando nuevas dinámicas de pensamiento más efectivas, concretas y acordes con el nuevo entorno. La posibilidad de acceder a mercados emisores tanto como receptivos, consolidadores o emisores gracias a las potencialidades que otorga la herramienta. (EST) (AAVV)

-Los alojamientos rurales necesitan de la integración y la ayuda de sectores como la administración o las asociaciones para sacar el máximo partido a las posibilidades del producto. (EST) (Rural)

-Se solicita involucrar también a los Ayuntamientos, de forma que puedan informar a los potenciales clientes de todas las festividades, actos y eventos que tienen lugar periódica o puntualmente. (COM) (EST) (Of. Complementaria)

-Open Apps ofrece acceder a la estrategia, puesto que con Camping Data ya ha iniciado el camino de acceso a la tecnología, al conectarle con toda la oferta de la Comunidad Valenciana y permitirle configurar y vender productos y no servicios. (EST) (Camping)

FOR - Necesidades identificadas de formación y desarrollo de capacidades

-Al sector de la restauración le preocupa que los altos conocimientos técnicos para utilizar la plataforma sean un impedimento para los restauradores, debido a la falta de formación tecnológica existente entre los empresarios restauradores. (FOR) (Restauración)

-Preocupación por el déficit formativo en tecnología, y más teniendo en cuenta el tamaño y el tipo de empresas que conforman el sector de la restauración. (FOR) (Restauración)

53

-Necesidad de una formación específica en torno al proyecto y a la gestión. (FOR) (Rural) MIS - Miscelánea (cualquier otro elemento que no encaje en los anteriores)

-Apuntan a algunas funcionalidades interesantes y que ya están operativas en algunos establecimientos: (Rural)

-Publicación de calendarios de ocupación y posibilidad de involucrar a los portales verticales de turismo rural en la integración de esta herramienta, ya que desde nuestra plataforma podremos actualizar la disponibilidad en todos ellos; Involucrar a los portales verticales en que se conviertan también en centrales de reservas, habría que "enchufarlos" al canal; (MIS)

-Herramienta de envío de partes policiales; (MIS)

-Módulo para controlar la gestión de calidad de los establecimientos. Algo adaptado a ISO o a Q, que permita controlar sobre todo lo burocrático de los sistemas de calidad: documentación, procedimientos, etc... (MIS) (Rural)

- Preguntan si habrá un plan de comunicación y promoción externo para que distribuidores utilicen la herramienta para comercializar. (MIS) (Of. Complementaria)

-Se considera interesante desarrollar programas de formación para guías turísticos puesto que son elementos fundamentales de la promoción en medios sociales. (MIS) (Of. Complementaria)

54

Anexo 2 – DAFOS de las Opciones de fórmula tecnológica.

DOCUMENTO DE CONCLUSIONES FASE CERO Proyecto OPENAPPS/INVATTUR

2

CONTENIDOS páginas 1 El Proyecto

1.1 – Contexto y Contenidos 03. 1.2 - Objetivos 06. 1.3 - Enfoque 07. 1.4 - Desarrollo 09.

2 Líneas de Trabajo FASE CERO 2.1 Estrategia – Transversalidad y Co-Responsabilidad 11. 2.2 Marketing integral del destino 12. 2.3 Monetización del Tráfico Webs Institucionales 13. 2.4 Plataforma tecnológica 15. 2.5 Comunidad de Desarrolladores 18.

3 Implicaciones, Plazos y Costes 3.1 Estrategia y Marketing 21. 3.2 Tecnología y Comunidad de Desarrolladores 23.

4 Plan de Trabajo Período 2.010 – 2.011 4.1 Proyecciones, Hitos y Plazos

4.1.1 Subproyectos OpenApps 1 a 4 29. 4.1.2 Subproyectos OpenApps 5 a 9 29. 4.1.3 Subproyectos OpenApps 10 a 13 30. 4.1.4 Otras Acciones

3

1 – EL PROYECTO 1.1 CONTENIDOS.-

El sector turístico de la Comunidad Valenciana, en el tránsito de un modelo de oferta basado en el monoproducto – sol y playa – y el monocanal – los tour operadores internacionales y de estancias en el mercado español – necesita hacer una serie de ajustes que alineen de forma eficaz los cambios que se han producido a lo largo de los últimos años en la demanda (clientes y mercados) con la oferta de productos y servicios turísticos. Se identifican como áreas de actuación básicas, aquellas relacionadas con el desarrollo y la mejora de las capacidades de todos los agentes sectoriales de los destinos turísticos de la Comunitat Valenciana, para la creación, comercialización y distribución de la variedad y riqueza de producto turístico que baja la marca principal Comunitat Valenciana y dentro de las 4 marcas de destino – Costa Blanca, Benidorm, Costa de Azahar y Valencia – se posicionarían con multitud de propuestas diferenciadas e irresistibles para clientes nacionales e internacionales. Para completar los elementos clave del ciclo comercial a desarrollar, se plantea además, la importancia de desarrollar un enfoque conjunto de todos los agentes turístico de la Comunitat, mediante el cual se trabaje de forma conjunta en la optimización de la identidad y la reputación de la propuesta y las marcas de la oferta turística en la redes sociales. Dentro de este concepto, se incluiría el elemento de fidelización del destino, como una combinación de acciones que buscarían, no sólo la repetición del viajero/turista, sino la conversión de cada cliente en un agente de marketing del destino, en el pre, durante y post de la experiencia de viaje a nuestra comunidad. El proyecto OPENAPPS/INVAT.TUR plantea una serie de líneas de trabajo y actuación sobre todos estos elementos, con especial incidencia en:

- El desarrollo de una línea de dirección estratégica en la gestión integral y la comercialización del destino.

- La generación de capacidades comerciales de vanguardia en empresarios y profesionales mediante la formación y la dotación de herramientas y mentorización.

- La implantación de una plataforma tecnológica en el destino que actúe como vertebrador de todo lo anterior.

- El desarrollo de una comunidad de desarrolladores que permita el mantenimiento y desarrollo de aplicaciones sobre la plataforma, que asegure la competitividad y vigencia de la misma a largo plazo.

4

El proyecto OPENAPPS/INVAT.TUR surge como una iniciativa de la Consellería de Turisme de la Comunitat Valenciana, que vía la Agencia Valenciana de Turisme, firma un convenio con el Instituto Tecnológico Hotelero – ITH – y éste con la consultora MindProject para que tras una primera conceptualización y un trabajo directo con líderes sectoriales durante el período Sep – Dic 2009, definan los criterios y elementos clave para la correcta toma de decisiones en relación a:

• Opciones estratégicas • Capacidad de consenso y coordinación sectorial • Desarrollo de la plataforma

o Opciones de código abierto o Funcionalidades básicas y desarrollo posterior o Elementos de arquitectura

• Alternativas a la rentabilización del tráfico de las webs institucionales • Implicaciones y gestión de la comunidad de desarrolladores

Los equipos de la Agencia Valenciana de Turismo, el INVAT.TUR, el ITH y MindProject han desarrollado en el período que va del 15 de Septiembre al 15 de Diciembre del 2009, la “Fase Cero” del proyecto OpenApps/INVAT.TUR una serie de acciones de interacción con el sector, mediante presentaciones, talleres de trabajo, sesiones de planificación internas, sesiones de consultoría a subsectores específicos o la dinamización de la comunidad OpenApps y sus foros creada como soporte y complemento de las sesiones presenciales con el sector y las instituciones. Una visión cuantitativa del trabajo de esta FASE CERO podría ser:

5

De todo el trabajo desarrollado de forma conjunta con el sector y los equipo de la Agencia Valenciana de Turismo, INVAT.TUR, ITH y MindProject se sacan una serie de conclusiones de alto nivel que en gran medida confirman las bases del proyecto, y múltiples conclusiones y aportaciones que lo enriquecen y lo adaptan a la casuística específica de cada uno de los subsectores. A grandes rasgos, hay unanimidad en el sector en la necesidad y la oportunidad que representa un proyecto como el OPENAPPS/INVAT.TUR para fortalecer la coordinación público-privada en la acción de promoción del destino, y la generación de capacidades comerciales de las empresas, que impliquen una mayor competitividad y un aumento de la rentabilidad del destino Comunitat Valenciana y de las empresas y negocios que lo conforman. Términos como consenso, alineamiento, coordinación, transversalidad y co-responsabilidad en la gestión integral del destino, parecen recobrar sentido y viabilidad fruto de las nuevas dinámicas del sector, la creación del INVAT.TUR y la eventual implantación del OPENAPPS.

Las oportunidades de mejora de la competitividad en la cadena de valor sectorial se concentran en las áreas de comerciales, tanto de Marketing como de Distribución.

6

1.2 OBJETIVOS del Proyecto OPENAPPS/INVAT.TUR

El proyecto OPENAPPS/INVAT.TUR tiene 10 objetivos en base a sus 4 áreas clave: 1 – Gestión Estratégica para la comercialización del DESTINO

• Objetivo I – Estrategia Comercial Común al Destino • Objetivo II – Impulso de la comercialización online (directa e

intermediada). • Objetivo III – Mejora de las capacidades de promoción,

marca/producto, distribución y fidelización del destino. 2 – Líneas de acción para la monetización del TRAFICO de las WEBS

INSTITUCIONALES (www.comunitatvalenciana.com y otras) • Objetivo IV – Conversión del Tráfico de las webs institucionales en

ventas efectivas. • Objetivo V – Herramientas tecnológicas y formativas para la mejora de

la actividad comercial de las empresas. 3 – PLATAFORMA TECNOLÓGICA

• Objetivo VI – Modular, actualizable regularmente a bajo coste • Objetivo VII – Incorporación de funcionalidades clave para la creación

de producto y la gestión de la comercialización directa e intermediada. • Objetivo VIII – Solución extensiva a toda la oferta del producto turístico

de la Comunitat Valenciana. 4 – Comunidad de DESARROLLADORES

• Objetivo IX – Creación de una comunidad de desarrolladores en sofware libre que genere aplicaciones que den respuesta a necesidades y oportunidades de negocio actuales y futuras.

7

• Objetivo X - El INVAT.TUR como referencia mundial del desarrollo de software libre para la gestión turística.

Estos objetivos se han mantenido desde la conceptualización del proyecto, y tras las sesiones de trabajo con el sector, se confirman como los objetivos que darán un sentido de la dirección al proyecto, y que darán el nivel de éxito una vez esté completada la implantación del mismo. 1.3 AREAS de ENFOQUE del Proyecto OPENAPPS/INVAT.TUR A partir del arranque de la implantación del proyecto en el año 2.010 se plantean las siguientes áreas de enfoque: 1 – ESTRATEGIA de Comercialización del DESTINO:

1.1 – Definición de la estrategia comercial turística de la Comunitat Valenciana y cada una de sus marcas y líneas de producto a 3 y 5 años.

1.2 – Atributos de marcas para definir la presencia e identidad en Redes Sociales.

1.3 – Coordinación con los subsectores en la acciones de agregación permanente de demanda en los diferentes mercados, segmentos y nichos.

1.4 – El INVAT.TUR como centro de gestión comercial integral del destino en donde se genera y gestiona la transversalidad y la co-responsabilidad.

2 La MONETIZACION del Tráfico de las WEBS Institucionales: 2.1 – Decisión sobre la fórmula alternativa para generar ventas a través del

tráfico de la web www.comunitatvalenciana.com así como las de el resto de webs institucionales que generan tráfico desde la promoción pública.

2.2 Puesta en marcha de la solución definitiva – y eventualmente de una solución de transición con el fin de comenzar a convertir el tráfico en ventas a la mayor brevedad.

2.3 Desarrollo de las capacidades comerciales de la estructura de las webs institucionales orientadas a la mejora de la conversión del tráfico en ventas a niveles de las mejores webs de distribución turística.

8

3 La PLATAFORMA TECNOLÓGICA: 3.1 Diseño y definición de una plataforma que incluya de forma modular,

gestión de producto (PMS), central de reservas (CRS), generador de páginas web avanzadas (CMS) y gestor de canales de distribución vía mensajes XML.

3.2 Todo ello con un desarrollo modular flexible, basado en un modelo de servicio, “software as a service” (SaaS) que permita una mayor rapidez en la implantación y unos bajos costes de adopción por parte de las empresas.

3.3 La permanente actualización, adaptación a las necesidades y oportunidades de los subsectores turísticos y desarrollo continuo de la plataforma, se produciría mediante la creación de una Comunidad de Desarrolladores que tendrían acceso al código abierto y que podrían desarrollar aplicaciones sobre el mismo.

3.4 La plataforma dará respuesta desde un primer momento a las necesidades y oportunidades de todos los subsectores turísticos de la Comunitat Valenciana.

3.5 El acceso a los principales canales de distribución nacionales e internacionales se solucionará en un primer momento mediante un gestor de canales (channel manager) que asegure la máxima conectividad a corto plazo. El INVAT.TUR irá progresivamente desarrollando conexiones directas durante los siguientes 12 meses a la implantación.

3.6 Código abierto, SaaS, modularidad y flexibilidad vía conexiones XML para conseguir una plataforma de comercialización que se convierta en un estándar y en un referente nacional e internacional, y que de forma efectiva implique una oportunidad de exportar conocimiento desde la Comunitat Valenciana y el INVAT.TUR.

4 La COMUNIDAD de DESARROLLADORES: 4.1 El acceso al código, el ratio de adopción de la herramienta en el sector y

el carácter modular y flexible de la misma, generará una demanda de actualizaciones, desarrollo de aplicaciones o integraciones sobre tecnología existente, que se cubrirá de forma natural por empresas tecnológicas e individuos que conformarán un entorno de comunidad de desarrolladores.

4.2 En un primer momento, la comunidad tendrá acceso a una serie de “interfaces de programación de aplicaciones” (APIs), entorno en el cual podrán tener acceso a desarrollos relacionados con conectividad, integración y desarrollo de aplicaciones específicas que enriquezcan las capacidades de la plataforma.

4.3 En fases posteriores se comenzará a liberar el código central de la plataforma gradualmente y se irá dando acceso a la posibilidad de actualizar, completar y/o mejorar el código existente.

4.4 La generación de aplicaciones tendrá 3 modelos de remuneración a la comunidad.

4.4.1 Solicitudes específicas de aplicaciones para subsectores, canalizadas a través de las asociaciones profesionales y

9

gestionadas a través del INVAT.TUR, que tendrán una propuesta de pago para los desarrolladores.

4.4.2 Encargos concretos y puntuales entre empresas o subsectores con empresas de informática que trabajarán sobre las APIs consolidando el estándar y generando crecientes incentivos de adopción.

4.4.3 Generación de funcionalidades y aplicaciones por parte de empresas e individuos en un modelo tipo Apple Store, en donde se ofrecen aplicaciones y módulos de integración o gestión a cambio de un pago puntual, ya sea por la aplicación o por su instalación y formación.

4.5 El INVAT.TUR se convertiría de esta forma en el gestor del código y del desarrollo de la plataforma, con una estrategia específica orientada a posicionarse como el centro de referencia mundial en el desarrollo de tecnologías aplicadas a la gestión y la comercialización de producto turístico.

1.4 DESARROLLO del proyecto OPENAPPS/INVAT.TUR El cierre de la “Fase Cero” y las conclusiones permitirán tomar una serie de decisiones relativas a la dirección, opciones de implantación y desarrollo, asignación de recursos y plazos del proyecto. Dada la complejidad del proyecto y las múltiples áreas a gestionar simultáneamente, se anticipa un desarrollo e implantación del proyecto, desde una dirección única (posiblemente una mesa de gestión con “consejeros” representantes de la AVT, INVAT.TUR y los subsectores vía asociaciones empresariales y profesionales turísticas, con un/os Consejero/s Delegado/s con amplia capacidad ejecutiva), y una serie de sub-proyectos cada uno de ellos con su dotación presupuestaria y de recursos, y con su propio plan y objetivos. Se propone para el desarrollo una estructura de este tipo: 1 – Proyecto OpenApps/INVAT.TUR – General

1.1 – ESTRATEGIA

1.1.1 OPENAPPS 1 – Plan de marketing y comercialización integral del destino 2.010 – 2.013. Enfoque, implantación y gestión.

1.2 – COMUNICACIÓN 1.2.1 OPENAPPS 2 – Planes de comunicación específicos que

permitan la información, formación e interacción de tres audiencias clave: Líderes sectoriales, Sector Turístico en general (autonómico y nacional) y área tecnológica y académica.

1.2.2 OPENAPPS 3 – Plan de formación y desarrollo de capacidades y perfiles específicos en los nuevos entornos de marketing y comercialización.

10

1.3 TRAFICO Webs Institucionales 1.3.1 OPENAPPS 4 – Definición de fórmula – de transición y

definitiva - y aplicación en la web www.comunitatvalenciana.com. A partir de aquí y sobre esta experiencia se invitará a todo el resto de las webs institucionales de la Comunitat Valenciana a compartir esta solución.

1.4 Plataforma TECNOLOGICA 1.4.1 OPENAPPS 5 – Selección de proveedor/es. Negociación

comercial y condiciones de implantación. 1.4.2 OPENAPPS 6 – Desarrollo del código y puesta en marcha del

SaaS. 1.4.3 OPENAPPS 7 – Proceso de implantación en las empresas

turísticas de la Comunidad Valenciana. 1.4.4 OPENAPPS 8 - Formación técnica específica

1.4.4.1 Profesionales turísticos 1.4.4.2 Tecnólogos

1.4.5 OPENAPPS 9 - Desarrollo de conectividades directas con sistemas de gestión y canales de distribución vía protocolos XML.

1.5 Comunidad de DESARROLLADORES 1.5.1 OPENAPPS 10 – Desarrollo y Gestión de APIs y Forjas 1.5.2 OPENAPPS 11 – Priorización y gestión, promoción y

dinamización de desarrollos y aplicaciones. 1.5.3 OPENAPPS 12 – Mantenimiento del código central (core

code) 1.5.4 OPENAPPS 13 – Gestión del OPENAPPS/Store para la

comercialización de aplicaciones no planificadas (en el OPENAPPS 11) de la comunidad de desarrolladores.

La correcta gestión de los 13 subproyectos con una visión general permitiría

asegurar el cumplimiento del objetivo de desarrollar e implantar el proyecto en 24

meses con un nivel de impacto sectorial del 70% de su potencial dentro de los

primeros 12 meses desde su arranque.

11

2 – LINEAS DE TRABAJO FASE CERO 2.1 ESTRATEGIA – Transversalidad y Co-Responsabilidad Desde un primer momento se ha planteado que la involucración de los diferentes líderes sectoriales en el proyecto sería un elemento clave para cualquier opción de éxito posterior. Los niveles de cambio, la crisis, y en general la incertidumbre que en estos momentos se vive en el sector, en relación con la capacidad de desarrollar y comercializar producto turístico de forma competitiva y con rentabilidades crecientes, hace que los niveles de resistencia a cualquier iniciativa de este tipo sea los más bajos en muchos años. Al mismo tiempo, se aprecia un interés en revisar el rol de las asociaciones empresariales y las agrupaciones sectoriales de todo tipo, en forma de clubes de producto, empresas de representación, marcas, clusters, etc. El desafío está en convertir el elemento debilitador de la fragmentación de nuestras empresas en un activo, basado en la diversidad de propuestas, productos y modelos de gestión. Un primer paso en esta dirección es la consolidación de las capacidades de marketing y de comercialización(inversiones, coordinación, desarrollo de capacidades y tecnología) En paralelo a estas dinámicas, se aprecia una necesidad de mayor coordinación y co-responsabilidad en la gestión de los fondos públicos orientados a la promoción y desarrollo de los destinos turísticos. Desde el prisma de la competitividad y el incremento de la rentabilidad de las empresas y del destino se plantearía una serie de líneas de acción con un sentido de la dirección común, a cuyo “carril” se sumaran empresas, asociaciones, instituciones y profesionales, con el fin de que los retornos de la inversión para el destino como un todo, aumentaran exponencialmente. Este proyecto representa por tanto representa la respuesta de la Consejería de Turismo de la Comunidad Valenciana a la crisis, de la mano del sector, dentro de las políticas y líneas estratégicas que desarrolla la Generalitat enmarcadas en el Plan de competitividad vigente. Sería, en definitiva, la oportunidad de coordinar, consensuar y explicitar una serie de líneas estratégicas y desarrollo de capacidades que permitan a todo el sector turístico la utilización de tecnologías innovadoras para vender más y mejor y ganar en competitividad tanto en la coyuntura actual como a futuro. Se trataría pues, de asegurar una transición del modelo actual a la generación de una “banda ancha” en la distribución turística, que permita una excelente comercialización multiproducto y multicanal.

12

LINEAS de ACCION Sugeridas: a) Desarrollo de un plan estratégico con un enfoque decisivo a la comercialización de la Comunitat Valenciana. b) Desarrollo de las plataformas colaborativas que permitan la gestión efectiva de estas dinámicas. c) El INVAT.TUR se consolida como centro de gestión integral de los objetivos planteados en el plan y como eje de transversalidad y de co-responsabilidad sectorial, y legitima así su liderazgo en estas áreas y en ese replanteamiento de los roles de empresarios y profesionales, asociaciones e instituciones.

13

2.2 MARKETING Integral del DESTINO Los cambios en las oportunidades de promoción y creación de marca y producto en los destinos turísticos, implica una coordinación máxima en todas y cada una de las acciones, tanto en su planificación como en su ejecución. Sobre el documento estratégico planteado en el apartado anterior, habría que desarrollar una serie de planes tácticos por marcas, productos, territorios, mercados y segmentos. Estos planes tácticos reforzarían la participación en la planificación y la ejecución conjunta de instituciones y empresas. Esta iniciativa permitiría además revisar los pesos de cada una de las tipologías de acciones de marketing y promoción (folletos, ferias, publicidad, convenios, etc) e incluir de forma decisiva una estrategia de destino de “Presencia e Identidad en Redes Sociales” en la que participara todo el sector. La Agencia Valenciana de Turismo y el INVAT.TUR tendrían el liderazgo y la iniciativa y la capacidad de coordinación y enfoque en esta área. LINEAS de ACCION Sugeridas:

a) Desarrollo de planes tácticos de MARKETING integral del destino por marcas de destino, clubes de producto, mercados y segmentos, etc. Con participación en la planificación y la ejecución con empresas y asociaciones empresariales, así como con profesionales referentes sectoriales.

b) Desarrollo de una serie de protocolos de comunicación (Escuchar, Hablar y Conversar) en Redes Sociales, integrados como amplificadores del plan estratégico de marketing.

c) Plataformas colaborativas para la gestión de estas dinámicas.

2.3 MONETIZACION del TRAFICO en Webs Institucionales De todas las opciones analizadas, se concluye en que la mejor opción sería la de la integración de la Central de Reservas propia de OPENAPPS que permitiría el acceso a todo el producto del destino. Los usuarios de la página www.comunitatvalenciana.com podrían hacer búsquedas de producto alojativo, de restauración y ocio, y de oferta complementaria o de coches de alquiler. Los resultados de esta búsqueda sobre todo el producto que haya disponible en la Central de Reservas, y desde la página de resultados, el usuario podrá acceder a reservar directamente en las webs de los proveedores (en la pasarela de pago de las webs conectadas a la central de reservas OpenApps). Para los mercados emisores europeos, se añadirá la opción de transporte mediante la integración de uno de los METABUSCADORES más relevantes en cada uno de los mercados – Kayak, TravelJungle, TravelZoo y Minube.

14

Esta es la solución propuesta como definitiva aunque se plantea una solución de transición hasta que la Central de Reservas OpenApps esté operativa y tenga un nivel mínimo de producto disponible. Esta consistiría en la integración de las diferentes versiones de las webs de la Comunitat Valenciana en los diferentes idiomas en un sistema de afiliación de tráfico a través de una de las dos grandes plataformas europeas, TradeDouble o Xanox, con el fin de redirigir todo el tráfico generado a agencias de viajes online, consolidadotes, tour operadores o proveedores turísticos para que sea ahí en donde el usuario decida en dónde hacer sus reservas. En ambos casos se conseguiría dar al usuario la opción de reservar en el momento en el que está consultando información sobre el destino (Objetivo I), se generarían ventas (Objetivo II) y se rentabilizaría el tráfico – como posible fuente de re-inversión en promoción adicional online que contribuya a generar más tráfico (Objetivo III). LINEAS de ACCION Sugeridas:

a) Fórmula de transición a. Elección del programa de afiliación por tráfico b. Integración en las versiones web (por idiomas)de la

www.comunitatvalenciana.com b) Fórmula definitiva

a. Integración del motor de reservas del OpenApps b. Elección de los Metabuscadores para el producto transporte por

mercado. c. Configuración de los resultados de búsqueda. d. Desarrollo de las capacidades de comercialización de la página. e. Expansión de la fórmula al resto de las webs institucionales de la

Comunitat Valenciana.

15

2.4 Plataforma TECNOLOGICA El sector turístico demanda una herramienta que le permita ganar en gestión de producto, comercialización y acceso a los mercados y los canales de distribución. Esta necesidad afecta a todos los subsectores, aunque los niveles de tecnificación de unos a otros son diferentes. En cualquier caso, se confirma tras esta “fase cero” la necesidad de una herramienta que permita el acceso a funcionalidades clave para:

• Gestión de producto e inventario (PMS) • Central de Reservas (CRS) • Gestor de Páginas Web (CRM) • Gestor de Canales de Distribución (Channel Manager)

La estructura básica de la plataforma tendría por tanto 4 módulos tal y como aparece en este diagrama:

16

Con sus cuatro módulos básicos por áreas de gestión:

Es la Fase Cero del proyecto se han llevado a cabo una serie de acciones con el fin de ser capaces de proveer a la Agencia Valenciana de Turismo y al INVAT.TUR de los mejores criterios para la selección, implantación y gestión de una herramienta que cumpla los requisitos básicos de:

• Modularidad. • Flexibilidad. • Complementariedad con tecnología existente en las empresas. • Horizontalidad como solución para toda la logística del sector. • Código abierto como mejor solución para:

o Actualizar o Desarrollar o Exportar conocimiento

Estas acciones nos han llevado a comparar diferentes herramientas y opciones de desarrollo e implantación en las líneas siguientes:

• Alternativa I – Desarrollo de Software como Producto – El INVATTUR solicitaría el desarrollo integral de la plataforma, para luego abrir el código y entregarla a la Comunidad de Desarrolladores. Los costes en capacidad de gestión, en tiempo y en recursos hacen que esta opción sea la menos atractiva a priori (aunque se analiza en profundidad en el documento TECH del proyecto) Como referencia de rango de costes y plazos, se estima que esta opción estaría plenamente operativa en unos 12 a 14 meses con un coste de alrededor de €900.000.

17

• Alternativa II – Desarrollo de Software como Servicio (Software as a

Service – SaaS). La plataforma como un sistema en la “nube” que da servicios a empresas, lo que permite su mayor difusión. Esta opción permite además una arquitectura de hardware mucho menos compleja tanto para el INVAT.TUR como para las empresas turísticas.

o Opción 2 – SaaS Público. Mediante el cual el INVAT.TUR

compra/desarrolla el código, lo adapta, lo gestiona y abre una serie de APIs para que la Comunidad de Desarrolladores pueda trabajar sobre ellas. Esta opción es casi tan compleja y cara como la opción I con lo que se descartaría en el contexto actual de decisión del proyecto. En plazos y costes estaríamos en unos 10 meses y €1.000.000.

o Alternativa 3 – SaaS Privado. El INVAT.TUR ofrece a un proveedor externo la implantación de la plataforma y la gestión del SaaS. Mediante una combinación de interés comercial y un exigente contrato de niveles de servicio, el proveedor adecuaría, desarrollaría y mantendría tanto la plataforma como el SaaS. El acuerdo le obligaría además a desarrollar y abrir el código de una serie de APIs que permitiría el trabajo de la Comunidad de Desarrolladores. La opción 2.2 es posiblemente la más atractiva por su bajo coste y menor plazo de implantación. Sin embargo la gestión externa y la concesión a una empresa privada generaría unos niveles de dependencia que el INVAT.TUR tendría que poder gestionar tanto a corto como a largo plazo. En cuanto a plazos y costes, esta opción se movería en torno a los 4 meses para comenzar la implantación en las empresas locales y con un coste de €400.000.

o Alternativa 4 – SaaS Público con gestión privada. Esta sería una fórmula híbrida de las dos anteriores. El INVAT.TUR compraría el código de una serie de plataformas existentes y lo daría a un proveedor externo para su gestión como SaaS. De esta forma tendría los beneficios de la opción anterior, y además ganaría en control, ya que podría recuperar el control del código y de la plataforma en cualquier momento y gestionarlo directamente o dárselo a otro externo para su gestión. Esta opción (4A) implicaría unos desarrollos sensiblemente superiores para duplicar los sistemas del proveedor y tener una serie de aplicaciones y sistemas dedicados a la plataforma OpenApps. Esto llevaría los plazos a unos 6/8 meses y €1.200.000 (que incluyen la compra de todo el código existente en al última versión disponible a la fecha y que fruto de una negociación se podría reducir el coste de compra, en base al contenido del acuerdo en la gestión del SaaS)

18

Se plantea como una opción explorada (4B) con alguno de los proveedores, el que dentro de esta negociación se plantee el SaaS como gestión privada que incluye que todos los datos de clientes y empresas queda incorporado a la propia empresa de gestión. Esto tendría un atractivo adicional para el proveedor y por tanto tendría un impacto significativo en unos menores costes (aproximadamente €700.000 en 6 meses).

En todos los casos, habría que añadir como costes adicionales relacionados con la implantación de la plataforma, la gestión de la Comunidad de Desarrolladores y sus incentivos, el desarrollo de conectores XML con los principales canales de distribución propios y los programas formativos a profesionales turísticos y tecnólogos, que rondarían los €500.000 para el período 2.010 – 2.011. La comparativa de las opciones nos daría la siguiente tabla: Opción 1

Producto

Opción 2

SaaS

Publico

Opción 3

SaaS

Privado

Opción 4A

SaaS

Público/Gestión

Privada incl.

datos

Opción 4B

SaaS

Público/Gestión

Privada no incl.

datos

Alineamiento

estratégico

Consistencia

tecnológica

Facilidad para

innovación/evolución

permanente

Coste

Plazo

Recursos

Externos/Internos

Sencillez del Modelo

de Gestión

Impacto sectorial 1

año

Desde la gestión del proyecto se propone arrancar el proyecto con la opción 3 (SaaS privado) por su coste y plazo con la consideración que el interés comercial será la mejor garantía de unos niveles de servicio excelentes, la actualización permanente de la plataforma y su código central, así como su contribución sistemática a la Comunidad de Desarrolladores y a la OpenApps Store. La ejecución de esta alternativa llevaría además aparejada una negociación muy rigurosa y un contrato de servicios que redujera al mínimo los posibles riesgos por un posible exceso de dependencia.

19

Alternativamente habría que contemplar la opción 3 y valorar si el diferencial de plazo y coste iría en línea con las expectativas y posibilidades actuales del proyecto. En cualquier caso, el desarrollo de la opción 3 debiera llevar aparejada la migración a un modelo de explotación basado en las opciones 4A o 4B. 2.5 Comunidad de DESARROLLADORES La Comunidad de Desarrolladores se constituye en uno de los ejes clave para el desarrollo futuro del proyecto. Desde el punto de vista estratégico, su correcta gestión y desarrollo daría al proyecto un recorrido adicional imparable, por el cual la Agencia Valenciana de Turismo y el INVAT.TUR aspirarían a convertir la plataforma OpenApps en un estándar sectorial y a promover su implantación más allá de los destinos y empresas turísticas de la Comunitat Valenciana. A corto y medio plazo significan una fuerza descomunal de recursos y talento que con el nivel correcto de gestión e incentivos se convertirían en una garantía de actualización, desarrollo y respuesta a necesidades específicas de subsectores o empresas turísticas. La gestión de la comunidad sería una de las responsabilidades clave del INVAT.TUR en este proyecto tanto en la creación, como en la dinamización y la gestión de la OpenAppsStore. La Comunidad de Desarrolladores se nutriría fundamentalmente de:

• Meses 1-3 proyecto – Recursos propios INVAT.TUR, empresa/s relacionada/s con el desarrollo del proyecto y empresas locales próximas.

• Meses 4–12 proyecto – Empresas de servicios tecnológicos de la comunidad valenciana, universidades, algunos departamentos tecnológicos de empresas turísticas y tecnólogos independientes.

• A partir del año de vida del proyecto – la comunidad comenzaría a tener una presencia de miembros de fuera de la Comunitat Valenciana verdaderamente significativa.

• A los 24 meses, con la expansión del modelo a otros destinos – dentro y fuera de España – la Comunidad de Desarrolladores podría alcanzar su máximo nivel de contribución con desarrolladores – empresas e individuos – de todo el mundo.

En cada una de las opciones del modelo de implantación de la tecnología propuestas se incluyen como hitos clave de desarrollo:

• HITO Desarrollo de la Comunidad de Desarrolladores

o 1.Forja: 2 meses


20


o 4.Programa incentivo lanzamiento “líderes comunidad”: 1

mes

o Resultado: 2 mejoras y/o adaptaciones

• HITO Expansión de la Comunidad de Desarrolladores




3– Implicaciones, Plazos y Costes de las acciones propuestas

Uno de los objetivos de este documento de conclusiones es poner en contexto y en

secuencia todas las líneas de acción planteadas para la implantación, el desarrollo

y la gestión del mismo.

Todas las estimaciones planteadas en este documento han sido contrastadas en

base a hipótesis de trabajo con especialistas, empresas y proveedores de servicios

y de tecnología con el fin de asegurar el rigor en los rangos planteados.

Debe considerarse, sin embargo, que el arranque del proyecto podrá dar lugar a

desviaciones – no significativas – tanto positivas, en base a una mejor posición

negociadora, como negativas debidas a elementos de ajuste en la implantación o de

información incorporada a posteriori en el proyecto.

La gestión del proyecto OpenApps se propone desde una gestión central

participativa y co-responsable de la Agencia Valenciana de Turismo, el

INVAT.TUR y una representación de líderes sectoriales.

Un consejo directivo no ejecutivo con uno o más “consejeros delegados” con

capacidad ejecutiva tendrán la responsabilidad de mantener la cohesión del

proyecto y su gestión como un todo integrado y coordinado.

21

Al mismo tiempo, se dota al proyecto de recursos y gestión para desarrollar trece

subproyectos que irían desarrollándose en paralelo y cuyos responsables

reportarían al consejo OpenApps INVAT.TUR.

La línea de gestión propuesta precisaría como mínimo de 4 recursos dedicados a

tiempo completo y 2 a tiempo parcial por parte del INVATTUR para la gestión del

proyecto. 3 de ellos tendrían un perfil tecnológico y los otros 3 de gestión.

3.1 – Estrategia y Marketing

Este área incluye los subproyectos OpenApps 1, 2, 3 y 4 descritos en la páginas 9 y

10 de este documento , es decir, los englobados dentro de los capítulos de

Estrategia, Comunicación y Tráfico.

OpenApps 1 - ESTRATEGIA

22

OpenApps 2 y 3 – COMUNICACIÓN

23

OpenApps 4 – TRAFICO

3.2 – Tecnología y Comunidad de Desarrolladores

Aquí quedarían encuadrados todos los proyectos relacionados con la decisión

sobre modelo, plataforma y proveedores, el desarrollo del software y hardware

necesario así como su implantación al sector. El avance en el desarrollo e

implantación de la plataforma permitiría ir desarrollando en paralelo las

dinámicas de la Comunidad de Desarrolladores. Los subproyectos incluidos aquí

irían del OpenApps 5 al OpenApps 13.

24

OpenApps #5 – Selección de PROVEEDOR/es – Condiciones de implantación.

OpenApps #6 – Adaptación CODIGO y preparación del SaaS.

25

OpenApps #7 – Implantación del OpenApps en EMPRESAS Turísticas

OpenApps #8 – Desarrollo de un CIRCUITO FORMATIVO en la PLATAFORMA

26

OpenApps #9 – Desarrollo de CONECTIVIDADES directas con Canales de

Distribución

OpenApps #10 – Desarrollo y Gestión de APIs y FORJAS

27

OpenApps #11 – Dinamización, PRORIZACION y GESTION de Iniciativas de

Desarrollo de Código.

OpenApps #12 – Mantenimiento y Desarrollo del Código Central

28

OpenApps #13 – Lanzamiento del OpenApps Store

4– Plan de Trabajo – Período 2.010 – 2.011

29

HITOS principales año 1

• Decisión sobre la plataforma TECH

• Definición del/los Proveedor/es

• Implantación de la fórmula de transición de monetización del

tráfico

• Finalización del SaaS y arranque de las implantaciones a empresas

• Lanzamiento del plan de Comercialización Integral del Destino

30

Hitos Principales año 2

• Lanzamiento del OpenApps Store

• Dinamización de gestión de aplicaciones

• Hitos de implantación y ratio de adopción en empresas

OpenApps – Invat·tur - Instituto Tecnológico Hotelero5.2 – eCommerce (capacidad de venta...

Documents

Transcript of OpenApps – Invat·tur - Instituto Tecnológico Hotelero5.2 – eCommerce (capacidad de venta...