Relatório semanal de ocupação e receitas, avaliado para automação.

O negócio

Ambos os percursos seguem um único grupo hoteleiro e sem nome: opera três hotéis boutique e um espaço de eventos na mesma cidade, com um back office partilhado. As reservas vivem num sistema de gestão hoteleira, as receitas no ponto de venda, as compras em folhas de fornecedores, e a equipa coordena as alterações por email.

• Dono e gerente: O gerente geral do grupo, dono do relatório semanal e das políticas de eventos contra as quais os fluxos são configurados.
• Equipa: Coordenadores de receção, cozinha e eventos a trabalhar por turnos — precisamente a razão pela qual pedidos e números se perdem entre balcões.
• Sistemas envolvidos: A caixa de entrada partilhada, o sistema de gestão hoteleira, o ponto de venda, as folhas de fornecedores e o calendário de eventos partilhado.

O fluxo hoje

Todas as sextas-feiras, o gerente geral do grupo publica um relatório semanal sobre ocupação, tarifa, receitas dos pontos de venda e seguimentos de eventos nos três hotéis e no espaço de eventos. Hoje o trabalho é manual, repartido por quatro pessoas e quase sempre terminado contra o relógio — antes do fim de semana, quando ninguém tem tempo de o corrigir.

O fluxo proposto

O fluxo proposto mantém as mesmas pessoas e os mesmos direitos de decisão, e substitui apenas a montagem repetitiva: recolha, verificações de exaustividade, redação e distribuição passam a ser agendadas e registadas. A aprovação humana fica no meio do fluxo.

Dimensões da avaliação

Cada dimensão abaixo é raciocinada por si. Não há uma pontuação agregada — um fluxo é julgado por onde é forte, onde é condicional e se as pré-condições da secção seguinte estão cumpridas.

1. Recorrência

   Com que frequência acontece este trabalho?

   Alta — semanal e previsível

   O relatório corre numa cadência semanal fixa, com um conjunto de entradas e um resultado definidos. A recorrência é o que torna um fluxo digno de automação.

2. Valor

   O que é que a automação poupa ou melhora?

   Moderado, a acumular

   A montagem e a reconciliação consomem várias horas do coordenador e do gerente todas as semanas, e relatórios atrasados adiam decisões de tarifas e compras. O valor aqui é uma hipótese sobre tempo e fiabilidade — não um resultado medido, porque ainda nada foi medido.

3. Mensurabilidade

   Conseguimos observar o resultado?

   Forte

   O sucesso é visível e contável: relatório entregue a horas, todas as fontes incluídas, sem alterações não aprovadas, seguimentos fechados. As medidas propostas estão listadas na secção do piloto abaixo; nenhuma é apresentada como alcançada.

4. Prontidão dos dados

   As fontes são acessíveis e estáveis?

   Condicional

   O sistema de gestão hoteleira e o ponto de venda têm acesso estável e documentado. A folha de compras depende atualmente de uma pessoa que a envia por email, por isso a automação precisa de um caminho de acesso aprovado ou de uma fonte de substituição antes de o piloto a poder cobrir.

5. Esforço de integração

   Quanto trabalho é preciso para ligar?

   Baixo a moderado

   As ligações são só de leitura e o fluxo não escreve nos sistemas de origem. O esforço principal é mapear a folha de compras e acordar que campos são autoritativos.

6. Risco da ação

   O que pode correr mal?

   Baixo

   O fluxo não contacta hóspedes, não muda reservas nem tarifas e não movimenta dinheiro. Cada resultado é revisto por um humano antes da distribuição, por isso o raio de impacto de um erro é um rascunho interno, não uma ação consequente.

7. Carga de mudança

   Quanto tem a equipa de mudar?

   Baixa

   Papéis e responsabilidades ficam iguais: as unidades continuam a fornecer números e o gerente geral continua a aprovar o relatório. O que muda é quem o monta — precisamente a parte repetitiva.

8. Adequação ao piloto

   É um bom primeiro fluxo?

   Forte candidato

   É pesado em leitura, com portão de aprovação e baixo risco, com um dono responsável. A adequação é um juízo raciocinado sobre as dimensões acima, não uma pontuação ponderada — e é condicional às pré-condições listadas abaixo.

Responsabilidade e limites

Dono e gatilho

• Dono: O gerente geral do grupo, dono do relatório, da sua distribuição e dos seguimentos que levanta.
• Gatilho: Um horário semanal configurado — recolha quinta-feira, rascunho sexta-feira de manhã, distribuição após aprovação.

Sistemas e permissões

