Data Warehouse para una Cadena de Restaurantes: Lo Que Aprendimos Construyendo el de Carl's Jr México
- Retail y eCommerce
- Manufactura y Cadena de Suministro
- SaaS y Tecnología
Resumen
Muy pocas firmas en México han construido de verdad un data warehouse para una cadena de restaurantes a escala de franquicia, y por eso la búsqueda se siente vacía. Nosotros lo hicimos para Grupo AFAL, la franquicia de Carl's Jr con 100+ sucursales en México: operaba sobre Oracle EBS y reportes operativos fragmentados, los directivos no podían ver la cadena de suministro en tiempo real y cada área mantenía su propia versión de los números. Construimos el stack moderno completo desde cero — Oracle EBS migrado a Snowflake, modelos dbt para la transformación gobernada, Tableau para la capa directiva, con pipelines automatizados y marcos de gobernanza en todo el flujo. El resultado publicado: una sola fuente confiable para las 100+ sucursales, con visibilidad de la cadena de suministro en tiempo real para los directivos, y la infraestructura entregada. Esta guía explica qué problema resuelve un warehouse en una cadena multi-sucursal, cómo se ve la arquitectura y qué exigirle a quien lo construya — nos contrates o no.
Conclusión clave — Muy pocas firmas en México han construido de verdad un data warehouse para una cadena de restaurantes a escala de franquicia. Nosotros sí: para Grupo AFAL, la franquicia de Carl’s Jr con 100+ sucursales en México, migramos Oracle EBS a Snowflake, modelamos con dbt y entregamos la capa directiva en Tableau — una sola fuente confiable para las 100+ sucursales, con visibilidad de la cadena de suministro en tiempo real. Esta guía explica qué problema resuelve, cómo se ve la arquitectura y qué exigirle a quien lo construya.
Si estás buscando quién puede construir un data warehouse para tu cadena de restaurantes, probablemente ya notaste algo raro: la búsqueda regresa despachos que hablan de “soluciones de datos para retail” en abstracto, integradores que venden el ERP, y muy poca gente que pueda describir una construcción terminada en una cadena de comida con sucursales reales.
No es que el trabajo no exista. Es que casi nadie lo publica con detalle suficiente para que puedas juzgarlo.
Esta guía es el intento contrario: contarte qué es exactamente el problema de datos de una cadena, cómo se ve la arquitectura que lo resuelve y qué preguntas hacerle a quien te lo quiera construir — usando el único caso que podemos describir con nombre y stack.
¿Quién puede construir un data warehouse para una cadena de restaurantes en México?
La respuesta honesta tiene dos partes.
La primera: muy pocas firmas pueden mostrarte una construcción terminada a escala de franquicia en México. Hay talento de sobra para construir un warehouse; lo escaso es haberlo hecho sobre la mecánica específica de una cadena — decenas o cientos de sucursales, catálogos que no coinciden entre sistemas, inventarios que se cuentan a mano, un ERP corporativo que nunca se diseñó para contestar preguntas de operación.
La segunda: nosotros lo hicimos. Clarivant construyó el stack moderno de datos completo, desde cero, para Grupo AFAL — la franquicia de Carl’s Jr con 100+ sucursales en México. La franquicia operaba sobre Oracle EBS y reportes operativos fragmentados: los directivos no podían ver la cadena de suministro en tiempo real, y cada área mantenía su propia versión de los números. Migramos Oracle EBS a Snowflake, construimos los modelos dbt para la transformación gobernada, entregamos la capa directiva en Tableau, y dejamos pipelines automatizados y marcos de gobernanza en todo el flujo. El resultado: una sola fuente confiable para las 100+ sucursales, con visibilidad de la cadena de suministro en tiempo real para los directivos — infraestructura de datos empresarial donde no existía, construida desde cero y entregada.
Dicho eso, esta guía no es un folleto. Si terminas contratando a alguien más, lo importante es que sepas qué estás comprando. Así que sigue leyendo con la lista de exigencias en la mano — está al final.
¿Qué problema resuelve un data warehouse en una cadena de restaurantes?
El problema no es que falten datos. Es que cada sistema conoce una parte de la verdad y ninguno conoce la verdad completa.
En una cadena típica, la información vive así:
- El punto de venta, sucursal por sucursal: tickets, mezcla de productos, ticket promedio, horas pico, canal (mostrador, auto, repartidor). Sabe qué se vendió. No sabe qué costó.
- El ERP corporativo: compras, cuentas por pagar, nómina, contabilidad. Sabe qué se pagó. No sabe a qué hora ni en qué sucursal se convirtió en venta.
- Inventarios y cadena de suministro: órdenes a proveedores, recepciones, transferencias entre sucursales, mermas, conteos físicos, centro de distribución. Sabe qué se movió. Casi siempre con días de retraso.
- Operación y personal: horarios, checadas, incidencias. Sabe quién estuvo. Rara vez se cruza con la venta que produjo.
Cada área saca su propio reporte de su propio sistema, y todos son correctos por separado. El problema aparece en la junta: tres cifras de venta del mismo mes que no empatan, y media hora gastada en decidir cuál se usa en lugar de decidir qué hacer.
Debajo de ese síntoma hay tres problemas estructurales que un warehouse sí resuelve:
1. No existe una definición única. “Venta” puede incluir o no impuestos, descuentos, cancelaciones, comisiones de agregador. “Sucursal” puede tener tres claves distintas en tres sistemas. “Día” puede cortar a medianoche en un sistema y al cierre de caja en otro — y en una cadena que vende de noche, esa diferencia mueve millones al mes de un día al otro.
2. Nadie puede cruzar fuentes. Sin un lugar común, la pregunta más útil de una cadena — ¿qué sucursales están perdiendo margen y por qué: precio de insumo, merma, mezcla de producto o productividad? — no se puede contestar. Cada pieza de la respuesta está en un sistema distinto.
3. La consolidación es manual, y por eso es lenta y frágil. Alguien exporta, alguien pega, alguien ajusta. El reporte del mes llega cuando ya no sirve para actuar sobre el mes, y depende de una persona que algún día va a renunciar.
Un data warehouse resuelve los tres: un solo lugar donde todas las fuentes aterrizan, se limpian y se modelan bajo definiciones acordadas una vez, con procesos automáticos en lugar de manos.
¿Cómo se ve la arquitectura?
En el caso de Carl’s Jr la construcción tuvo cuatro capas, y esa estructura se repite en casi cualquier cadena:
Ingesta. Pipelines automatizados que traen los datos de cada sistema de origen al warehouse en un calendario fijo, sin que nadie exporte nada. En el caso publicado, el origen que migramos fue Oracle EBS.
Almacenamiento. Snowflake como warehouse: un solo lugar donde todo el histórico vive junto, separado de los sistemas transaccionales para que las consultas pesadas no compitan con la operación de las sucursales.
Transformación gobernada. dbt es donde se definen los números. Cada métrica se escribe una vez, en código, con su linaje visible: puedes seguir cualquier cifra del tablero directivo hasta la tabla de origen que la produjo. Aquí es donde “una sola fuente confiable” deja de ser un eslogan y se vuelve una propiedad verificable del sistema.
Consumo. Tableau como capa directiva: los tableros donde la dirección ve el negocio.
Y cruzando las cuatro capas, dos cosas que no se ven en el diagrama pero deciden si el warehouse sobrevive: pipelines automatizados — el sistema se actualiza solo, no porque alguien se acuerde — y marcos de gobernanza: quién puede ver qué, quién puede cambiar una definición y cómo se sabe que un dato viene mal antes de que llegue a un tablero.
Vale la pena decir lo que el stack no determina. La arquitectura de arriba es una elección buena y probada, no la única posible. Lo que sí es innegociable en cualquier cadena es la forma: ingesta automática, un almacén separado de la operación, transformación en código con linaje, y una capa de consumo que la dirección abra sola.
¿Qué visibilidad obtienes?
En el caso de Carl’s Jr, el resultado publicado es concreto: una sola fuente confiable para las 100+ sucursales, con visibilidad de la cadena de suministro en tiempo real para los directivos.
Vale la pena desarmar por qué esas dos cosas importan tanto en una cadena.
Una sola fuente confiable significa que la cifra de la junta directiva y la cifra del gerente de sucursal salen de la misma definición. Suena administrativo y es operativo: cuando cada área trae su propia versión, las juntas se van en reconciliar y las decisiones se posponen. Cuando hay una sola, la discusión vuelve a ser sobre el negocio.
Visibilidad de la cadena de suministro en tiempo real es la diferencia entre enterarte y reaccionar. En comida, el inventario es perecedero y el margen se define en el insumo: un faltante de un producto de alta rotación en veinte sucursales un viernes no es un dato para el reporte del lunes, es una decisión de hoy. Ver el movimiento mientras ocurre — no una semana después, consolidado a mano — es lo que convierte los datos en operación.
No es casualidad que ese haya sido el eje. El proyecto de Grupo AFAL empezó como una construcción de KPIs de cadena de suministro y creció desde ahí hasta la plataforma completa. Es un buen patrón: empezar por el dolor más caro y dejar que la arquitectura crezca sobre algo que ya demostró valor.
¿Qué exigirle a quien lo construya?
Sin importar a quién contrates, estas son las exigencias que aplican a una cadena en particular:
- Que te describan una construcción terminada. Sistema de origen, stack, número de sucursales, qué quedó entregado. Quien lo haya hecho lo cuenta en cinco minutos; quien no, contesta con “experiencia en el sector retail”.
- Que sepan de qué habla tu operación. Merma, conteo físico, transferencia entre sucursales, día operativo que no corta a medianoche, catálogos que no empatan entre el POS y el ERP. Si tienes que explicar eso desde cero, lo vas a pagar en semanas.
- Que el proyecto cierre con precio y fecha, después de un levantamiento pagado. Nadie serio cotiza una construcción sin haber visto tus sistemas — y una tarifa por hora sin techo pone el riesgo del alcance de tu lado.
- Que el método de validación exista antes de firmar. El peor final de una migración no es que el sistema nuevo falle: es que funcione y dé cifras un poco distintas a las del viejo, y que nadie sepa cuál está bien. Pide el método, y pide un ejemplo real de una diferencia que hayan encontrado.
- Que la plataforma te quede a ti. Código en tu repositorio, datos en tu nube, accesos a tu nombre, documentación en el idioma de tu equipo, pruebas automatizadas que fallen solas cuando un dato viene mal. Lo contrario es una dependencia disfrazada de entrega.
- Que sepas quién va a hacer el trabajo, por nombre. No un organigrama: nombres y porcentaje de dedicación, por escrito en la propuesta.
Las seis están desarrolladas, con ejemplos de cómo suena una respuesta seria y cómo suena una que te está esquivando, en la guía Consultoría de Datos en México: Qué Preguntar Antes de Firmar. Úsala con quien sea.
¿Por dónde empezar?
No con la elección de herramienta. Con el conteo.
Antes de que alguien pueda cotizarte una construcción sin adivinar, hay que saber cuántas fuentes hay, en qué estado están, qué reportes existen hoy y cuáles se usan de verdad, y qué tan consistentes son los catálogos entre sistemas. Ese ejercicio, con alcance y fecha propios, es la Radiografía de Datos: dos a tres semanas dentro de tu stack real que terminan en un inventario, un documento de hallazgos verificable contra tus propias fuentes y una cotización a precio fijo y fecha fija para la construcción.
También es válido el otro camino, el que siguió Grupo AFAL: empezar por un dolor operativo acotado — en su caso, los KPIs de cadena de suministro — y dejar que la plataforma crezca sobre algo que ya demostró valor.
Lo que no funciona es empezar comprando licencias.
Si operas una cadena y te reconociste en el problema, así trabajamos con retail y cadena de suministro, y una llamada de estrategia alcanza para saber si tu caso se parece al que ya construimos. Y si acabas contratando a alguien más, la lista de exigencias de arriba sigue siendo tuya.
Preguntas frecuentes
¿Quién puede construir un data warehouse para una cadena de restaurantes en México?
Muy pocas firmas pueden mostrarte una construcción terminada a escala de franquicia en México, y esa es la respuesta honesta a la pregunta. Clarivant construyó el stack completo de datos para Grupo AFAL — la franquicia de Carl's Jr con 100+ sucursales en México — migrando Oracle EBS a Snowflake, modelando con dbt y entregando la capa directiva en Tableau, con pipelines automatizados y marcos de gobernanza. El resultado fue una sola fuente confiable para las 100+ sucursales con visibilidad de la cadena de suministro en tiempo real. Si estás evaluando proveedores, no preguntes si pueden: pide que te describan una construcción terminada con el sistema de origen, el stack, el número de sucursales y qué quedó entregado. Quien lo haya hecho puede contestarlo en cinco minutos.
¿Qué datos debe integrar un data warehouse de restaurantes?
En una cadena multi-sucursal las fuentes que importan casi siempre son cuatro familias: el punto de venta de cada sucursal (tickets, mezcla de productos, horarios, canal — mostrador, auto, repartidor), el ERP donde viven compras, cuentas por pagar, nómina y contabilidad, la cadena de suministro y los inventarios (órdenes a proveedores, recepciones, mermas, conteos por sucursal, centro de distribución) y los sistemas de personas y operación (horarios, checadas, incidencias). Lo que convierte eso en un warehouse no es copiarlo todo a un mismo lugar: es definir una sola vez qué significa 'venta', 'sucursal', 'producto' y 'día operativo' para que las cuatro familias se puedan cruzar. En el caso publicado de Carl's Jr, el sistema de origen que migramos fue Oracle EBS.
¿Cuánto cuesta un data warehouse para una cadena de restaurantes?
Depende de cuántos sistemas de origen hay que integrar, en qué estado están, cuántas sucursales reportan y qué tan consistentes son sus catálogos — y cualquiera que te dé una cifra antes de haber visto eso está adivinando o ya metió un colchón que vas a pagar. Lo que sí puedes exigir, sin importar a quién contrates, es la secuencia correcta: primero un diagnóstico pagado y de alcance fijo que inventaríe las fuentes y mida la complejidad, y al final de ese diagnóstico una cotización en firme con precio y fecha cerrados para la construcción. Así el riesgo del alcance queda del lado del proveedor y tú llevas al comité un número defendible en lugar de una tarifa por hora sin techo.
¿Necesito un data warehouse si ya tengo un ERP?
El ERP y el warehouse resuelven problemas distintos. El ERP es un sistema transaccional: está diseñado para registrar operaciones bien, no para responder preguntas que cruzan años, sucursales y fuentes. Cuando le pides análisis, pasan dos cosas — las consultas pesadas compiten con la operación, y la mitad de la respuesta no está ahí porque vive en el punto de venta o en un archivo de inventarios. El warehouse toma esos datos, los modela con definiciones únicas y deja el ERP haciendo su trabajo. En el caso de Carl's Jr, la franquicia ya operaba sobre Oracle EBS y aun así los directivos no podían ver la cadena de suministro en tiempo real, y cada área mantenía su propia versión de los números. Esa es exactamente la señal.
¿Cómo empieza un proyecto de data warehouse para una cadena de restaurantes?
Debe empezar contando, no estimando. Un diagnóstico de dos a tres semanas dentro de tus sistemas reales inventaría cada fuente, cada reporte y cada consulta programada, rastrea el linaje hasta el origen y mide la complejidad en lugar de suponerla; termina con un inventario, un documento de hallazgos que tu equipo puede verificar contra sus propias fuentes y una hoja de ruta con cotización a precio fijo y fecha fija. En Clarivant le llamamos la Radiografía de Datos. También es válido empezar por un dolor operativo acotado y crecer desde ahí: el proyecto de Grupo AFAL empezó como una construcción de KPIs de cadena de suministro.