Relatórios da rede em tempo real

A maioria dos relatórios para conselhos de administração no setor da hotelaria é uma apresentação elaborada por um analista financeiro na manhã de terça-feira, mostrando o que aconteceu na semana anterior. Os dados são fiáveis, a formatação é consistente, o analista é competente. O problema é que, no momento em que alguém olha para eles, a realidade operacional descrita já tem uma semana.

Para um operador com um único espaço, isto não tem problema. O panorama de há uma semana é suficientemente detalhado para tomar decisões para a semana seguinte. Para um operador multiespaço que gira 50, 200 ou 1,000 estabelecimentos, um panorama com uma semana é um risco estratégico. As decisões são tomadas com base em dados desatualizados porque o ecossistema tecnológico não consegue produzir dados recentes sem esse analista.

Este artigo aborda como são os relatórios para toda a rede quando o painel executivo está a apenas uma consulta de distância da fonte operacional, bem como os compromissos arquiteturais transparentes que os tornam possíveis.

O problema com a maioria dos relatórios na hotelaria

A maioria dos grupos hoteleiros e de restauração multiespaço tem um ecossistema fragmentado: PMS para hotéis, POS para F&B, channel manager para OTAs, plataforma de reservas para mesas, sistema de fidelização para membros, plataforma de marketing para e-mail, CRM para vendas B2B e uma ferramenta de relatórios independente sobreposta a tudo isto.

Cada sistema tem a sua própria camada de relatórios. Cada camada de relatórios responde a questões no seu próprio formato, de acordo com o seu próprio modelo de dados e no seu próprio ciclo de atualização. As questões transversais aos sistemas (aquelas que o conselho de administração realmente coloca) exigem uma reconciliação manual.

Uma pergunta típica do conselho de administração: "Quais os grupos de estabelecimentos que registaram a maior receita por lugar-hora disponível no último trimestre, desagregada por marca, e como se comparou com o mesmo trimestre do ano passado?"

Num ecossistema fragmentado, responder a esta questão exige:

1. Exportar dados do POS a partir da ferramenta de relatórios do fornecedor do POS (por estabelecimento, por mês, combinados manualmente)
2. Exportar dados de reservas do fornecedor de reservas (formato diferente, exige reconciliação com o POS para evitar dupla contagem)
3. Mapear o agrupamento de estabelecimentos numa folha de cálculo separada (pois nenhum sistema isolado reconhece "grupos de estabelecimentos" como um conjunto multimarca)
4. Calcular o REVPASH manualmente (receita ÷ lugares-hora disponíveis), uma vez que nenhum sistema o relata nativamente
5. Comparação homóloga através de outro conjunto de exportações para o período equivalente

Quando o analista termina, já passaram três dias. O valor está correto. Contudo, o valor chega demasiado tarde para ser útil. Quando o conselho de administração se reúne para o discutir, já se passou outra semana.

Isto não é uma falha do analista. É uma falha da arquitetura.

O que muda quando os relatórios residem na mesma base de dados

A arquitetura de relatórios do mDOS adota uma abordagem diferente. Não existe uma base de dados de relatórios separada. Não existe qualquer processo ETL a transferir dados operacionais para um data warehouse durante a noite. O painel executivo executa consultas SQL diretamente nas mesmas tabelas Postgres onde o POS, o PMS, o sistema de reservas e o motor de fidelização estão a escrever em tempo real.

Isto pode parecer um desastre de desempenho. E seria, se a arquitetura fosse ingénua. Mas não é.

O design real é híbrido. Os painéis operacionais (aqueles que os gestores de estabelecimento e os gestores regionais consultam hora a hora durante o serviço) funcionam como consultas em tempo real às tabelas operacionais. Estão delimitados a um único estabelecimento ou a um pequeno grupo de estabelecimentos, pelo que os planos de consulta são rápidos (p95 inferior a um segundo nos testes de carga medidos na plataforma). Os dados estão atualizados até ao momento do carregamento da página.

Para agregações executivas em toda a rede, a plataforma mantém igualmente uma camada de instantâneos pré-calculados: uma tarefa agendada (executada no Trigger.dev, o nosso agendador gerido) agrega os dados operacionais numa tabela de instantâneos todas as noites às 3am UTC. À escala atual da plataforma, os painéis executivos ainda disponibilizam estas agregações sob a forma de consultas em tempo real a toda a rede (também inferiores a um segundo nos testes de carga medidos); a leitura a partir da tabela de instantâneos pré-calculados é o caminho de escalabilidade à medida que as redes crescem no sentido de "todos os 300 estabelecimentos, histórico completo de transações, de ano para ano", onde a agregação em tempo real acabaria por se tornar demasiado lenta para ser útil.

A plataforma é transparente quanto aos compromissos assumidos. Os painéis operacionais mostram dados "até ao momento". A camada de instantâneos, assim que uma interface executiva a consulta, mostra dados "às 3am de hoje": carregamento instantâneo, mas com até 24 horas de desatualização. De qualquer forma, se o CFO precisar de dados do turno atual para uma decisão específica, basta aceder ao painel operacional para os obter em tempo real.

Os quatro âmbitos que fazem a análise da rede realmente funcionar

A razão pela qual as questões transversais são tão difíceis em ecossistemas fragmentados é que nenhum sistema individual conhece a verdadeira estrutura organizacional do cliente. O POS conhece os estabelecimentos. A plataforma de reservas conhece os estabelecimentos. O CRM poderá conhecer as marcas. Mas nenhum sistema conhece conjuntos multimarca arbitrários.

