Como introduzir um novo sistema de gestão hoteleira sem resistência da equipa

Porque é que a mudança de PMS costuma ficar estagnada

Na perspetiva de um gestor, um novo PMS é uma ferramenta melhor. Oferece mais funcionalidades, liga-se a mais canais e automatiza mais tarefas. A lógica da mudança costuma ser clara antes do início do projeto.

Na perspetiva de um colaborador da receção o novo sistema é algo desconhecido que substitui uma ferramenta que já domina. O sistema antigo, por mais limitado que seja, não lhe causa erros porque sabe exatamente como utilizá-lo. O novo exige aprendizagem, e aprender requer um tempo de que não dispõe durante um turno movimentado.

A resistência que surge — adoção lenta, soluções alternativas e regressos discretos ao processo antigo — não está relacionada com o software. Está relacionada com a própria mudança. A introdução de um PMS que aborde o problema humano em paralelo com o problema técnico tem muito mais probabilidades de se consolidar.

As quatro objeções da equipa — e o que realmente significam

Compreender o que a resistência da equipa realmente expressa é o primeiro passo para lhe dar resposta.

"O sistema antigo funciona bem." Isto é aversão à perda, não uma avaliação técnica. A equipa investiu tempo a aprender a utilizar o sistema atual. Substituí-lo transmite a sensação de que esse investimento está a ser desvalorizado. A resposta não consiste em argumentar que o novo sistema é melhor — consiste em reconhecer aquilo que o sistema atual faz bem e explicar especificamente o que o novo permite fazer que o antigo não permite.

"Não tenho tempo para aprender isto agora." Esta é uma preocupação legítima com a carga de trabalho, não uma desculpa. Se a formação for agendada durante períodos de ocupação máxima ou acrescentada a turnos completos sem qualquer ajuste, fracassará independentemente da qualidade do software. A resposta passa por um calendário de formação realista que trate a aprendizagem como uma tarefa profissional, e não como um projeto pessoal.

"É mais complicado do que o sistema que temos." Isto costuma refletir as primeiras experiências de integração, não a complexidade real do sistema. Uma apresentação de todas as funcionalidades de um novo PMS pode parecer excessiva quando aquilo de que a equipa necessita é uma demonstração dos fluxos de trabalho — o percurso específico para realizar as três tarefas que executa com maior frequência. A resposta é uma formação baseada nas funções, que começa por um âmbito limitado e só se expande depois de estabelecida a confiança.

"O que acontece se eu cometer um erro?" Trata-se do receio de consequências reais para os hóspedes. Um colaborador da receção que já tenha visto uma reserva duplicada ou uma cobrança incorreta transformar-se num problema que teve de resolver diante de um hóspede tem razão em levar os erros do sistema a sério. A resposta deve ser clara: isto é o que o sistema impede automaticamente, isto é o que deve fazer se algo correr mal e esta é a pessoa a contactar.

A implementação faseada: porque é que mudar tudo de uma só vez não funciona

Transferir toda uma equipa de um PMS para outro no mesmo dia cria o máximo risco com o mínimo apoio. Se surgir um problema no primeiro dia, todos o encontram ao mesmo tempo. Se uma funcionalidade se comportar de forma inesperada, ninguém terá experiência anterior com ela.

Uma implementação faseada funciona de outra forma. Distribui a adoção por etapas, permitindo acumular experiência antes de esta ser necessária em grande escala.

Fase 1 — Apenas configuração. O gestor ou proprietário configura o sistema: quartos, tarifas, canais e definições de pagamento. Não há envolvimento da equipa da receção ou da limpeza. Esta fase resulta num sistema pronto a utilizar sem expor a equipa a uma configuração inacabada.

Fase 2 — Formação inicial de um ou dois colaboradores. O estabelecimento utiliza ambos os sistemas em paralelo enquanto um ou dois colaboradores da receção aprendem a utilizar o novo PMS num dia de pouco movimento. Estes processam reservas reais no novo sistema, mantendo o antigo disponível como alternativa. A sua experiência permite identificar problemas antes de toda a equipa ser exposta ao novo sistema.

Fase 3 — Integração de toda a equipa. Com os colaboradores da Fase 2 a servirem como recursos internos, é dada formação à restante equipa. Os colaboradores da Fase 2 respondem às perguntas dos colegas em linguagem operacional — "quando tiver uma chegada da Booking.com, deve fazer isto" — com maior eficácia do que qualquer sessão de formação conduzida de cima para baixo.

Fase 4 — Desativação do sistema antigo. Após duas semanas de funcionamento em paralelo sem recorrer ao sistema de reserva, o sistema antigo é desativado.

Atualização dos procedimentos operacionais padrão antes da entrada em funcionamento

Procedimentos operacionais padrão que fazem referência ao sistema antigo tornam-se prejudiciais após uma mudança de PMS. Um procedimento da receção que indique "marcar o quarto como disponível no [sistema antigo]" não está apenas desatualizado — descreve a ferramenta errada para uma tarefa que agora se espera que o colaborador realize de outra forma.

Os procedimentos operacionais padrão devem ser atualizados antes da entrada em funcionamento, não depois. Os procedimentos que necessitam de revisão na maioria das transições de PMS são: a sequência de check-in e check-out, o procedimento de processamento de pagamentos, o fluxo de trabalho relativo ao estado dos quartos (quem atualiza o quê e quando) e o processo de não comparência e cancelamento.