• Só de leitura: Sistema de gestão hoteleira, ponto de venda e folha de compras — as métricas são extraídas, nunca escritas.
• Escrita: Apenas a pasta partilhada de relatórios, onde o rascunho e o relatório aprovado são guardados.
• Distribuição: A lista de distribuição existente, usada apenas para o relatório aprovado.

Exclusões explícitas

• Sem mensagens a hóspedes de qualquer tipo.
• Sem alterações a reservas, tarifas ou registos financeiros.
• Sem escrita nos sistemas de origem, nem para «limpar» dados.
• Sem interpretação do que os números significam — isso fica com o gerente geral.

Pontos de controlo humanos

• Os donos dos dados confirmam ou fornecem as entradas em falta (com seguimento do agente).
• O gerente geral revê e aprova cada rascunho antes da distribuição.
• As ações são atribuídas a donos nomeados pelo gerente, não pelo agente.

Exceções

• Exceção empresarial: Uma unidade contesta uma definição de KPI — como as faltas de comparência contam para a ocupação, por exemplo — ou quer números diferentes. O cliente decide; o agente pausa e espera por orientação.
• Exceção técnica: Um sistema de origem está inacessível ou uma exportação está mal formada. A Disponi é dona da monitorização, da recuperação e da comunicação; o relatório é marcado como incompleto em vez de preenchido em silêncio.

Motivos para adiar ou rejeitar este fluxo

• As definições de KPI são disputadas e ninguém é dono delas.
• Uma fonte necessária não tem caminho de acesso aprovado nem substituição.
• Não há um dono de processo responsável para aprovar rascunhos e ser dono das ações.
• Espera-se que o relatório tome ou autorize decisões consequentes sem portão humano — a automação é adiada até existir um ponto de controlo humano.

Âmbito do piloto, aceitação e recomendação

Âmbito do piloto

Um piloto só de leitura de quatro semanas cobrindo o sistema de gestão hoteleira e o ponto de venda. O piloto separa as responsabilidades com clareza:

• O piloto faz: Recolhe fontes (leitura), corre verificações de exaustividade, dá seguimento a dados em falta (coordenação) e reúne o rascunho (preparação).
• O piloto não faz: Aprovar, distribuir ou acompanhar ações. A aprovação e a distribuição ficam totalmente manuais, e nenhuma escrita é feita em nenhum sistema de origem.

Critérios de aceitação

• Quatro relatórios semanais consecutivos concluídos através do fluxo do piloto.
• Todas as fontes esperadas recolhidas a tempo pelo menos 95% das vezes.
• Nenhuma alteração não aprovada a qualquer número entre a recolha e o rascunho.
• O gerente geral reconhece cada rascunho e aprova-o antes da distribuição.
• Nenhum dado é escrito num sistema de origem, e nenhuma mensagem é enviada a um hóspede.

Plano de medição

O piloto mediria: tempo de recolha das fontes, taxa de exaustividade, tempo da recolha ao rascunho aprovado, número de seguimentos de dados em falta, tempo de revisão e rascunhos a precisar de correção. Estas são medidas propostas para o piloto — nenhuma é um resultado alcançado, porque o piloto ainda não correu.

Recomendação condicional

Avançar com um piloto só de leitura de quatro semanas, sob três condições: o gerente geral torna-se formalmente dono do relatório e dos seus seguimentos; a folha de compras ganha um caminho de acesso aprovado (ou uma substituição); e um humano aprova cada rascunho antes da distribuição. Se as definições de KPI continuarem disputadas ou o acesso às fontes não for aprovado, adiar. Se o papel do relatório crescer para ação consequente sem portão humano, rejeitar.

Porque vem antes da coordenação

Os relatórios estão no início da progressão: observam e preparam, são só de leitura, e cada resultado é revisto. Uma primeira implementação segura deve ser a coisa útil menos arriscada — e é por isso que o percurso do fluxo mostra uma fase posterior, em que o mesmo grupo coordena alterações de eventos e encomendas a fornecedores com portões de aprovação e ação limitada. Nem todos os clientes seguem este caminho, e a Disponi não afirma o contrário.

1. ObservarFluxos só de leitura que recolhem e preparam informação.
2. PrepararRascunhos, verificações e seguimentos que ficam dentro da equipa.
3. Coordenar com aprovaçãoCoordenação entre sistemas que pausa para aprovação do cliente em pontos importantes.
4. Agir dentro da políticaAções limitadas e registadas dentro das regras definidas pelo cliente.

Ver o percurso do fluxo — a fase posterior e limitada →

O limite de operação partilhada

O mesmo modelo de responsabilidade aplica-se a todos os fluxos: o discernimento empresarial e a responsabilidade final ficam com o cliente; a operação da plataforma e os incidentes técnicos ficam com a Disponi.