Cambiar un menú en 100 establecimientos no debería tardar una semana

En la mayoría de los operadores hosteleros con múltiples establecimientos, el plan de proyecto para "actualizar el menú de primavera en todos los locales" ocupa cuatro páginas y se alarga durante tres semanas.

La primera semana se dedica a la herramienta de ingeniería de menús: escandallos, verificación de alérgenos, fotografía y aprobación del chef ejecutivo. La segunda semana abarca la coordinación del despliegue: correos electrónicos a los directores generales, hojas de formación para las brigadas de cocina y documentos de preguntas frecuentes para el personal de sala. La tercera semana es el despliegue técnico propiamente dicho: exportar el nuevo menú desde la herramienta de ingeniería de menús, cargarlo en el portal del proveedor de EPOS, enviarlo a cada TPV individual, actualizar el CMS del sitio web por separado, sincronizarlo de nuevo por separado con la plataforma de pedidos en línea, garantizar que las tabletas de servicio de habitaciones reciban la misma versión del menú y, finalmente, cruzar los dedos para que las pantallas de pedidos por código QR de las terrazas apunten al archivo de menú correcto.

Durante el despliegue, diferentes TPVs de un mismo establecimiento pueden mostrar distintas versiones del menú durante horas. El sitio web podría mostrar precios que no coinciden con los de la caja. El canal de pedidos en línea podría estar promocionando platos que la cocina ya ha retirado. La tableta de la habitación podría seguir con el menú de la temporada anterior porque nadie sabía que debía actualizarse por separado.

No es una exageración. Es la realidad operativa de cualquier grupo hostelero multilocal que utilice una arquitectura heredada. El director de Alimentos y Bebidas lo ha aceptado como el coste de operar. El equipo de TI ya no se entusiasma con los lanzamientos de menús. El equipo de atención al cliente dispone de guiones para gestionar las inevitables quejas del tipo "pero en la web ponía £14".

Este artículo explica por qué las cosas no tienen por qué ser así y cómo es una arquitectura cuando se diseña de forma diferente.

La razón arquitectónica por la que el despliegue de menús es lento

Esta lentitud tiene una causa fundamental: en la mayoría de las arquitecturas, el menú se duplica en cada sistema que necesita conocerlo. El EPOS tiene su copia. El CMS tiene su copia. La plataforma de pedidos en línea tiene su copia. La tableta de la habitación tiene su copia. La pantalla de pedidos por QR tiene su copia. La herramienta de ingeniería de menús tiene su copia. Cada copia reside en una base de datos distinta, con un esquema diferente y bajo la propiedad de un proveedor diferente.

Cuando el menú cambia, hay que actualizar cada copia. Cada actualización es una operación independiente. Cada operación presenta sus propios modos de fallo. La capa de integración que se supone que debe mantenerlos sincronizados existe solo de forma parcial, opera con sus propios tiempos de latencia y falla de manera silenciosa, manifestándose en forma de quejas de clientes dos días después.

La razón de ser de esta arquitectura es histórica. Cada sistema se adquirió por separado, en momentos distintos y por motivos diferentes. La herramienta de ingeniería de menús fue la última incorporación. El EPOS fue una decisión de compra de 2018. El CMS es aún anterior. Cada proveedor ha desarrollado su propio modelo de menú porque no le quedaba otra opción. Su producto necesita una estructura de menú para funcionar y ninguno podía confiar en que la estructura de otro proveedor estuviera disponible.

Por tanto, cualquier operador con una arquitectura fragmentada acaba teniendo cinco o seis "menús" que describen los mismos platos. Y cada operador ha diseñado un flujo de trabajo (formal o informal) para mantener sincronizados esos cinco o seis menús. Y todos han aceptado que, de vez en cuando, esa sincronización fallará.

Qué cambia cuando existe un único menú canónico

La arquitectura de mDOS adopta un enfoque diferente. Solo existe un menú. Se gestiona de forma centralizada para toda la empresa, junto con sus categorías y platos. A cada local simplemente se le asigna ese menú: no se trata de una copia, sino de una asignación con un conjunto opcional de ajustes específicos (overrides) para adaptar las diferencias particulares de cada establecimiento.

Se trata de un modelo de datos fundamentalmente distinto. No hay duplicidades. El sitio web, el EPOS, la tableta de la habitación, la pantalla QR y el canal de pedidos en línea leen exactamente de los mismos registros de platos. Cualquier cambio en un plato no requiere sincronización superficie por superficie, porque solo existe una copia.

