Libera el capital circulante parado en el exceso de stock.
marql encuentra el stock por encima de la cobertura objetivo por SKU y ubicación, valora el exceso con tus propios datos de coste y lo convierte en un plan con responsable, plazo y fecha de revisión.
Encontrado
2.728 €
capital a precio de coste
- ordenado en €
- calculado desde los datos de origen
- efecto sólo después de medir
Secciones
Se vende. Y aun así sobra stock.
En Maison Marché el agua mineral no es stock muerto: la última venta fue hoy. Pero la cobertura ha llegado a 110 días frente a un colchón objetivo de 7. marql calculó el exceso contra el colchón más el plazo de entrega, valoró a coste el capital inmovilizado en él y puso las opciones sobre la mesa.
- 110
- días de cobertura
- 7
- colchón objetivo
- 2.728 €
- capital a coste
- 35
- días de desviación
De una desviación a un efecto medido.
Señal, diagnóstico, acción de gestión y evaluación del resultado son un solo proceso, sin hueco entre el análisis y lo que alguien hace de verdad.
El exceso de stock se ve antes de que cierre el periodo.
Una pasada diaria por SKU × ubicación encuentra dónde los días de cobertura superan el objetivo y ordena las desviaciones por el capital que retiene cada exceso.
Seguimiento automático · SKU × ubicación
Muestra la causa y las formas de actuar sobre ella.
marql separa el stock muerto de un SKU que se vende pero lleva demasiada cobertura, leyendo el ritmo de venta, el factor meteorológico y la disponibilidad en las demás ubicaciones. Después propone: pausar la reposición, acelerar la venta con una promoción, trasladar entre ubicaciones o cambiar el umbral.
7 factores leídos · aritmética contrastada con los datos
La cantidad recomendada sale de un modelo de inventario.
ShelfSense lee el stock disponible, el consumo medio diario, el plazo de entrega y el colchón objetivo. La IA explica el razonamiento; la cantidad en exceso y el capital que contiene se calculan de forma determinista.
Disponible 4.625,6 · previsión 39,2 unidades/día
Un efecto sólo cuenta después del periodo de control.
Cuando se confirma una acción, marql fija el periodo base y la ventana de medición. El registro de impacto (Impact Ledger) mantiene separados seis estados, «encontrado», «midiendo», «probado», «sin efecto», «no concluyente» y «peor», y congela la facturación contra la que se mide el efecto en el momento en que se compromete la decisión, de modo que el resultado no puede inflarse después.
Línea base · control cuando lo hay · historial de cambios
110 días pueden ser la respuesta correcta.
La aritmética de arriba no está en discusión: 4.076,8 unidades están por encima de la cobertura objetivo y el capital que contienen, valorado a coste, son 2.728 €. Lo que está en discusión es si eso es un error. En al menos cinco situaciones corrientes la cobertura es alta a propósito, y quien actúa sobre la señal de todos modos está deshaciendo una decisión que alguien ya tomó bien.
Acopio de temporada
Se compra la temporada, no la semana. Medir la cobertura contra un objetivo de 7 días a mitad de un acopio para un pico que llega dentro de seis semanas es aritméticamente correcto y operativamente irrelevante: el stock va por delante de la demanda, no por detrás.
El mismo SKU, las mismas semanas del año pasado: si entonces el ritmo de venta era varias veces el actual, la cobertura es un acopio. Si el año pasado se parece a este, no lo es.
Pedido mínimo del proveedor
Cuando el pedido mínimo es un palé y la ubicación vende cuarenta unidades a la semana, el pedido más pequeño que acepta el proveedor ya son once semanas de cobertura. La compra no tiene nada de malo. El objetivo se escribió para SKU que se pueden pedir en la cantidad que de verdad necesitas.
Pedido mínimo dividido entre el consumo medio diario. Si eso solo ya supera el objetivo, ningún pedido que acepte el proveedor puede cumplirlo, y lo que hay que cambiar es el objetivo.
Una compra para asegurar el precio
Una subida confirmada, una promoción del proveedor o la exposición al tipo de cambio pueden hacer que comprar por adelantado salga más barato que comprar para cubrir. El stock no es capital ocioso: es una protección frente al precio, con un rendimiento conocido y una fecha.
Ahorro por unidad frente a coste de mantenimiento por unidad durante el tiempo que se guarda. Y si la decisión está escrita en algún sitio aparte de la memoria del comprador: una protección sin registrar no se distingue de un pedido excesivo.
Acopio previo a una promoción cerrada
La cobertura antes de una campaña con fecha, mecánica y previsión no es exceso. Es la campaña. La alerta llega pronto, no está equivocada.
Una promoción en el calendario cuya previsión consume la cobertura, y un responsable con nombre para el remanente si no se vende entero.
Cobertura deliberada frente al riesgo de suministro
Un SKU de proveedor único, un retraso en aduanas, un proveedor que ya ha fallado dos veces: llevar semanas de más es comprar disponibilidad, y una rotura en un básico suele costar más que tenerlo guardado.
Si el plazo de entrega que figura en el sistema es el contratado o el observado de verdad. Un objetivo fijado contra un contrato que nadie cumple marcará la prudencia como despilfarro todas las semanas.
En resumen
Ninguna de estas hace reaparecer el dinero: el capital está realmente inmovilizado en las cinco, y conviene saberlo. Lo que cambia es que la respuesta pasa a ser «mantenerlo, y éste es el motivo» en lugar de «liberarlo». marql sólo puede reconocer el motivo cuando el motivo está en los datos: un calendario de promociones, una cantidad de pedido, un plazo de entrega observado. Cuando no lo está, el SKU se marca y el comprador lo anula, y esa anulación es el registro útil.
La señal era correcta. La decisión falló igual.
Cinco formas de que una decisión sobre exceso de stock salga mal una vez que la desviación es real, en el orden en que ocurren: la causa mal leída, el destino equivocado, el precio equivocado, el arreglo equivocado y la contabilidad equivocada. Son escenarios construidos, no observados: detrás no hay cifras de ninguna cadena.
La misma acción para el stock muerto y para un SKU que rota
Dos filas están una al lado de la otra en la misma lista, las dos por encima de 100 días de cobertura. Una no ha vendido ni una unidad en seis semanas. La otra vendió esta mañana. Una rebaja liquida la primera y regala margen en la segunda, que se habría vendido a precio completo: más despacio de lo que querías, pero a precio completo. Pausar la reposición arregla la segunda y no hace nada por la primera, porque no hay nada pedido.
Lee la causa antes de elegir la acción. Fecha de la última venta, ritmo de venta a lo largo de la ventana y si hay algo pedido: tres campos que separan un SKU parado de uno al que le sobra cobertura, y que apuntan a acciones opuestas.
Un traslado a una ubicación que tampoco puede venderlo
El exceso es real y el arreglo parece obvio: llevarlo a una ubicación que tiene el mismo SKU. Pero la ubicación que recibe está en 40 días frente al mismo objetivo de 7; sólo que su error se ve menos. El stock llega, la alerta desaparece en la que envía, y el mismo capital queda inmovilizado una dirección más allá, con el coste del traslado encima.
Un traslado sólo cuenta como arreglo si la cobertura propia de la ubicación que recibe se mantiene dentro de su objetivo después de que llegue el stock. Eso depende de la demanda de esa ubicación, no de la media de la red. Si ninguna ubicación pasa la prueba, esto es un problema de rebaja o de compras, no de distribución.
Una rebaja que cuesta más que mantener el stock
Un descuento lo bastante profundo para liquidar cuatro mil unidades en quince días regala más margen bruto del que costaba mantener el exceso. Hay dos números distintos en juego, el capital que hay en el exceso y lo que cuesta cada semana tenerlo ahí parado, y el descuento tiene que batir al segundo, no al primero. Frente al capital, casi cualquier rebaja parece justificada. Frente al coste de mantenimiento semanal, la mayoría de las rebajas profundas no lo están.
Compara el margen regalado con el coste de mantenimiento durante el tiempo que de otro modo tendrías el stock, más el riesgo de baja si caduca. En un SKU no perecedero sin fecha de caducidad, no hacer nada suele ser la acción más barata disponible.
Subir el umbral en vez de cancelar el pedido
El objetivo es de 7 días, la cobertura es de 110, y la forma más rápida de que la alerta deje de saltar es decidir que el objetivo estaba mal. A veces lo estaba: de eso trata la sección anterior. Pero cuando el objetivo era correcto, moverlo convierte un problema de compras en un problema de informes: el capital sigue exactamente donde estaba, la señal deja de llegar y el siguiente pedido excesivo es invisible.
Un cambio de umbral es un resultado legítimo sólo cuando se argumenta desde la demanda, el plazo de entrega o la cantidad de pedido, y sólo cuando deja constancia de quién lo cambió, desde qué valor y por qué. Si el objetivo se mueve y el pedido de compra abierto no, no se ha arreglado nada.
Apuntar el ahorro antes de que cierre la ventana
Se toma la acción, la cobertura baja y los 2.728 € se anotan como recuperados. Después resulta que la semana en que se movió el stock fue la semana en que un competidor cerró por reformas, o que una ola de calor vendió el agua sin ayuda de nadie. Atribuir eso a la decisión infla el registro, y cada cifra anotada después hereda el error.
El periodo base y la ventana de medición se fijan al confirmar la acción, nunca se eligen una vez conocido el resultado. Al registro de impacto hay que permitirle devolver «sin efecto» y «datos insuficientes»: un registro que sólo dice «probado» no está midiendo nada.
En resumen
Ninguno de los cinco es un fallo de la aritmética: la señal era correcta en todos. Cuatro son una acción equivocada elegida a partir de una cifra correcta, y el quinto es una acción correcta registrada de forma deshonesta. Por eso existen las secciones 3 y 7: una pregunta si la cifra significa lo que parece, la otra dice quién puede actuar sobre ella.
Empieza por la que importa
¿Qué SKU inmovilizan capital circulante sin rotar lo bastante rápido?
- A¿Dónde se concentra el exceso de stock: por SKU, por categoría y por ubicación?
- B¿Es stock muerto, un SKU de baja rotación o un excedente temporal?
- C¿Dónde pausamos la reposición, rebajamos, promocionamos o trasladamos?
- D¿Qué ubicaciones pueden absorber el SKU, dada su demanda y su propio stock?
- E¿Cuánto capital circulante se puede liberar sin aumentar las roturas de stock?
- FPrepara el plan: acción, responsable, plazo y fecha de revisión.
Qué hace falta para valorar el exceso.
Ventas por SKU × ubicación
Cantidad, importe, fecha de la última venta, ubicación y categoría.
Stock disponible + precio de coste
Sin precios de coste se puede seguir contando la cantidad en exceso, pero no se puede valorar el capital inmovilizado en ella, así que la columna de dinero se queda vacía en vez de estimarse.
Plazo de entrega + stock pedido
Proveedor, pedidos de compra abiertos, centro de distribución, vida útil y qué traslados entre ubicaciones son posibles de verdad.
Cómo se calculó
El escaneo, la ventana y la aritmética.
Un escaneo por SKU recorre las filas diarias por producto (ventas, coste, stock) y nombra los SKU exactos que hay detrás del dinero, de modo que cada uno lleva su propia aportación y no una parte de un total.
Filas diarias por SKU en una ventana de 7 a 28 días, según la comprobación. Las comprobaciones de tendencia comparan dos ventanas contiguas de igual longitud.
- unidades en exceso = stock disponible − consumo medio diario × (plazo de entrega + colchón objetivo)
- capital en el exceso = unidades en exceso × coste unitario
- Sincronización TPV / ERP
- product_sales_daily · inventory_daily
- escaneo por SKU
- incidencia
- inventory_daily
- qty_in_stock, cost_value, category_name
- product_sales_daily
- items_count, cost, category_name
Las dos ecuaciones de arriba reproducen exactamente las pantallas. Los días de cobertura no se deducen de ellas: no son el stock disponible dividido entre la previsión impresa al lado, porque una comprobación de desviaciones y un modelo de inventario leen el consumo en ventanas distintas de las mismas filas diarias. Por eso este bloque imprime el modelo y no una sola división, y por eso la cifra que produce es capital valorado a coste, no un gasto. Lo que cuesta cada semana mantener ese capital es otro número, y es el que una rebaja tiene que batir.
Compruébalo con tus propias cifras
Las dos ecuaciones de arriba, con los campos a la vista. Se abre con los datos de este playbook, así que la primera cifra que imprime es la de la cabecera: cambia cualquier campo y la aritmética le sigue.
- Unidades en exceso
- 4.076,8
- Capital en el exceso
- 2.728 €
No calcula los días de cobertura ni lo que cuesta cada semana mantener el stock. Lo primero necesita la ventana de consumo que esta página no ha fijado; lo segundo necesita una tasa de coste de mantenimiento, e inventarse una para que una calculadora parezca completa es justo el tipo de número que este playbook existe para rechazar.
Una acción necesita un nombre. El nombre lo marca el ámbito.
El ciclo termina en una acción con responsable, plazo y fecha de revisión, y el responsable es la parte que esta página antes dejaba en blanco. Cuál es resulta no ser una cuestión de jerarquía. Lo que un rol puede decidir está limitado por lo que ese rol puede ver, y marql trae tres ámbitos que ven cosas distintas: la misma mañana pone un exceso de stock en la cola de decisiones de una persona y no en la de otra.
Encargado de tienda
Sólo sus tiendas, y una fracción de las incidencias abiertas de la red. Es también el único ámbito que recibe percentiles de cohorte: dónde se sitúan el margen y el ticket medio de cada tienda frente a una red anónima de tiendas comparables.
- La realidad sobre el terreno: si el stock está físicamente ahí, si se puede vender y si está en el estado que el sistema cree.
- Ejecutar una rebaja o un tramo de un traslado, una vez fijados la profundidad y el destino.
- Plantear un contracaso: la promoción que nadie registró, el palé que no se podía partir, la entrega que llegó dos veces.
El traslado, la profundidad de la rebaja y el umbral. Cada uno necesita una cifra de fuera de este ámbito, y el caso más claro es el traslado: toda su prueba consiste en cómo queda después la cobertura de la tienda que recibe, y esa tienda no está en esta cola.
Si la cobertura de sus propias tiendas vuelve dentro del objetivo, y si el contracaso que planteó se sostuvo.
Responsable de zona
Un grupo de tiendas, con incidencias que el ámbito de tienda que tiene debajo no puede ver, incluido un exceso de stock en una tienda que no está en la lista de ese encargado.
- El traslado, porque éste es el primer ámbito que ve sus dos extremos.
- La elección entre mover el stock y rebajarlo: la comparación de la que depende el modo de fallo B.
- Qué exceso de tienda es problema de la red y cuál es local.
La compra que creó el exceso, y el propio objetivo cuando se fija de forma central. Una zona puede reequilibrar el stock que ya tiene; no puede deshacer el pedido.
La cobertura en el grupo, y cuánto del exceso se movió en lugar de rebajarse.
Propietario
Toda la red, y sin bloque de cohorte: en este ámbito no queda nada con lo que compararse salvo consigo mismo.
- Pausar la reposición y cancelar lo que está pedido: las únicas acciones que tocan la causa y no el síntoma.
- El umbral, y el registro de quién lo movió, desde qué valor y por qué: el modo de fallo D es lo que pasa sin ese registro.
- La honestidad del registro de impacto: la decisión de no apuntar un ahorro antes de que cierre la ventana de control.
Lo que este ámbito intenta tomar más a menudo de todos modos: el juicio sobre si un palé concreto en una trastienda concreta se puede vender. Es el único dato que tiene el ámbito más pequeño y no tiene el más grande.
Capital circulante liberado en toda la red, y si el mismo SKU vuelve el trimestre siguiente.
En resumen
Éstos son los tres ámbitos que trae el producto, no una afirmación sobre cómo debería organizarse una cadena. Una cadena con un departamento de compras tiene un puesto que ninguno de los tres describe (un comprador de categoría es dueño del pedido como no lo es ningún rol de tienda), y este playbook no se lo va a inventar. Mapea tus propios títulos sobre los ámbitos y no al revés: el ámbito es lo que limita la decisión, y un título que no puede ver la tienda que recibe no es dueño del traslado, se llame como se llame.
Todo lo anterior, en una hoja de cálculo.
Nada de esto necesita marql. El escaneo, la clasificación y el registro son lo que automatiza el producto; el método de debajo son cuatro decisiones y unas dos docenas de campos, y funciona en papel. Quédatelo. Si lo haces a mano durante un trimestre y la aritmética sigue compensando la tarde que cuesta, ahí está el argumento para automatizarla; y si no, habrás gastado una tarde y no una suscripción.
¿Está muerto o sólo le sobra cobertura?
El modo de fallo A es una sola acción aplicada a dos problemas distintos. Tres campos los separan: las unidades vendidas en la ventana y la fecha de la última venta, las dos en una exportación de ventas, y lo que haya pedido, que está en los pedidos de compra abiertos.
¿Cuándo se vendió este SKU por última vez en esta ubicación?
- Hace más que el plazo de entrega
- Trátalo como stock muerto. La reposición no es la palanca: no queda nada que pausar. Ve a la parte C y compara una rebaja con darlo de baja.
- Hace poco, a ritmo constante
- Le sobra cobertura, no está muerto. Continúa.
¿Queda algo pedido o en tránsito?
- Sí
- Ésa es la causa. Cancélalo o páusalo antes que nada: cualquier otra acción trata el síntoma, y la siguiente entrega la deshace.
- No
- El exceso ya está en el estante. Continúa.
¿Se aplica alguno de los contracasos de la sección 3: un acopio, una cantidad de pedido, un precio asegurado, una promoción cerrada, un riesgo de suministro?
- Sí
- Anota cuál, quién lo decidió y cuándo debe revisarse. No hagas nada. Ese registro es lo que evita que esto llegue como sorpresa cada semana.
- No
- Continúa.
¿Hay alguna ubicación cuya propia cobertura siga dentro de su objetivo después de recibir el exceso?
- Sí
- Traslada. Comprueba la cobertura de la ubicación que recibe después del movimiento, no la media de la red: ése es el modo de fallo B.
- No
- La distribución no va a arreglar esto. Ve a la parte C.
Uno de cinco finales: cancelar el pedido, trasladar, rebajar, dar de baja, o anotar un motivo y no hacer nada.
¿Se puede cumplir el objetivo siquiera?
El contracaso del pedido mínimo de la sección 3, en forma de hoja. Una fila por clase de SKU, no por SKU: la respuesta es la misma para todo lo que compras por palés.
- Consumo medio diario
- Unidades al día en una ventana de la que te fíes. Apunta la ventana al lado: sin ella el número no significa nada.
- Plazo de entrega
- El observado, no el contratado. Si los tres últimos repartos llegaron tarde, el observado es el real.
- Colchón objetivo
- Días de cobertura que quieres por encima del plazo de entrega. Esto más el plazo de entrega es contra lo que se mide el exceso.
- Pedido mínimo
- La cantidad más pequeña que el proveedor acepta de verdad, en las mismas unidades que el consumo.
- Pedido mínimo ÷ consumo medio diario
- Días de cobertura que ya crea el pedido más pequeño permitido, antes de que nadie haya pedido de más.
- ¿Se puede alcanzar el objetivo?
- Compara la línea anterior con el plazo de entrega más el colchón. Si es mayor, ningún pedido que acepte el proveedor puede cumplir el objetivo, y lo que tiene que cambiar es el objetivo, no el comprador.
O un objetivo que puedes exigir a alguien, o un objetivo que ahora sabes inalcanzable y que debería dejar de lanzar alertas.
¿Sale más barato rebajar que mantener?
El modo de fallo C en forma de hoja: la comparación que se salta, porque frente al capital cualquier descuento parece justificado.
- Unidades por encima del objetivo
- Stock disponible menos consumo medio diario por (plazo de entrega más colchón), de la parte B.
- Capital en el exceso
- Esas unidades a coste unitario. Éste es el número con el que no hay que comparar el descuento.
- Coste de mantenimiento por semana
- Lo que cuesta cada semana mantener el exceso: capital, almacenaje, seguro, merma. Si no tienes una tasa a mano, apunta la que estás suponiendo y etiquétala como supuesto.
- Semanas que lo tendrías de otro modo
- Al consumo actual, cuánto tarda el exceso en desaparecer por sí solo.
- Coste de mantenimiento en ese horizonte
- Coste semanal por las semanas. Éste es el número que un descuento tiene que batir.
- Margen regalado
- Descuento por unidad por las unidades que esperas mover, a la profundidad que estás considerando.
- Riesgo de baja
- Cero en un SKU no perecedero sin fecha de caducidad. En cualquier perecedero, las unidades que probablemente caduquen, a coste unitario.
Si el margen regalado supera el coste de mantenimiento en el horizonte más el riesgo de baja, no hacer nada es la acción más barata, y vale la pena registrarlo como decisión y no como omisión.
Fija la medición antes de actuar.
El modo de fallo E en forma de hoja, y la única parte con plazo: todos los campos se rellenan antes de la acción, porque una vez conocido el resultado ninguno puede elegirse con honestidad. Las pistas nombran lo que exige el propio registro de marql, de modo que una hoja llevada a este estándar y el producto responden a la misma pregunta.
- La acción, en una frase
- Qué se hace, sobre qué SKU, en qué ubicaciones.
- Responsable
- Un nombre, con un ámbito que pueda ver de verdad lo que la acción necesita: sección 7.
- Línea base, congelada ahora
- La cifra contra la que se medirá el efecto, escrita y no recalculada después. marql la congela en el momento en que se compromete una decisión; en una hoja de cálculo, congelarla significa pegar el valor en vez de dejar una fórmula que se moverá.
- Ventana de medición
- Fechas exactas después de la acción, elegidas ahora y no cuando las cifras empiecen a pintar bien. Las líneas del registro de marql duran unas cuatro semanas: lo bastante para contener ciclos semanales enteros.
- La métrica
- Días de cobertura de este SKU en estas ubicaciones. Una sola métrica: la segunda es la forma de elegir a posteriori el resultado que conviene.
- Controles emparejados
- Ubicaciones comparables que no reciben la acción. marql no da una línea por probada con menos de cuatro tiendas de control emparejadas; sin pares recurre a la volatilidad de la propia unidad, que es una afirmación más débil y debe etiquetarse como tal.
- El listón que supera al ruido
- La prueba de marql es un intervalo de predicción t de Student con α = 0,10 unilateral frente a esos controles. En una hoja de cálculo, el equivalente honesto es un umbral escrito antes de mirar: cualquier cosa decidida después es una preferencia, no un resultado.
- Qué anularía la ventana
- Una promoción que cubra más de la mitad de ella, un cambio de precio, un cambio de proveedor, una rotura de stock o un pico de descuentos. Con cualquiera de ellos el veredicto honesto es no concluyente, no probado.
- Qué cuenta como sin efecto y qué como peor
- Los dos, escritos antes de conocerlos. Un protocolo que no puede salir negativo no está midiendo nada.
Una fila que puede cerrarse en seis direcciones: encontrado, midiendo, probado, sin efecto, no concluyente, peor. Si las tres últimas son inalcanzables en tu versión, las tres primeras no valen la pena.
En resumen
Ése es el método completo. Lo que añade marql no es una ecuación mejor: recorre el escaneo a diario sobre todos los SKU y ubicaciones en lugar del que alguien vio por casualidad, ordena las desviaciones por el capital que contienen para que la tarde se dedique a las mayores, y mantiene el registro para que una fila cerrada no pueda reabrirse en silencio y mejorarse. La aritmética de arriba es la misma en ambos casos.
9 · Donde se detiene la prueba
Potencial liberable
≠ efecto probado.
Los 2.728 € son el capital que hay en el stock por encima del nivel objetivo, valorado a coste. No son lo que cuesta cada semana mantener ese stock, no son un ahorro realizado y no son el ROI de marql.
Un efecto probado se registra sólo después de ejecutar la acción, fijar el periodo base y cerrar la ventana de control. Cuando los datos son insuficientes o un factor externo distorsionó el resultado, el registro de impacto marca el efecto como no probado.
De dónde salen estas pantallas
Las cuatro superficies por las que pasó la decisión
¿Listo para ver
los euros que ha encontrado?
La demo se construye sobre el TPV y la contabilidad que ya usas. Déjanos tus datos y elige una hora.