PMS na nuvem ou local: guia de decisão para hotéis independentes

Qual é a diferença real entre nuvem e local?

Numa implantação na nuvem, a aplicação e a base de dados funcionam num ambiente operado pelo fornecedor. O hotel acede através de um navegador ou de um cliente leve. As cópias de segurança, a aplicação de atualizações e a capacidade são responsabilidade do fornecedor. A dependência do hotel é o caminho de rede até ao fornecedor.

Numa implantação local, a aplicação e a base de dados funcionam em servidores dentro do hotel. O hotel controla o hardware, a rede e o calendário de atualizações. A dependência se desloca para a capacidade local de TI: alguém tem de ser responsável pelo servidor, pelas cópias de segurança e pela janela de atualização.

O produto funcional pode ser idêntico. O que muda é onde vivem os modos de falha.

Quando faz mais sentido a nuvem?

A nuvem é normalmente a opção padrão certa para hotéis independentes e pequenos grupos. Retira o servidor da lista de riscos do hotel, torna os relatórios multi-hotel simples e mantém o software atualizado sem um projeto todos os anos.

É particularmente adequada quando o hotel tem uma ligação resiliente, uma equipe de TI pequena e nenhuma exigência regulatória de manter os dados dos hóspedes dentro do edifício. Também serve grupos que acrescentam hotéis mais depressa do que conseguem criar capacidade de TI.

• O hotel tem um caminho de internet principal e de reserva confiável.
• Não existe uma equipe interna de TI responsável pelos servidores e pelas cópias de segurança.
• O grupo quer relatórios consolidados sem um projeto de armazém de dados.
• O hotel espera acrescentar módulos ou quartos sem planejamento de hardware.

Quando o local ainda faz sentido?

O local não está obsoleto. Continua a ser a escolha honesta quando não se pode confiar na rede, quando os dados têm de permanecer numa jurisdição ou num edifício específicos, ou quando o hotel tem a disciplina de TI para o operar corretamente.

O erro é escolher o local para evitar uma subscrição na nuvem, subestimando o custo operacional: substituição do servidor, verificação das cópias de segurança, atualizações, energia e uma pessoa responsável.

• A residência de dados ou a política do proprietário exige que a base de dados permaneça no hotel.
• A WAN não é confiável e um sistema local é a única forma de manter a recepção a funcionar.
• O hotel já dispõe de uma sala de servidores disciplinada, com cópias de segurança testadas.
• Prefere-se um modelo de despesa de capital e o custo do ciclo de vida é compreendido.

O que significa realmente híbrido?

Híbrido significa normalmente um servidor no hotel que mantém as operações locais a funcionar, com os dados sincronizados para um ambiente central para relatórios e serviços de grupo. Se a WAN cair, o check-in, as faturas e a governança continuam localmente; quando a ligação regressa, as transações são reconciliadas.

O híbrido é mais complexo do que qualquer dos modelos puros, porque a reconciliação entre dados locais e centrais tem de ser concebida. Vale a complexidade quando a resiliência local e a visibilidade central são ambas requisitos genuínos.

Um desenho híbrido só é credível se alguém conseguir explicar, numa página, o que acontece a uma fatura lançada durante uma falha de WAN e como é reconciliada depois.

Como comparar o custo total?

Não compare o preço da subscrição com o preço do servidor. Compare o custo de propriedade a três anos, incluindo implementação, interfaces, renovação de hardware, cópia de segurança e recuperação, esforço de atualização, tempo da equipe interna e o custo de um fecho falhado.

Uma subscrição na nuvem que parece mais cara por mês pode ser mais barata do que uma implantação local que exige um novo servidor, um sistema de cópias de segurança e 20% de uma pessoa de TI. Uma implantação local que parece barata pode tornar-se cara na primeira vez que for necessária uma restauração e ninguém a tiver testado.

• Esforço de implementação e de migração de dados
• Desenvolvimento e manutenção de interfaces
• Hardware, energia, refrigeração e ciclo de substituição
• Cópias de segurança, testes de recuperação e atualizações de segurança
• Tempo da equipe interna para atualizações e incidentes
• Exposição a indisponibilidade durante a auditoria noturna e os picos de chegadas

O que deve constar do contrato, qualquer que seja o modelo escolhido?

O rótulo comercial é menos importante do que os compromissos operacionais. Peça-os por escrito, em linguagem simples, e certifique-se de que correspondem à forma como o seu hotel funciona realmente.

• Quem é o proprietário dos dados e como podem ser exportados num formato utilizável?
• Objetivos de tempo e de ponto de recuperação e quando foram testados pela última vez.
• Horários de suporte, tempos de resposta e o caminho de escalonamento às 02:00.
• O que acontece durante uma atualização falhada ou um incidente de segurança.
• Condições de saída: prazo de aviso, extração de dados, execução em paralelo e eliminação.
• Que interfaces estão incluídas, quais são cobradas e quem assume uma falha de terceiros.