O mDOS resolve isto através de quatro níveis de âmbito, integrados na camada de relatórios ao nível da arquitetura.

Âmbito da empresa: todos os estabelecimentos em toda a rede. Os relatórios subjacentes são simplesmente executados sem filtro de estabelecimento.

Âmbito da marca: todos os estabelecimentos sob uma marca específica, identificados ao procurar os estabelecimentos pertencentes a essa marca.

Âmbito do grupo de estabelecimentos: conjuntos multimarca arbitrários, definidos ao listar os estabelecimentos pertencentes a cada grupo. Um estabelecimento pode pertencer a vários grupos e os grupos nunca ultrapassam os limites das empresas. É algo que a maioria dos concorrentes não consegue oferecer. Um grupo como "todos os estabelecimentos no centro da cidade em todas as marcas" é um único grupo de estabelecimentos no mDOS, consultável numa única consulta. Num ecossistema fragmentado, esta consulta exigiria a combinação de relatórios específicos de marca de múltiplos sistemas de fornecedores e a sua reconciliação manual.

Âmbito do estabelecimento: propriedade individual. A visualização padrão de um único estabelecimento.

A questão para o conselho de administração que antes demorava três dias ("Quais os grupos de estabelecimentos que registaram o REVPASH mais elevado no último trimestre, discriminados por marca, face ao ano anterior?") resume-se agora a uma seleção de filtro no dashboard. A consulta é executada em menos de um segundo sobre a tabela de instantâneos. O CFO tem a resposta antes de se passar ao ponto seguinte da ordem do dia.

O que o dashboard executivo realmente mostra

A visão geral executiva apresenta estas métricas para todo o portfólio, com detalhamento inter-âmbitos:

Receita proveniente de cinco fluxos (POS, alojamento, serviço de mesa, OTA, gestor de canais) consolidada num único valor global para todo o portfólio. RevPAR, ADR e percentagem de ocupação resultantes de um cálculo dedicado de KPI hoteleiros. REVPASH calculado de forma nativa. Desagregação da receita B2B apresentada separadamente.

Número de clientes (covers) e tempos de rotatividade nos espaços de refeição, com percentagens de utilização da capacidade, distribuição por dia da semana e taxas de no-show. Contagem de membros do programa de fidelização à escala de todo o grupo, distribuição por níveis, taxas de resgate e principais recompensas. Saldos dos fundos de pontos corporativos e valor do ciclo de vida dos contactos no limiar do percentil 75.

Volume de envio de e-mails e SMS, taxas de abertura e taxas de clique por campanha e fluxo. Percentagens de conversão do funil com atribuição de receita ao nível da etapa e rastreio UTM. Mix de canais distribuído entre direto, OTA, orgânico e pago. Pontuação média de avaliações do grupo com análise de sentimento ao longo do tempo.

Tudo isto pode ser filtrado através dos quatro âmbitos (empresa, marca, grupo de estabelecimentos, estabelecimento), agrupado por dia/semana/mês e comparado com o período anterior ou com o mesmo período do ano anterior. A resolução do fuso horário tem em conta cada estabelecimento: quando o CFO compara estabelecimentos de Londres com os de Nova Iorque, a comparação respeita o horário de funcionamento local de cada estabelecimento, em vez de recorrer a uma simples hora UTC.

Uma lacuna assumida

Este artigo não deve pretender que a arquitetura seja perfeita.

Um endpoint legado de relatórios (relatórios de POS) utiliza atualmente um parâmetro descontinuado de estabelecimento único e não respeita o âmbito por grupo de estabelecimentos. Como alternativa silenciosa, recorre ao modo de estabelecimento único. A correção está em curso e será lançada neste sprint. Assim que for disponibilizada, todos os endpoints de relatórios respeitarão o modelo de quatro âmbitos de forma uniforme.

Mencionamos isto porque a due diligence de um comprador iria identificá-lo. O custo de fingir o contrário é muito mais elevado do que o custo de ser transparente.

Por que razão isto é determinante para as decisões do conselho de administração

O CFO de um grupo de hotelaria e restauração com 200 estabelecimentos toma um número reduzido de decisões por trimestre que afetam materialmente a demonstração de resultados (P&L). A qualidade dessas decisões depende da atualidade, exatidão e granularidade dos dados com que trabalha.

Uma arquitetura de relatórios que apresenta o REVPASH de todo o portfólio em um segundo, com capacidade de detalhe até aos grupos de estabelecimentos e comparação homóloga integrada, altera o ritmo de tomada de decisão. Os conselhos de administração passam de "analisar o relatório do analista do trimestre anterior" para "explorar questões em tempo real no dashboard durante a reunião". As conversas estratégicas tornam-se mais incisivas porque os dados que as suportam estão mais próximos da realidade operacional.

Uma arquitetura de relatórios que fornece os mesmos dados três dias mais tarde, através de reconciliação manual, torna essas conversas mais lentas, vagas e dependentes da intuição. A intuição pode estar certa, mas também pode não estar. A arquitetura deve eliminar essa incerteza, e não preservá-la.

É para isto que servem os relatórios em tempo real do portfólio. Não se trata de substituir os analistas: os analistas acrescentam valor real através da interpretação e de recomendações. Trata-se de garantir que o tempo do analista é dedicado à interpretação e não ao trabalho mecânico de cruzar exportações de cinco fornecedores para produzir um número que devia estar à distância de uma simples consulta.

---

A arquitetura de relatórios é desenvolvida sobre Postgres com consultas híbridas em tempo real/instantâneo. Documentação sobre a metodologia disponível mediante NDA mútuo.