Alterar um menu em 100 estabelecimentos não deveria demorar uma semana

Na maioria dos operadores de hotelaria e restauração com múltiplos estabelecimentos, o plano de projeto para "atualizar o menu de primavera em todas as unidades" ocupa quatro páginas e demora três semanas.

A primeira semana é dedicada à ferramenta de engenharia de menus: cálculo de custos, verificação de alergénios, fotografia, aprovação do chef executivo. A segunda semana é dedicada à coordenação da implementação: e-mails para os diretores-gerais, fichas de formação para as equipas de cozinha, documentos de FAQ para a equipa de sala. A terceira semana é a implementação técnica propriamente dita: exportar o novo menu da ferramenta de engenharia de menus, carregar para o portal do fornecedor de EPOS, enviar para cada caixa registadora individual, atualizar o CMS do site separadamente, sincronizar com a plataforma de pedidos online novamente em separado, garantir que os tablets de serviço de quarto recebem a mesma versão do menu e, finalmente, torcer para que os ecrãs de pedidos por QR code nas esplanadas estejam a apontar para o ficheiro de menu correto.

Durante a implementação, diferentes caixas registadoras no mesmo estabelecimento podem apresentar versões distintas do menu durante horas. O site pode estar a mostrar preços que não coincidem com os da caixa registadora. O canal de pedidos online pode estar a promover pratos que a cozinha já removeu. O tablet do quarto pode ainda estar com o menu da temporada anterior porque ninguém sabia que precisava de ser atualizado separadamente.

Isto não é um exagero. É a realidade operacional de qualquer grupo de hotelaria e restauração multi-estabelecimento que utilize uma arquitetura tecnológica legada. O Diretor de Comida e Bebidas já aceitou a situação como o custo de fazer negócios. A equipa de TI deixou de se entusiasmar com os lançamentos de menus. A equipa de apoio ao cliente tem guiões para gerir as inevitáveis reclamações do tipo "mas o site dizia £14".

Este artigo explica por que razão as coisas não têm de ser assim e como é a arquitetura quando não o são.

A razão arquitetural pela qual as atualizações de menus são lentas

Esta lentidão tem uma causa subjacente: na maioria das arquiteturas de software, o menu é duplicado em todos os sistemas que precisam dele. O EPOS tem a sua cópia. O CMS tem a sua cópia. A plataforma de pedidos online tem a sua cópia. O tablet do quarto tem a sua cópia. O ecrã de pedidos por QR code tem a sua cópia. A ferramenta de engenharia de menus tem a sua cópia. Cada cópia reside numa base de dados diferente, com um esquema diferente, pertencente a um fornecedor diferente.

Quando o menu muda, todas as cópias têm de ser atualizadas. Cada atualização é uma operação independente. Cada operação tem os seus próprios pontos de falha. A camada de integração que deveria mantê-los sincronizados existe apenas parcialmente, funciona com a sua própria margem de latência e falha silenciosamente de formas que culminam em reclamações de clientes dois dias depois.

A razão para a existência desta arquitetura é histórica. Cada sistema foi adquirido separadamente, em momentos distintos e por razões diferentes. A ferramenta de engenharia de menus foi a aquisição mais recente. O EPOS foi uma decisão de compra de 2018. O CMS é ainda anterior. Cada fornecedor desenvolveu o seu próprio modelo de menu porque não tinha alternativa. O seu produto precisa de uma estrutura de menu para funcionar e nenhum podia depender da disponibilidade da estrutura de outro fornecedor.

Assim, qualquer operador que utilize uma arquitetura fragmentada acaba por ter cinco ou seis "menus" que descrevem exatamente os mesmos pratos. E cada operador criou um fluxo de trabalho (formal ou informal) para manter esses cinco ou seis menus sincronizados. E cada operador aceitou que essa sincronização falhará pontualmente.

O que muda quando existe um único menu canónico

A arquitetura do mDOS adota uma perspetiva diferente. Existe apenas um menu. É mantido uma única vez para toda a empresa, acompanhado das suas categorias e pratos. Cada estabelecimento é simplesmente associado a ele: não se trata de uma cópia do menu, apenas de uma associação, com um conjunto opcional de sobreposições (overrides) para cobrir as especificidades de cada local.

Trata-se de um modelo de dados fundamentalmente diferente. Não há duplicação. O site, o EPOS, o tablet do quarto, o ecrã QR e o canal de pedidos online leem todos os mesmos registos de pratos. Qualquer alteração a um prato não exige sincronização por interface, pois existe apenas uma única cópia.