Como a decisão de implantação muda conforme o porte do hotel?

Em um hotel de 10–60 quartos, muitas vezes não há sala de servidores e raramente existe uma pessoa dedicada à TI. O gerente geral, o proprietário ou um gerente de plantão é o que mais se aproxima de um suporte técnico, e a equipe da recepção cobre check-in, reservas e concierge no mesmo turno. Nesse cenário, a decisão de implantação trata principalmente do caminho de rede e de quem atende às 02:00. A nuvem é o padrão mais comum porque retira o servidor do prédio e mantém atualizações e backups com o fornecedor. O ambiente local continua defensável quando uma regra legal ou do proprietário mantém os dados do hóspede dentro do hotel, ou quando a única conexão disponível não suporta a recepção. Seja qual for o modelo, registre por escrito o que a recepção faz quando a conexão cai: quais chegadas ainda podem ser processadas, como as chaves são emitidas e onde as cobranças são lançadas até o link voltar. Um único hotel pequeno raramente precisa de um segundo data center, mas precisa de um segundo caminho para a internet e de uma pessoa nomeada para chamar. Escreva o procedimento offline em uma página e teste-o em uma semana tranquila, não em um dia de lotação máxima.

Entre 60 e 250 quartos, o hotel ganha departamentos, interfaces e escalas de turno. A recepção funciona 24 horas em 3 turnos, e o PMS conversa com o PDV, as fechaduras, o channel manager, os terminais de pagamento e, às vezes, um sistema de spa ou golfe. Check-in e auditoria noturna dependem dessas interfaces, então os modos de falha se multiplicam mesmo que o software não mude. É nessa faixa que o híbrido se torna uma opção real, e não um compromisso: um servidor local mantém a recepção e os pontos de venda funcionando durante uma queda de WAN, enquanto os dados sincronizam para um ambiente central para relatórios. É também onde o hotel costuma ter um profissional generalista de TI ou um provedor de serviços gerenciados, o que muda a resposta honesta sobre o ambiente local. A questão a resolver não é nuvem ou local, mas quais funções precisam sobreviver à perda de conexão e quais podem esperar. Se a resposta inclui check-in, folios e governança, a arquitetura precisa refletir isso. Se apenas os relatórios podem esperar, uma implantação em nuvem com um procedimento offline documentado costuma ser mais simples de operar.

Acima de 250 quartos, e em resorts com vários prédios, o hotel se comporta como um pequeno campus. Há vários pontos de venda, banquetes, lazer, vários armários de cabeamento e uma equipe noturna presente no local em vez de ficar de sobreaviso. Caminhos de internet redundantes, uma sala de servidores com acesso controlado e uma função de TI são expectativas normais nessa escala, e a decisão de implantação se torna um exercício de desenho: quais serviços rodam localmente, quais rodam centralmente e como os dois se reconciliam quando um link falha. Um resort também pode enfrentar regras de dados no país onde opera, e um grupo pode querer uma camada única de relatórios entre hotéis sujeitos a regras diferentes. É essa combinação que justifica a complexidade do híbrido, mas somente se a reconciliação for especificada com antecedência. Latência na recepção, o comportamento dos terminais de pagamento durante um failover e a rota de suporte remoto do fornecedor merecem um teste antes da abertura, não um parágrafo no contrato. Energia e refrigeração para o rack local também se tornam responsabilidade de alguém, e essa responsabilidade deve ser nomeada no modelo operacional.

Defina as restrições determinantes antes de comparar produtos. Primeiro, as obrigações de dados: se alguma lei, acordo de franquia ou política do proprietário exige que os dados do hóspede permaneçam em uma jurisdição ou no hotel. Segundo, a realidade da rede: se existem dois caminhos genuinamente independentes e quando o failover foi testado pela última vez. Terceiro, a propriedade da recuperação: quem executa uma restauração, com que frequência e quais evidências são mantidas. Quarto, o custo de 3 a 5 anos no mesmo escopo, incluindo interfaces, renovação de hardware e tempo da equipe, e não apenas a linha da assinatura. Quinto, a saída: como é um export utilizável e por quanto tempo a operação em paralelo é permitida. Essas cinco respostas geralmente reduzem a escolha a um modelo antes de qualquer demonstração. Uma disciplina útil é escrever a resposta de cada restrição em um parágrafo curto e pedir ao fornecedor que responda por escrito, e não em uma apresentação. A condição limite é o teste das 02:00. Se ninguém consegue explicar quem é chamado, o que a recepção faz e como as transações faltantes são reconciliadas, o rótulo no contrato não salvará a noite.

• A recepção consegue continuar fazendo check-in por 4 horas sem a WAN?
• Existe um segundo caminho de internet, e o failover foi testado este ano?
• Alguma lei ou política do proprietário exige que os dados do hóspede fiquem no hotel?
• Quem executa um teste de restauração, e onde o resultado é registrado?
• Os custos de 3 a 5 anos são comparados com escopo e interfaces idênticos?