PMS en la nube o local: guía de decisión para hoteles independientes

¿Cuál es la diferencia real entre la nube y el local?

En un despliegue en la nube, la aplicación y la base de datos se ejecutan en un entorno operado por el proveedor. El hotel accede a través de un navegador o un cliente ligero. Las copias de seguridad, la aplicación de parches y la capacidad son responsabilidad del proveedor. La dependencia del hotel es la ruta de red hasta el proveedor.

En un despliegue local, la aplicación y la base de datos se ejecutan en servidores dentro del hotel. El hotel controla el hardware, la red y el calendario de actualizaciones. La dependencia pasa a la capacidad de TI local: alguien tiene que encargarse del servidor, las copias de seguridad y la ventana de actualización.

El producto funcional puede ser idéntico. Lo que cambia es dónde residen los modos de fallo.

¿Cuándo tiene más sentido la nube?

La nube suele ser la opción predeterminada adecuada para hoteles independientes y grupos pequeños. Elimina el servidor de la lista de riesgos del hotel, facilita los informes multipropiedad y mantiene el software actualizado sin un proyecto cada año.

Es especialmente adecuada cuando el hotel tiene una conexión resiliente, un equipo de TI pequeño y ninguna exigencia normativa de mantener los datos de huéspedes dentro del edificio. También encaja en grupos que añaden hoteles más rápido de lo que pueden crear capacidad de TI.

• El hotel dispone de una ruta de internet principal y de respaldo fiable.
• No hay un equipo de TI interno que se encargue de servidores y copias de seguridad.
• El grupo quiere informes consolidados sin un proyecto de almacén de datos.
• El hotel prevé añadir módulos o habitaciones sin planificar hardware.

¿Cuándo sigue teniendo sentido el local?

El local no está obsoleto. Sigue siendo la opción honesta cuando no se puede confiar en la red, cuando los datos deben permanecer en una jurisdicción o un edificio concretos, o cuando el hotel tiene la disciplina de TI para operarlo correctamente.

El error es elegir local para evitar una suscripción en la nube subestimando el coste operativo: sustitución de servidores, verificación de copias de seguridad, aplicación de parches, energía y una persona responsable.

• La residencia de datos o la política del propietario exigen que la base de datos permanezca en el hotel.
• La WAN es poco fiable y un sistema local es la única forma de mantener la recepción operativa.
• El hotel ya cuenta con una sala de servidores disciplinada y copias de seguridad probadas.
• Se prefiere un modelo de gasto de capital y el coste del ciclo de vida se comprende bien.

¿Qué significa realmente híbrido?

Híbrido suele significar un servidor en el hotel que mantiene la operación local, con los datos sincronizados con un entorno central para informes y servicios de grupo. Si la WAN cae, el registro de entrada, los folios y el housekeeping continúan localmente; cuando vuelve el enlace, las transacciones se concilian.

El híbrido es más complejo que cualquiera de los dos modelos puros, porque hay que diseñar la conciliación entre los datos locales y los centrales. La complejidad merece la pena cuando tanto la resiliencia local como la visibilidad central son requisitos reales.

Un diseño híbrido solo es creíble si alguien puede explicar, en una página, qué ocurre con un folio registrado durante un corte de la WAN y cómo se concilia después.

¿Cómo debería compararse el coste total?

No compare el precio de la suscripción con el precio del servidor. Compare el coste de propiedad a tres años, incluidos la implantación, las interfaces, la renovación del hardware, la copia de seguridad y la recuperación, el esfuerzo de actualización, el tiempo del personal interno y el coste de un cierre fallido.

Una suscripción en la nube que parece más cara al mes puede ser más barata que un despliegue local que exige un servidor nuevo, un sistema de copias de seguridad y el 20 % de una persona de TI. Un despliegue local que parece barato puede volverse caro la primera vez que se necesita una restauración y nadie la ha probado.

• Esfuerzo de implantación y migración de datos
• Desarrollo y mantenimiento de interfaces
• Hardware, energía, refrigeración y ciclo de sustitución
• Copias de seguridad, pruebas de recuperación y aplicación de parches de seguridad
• Tiempo del personal interno para actualizaciones e incidentes
• Exposición a interrupciones durante la auditoría nocturna y las horas punta de llegadas

¿Qué debería incluir el contrato, sea cual sea el modelo?

La etiqueta comercial importa menos que los compromisos operativos. Pídalos por escrito, en lenguaje claro, y asegúrese de que coinciden con cómo funciona realmente su hotel.

• ¿Quién es propietario de los datos y cómo pueden exportarse en un formato utilizable?
• Objetivos de tiempo de recuperación y de punto de recuperación, y cuándo se probaron por última vez.
• Horario de soporte, objetivos de respuesta y la vía de escalado a las 02:00.
• Qué ocurre durante una actualización fallida o un incidente de seguridad.
• Condiciones de salida: plazo de preaviso, extracción de datos, funcionamiento en paralelo y supresión.
• Qué interfaces están incluidas, cuáles se cobran y quién asume un fallo de un tercero.

¿Cómo cambia la decisión de despliegue según el tamaño del hotel?

