El giro de timón que nadie quería dar: cómo un grupo hotelero de Sudamérica y el Caribe dejó atrás su deuda tecnológica y construyó la plataforma que lo llevará a todo el continente americano
Propiedades en ciudades y playas de Sudamérica y el Caribe. Sistemas heredados que se ahorcaban solos. Datos dispersos entre 5 plataformas. Huéspedes esperando mientras el PMS cargaba. La historia de un grupo que aplicó exactamente el principio que hace que la IA y la transformación digital funcionen en la realidad: orden, continuidad del negocio, y la misma lógica de romper un monolito — pero sin apagar el hotel.
La industria hotelera tiene un problema tecnológico que lleva décadas acumulando intereses. El Property Management System —el PMS, ese sistema que en teoría es el corazón de cada propiedad— se ha convertido para muchos grupos en una fuente permanente de fricción: con los huéspedes, con el personal, con los canales de distribución y con cualquier nuevo sistema que intente conectarse a él. Opera en sus versiones legacy corre en más de 40,000 propiedades en el mundo. Solo una fracción había migrado a la nube al cierre de 2023. El resto sigue operando sobre infraestructura on-premise con integraciones que se construyeron hace diez o quince años y nunca se actualizaron. El caos no es el estado de excepción: es el estado habitual.
El grupo al que llamaremos HospitaGroup —hoteles de negocios en capitales de Sudamérica, resorts de playa en el litoral del Pacífico y el Atlántico, y propiedades boutique en destinos del Caribe— llegó a ese punto de quiebre después de varios años de invertir en la dirección equivocada. La operación ya abarcaba Colombia, Perú, Chile, Ecuador y tres destinos del Caribe. La visión de la dirección era clara: completar la cobertura del continente americano en los siguientes tres años. El problema era que la plataforma tecnológica que tenían no soportaba las propiedades actuales, mucho menos la expansión. Millones de dólares en una plataforma cloud que prometía resolver la fragmentación y que, en la práctica, la multiplicó. Un equipo de TI que pasaba sus días apagando incendios de integración en lugar de construir capacidades. Y un Director General que, en una revisión trimestral, escuchó al Director de Operaciones describir cómo el proceso de check-in de sus mejores suites tardaba ocho minutos porque el sistema no respondía a velocidad humana. Eso fue suficiente para tomar la decisión que nadie en la sala quería tomar.
El problema de HospitaGroup no era único ni excéntrico. Era estadísticamente normal en el sector hotelero global, lo que lo hacía aún más inaceptable: si la mayoría tiene el mismo problema, quien lo resuelve primero tiene ventaja real.
El diagnóstico real: el ecosistema que se comía a sí mismo
El error de diagnóstico más frecuente en proyectos de transformación hotelera es apuntar al PMS como el villano único. Opera on-premise tenía sus problemas — pero el verdadero ecosistema de dolor era más amplio y más profundo. El grupo había construido a lo largo de los años sistemas propios: módulos de lealtad desarrollados internamente, integraciones hechas a la medida para conectar el CRS con el canal directo, scripts de sincronización entre el POS de F&B y la cuenta de habitación, reportes automatizados sobre bases de datos que nadie había tocado en cuatro años. Cada uno de esos desarrollos fue, en su momento, la solución pragmática a un problema real. Con el tiempo, se convirtieron en cajas negras — funcionan, pero nadie sabe exactamente cómo, y la persona que las construyó ya no está en la empresa.
El riesgo no era solo la falta de documentación. Era el tiempo: las versiones de las herramientas sobre las que corrían esos sistemas propios acumulaban años sin actualización. Frameworks deprecados. Librerías con vulnerabilidades conocidas sin parche disponible. Lenguajes de integración que los proveedores cloud ya no soportan en sus ambientes modernos. El reloj de obsolescencia no avisa cuando llega a cero — simplemente el sistema deja de funcionar en el peor momento posible.
El método: BSC como inspiración, conocimiento del negocio como base
Antes de diseñar la solución, el equipo directivo revisó qué había funcionado en la industria y por qué. El referente más sólido fue Marriott International, que adoptó el Balanced Scorecard de Kaplan y Norton como marco de ejecución estratégica. El resultado fue documentado en múltiples estudios de caso: alineación real entre objetivos financieros, operativos, de cliente y de aprendizaje organizacional que permitió crecer de forma consistente en miles de propiedades manteniendo estándares de servicio. El BSC en Marriott no fue un ejercicio de consultoría — fue el mecanismo que convirtió la visión corporativa en acciones medibles en cada propiedad, cada turno y cada punto de contacto con el huésped.
La inspiración fue clara: si algo así transformó a uno de los grupos hoteleros más grandes del mundo, el marco correcto de medición y ejecución cambia la dirección de toda la organización. HospitaGroup no adoptó el BSC como plantilla — lo usó como principio: cada dominio de la plataforma tiene sus métricas de cliente, operación, finanzas y aprendizaje alineadas. Y el principio rector que ningún marco externo puede sustituir: primero entender el negocio hotelero como es, luego diseñar la tecnología que lo sirve.
El sistema legado que se ahorca solo — y cómo migrar sin dañar la operación
Aquí está la conversación que nadie quiere tener: el sistema legacy no falla de un día para otro. Se ahorca gradualmente. Cada nueva integración que se agrega sobre él lo hace más frágil. Cada parche sobre un módulo desactualizado crea una dependencia que nadie documentó. Cada proceso que se automatizó hace diez años con la lógica de ese momento es hoy una caja negra que el equipo actual opera con cuidado porque "si lo tocas, se cae algo". Y sin embargo, el sistema sigue en producción las 24 horas del año — gestionando cada reservación, cada cargo, cada check-in — porque apagarlo no es una opción.
Este es exactamente el mismo problema que ocurre cuando se migra un monolito de software a microservicios. La solución en arquitectura de software se llama Strangler Fig — y aplica con precisión quirúrgica a la transformación de sistemas legados hoteleros.
La continuidad del negocio no es un proyecto paralelo — es una restricción de diseño
El principal argumento contra la transformación en operaciones 24/7 siempre es el mismo: "no podemos parar". La respuesta correcta no es "haremos el cambio rápido" ni "lo haremos de madrugada". La respuesta correcta es diseñar la migración para que la operación no se interrumpa en ningún momento — con planes de rollback probados para cada etapa, criterios de avance basados en estabilidad operacional (no en calendario), y la certeza de que si algo falla en la transición, el sistema anterior sigue disponible como respaldo activo.
Esta lógica es exactamente la misma que aplica al romper un monolito de software en microservicios: no se apaga el sistema central el viernes para el lunes tener los microservicios funcionando. Se extrae funcionalidad dominio por dominio, se valida en producción paralela, y el monolito se retira cuando ya no sostiene nada que el nuevo sistema no cubra mejor. La higuera estranguladora no mata al árbol de un golpe. Lo rodea hasta que el árbol ya no es necesario.
"La transformación tecnológica más difícil no es la técnica. Es convencer al equipo de operaciones de que la migración no los pondrá en riesgo durante temporada alta. Eso solo se logra con un plan que tenga salida en cada etapa — y cumpliéndolo."— CTO, HospitaGroup
La elección de Microsoft Azure no fue una decisión de preferencia de proveedor. Fue el resultado de evaluar qué plataforma cloud resolvía mejor el problema específico de un grupo hotelero: integrar un ecosistema de sistemas especializados —Opera Cloud, CRS, RMS, channel managers, GDS, agencias, F&B, lealtad, pagos— con una arquitectura que no requiriera reconstruir cada vez que un componente cambia.
El patrón arquitectural elegido fue la plataforma hub como cerebro orquestador: Azure Event Grid y Azure Service Bus como bus de eventos que conecta todos los sistemas existentes y nuevos sin acoplarlos directamente. Opera Cloud no habla con el RMS. Habla con el bus de eventos. El RMS no habla con el CRS. Habla con el bus. Cuando un sistema cambia —o cuando se incorpora un nuevo proveedor de revenue management— el cambio es en el adaptador de ese sistema, no en toda la arquitectura.
🔷 Plataforma hub Azure
Azure API Management como capa de integración gobernada · Azure Event Grid para eventos en tiempo real entre sistemas · Azure Service Bus para mensajería garantizada transaccional · Azure Entra ID para identidad unificada de huéspedes, staff y canales · Azure API Management conectando OHIP (Opera Cloud APIs) y sistemas de agencias GDS
🔷 Datos, IA y analytics
Azure Cosmos DB para el golden record del huésped · Azure Synapse Analytics para analítica de revenue e inteligencia comercial · Azure Machine Learning para pricing dinámico y modelos de demanda · Azure AI Services para experiencia conversacional · Power BI Embedded en dashboards operativos y ejecutivos por propiedad y consolidado
El golden record del huésped: el activo más valioso que nadie estaba protegiendo
Antes de la transformación, los datos del huésped de HospitaGroup vivían en al menos cinco sistemas distintos con definiciones diferentes del mismo concepto. El nombre del huésped en Opera podía no coincidir con el del CRM. Las preferencias capturadas en un resort de playa no llegaban al hotel de negocios donde ese mismo huésped se hospedaba dos semanas después. El historial de consumo en restaurantes no era visible para el equipo de front desk al momento del check-in.
El golden record del huésped en Azure Cosmos DB se construyó como la fuente de verdad única y actualizada en tiempo real: cada interacción del huésped en cualquier canal o punto de contacto genera un evento que enriquece ese perfil en menos de dos segundos. La recepcionista que abre el expediente de un huésped VIP ve, en una sola pantalla, el historial completo de estadías, sus preferencias documentadas, su consumo en F&B, cualquier incidencia resuelta y la nota más reciente del equipo. Por primera vez, el conocimiento del cliente no estaba atrapado en la cabeza de una sola persona ni en el cuaderno de la recepción del resort.
⬡ Gobierno de datos: la condición de entrada, no el proyecto final
Antes de migrar un solo registro de datos históricos a la nueva plataforma, el equipo ejecutó un proceso de gobierno de datos que la mayoría de las empresas pospone indefinidamente. Cada entidad de dato relevante para el negocio hotelero —huésped, reservación, habitación, tarifa, promoción, cargo, pago— fue definida con su modelo canónico, su dueño organizacional, sus reglas de calidad y su ciclo de vida. Los pipelines de integración con Opera Cloud, el CRS y el channel manager no mueven datos: validan, transforman y enriquecen. Un dato que no cumple los contratos de calidad definidos no entra al golden record. Genera una alerta y espera corrección.
Opera Cloud: de fuente de caos a componente integrado
La decisión sobre Opera Cloud fue delicada por la misma razón que cualquier migración de PMS en una operación 24/7: el sistema gestiona cada reservación activa, cada cargo y cada proceso de check-in simultáneamente en todas las propiedades. HospitaGroup decidió no reemplazarlo — decidió integrarlo correctamente por primera vez, propiedad por propiedad, con planes de rollback probados en cada etapa. Sus 3,000 capacidades de API vía OHIP son considerablemente más que las 400 del sistema on-premise legacy, pero la diferencia real es arquitectural: los errores ahora son visibles, rastreables y se corrigen automáticamente sin que el huésped los experimente.
"Con Opera 5 on-premise, cuando algo fallaba teníamos que llamar a quien sabía cómo reiniciar el servidor correcto. Con Opera Cloud integrado vía la plataforma hub, cuando algo falla lo vemos en el dashboard en tiempo real y el sistema lo reintenta automáticamente. El huésped no espera."— Director de Operaciones, HospitaGroup
Pricing dinámico e IA: del ajuste manual de madrugada al motor que nunca duerme
El revenue management hotelero es, en su esencia, un problema de optimización de precios en tiempo real bajo condiciones de demanda cambiante, inventario perecedero y competencia dinámica. Durante años, HospitaGroup resolvió ese problema con una sola persona que llegaba temprano cada mañana, revisaba el pick-up nocturno en tres pantallas y ajustaba tarifas manualmente para el día. Era un proceso que dependía de una persona, tardaba entre 90 minutos y dos horas, y producía decisiones de pricing basadas en información de hace seis horas.
El motor de pricing dinámico sobre Azure Machine Learning opera con datos en tiempo real de ocupación, pick-up, eventos en destino, clima, comportamiento histórico de demanda por segmento, y señales de competencia extraídas vía integraciones de benchmarking. El modelo actualiza tarifas recomendadas por tipo de habitación y propiedad cada 15 minutos. Las reglas de negocio —mínimos de tarifa, restricciones de paridad, fechas de bloqueo— viven en configuración que el equipo de revenue ajusta sin tocar código. El revenue manager que antes pasaba dos horas ajustando tarifas ahora pasa esas dos horas analizando el desempeño de la semana siguiente y definiendo estrategia de temporada.
IA con sentido de negocio: viviendo en la plataforma, no en una factura de API
La decisión sobre IA en HospitaGroup siguió exactamente el principio que distingue a los proyectos de inteligencia artificial que generan valor de los que no llegan a producción: primero el problema de negocio con criterio medible, luego el proceso rediseñado por quienes lo operan, luego los datos gobernados, y al final la tecnología que los potencia. En ese orden, no al revés.
La IA no es una sola cosa — es un portafolio de capacidades distintas que requieren distintas arquitecturas y distintos criterios de uso. En el caso hotelero, la mayor parte de los problemas que la IA resuelve son de patrón, predicción y clasificación, no problemas que requieren modelos de frontera. Modelos propios, entrenados con datos propios del grupo, corriendo en Azure Machine Learning. Agentes conversacionales desplegados en los puntos de fricción real. Visión por computadora para operaciones físicas. Cada capacidad elegida por el problema que resuelve — no por la categoría de moda en la presentación del proveedor.
Y la regla arquitectural que aplica sin excepción: la IA vive dentro de la plataforma, no afuera de ella como dependencia externa. El proveedor del modelo es un parámetro de configuración. Si mañana aparece un modelo más preciso, más económico o con mejor soporte regulatorio en algún mercado de Sudamérica, la plataforma lo adopta sin reescribir la lógica del negocio que lo consume.
💰 Pricing dinámico
Motor de revenue que actualiza tarifas cada 15 minutos con datos de demanda, competencia y eventos. Las reglas de negocio son configurables. Las decisiones rutinarias son automáticas. Las estratégicas, del equipo de revenue.
🧳 Perfil predictivo de huésped
Modelo que predice preferencias, probabilidad de upsell, riesgo de no-show y valor de vida del cliente al momento del check-in. El equipo de front desk ve recomendaciones accionables, no datos crudos.
🎯 Upsell y promociones
Propuestas de upgrade, servicios adicionales y paquetes generadas por IA en el momento correcto del journey del huésped —en la confirmación, en el pre-arribo y al check-in— con probabilidad de conversión estimada por cliente.
🏠 Operaciones predictivas
Modelos de mantenimiento predictivo para equipos críticos (HVAC, elevadores, equipos de cocina). Predicción de ocupación de F&B para gestión de inventario. Optimización de asignación de habitaciones para eficiencia de housekeeping.
💬 Bot de huésped
Agente conversacional en app y WhatsApp que resuelve solicitudes frecuentes en tiempo real: estado de reservación, servicios disponibles, solicitudes de amenities, información de restaurantes. Escala al equipo humano con contexto completo cuando la solicitud lo requiere.
🔍 Detección de fraude en pagos
Modelo de anomalías evaluando cada transacción de pago en menos de 300ms contra patrones de comportamiento del huésped, perfil del canal y reglas PCI. Las alertas llegan al equipo de seguridad con evidencia organizada, no como señales sin contexto.
📊 Revenue intelligence
Dashboards de inteligencia comercial con proyecciones de demanda a 90 días por propiedad y segmento, identificación de oportunidades de segmentación y análisis de displacement entre canales. El gerente general ve el negocio completo en una sola pantalla.
⌨️ Apoyo en desarrollo de código
IA usada como herramienta de apoyo al equipo técnico —nunca para generar componentes completos ni sustituir el criterio arquitectural. Sugerencias de patrones, revisión de pruebas, detección de redundancias y documentación asistida. El desarrollador decide siempre. La velocidad mejoró sin comprometer la calidad.
El estado del procesamiento de pagos en HospitaGroup antes de la transformación era, en el lenguaje de la seguridad, un perímetro extendido no controlado: terminales físicas con versiones distintas de software, tokenización inconsistente entre propiedades, reconciliación manual nocturna con tasas de discrepancia del 3.4% y un cumplimiento PCI que pasaba la auditoría anual con observaciones que se cerraban con compromisos que nadie seguía.
El nuevo stack de pagos está construido sobre Azure Payment HSM con tokenización centralizada y un único vault de claves administrado via Azure Key Vault con rotación automática. Todas las propiedades comparten la misma implementación, lo que significa que el cumplimiento PCI DSS se gestiona una vez, no quince. Los medios de pago digitales —transferencias, wallets, QR— se incorporaron como adaptadores en el API Gateway, visibles para el huésped desde la app y el web con la misma fluidez que el pago con tarjeta física.
Seguridad: NIST, ISO 27001, PCI DSS y la madurez que protege a los huéspedes
NIST CSF
Las cinco funciones desde el diseño de cada componente: identificar, proteger, detectar, responder y recuperar. RTO y RPO definidos por dominio. Playbooks documentados y probados para los escenarios de incidente más probables en una operación hotelera 24/7.
ISO 27001
Sistema de gestión de seguridad de la información con controles documentados por dominio, revisiones anuales independientes y mejora continua auditada. El estándar aplica tanto a la plataforma cloud como a los sistemas on-property que se mantienen en cada hotel.
PCI DSS
Cumplimiento del estándar de seguridad para datos de tarjetahabientes en todos los puntos de pago del grupo —físicos y digitales. Tokenización centralizada, vault unificado de claves, segmentación de red entre el entorno de pago y el resto de la infraestructura.
Cifrado y observabilidad
TLS 1.3 en tránsito. Azure KMS con rotación automática para datos en reposo —incluyendo datos biométricos de acceso sin contacto. Azure Monitor + Application Insights para observabilidad completa. Microsoft Sentinel para SIEM centralizado con correlación de eventos entre propiedades.
La estrategia de migración: gradual, reversible y sin noche de terror
La estrategia de migración: gradual, reversible y sin noche de terror
Como se ilustró en el diagrama del patrón Strangler Fig, la regla no negociable fue una sola: cada etapa debe ser reversible, y el criterio de avance a la siguiente es operación estable — no calendario. Un grupo hotelero con presencia en múltiples países de Sudamérica y el Caribe no puede permitirse que una migración tecnológica afecte la operación en temporada alta de ninguna de sus propiedades. La estrategia de olas resolvió eso con precisión: primero el hub y la propiedad piloto, luego revenue y pagos con expansión al 60% de propiedades, finalmente plataforma completa con lealtad y F&B — y en paralelo, la arquitectura lista para la expansión a Centroamérica y Norteamérica en 2026.
El huésped que ya no tiene que luchar con el sistema
El cambio que el huésped siente no es tecnológico — es humano. Cuando el check-in dura 90 segundos, la recepcionista puede mirar al huésped a los ojos y darle la bienvenida que merece. Cuando el upgrade disponible llega como notificación antes del arribo, el huésped siente que el hotel lo conoce. Cuando pide algo en el restaurante y puede cargarlo a su cuarto sin que nadie tenga que hacer una llamada para confirmarlo, resuelve su necesidad en el momento. Antes, resolver cualquier cosa que implicara cruzar sistemas era un dolor de cabeza para el huésped y para el equipo que intentaba ayudarlo. Hoy es un flujo natural.
"Lo que aprendimos es que nuestro diferenciador nunca fue ni será el sistema. Es la persona que recibe al huésped, la que recuerda que prefiere almohadas firmes, la que resuelve en cinco minutos lo que en otro hotel tardaría un día. La plataforma le da a esa persona el tiempo y la información para hacer bien su trabajo."— Directora General de Operaciones, HospitaGroup
Los resultados del primer año
| Métrica | Antes | Año 1 | Δ |
|---|---|---|---|
| RevPAR consolidado | Base | +18% | vs. mismo periodo anterior |
| Conversión canal directo web | 1.8% | 4.1% | +2.3 pp |
| Tiempo de check-in — socios de lealtad | 8+ min | 90 segundos | −81% |
| NPS promedio del grupo | 41 | 67 | +63% |
| Discrepancias de datos entre sistemas | Diarias / manuales | −74% | Reconciliación automática |
| Conversión de upsell (upgrade + servicios) | 6% | 19% | +13 pp con IA |
| Costo plataforma tecnológica | Base | −34% | Stack unificado en Azure |
| Tiempo de resolución de incidencias operativas | Avg. 47 min | Avg. 11 min | −77% |
Producto, Tech y QA cohesionados — resolviendo negocio, no sistemas
El cambio más visible para el equipo de operaciones de HospitaGroup no fue tecnológico. Fue de agenda: el equipo de tecnología dejó de pasar sus días resolviendo problemas de integración entre sistemas legados y empezó a trabajar en iniciativas de negocio. Esa transición no ocurre automáticamente cuando se instala una nueva plataforma — ocurre cuando Producto, Tech y QA operan como una unidad cohesionada con objetivos de negocio compartidos, no como departamentos con tickets entre ellos.
En el modelo anterior, una solicitud de una nueva funcionalidad para el huésped — un servicio de conserjería digital, una alerta de upgrade disponible, un proceso de checkout exprés — pasaba por tres departamentos, cuatro reuniones de alineación, y terminaba bloqueada porque alguna integración del sistema de lealtad no soportaba la información necesaria. El sistema era el límite del negocio.
Hoy el equipo cross-functional de HospitaGroup tiene una estructura diferente: Producto define la iniciativa con criterio de valor para el huésped y el negocio. Tech la arquitectura y construye sobre la plataforma hub. QA valida no solo que funcione, sino que funcione como el huésped lo necesita. La IA no es un proyecto separado — es una capacidad dentro de la plataforma que el equipo activa cuando resuelve un problema real. Nuevos servicios que antes tardaban trimestres en llegar al huésped ahora tienen ciclos de semanas.
El equipo como ventaja competitiva — no solo la tecnología
Cada líder de dominio tiene experiencia operativa real en hotelería antes de ser líder técnico. El arquitecto de integración fue durante ocho años director de sistemas en una cadena del sector. La responsable de producto del módulo de experiencia del huésped recibió a cientos de huéspedes en el front desk. Ese conocimiento no se construye en un onboarding — se trae al equipo desde el primer día.
El resultado: cuando el equipo diseña una nueva funcionalidad, ya sabe por qué el índice de ocupación a las 2pm importa más que a las 10am, qué significa para el recepcionista tener cinco familias esperando con maletas, y cuánto duele para el huésped que el sistema de cargo del restaurante no sincronice con la cuenta de habitación al hacer checkout. Esa empatía operativa es lo que hace que lo que se construye funcione de verdad — no solo en el demo.
"Antes el equipo de tecnología era el departamento al que llamabas cuando algo fallaba. Ahora es el equipo al que llamas cuando quieres lanzar algo nuevo. Ese es el cambio que ningún software puede producir solo."— Directora General de Operaciones, HospitaGroup
Por Jorge Mercado
Los nombres, cifras operativas y detalles de implementación de HospitaGroup son modificados con fines ilustrativos. Los indicadores sectoriales corresponden a datos reales publicados en el Lodging Technology Study 2024, HotelTechReport (febrero 2026) y Starfleet Research. El patrón Strangler Fig es un patrón de arquitectura de software ampliamente documentado, aplicado aquí en el contexto de transformación de sistemas hoteleros legados.
No hay comentarios.:
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.