Odoo + computer vision en restaurantes: caso Dodo Pizza para LATAM

Cada sábado: 287 000 eventos. Cada uno es telemetría

Sábado, 21:14 hora de Lima. La pizzería Dodo Pizza en Miraflores recibe un pedido. A los 11 milisegundos el evento order.created cae en Kafka. A los 84 segundos la tablet de cocina avisa al pizzero: «En 8 minutos llega una ola de 12 pedidos — empieza a estirar masa ahora». A las 21:39 el repartidor cierra la puerta del auto con la pizza adentro, y la métrica delivery_time en el dashboard del COO en Ciudad de México se actualiza en tiempo real.

No es ciencia ficción ni una charla TED. Es la infraestructura que Dodo Pizza viene construyendo desde 2018 y que permitió a la red crecer de 64 a más de 100 puntos en LATAM sin aumentar el equipo regional. Cada local genera unos 287 000 eventos un sábado de pico. Cada evento pasa por computer vision, un procesador de streaming y el billing de Odoo en menos de 100 ms.

Si gestionas una red QSR en Perú, México, Colombia o Chile y te enteras de un sábado fallido leyendo Excel el lunes a la mañana — no tienes un sistema operativo. Tienes un archivo. Y ese archivo cuesta cada mes entre 8 y 15% de margen perdido: pedidos pasados de cocción, switch entre POS desincronizados, errores de armado, sobre-pago de repartidores en horas valle.

Lo que sigue es la disección técnica concreta: cómo conectar Odoo POS Restaurant con un stack de computer vision, qué módulos necesitas, qué hardware comprar, en qué casos el pilot se paga en 6 meses y en cuáles nunca. Nos apoyamos en datos públicos de Dodo Pizza (incluidos repositorios abiertos de Dodo IS) y en la experiencia paralela de Domino's con DOM Pizza Checker.

Resumen en un minuto

01. Computer vision en QSR es una práctica madura desde 2019. Domino's (DOM Pizza Checker), Dodo Pizza (Dodo IS), Wendy's, Taco Bell — cada uno opera su propio stack.

02. Odoo por sí solo no hace CV. La combinación: point_of_sale + pos_restaurant + iot + un módulo bridge custom hacia MQTT/Kafka + edge-inference en NVIDIA Jetson (alternativa cloud: AWS Rekognition o Vertex AI).

03. Piloto de 3-5 puntos: USD 28 000-USD 60 000 en 12 semanas. Payback de 6-10 meses con reducción de tiempo de cocina 15-20% y caída de reclamos 25-30%.

04. No es para todos. Umbral mínimo: 5 puntos o USD 2M de facturación anual. Por debajo, CV no se amortiza.

05. El error más frecuente es arrancar por el dashboard para C-level. La adopción real llega del tablet en cocina con latencia < 200 ms.

De dónde sale la tendencia: timeline CV en restaurantes 2019-2026

Computer vision en QSR no apareció ayer. La cronología de los hitos clave:

#1. 2019 — Domino's lanza DOM Pizza Checker

Domino's pone DOM Pizza Checker en producción en Australia. Un modelo CV sobre iOS revisa cada pizza antes de hornear: distribución correcta de los toppings, forma, presencia de todos los ingredientes. Los locales con menos del 80% de pizzas «correctas» están obligados a rehacer el pedido.

#2. 2020 — Dodo Pizza escala Dodo IS a 13 países

La red de Fyodor Ovchinnikov tiene una plataforma IT abierta que controla todo el ciclo: del pedido al despacho. Los modelos CV verifican la forma de la masa, la cantidad de queso, el tiempo de horneado. Los eventos se publican en una «vitrina online» pública — cualquiera ve cuántas pizzas produjo cada local en el día.

#3. 2021 — abaratamiento masivo del edge hardware

NVIDIA lanza Jetson Nano por USD 99, ONNX Runtime soporta Raspberry Pi 4, AWS Rekognition Custom Labels cobra USD 1 cada 1 000 requests. El umbral de entrada en CV para QSR cae un orden de magnitud.

#4. 2022 — kitchens robotizadas

Chipotle y Sweetgreen experimentan con cocinas robotizadas. El CV no se usa para control de calidad sino para coordinar al robot que arma bowls. Precisión de 96%+ sobre recetas estandarizadas.

#5. 2023 — voice-AI muere, CV sigue vivo

McDonald's cierra el piloto IBM voice-AI en drive-thru — el asistente de voz no manejó los acentos ni el ruido de fondo. Pero el CV para contar autos en la cola y predecir carga de cocina sigue siendo mainstream — instalado en más de 1 500 puntos de Wendy's y Taco Bell.

