Miguel Paredes tiene dos carnicerías en el área de Chicago. La primera la abrió hace 11 años en Pilsen. La segunda, hace 3 años en Little Village. Sabe que una va mejor que la otra. Pero hasta hace 6 meses, no sabía exactamente cuánto mejor, por qué, ni qué hacer al respecto.
Su proceso para revisar los números era el siguiente: llamar a la encargada de cada tienda los viernes por la tarde, pedirle que le leyera las ventas de la semana, anotarlas en un cuaderno, y comparar. Si la encargada no estaba o estaba ocupada, la llamada se postergaba. Si los datos no cuadraban, había que esperar hasta que el contador enviara los estados de cuenta el mes siguiente.
Miguel tomaba decisiones sobre dos negocios con $1.2M anuales de ingresos combinados basándose en llamadas telefónicas y notas a mano.
Esto no es un caso extremo — es la realidad operativa de la mayoría de pequeños negocios con más de una ubicación en Estados Unidos.
El problema real de operar sin visibilidad cruzada
El peligro de no poder comparar sucursales en tiempo real no es solo incomodidad — es que los problemas escalan en silencio.
En el caso de Miguel, el análisis inicial cuando conectamos los datos reveló tres situaciones que él desconocía:
1. La tienda de Little Village tenía un costo de productos del 48%, vs. 39% en Pilsen. Para una carnicería, esa diferencia es devastadora: 9 puntos de margen bruto desapareciendo sin explicación visible. El origen resultó ser una combinación de merma no controlada y precios de proveedores que no se habían renegociado en 18 meses.
2. El día con mejores ventas era diferente en cada tienda. Pilsen vendía más los sábados; Little Village, los jueves (día de pago en varias plantas industriales cercanas). Miguel enviaba refuerzos de personal los sábados a ambas tiendas — dejando Little Village understaffed el jueves.
3. Tres productos de alto margen se agotaban consistentemente en Little Village los martes. Los clientes preguntaban por ellos y se iban a la competencia. El sistema de reabastecimiento no detectaba el patrón porque nadie lo estaba mirando semanalmente.
Ninguno de estos problemas era catastrófico por sí solo. Juntos, representaban entre $80,000 y $110,000 anuales en ingresos no capturados o márgenes perdidos.
El dashboard de comparación de sucursales en Power BI
La solución fue conectar las dos fuentes de datos que ya existían — el sistema POS (Square) y la contabilidad (QuickBooks) — a Power BI, y construir un dashboard diseñado específicamente para responder las preguntas que Miguel necesitaba responder cada semana.
Fuentes de datos conectadas
- Square POS (API): Ventas por producto, por hora, por día, tickets promedio, métodos de pago — actualizado en tiempo real
- QuickBooks Online (API): Costos de productos, gastos operativos, nómina por ubicación, márgenes netos — actualizado diariamente
- Google Sheets (manual): Inventario de inicio de semana — ingresado por la encargada de cada tienda los lunes
Las 5 vistas del dashboard
Vista 1 — Resumen ejecutivo semanal Una página con los KPIs más importantes de las dos tiendas lado a lado: ventas totales, margen bruto, ticket promedio, y variación vs. la semana anterior. Tarda menos de 60 segundos leer. Miguel la revisa cada lunes en el teléfono antes de las 8 AM.
Vista 2 — Comparación de productos Qué productos venden más en cada tienda, cuáles tienen mejor margen, y cuáles se agotan antes del fin de semana. Esta vista reveló el problema de los martes en Little Village en la primera semana de operación.
Vista 3 — Patrones horarios y de día Visualización de calor (heat map) con las ventas por hora y por día de la semana para cada sucursal. Fue esta vista la que mostró la discrepancia entre el sábado de Pilsen y el jueves de Little Village.
Vista 4 — Costos y márgenes Comparación de costo de productos vendidos (COGS), gasto en nómina como porcentaje de ventas, y margen neto. Esta vista identifica automáticamente cuando el margen de una tienda se desvía más de 2 puntos del promedio histórico — y genera una alerta visual en rojo.
Vista 5 — Proyección del mes Basándose en el ritmo de ventas de las primeras semanas del mes, el dashboard proyecta cómo terminará el mes completo para cada sucursal. Esto le permite a Miguel tomar decisiones sobre compras de inventario antes de que sea demasiado tarde para corregir.
Implementación técnica
Herramientas utilizadas
- Power BI Desktop + Power BI Service: Construcción y publicación del dashboard
- Power Query (dentro de Power BI): Transformación y limpieza de datos antes de visualizar
- Square API: Datos de ventas en tiempo real vía conector nativo de Power BI
- QuickBooks Online API: Datos financieros vía conector nativo de Power BI
- n8n: Automatización del reporte semanal que llega por WhatsApp a Miguel cada lunes
Tiempo de implementación: 2 semanas
Días 1-3 — Conexión de datos y limpieza: El mayor desafío fue que los nombres de productos en Square no coincidían exactamente con los nombres en QuickBooks (uno decía "Bistec de res" y el otro "Carne res bistec"). Power Query resolvió esto con tablas de mapeo que unificaron la nomenclatura.
Días 4-8 — Construcción del dashboard: Se construyeron las 5 vistas y se ajustó la lógica de las alertas. La regla de desviación de 2 puntos en margen requirió calibración: en las primeras pruebas, los picos naturales de fin de mes disparaban falsas alarmas.
Días 9-14 — Validación con datos reales: Miguel revisó el dashboard junto con el contador para validar que los números de Power BI coincidían con los estados de cuenta oficiales. Había una discrepancia en la nómina que resultó ser un problema en cómo QuickBooks categorizaba las horas extras — se corrigió en la fuente.
Resultados a los 90 días
- Margen bruto de Little Village: de 52% a 59% — Los 7 puntos recuperados vienen de renegociar el precio de tres cortes de carne con el proveedor y reducir la merma con un sistema simple de conteo diario
- Ventas de Little Village los jueves: +22% — Al ajustar el personal ese día, pudieron atender la demanda que antes se perdía por filas largas
- Agotamientos de productos de alto margen: reducidos en 80% — Con visibilidad semanal del patrón, ahora el pedido del martes llega antes de que se agote
- Tiempo de Miguel revisando números: de 3 horas/semana (llamadas + cuaderno) a 15 minutos/semana
- Estimación de impacto en ingresos/márgenes en los primeros 90 días: $28,000 adicionales
Lo que aprendimos
1. El primer mes siempre revela una sorpresa.
En todos los proyectos de dashboard para negocios con dos o más ubicaciones, el primer mes de datos reales siempre revela al menos un problema que el dueño no sabía que existía. No porque el dueño sea descuidado — sino porque sin visibilidad sistémica, es imposible ver esos patrones.
2. Los datos deben responder preguntas específicas del dueño.
Un dashboard genérico con 30 gráficas es inútil. Antes de construir nada, pasamos una sesión con Miguel preguntándole: ¿qué tres preguntas necesitas poder responder el lunes por la mañana sin llamar a nadie? Las respuestas a esas preguntas son las vistas del dashboard.
3. La resistencia no viene del dueño, viene de los encargados.
Las encargadas de cada tienda inicialmente sintieron que el dashboard era una forma de "vigilarlas." Fue clave incluirlas en la presentación del proyecto y mostrarles que el objetivo era darle a Miguel información para tomar mejores decisiones, no crear un sistema de control. Hoy, ambas encargadas revisan el dashboard ellas mismas para anticipar qué les va a preguntar Miguel.
4. El dashboard no reemplaza al contador — cambia el tipo de conversación.
El contador de Miguel dejó de dedicar tiempo a explicarle qué pasó el mes pasado. Ahora esa reunión mensual se enfoca en qué decisiones tomar el mes que viene, porque Miguel ya llega con los números entendidos.
¿Tienes más de una ubicación y tomas decisiones basado en llamadas telefónicas y corazonadas?
Si el lunes por la mañana no puedes ver en 60 segundos cómo está cada sucursal, estás operando con una venda en los ojos. Un dashboard de decisión puede cambiar eso.
Agenda una llamada de 30 minutos y revisamos qué datos ya tienes y cómo conectarlos.