Como todas as interfaces leem a partir dessa fonte única, qualquer edição no menu reflete-se assim que o menu for novamente processado (o carregamento de uma página, a obtenção de menu por um terminal). Não há cópias para distribuir nem para reconciliar entre fornecedores. Para a única alteração que tem de ocorrer a meio do serviço sem esperar por uma nova obtenção (como indisponibilizar um prato que acaba de esgotar — o chamado 86'ing), um canal de transmissão em direto envia a alteração em tempo real para todas as interfaces ligadas (consulte a secção sobre 86'ing abaixo).

Latência medida desde o momento em que o operador clica em "Guardar" no construtor de menus até a alteração estar ativa em todas as interfaces ligadas do grupo: aproximadamente 200 milliseconds no percentil 95.

Este não é um número teórico. Uma única escrita na base de dados, distribuída através de um canal WebSocket, faz com que todas as caixas registadoras de cada estabelecimento apresentem o novo estado em menos de meio segundo. Não há janelas de desfasamento de versão. Não há etapas de carregamento por terminal. Não há esperas.

O sistema de sobreposição que o faz funcionar à escala do grupo

Uma arquitetura ingénua de "menu único" forçaria todos os estabelecimentos a serem idênticos. O hotel de charme no campo com o menu de degustação de £180 e o bar de vinhos no centro da cidade com os petiscos a £14 teriam de utilizar menus completamente separados, o que anularia as vantagens da centralização.

O mDOS resolve este problema através do sistema de sobreposições. O menu base é definido uma vez ao nível global da empresa. A associação de cada estabelecimento inclui um pequeno conjunto de sobreposições capazes de alterar qualquer campo de qualquer item: preço, nome, descrição, disponibilidade, alergénios, etiquetas dietéticas, calorias, imagem, tipo de bebida, teor alcoólico (ABV), disponibilidade para serviço de quarto, preço para serviço de quarto, grupos de modificadores, preço de opções de modificadores, alocação de categorias, disponibilidade por janela horária ou a visibilidade total de uma categoria.

O resolutor é executado puramente do lado do cliente após o carregamento do menu. A cascata de resolução é base → grupo → estabelecimento, com a sobreposição do estabelecimento a prevalecer ao nível de cada campo. O conjunto de sobreposições ocupa normalmente menos de 1KB por estabelecimento. A latência de resolução é inferior a um milissegundo.

O que isto significa em termos operacionais: um grupo de 50 estabelecimentos pode ter uma única definição de "menu de primavera" com 50 conjuntos de sobreposições específicas por estabelecimento que gerem preços locais, substituições regionais de ingredientes, janelas de disponibilidade específicas por localização e fotografia própria de cada espaço. Uma alteração ao menu base (por exemplo, remover um prato descontinuado) propaga-se instantaneamente para todos os 50 estabelecimentos. Uma alteração à sobreposição de um estabelecimento (por exemplo, aumentar o preço do bife no estabelecimento de Londres) afeta apenas esse espaço, sem alterar a base.

A alternativa legada consiste em 50 ficheiros de menu separados, cada um mantido manualmente, exigindo cada um a sua própria atualização quando a base altera. As discrepâncias entre eles são inevitáveis. A carga administrativa é significativa. A probabilidade de erro é constante.

O bloqueio de publicação da Lei de Natasha

No Reino Unido, o Regulamento sobre Informação Alimentar (comumente denominado Lei de Natasha) exige que os operadores de hotelaria e restauração forneçam informação completa sobre alergénios para qualquer alimento preparado nas instalações e embalado para venda. As infrações acarretam sanções regulamentares significativas e, em casos extremos, responsabilidade criminal.

A maioria dos sistemas de gestão de menus na restauração trata a conformidade relativa a alergénios no código da aplicação. O construtor de menus exibe um aviso se faltarem alergénios. O fluxo de trabalho de publicação verifica a integridade dos dados. O material de formação relembra a equipa para verificar os alergénios antes da publicação. Tudo isto pode ser ignorado por um operador determinado ou distraído.

O mDOS trata esta questão na camada da base de dados. Cada item do menu inclui um estado de alergénios. Os itens que ainda aguardam verificação não podem ser publicados: uma regra de base de dados na operação de publicação do menu interrompe o processo se for incluído qualquer item não verificado. A verificação exige uma ação explícita: um utilizador autenticado com a função adequada marca o item como verificado, e a base de dados regista quem o verificou e quando, para efeitos de auditoria.