#6. 2024 — Odoo 18 trae POS Restaurant mejorado

Octubre 2024. Aparece el POS Restaurant mejorado con generación automática de kitchen tickets, y la nueva Odoo IoT Box soporta MQTT 5.0 nativo. Primer release donde integrar Odoo con eventos CV streaming deja de ser un proyecto épico.

#7. 2025 — explosión de foundation models para CV

YOLOv11 (Ultralytics), Segment Anything 2 (Meta), Florence-2 (Microsoft). El fine-tuning sobre un menú específico ahora requiere 200-500 imágenes etiquetadas en lugar de 5 000. Time-to-production cae de 3 meses a 3 semanas.

#8. 2026 — Odoo 19 anuncia conector Kafka nativo

Esperado en octubre 2026. Resolvería el cuello de botella principal para stacks real-time — por ahora se ataja con un módulo custom pos_event_publisher.

Requisitos técnicos: cómo conectar Odoo con computer vision

La arquitectura se divide en cuatro capas. Vamos una por una.

#1. Captura de eventos en Odoo

Módulos base:

• point_of_sale (community y enterprise) — el POS
• pos_restaurant (enterprise o OCA fork) — extensión para restaurantes: mesas, división de cuenta, kitchen displays. Detalle de funciones en la página oficial Odoo Restaurants.
• iot (enterprise o OCA iot) — para conectar IoT Box a balanzas, termómetros, marcadores BLE de bandejas.
• stock + mrp (opcional) — si necesitas trazar «queso → pizza → cliente» en un flujo único.

Lo que no viene en core:

• pos_event_publisher — módulo bridge custom. Escucha hooks de pos.order y publica JSON hacia MQTT broker o Kafka. ~200 líneas: una automated action de Odoo más Python con paho-mqtt o confluent-kafka.

Hay módulos OCA tipo pos_kitchen_screen que resuelven parte del problema, pero el event-publisher casi todos los equipos lo escriben a medida — los schemas de eventos son demasiado específicos del negocio.

#2. CV inference

Edge o cloud. Para LATAM recomiendo edge.

Edge (NVIDIA Jetson + cámara):

• Hardware: Jetson Nano 8GB (~USD 249) o Orin Nano 8GB (~USD 499). Cámara Sony IMX477 (~USD 75). Carcasa con refrigeración pasiva obligatoria — la cocina es caliente.
• Modelo: YOLOv8n / YOLOv11n (Ultralytics, AGPL — para uso comercial necesitas Enterprise license desde USD 2 500/año). Alternativa: RT-DETR o MobileNet-SSD bajo Apache 2.0.
• Runtime: ONNX Runtime o TensorRT. Latencia 40-80 ms por frame 720p.
• Qué reconocemos: distribución correcta de los toppings, forma de la masa, presencia de ingredientes en la bandeja, integridad del packaging.

Cloud (para pilotos / volumen bajo):

• AWS Rekognition Custom Labels — USD 1/1 000 requests, latencia 300-600 ms desde LATAM
• GCP Vertex AI Vision — comparable, mejor latencia desde São Paulo (~150 ms)
• Azure Custom Vision — free tier hasta 5 000 requests/mes

El enfoque cloud-only no lo recomiendo: con caída de internet la operación se detiene. En LATAM eso pasa más seguido de lo que querrías.

#3. Streaming

Los eventos deben llegar a Odoo y a los dashboards en tiempo real.

Stack ligero (3-10 puntos):

• MQTT broker (Eclipse Mosquitto, gratis) — maneja 10k+ msg/seg en una VPS de USD 20
• Telegraf + InfluxDB para agregación de series temporales
• Grafana para dashboards

Stack pesado (50+ puntos, como Dodo):

• Apache Kafka (Confluent Cloud / Redpanda / self-hosted) — delivery garantizado, replay, particionamiento
• Apache Spark Structured Streaming o Apache Flink — para agregación por ventanas
• Delta Lake o Apache Iceberg — almacenamiento a largo plazo de eventos crudos
• Databricks o Snowflake — si necesitas DWH gestionado

Entre Odoo y Kafka: Kafka Connect o un microservicio propio (FastAPI + confluent-kafka).

#4. Superficies de consumo

Los mismos eventos alimentan distintos UIs:

• Tablet en cocina — PWA React/Vue con WebSocket. Muestra: cola actual, pronóstico de ola en 8 minutos, rechazos del CV.
• Alertas Slack / Telegram — webhook vía Odoo Studio o microservicio Flask. Triggers: stock-out, tiempo de cocción excedido, CV rechaza 3 pizzas seguidas.
• App móvil C-level — React Native / Flutter. Agregados de red, top-3 alertas, drill-down al local.
• Dashboard BI — Apache Superset o Metabase conectado a Iceberg/Delta Lake.

Cálculo mínimo de un piloto (3 puntos)

Este es el pricing concreto para PYME LATAM. Las redes grandes invierten entre 3 y 10 veces más.

Cuándo el stack CV funciona — y cuándo no

#1. Red QSR ≥5 puntos con menú homogéneo

Producto estandarizado es la condición central. El modelo distingue «Margarita correcta» de «incorrecta» con 95%+ de precisión sobre 500-1 000 ejemplos etiquetados. Un menú de 200 SKUs requiere un orden de magnitud más de datos y retraining constante.

Caso anónimo: red de hamburgueserías en Lima, 7 puntos, facturación USD 3.5M/año. La verificación CV del armado antes del packaging bajó los refunds vía UberEats / Rappi un 28% en 4 meses. ROI del piloto sobre 2 puntos: 7 meses.

#2. Cloud kitchen / dark kitchen con alto share de delivery

En dark kitchen no hay dine-in, pero sí batching de pedidos. El CV reconoce qué hamburguesa va en qué bolsa (vía stickers con QR), elimina errores de armado. Es crítico en México y Brasil, donde los operadores cloud kitchen (CloudKitchens, Foodology) corren 10-20 marcas virtuales en una misma cocina.

#3. Red con proceso de cocina regulado

Si tienes SOP formalizado — «tiempo de cocción de pizza 8 min ± 30 seg», «cantidad de jamón 80 g ± 5 g» — el CV te da control automático del cumplimiento. La alternativa es una auditoría manual trimestral que se pierde el 95% de las desviaciones.

Funciona con ajustes

#4. Menú muy customizado (sushi à la carte, fine dining)

El CV requiere o retraining constante (caro) o simplificar la arquitectura — por ejemplo, no «plato correcto» sino «peso coincide con el pedido» vía integración de balanzas a través de Odoo IoT. Funciona, pero el efecto es modesto: portion control, no calidad.

#5. Regiones con internet inestable

Si la latencia media es > 100 ms o internet cae > 1% del tiempo — cloud-CV no aplica. Edge inference obligatorio. Sube el CAPEX, pero baja el opex y el riesgo.

No funciona

#6. 1-3 puntos, facturación < USD 500k/año

El TCO de USD 28-32k no se amortiza. Mejor invertir en un Odoo POS limpio sin CV, estandarizar SOPs y capacitar al personal.

#7. Equipo sin bench de data engineering

Los modelos CV no son «set and forget». En 3-6 meses el modelo entra en drift: cambia la iluminación, el proveedor de ingredientes, la mano del pizzero. Sin ciclo MLOps el modelo empieza a dar falsos positivos y el equipo deja de confiarle.

#8. Negocio familiar sin procesos formalizados

Si la receta es «a ojo, como mamá» — la verificación CV es absurda. Primero formaliza el proceso, después automatiza.

5 errores típicos al implementar

#1. Arrancar por el dashboard C-level, no por la tablet de cocina

El equipo de Dodo Pizza lo escribió textual en sus lessons learned: «Primero construimos para el directorio porque ellos firman el contrato. Error. La adopción real despegó cuando rehicimos la tablet de cocina desde cero». Si el operador de cocina no ve valor en la primera semana — el sistema no prende.

Qué hacer: primer MVP = tablet con una sola feature (pronóstico de ola en 8 minutos). El dashboard del COO viene después de que el 80% de los pizzeros usa la tablet a diario.

#2. Cloud-only CV sin edge fallback

Cuando se cae internet la operación se frena. En LATAM el uptime promedio del internet comercial está entre 99.5% y 99.8%. Con 100 puntos eso significa que 1-3 puntos al día tienen problemas.

Qué hacer: edge inference + enriquecimiento cloud asíncrono. Cola local Mosquitto + persistent storage para el caso de corte.

#3. Ahorrar en el etiquetado de datos

Etiquetado barato (equipo interno sin preparación) da un clasificador de 60-70% de precisión. El pizzero ve que el sistema se equivoca uno de cada tres y deja de creerle en una semana.

Qué hacer: outsource a Scale AI, Labelbox o Sama (desde USD 0.05/imagen). Mínimo 1 000 ejemplos por clase, mejor 3 000-5 000. Inter-annotator agreement ≥ 90%.

