Resumen Ejecutivo
El problema principal del Cliente no es la cantidad de herramientas ni la calidad de cada una por separado: es un problema de modelo, y tiene dos caras. La primera es la ausencia de un modelo de datos corporativo que permita que esas herramientas hablen entre sí, se actualicen de forma coherente y generen inteligencia accionable; hoy cada sistema sabe lo que sabe, pero nadie, ni humano ni máquina, tiene una visión consolidada del huésped, del empleado o del edificio. La segunda es que el núcleo tecnológico sobre el que se ha construido la operación durante dos décadas, el PMS personalizado a medida, ha llegado al final de su recorrido, y plantea una decisión estratégica que ya no admite aplazamiento.
El Cliente ha construido, en los últimos diez años, una cultura de innovación honesta: adopta herramientas porque cree en ellas, no por presión comercial. Eso es un activo diferencial. El reto ahora es pasar del modelo de "herramienta por herramienta" al modelo de "plataforma": donde los datos fluyen, las integraciones son explícitas y las personas dedican su tiempo a decidir, no a copiar y pegar.
El diagnóstico identificó tres categorías de hallazgos: (1) concentración de conocimiento crítico en personas sin sustituto formal; (2) riesgos legales y operativos activos que requieren intervención inmediata; y (3) oportunidades de transformación digital que, con las decisiones correctas en los próximos 12 meses, pueden redefinir la capacidad competitiva del Cliente. Sobre ese diagnóstico, el informe formula una recomendación estratégica de fondo, la dirección que debe tomar el núcleo tecnológico, y un roadmap priorizado en tres horizontes para ejecutarla.
Tres alertas prioritarias
El Cliente opera con al menos once Puntos Únicos de Fallo (SPoF) humanos: personas cuya ausencia detendría procesos críticos sin recuperación inmediata. el Responsable PMS-ERP (EdocAssistant, cierre contable diario y herramientas financieras propias), el Técnico BMS (BMS Circutor), el Director de Ingeniería (ingeniería e instalaciones) y la Responsable de Nóminas (nóminas) son los casos más urgentes.
El Cliente comunica su impacto positivo externamente, memoria corporativa y certificación B Corp, sin disponer hoy de una base de indicadores con trazabilidad documentada, fuentes verificables y metodología consistente. Los datos de residuos están parcialmente corrompidos (más de 15.000 registros en formato no analizable), los consumos energéticos se registran a mano desde facturas físicas, y los indicadores de personas tuvieron fuentes divergentes hasta hace dos o tres años. La normativa europea de greenwashing exige respaldo verificable para cada declaración de impacto: esta situación es una exposición legal y reputacional real que debe resolverse antes de la próxima publicación de la memoria corporativa.
Las integraciones entre sistemas son mayoritariamente manuales o inexistentes. El inventario tecnológico no está documentado exhaustivamente. La llegada de Duetto (enero 2026) y la situación de Cendyn (post-adquisición por Amadeus) abren ventanas de decisión que exigen criterio estratégico antes de fin de 2026.
Recomendación estratégica central
Antes de cualquier nueva herramienta, el Cliente necesita definir su modelo de datos corporativo: qué entidades son maestras (huésped, empleado, edificio, reserva), quién es el propietario de cada una y qué sistema es la fuente de verdad. Con ese modelo como brújula, muchas decisiones tecnológicas, cómo consolidar el CRM, cómo unificar la formación, qué herramientas conservar y cuáles retirar, se vuelven evidentes en lugar de debatibles.
La decisión de mayor calado es qué hacer con el núcleo tecnológico. El modelo de personalización a medida sobre el que se construyó el PMS ya no es sostenible: las personas que lo programaban, el soporte del partner y el propio control del código fuente han desaparecido casi a la vez. La dirección recomendada no es reconstruir ese modelo, ni adoptar una suite cerrada de gran cadena, sino un modelo de componentes intercambiables, una plataforma cloud componible que el Cliente adapta configurando, no programando, con la decisión del Front (el PMS) desacoplada de la del Back (el ERP). No es una elección de producto que deba tomarse de forma unilateral, sino una recomendación que una evaluación formal debe confirmar dentro de 2026.
Tanto el modelo de datos como la decisión del núcleo se rigen por un mismo principio rector, que la Dirección General ha fijado para toda la transformación: personalización sí, dependencia no. Ninguna solución, por correcta que sea técnicamente, debería generar una atadura nueva, con un proveedor, una plataforma o una persona. El grado de dependencia que crea cada opción debe pesar, en la evaluación de cualquier escenario, tanto como su coste o su funcionalidad.
Stakeholders Entrevistados
Las siguientes diez personas participaron en el proceso de diagnóstico, representando el 100% de las áreas funcionales con impacto tecnológico directo en el Cliente.
Director General
Visión estratégica, cultura, tolerancia al riesgo, decisiones de inversión tecnológica.
Responsable IT / CTO de facto
Azure, Power Platform, integraciones, seguridad, gobernanza, arquitectura corporativa.
Dir. Gral. / Ref. PMS-ERP
QuoHotel (PMS front), Dynamics (ERP back), EdocAssistant, transición hacia jubilación.
Directora Revenue & Distribución
Duetto (RMS), SiteMinder (channel mgr), Mirai (directo), estrategia de pricing, OTA mix.
Responsable Marketing Digital
GA4, Cendyn CRM, HiJiffy, tracking server-side, Customer 360, IA conversacional.
Responsable Lean & Operaciones
Power Platform 40+ apps, automatización, flujos operativos, "fábrica de soluciones".
Coordinadora Lean
Metodología lean hotelera, criterio físico vs. digital, implementación en campo.
Responsable Impacto Positivo
Indicadores ambientales, herramientas ESG, Power App de residuos, riesgo greenwashing.
Director Ingeniería y Mantenimiento
BMS Circutor, Schneider EcoStruxure, DHK, mantenimiento preventivo, eficiencia energética.
Dirección Personas & Bienestar
Viterbit, Nivimu, HRider, Happyforce, 3 LMS, nóminas, selección, formación, bienestar.
Arquitectura Tecnológica Actual
La infraestructura tecnológica del Cliente se organiza en tres capas con niveles de madurez muy distintos. La capa de infraestructura es sólida y moderna; la capa de sistemas de negocio es funcional pero fragmentada; y la capa de analítica e integración es el principal cuello de botella.
Infraestructura y Nube
El Cliente completó su migración a Azure en 2017, convirtiéndose en una de las primeras cadenas hoteleras independientes de España en operar el 100% de su infraestructura en la nube. Esto supone una base sólida para cualquier iniciativa de transformación digital: no hay datacenters locales que gestionar, los costes de infraestructura son variables y la capacidad de escalar es inmediata.
La red está articulada a través de 6 centros conectados por VPN (Palma como hub central, más los hoteles principales, otras propiedades de la cadena), protegida por 12 firewalls Fortinet. El parque informático es de aproximadamente 100 ordenadores y 60 dispositivos móviles corporativos.
Sistemas de Negocio
El núcleo de los sistemas de negocio está compuesto por QuoHotel (PMS front-end sobre SQL) y Microsoft Dynamics (ERP back-end), que son sistemas distintos con una historia de integración propia. Es importante no confundirlos: la decisión de cambiar el PMS (QuoHotel) y la decisión sobre el ERP (Dynamics) son decisiones independientes con implicaciones, plazos y riesgos diferentes.
Sobre esta base operan los sistemas especializados por área: Duetto (Revenue Management, activo desde enero 2026), SiteMinder (Channel Manager), Mirai (motor de reservas directas), Cendyn (CRM, 100.000+ contactos), HiJiffy (chatbot WhatsApp), Lighthouse (inteligencia competitiva), Revi Pro (reputación online) y EdocAssistant (gestión documental con 20.000+ facturas anuales).
En el ámbito de personas: Viterbit (ATS), Nivimu (HRM), HRider (evaluación del desempeño) y Happyforce (clima organizacional con HI actual de 73/100, objetivo 75). En ingeniería y mantenimiento: el BMS energético Circutor (in-house) que monitoriza el consumo de los cinco hoteles; el control climático Schneider EcoStruxure, integrado en algunos hoteles y pendiente en otras propiedades; y DHK (registro de incidencias, caso de éxito). En formación: tres plataformas LMS independientes (Turiscool, Scoolinary, Preply) sin integración entre ellas.
Datos e Integración
Existe un data warehouse en Azure que consolida datos del PMS mediante procesos nocturnos en SQL. Sin embargo, su alcance es limitado: no cubre datos de CRM, reputación, sostenibilidad, formación ni RRHH. La herramienta RevTool (Power BI sobre HotelDataFlow) consume este warehouse para producir el informe de Revenue, pero no hay una arquitectura de datos corporativa que defina entidades maestras, propietarios de datos ni reglas de calidad.
Las integraciones entre sistemas son, en su mayoría, manuales o semi-manuales. No existe un bus de integración ni una capa de orquestación de datos. Cada equipo ha desarrollado sus propias soluciones workaround, muchas de ellas a través de Power Apps y Power Automate, lo que ha creado un ecosistema funcional pero frágil, difícil de mantener y prácticamente imposible de auditar sin el conocimiento de las personas que lo construyeron.
Inventario de Sistemas por Área
| Categoría | Herramienta | Estado | Notas clave |
|---|---|---|---|
| PMS Front-End | QuoHotel | Operativo | Único sistema con acceso completo a reservas. Sin API documentada pública. |
| ERP Back-End | Microsoft Dynamics | Operativo | Financiero y contable. Decisión independiente del PMS. Integración manual. |
| Channel Manager | SiteMinder | Operativo | Conecta OTAs. Decisión de no integrar con Mirai (intencional). |
| Motor Reservas Directas | Mirai | Operativo | Resultados positivos en conversión directa. Gap: no comparte datos de huésped con CRM. |
| Revenue Management | Duetto | Activo ene-2026 | En fase de consolidación. Recoge rates de SiteMinder. Gap: no recibe datos de CRM. |
| CRM | Cendyn | Riesgo activo | 100.000+ contactos. Post-adquisición por Amadeus: riesgo de cambio de política/precios. |
| Chatbot WhatsApp | HiJiffy | Operativo | Buena acogida. Coexiste con SpeakSpot (solapamiento). Oportunidad de consolidación. |
| Inteligencia Competitiva | Lighthouse | Operativo | Datos de mercado para pricing. Complementa Duetto. |
| Reputación Online | Revi Pro | Operativo | Gestión de reviews. No integrado con CRM ni Revenue. |
| Gestión Documental | EdocAssistant | Operativo | 20.000+ facturas/año. Proveedor: el proveedor del sistema. Custodio único: el Responsable PMS-ERP (SPoF). |
| Data Warehouse | Azure DW (SQL nocturnos) | Alcance limitado | Solo datos PMS. No cubre CRM, RRHH, sostenibilidad ni formación. |
| Analytics Revenue | RevTool (Power BI/HotelDataFlow) | Operativo | Informe Revenue diario. Pickup manual intencional (5-7 min/hotel/día). |
| Power Platform | 40+ aplicaciones (el Responsable Lean) | Ecosistema activo | Desarrollo low-code interno con gobernanza intencional (cuenta de servicio corporativa, documentación, traspaso). el Responsable IT asumió la gobernanza formal en ene-2026. |
| ATS (Selección) | Viterbit | Operativo | Gestión de candidatos. Activación de integración API con Nivimu pendiente. |
| HRM | Nivimu | Operativo | Gestión de personal. Integración con Viterbit sin activar. |
| Evaluación Desempeño | HRider | Operativo | Sin integración con Nivimu ni Happyforce. |
| Clima Organizacional | Happyforce | Operativo | HI actual 73/100. Objetivo 75. Custodio: la Directora de Personas (SPoF). |
| LMS Formación | Turiscool + Scoolinary + Preply | Fragmentado | Tres sistemas sin integración. Registros manuales. la Directora de Personas no tiene visibilidad total. |
| Incidencias Ingeniería | DHK | Caso de éxito | Adoptado rápidamente. Buen ejemplo de digitalización operativa. |
| BMS energético | Circutor (in-house) | SPoF crítico | Monitorización energética de los 5 hoteles. Custodio único: el Técnico BMS. Datos en servidor local sin backup corporativo. Sin documentación técnica. |
| Control climático | Schneider EcoStruxure | Operativo | Termostatos por habitación integrados en el BMS en los hoteles principales; integración pendiente en otras propiedades. |
| ATS/RRHH | Dokify | En evaluación | Control de documentación de proveedores. Estado de uso no confirmado. |
Hallazgos por Área
El diagnóstico recoge los hallazgos de las nueve áreas funcionales entrevistadas. Selecciona una pestaña para leer el análisis completo de cada área.
El Director General aportó al diagnóstico la dimensión cultural y estratégica que da sentido a todos los demás hallazgos. el Cliente no es una empresa que tecnifica por presión del mercado; es una empresa que tecnifica cuando cree que la herramienta sirve a su modelo de negocio y a sus personas. Esta filosofía es, al mismo tiempo, la mayor fortaleza y el mayor riesgo de la organización.
La conversación con el Director General reveló una claridad estratégica que no siempre llega con la misma nitidez a las capas operativas: el Cliente quiere ser un empleador de referencia en el sector hotelero, donde las personas no hagan trabajo mecánico que pueda hacer una máquina. el Director General enmarca este modelo en el paradigma organizativo Teal, sostenido sobre tres pilares: propósito, autonomía y plenitud de las personas, y de ese marco se desprende una consecuencia tecnológica directa: la tecnología debería habilitar la autonomía, no limitarla. Hoy ocurre lo contrario. La complejidad de los sistemas actuales produce el efecto inverso al deseado, en lugar de liberar criterio y tiempo, obliga a las personas a depender de procesos opacos y de otras personas. Cualquier herramienta que no libere tiempo humano de valor no encaja con el modelo.
Asociada a esa visión hay una distinción que el Director General formula con franqueza: la eficiencia es un resultado, no un objetivo. Cuando una persona es autónoma y se realiza en su trabajo es más feliz y, como consecuencia, más eficiente. el Cliente cometió hace años el error de plantear el Lean como un programa de reducción de costes, y aprendió que ese encuadre vacía la metodología de su sentido. Es una advertencia que el roadmap de transformación debe tener presente: cualquier iniciativa tecnológica que se presente como un ejercicio de ahorro, y no como una forma de devolver capacidad y criterio a las personas, chocará con la cultura de la casa.
El Director General identificó dos lecciones aprendidas que el equipo directivo debe tener presentes en cualquier decisión tecnológica futura. La primera es la experiencia de Aplanet, la plataforma de sostenibilidad adoptada y posteriormente abandonada, que demostró que la adopción sin apropiación genera coste sin beneficio. La segunda es la proliferación de Power Apps sin gobernanza, que creó soluciones útiles pero dejó un legado de dependencias opacas. De ambas extrae un mismo diagnóstico: las herramientas son la consecuencia, no la causa; lo que llevó al Cliente a esta situación fue no haber trabajado con un proceso y un gobierno claros. Y sitúa el punto de rotura con precisión: los proyectos no fracasan en la implementación, sino en la definición. Si algo no se define bien desde el principio, el resto saldrá mal y el mantenimiento acabará pagando el coste de todos los errores anteriores.
De ese aprendizaje se deriva el principio rector que el Director General pide aplicar como filtro de toda decisión: personalización sí, dependencia no. el Cliente puede y debe adaptar la tecnología a su modelo, pero ninguna solución debería ser tan propietaria, atada a un proveedor, a una plataforma o a una persona, que genere una nueva forma de dependencia. Una opción puede ser técnicamente correcta y, aun así, culturalmente ruinosa si crea esa atadura. El grado de dependencia que genera cada escenario debe pesar tanto como su coste o su funcionalidad.
Hay un dato que el Director General señala como el más valioso para la dirección, por encima de cualquier métrica operativa o financiera: la respuesta a la pregunta de quién es el cliente objetivo del Cliente, no en sentido estadístico, sino en sentido de valores. El huésped que comparte la filosofía del Cliente, y no el que la elige solo por precio o ubicación, tiene un NPS estructuralmente superior, un coste de adquisición menor, llega por recomendación y una rentabilidad más predecible. el Cliente ha intentado definir ese perfil en el pasado sin conseguirlo, por falta de método y de datos integrados. El modelo de datos corporativo que recomienda este informe debe incluir, como objeto prioritario, la construcción de ese perfil de cliente objetivo. Esta necesidad de la Dirección General converge exactamente con la fricción que identifica el área de Marketing, la ausencia de una visión unificada del huésped que cruce PMS, CRM, canal de reserva y comportamiento en el hotel: son dos formulaciones del mismo problema estratégico.
En cuanto a los próximos pasos, el Director General tiene claridad sobre las grandes decisiones que se avecinan: la posible sustitución del PMS, la situación de Cendyn tras su adquisición por Amadeus, y la necesidad de un modelo de datos que permita ver al huésped de forma completa. Lo que pide es un proceso estructurado para tomar esas decisiones, no una recomendación unilateral y, además, un proceso relativamente corto, que permita empezar a decidir y a trabajar con criterio en un plazo cercano. Describe también con precisión el perfil que el Cliente necesita para sostener la transformación: un especialista en tecnología, no en un área concreta del negocio, capaz de actuar como puente entre el negocio y los proveedores, un perfil interno, con visión de conjunto y con la simplicidad como criterio de filtro. No pide un organigrama, sino las competencias que la transformación exige; la estructura vendrá después.
El Responsable IT lleva veinte años al frente de la tecnología de la compañía y ha sido el arquitecto de buena parte de la infraestructura que hoy sostiene la operación. Bajo su responsabilidad, el Cliente completó la migración íntegra a Microsoft Azure en 2017, implantó y gobierna el ecosistema Microsoft 365, integró el PMS con Duetto, SiteMinder y el CRM, diseñó la arquitectura de red multi-sede protegida por Fortinet, y sostiene el programa de ciberseguridad y cumplimiento RGPD de la cadena. Prepara además, por iniciativa propia, el despliegue de Microsoft Purview para la clasificación automática de documentos por nivel de sensibilidad, un proyecto a la espera de aprobación económica de la Dirección. Es el único con visión transversal de qué herramienta conecta con qué, y acaba de asumir la gobernanza de Power Platform, un ecosistema de más de 40 aplicaciones creadas por el Responsable Lean, que hasta enero de 2026 operaba sin supervisión IT formal.
Esta trayectoria importa para interpretar correctamente su rol: el Responsable IT no es un técnico que se limita a ejecutar, sino el responsable que ha conducido la transformación digital del Cliente durante dos décadas, decidiendo con criterio estratégico qué capacidades desarrollar internamente y cuáles externalizar. El conocimiento que ha acumulado en ese tiempo, sobre el ecosistema, los proveedores, la historia de cada decisión técnica y el modelo operativo de la cadena, es un activo que no se encuentra en el mercado: cualquier perfil externo necesitaría entre 12 y 18 meses para aproximarse a esa comprensión.
"Solo pido que me digan las reglas del juego. Si me pides que sea el bombero, no juguemos a encender cerillas mientras tanto."
— el Responsable IT
Esta frase sintetiza la tensión central de su rol: el Responsable IT es llamado a resolver emergencias técnicas constantemente, pero no siempre tiene la autoridad formal para prevenir que esas emergencias ocurran. El origen de esa tensión es organizativo. La función IT depende hoy de la Dirección Financiera, sin un canal formal con el Comité de Dirección ni acceso al plan estratégico de la empresa. Por eso, las ausencias que un diagnóstico tecnológico señala, la falta de un plan tecnológico corporativo, de un modelo de datos formal, de un cuadro de mando unificado, no reflejan una limitación de capacidad ni de voluntad del Responsable IT, sino una posición organizativa que nunca le atribuyó ese mandato. El gap es de posición y autoridad, no de competencia. La recomendación que se deriva no es sustituir ese liderazgo, sino elevarlo: dar a la función IT la posición organizativa, la autoridad formal y el apoyo estructural que la próxima fase de transformación exige, de modo que los criterios técnicos del Responsable IT se conviertan en política organizacional respaldada por la Dirección.
Shadow IT — el problema no reconocido
El Responsable IT acaba de asumir, hace aproximadamente un mes al momento de la entrevista, la gobernanza de Power Platform, que antes gestionaba el Responsable Lean sin coordinación formal con IT. Esto no es shadow IT en el sentido peyorativo (las aplicaciones son útiles y están bien construidas), pero crea un ecosistema de dependencias que solo el Responsable IT y el Responsable Lean conocen, y que nadie más puede mantener o extender de forma segura.
El inventario de Power Apps activas supera las 40 aplicaciones. No existe documentación técnica centralizada de las integraciones entre ellas. Cuando se produce un fallo en una de estas apps, el único camino de recuperación es llamar al Responsable Lean o al Responsable IT. Ese es, por definición, un SPoF sistémico.
Conviene precisar que el Responsable IT no plantea esto como una oposición a que el negocio desarrolle sus propias soluciones, (reconoce el valor de lo que se ha construido); lo que reclama es un marco de reglas claras: quién puede desarrollar, con qué aprobación, cómo se documenta y cómo se pasa a producción. Es, en sus propias palabras, la única cosa que cambiaría en los próximos doce meses. El plan de gobernanza de Power Platform recogido en las recomendaciones de este informe responde directamente a esa petición: no busca limitar la capacidad de innovar con low-code, sino darle las condiciones para que sea sostenible.
Capa de datos — alcance real del warehouse
Existe un data warehouse en Azure que consolida datos del PMS mediante procesos SQL nocturnos. Este warehouse alimenta RevTool (la herramienta de Revenue de Power BI). Sin embargo, su alcance es estrictamente limitado al PMS: no incluye datos de CRM, reputación, formación, RRHH ni sostenibilidad. Esto significa que el Cliente tiene fragmentos de datos en silos y no tiene una vista integrada de ninguna entidad crítica del negocio.
El Responsable IT es, además, el primero en señalar el recorrido disponible: tanto en la captura del dato como en la analítica, el Cliente tiene margen para crecer de forma considerable, y ve en la inteligencia artificial un terreno de oportunidad real, siempre que se aborde de forma conjunta entre IT y negocio.
Infraestructura — fortalezas y brechas
La base de Azure es una fortaleza genuina. La migración al 100% en la nube completada en 2017 pone a el Cliente en una posición favorable para cualquier modernización: no hay que migrar datacenters, no hay que gestionar hardware físico, y la capacidad de provisionar nuevos entornos es inmediata. Los 12 firewalls Fortinet proporcionan un perímetro de seguridad adecuado, aunque la gestión de credenciales corporativas no está estandarizada (ausencia de un gestor de contraseñas como 1Password Business).
La brecha principal está en la gestión de identidades y el control de acceso: quién tiene acceso a qué sistema, con qué privilegios, y qué ocurre cuando alguien abandona la empresa. Sin un directorio de identidades corporativas bien gestionado, el offboarding de empleados crea riesgos de acceso residual.
El Responsable PMS-ERP es el interlocutor más informado sobre la arquitectura de sistemas de back-office del Cliente. Su visión sobre el PMS, el ERP y los sistemas de soporte es la más matizada del diagnóstico: distingue con precisión dónde hay riesgo real, dónde no lo hay, y dónde la organización tiende a sobreestimar o subestimar la complejidad.
El Responsable PMS-ERP no es un punto único de fallo para el PMS ni para el ERP a nivel funcional: el conocimiento de aplicación está compartido con el Responsable IT desde la migración de hace más de un año, y el mantenimiento de las personalizaciones y nuevos desarrollos recae en el partner de Microsoft, el partner tecnológico del PMS. el Responsable PMS-ERP ya no tiene acceso a la fuente del código. Sí queda, en cambio, una capa más profunda que sigue dependiendo de él y que no está documentada, el SQL Management del PMS: servidor, estructura de tablas, conectores y lógica de negocio acumulada en la base de datos, que requiere una sesión de documentación específica antes de su salida.
PMS front-end (QuoHotel) vs. ERP back-end (Dynamics): dos decisiones distintas
Esta distinción es fundamental y el Responsable PMS-ERP la formula con claridad: cuando el Cliente habla de "el PMS", en realidad está hablando de dos piezas diferentes con lógicas, proveedores y decisiones independientes. QuoHotel es el PMS front-end (reservas, check-in, check-out, producción, facturación) y Microsoft Dynamics es el ERP back-end (contabilidad, compras, inventarios). Mews, por ejemplo, es un PMS y no tiene nada del back; si el Cliente migra a Mews, Dynamics puede mantenerse intacto.
La decisión de cambiar el PMS y la decisión sobre el ERP son independientes y deben tratarse por separado. Mezclarlas crea una complejidad artificial que paraliza la toma de decisiones. La opción de sustituir únicamente el Front (manteniendo el Back en Dynamics) es la más reversible y la menos costosa de las posibles, y es además la práctica habitual en la industria hotelera moderna.
El PMS corre on-prem — una situación anómala que tiene fecha de caducidad
Actualmente el PMS opera on-premises como una excepción activa a la política de Microsoft. A nivel de código, la versión es 100% cloud y la migración técnica podría hacerse en cualquier momento. La razón por la que no se ha hecho hasta ahora es de prudencia estratégica: el Cliente ha preferido esperar a que grupos hoteleros más grandes hagan el paso primero y validar el proceso.
Sin embargo, el Responsable PMS-ERP es claro: esta situación es anómala y no puede mantenerse indefinidamente. La política de Microsoft no permite la convivencia de versiones distintas, y más pronto que tardel Cliente tendrá que regularizar su situación. Esta migración al cloud no es una decisión a tomar; es una obligación a planificar. La ventaja es que técnicamente no hay barreras: el trabajo es de gestión del cambio, no de ingeniería.
Power Apps — la documentación existe
Contrariamente a lo que podría parecer desde fuera, el ecosistema de Power Apps del Responsable Lean no es una caja negra sin documentación. el Responsable Lean dedicó varios meses a documentar las aplicaciones antes de traspasarlas a el Responsable IT.
Sin embargo, el Responsable PMS-ERP introduce una distinción importante que el diagnóstico debe reflejar: hay dos categorías de Power Apps con naturaleza muy diferente. La primera categoría son aplicaciones que resuelven problemas sencillos y específicos con volúmenes de datos reducidos (menos de 2.000 registros, que es el límite natural de Power Apps). La segunda categoría son aplicaciones que sustituyen o complementan funcionalidades del PMS con grandes volúmenes de datos (principalmente Inventarios y Pedidos). Estas últimas están operando fuera del ámbito natural de Power Apps y deberían migrarse a alternativas estándar del marketplace de Dynamics.
BookingNew — un sustituto disponible que no se usa
El informe BookingNew (que el Responsable PMS-ERP mantiene como Excel) cubre en gran medida la misma información que RevTools. el Responsable PMS-ERP ha identificado que el recambio lleva años disponible, pero el equipo comercial prefiere continuar con BookingNew por comodidad y porque es más fácil filtrar y copiar datos. Esta es una decisión operativa válida a corto plazo, pero crea una dependencia de Excel que no aporta valor diferencial y que conviene eliminar en algún momento.
EdocAssistant — el sistema de mayor valor filosófico
EdocAssistant sí representa un área donde el conocimiento del Responsable PMS-ERP es genuinamente relevante. El sistema nació de una conversación en 2007 entre el Director General y el Responsable PMS-ERP: "¿cómo liberamos a las personas cualificadas del trabajo mecánico de gestionar facturas?" una pregunta que anticipa lo que hoy se llama automatización de procesos. El resultado es un sistema que hoy procesa más de 20.000 facturas de proveedor al año de forma automatizada, gestiona la imputación de cobros de clientes y cierra el triángulo documental de las compras: Pedido, Factura y Albarán. Esa validación a tres bandas es lo que permite a el Cliente gestionar las compras de sus cinco hoteles con una sola persona, frente a las tres personas por hotel habituales en el sector. El proveedor el proveedor del sistema es el socio técnico que mantiene el sistema.
La custodia de la relación con el proveedor del sistema y el conocimiento de las excepciones y configuraciones de EdocAssistant es donde existe una dependencia real del Responsable PMS-ERP. A ello se suman dos procesos financieros que también recaen sobre él: el cierre contable diario, la importación, cada mañana, de las facturas del día anterior del PMS al ERP, sin la cual la contabilidad deja de actualizarse, y las herramientas de reporting financiero que ha desarrollado a lo largo de los años, una dependencia que él mismo está mitigando con la configuración de un complemento nativo de Dynamics antes de su salida. Estos son los puntos que merecen un plan de transferencia prioritario, y son más urgentes que cualquier preocupación sobre el PMS, cuyo conocimiento ya está compartido con el Responsable IT y cuyo mantenimiento recae en el partner tecnológico del PMS.
El problema real de las nóminas — integración, no personas
Una corrección importante que el Responsable PMS-ERP señala afecta al diagnóstico de nóminas. El problema no es que la Responsable de Nóminas sea la única persona que sabe procesar las nóminas (aunque eso también merita atención); el problema raíz es la ausencia de integración entre Nivimu (el sistema de gestión de personal) y la gestoría externa (que elabora las nóminas). Actualmente, la gestoría envía una plantilla (todavía en Excel) con todos los datos necesarios para elaborar la nómina, y el equipo interno construye un proceso manual para alimentar esa plantilla.
El error de diseño ha sido tratar de optimizar el proceso de llenado de la plantilla sin atacar la causa raíz, que es la ausencia de integración. Existe ya un grupo de trabajo interno analizando esta situación. La recomendación es que ese grupo evalúe la integración directa Nivimu ↔ Gestoría como objetivo primario.
La pregunta del Responsable PMS-ERP sobre la transformación
El Responsable PMS-ERP cierra con una reflexión que merece espacio en el diagnóstico: más que definir cargos y organigramas, le interesa saber qué responsabilidades y habilidades considera necesarias el diagnóstico para llevar a cabo la transformación tecnológica. Esa es la pregunta correcta. Las competencias primero; la estructura después.
La Directora Revenue dirige el área que, probablemente, tiene el mayor nivel de madurez tecnológica del Cliente en relación con sus objetivos. La incorporación de Duetto en enero de 2026 es un salto cualitativo significativo: el Cliente pasa de un pricing basado en hojas de cálculo a un sistema de Revenue Management científico que combina datos históricos, pickup en tiempo real e inteligencia de mercado.
"El pickup lo hacemos a mano a propósito. Quiero que el equipo entienda el dato, no que lo lea de un dashboard."
— la Directora Revenue
Este matiz es fundamental para interpretar correctamente la situación tecnológica del área. El hecho de que el equipo dedique entre 5 y 7 minutos por hotel al día a introducir manualmente el pickup diario no es una ineficiencia a corregir: es una decisión pedagógica y de cultura analítica. Antes de automatizar este proceso, la Directora Revenue quiere que el equipo tenga un entendimiento visceral de lo que significa cada dato.
Duetto — de validador manual a motor de pricing
Duetto, el sistema de Revenue Management del Cliente, está activo desde enero de 2026: apenas tres meses en el momento de este diagnóstico. El equipo está en una fase de aprendizaje activo y, por ahora, las recomendaciones de tarifa no están automatizadas, cada propuesta se revisa manualmente antes de aceptarla, ajustarla o descartarla.
La fricción principal no es la calibración del modelo, sino su opacidad. Duetto propone un precio pero no explica con claridad el razonamiento que hay detrás. En casos en los que recomienda subir tarifas con baja ocupación y sin pickup apreciable, el equipo no dispone del contexto para confiar en la recomendación y acaba recurriendo a su propio criterio. El efecto es que el Cliente está usando un RMS de coste considerable como validador pasivo, no como motor de decisión: se paga por una capacidad que se aprovecha solo en parte.
Resolver esto no es una cuestión de tiempo, sino de configuración y formación. La acción recomendada para la primera fase del roadmap es un workshop de onboarding técnico con el equipo de Duetto con tres objetivos: entender la lógica del modelo de recomendación; configurar las reglas de negocio propias de el Cliente (eventos en los hoteles principales, cierre de temporada, mix de canal por hotel); y definir criterios de aceptación automática para los escenarios de menor riesgo, de modo que el pricing de baja complejidad deje de requerir intervención manual. Conviene recordar, además, que Duetto es un sistema del que se puede prescindir operativamente: si fallara, el equipo cargaría las tarifas directamente en SiteMinder como hacía antes. Su criticidad es de valor, no de continuidad.
La conexión PMS↔SiteMinder — una decisión de Revenue Management
La conexión entre el PMS y SiteMinder es unidireccional por decisión estratégica explícita del equipo de Revenue, no por una limitación técnica. Revenue carga el inventario en el Channel Manager, pero las ventas que se realizan en el Channel no descuentan automáticamente el inventario del PMS. Esta arquitectura responde a un modelo deliberado de gestión de cupo: en lugar de abrir toda la disponibilidad en todos los canales a la vez, Revenue libera cupo de forma gradual para gestionar subidas de precio, aplicar restricciones por canal y evitar que entren grupos por OTA en momentos de alta ocupación.
Como consecuencia, el PMS muestra siempre más reservas que el Channel Manager: la diferencia corresponde a reservas no conectadas, contratos tradicionales, reservas telefónicas, tarifas negociadas con empresas. Ese desajuste es esperado y no constituye un error de integración. La opción bidireccional está disponible técnicamente; el equipo ha decidido conscientemente no activarla. Es importante que este punto quede documentado como una decisión de diseño: cualquier intervención técnica futura que modifique el comportamiento de esta conexión, en particular en el contexto de una eventual migración de PMS, donde la bidireccionalidad suele venir activada por defecto, debe ser validada explícitamente por la Revenue Manager antes de implementarse.
Conviene también precisar el ownership: el contrato de SiteMinder es del área de Revenue, no de IT, cada hotel tiene su propia cuenta y la gestión diaria es cien por cien de Revenue. IT intervino únicamente en la conectividad inicial. Cualquier decisión sobre el Channel Manager debe tener a la Directora Revenue como propietaria.
El cockpit fragmentado y los quick wins de automatización
El equipo de Revenue toma decisiones combinando cinco fuentes que no están integradas entre sí: RevTool (análisis retrospectivo, con actualización aproximadamente diaria y latencia D-1), Booking New (un Excel mantenido manualmente que funciona como proxy intradía, porque permite refrescar el dato en cualquier momento), la Pickup Sheet, Lighthouse (precios de la competencia) y las recomendaciones de Duetto. Esta fragmentación es funcional, pero tiene un coste de tiempo que el diagnóstico debe nombrar y, sobre todo, dos automatizaciones evidentes que pueden abordarse de inmediato con las herramientas ya contratadas.
La primera es el informe semanal de Revenue. Cada Account prepara manualmente, a partir del Booking New, el informe de su hotel para la llamada semanal con dirección: producción frente a objetivo, ocupación y ADR, mix de canal y detalle de venta web. Es el proceso que más tiempo consume al área, del orden de 3 a 4 horas semanales para el conjunto del equipo, sobre datos que ya existen en RevTool y Booking New. No es un proyecto complejo: es construir el template que hoy nadie ha construido. La segunda es el Excel que la Revenue Manager prepara cada lunes con la producción bruta por canal para que Marketing la cruce con Google Analytics 4, un cruce necesario mientras GA4 siga perdiendo dato por las restricciones de cookies; una exportación programada desde RevTool o SiteMinder lo eliminaría.
Una tercera oportunidad, de horizonte algo mayor, es la gestión de los siete buzones de correo que el área administra, el propio, los de reservas de los cinco hoteles y el genérico del Cliente. El volumen de peticiones estándar (disponibilidad, condiciones de tarifa, información de habitaciones) consume tiempo de un equipo cualificado. Es, en palabras de la propia la Directora Revenue, la aplicación más clara de la IA en su área: automatizar la respuesta a esas peticiones recurrentes liberaría al equipo para tareas de mayor valor. HiJiffy, que ya canaliza peticiones de la web hacia esos buzones, puede ser la capa conversacional que filtre y clasifique las peticiones antes de que requieran respuesta manual.
El gap Revenue ↔ CRM
El talón de Aquiles del área Revenue es la desconexión con el CRM corporativo. No existe ninguna integración formal entre los datos de reserva que gestiona Revenue, canal de origen, tarifa, estancia, perfil de gasto, y los perfiles de cliente. Esto impide hacer Revenue Management personalizado y, sobre todo, impide responder a una pregunta de impacto directo en la rentabilidad: ¿qué clientes con perfil de cliente conocido siguen reservando por OTA en lugar de hacerlo por el canal directo?
Esa pregunta se vuelve crítica con el lanzamiento, ya en marcha, del club de fidelización. Sin integración Revenue ↔ CRM, el programa de lealtad no podrá medir su propio impacto: se evaluará por el volumen de altas, no por lo que de verdad importa, cuántos clientes fidelizados se reconvierten de la OTA al canal directo. Las comisiones OTA representan entre el 15 y el 20% del valor de cada reserva, de modo que cada cliente reconvertido tiene un efecto financiero medible. La recomendación es abordar la integración en dos fases: primero un cruce manual de datos Revenue-CRM para dimensionar el problema, y después la automatización de la detección y de los flujos de re-engagement por canal directo. Es una de las recomendaciones de mayor impacto económico de este diagnóstico.
El área de Marketing Digital es la más expuesta a la paradoja de la fragmentación tecnológica del Cliente: tiene acceso a datos de todos los touchpoints digitales del huésped (web, email, WhatsApp, redes sociales), pero esos datos viven en silos que no se hablan. El resultado es que el Responsable Marketing toma decisiones de marketing con información parcial, sin poder ver el journey completo del cliente desde el primer clic hasta el check-out.
Tracking digital — la base está rota
El punto de partida de cualquier estrategia de marketing digital es la medición. Actualmente, el Cliente no tiene implementado el tracking server-side, lo que significa que una parte significativa de las conversiones y del comportamiento de usuarios no se está capturando correctamente. Las restricciones de cookies de terceros y los bloqueadores de anuncios están dejando fuera del radar datos que existen pero no se registran.
El tracking server-side no es una mejora técnica opcional; es el prerequisito para cualquier análisis de ROI de marketing digital que pretenda ser fiable. Lo que está en juego no es menor: con una inversión de alrededor de 30.000 euros en metasearch (Google Hotel Ads, Trivago, Kayak), el Cliente genera del orden de 500.000 euros en reservas directas. Sin atribución fiable, ese retorno se gestiona casi a ciegas y cada euro de paid media se optimiza sobre datos incompletos. el Responsable Marketing tiene en análisis, junto con la agencia la agencia digital, un proyecto de tracking server-side que traslada el dato de atribución a servidores propios del Cliente para recuperar la trazabilidad de las conversiones. Es una iniciativa estratégica, no un ajuste técnico menor.
Cendyn — el riesgo CRM post-adquisición
Cendyn, el CRM del Cliente con más de 100.000 contactos activos, cambió de propietario tras su adquisición por Amadeus, y desde esa operación el nivel de soporte se ha degradado de forma apreciable. La herramienta sigue plenamente operativa, pero sin el respaldo técnico y comercial que tenía antes. Su perfil de riesgo ya no es el de un SaaS estable, sino el de un proveedor en sunset operativo: funciona, pero sin garantía de evolución ni de una respuesta adecuada ante una incidencia grave de integración o de configuración.
El riesgo no es la interrupción inmediata del servicio, sino la capacidad de reacción. el Cliente depende por completo de Cendyn para sus campañas de email, la segmentación de audiencias y la gestión del ciclo de vida del cliente; una incidencia que el soporte no resuelva con agilidad podría paralizar la actividad de marketing activo durante días. La recomendación es evaluar en paralelo, ya en la primera fase del roadmap, alternativas como Revinate o Dailypoint, plataformas de CDP+CRM especializadas en hotelería independiente, con mejores integraciones nativas con PMS modernos, y preparar un plan de migración de los contactos hacia una plataforma con soporte activo.
El journey digital del huésped — una decisión de plataforma pendiente
Marketing opera hoy tres plataformas con funcionalidades solapadas en la comunicación digital con el huésped: HiJiffy, chatbot con IA en web y WhatsApp, en uso y con buenos resultados en la fase pre-estancia; SpeakSpot, comunicación por WhatsApp durante la estancia, en piloto; y la propia capa de IA que el motor de reservas Mirai está incorporando para el pre y el durante de la estancia. HiJiffy y SpeakSpot suman en torno a 13.000 euros anuales en licencias. El problema no es el coste, sino la incoherencia: tres plataformas pueden acabar hablando con el mismo huésped en momentos distintos, sin un criterio común de experiencia ni una integración compartida con el PMS y el CRM. Definir cuál de ellas se desarrolla como canal único del journey digital, y descontinuar las demás, es la decisión tecnológica más urgente del área de Marketing. Los criterios de selección deberían ser tres: cobertura funcional del journey completo (pre-reserva, estancia y post-estancia), profundidad de integración con PMS y CRM, y capacidad de personalización a partir del perfil del huésped. Canary Technology se ha identificado como referencia de mercado de journey centralizado, pero la evaluación debe contemplar también la opción de consolidar sobre una de las plataformas que ya están en uso.
el Digital Manager y la agencia digital — concentración del ecosistema digital comercial
El Digital Manager es el Digital Manager de Marketing y concentra el conocimiento operativo de cuatro sistemas de alto impacto en la venta directa: el CRM Dynamics: configuración de segmentaciones, flujos automáticos e integración en tiempo real con el PMS, Cendyn:gestión de los 100.000 contactos y ejecución de todas las campañas de email y newsletters, Google Tag Manager: el sistema de atribución de toda la inversión en paid media, incluido el metasearch, y los dashboards de Power BI de Marketing. Su salida sin un plan de transferencia previo interrumpiría la capacidad de lanzar campañas y de medir el retorno de la inversión publicitaria. Es un punto único de fallo de impacto comercial equivalente al de los identificados en infraestructura, PMS o personas, y debe incorporarse al mismo protocolo de documentación y transferencia de conocimiento.
A esa concentración interna se suma una dependencia externa: la agencia digital gestiona la web, el Google Tag Manager, el SEO técnico y los cuadros de Looker Studio, con acceso directo a la configuración técnica. Cualquier cambio estructural en la web pasa por ella. No es un riesgo de continuidad inmediata, pero sí una dependencia que conviene documentar: la salida de la agencia, o un conflicto contractual, afectaría directamente a la capacidad del Cliente de modificar su web y de medir el rendimiento de su paid media.
Customer 360 — la visión que falta
La aspiración del Responsable Marketing es coherente con la estrategia del Cliente: conocer al huésped de forma completa a lo largo de todo su ciclo de vida. Hoy, el dato de marketing (campañas, clics, aperturas de email) vive en Cendyn; el dato de reserva, en el PMS; el dato de experiencia en el hotel es fragmentario, repartido entre la Stay App y el chatbot; y el dato de satisfacción post-estancia, en Revi Pro. Nadie ve todo esto junto, y por eso preguntas básicas, quién hizo el check-in online, quién abrió el WhatsApp de bienvenida, qué consumió en el hotel, si ha vuelto, hoy no tienen respuesta.
Conviene distinguir esta necesidad de la del reporting de dirección. La fragmentación del dato se ha descrito en este informe sobre todo como un obstáculo para la toma de decisiones directivas, la falta de una fuente única de verdad. Para Marketing el problema es otro, aunque relacionado: la incapacidad de segmentar, personalizar y medir la recurrencia del cliente. Lo que Marketing necesita es un perfil unificado del huésped que cruce PMS, CRM, canales digitales y datos de consumo interno. Construir ese Customer 360 no requiere un sistema nuevo: requiere definir qué dato es el maestro de cliente, cómo se actualiza y qué herramientas consumen esa vista unificada. Esa decisión de arquitectura de datos es el primer paso, y converge con la prioridad estratégica que la Dirección General ha situado en el centro: saber quién es el cliente objetivo del Cliente.
El área Lean es, paradójicamente, la que ha generado más innovación tecnológica interna en el Cliente, el ecosistema de Power Apps del Responsable Lean supera las 40 aplicaciones, y también la que enfrenta el riesgo más sistémico de dependencia de personas. La relación entre el Responsable Lean y la Coordinadora Lean es complementaria y necesaria: el Responsable Lean aporta el pensamiento de sistemas y la capacidad de construir soluciones digitales; la Coordinadora Lean aporta el criterio de qué debe vivir en la pared del hotel y qué debe vivir en un dashboard.
Hay cosas que tienen que estar en la pared del hotel, visibles. Si lo metes en un dashboard, nadie lo mira.
la Coordinadora Lean
Esta observación de la Coordinadora Lean tiene implicaciones directas para el diseño de cualquier herramienta operativa en el Cliente. El criterio no es "digital vs. analógico"; es "¿qué soporte garantiza que esta información llegue a quien tiene que llegar en el momento en que la necesita?". En algunos casos es una pantalla; en otros es un papel en la pared del office.
El ecosistema low-code — gobernanza intencional, no Shadow IT
El Responsable Lean ha construido en los últimos años un ecosistema de más de 40 aplicaciones y automatizaciones en Power Platform que dan soporte a procesos operativos que los sistemas comerciales no cubren: el Daily de hotel, las Solicitudes de Administración, la gestión de primas, la Agenda, los Pedidos, los Inventarios, los partes de camareras, los uniformes y los escandallos, entre otros. Estas aplicaciones son genuinamente útiles y tienen adopción real en los hoteles.
No es Shadow IT porque no se adopta a espaldas de IT; lo que el Responsable Lean ha hecho es desarrollo low-code interno con conocimiento pleno de IT y decisiones de gobernanza tomadas con criterio desde el inicio: una cuenta de servicio corporativa única (la cuenta de servicio corporativa) para todas las automatizaciones, en lugar de cuentas personales, sesiones de documentación grabadas, un Excel de inventario de las propias apps y un traspaso estructurado al Responsable IT con grupos de seguimiento de incidencias. Esa cuenta de servicio corporativa es, de hecho, una de las buenas prácticas que este informe recomienda a otras áreas: aquí ya está implementada.
El riesgo de este ecosistema, por tanto, no es de ausencia de gobernanza ni de abandono, conviene distinguirlo con claridad del legado de la anterior responsable de digitalización, cuyas aplicaciones sí quedaron inoperables por falta de documentación y traspaso. El riesgo de las apps del Responsable Lean es de formalización: convertir una gobernanza informal pero intencional en un modelo estándar, documentado y sostenible con independencia de cualquier persona.
La app de Inventarios y los quick wins operativos
Entre las soluciones del ecosistema, la app de gestión de inventarios de almacén es el caso de uso de mayor impacto operativo del diagnóstico. Antes de su implementación, el cierre mensual de inventario exigía contar físicamente y teclear en Excel hasta 1.200 referencias en las cocinas durante el verano, un proceso lento, propenso a error y dependiente de personal cualificado. La app actual usa lectura de código de barras con búsqueda por nombre, funciona en modo offline con sincronización posterior y vuelca los datos directamente en la tabla de inventario del PMS, eliminando el Excel intermedio. Está implantada en tres hoteles (tres hoteles de la cadena) y los demás siguen con el proceso manual. Estandarizar este sistema en los hoteles restantes es una acción prioritaria de la primera fase del roadmap: el bloqueo no es técnico, sino de tiempo y de acompañamiento presencial en la implantación. Ese momento de estandarización es, además, la ocasión adecuada para confirmar que la capa de datos sobre la que se apoya es la correcta para el volumen que maneja en plena temporada.
Conviene evitar aquí una confusión de términos que puede colarse en el roadmap: una cosa es el inventario de las Power Apps, catalogar las aplicaciones existentes, y otra distinta es la app de Inventarios, el sistema de gestión de stock. Son dos acciones diferentes y ambas deben figurar de forma explícita.
El Responsable Lean identificó además dos quick wins de bajo esfuerzo y alta visibilidad para los equipos. El primero son los partes de ropa de las camareras: hoy una persona baja treinta minutos antes del turno, recoge los partes de todas las camareras, los suma a mano y los teclea en Excel, en paralelo a DHK; el proceso es eliminable con Power Query y solo está bloqueado por una duda técnica sobre la tabla de DHK que conviene resolver como primer paso. El segundo es la comida de personal: los empleados se apuntan en una pizarra o en papel y el chef copia la lista a mano; una app sencilla en tablet, estimada por el Responsable Lean en pocos días de desarrollo, elimina el papel y el retrabajo del chef. Ambos son candidatos directos de la primera fase del roadmap.
La fricción el Responsable Lean–IT y la adopción real
La tensión entre el Responsable Lean e IT no se resuelve con más capas de aprobación. el Responsable Lean formula la causa raíz con precisión: lo que necesita no es un proceso, sino información, que IT documente todo aquello que el PMS ya ofrece, para tenerlo presente antes de ponerse a desarrollar. El conflicto nace de una asimetría: el Responsable Lean conoce a fondo lo que existe en low-code, pero no siempre tiene visibilidad de lo que el PMS resuelve de forma nativa. Por eso, antes de añadir entornos formales y procesos de aprobación, el modelo de gobernanza necesita un quick win concreto: un catálogo de las capacidades nativas del PMS, qué procesos cubre, qué tablas existen, qué está ya resuelto. Documentar lo que no hace falta construir es, desde el punto de vista de la gobernanza preventiva, tan importante como documentar lo ya construido.
Hay además un punto ciego que el inventario de apps no captura: la diferencia entre una app implantada y una app realmente en uso. el Responsable Lean descubrió, visitando un hotel, que un equipo había vuelto al proceso manual sin comunicarlo a nadie; la app seguía figurando como activa. La resistencia al cambio en hotelería rara vez es ruidosa, el usuario no se queja, simplemente deja de usar la herramienta. Sin métricas de uso es imposible saber cuántas de las más de 40 apps están vivas y cuántas se han abandonado en silencio. Una auditoría de adopción real debería ser una de las primeras acciones del partner, y el CoE Kit de Microsoft debe incorporarse no como herramienta genérica sino como instrumento para medir uso efectivo frente a uso declarado.
Los errores que he tenido han sido casi siempre en la fase inicial: querer ir rápido y dar la solución antes de haber entendido bien el problema. Lo que no se debería perder es el contacto directo con el terreno.
el Responsable Lean
De ahí se derivan dos principios que conviene elevar a norma del modelo de gobernanza. El primero: ninguna solución low-code nueva debería aprobarse sin una visita al proceso real sobre el terreno, diseñar para un equipo sin ver cómo trabaja es la causa más frecuente del abandono silencioso. El segundo: la estandarización de las apps existentes debe ir precedida de una revisión de su diseño y su experiencia de uso, porque replicar una app con errores de diseño replica también los errores. En la fase de formalización de la gobernanza, el papel del Responsable Lean debería ser explícito: propietario técnico del inventario de aplicaciones y responsable de la auditoría de adopción real, por ser quien mejor conoce qué funciona, qué falla y qué usan de verdad los hoteles.
La Responsable de Impacto es la responsable de toda la estrategia de sostenibilidad del Cliente, indicadores ambientales, reporte ESG, certificaciones, gestión de residuos, y es el caso más claro de concentración de conocimiento crítico sin respaldo. No hay nadie más en la organización que tenga su comprensión del sistema de métricas de sostenibilidad del Cliente, de qué datos son fiables y cuáles no, y de qué compromisos ambientales se han adquirido con terceros.
Yo sé qué datos tenemos y qué datos nos inventamos. El problema es que nadie más lo sabe.
la Responsable de Impacto Fernández
La aplicación de registro de residuos exportó más de 15.000 registros (2023-2025, todos los hoteles) en formato texto en lugar de numérico, y con las fechas sin configurar como fechas. Esto invalida los datos para cualquier análisis: no se pueden calcular kilos por fracción ni por hotel, no se pueden construir series temporales y no se puede reportar el indicador de residuos a los directores. No es un riesgo de continuidad a planificar: es una emergencia activa que bloquea hoy un objetivo corporativo y exige intervención en las próximas semanas.
La Power App de residuos — auditoría y corrección urgente
La persona que configuró la Power App, a través del proceso de digitalización, con el Responsable Lean como intermediario con el partner, ya no está en la empresa, y no existe documentación técnica de cómo está montada. la Responsable de Impacto y el Responsable IT trabajan en la corrección, pero sin un roadmap definido. Hay además dos agravantes. El primero: la Power App de evaluación de alimentos comparte arquitectura con la de residuos y probablemente arrastra el mismo fallo de tipo de dato, está pendiente de auditoría. El segundo: los datos históricos de 2023, que la Responsable de Impacto introdujo manualmente antes de crear la app, también están afectados; si no son recuperables, el Cliente tendría que reconstruir tres años de indicadores de residuos, justo el tipo de serie temporal que la certificación B Corp exige.
La corrección debe abordarse como la primera prioridad técnica del área antes de septiembre de 2026, con cuatro pasos: auditar los 15.000+ registros con el Responsable IT para determinar qué es recuperable; corregir los tipos de dato en la pipeline Power App → Excel; auditar la Power App de evaluación de alimentos con el mismo criterio; y no construir ningún dashboard de impacto hasta que la base de datos esté validada como numérica y consistente.
El proceso de la memoria y la carga sobre la Responsable de Impacto
El Cliente tiene compromisos de reporte de más de 250 indicadores de sostenibilidad, de los cuales la Responsable de Impacto gestiona directamente alrededor de 170 para la memoria corporativa y la certificación B Corp. La elaboración de la memoria es un proceso de entre uno y uno y medio meses que solo la Responsable de Impacto conoce de principio a fin: de dónde viene cada dato, cómo se calcula, cómo se concilia y qué significa cuando hay una anomalía. La mayor parte de ese tiempo se va en buscar, consolidar y validar datos, no en interpretarlos. la Responsable de Impacto asume incluso indicadores de otras áreas, como los de suministros, porque sabe que si no los recoge ella no los recogerá nadie.
Este proceso es, en la práctica, el equivalente en el área de Impacto al cierre contable diario de el Responsable PMS-ERP: una tarea crítica y periódica que depende por completo de una persona. La diferencia es de ritmo, el cierre diario detiene la contabilidad en horas; el de la memoria solo se manifiesta una vez al año, pero las consecuencias de no poder completarla son de largo plazo, porque afectan a la certificación B Corp y a la credibilidad del reporte de impacto. Documentar el proceso de la memoria mientras la Responsable de Impacto está disponible, fuentes, conversiones, reconciliaciones y criterios de trazabilidad, es una acción de continuidad tan necesaria como la transferencia del cierre diario.
Buena parte de la carga procede de un patrón que conviene nombrar: el del "Excel bonito" frente al "Excel operativo". Distintas áreas entregan a la Responsable de Impacto hojas de cálculo con un formato visual cuidado pero sin estructura de base de datos, cabeceras con celdas combinadas, fórmulas mezcladas con datos, columnas sin tipo definido. Antes de poder extraer cualquier estadística, la Responsable de Impacto tiene que reconstruir esos Excel desde cero. No es un problema de gobernanza ni de Shadow IT, sino de alfabetización de datos, y se resuelve con una guía mínima de una página, co-creada con la Responsable de Impacto, que defina la estructura exigible a cualquier Excel que alimente un indicador de impacto.
Aplanet y el modelo de datos de impacto
El Cliente adoptó Aplanet como plataforma de gestión de sostenibilidad y la abandonó después de unos dos años. La lectura habitual de ese episodio, adopción sin apropiación, es correcta pero incompleta. La razón de fondo, tal y como la formula la Responsable de Impacto, es estructural: sin un modelo de datos homogéneo previo, ningún SaaS de sostenibilidad funciona. Aplanet no encajó porque la estructura de los datos del Cliente, Excel heterogéneos, Power Apps con tipos de dato incorrectos, fuentes de consumos no homogéneas entre hoteles, 250+ indicadores con metodologías dispares, no era compatible con ninguna plataforma de reporting.
De ahí se deriva una recomendación que debe preceder a cualquier inversión en herramientas de impacto: antes de contratar un nuevo SaaS, construir un dashboard o ampliar las Power Apps, el Cliente tiene que definir su modelo de datos de impacto normalizado. Eso significa fijar, para cada indicador irrenunciable de B Corp y de la memoria, su fuente primaria verificable, el responsable de su recogida y validación, la periodicidad, el formato y tipo de dato, y el criterio de trazabilidad que exige la normativa de greenwashing. Es un trabajo de entre cuatro y seis semanas, co-diseñado por la Responsable de Impacto y validado por IT, y es el que evita repetir la experiencia de Aplanet: una herramienta que falla no por mala elección, sino porque los datos de entrada nunca tuvieron la estructura necesaria.
Sobre ese modelo normalizado, y solo entonces, tiene sentido construir un dashboard de impacto centralizado: una vista comparativa entre hoteles de los indicadores clave (residuos por fracción, consumos energéticos, indicadores de personas), con actualización automatizada donde sea posible y un campo de trazabilidad por indicador. Ese dashboard eliminaría el grueso del trabajo manual de consolidación de la memoria, permitiría detectar anomalías durante el año en lugar de descubrirlas al cerrarla, y aportaría la evidencia documentada que la normativa de greenwashing exige.
Quick wins de impacto
Tres mejoras de bajo coste y alto impacto pueden abordarse de inmediato. La primera: normalizar el acceso a la herramienta de IA de clasificación de residuos. Existe una herramienta que orienta al personal sobre en qué contenedor va cada residuo, pero no tiene un acceso formal; el personal de los hoteles consulta a la Responsable de Impacto por WhatsApp personal, incluso en fin de semana. la Responsable de Impacto ya ha construido un site de SharePoint de residuos, con el enlace a la herramienta, los procedimientos y los contactos de los gestores, que solo está pendiente de aprobación interna. Aprobarlo y publicarlo, y añadir un código QR en los puntos de recogida de cada hotel, elimina la dependencia del WhatsApp personal y crea un canal formal y auditable.
La segunda: los consumos energéticos. Hoy se introducen manualmente en Excel a partir de facturas físicas, sin sistema conectado a contadores, y con unidades no homogéneas entre hoteles (litros, m³, kWh) que obligan a conversiones manuales. Un error de conversión se propaga directamente a la huella de carbono reportada, uno de los indicadores de mayor visibilidad externa. Documentar una tabla de factores de conversión por hotel es una mitigación inmediata que no requiere tecnología nueva, en paralelo a la automatización de la captura a medio plazo.
La tercera es de cumplimiento de datos: la Responsable de Impacto procesa hoy contenido de impacto en ChatGPT con una cuenta institucional universitaria, no corporativa. Dado que el Cliente ya dispone de Copilot en su licencia de Microsoft, migrar ese flujo de trabajo a la herramienta corporativa es un quick win de compliance sin coste adicional.
Conviene además registrar dos observaciones de proceso. La primera: la lista de proyectos de impacto en SharePoint que la Responsable de Impacto construyó es la herramienta que mejor funciona del área, un repositorio estructurado, con tipos de dato correctos y sin dependencia de soporte externo, y es un buen modelo a replicar. La segunda: tanto el site de residuos como una lista de políticas con alertas de renovación son soluciones ya construidas que permanecen bloqueadas a la espera de aprobación corporativa, lo que obliga a la Responsable de Impacto a mantener Excel paralelos mientras tanto. El cuello de botella, en estos casos, no es técnico sino de proceso de aprobación interna, y conviene tratarlo como tal.
La capa de gestión energética — Circutor y EcoStruxure
La gestión energética del Cliente se apoya en dos sistemas complementarios: el BMS Circutor, que monitoriza el consumo de los cinco hoteles, y el control climático Schneider EcoStruxure, integrado en los hoteles de los hoteles principales y pendiente de completar su integración en otras propiedades. Para el área de Impacto la relevancia es directa: ambos sistemas son la fuente primaria de los datos de consumo energético que alimentan los indicadores de la memoria corporativa y la certificación B Corp. Completar la integración de EcoStruxure y migrar el histórico del BMS a infraestructura corporativa —ambas tratadas en el área de Ingeniería— son condiciones para que esos indicadores dejen de depender de la captura manual.
El Director de Ingeniería dirige el área de Ingeniería, Calidad y Medioambiente, una de las más críticas para la operación hotelera y una de las más invisibles desde la perspectiva tecnológica corporativa. El área gestiona los edificios físicos del Cliente, climatización, electricidad, agua y energía, el cumplimiento reglamentario de las instalaciones y el control de calidad, y su tecnología está, en muchos casos, más avanzada de lo que la organización reconoce.
el Director de Ingeniería — treinta años de conocimiento sin respaldo
El Director de Ingeniería lleva treinta años en el Cliente y es la persona con mayor conocimiento transversal del estado físico y técnico de los cinco hoteles. Concentra, sin respaldo documentado: los contratos de mantenimiento negociados por volumen (ascensores, desinfección, alarmas, climatización), el calendario de inspecciones reglamentarias obligatorias, la validación técnica de las facturas de obra, cuyo volumen puede superar los dos millones de euros en períodos de reforma, la arquitectura del BMS energético, el seguimiento del proyecto de reducción de emisiones y relaciones con proveedores construidas a lo largo de tres décadas. Es un punto único de fallo de la misma magnitud que los identificados en IT, finanzas o impacto, con una particularidad que lo hace más urgente: una intervención quirúrgica programada a corto plazo. La continuidad del área durante su ausencia exige un conjunto de acciones previas a la cirugía, detalladas en el roadmap y la aceleración del checklist de hotel que el Director de Ingeniería ya está construyendo: un documento que centraliza planos, instalaciones, equipos, licencias de apertura, certificaciones e inspecciones, y que es exactamente el mecanismo de transferencia de conocimiento tácito que esta situación requiere.
El riesgo de continuidad más inmediato del área no es tecnológico sino físico: el ACS, el agua caliente sanitaria. Una avería a primera hora de la mañana puede dejar a varios cientos de huéspedes sin posibilidad de ducharse, una crisis operativa más inmediata que la caída de cualquier sistema informático. El plan de contingencia del ACS por hotel debe estar documentado y ser accesible sin depender del Director de Ingeniería. A ello se añade que entre un 20 y un 30% de la documentación técnica de las instalaciones sigue en papel o corresponde a documentación de obra original que ya no refleja tres décadas de modificaciones, una carencia que un técnico externo que intervenga en ausencia del Director de Ingeniería sufriría de inmediato.
El Técnico BMS es el único que sabe cómo funciona el BMS por dentro. Si él no está, no hay nadie.
el Director de Ingeniería Sintes
El BMS Circutor y la dependencia del Técnico BMS
El BMS (Building Management System) del Cliente es Circutor, un sistema construido internamente, algo inusual en el sector, por el Técnico BMS, responsable de Servicios Técnicos del otro de los hoteles. No es una herramienta de monitorización pasiva: integra entre veinte y treinta contadores inteligentes por hotel, electricidad, agua, gas, fotovoltaica y grupo electrógeno en tiempo real, permite el control remoto de las instalaciones (arranque y parada de calderas, consignas de climatización, rearme de alarmas) sin desplazamiento físico, y compara curvas de carga entre hoteles y períodos. Su coste fue de unos 1.500 euros de licencia única, frente a soluciones de mercado equivalentes que pueden superar los 50.000. La ventaja del modelo in-house es la autonomía: cada vez que se añade un equipo nuevo, el propio equipo de el Cliente lo incorpora, sin depender de un proveedor externo.
Esa misma virtud es su riesgo. el Técnico BMS es el único con conocimiento completo de la arquitectura del Circutor: los contadores instalados, los parámetros de configuración de cada hotel y el histórico de modificaciones. No hay documentación técnica ni un segundo técnico capaz de operar el sistema en modo de contingencia. Además, los datos del BMS residen en un servidor local cedido por IT, sin integración en la infraestructura corporativa y sin backup documentado, y ese histórico de consumos es la base del proyecto el objetivo de reducción de emisiones y de la certificación ISO 14001. Las acciones necesarias son dos: documentar la arquitectura completa del BMS (contadores por hotel, parámetros, manual de operación) mientras el Técnico BMS está disponible, y migrar los datos históricos al entorno Azure gestionado por el Responsable IT para garantizar su continuidad y trazabilidad.
EcoStruxure — la palanca de eficiencia energética
Sobre la capa de monitorización del Circutor opera el sistema de control climático Schneider EcoStruxure, del que el Cliente es partner. Consiste en termostatos cableados en cada habitación que permiten ver y gestionar, desde el BMS, la temperatura, el estado y las curvas de las últimas horas de cada estancia. Su relevancia no es de confort sino económica: el aire acondicionado representa entre el treinta y el treinta y cinco por ciento del coste eléctrico de cada hotel, y EcoStruxure es la principal palanca para gestionarlo activamente.
El sistema está plenamente integrado en los hoteles principales de la cadena. otras propiedades de la cadena disponen de termostatos incluso más avanzados, pero su integración con el servidor central del BMS aún no se ha completado. Cerrar esa integración es un quick win de eficiencia energética: la infraestructura ya está parcialmente instalada y el impacto sobre el principal componente del coste eléctrico es directo.
La pipeline de suministros y el proyecto de reducción de emisiones
La gestión de suministros depende hoy de un trabajo manual estructural. Cada mes, el Director de Ingeniería dedica entre dos y tres tardes a recopilar seis datos por hotel, electricidad, gas, gasóleo, agua, fotovoltaica y estancias, corregir el desfase entre la fecha de factura y el mes de consumo real, y generar el informe de consumos para direcciones, managers e la Responsable de Impacto. Los datos están disponibles: el Circutor tiene los contadores en tiempo real y las facturas se descargan ya de aplicaciones digitales. Una integración entre esas fuentes y el Excel de suministros, con una regla automática de asignación del desfase, eliminaría ese trabajo manual.
Conviene incorporar aquí un matiz que el Director de Ingeniería formula con claridad y que debe ser un principio de diseño de cualquier automatización de reporting: la captura y el cálculo pueden automatizarse, pero la publicación del informe exige un paso de validación humana explícita. Automatizar sin ese paso no ahorra tiempo de control, solo traslada el riesgo de un error no detectado.
Este pipeline alimenta el proyecto de reducción de emisiones, el compromiso del Cliente de reducir un 80% sus emisiones de CO₂ en ocho años respecto a 2018. El seguimiento es hoy enteramente manual: el Director de Ingeniería extrae los consumos, les aplica coeficientes de emisión en una hoja de cálculo y produce el informe. El proyecto concluye en 2026, algunos hoteles ya están cerca del objetivo y los más avanzados superan el estándar europeo de referencia, el 50% de reducción a 2030, y el Cliente no dispone todavía de un marco de objetivos de sostenibilidad para 2027 en adelante. Esa es una laguna de gobernanza estratégica, no técnica: afecta a la certificación ISO 14001, que exige objetivos de mejora continua, y a la memoria corporativa. La secuencia correcta es definir primero el marco post-2026, automatizar después el pipeline de datos de consumos y CO₂, y solo entonces evaluar las plataformas de software de cálculo de emisiones que el Director de Ingeniería ya ha identificado, que requieren, precisamente, datos estructurados que hoy no existen en formato automatizable.
Inspecciones reglamentarias — un calendario en un Excel privado
El calendario de las inspecciones reglamentarias obligatorias de los cinco hoteles, ascensores cada dos años, instalaciones eléctricas cada cinco, depósitos y protección contra incendios cada diez, existe únicamente en un Excel personal del Director de Ingeniería y no está compartido. Si el Director de Ingeniería no está disponible, ningún director de hotel sabe qué inspección vence, quién debe contratarla ni con qué empresa. Una instalación que falle sin una inspección válida en vigor puede generar responsabilidad legal inmediata e incluso afectar a la licencia de apertura. Es, estructuralmente, un riesgo equivalente al del cierre contable diario del Responsable PMS-ERP, con un plazo de impacto incluso más corto. Exportar ese calendario a una lista compartida, SharePoint o Microsoft Planner, con alertas automáticas para los directores es una acción de coste técnico mínimo que debe completarse antes de la cirugía del Director de Ingeniería. A ello se añade que el Director de Ingeniería coordina el proceso anual de auditoría de las certificaciones ISO 9001 y 14001 de los cinco hoteles: una dependencia adicional que el plan de continuidad del área debe contemplar.
DHK — el caso de éxito que debe replicarse
DHK, el sistema de registro de incidencias técnicas, es uno de los ejemplos más claros de digitalización exitosa en el Cliente. El papel y la libreta han desaparecido del flujo de incidencias: camareras, gobernanta, restauración, spa y recepción reportan los partes digitalmente, y mantenimiento los recibe en tiempo real en el móvil y los cierra al resolverlos. El factor clave del éxito fue que resolvía un problema real del equipo, no un problema de reporting para la dirección. Sobre DHK opera además un indicador de calidad bien diseñado, el ratio de partes detectados por el cliente, hoy entre el 0 y el 13% según el hotel, con objetivo del 0%, revisado de forma periódica con cada dirección. DHK debería citarse explícitamente como modelo de digitalización a replicar, en contraste con las Power Apps que no alcanzaron la misma adopción.
El área de Personas & Bienestar es la que concentra el mayor número de herramientas desconectadas entre sí y el mayor número de personas críticas sin sustituto formal. la Directora de Personas lidera el área y tiene la visión completa de la estrategia de personas del Cliente; la Responsable de Nóminas gestiona la operativa de nóminas y administración de personal; la Coordinadora de Formación coordina la formación de estudiantes y el programa de alojamiento.
Hay formaciones que ni me entero que suceden. Y aunque sea por el propio manager, también es una formación. La idea es que no tengamos que pasar un papelito.
la Directora de Personas
El ecosistema de RRHH — cinco herramientas, cero integración
El Cliente opera con un ecosistema de RRHH fragmentado en cinco herramientas principales: Viterbit (selección y ATS), Nivimu (HRM y administración), HRider (evaluación del desempeño y feedback continuo), Happyforce (clima organizacional y bienestar) y tres LMS independientes (Turiscool, Scoolinary y Preply) para formación. Ninguna de estas herramientas comparte datos con las demás de forma automatizada.
El resultado es que el journey completo del empleado, desde la candidatura hasta la evaluación de desempeño, pasando por la incorporación, la formación y el bienestar, no puede verse de forma integrada en ningún sistema. la Directora de Personas debe cruzar datos manualmente entre herramientas para tener una visión completa de cualquier empleado.
Viterbit — la integración que no se ha activado
Viterbit, el ATS del Cliente, tiene una integración técnica disponible con Nivimu (el HRM). Esta integración permitiría que cuando un candidato es contratado en Viterbit, su ficha se creara automáticamente en Nivimu sin intervención manual. Sin embargo, esta integración no está activada. El proceso actual requiere que el equipo de RRHH introduzca los datos del nuevo empleado manualmente en Nivimu después de cerrar el proceso en Viterbit.
Los tres LMS — la fragmentación de la formación
El Cliente tiene tres plataformas de formación activas para propósitos distintos: Turiscool para formación hotelera general, Scoolinary para formación gastronómica, y Preply para idiomas. Estas tres plataformas no comparten datos entre sí, no se integran con Nivimu para registrar la formación completada en el expediente del empleado, y la Directora de Personas no tiene visibilidad consolidada de qué empleado ha completado qué formación en qué plataforma.
Esta fragmentación tiene consecuencias reales: hay formaciones que ocurren (incluso formaciones impartidas por los propios managers, que son igualmente válidas) que nunca quedan registradas en ningún sistema. el Cliente no puede auditar su inversión en formación ni garantizar el cumplimiento de requisitos formativos regulatorios.
La Directora de Personas identifica esta fragmentación formativa como su prioridad operativa número uno, y ya ha empezado a actuar sobre ella: inició el desarrollo de una Power App de registro de formaciones cuyo objetivo es centralizar toda la actividad formativa, online, presencial y la impartida por managers, en un único punto de registro. El desarrollo quedó en stand-by por la presión de las tareas de selección, pero la base de la aplicación ya existe. Retomarla, o sustituirla por una solución equivalente, como un formulario de SharePoint con un Power BI de consulta, es un quick win de bajo coste: no resuelve por sí solo la consolidación de los LMS, pero sí da, de forma inmediata, la visibilidad que hoy falta sobre el 100% de las formaciones, con un criterio mínimo de registro: fecha, formando, formador, tipo y duración.
HRider — evaluación sin integración
HRider gestiona las evaluaciones de desempeño trimestrales y el feedback continuo entre managers y empleados, e integra además la encuesta de salida del proceso de offboarding. Es una herramienta valorada por el equipo, pero opera en silo: sus datos no alimentan Nivimu, no se cruzan con los resultados de Happyforce, y no hay forma de correlacionar el clima organizacional con el rendimiento individual.
Happyforce — el termómetro organizacional con objetivo de mejora
Happyforce mide el clima organizacional del Cliente con un HI (Happiness Index) actual de 73/100, con un objetivo de 75. Esta herramienta tiene adopción real en la organización y sus datos son tomados en serio por la dirección. la Directora de Personas es la principal usuaria e intérprete de estos datos, y también es la única que sabe cómo extraer el máximo valor de la herramienta.
la Responsable de Nóminas, la Coordinadora de Formación y la Directora de Personas — tres dependencias críticas
La Responsable de Nóminas gestiona las nóminas del Cliente. El problema estructural no es exclusivamente la dependencia de la Responsable de Nóminas, sino la causa raíz: la ausencia de integración entre Nivimu (sistema de gestión de personal) y la la gestoría externa, que elabora las nóminas con una plantilla Excel. El proceso de construcción manual de esa plantilla concentra riesgo operativo. Existe ya un grupo de trabajo interno analizando la situación. La prioridad es atacar la integración Nivimu ↔ Gestoría, no solo documentar el proceso actual.
La Coordinadora de Formación coordina el programa de estudiantes en prácticas y el alojamiento de empleados. Gestiona en exclusiva el Excel de estudiantes, hotel, tutor, fechas, convenios, al que los hoteles no tienen acceso: solo el equipo central de P&B puede consultarlo. La gestión del alojamiento de empleados es, además, un proceso completamente manual, y los convenios de prácticas siguen en papel. la Coordinadora de Formación concentra el conocimiento de los convenios, los procesos y los contactos institucionales; su ausencia dejaría sin cobertura tanto la gestión de prácticas como la de alojamiento. La mitigación es de bajo coste: migrar el Excel de estudiantes a una lista de SharePoint con acceso controlado por hotel y documentar el proceso de alojamiento.
La propia la Directora de Personas es la tercera dependencia crítica del área: es la única gestora activa de Happyforce y la principal intérprete de HRider, de modo que ambas plataformas, el termómetro de clima y la evaluación del desempeño de toda la cadena, quedan sin supervisión ni actualización en su ausencia. Designar y formar a un segundo gestor para Happyforce y HRider es la pieza que completa el plan de continuidad de Personas & Bienestar.
Hallazgos Transversales
Más allá de los hallazgos específicos de cada área, el diagnóstico identificó cinco patrones que atraviesan toda la organización y que tienen implicaciones estratégicas para cualquier iniciativa de transformación digital.
Patrón 1 — Concentración de conocimiento crítico en personas sin sustituto
El Cliente tiene al menos once Puntos Únicos de Fallo (SPoF) humanos identificados: el Responsable IT (IT completo), el Responsable PMS-ERP (EdocAssistant, herramientas financieras y arquitectura SQL del PMS), el Técnico BMS (BMS Circutor), la Responsable de Nóminas (nóminas), el Digital Manager (ecosistema digital comercial — CRM, Cendyn, GTM y Power BI), la Coordinadora Lean (Lean en campo), la Coordinadora de Formación (estudiantes y alojamiento), la Directora de Personas (Happyforce y visión de RRHH), la Responsable de Impacto (sostenibilidad completa), el Director de Ingeniería (ingeniería, instalaciones y cumplimiento reglamentario), y el Responsable Lean (ecosistema Power Apps).
Este patrón no es resultado de negligencia organizacional; es el resultado natural del crecimiento de una empresa que prioriza el talento interno y confía en sus personas. El problema es que esa confianza no ha ido acompañada de mecanismos de transferencia de conocimiento (documentación, dobles, rotación, simulacros de continuidad). Cuando alguien se va de vacaciones, se pone enfermo o se jubila, la organización descubre qué no sabe.
Patrón 2 — Fragmentación de datos sin modelo corporativo
Los datos del Cliente viven en al menos 15 sistemas distintos que no comparten una definición común de las entidades fundamentales del negocio: ¿quién es el "huésped"? ¿quién es el "empleado"? ¿qué es una "reserva"? Cada sistema tiene su propia respuesta. El resultado es que consolidar cualquier dato requiere intervención humana manual y es propenso a errores.
La ausencia de un modelo de datos corporativo no es un problema técnico; es un problema de governance. Alguien tiene que tomar la decisión de qué sistema es la fuente de verdad para cada entidad, y esa decisión tiene que ser respetada por todos los sistemas y todos los equipos.
Patrón 3 — Adopción sin apropiación
El Cliente tiene una historia de adoptar herramientas que luego no se usan a su máxima capacidad, o que se abandonan. La experiencia de Aplanet es el ejemplo más documentado, pero el patrón se repite: Power Apps creadas y no usadas, funcionalidades de Duetto sin activar, integración Viterbit-Nivimu disponible pero no activada. La causa no es la herramienta; es la ausencia de un proceso formal de onboarding, formación y medición de adopción.
La regla que se extrae de este patrón: ninguna herramienta debería pasar a producción sin un Owner designado, un criterio de éxito medible, y un plan de revisión a 90 días. Si a los 90 días la herramienta no ha alcanzado el umbral de adopción, se revisa la formación, no se culpa a la herramienta.
Patrón 4 — Integraciones manuales como sustituto de arquitectura
La mayoría de las transferencias de datos entre sistemas en el Cliente ocurren de forma manual: alguien descarga un archivo de un sistema y lo sube a otro, o copia datos de una pantalla a otra. Esto no es único del Cliente, es habitual en empresas de este tamaño, pero tiene un coste oculto: horas de trabajo de personas cualificadas dedicadas a trabajo de fontanería de datos, más riesgo de errores de transcripción, más imposibilidad de tener datos en tiempo real.
La solución no siempre es técnica. A veces es rediseñar el proceso para que el dato solo se introduzca una vez. Otras veces es una integración vía API. Y en algunos casos, la solución es aceptar que el proceso manual tiene sentido (como el pickup de la Directora Revenue) y documentarlo explícitamente como una decisión, no como una carencia.
Patrón 5 — Gobernanza tecnológica centralizada en IT sin visión de producto
El Responsable IT es el responsable técnico de prácticamente todo, pero su rol no incluye formalmente la visión de producto: qué debe hacer cada herramienta, para quién, con qué criterios de éxito. Esa visión de producto vive dispersa en cada área, Revenue sabe lo que necesita de Duetto, Marketing sabe lo que necesita de Cendyn, pero no hay un proceso formal para que esas necesidades se traduzcan en decisiones técnicas priorizadas.
El modelo que el Cliente necesita no es "IT decide qué hacer"; es "el negocio define qué necesita, y IT evalúa cómo hacerlo posible con los recursos y la arquitectura correcta". Esa colaboración estructurada es la base de un Comité de Tecnología funcional.
Mapa de Riesgos Prioritarios
El diagnóstico ordena los riesgos identificados en tres niveles de prioridad. Filtra por nivel para concentrar la lectura.
| Nivel | Riesgo | Horizonte | Acción recomendada |
|---|---|---|---|
| Crítico | Power App Residuos — 15.000+ registros corruptos | Inmediata | Auditoría de datos, migración a sistema fiable, plan de corrección documental. |
| Crítico | el Técnico BMS — BMS Circutor in-house sin sustituto ni documentación; datos en servidor local sin backup (cirugía próxima) | Inmediata | Documentación de la arquitectura del BMS + formación de segundo técnico + migración de los datos a Azure. |
| Crítico | EdocAssistant — custodio único el Responsable PMS-ERP (jubilación próxima, relación con el proveedor del sistema sin respaldo) | Inmediata | Documentación de EdocAssistant + transferencia de relación con el proveedor del sistema + formación de segundo custodio. |
| Crítico | Cendyn — proveedor en sunset operativo tras el cambio de propiedad (soporte degradado, 100.000 contactos dependientes) | Corto plazo | Evaluación de Revinate/Dailypoint como alternativas + plan de migración de contactos a una plataforma con soporte activo. |
| Crítico | Greenwashing legal — datos ambientales no auditables | Inmediata | Auditoría de indicadores, corrección de Power App, certificación de proceso de datos. |
| Crítico | Nóminas — sin integración Nivimu ↔ la gestoría externa (proceso manual sobre Excel) | Corto plazo | Integración directa Nivimu ↔ Gestoría como objetivo del grupo de trabajo existente. |
| Crítico | Arquitectura SQL del PMS sin documentar — conocimiento concentrado en el Responsable PMS-ERP | Inmediata | Sesión específica de documentación del SQL Management (servidor, tablas, conectores, reglas de negocio) antes de su salida, con un mapa de tablas del PMS como entregable. |
| Crítico | el Director de Ingeniería — 30 años de conocimiento de instalaciones sin respaldo (cirugía programada) | Inmediata | Plan de continuidad: calendario de inspecciones compartido, contratos de mantenimiento documentados, sustituto para validación de facturas de obra, contingencia del ACS. |
| Alto | Visión transversal de infraestructura e integraciones concentrada en una sola persona (el Responsable IT) | Corto plazo | Elevación organizativa de la función IT + documentación de arquitectura + incorporación de un segundo perfil técnico para reducir la concentración. |
| Alto | Power Platform — apps de gran volumen de datos fuera del ámbito natural de la herramienta | Corto plazo | Migración de Inventarios y Pedidos a alternativas del marketplace de Dynamics + gobernanza formal. |
| Alto | Ausencia de modelo de datos corporativo | Corto plazo | Taller de definición de entidades maestras + designación de data owners. |
| Alto | Concentración del ecosistema digital comercial en una sola persona (el Digital Manager) | Corto plazo | Documentación y protocolo de transferencia de CRM, Cendyn, GTM y Power BI de Marketing. |
| Alto | Tracking digital sin server-side — ROI de marketing no medible | Corto plazo | Implementación de tracking server-side + auditoría GA4 con el Digital Manager. |
| Alto | Tres LMS sin integración — formación invisible para Personas | Medio plazo | Unificación en un LMS (TalentLMS/Docebo) + integración con Nivimu. |
| Alto | Integración Viterbit-Nivimu sin activar — datos de RRHH duplicados | Corto plazo | Activación de integración API existente entre Viterbit y Nivimu. |
| Alto | la Coordinadora de Formación — gestión exclusiva del Excel de estudiantes en prácticas y del alojamiento de empleados (sin acceso de los hoteles, sin backup) | Corto plazo | Migración del Excel de estudiantes a SharePoint con acceso por hotel + documentación del proceso de alojamiento. |
| Alto | la Directora de Personas — única gestora de Happyforce y principal intérprete de HRider | Medio plazo | Designación y formación de un segundo gestor para Happyforce y HRider. |
| Medio | Duetto — RMS usado como validador manual por opacidad del modelo (riesgo de infrautilización) | Corto plazo | Workshop de onboarding técnico con Duetto: lógica del modelo, configuración de reglas de negocio de el Cliente y criterios de aceptación automática. |
| Medio | HiJiffy, SpeakSpot e IA de Mirai — tres plataformas solapadas en el journey digital del huésped | Corto plazo | Decisión de plataforma única de journey y descontinuación de las demás (criterios: cobertura funcional, integración PMS/CRM, personalización). |
| Medio | Integración de EcoStruxure pendiente en otras propiedades de la cadena | Corto plazo | Completar la integración de los termostatos con el servidor central del BMS. |
| Medio | Booking New — informe Excel mantenido en paralelo pese a existir un sustituto contratado (RevTool) | Medio plazo | Confirmar con el equipo comercial la cobertura funcional de RevTool y planificar la retirada progresiva de BookingNew. |
| Medio | la Coordinadora Lean — SPoF lean en campo no visible en organigrama | Medio plazo | Reconocimiento formal del rol + plan de formación de segundo referente lean. |
| Medio | Ausencia de gestión centralizada de credenciales corporativas | Corto plazo | Implementación de 1Password Business o similar para toda la organización. |
Recomendaciones Priorizadas
Las 39 recomendaciones se organizan en tres horizontes temporales. H1 es acción inmediata (0-90 días), orientada a reducir riesgos críticos activos. H2 es transformación a corto plazo (3-12 meses), orientada a construir capacidades diferenciales. H3 es visión estratégica (12-24 meses), orientada a posicionar al Cliente como referente tecnológico en la hotelería independiente española.
| # | Acción | Responsable | Criterio de éxito |
|---|---|---|---|
| 1 | Reclamación a el partner tecnológico del código fuente del PMS y de los objetos personalizados (AL) | Dirección + el Responsable PMS-ERP + el Responsable IT | Recuperación formal del código —propiedad del Cliente— antes de que la reestructuración del partner tecnológico lo haga inviable. Insumo de seguro para la transición y registro de la lógica de negocio a trasladar. |
| 2 | Auditoría y corrección de las Power Apps de Impacto (residuos y evaluación de alimentos) | la Responsable de Impacto + el Responsable IT | Auditoría de los 15.000+ registros de residuos y corrección de tipos de dato (texto → numérico, fechas); auditoría de la Power App de evaluación de alimentos con el mismo criterio. Datos validados como numéricos y consistentes antes de septiembre de 2026. Ningún dashboard de impacto hasta entonces. |
| 3 | Documentación del BMS Circutor y migración de datos a Azure | el Técnico BMS + el Responsable IT | Manual técnico completo de la arquitectura (contadores por hotel, parámetros). Formación de un segundo técnico antes de la intervención quirúrgica del Técnico BMS. Migración de los datos del BMS del servidor local a Azure. |
| 4 | Plan de transferencia el Responsable PMS-ERP — EdocAssistant, cierre contable diario, herramientas financieras y SQL Management del PMS | el Responsable PMS-ERP + el Responsable IT | Documentación de EdocAssistant y reunión con el proveedor del sistema. Traspaso del cierre contable diario y de las herramientas de reporting financiero. Sesión específica de documentación del SQL Management del PMS (servidor, tablas, conectores, reglas de negocio), con un mapa de tablas como entregable. Designación de segundo custodio. |
| 5 | Activación integración Viterbit ↔ Nivimu | la Directora de Personas + el Responsable IT | Eliminación del proceso de doble introducción de datos. Adopción en <30 días. |
| 6 | Evaluación de Cendyn como proveedor en riesgo y de sus alternativas | el Responsable Marketing + Dirección | Confirmación del nivel real de soporte tras el cambio de propiedad. Evaluación de alternativas (Revinate, Dailypoint) y plan de migración de los 100.000 contactos a una plataforma con soporte activo. |
| 7 | Implementación tracking server-side | el Responsable Marketing + el Digital Manager | ROI de marketing medible de forma fiable. GA4 auditado y validado. |
| 8 | Inventario técnico Power Platform, auditoría de adopción y catálogo del PMS | el Responsable Lean + el Responsable IT | Mapa de las 40+ apps (owner, usuarios, integraciones, criticidad) distinguiendo apps implantadas de apps en uso real; catálogo de las capacidades nativas del PMS (qué resuelve ya, qué no hay que construir). |
| 9 | Implementación gestor de contraseñas corporativo | el Responsable IT | 1Password Business o equivalente. Todas las cuentas críticas bajo gestión centralizada. |
| 10 | Integración Nivimu ↔ la gestoría externa — atacar la causa raíz de nóminas | la Responsable de Nóminas + el Responsable IT + Grupo de trabajo | Proceso de nóminas sin dependencia de plantilla Excel manual. Gestoría recibe datos desde Nivimu. |
| 11 | Documentación de la arquitectura de distribución — conexión unidireccional PMS↔SiteMinder | la Directora Revenue | Registro formal de la unidireccionalidad PMS↔SiteMinder como decisión de Revenue Management (gestión de cupo), con su racional y la condición de validación previa por Revenue ante cualquier cambio. |
| 12 | Decisión de plataforma única de journey digital del huésped | el Responsable Marketing + el Responsable IT | Una sola plataforma de comunicación con el huésped (HiJiffy, SpeakSpot o IA de Mirai), seleccionada por cobertura funcional, integración PMS/CRM y personalización; las demás descontinuadas. |
| 13 | Automatización del reporting de Revenue — informe semanal y Excel de Marketing | IT + la Directora Revenue | Template automatizado del informe semanal a partir de RevTool/Booking New, sin intervención manual, y exportación programada de la producción por canal hacia Marketing. Impacto: 3-4 h semanales liberadas. |
| 14 | Estandarización del sistema de Inventarios y quick wins operativos | el Responsable Lean + IT | Replicar la app de Inventarios (código de barras) en los hoteles que siguen en proceso manual; resolver los partes de ropa de camareras (Power Query) y la comida de personal (app en tablet). |
| 15 | Modelo de datos de impacto normalizado y documentación del proceso de la memoria | la Responsable de Impacto + el Responsable IT | Definición, para cada indicador irrenunciable de B Corp y memoria, de su fuente verificable, responsable, periodicidad, formato y criterio de trazabilidad; documentación del proceso de la memoria mientras la Responsable de Impacto está disponible. Prerequisito de cualquier SaaS o dashboard de impacto. |
| 16 | Normalización del acceso a la herramienta de IA de clasificación de residuos | la Responsable de Impacto + el Responsable IT | Aprobación y publicación del site de SharePoint de residuos ya construido (enlace a la herramienta, procedimientos, contactos) y código QR en los puntos de recogida. Elimina el canal informal de WhatsApp personal. |
| 17 | Plan de continuidad de Ingeniería | el Director de Ingeniería + Dirección | Calendario de inspecciones reglamentarias exportado a lista compartida con alertas; lista de contratos de mantenimiento documentada; sustituto formal para la validación de facturas de obra; plan de contingencia del ACS por hotel; aceleración del checklist de hotel. |
| 18 | Automatización del pipeline de suministros | IT + el Director de Ingeniería | Integración Circutor / facturas digitales → Excel de suministros, con asignación automática del desfase y paso de validación obligatorio. Libera 2-3 tardes/mes y estructura los datos para el cálculo de CO₂. |
| 19 | Completar la integración de EcoStruxure en otras propiedades de la cadena | el Técnico BMS + Schneider | Integración de los termostatos con el servidor central del BMS. Palanca directa sobre el 30-35% del coste eléctrico. Antes del cierre de temporada 2026. |
| 20 | Sistema único de registro de formaciones | la Directora de Personas + IT | Retomar la Power App de registro de formaciones en stand-by, o sustituirla por un formulario SharePoint + Power BI, para capturar el 100% de la actividad formativa (online, presencial y de managers) con un criterio mínimo: fecha, formando, formador, tipo y duración. |
| 21 | Evaluación formal del PMS cloud componible | el Responsable PMS-ERP + el Responsable IT + el Director General | RFP estructurada con Mews, Cloudbeds y Apaleo como candidatos y QuoHotel como línea de base. Decisión del Front desacoplada de la del Back (Business Central). Criterios: integración nativa con Duetto/SiteMinder/Mirai/Cendyn, API abierta, escala multi-propiedad, TCO a 5 años y filtro de dependencia. |
| # | Acción | Responsable | Criterio de éxito |
|---|---|---|---|
| 22 | Definición del modelo de datos corporativo | el Responsable IT + Dirección + Áreas | Documento aprobado con entidades maestras, owners y fuentes de verdad por área. |
| 23 | Consolidación de LMS — selección y migración | la Directora de Personas + el Responsable IT | Un solo LMS activo (TalentLMS/Docebo), integrado con Nivimu, con visibilidad completa de formación. |
| 24 | Construcción del Customer 360 | el Responsable Marketing + el Responsable IT + la Directora Revenue | Vista unificada del huésped en un sistema (CRM o CDP), alimentada por PMS, web y email. Incluye como objeto prioritario la definición del cliente objetivo del Cliente por afinidad de valores. |
| 25 | Plan de gobernanza Power Platform | el Responsable Lean + el Responsable IT | Estándares de desarrollo, documentación obligatoria, proceso de aprobación de nuevas apps. |
| 26 | Homologación de la capa de gestión energética entre los cinco hoteles | el Director de Ingeniería + el Técnico BMS + el Responsable IT | Unificación de la monitorización (Circutor) y del control climático (EcoStruxure integrado en todos los hoteles), con los datos en infraestructura corporativa. |
| 27 | Implementación CMMS (UpKeep/Limble) | el Director de Ingeniería | Sistema de mantenimiento preventivo activo. Reducción de intervenciones correctivas en 30%. |
| 28 | Comité de Tecnología — primera sesión y charter | el Director General + el Responsable IT + Áreas | Comité operativo con reuniones mensuales, backlog priorizado y criterios de decisión documentados. |
| 29 | Integración Revenue ↔ CRM | la Directora Revenue + el Responsable Marketing + el Responsable IT | Cruce de datos de reserva y perfil de cliente para identificar clientes fidelizados que siguen reservando por OTA. Medición del impacto del club de fidelización en la reconversión a canal directo. |
| 30 | Documentación del employee journey completo | la Directora de Personas | Mapa de 14 fases del journey del empleado con touchpoints tecnológicos y owners por fase. |
| 31 | IA para la gestión de buzones de reservas | Revenue + IT | Automatización de respuestas a peticiones estándar (disponibilidad, condiciones de tarifa, información de habitaciones). Prerequisito: mapear los 10-15 tipos de petición más frecuentes y validar plantillas con Revenue. |
| 32 | Dashboard de impacto centralizado | la Responsable de Impacto + el Responsable IT | Vista comparativa entre hoteles de los indicadores B Corp y de memoria (residuos, consumos, personas), con trazabilidad por indicador. Prerequisito: modelo de datos de impacto normalizado y corrección de la Power App de residuos. |
| 33 | Marco de objetivos de sostenibilidad post-2026 | Dirección + el Director de Ingeniería + la Responsable de Impacto | Definición de métricas, sistema de seguimiento y responsable para el período 2027 en adelante, tras el cierre del proyecto de reducción de emisiones. Prerequisito de cualquier software de cálculo de emisiones CO₂. |
| # | Iniciativa | Liderazgo | Criterio de éxito |
|---|---|---|---|
| 34 | Migración del Front a un PMS API-first, con el Back/ERP tratado en fase separada (si se decide en H2) | el Responsable IT + el Responsable PMS-ERP + el Director General | Migración completada sin pérdida de datos ni interrupción operativa. Decisiones de Front y Back desacopladas. Integraciones documentadas. |
| 35 | Plataforma CDP unificada — Customer 360 operativo | el Responsable Marketing + la Directora Revenue + el Responsable IT | Segmentación dinámica de huéspedes activa. ROI de campañas personalizado medible. |
| 36 | Centro de Excelencia Power Platform (CoE) | el Responsable IT + el Responsable Lean | CoE Starter Kit implementado. Gobernanza automatizada de apps. Reducción de shadow IT residual. |
| 37 | Sistema ESG nativo con trazabilidad legal | la Responsable de Impacto + el Responsable IT | Todos los indicadores de sostenibilidad con fuente de datos automatizada y auditable. |
| 38 | Mantenimiento predictivo con IA (BMS + DHK) | el Director de Ingeniería + el Responsable IT | Modelo predictivo de fallos técnicos activo. Reducción de averías imprevistas en 40%. |
| 39 | el Cliente como empleador digital de referencia | la Directora de Personas + el Director General | Employee journey 100% digital. NPS de empleados en top-5 sector hotelero español. |
Recomendaciones Estratégicas — La Decisión del Núcleo Tecnológico
Las secciones anteriores describen lo que el Cliente tiene (sección 6) y ordenan sus riesgos (sección 8). Esta sección aborda la decisión de mayor calado de todo el diagnóstico: qué hacer con el núcleo tecnológico, el PMS y el ERP, sobre el que se apoya toda la operación de la cadena. Es una decisión estratégica, no operativa, y condiciona casi todo lo demás. La sección evalúa los tres caminos posibles, recomienda uno y resuelve las cinco decisiones de fondo que el Cliente tiene por delante.
El hecho que cierra la pregunta
A primera vista, el Cliente dispone de tres caminos para el futuro de su PMS, y los tres parecen igualmente abiertos. No lo están: hay un hecho que cierra la pregunta antes de plantearla.
El modelo actual, el de la personalización a medida, se sostuvo durante dos décadas sobre tres pilares: las personas que sabían programar las personalizaciones (el Responsable PMS-ERP y, en los últimos años, el Responsable Lean), el partner que las acompañaba (un programador del partner tecnológico con conocimiento del código en AL) y un núcleo PMS/ERP estable sobre el que construir. Los tres pilares han caído a la vez. el Responsable PMS-ERP se jubila y el Responsable Lean ha pasado a dirigir un hotel. el partner tecnológico ha despedido al programador que daba ese soporte. Y el Cliente no dispone del código fuente, ni del PMS ni de sus propios objetos personalizados.
La conclusión es incómoda pero ineludible: "continuar personalizando QuoHotel sobre Dynamics" no es un camino que el Cliente pueda elegir. Es un modelo que ya ha terminado. Mantenerlo no es la opción prudente ni la de menor riesgo: es operar cada día un sistema central sin soporte de personalización, sin código fuente y sin documentación, acumulando riesgo en lugar de contenerlo. La decisión real del Cliente no es entre tres caminos, sino entre los dos que quedan.
Los tres modelos, evaluados
Personalización a medida
No por una mala decisión, sino por la erosión de las condiciones que lo hacían posible. Su virtud histórica fue real: el Cliente adaptó la tecnología a su modelo operativo con un coste de licencias muy bajo. Pero esa virtud dependía de un conocimiento interno escaso y de un partner que ya no lo sostiene. Prolongar este modelo equivale a aumentar la dependencia de las dos personas que se van, justo cuando se van.
Estándar (Opera + SAP)
Es el modelo de las grandes cadenas: el sistema recoge el know-how del sector y la organización se adapta a él, con un margen de personalización mínimo. Tiene una virtud que el Cliente debe aprender: no se programa a medida lo que es un proceso de mercado estándar. Pero su instrumentación (Opera en el front, SAP en el back) es desproporcionada para una cadena del tamaño del Cliente: cara, de implantaciones largas y, sobre todo, culturalmente opuesta a su identidad. el Cliente no quiere que sus personas se adapten al sistema; quiere que el sistema sirva a sus personas. Adoptar el modelo Estándar resolvería el problema técnico destruyendo la diferencia operativa que sostiene la marca.
Componentes intercambiables
Es el modelo de un núcleo cloud y abierto al que se conectan, y del que se desconectan, componentes especializados. Es el adecuado paral Cliente por cuatro razones concretas. Primero, entrega adaptabilidad sin dependencia: el Cliente sigue adaptando la tecnología a su modelo, pero lo hace configurando y eligiendo componentes, no escribiendo código que solo dos personas entienden. Segundo, elimina el punto único de fallo de raíz: no hay código fuente propietario retenido por un tercero, no hay capa a medida que mantiene una sola persona. Tercero, escala: una plataforma cloud multi-propiedad incorpora el hotel número 25 como una tarea de configuración, no como un rediseño. Cuarto, encaja con la realidad de recursos del Cliente, un departamento de sistemas de una persona apoyado en outsourcing, porque desplaza el trabajo de "programar" a "integrar, configurar y gobernar proveedores".
Conviene una precisión, basada en el estado del mercado en 2026. Dentro de este modelo conviven dos enfoques. Uno es el de infraestructura pura, Apaleo es el referente: el PMS como capa base sobre la que el hotel construye su propio stack a medida; potente, pero pensado para grupos con equipo técnico propio (citizenM, Limehome, easyHotel). El otro es el de plataforma componible unificada, Mews es el referente: un núcleo inteligente y unificado que además expone un marketplace abierto de integraciones. Paral Cliente, con un IT de una sola persona, la recomendación es el segundo enfoque: una plataforma componible unificada mantiene la carga de integración manejable, mientras conserva la libertad de conectar y sustituir los componentes especializados. En la práctica, este enfoque recoge lo mejor del modelo Estándar (no programar a medida los procesos de mercado) y lo mejor de la Personalización (adaptar lo que de verdad diferencia), sin la dependencia de ninguno de los dos.
Las cinco decisiones de fondo
Decisión 1 — ¿Mantener la unidad entre Back (ERP) y Front (PMS)?
Desacoplarlos. La unidad PMS+ERP sobre una misma tecnología y un mismo partner fue una simplificación razonable en la arquitectura cliente/servidor de los años noventa; hoy es la forma concreta que toma el lock-in. La recomendación es tratar dos pistas separadas, con plazos distintos. El Front: reservas, check-in, facturación al huésped, producción, migra a un PMS cloud componible. El Back: contabilidad, compras, inventarios, tesorería, permanece en el ecosistema Microsoft y completa su regularización a Dynamics 365 Business Central en cloud. Microsoft mantiene hasta diciembre de 2027 su programa Bridge to Cloud, con descuento sobre las licencias online para clientes on-premises, lo que abre una ventana económica concreta para esa regularización. La migración del PMS no debe esperar a la del ERP, ni a la inversa.
Decisión 2 — ¿Qué modelo arquitectónico?
Componentes intercambiables, instrumentado como un PMS cloud componible-unificado. Pero la elección del producto no debe tomarse de forma unilateral: debe salir de una evaluación formal. El conjunto de candidatos a evaluar: Mews, referencia de mercado, en enero de 2026 levantó 300 millones de dólares a una valoración de 2.500 millones y opera unas 15.000 propiedades en 85 países; Cloudbeds, plataforma fuerte en hotelería independiente, con su modelo de IA Signals; y Apaleo, API-first puro, como contraste. Como línea de base, QuoHotel tal cual está, para cuantificar el coste real de no decidir. Los criterios de evaluación: integración nativa con el stack que el Cliente ya opera bien (Duetto, SiteMinder, Mirai, Cendyn); API abierta y documentada; escala multi-propiedad real; modelo y coste de migración de datos históricos; coste total de propiedad a cinco años; referencias verificables en cadenas europeas comparables; y, de forma explícita, el filtro de dependencia, descartar cualquier candidato que reproduzca el lock-in del que el Cliente está saliendo.
Decisión 3 — ¿Qué horizonte de crecimiento debe asumir la arquitectura?
el Cliente contempla expandirse en las próximas dos décadas hacia un orden de 20 a 30 hoteles. Ese horizonte no es un dato accesorio: es un criterio de decisión que refuerza las dos anteriores. La arquitectura debe diseñarse a la escala de destino, no a la actual. Un QuoHotel personalizado que ya es frágil con la cadena de hoy sería inmanejable con 25 hoteles: lejos de diluirse, el riesgo tecnológico del modelo actual se agravaría con cada nueva propiedad. Una plataforma cloud componible, en cambio, convierte cada nuevo hotel en una incorporación de días. Y permite algo más: estandarizar ahora, mientras la cadena es pequeña, un "stack tipo", la plataforma, el conjunto de componentes y su configuración, que cada propiedad nueva hereda. Así el crecimiento es replicación, no reinvención.
Decisión 4 — ¿Qué tipo de tecnología?
Cloud-nativa, API-first, SaaS. Cinco principios concretos: (1) el PMS como núcleo componible-unificado con una API abierta y documentada; (2) la integración como una capa gobernada, el marketplace de la plataforma o un iPaaS, de modo que cada integración sea un activo documentado y propio, y se cierre la etapa del Excel, el VBA y el Power Query como tejido de integración; (3) una capa de datos independiente de los sistemas operativos, el modelo de datos corporativo que este informe ya recomienda, para que el BI, el Customer 360 y el reporte de impacto no se rompan cada vez que cambia un sistema de origen; (4) el ERP en Business Central cloud; (5) Microsoft 365 como base de productividad y colaboración. El filtro de selección, transversal a los cinco: preferir la configuración al código, y la API abierta al lock-in.
Decisión 5 — ¿Qué conocimientos, organización y recursos humanos?
El cambio de modelo redefine el perfil de competencias de IT. El perfil antiguo, programadores en C/AL y AL, uso intensivo de VBA, un consultor del partner tecnológico, ha desaparecido y no debe reconstruirse. El perfil que el Cliente necesita tiene cuatro componentes. Primero, un rol de liderazgo tecnológico con autoridad de arquitectura y un asiento en la mesa estratégica: la función IT no puede seguir dependiendo de la Dirección Financiera si se le pide conducir esta transformación. Segundo, capacidad de integración y de datos: dada la tradición de outsourcing del Cliente, lo razonable es cubrirla con un partner integrador y una capa iPaaS antes que con plantilla propia. Tercero, propiedad distribuida: dueños de dato y dueños de aplicación por dominio, no todo el conocimiento en una persona. Cuarto, disciplina Lean sobre la migración: ningún proceso debe reimplementarse en el sistema nuevo sin antes analizarse, optimizarse o, si procede, eliminarse. No se migra el desperdicio.
Hay una objeción legítima a este modelo que conviene abordar de frente: en el paradigma de componentes, la figura del consultor que forma y ayuda a configurar tiende a desaparecer, sustituida por plataformas de formación online. Lejos de ser una pérdida, es una mejora. El modelo de consultor único es, precisamente, la dependencia que acaba de fallar, el programador del partner tecnológico era ese consultor. Lo que lo sustituye es más robusto: formación y certificación del proveedor para que el equipo interno configure el stack, y un partner integrador contratado con una condición explícita, que no se convierta en el nuevo el partner tecnológico; es decir, que entregue integraciones documentadas, portables y propiedad del Cliente.
Mapa de responsabilidades y competencias de la transformación
Las cinco decisiones anteriores tienen una consecuencia organizativa que conviene hacer explícita. El nuevo modelo no se sostiene con el perfil de IT del modelo anterior, y la pregunta correcta no es "qué cargos crear", sino "qué responsabilidades y qué competencias exige conducir esta transformación". La estructura, el organigrama, los cargos, el reparto entre plantilla propia y externos, es una consecuencia de esa respuesta, no su punto de partida.
El mapa siguiente ordena la transformación en siete bloques de responsabilidad. Para cada uno indica las competencias que requiere y una recomendación de origen, interno, subcontratado o mixto. Esa recomendación es orientativa: la decisión de qué cubrir con plantilla propia y qué con un partner pertenece al Cliente, y debe tomarse a la luz de su tradición de outsourcing y de su capacidad real de absorber perfil técnico. Lo que el mapa fija no es el organigrama, sino el criterio: ninguna de estas responsabilidades puede quedar sin dueño, y las marcadas como internas no deberían externalizarse aunque resulte cómodo hacerlo, porque son las que mantienen el control en manos del Cliente.
| Responsabilidad | Competencias clave | Origen recomendado |
|---|---|---|
| Liderazgo tecnológico y arquitectura | Arquitectura de soluciones; criterio sobre el mercado de tecnología hotelera; capacidad de traducir necesidades de negocio en decisiones técnicas; visión de conjunto y simplicidad como filtro. | Interno. Es el rol que no puede externalizarse: quien decide la dirección tecnológica tiene que conocer la casa y rendir cuentas dentro de ella. |
| Dirección del programa de transformación | Gestión de programa y de proyecto; priorización; gestión del cambio organizativo; coordinación de stakeholders. | Mixto. Sponsor y dirección internos, con apoyo externo de programa, el partner integrador o un perfil fraccional, durante la fase más intensa. |
| Gobierno del dato | Data governance; modelado de datos; gestión de datos maestros (MDM); criterios de calidad y trazabilidad. | Interno, con la metodología inicial aportada por un especialista externo. Los dueños de dato son, por definición, internos; de fuera puede venir el método, no la propiedad. |
| Integración y arquitectura de APIs | Ingeniería de integración; iPaaS; diseño y consumo de APIs; documentación de flujos. | Subcontratable. Es la competencia más razonable de cubrir con un partner, en línea con la tradición de outsourcing del Cliente, con la condición explícita de que las integraciones se entreguen documentadas y en propiedad del Cliente. |
| Gestión de proveedores y contratos | Selección y gobierno de proveedores; conducción de RFP; negociación de SLAs; aplicación del filtro de dependencia. | Interno. Decidir de quién dependel Cliente no puede delegarse en quien aspira a ser ese proveedor. |
| Configuración y administración de plataformas | Configuración avanzada de plataformas low-code y SaaS; gobernanza de desarrolladores ciudadanos; administración del PMS componible y del ecosistema Power Platform. | Mixto. La capacidad de configurar debe quedar dentro, formada mediante la certificación de los proveedores; la puesta en marcha inicial puede apoyarse en el partner. |
| Adopción, formación y gestión del cambio | Gestión del cambio; diseño de formación; facilitación Lean; presencia en el proceso operativo real. | Interno. Es una competencia cultural, y el Cliente ya la tiene: vive en su práctica Lean y en las personas que la sostienen. |
A este mapa subyace una función que no aparece en él porque no es nueva: la operación y el soporte del día a día, infraestructura Azure, Microsoft 365, identidades, ciberseguridad, cumplimiento RGPD, hoy sostenida por la combinación de IT interno y outsourcing, y que debe seguir funcionando con normalidad durante toda la transformación. El mapa recoge lo que la transformación añade, no lo que ya existe.
Leído en conjunto, el mapa ofrece a la dirección una secuencia clara: primero, validar que estas siete responsabilidades están completas y bien definidas; segundo, decidir el origen de cada una, interno, mixto o subcontratado; y solo entonces traducir esas decisiones en estructura, cargos y contratos. Definir el organigrama antes de este ejercicio es empezar por el final.
La acción que no puede esperar — reclamar el código fuente
Con independencia del modelo que se elija y del calendario de migración, hay una acción que el Cliente debe ejecutar de forma inmediata: reclamar formalmente a el partner tecnológico el código fuente del PMS y, sobre todo, de los objetos personalizados desarrollados en AL. Ese código es propiedad del Cliente y hoy no obra en su poder. Es urgente por la situación del partner tecnológico: una empresa en reestructuración, que ha despedido al técnico que conocía ese código y ha trasladado su desarrollo a otra geografía. El código se necesita por tres razones: como seguro durante toda la transición, como registro documentado de la lógica de negocio que habrá que trasladar al nuevo PMS, y como palanca de negociación. Cada mes que pasa, recuperarlo es más difícil.
Secuencia
Nada de lo anterior significa sustituir el PMS mañana. QuoHotel sigue sosteniendo la operación diaria y debe seguir haciéndolo de forma ordenada durante toda la transición. Pero la retirada del partner tecnológico sí cambia los plazos: el Cliente ya no tiene margen para aplazar la decisión del PMS. La secuencia recomendada es: reclamar el código ahora; lanzar la evaluación formal del PMS dentro de 2026; decidir la plataforma componible; y ejecutar la migración en los horizontes H2-H3, con el modelo de datos corporativo y la gobernanza como prerrequisitos, y con el principio Lean, optimizar antes de migrar, gobernando cada proceso. La migración de un PMS es una de las transformaciones más complejas del sector, y este informe no la minimiza; pero una plataforma moderna con conectores nativos a Duetto y a SiteMinder convierte una reintegración como la que costó tres años con la arquitectura actual en un trabajo de semanas.
En una frase: la recomendación estratégica de este diagnóstico es el principio de la Dirección General, personalización sí, dependencia no, traducido a arquitectura. El modelo de componentes intercambiables es la única de las tres vías que entrega lo primero sin lo segundo.
Marco para los Workshops de Alineación Estratégica
Las recomendaciones de este informe requieren decisiones que no puede tomar una sola persona ni un solo departamento. Proponemos tres workshops estructurados para que el Cliente construya consenso, aclare roles y defina el roadmap con la participación de todas las áreas implicadas.
El mensaje central que debe guiar los tres workshops
"el Cliente tiene la infraestructura, la cultura y las personas para ser referente tecnológico en la hotelería independiente española. Lo que necesita ahora no es más herramientas, sino más arquitectura: un modelo de datos claro, una gobernanza explícita, y un proceso para tomar decisiones tecnológicas que involucre a todas las áreas."
Gobernanza y Modelo de Datos
Objetivo: Definir el modelo de datos corporativo del Cliente. Identificar las entidades maestras (Huésped, Empleado, Reserva, Edificio, Indicador ESG), designar el Owner de cada entidad, y acordar qué sistema es la fuente de verdad para cada una.
Estructura de la sesión
- Presentación del diagnóstico de datos: dónde vive cada entidad hoy y qué inconsistencias genera la fragmentación actual (30 min)
- Ejercicio de mapeo: cada área identifica qué datos produce, cuáles consume, y cuáles echa de menos (45 min)
- Decisión: para cada entidad maestra, ¿cuál es la fuente de verdad? ¿Quién es el owner? (45 min)
- Próximos pasos: quién hace qué antes del Workshop 2 (30 min)
Riesgos Críticos y Plan de Continuidad
Objetivo: Abordar de forma explícita el mapa de SPoFs humanos y los riesgos críticos activos. Crear planes de continuidad concretos para cada riesgo de nivel CRÍTICO identificado en este informe.
Estructura de la sesión
- Presentación del mapa de SPoFs: visualización de quién sabe qué y qué pasaría si no estuviera (30 min)
- Por cada SPoF CRÍTICO: ¿qué pasaría si esta persona no está mañana? ¿Cuánto tiempo aguantamos? ¿Qué necesitamos documentar o transferir? (90 min)
- Asignación de planes de documentación: quién documenta qué, con qué fecha límite, con qué formato (30 min)
- Revisión del caso Power App Residuos: pasos específicos para la corrección de datos (30 min)
Decisión Estratégica del Núcleo y Roadmap 2026-2028
Objetivo: Ratificar las recomendaciones estratégicas de la sección 10, el modelo arquitectónico del núcleo tecnológico y las cinco decisiones de fondo, decidir el origen de las competencias que la transformación exige, priorizar el backlog completo y constituir el Comité de Tecnología. A diferencia de los dos workshops anteriores, este no delibera desde cero: trabaja sobre recomendaciones ya formuladas, que la Dirección valida, matiza o reorienta.
Estructura de la sesión
- Revisión de hallazgos de Workshops 1 y 2: ¿qué hemos resuelto? ¿qué queda pendiente? (20 min)
- Ratificación de la decisión del núcleo tecnológico: el modelo de componentes intercambiables y las cinco decisiones de fondo, Front/Back, modelo arquitectónico, horizonte de crecimiento, tipo de tecnología y competencias. La Dirección decide si las asume, las matiza o las reorienta (60 min)
- Decisión de origen de las competencias de la transformación: para cada uno de los siete bloques del mapa de la sección 10, acordar si se cubre con plantilla propia, de forma mixta o subcontratada (30 min)
- Compromiso de lanzamiento de la evaluación formal del PMS: confirmar el conjunto de candidatos, los criterios y el calendario de la RFP dentro de 2026 (30 min)
- Decisiones de área pendientes (CRM/CDP, LMS unificado, plataforma ESG, CoE de Power Platform): confirmación y secuenciación de las recomendaciones ya recogidas en este informe (40 min)
- Construcción del backlog: priorización de las 39 recomendaciones del informe en H1/H2/H3, con responsables y fechas (30 min)
- Constitución del Comité de Tecnología: charter, frecuencia, agenda tipo y primera fecha de reunión (30 min)
Próximos Pasos
El diagnóstico ha identificado el problema. El trabajo real empieza ahora. Estas son las acciones concretas para las próximas cuatro semanas.
Reclamación formal del código fuente a el partner tecnológico
Dirección + el Responsable PMS-ERP + el Responsable IT — Carta enviada por burofax y plazo de entrega abierto.
Inicio auditoría Power App Residuos
La Responsable de Impacto + el Responsable IT — Primera evaluación del volumen real de registros corruptos.
Convocatoria del Técnico BMS para documentación BMS
El Director de Ingeniería + el Técnico BMS — Inicio de sesiones de documentación técnica del BMS Circutor.
Reunión con el Responsable PMS-ERP — plan de sucesión y EdocAssistant
El Responsable PMS-ERP + el Responsable IT + el Director General — Acuerdo sobre el plan de transferencia de conocimiento y plazos.
Contacto con el proveedor del sistema (proveedor EdocAssistant)
El Responsable PMS-ERP + el Responsable IT — Evaluación de la situación contractual y del soporte disponible.
Activación integración Viterbit-Nivimu
La Directora de Personas + el Responsable IT — Proceso técnico de activación, pruebas y validación.
Workshop 1 — Gobernanza y Modelo de Datos
El Director General + el Responsable IT + Áreas — Modelo de datos corporativo acordado.
Workshop 2 — Riesgos y Continuidad
El Director General + Áreas críticas — Planes de continuidad para los 8 riesgos CRÍTICOS.
Workshop 3 — Decisión Estratégica del Núcleo y Roadmap
Dirección + Áreas — Recomendaciones estratégicas ratificadas, backlog priorizado y Comité de Tecnología constituido.
Evaluación formal de alternativas a Cendyn
El Responsable Marketing + Dirección — Informe de evaluación Cendyn vs. Revinate vs. Dailypoint.
Implementación tracking server-side
El Responsable Marketing + el Digital Manager — GA4 auditado + server-side tracking operativo.
Inventario completo Power Platform
El Responsable Lean + el Responsable IT — Mapa técnico de las 40+ apps con owners y criticidad.
Nota final
Este diagnóstico es un punto de partida, no un destino. Su valor no está en la lista de herramientas que describe, sino en el mapa de dependencias que revela y en las conversaciones que debería desencadenar. Las organizaciones que transforman bien su tecnología no son las que compran más software; son las que tienen más claridad sobre qué problema están resolviendo y quién es responsable de resolverlo.
El Cliente tiene la cultura, las personas y la base tecnológica para hacer esa transformación bien. La Dirección General abrió este proyecto con una frase que merece cerrarlo: "que la solución sea más sencilla y que sea mucho más posible trabajar aquí. Empezamos con estas palabras y terminamos con las mismas: simplicidad". Ese es el criterio último con el que el Cliente debe medir cualquier propuesta, cualquier partner y cualquier decisión técnica a partir de ahora. Si dentro de doce meses el equipo trabaja con menos fricción, el dato es fiable y ningún proceso crítico depende de una sola persona, este proyecto habrá tenido éxito, con independencia de los escenarios arquitectónicos que se elijan.