Margen por tienda y por categoría: el análisis que casi nadie hace
Casi toda cadena de retail mide venta por tienda y muy pocas miden margen por tienda. La diferencia cambia qué tiendas parecen buenas y qué categorías parecen rentables. Por qué es difícil y cómo se construye.
Casi toda cadena de retail mide venta por tienda. Muy pocas miden margen por tienda. Y la diferencia no es un refinamiento contable: cambia qué tiendas parecen buenas, qué categorías parecen rentables y qué promociones parecen haber funcionado.
El caso incómodo es común: la tienda que más vende de la red puede ser una de las menos rentables, porque su venta se concentra en categorías de margen bajo y su costo de operación es alto. Si el tablero solo muestra venta, esa tienda recibe reconocimiento e inventario prioritario — y la que sí genera utilidad pasa desapercibida.
Por qué es más difícil que medir venta
Cuatro razones concretas, y ninguna es de herramienta.
1. El costo del producto no es un solo número. Cambia con el tiempo, con el volumen de compra, con la negociación del proveedor y con el flete. La pregunta “¿qué costó esta pieza?” tiene al menos tres respuestas defendibles: el último costo, el costo promedio, o el costo de la capa específica de inventario que se vendió. Cada una da un margen distinto y hay que elegir una y sostenerla.
2. Los apoyos de proveedor distorsionan todo. Descuentos por volumen, rebates, apoyo promocional, cobro por espacio en anaquel. Son ingresos reales asociados a categorías específicas, y normalmente se liquidan por periodo y a nivel corporativo — no por tienda. Repartirlos requiere una regla explícita, y si no existe, el margen por categoría está sistemáticamente subestimado en las categorías que reciben más apoyo.
3. Los costos de operación de la tienda están en otro lado. Renta, personal, energía, mantenimiento. Viven en el ERP por centro de costo, no por categoría ni por SKU. Bajarlos a nivel de categoría requiere un criterio de asignación —por metro lineal de anaquel, por participación de venta, por horas de personal— y ninguno es objetivamente correcto.
4. La merma se registra tarde. El ajuste de inventario que se hace mensual afecta el margen del periodo en que se registra, no del periodo en que ocurrió. En categorías perecederas esa distorsión es grande.
La decisión que hay que tomar de entrada
Antes de construir nada, hay que decidir hasta dónde bajar. Y la recomendación práctica es que no todo baja al mismo nivel:
| Nivel de margen | Qué incluye | Hasta dónde baja bien |
|---|---|---|
| Margen bruto | Venta menos costo de producto | Tienda, categoría y SKU |
| Margen bruto ajustado | Más apoyos de proveedor y merma | Tienda y categoría |
| Margen de contribución | Más costos directos de tienda | Tienda; por categoría solo con criterio declarado |
| Utilidad por tienda | Más asignación de gastos corporativos | Tienda, con muchas advertencias |
El error que arruina estos proyectos es intentar el último renglón primero. La asignación de gastos corporativos genera discusiones metodológicas interminables antes de que nadie haya visto un solo insight, y el proyecto muere en esas discusiones.
Empieza por margen bruto por tienda y categoría. Es el que se puede construir con datos que ya existen, el que no requiere criterios discutibles, y el que ya cambia decisiones.
Las tres preguntas que se desbloquean
¿Qué categorías sostienen la tienda y cuáles la acompañan? Casi siempre hay una categoría de tráfico —margen bajo, atrae gente— y otras que generan la utilidad. Saber cuál es cuál en cada tienda, no en el promedio de la red, es lo que permite decidir surtido y espacio con criterio.
¿La promoción generó utilidad o solo movió volumen? Es la pregunta que el análisis de venta no puede responder. Una promoción que sube 30 % el volumen y baja el margen unitario a la mitad destruyó valor, y en un tablero de ventas se ve como un éxito.
¿Qué tiendas están mal comparadas? Dos tiendas con venta similar y margen distinto no tienen un problema de desempeño: tienen mezclas de venta distintas. Eso cambia contra qué se les evalúa — y quita conversaciones injustas con los gerentes.
Qué se necesita, y en qué orden
Paso 1 — Costo de producto por SKU y fecha. Del ERP, con el método elegido y documentado. Sin esto no hay margen; con esto ya hay margen bruto.
Paso 2 — Venta a nivel de línea de ticket. No el total del ticket. Es donde falla más de lo que se supone: hay cadenas que solo conservan el encabezado en su histórico analítico, y sin la línea no hay margen por categoría posible.
Paso 3 — Jerarquía de producto limpia. Para que “categoría” signifique lo mismo en todos los sistemas. Es la misma dependencia que aparece en cómo analizar un catálogo de miles de SKU.
Paso 4 — Apoyos de proveedor con regla de asignación escrita. Aquí conviene involucrar a finanzas desde el diseño, no al final. Si el número no cuadra con el estado de resultados, finanzas lo va a rechazar y con razón.
Paso 5 — Costos de tienda por centro de costo. Con el criterio de asignación declarado en el propio tablero, visible para quien lo lee.
Los cinco pasos requieren que ERP, punto de venta y catálogo estén en el mismo lugar consultable — la parte de centralización de datos, que en retail normalmente se resuelve replicando esas fuentes a Snowflake con Fivetran. Si el ERP es SAP, el costo suele vivir en tablas que no se leen con SQL directo, y eso cambia el enfoque de extracción: lo tratamos en por qué extraer datos de SAP es difícil.
Por qué esto tiene que vivir en la capa semántica
De todos los análisis de retail, el margen es el que menos tolera definiciones múltiples.
Si mercadotecnia calcula margen sin merma, operaciones lo calcula sin apoyos de proveedor y finanzas lo calcula completo, las tres cifras son distintas y las tres son defendibles. La junta se va en reconciliar, y la conclusión práctica es que nadie usa ninguna.
Una sola definición de “margen bruto” y “margen de contribución”, declarada una vez y heredada por cualquier consulta, es lo que hace que este análisis se sostenga más de un trimestre. Es el argumento de qué es una capa semántica, y es una de las razones por las que Omni funciona bien en este caso: el margen se define en el modelo y el analista de finanzas conserva SQL para las preguntas que el modelo no anticipó.
La advertencia honesta
Un tablero de margen que no cuadra contra el estado de resultados no se va a usar, sin importar qué tan bien esté diseñado.
Por eso el primer entregable de este tipo de proyecto no es el tablero: es la conciliación. Margen bruto del tablero contra margen bruto del cierre contable, con las diferencias explicadas una por una. Es la parte menos vistosa y la que determina si finanzas defiende el proyecto o lo desacredita en la primera junta.
Cuando esa conciliación existe y está documentada, el análisis de margen por tienda deja de ser un ejercicio de BI y se convierte en la cifra con la que se decide surtido, espacio y promoción.
En EGOS BI construimos analítica de rentabilidad para retail: integración de ERP y punto de venta en Snowflake, modelado de costo y margen conciliado con finanzas, y visualización con Tableau u Omni. Si hoy mides venta por tienda pero no margen, agenda un diagnóstico — o revisa cómo trabajamos con datos en retail.
Más en Data Analytics
¿Te resultó útil?
Agenda una discovery call de 30 minutos para hablar de cómo aplicar esto en tu organización.
Agenda discovery call
¿Qué tan AI-ready
está tu data hoy?
Agenda una sesión de 30 minutos con uno de nuestros consultores senior. Salimos con un diagnóstico inicial y un siguiente paso claro.