Informes del grupo en tiempo real

La mayoría de los informes para consejos de administración en hostelería son presentaciones elaboradas por un analista financiero los martes por la mañana para mostrar lo sucedido la semana anterior. Los datos son fiables, el formato es constante y el analista es competente. El problema es que, para cuando alguien los consulta, la realidad operativa que describen ya tiene una semana de antigüedad.

Para un operador con un solo establecimiento, esto es suficiente. La visión de hace una semana tiene el detalle necesario para tomar decisiones para la siguiente. Para un operador multiestablecimiento que gestiona 50, 200 o 1000 locales, esa imagen con una semana de antigüedad representa una desventaja estratégica. Las decisiones se toman basándose en datos desactualizados porque la infraestructura tecnológica no puede generar datos frescos sin recurrir a dicho analista.

Este artículo aborda cómo son los informes a nivel de todo el grupo cuando el cuadro de mando ejecutivo se encuentra a una sola consulta de la fuente operativa, así como los verdaderos compromisos de arquitectura que lo hacen posible.

El problema de la mayoría de los informes en hostelería

La mayoría de los grupos hosteleros multiestablecimiento cuentan con un stack fragmentado: PMS para hoteles, POS para F&B, gestor de canales para OTA, plataforma de reservas para mesas, sistema de fidelización para membresías, plataforma de marketing para correo electrónico, CRM para ventas B2B y una herramienta de informes independiente superpuesta a todas ellas.

Cada sistema dispone de su propia capa de informes. Cada capa responde a las preguntas en su propio formato, con su propio modelo de datos y en su propio ciclo de actualización. Las preguntas entre sistemas (las que realmente plantea el consejo) requieren una conciliación manual.

Una pregunta típica del consejo: "¿Qué grupos de establecimientos obtuvieron los mayores ingresos por hora de asiento disponible el último trimestre, desglosados por marca, y cómo se comparan con el mismo trimestre del año anterior?"

En un stack fragmentado, responder a esta pregunta requiere:

1. Exportar los datos del POS desde la herramienta de informes del proveedor del POS (por establecimiento, por mes y combinados manualmente)
2. Exportar los datos de reservas del proveedor de reservas (en un formato diferente, lo que requiere conciliación con el POS para evitar la doble contabilización)
3. Resolver la agrupación de establecimientos en una hoja de cálculo independiente (ya que ningún sistema conoce los "grupos de establecimientos" como una agrupación multimarca)
4. Calcular el REVPASH manualmente (ingresos ÷ horas de asiento disponibles), porque ningún sistema lo ofrece de forma nativa
5. Realizar la comparación interanual mediante otra serie de exportaciones para el periodo equivalente

Para cuando el analista termina, han pasado tres días. La cifra es correcta. Sin embargo, también llega demasiado tarde como para tomar medidas. Cuando el consejo se reúne para debatirlo, ha transcurrido otra semana más.

No se trata de un fallo del analista. Es un fallo de la arquitectura.

Qué cambia cuando los informes residen en la misma base de datos

La arquitectura de informes de mDOS adopta un enfoque diferente. No existe una base de datos de informes independiente. No hay ningún proceso ETL que traslade los datos operativos a un data warehouse durante la noche. El cuadro de mando ejecutivo ejecuta consultas SQL directamente contra las mismas tablas de Postgres en las que el POS, el PMS, el sistema de reservas y el motor de fidelización escriben en tiempo real.

Esto podría parecer un desastre de rendimiento. Lo sería si la arquitectura fuese simplista. Pero no lo es.

El diseño real es híbrido. Los cuadros de mando operativos (los que consultan los directores de establecimiento y de zona hora a hora durante el servicio) funcionan mediante consultas en directo sobre las tablas operativas. Su alcance se limita a un solo local o a un grupo reducido de ellos, por lo que los planes de consulta son rápidos (p95 inferior al segundo en las pruebas de carga medidas de la plataforma). Los datos están actualizados al instante exacto en que se carga la página.

Para las consolidaciones ejecutivas de todo el grupo, la plataforma también mantiene una capa de capturas precalculadas: una tarea programada (ejecutada en Trigger.dev, nuestro programador gestionado) agrega los datos operativos en una tabla de capturas todas las noches a las 3:00 UTC. Con la escala actual de la plataforma, los cuadros de mando ejecutivos siguen ofreciendo estas consolidaciones mediante consultas directas en todo el grupo (también en menos de un segundo en las pruebas de carga); la lectura desde la tabla de capturas precalculadas es la vía de escalado a medida que los grupos crecen hacia "los 300 locales, historial de transacciones completo, interanual", donde la agregación en directo acabaría siendo demasiado lenta para resultar útil.

La plataforma es transparente respecto a los compromisos asumidos. Los cuadros de mando operativos muestran la información "en tiempo real". La capa de capturas, una vez que la interfaz ejecutiva lee de ella, muestra los datos "a las 3:00 de hoy": su carga es instantánea, pero pueden tener hasta 24 horas de antigüedad. En cualquier caso, si el director financiero necesita datos del turno actual para una decisión específica, basta con desglosar la información en el cuadro de mando operativo y obtenerlos en directo.

Los cuatro alcances que hacen que el análisis del grupo funcione de verdad

El motivo por el que las preguntas entre sistemas resultan tan difíciles en stacks fragmentados es que ningún sistema individual conoce la verdadera estructura organizativa del cliente. El POS conoce los locales. La plataforma de reservas conoce los locales. El CRM puede conocer las marcas. Pero nada conoce las agrupaciones multimarca arbitrarias.