Dado que todas las interfaces leen de esa única fuente, la edición de un menú se refleja la próxima vez que el menú se resuelva (al cargar una página o al consultar el menú desde un terminal). No hay copias que desplegar ni reconciliaciones entre proveedores. En el caso de cambios que deban aplicarse en pleno servicio sin esperar a una actualización (marcar como agotado o "86" un plato que se acaba de terminar), un canal de emisión en directo transfiere el cambio a cada interfaz conectada en tiempo real (consulte la sección sobre marcado de agotados más adelante).

La latencia medida desde que el operador hace clic en "Guardar" en el creador de menús hasta que el cambio está activo en todas las interfaces conectadas del grupo es de aproximadamente 200 milisegundos en el percentil 95.

No se trata de una cifra teórica. Una sola escritura en la base de datos, distribuida a través de un canal WebSocket, hace que cada TPV de cada local muestre el nuevo estado en menos de medio segundo. No hay margen para desajustes de versión. No hay proceso de carga terminal por terminal. No hay esperas.

El sistema de ajustes personalizados que permite operar a gran escala

Una arquitectura ingenua de "menú único" obligaría a que todos los locales fueran idénticos. El hotel rural con el menú degustación de £180 y el bar de vinos del centro urbano con los platos pequeños de £14 tendrían que utilizar menús totalmente independientes, lo que anularía las ventajas de la centralización.

mDOS resuelve esto mediante el sistema de modificaciones específicas (overrides). El menú base se define una sola vez a nivel corporativo. La asignación de cada local incluye un pequeño conjunto de modificaciones que pueden cambiar cualquier campo de cualquier elemento: precio, nombre, descripción, disponibilidad, alérgenos, etiquetas dietéticas, calorías, imagen, tipo de bebida, graduación alcohólica (ABV), disponibilidad en servicio de habitaciones, precio en servicio de habitaciones, grupos de modificadores, precio de opciones de modificadores, ubicación en categorías, disponibilidad por franja horaria o visibilidad de categorías completas.

El resolutor se ejecuta íntegramente en el lado del cliente una vez cargado el menú. La cascada de resolución es base → grupo → local, prevaleciendo la modificación del local en cada campo. El conjunto de modificaciones suele ocupar menos de 1 KB por local. La latencia de resolución es inferior a un milisegundo.

Lo que esto significa a nivel operativo: un grupo de 50 locales puede contar con una única definición de «menú de primavera» con 50 conjuntos de sustituciones específicas por local que gestionan los precios locales, los cambios regionales de ingredientes, las franjas de disponibilidad según la ubicación y la fotografía específica de cada establecimiento. Cualquier cambio en el menú base (por ejemplo, retirar un plato descatalogado) se propaga instantáneamente a los 50 locales. Un cambio en la sustitución de un único local (por ejemplo, subir el precio del filete en el local de Londres) afecta exclusivamente a dicho establecimiento sin alterar el menú base.

La alternativa tradicional consiste en 50 archivos de menú independientes, mantenidos de forma manual y requiriendo cada uno su propia actualización cuando cambia la base. La discrepancia entre ellos es inevitable, la carga administrativa es elevada y el margen de error es constante.

La barrera de publicación de Natasha's Law