Isto não é uma escolha de UX. É uma escolha de arquitetura. A base de dados recusa-se a publicar itens não verificados, independentemente da interface que tenta a publicação, do utilizador que a realiza ou do que o código da aplicação considera aceitável. O controlo de conformidade não pode ser ultrapassado porque é imposto na camada inferior à aplicação.

Para operadores com múltiplos estabelecimentos, isto é fundamental no momento da auditoria. Aos auditores regulamentares pode ser apresentado o bloqueio ao nível da base de dados. Não um documento de política interna, não um certificado de formação, mas a regra literal da base de dados que impede publicações não conformes. A postura de conformidade passa de processual a arquitetural.

Gestão de indisponibilidade ("86'ing") em tempo real: o momento de verdade operacional

O lançamento de menus é o cenário planeado. O cenário não planeado (e o que mais importa operacionalmente) é a indisponibilidade de itens em pleno serviço (o famoso "86'ing"). A cozinha fica sem um ingrediente. O prato precisa de ser retirado do menu no imediato. Todas as interfaces precisam de parar de o vender instantaneamente.

Numa arquitetura fragmentada, este é um processo manual. O chef avisa o chefe de sala. O chefe de sala desloca-se a cada ponto de venda e atualiza-o. O website continua a apresentar o prato durante o tempo que for preciso até que alguém se lembre de o atualizar. O canal de pedidos online continua a aceitar pedidos que a cozinha não consegue preparar. Os ecrãs de QR na esplanada continuam a exibi-lo.

O mDOS trata a indisponibilidade como uma simples alteração de estado. O chefe de sala toca em "Indisponível" no prato dentro da interface de gestão de menus. A atualização marca o prato como indisponível com um carimbo de data/hora, e um canal de transmissão em direto da sua empresa envia a alteração para todas as interfaces ligadas quase instantaneamente: cada ponto de venda deixa de exibir o prato, cada ecrã QR apresenta-o a cinzento, cada interface de pedidos online marca-o como esgotado, cada tablet no quarto oculta-o.

A cozinha nunca mais recebe outro pedido para o prato indisponível. O chef não tem de pedir desculpas à mesa seguinte. O empregado de mesa não tem de voltar embaraçado à cozinha. O cliente nunca passa pela desilusão de pedir algo que não pode ser servido.

Para estabelecimentos de grande movimento (noites de sexta-feira movimentadas, salas cheias ao jantar, horas de ponta num destino turístico), isto é de extrema importância. Cada minuto de latência entre marcar como "indisponível" e estar "efetivamente indisponível em todo o lado" é um minuto a acumular problemas. O mDOS reduz essa latência para meio segundo.

O que isto significa para o diretor de F&B

Para o Diretor de Alimentos e Bebidas (F&B) de um grupo com múltiplos estabelecimentos, o problema da gestão de menus tem sido uma das limitações operacionais mais frustrantes da sua função. A realidade técnica limitava o que podia fazer. As atualizações sazonais de menu são eventos trimestrais que demoram três semanas a implementar. Os ajustes a meio da temporada são complexos a nível organizacional. Exigem coordenação com IT, operações, marketing e a equipa de marca. Quando o ajuste é finalmente lançado, o momento já passou.

Numa arquitetura unificada, o Diretor de F&B pode lançar alterações de menu exatamente como deseja. O menu de primavera entra em vigor na segunda-feira de manhã em todos os 200 estabelecimentos simultaneamente. Um ajuste a meio da semana com base nos dados de vendas iniciais é lançado na quarta-feira à tarde. Uma promoção por tempo limitado é lançada na sexta-feira com sobreposições ao nível do estabelecimento para preços regionais. A tecnologia deixa de ser o fator limitador do que a área de F&B pode realizar.

Para investidores ou adquirentes que avaliam o mDOS enquanto propriedade intelectual (IP), a solidez arquitetural do subsistema de gestão de menus é um sinal inequívoco. A maioria do SaaS para a restauração e hotelaria trata a gestão de menus como uma funcionalidade periférica: um ecrã de edição básico sobre uma tabela de menu do fornecedor, com lógica de propagação limitada. O mDOS trata-a como um subsistema central com o mesmo rigor do motor de pagamentos: modelo de dados canónico de fonte única, operações atómicas, difusão de indisponibilidade por transmissão imediata, barreiras de conformidade na camada da base de dados. A profundidade de engenharia aqui demonstra a profundidade de engenharia no restante sistema.

---

O subsistema de gestão de menus trata a resolução de base + sobreposição, a difusão instantânea de indisponibilidades e o bloqueio de verificação de alergénios segundo a Lei de Natasha. Documentação técnica disponível mediante NDA mútuo.