mDOS resuelve esto mediante cuatro niveles de alcance, integrados en la capa de informes a nivel de arquitectura.

Alcance de empresa: todos los locales de todo el grupo. Los informes subyacentes simplemente se ejecutan sin ningún filtro de establecimiento.

Alcance de marca: todos los locales pertenecientes a una marca específica, identificados mediante la búsqueda de los establecimientos vinculados a esa marca.

Alcance de grupo de establecimientos: agrupaciones multimarca arbitrarias, definidas especificando qué locales pertenecen a cada grupo. Un establecimiento puede formar parte de varios grupos, y los grupos nunca superan los límites de la empresa. Esto es algo que la mayoría de los competidores no pueden ofrecer. Un grupo como "todos los locales del centro de la ciudad de todas las marcas" es un único grupo de establecimientos en mDOS, consultable mediante una sola consulta. En un stack fragmentado, esta consulta requeriría combinar informes específicos por marca procedentes de múltiples sistemas de distintos proveedores y conciliar los datos manualmente.

Alcance de establecimiento: una sola propiedad. La vista estándar de un solo local.

La pregunta del consejo de administración que antes requería tres días («¿Qué grupos de locales obtuvieron el REVPASH más alto el trimestre pasado, desglosado por marca y en comparación interanual?») se resuelve ahora con la selección de un único filtro en el panel de control. La consulta se ejecuta en menos de un segundo sobre la tabla de instantáneas. El CFO obtiene la respuesta antes de pasar al siguiente punto del orden del día.

Lo que muestra realmente el panel ejecutivo

La vista general ejecutiva ofrece estas métricas a nivel de todo el grupo, con un desglose multinivel entre ámbitos:

Ingresos consolidados en una única cifra global procedentes de cinco fuentes (POS, alojamiento, restauración, OTA y gestor de canales). RevPAR, ADR y porcentaje de ocupación derivados de un cálculo de KPI específico para gestión hotelera. REVPASH calculado de forma nativa. Desglose de ingresos B2B mostrado de forma independiente.

Comensales y tiempos de rotación en las zonas de restauración, con porcentajes de utilización de capacidad, distribución por días de la semana y tasas de no presentación (*no-shows*). Métricas de fidelización a nivel de todo el grupo: recuento de miembros, distribución por niveles, tasas de canje y recompensas principales. Saldos del fondo de puntos corporativos y valor del tiempo de vida del contacto (*lifetime value*) en el umbral del percentil 75.

Volumen de envíos de correo electrónico y SMS, tasas de apertura y tasas de clics por campaña y flujo. Porcentajes de conversión del embudo con atribución de ingresos a nivel de paso y seguimiento UTM. Combinación de canales entre directo, OTA, orgánico y de pago. Puntuación media de valoraciones del grupo con análisis de sentimiento a lo largo del tiempo.

Todo ello es filtrable a través de los cuatro ámbitos (empresa, marca, grupo de locales y local), agrupable por día/semana/mes y computable en relación con el periodo anterior o el mismo periodo del año precedente. La resolución de zona horaria contempla las particularidades de cada local: cuando el CFO compara los locales de Londres con los de Nueva York, la comparación respeta el horario comercial local de cada establecimiento en lugar de aplicar un cálculo UTC básico.

Una limitación honesta

Este artículo no debe pretender que la arquitectura sea perfecta.

Un punto de conexión (*endpoint*) de informes heredado (informes de POS) utiliza actualmente un parámetro de local único obsoleto y no respeta el alcance de grupo de locales. Por defecto, recurre silenciosamente al modo de local único. La corrección está en curso y se desplegará en este *sprint*. Una vez implementada, todos los puntos de conexión de informes respetarán el modelo de cuatro ámbitos de forma uniforme.

Mencionamos esto porque la auditoría de compra (*due diligence*) lo detectará. El coste de disimularlo es mucho mayor que el de ser transparentes desde el principio.

Por qué esto es fundamental para las decisiones del consejo de administración

El CFO de un grupo de hostelería con 200 locales toma un número reducido de decisiones al trimestre que afectan de forma sustancial a la cuenta de pérdidas y ganancias (P&L). La calidad de dichas decisiones depende de la actualización, precisión y granularidad de los datos con los que trabaja.

Una arquitectura de informes que proporciona el REVPASH de todo el grupo en un segundo, desglosable por grupos de locales y con comparación interanual integrada, transforma el ritmo de toma de decisiones. Los consejos de administración pasan de «revisar el informe del analista del trimestre pasado» a «explorar preguntas en tiempo real en el panel durante la propia reunión». Las conversaciones estratégicas se vuelven más precisas porque los datos que las respaldan están más cerca de la realidad operativa.

Una arquitectura de informes que entrega esos mismos datos tres días después mediante una conciliación manual hace que esas conversaciones sean más lentas, imprecisas y dependientes de la intuición. La intuición puede ser acertada, pero también puede no serlo. La arquitectura debe eliminar esa incertidumbre, no perpetuarla.

Este es el objetivo de los informes en tiempo real para todo el grupo. No se trata de sustituir a los analistas: estos aportan un valor real mediante la interpretación y la recomendación. Se trata de garantizar que el tiempo del analista se dedique a la interpretación y no al trabajo mecánico de consolidar cinco exportaciones de distintos proveedores para obtener una cifra que debería estar a un solo clic de distancia.

---

La arquitectura de informes está construida sobre Postgres con consultas híbridas en tiempo real y de instantáneas. Documentación metodológica disponible bajo acuerdo de confidencialidad (NDA) mutuo.