En un hotel de 10–60 habitaciones, lo habitual es que no haya sala de servidores y rara vez una persona dedicada a TI. El director general, el propietario o un jefe de turno son lo más parecido al soporte técnico, y el personal de recepción cubre recepción, reservas y conserjería en el mismo turno. En ese contexto, la decisión de despliegue tiene que ver sobre todo con la ruta de red y con quién responde a las 02:00. La nube es la opción predeterminada habitual porque saca el servidor del edificio y mantiene las actualizaciones y las copias de seguridad del lado del proveedor. El despliegue local sigue siendo defendible cuando una norma legal o una política del propietario exige que los datos de los huéspedes permanezcan en el hotel, o cuando la única conexión disponible no puede soportar la recepción. Sea cual sea el modelo, hay que documentar qué hace la recepción cuando cae la conexión: qué llegadas se pueden procesar, cómo se emiten las llaves y dónde se registran los cargos hasta que vuelva el enlace. Un hotel pequeño rara vez necesita un segundo centro de datos, pero sí necesita una segunda vía de acceso a internet y una persona concreta a la que llamar. Escriba el procedimiento sin conexión en una página y pruébelo en una semana tranquila, no en una noche de lleno total.

Entre 60 y 250 habitaciones, el hotel gana departamentos, interfaces y patrones de turnos. La recepción funciona 24 horas en tres turnos, y el PMS habla con el POS, las cerraduras, el channel manager, los terminales de pago y a veces con un sistema de spa o de golf. El registro de entrada y el cierre nocturno dependen de esas interfaces, así que los modos de fallo se multiplican aunque el software no cambie. En esta franja la modalidad híbrida pasa a ser una opción real y no un compromiso: un servidor local mantiene la recepción y los puntos de venta operativos durante un corte de WAN, mientras los datos se sincronizan con un entorno central para los informes. También es la franja en la que el hotel suele contar con un generalista de TI o un proveedor de servicios gestionados, lo que cambia la respuesta honesta sobre el despliegue local. La cuestión que hay que resolver no es nube o local, sino qué funciones deben sobrevivir a una pérdida de conexión y cuáles pueden esperar. Si la respuesta incluye el registro de entrada, las cuentas de huésped y la limpieza de habitaciones, la arquitectura debe reflejarlo. Si solo los informes pueden esperar, un despliegue en la nube con un procedimiento sin conexión documentado suele ser más sencillo de operar.

Por encima de 250 habitaciones, y en resorts con varios edificios, el hotel se comporta como un pequeño recinto. Hay múltiples puntos de venta, banquetes, ocio, varios armarios de cableado y un equipo nocturno presente en el sitio en lugar de disponible por teléfono. Las rutas de internet redundantes, una sala de servidores con acceso controlado y una función de TI son expectativas normales a esta escala, y la decisión de despliegue se convierte en un ejercicio de diseño: qué servicios se ejecutan localmente, cuáles de forma central y cómo se concilian ambos cuando falla un enlace. Un resort también puede enfrentarse a normas de datos en el país donde opera, y un grupo puede querer una capa de informes única para hoteles sujetos a normas distintas. Esa combinación es donde lo híbrido justifica su complejidad, pero solo si la conciliación se especifica de antemano. La latencia en la recepción, el comportamiento de los terminales de pago durante un failover y la vía de soporte remoto del proveedor merecen una prueba antes de la apertura, no un párrafo en el contrato. La alimentación y la refrigeración del rack local también pasan a ser responsabilidad de alguien, y esa responsabilidad debe nombrarse en el modelo operativo.

Fije las restricciones vinculantes antes de comparar productos. Primero, las obligaciones de datos: si alguna ley, acuerdo de franquicia o política del propietario exige que los datos de los huéspedes permanezcan en una jurisdicción o en el hotel. Segundo, la realidad de la red: si existen dos rutas realmente independientes y cuándo se probó el failover por última vez. Tercero, la titularidad de la recuperación: quién ejecuta una restauración, con qué frecuencia y qué evidencia se conserva. Cuarto, el coste a tres o cinco años con el mismo alcance, incluidas interfaces, renovación de hardware y tiempo del personal, no solo la línea de suscripción. Quinto, la salida: cómo es una exportación utilizable y cuánto tiempo se permite la operación en paralelo. Estas cinco respuestas suelen reducir la elección a un modelo antes de que se produzca una demostración. Una disciplina útil es escribir la respuesta a cada restricción en un párrafo breve y pedir al proveedor que responda por escrito, no en una presentación. La condición límite es la prueba de las 02:00. Si nadie puede explicar a quién se llama, qué hace la recepción y cómo se concilian las transacciones faltantes, la etiqueta del contrato no salvará la noche.

• ¿Puede la recepción seguir registrando huéspedes durante cuatro horas sin la WAN?
• ¿Existe una segunda ruta de internet y se ha probado el failover este año?
• ¿Exige alguna ley o política del propietario que los datos de los huéspedes permanezcan en el hotel?
• ¿Quién ejecuta una prueba de restauración y dónde se registra el resultado?
• ¿Se comparan los costes a tres o cinco años con el mismo alcance e interfaces?