6 casos públicos de datos en retail, con las fuentes a la mano

Cuando alguien evalúa un proyecto de datos en retail, la pregunta que llega es siempre la misma: “¿esto ya lo hizo alguien de mi tamaño?”. Y es una buena pregunta, porque los argumentos de arquitectura suenan igual de convincentes antes y después de fracasar.

Estos son seis casos publicados por los propios proveedores, con la fuente de cada uno al final para que puedas leer el original. Vale la pena decirlo de entrada: son casos de estudio publicados por el vendedor, así que los números que aparecen son los que el vendedor eligió publicar. Aun así son útiles, por dos razones: identifican qué problema estaba antes y qué se hizo, que es la parte que sí se traslada a tu caso.

Al final hay una lectura transversal de los cinco patrones que se repiten.

1. Petco — de un almacén heredado a arquitectura multi-clúster

Contexto declarado: Petco procesa datos de millones de visitantes web mensuales y más de 1,500 tiendas en Estados Unidos, México y Puerto Rico, sobre lo que Snowflake describe como una arquitectura de almacén de datos heredada.

Lo que se hizo: migración a Snowflake aprovechando su arquitectura multi-clúster, y despliegue de Streamlit para que los equipos publiquen aplicaciones sobre los datos.

Números declarados: procesamiento hasta 50 % más rápido en cargas de ventas y de datos de marketing (25–50 % según el proceso), 20 % más de productividad en los equipos de ciencia de datos, y compartición de datos diez veces más rápida.

Lo interesante no es el porcentaje. Es que Petco reorganizó su equipo de ingeniería de datos en cinco “torres” discretas. La reestructuración organizacional aparece junto a la migración técnica — un recordatorio de que las plataformas no se adoptan solas.

2. KFC Australia — cuando el reporte simplemente no termina

Contexto declarado: más de 700 restaurantes en Australia, 500 mil transacciones de pedido diarias. El problema, tal como lo describe el caso, es específico y reconocible: el reporte de ventas por canal y por día nunca terminaba de ejecutarse en la base de datos SQL anterior.

Lo que se hizo: migración a Snowflake iniciada en mayo de 2019, empezando por una prueba de concepto.

Números declarados: 70 % menos costos operativos de base de datos; reportes que tomaban “horas o incluso días” generados en 20 segundos; más de 10,000 extracciones y reportes diarios soportados; y los procesos de compartición de datos pasaron de días a segundos.

El dato que más dice: las partes con las que comparten datos pasaron de 3 a más de 30. Cuando compartir deja de costar, se comparte con más gente — y eso cambia quién puede decidir con datos.

3. DOUGLAS — 200 fuentes en una plataforma de belleza con 2,000 tiendas

Contexto declarado: DOUGLAS opera tiendas en línea, un marketplace de belleza y más de 2,000 tiendas físicas en Europa. Antes: sistemas de recolección dispersos, hojas de cálculo y captura manual — un enfoque que el caso describe explícitamente como no escalable.

Lo que se hizo: más de 200 fuentes centralizadas con alrededor de 200 conectores de Fivetran, hacia Snowflake, con Tableau para analítica.

Números declarados: 30 % del tiempo que antes se iba en construir y mantener pipelines, ahorrado; 99.9 % de disponibilidad en los más de 200 conectores; y un ahorro equivalente a 2–3 empleados de tiempo completo.

Por qué este caso importa más que los demás para retail mexicano: 200 fuentes es el orden de magnitud real de un retailer omnicanal, y es exactamente el punto donde mantener conectores propios deja de ser viable. Lo desarrollamos en omnicanalidad en retail.

4. Saks — el costo de los pipelines hechos a mano

Contexto declarado: pipelines ETL propios, lentos y con mantenimiento constante; integrar una fuente nueva tomaba semanas o meses, con docenas de pipelines sin monitoreo.

Lo que se hizo: ingesta con Fivetran desde Oracle, SQL Server, Salesforce, PostgreSQL, Workday y más de 15 fuentes adicionales, hacia Snowflake, con dbt para las transformaciones.

Números declarados: 35 fuentes en 6 meses; refresco cercano a tiempo real cada 5 minutos; un pipeline configurado en una llamada de 40 minutos contra las semanas que tomaba antes. El caso también afirma que la estructura anterior habría requerido 4–5 veces el equipo actual.

La lección transferible: el ahorro no está en la licencia, está en el número de personas que ya no mantienen plomería. Es el mismo argumento que aplica cuando la fuente es SAP y aparece el desarrollo ABAP a la medida — lo tratamos en cómo llevar datos de SAP a Snowflake.