En el Reino Unido, el Reglamento sobre la información alimentaria (conocido comúnmente como Natasha's Law) exige a los operadores de hostelería facilitar información completa sobre alérgenos para cualquier alimento preparado en el establecimiento y envasado para su venta. Las infracciones conllevan importantes sanciones administrativas y, en casos extremos, responsabilidad penal.

La mayoría de los sistemas de menús para hostelería gestionan el cumplimiento normativo sobre alérgenos en el código de la aplicación. El creador de menús muestra una advertencia si faltan alérgenos; el flujo de publicación comprueba que la información esté completa; el material de formación recuerda al personal que verifique los alérgenos antes de publicar. Sin embargo, un operador decidido o distraído puede eludir todo esto fácilmente.

mDOS lo gestiona a nivel de la capa de base de datos. Cada elemento del menú incluye un estado de alérgenos. Los elementos pendientes de verificación no se pueden publicar: una regla de la base de datos en la operación de publicación del menú detiene el proceso si se incluye algún elemento no verificado. La verificación requiere una acción explícita: un usuario autenticado con el rol adecuado marca el elemento como verificado y la base de datos registra quién lo verificó y cuándo, garantizando el registro de auditoría.

No se trata de una decisión de UX, sino de una decisión de arquitectura. La base de datos rechaza la publicación de elementos no verificados, independientemente de la interfaz que intente realizar la publicación, del usuario que la ejecute o de lo que el código de la aplicación considere aceptable. La barrera de cumplimiento no se puede omitir porque se impone en la capa inferior a la aplicación.

Para los operadores multilocal, esto resulta crucial durante una auditoría. Se puede mostrar a los inspectores la barrera directamente a nivel de base de datos. No un documento de políticas ni un certificado de formación, sino la regla literal de la base de datos que impide publicaciones no conformes. La postura de cumplimiento pasa de ser procedimental a ser arquitectónica.

Agotamiento de platos («86'ing») en tiempo real: el momento de la verdad operativo

El lanzamiento de menús es el escenario planificado. El escenario no planificado (y el más crítico a nivel operativo) es marcar un plato como agotado («86'ing») a mitad del servicio. La cocina se queda sin un ingrediente, el plato debe retirarse del menú de inmediato y todos los puntos de venta deben dejar de ofrecerlo al instante.

En un ecosistema fragmentado, este es un proceso manual. El chef avisa al encargado de sala; el encargado camina hasta cada TPV para actualizarlo; el sitio web sigue mostrando el plato durante el tiempo que tarde alguien en acordarse de actualizarlo; el canal de pedidos en línea sigue recibiendo comandas que la cocina no puede preparar, y las pantallas QR de la terraza continúan mostrándolo.

mDOS gestiona el agotamiento de productos mediante un único conmutador. El encargado de sala pulsa «No disponible» en el plato dentro de la interfaz de gestión de menús. La actualización marca el plato como no disponible con una marca de tiempo y un canal de emisión en directo de su empresa distribuye el cambio a todas las pantallas e interfaces conectadas casi al instante: cada TPV deja de mostrar el plato, cada pantalla QR lo deshabilita, cada interfaz de pedidos en línea lo marca como agotado y cada tableta en habitación lo oculta.

La cocina no vuelve a recibir ni un solo pedido del plato retirado. El chef no tiene que disculparse con la siguiente mesa, el camarero no se ve obligado a regresar incómodo a la cocina y el cliente nunca sufre la decepción de pedir algo que no se le puede servir.

Para los locales de gran volumen (un viernes por la noche concurrido, servicios con lleno completo o picos de máxima afluencia en destinos turísticos), esto es de suma importancia. Cada minuto de latencia entre el marcaje de «agotado» y el hecho de estar «realmente agotado en todas partes» es un minuto acumulando problemas. mDOS reduce esa latencia a medio segundo.

Lo que esto significa para la dirección de F&B

Para la dirección de Alimentos y Bebidas (F&B) de un grupo multilocal, la gestión de menús ha sido una de las limitaciones operativas más frustrantes de su función. La realidad técnica ha coartado sus posibilidades: la renovación de menús de temporada es un acontecimiento trimestral que tarda tres semanas en implantarse, y los pequeños ajustes a mitad de temporada resultan complicados de coordinar. Requieren ponerse de acuerdo con TI, operaciones, marketing y el equipo de marca; cuando el ajuste se implementa, la oportunidad ya ha pasado.

En una arquitectura unificada, la dirección de F&B puede aplicar cambios de menú de la forma en que realmente desea. El menú de primavera se despliega el lunes por la mañana en los 200 locales simultáneamente; un ajuste a mitad de semana basado en los datos de ventas iniciales se aplica el miércoles por la tarde; una promoción por tiempo limitado se lanza el viernes con ajustes específicos por local para precios regionales. La tecnología deja de ser el freno que limita la capacidad de actuación del área de F&B.

Para los compradores que evalúan mDOS como propiedad intelectual, la solidez arquitectónica del subsistema de gestión de menús es un indicador claro. La mayoría del software SaaS para hostelería aborda la gestión de menús como una funcionalidad periférica: una pantalla de edición básica sobre la tabla de menús de un proveedor, con una lógica de propagación limitada. mDOS lo trata como un subsistema principal con el mismo rigor que el motor de pagos: un modelo de datos canónico de fuente única, operaciones atómicas, distribución broadcast para agotamiento de platos y barreras de cumplimiento normativo en la capa de base de datos. La profundidad de ingeniería presente aquí refleja la profundidad de ingeniería en todo lo demás.

---

El subsistema de gestión de menús gestiona la resolución de base + sustituciones, la distribución broadcast para agotamiento de platos («86») y el control de verificación de alérgenos según Natasha's Law. Documentación técnica disponible bajo acuerdo de confidencialidad recíproco (NDA).