Os procedimentos operacionais padrão atualizados devem seguir o fluxo de trabalho do novo sistema, em vez de reproduzirem o funcionamento do antigo. Se o novo sistema gerir o estado dos quartos através de um painel de limpeza em vez de uma chamada telefónica para a receção, o procedimento deve descrever o processo no painel de limpeza — e não explicar que "em vez de telefonar, agora deve abrir este ecrã".

As cópias impressas ou afixadas no local de utilização — na receção ou no posto da limpeza — são consultadas de forma mais consistente do que documentos partilhados guardados numa pasta que ninguém abre durante um turno movimentado.

Criar um ciclo de feedback que a equipa realmente utilize

A maioria dos comentários sobre um novo sistema não chega espontaneamente à gestão. Quando encontram um problema durante um turno, os colaboradores registam-no através da utilização de uma solução alternativa, não comunicando-o. Quando o gestor finalmente toma conhecimento de um problema recorrente, este já terá causado dificuldades invisíveis durante semanas.

Um ciclo de feedback estruturado promove a conversa durante o período em que esta é mais importante.

Durante as primeiras duas semanas após a entrada em funcionamento, faça uma reunião de cinco minutos no início ou no fim de cada turno, com uma ou duas perguntas específicas: "O que demorou mais do que esperava hoje?" e "O que teve de descobrir sem ajuda?" Estas perguntas produzem respostas que permitem agir — uma etapa específica do fluxo de check-in que não foi abordada na formação, um relatório que a equipa não consegue encontrar ou uma situação não contemplada pela formação.

O ciclo de feedback só funciona se a pessoa que o recolhe tiver autoridade para agir no prazo de 24 horas. Uma lista de problemas que aguarda duas semanas por uma resposta da gestão transmite à equipa que o mecanismo de feedback é meramente simbólico, e não funcional. Quando os colaboradores veem um problema comunicado ser corrigido ou tratado de imediato, continuam a reportar problemas. Caso contrário, deixam de o fazer.

Quando a resistência continua após a entrada em funcionamento

Se um colaborador continuar a utilizar o sistema antigo ou um processo alternativo duas semanas após a entrada em funcionamento, determine se a causa é uma questão de capacidade ou de escolha.

As lacunas de capacidade — quando o colaborador não consegue realmente concluir uma tarefa no novo sistema sem ajuda — exigem formação específica sobre esse fluxo de trabalho, não a repetição de toda a sessão de integração. O acompanhamento por um colega da Fase 2 que já tenha resolvido o mesmo problema costuma ser mais eficaz.

A resistência comportamental — quando o colaborador sabe utilizar o novo sistema, mas opta por não o fazer — exige uma conversa direta. A mensagem é simples: a empresa tomou esta decisão, o sistema é agora a forma como o estabelecimento funciona e espera-se que a equipa o utilize. Esta conversa é mais eficaz quando ocorre cedo, antes de a solução alternativa se tornar um hábito, e quando especifica claramente qual é o comportamento esperado.

Perguntas frequentes

Porque é que as equipas hoteleiras resistem a um novo PMS?

A resistência da equipa a um novo PMS costuma ser motivada por uma ou mais de quatro preocupações: aversão à perda relativamente ao sistema que já domina, pressão da carga de trabalho que faz parecer impossível encontrar tempo para aprender, primeiras experiências de integração que fizeram o sistema parecer mais complexo do que realmente é ou receio de cometer erros com consequências para os hóspedes. Cada preocupação exige uma resposta diferente — e tratar toda a resistência como um único problema costuma não resolver nenhuma delas.

O que é uma implementação faseada de um PMS?

Uma implementação faseada introduz o novo PMS por etapas, em vez de transferir toda a equipa no primeiro dia. A sequência habitual é: primeiro, a configuração apenas pelo gestor; depois, a formação de um ou dois colaboradores com reservas reais, utilizando em paralelo o sistema antigo; em seguida, a integração de toda a equipa, com os primeiros colaboradores a atuarem como recursos internos; e, por fim, a desativação do sistema antigo após duas semanas de funcionamento em paralelo sem recorrer ao sistema de reserva. A abordagem faseada reduz o risco e cria promotores internos antes da integração da restante equipa.

Que procedimentos operacionais padrão devem ser atualizados ao mudar de sistema de gestão hoteleira?

Os procedimentos operacionais padrão que exigem revisão imediata ao mudar de PMS são a sequência de check-in e check-out, o procedimento de processamento de pagamentos, o fluxo de atualização do estado dos quartos (quem atualiza o quê e quando) e o processo de não comparência e cancelamento. Os procedimentos atualizados devem ser redigidos de acordo com o fluxo de trabalho do novo sistema, em vez de explicarem passo a passo como este substitui o antigo. As cópias impressas no local de utilização são consultadas de forma mais consistente do que os documentos digitais partilhados.

Como recolher o feedback da equipa após a entrada em funcionamento de um Sistema de Gestão Hoteleira?

Realize um Check-in estruturado de cinco minutos no início ou no final de cada turno durante as primeiras duas semanas, utilizando perguntas específicas: «O que demorou mais do que o esperado hoje?» e «O que teve de descobrir sem ajuda?». O mais importante é agir com base no feedback no prazo de 24 horas — quando a equipa vê que os problemas são resolvidos de imediato, continua a comunicá-los. Quando os problemas comunicados ficam por resolver, deixa de o fazer. Um ciclo de feedback que não gera medidas visíveis num curto espaço de tempo acaba por deixar de gerar feedback.