5. Metro Singapur — el hallazgo de los medios números

Este es el caso más pequeño de la lista y el más instructivo.

Contexto declarado: una cadena de cinco tiendas departamentales en Singapur, con alrededor de 10 años de histórico —compras de cliente, métodos de pago, historia de cadena de suministro— en muchos terabytes y en formatos distintos. El personal recuperaba datos a mano y los capturaba en otro sistema para poder analizarlos: un reporte tardaba semanas.

Lo que se hizo: nueve tableros en Tableau, cubriendo desempeño de ventas, seguimiento de inventario y gestión de la relación con el cliente.

Números declarados: lo que tomaba semanas se redujo a segundos.

Y el hallazgo concreto: el equipo revisó los datos de tallas de calzado y descubrió que los clientes casi no compraban medias tallas. Surtieron más de las tallas populares y redujeron el sobreinventario.

Ese hallazgo vale más que cualquier porcentaje de este artículo, y por una razón: nadie lo estaba buscando. No salió de un modelo predictivo ni de un proyecto de IA. Salió de que alguien pudo mirar el detalle de su propio catálogo sin pedir permiso ni esperar semanas. Es el argumento completo a favor de bajar la analítica al nivel donde se decide — lo mismo que vemos en analítica de ventas por tienda.

6. Caraway y Guitar Center — la capa semántica como cimiento

Dos casos que Omni publica en su página de retail.

Caraway reporta haber crecido 5 veces la adopción de datos en la organización, con reportería de inventario ampliada que ayuda a la gestión de disponibilidad de cara a su temporada alta de ventas.

Guitar Center lo plantea en términos de lo que viene: su VP de Datos señala que la plataforma los prepara para dar el salto a IA porque el modelo semántico está en el centro.

Ese segundo punto es la tesis que más se repite en 2026. Omni describe su propuesta para retail como definir métricas —margen bruto, sell-through, lift promocional, rotación de inventario— una sola vez en la capa semántica y reutilizarlas en tableros, hojas de cálculo y IA. Es la misma conclusión a la que llegamos por otro camino en qué es una capa semántica y por qué la IA la necesita.

Los cinco patrones que se repiten

Leídos juntos, los seis casos coinciden en más de lo que difieren:

1. El punto de partida casi siempre es el mismo: datos dispersos, captura manual y reportes que tardan semanas o que no terminan. Ninguno de estos casos empezó desde una arquitectura moderna a la que le faltaba un detalle.

2. La secuencia es idéntica en todos: integrar primero, después modelar y definir, al final visualizar. Ninguno empezó por el tablero.

3. El ahorro que declaran no es de licencia, es de personas. DOUGLAS habla de 2–3 empleados equivalentes; Saks de 4–5 veces el equipo. El costo real de la plomería hecha a mano es el equipo permanente que la mantiene.

4. El número de fuentes es el que decide la arquitectura. DOUGLAS con 200 y Saks con 35 no eligieron conectores gestionados por gusto: los eligieron porque a ese volumen no hay alternativa sostenible.

5. La velocidad importa por lo que habilita, no por sí misma. KFC pasó de 3 a 30 partes compartiendo datos. Petco multiplicó por diez la compartición. El valor no fue el segundo ahorrado — fue la gente que empezó a preguntar.

Cómo leer estos casos sin engañarte

Tres advertencias honestas:

Son casos publicados por el vendedor. Los números están seleccionados y no hay auditoría independiente. Úsalos para entender el tipo de resultado, no para proyectar el tuyo.

El “antes” es la parte más confiable y la más útil. “El reporte nunca terminaba”, “un reporte tardaba semanas”, “captura manual en hojas de cálculo” — eso no es marketing, es diagnóstico, y probablemente reconoces alguno.

Ninguno menciona el costo total ni el tiempo real del proyecto completo. Esa conversación hay que tenerla aparte, y las preguntas que la ordenan están en 8 preguntas antes de comprometer presupuesto.

---

En EGOS BI el 60 % de nuestro trabajo es con retail, y trabajamos con las mismas piezas de estos casos: Fivetran y Theobald para ingesta, Snowflake como repositorio, Tableau u Omni para la analítica. Si quieres ver cómo aplica a tu red de tiendas, agenda un diagnóstico — o revisa cómo trabajamos con datos en retail.

Fuentes: Snowflake — Petco · Snowflake — KFC Australia · Fivetran — DOUGLAS · Fivetran — Saks · Tableau — Metro · Omni — Retail