#4. «Lanzamos el modelo y nos olvidamos»

A los 3 meses cambia la iluminación, el proveedor, el menú — el modelo entra en drift. La precisión cae de 95% a 75% sin que nadie lo note, porque nadie monitorea.

Qué hacer: ciclo MLOps desde el día uno. Métricas precision / recall en Grafana. Alerta al caer por debajo del threshold. Retraining trimestral o ante un cambio significativo de menú.

#5. Ignorar las particularidades PE vs MX vs BR vs CO

Un modelo entrenado sobre pizzas con queso oaxaca de México no anda en Brasil con mozzarella. La diferencia de color, textura y grosor de masa es crítica.

Qué hacer: o un modelo separado por país, o multi-clase con el locale como feature. Considera diferencias en vajilla, packaging y luz.

Caso: Dodo Pizza en LATAM

Datos públicos sobre el stack tecnológico de Dodo Pizza en LATAM:

Contexto. Red fundada en Syktyvkar, Rusia, en 2011. Para 2026: 1 100+ puntos en 14 países, de los cuales 100+ en LATAM (32 en Perú, 38 en Brasil, 18 en México, 14 en Colombia — según publicaciones de la compañía).

Stack. Dodo IS es la plataforma propia de gestión de la red. Parte de los repositorios están abiertos en GitHub Dodo Pizza. Incluye: POS, CRM, marketing, analytics, inventarios, controles CV. Stack:.NET Core, PostgreSQL, Kafka, ClickHouse, modelos ML sobre PyTorch.

Aplicaciones CV (según charlas técnicas del equipo Dodo en HighLoad++, Saint HighLoad):

1. Control de calidad de la pizza antes del horneado — distribución correcta de toppings, forma.
2. Reconocimiento de bandejas y armado de batches para repartidores.
3. Conteo de clientes en sala para predecir carga de cocina en los próximos 30 minutos.

Resultados declarados por la compañía (según publicaciones técnicas):

• −27% tiempo promedio de cocción vs baseline en 12 meses
• +19 puntos NPS de delivery
• 99.97% uptime del pipeline rolling 12 meses
• Pico de procesamiento: 10 000 eventos/minuto (sábado, 20:00 hora de Lima)

Construimos Dodo IS como un producto, no como un sistema interno. Esa es la razón por la cual podemos abrir el código.

Lo importante para otras redes: Dodo Pizza empezó a invertir en IT como producto cuando tenía 10 puntos. Eso le permitió escalar sin crecimiento lineal del equipo IT. Las redes que postergan esa inversión hasta los 50+ puntos suelen chocar con el techo operativo: ya no se puede crecer sin reescribir los sistemas.

Checklist: ¿está tu red lista para CV?

Si respondes «sí» a 6 o más de los 8 puntos — el piloto CV tiene chances razonables de pagarse:

1. Tengo ≥5 puntos o ≥USD 2M de facturación anual
2. El menú está estandarizado (≤30 SKUs)
3. Hay SOPs formalizados de cocción
4. Estoy dispuesto a invertir USD 25k-USD 60k en un piloto sobre 3 puntos
5. Tengo equipo IT o un partner con experiencia Odoo + Python
6. Estoy dispuesto a rediseñar procesos de cocina para un enfoque data-driven
7. Puedo financiar el ciclo MLOps post-piloto (≥USD 500/mes)
8. Entiendo que el payback es 6-10 meses, no 6 semanas

Descarga el checklist completo (PDF) + plantilla de TDR para piloto →

Conclusión: la ventana se cierra entre 2027 y 2028

Computer vision + Odoo no es bala de plata. Es una herramienta para redes con 5+ puntos, menú estandarizado y disposición real a operar data-driven. Si encajas en el perfil — la ventana para ventaja competitiva en LATAM se cierra en los próximos 12-24 meses. Después de 2027-2028 esto va a ser un requisito basal, igual que las cajas online o la integración con UberEats.

Si estás listo a conversarlo — agenda una llamada de 30 minutos. Sin formularios largos, Calendly directo.

Para profundizar:

• Computer Vision para restaurantes — pillar Tier B con disección técnica extendida
• Odoo POS Restaurant: módulos y configuración — deep dive del stack Odoo
• Odoo en Perú, Odoo en México, Odoo en Colombia, Odoo en Argentina — country pillars
• Implementación de Odoo y auditoría Odoo — pillars de servicio
• Caso Dodo Pizza: arquitectura completa — case study original
• Real-time Kafka pipelines — ángulo Tier B

Preguntas frecuentes