Menos días de inventarioReducir exceso sin sacrificar disponibilidad.
AVANCES DEL PROGRAMA · MAXIOFERTAS PGC
De los datos de la operación al pedido correcto.
Un ecosistema que conecta la información de Delfín, el pronóstico de demanda, la lógica de abastecimiento de ROTAR y el control físico de inventarios para comprar con más precisión y reducir días de inventario.
01Pronosticar
la demanda
la demanda
02Calcular
la compra
la compra
03Validar
el inventario
el inventario
ECOSISTEMA PGC
DECISIÓN
ABASTECER
con precisión
DatosDelfín
DemandaPronóstico
CompraROTAR
RealidadInventarios
OBJETIVO
Comprar lo necesario · cuando se necesita · con el inventario correcto
Mayor rotaciónConvertir inventario en venta con mayor velocidad.
Menos quiebresAnticipar la necesidad antes de perder la venta.
Más confiabilidadTomar decisiones sobre existencias verificadas.
EL PROCESO COMPLETO
No son programas separados.
Es una sola cadena de decisión.
El proceso empieza con la información transaccional, la convierte en una expectativa de venta, transforma esa expectativa en una necesidad real de compra y finalmente valida físicamente si la existencia con la que decidimos coincide con la realidad de la tienda.
00
FUENTE OPERATIVA
Delfín entrega la materia prima del proceso.
Ventas, productos, existencias, movimientos y demás información operativa son canalizados desde la API para alimentar los módulos sin depender de capturas manuales.
ENTREGADatos confiables
01
MOTOR DE DEMANDA
Pronóstico estima cuánto puede vender cada SKU.
La venta histórica se convierte en una proyección futura específica por tienda, producto y fecha. Es la demanda esperada que después deberá ser cubierta.
RESPONDE¿Cuánto vamos a vender?
02
MOTOR DE ABASTECIMIENTO
ROTAR convierte pronóstico en compra.
El pronóstico por sí solo no es un pedido. ROTAR lo cruza con vestido, inventarios, órdenes pendientes, mercancía en camino, cobertura, proveedor y tiempo de entrega para calcular cuánto hace falta comprar de verdad.
RESPONDE¿Cuánto debemos pedir?
03
CONTROL FÍSICO
Inventarios valida la realidad de la tienda.
Conteos, novedades, reconteos y supervisión permiten confirmar o corregir la existencia física. Esa información vuelve a ROTAR y mejora la siguiente decisión.
RESPONDE¿Lo que tenemos es real?
↺
El ciclo se retroalimenta.
Venta real + inventario validado + comportamiento del proveedor = una decisión de compra cada vez más precisa.
01 PROGRAMA DE PRONÓSTICO
Primero calculamos la demanda futura.
El pronóstico es el punto de partida del abastecimiento. No intenta decidir cuánto comprar: estima cuánto se espera vender en cada tienda y en cada fecha futura.
Ejemplo conceptualDemanda por SKU · Tienda
Histórico Pronóstico
SALIDA PARA ROTAR
JUE18und
VIE24und
SÁB31und
Demanda de cobertura73 und
ROTAR toma únicamente los días que realmente debe cubrir según la recurrencia y el tiempo de entrega del proveedor.
Histórico de ventas
La información se organiza por fecha, tienda y SKU para construir la serie de comportamiento de cada referencia.
Días comparables
Se observan días equivalentes y patrones recurrentes para evitar que un promedio general diluya la realidad de cada jornada.
Serie individual
El mismo producto puede tener comportamientos distintos entre tiendas; por eso la proyección se trabaja a nivel tienda + SKU.
Proyección por fecha
El resultado no es una cifra mensual abstracta. Es una demanda futura utilizable por fecha para alimentar el pedido.
02 ROTAR · MOTOR DE PEDIDO
El pronóstico dice cuánto venderemos.
ROTAR decide cuánto comprar.
Esta es la capa donde el pronóstico se vuelve una decisión operativa. ROTAR toma la demanda futura y la confronta con lo que existe, lo que está por llegar y la forma real en que compra cada proveedor.
LÓGICA CENTRAL
Necesidad de cobertura
DEMANDAPronóstico de los días a cubrir
Lo que esperamos vender antes de la siguiente oportunidad efectiva de abastecimiento.
+
PROTECCIÓNVestido
Inventario mínimo visual/operativo que queremos conservar después de cubrir la demanda.
−
DISPONIBLEExistencia proyectada
Inventario real o teórico + mercancía pendiente de ingresar − consumo esperado hasta la llegada.
=
RESULTADOPedido sugerido
La necesidad neta que realmente debe comprarse.
Pronóstico
Demanda esperada para las fechas que la compra debe cubrir.
Vestido
Reserva objetivo que evita que la exhibición o disponibilidad termine en cero.
Inventario real
Conteo físico validado cuando está disponible para el SKU y la tienda.
Inventario teórico
Existencia calculada desde la información transaccional cuando no existe conteo físico vigente.
Órdenes pendientes
Mercancía solicitada o despachada que todavía no ha ingresado a la existencia disponible.
Avance del día
La venta real del día ayuda a proyectar cuánto inventario quedará al cierre o a la llegada del pedido.
EJEMPLO ILUSTRATIVO
ROTAR no pide el pronóstico completo.
ROTAR no pide el pronóstico completo.
Pide la diferencia que falta.
El ejemplo muestra por qué el pronóstico es una entrada, no el pedido final.
Pronóstico a cubrir73
+ Vestido15
Necesidad objetivo88
− Inventario disponible30
− Orden pendiente por ingresar20
PEDIDO SUGERIDO38 und
LA DIFERENCIA CLAVE
El pedido se construye por marca, vendedor, recurrencia y tiempo de entrega.
ROTAR no trata todos los productos como si se compraran de la misma manera. La frecuencia con la que el vendedor toma pedido y el tiempo que tarda el proveedor en entregar determinan qué fechas deben cubrirse.
Ejemplo de recurrenciaProveedor PGC
LUNToma pedido
MAREntrega
MIÉCubrir
JUENueva toma
VIEEntrega
SÁBOperación
DOMOperación
La cobertura cambia cuando cambia la recurrencia. Un proveedor diario no debe generar el mismo nivel de inventario que uno que visita una vez por semana.
Agrupa las referencias que se negocian o gestionan bajo la misma estructura comercial.
Identifica quién toma el pedido y permite organizar la compra según la gestión real con el proveedor.
Define los días en que existe oportunidad de volver a pedir y evita comprar cobertura innecesaria.
Indica cuándo estará disponible la mercancía y desde qué fecha la compra puede empezar a cubrir demanda.
03 SISTEMA DE INVENTARIOS
Para pedir bien, primero debemos saber qué tenemos de verdad.
El sistema de inventarios convierte el conteo físico en una estructura controlada, trazable y utilizable por el abastecimiento. Su valor no termina en detectar diferencias: mejora directamente la calidad de la compra.
ESTRUCTURA OPERATIVA
Del supermercado al SKU
01TiendaUbicación física
→
02GrupoFamilia comercial
→
03SubgrupoSegmentación operativa
→
04SKUUnidad de control
→
05ABCPrioridad
Novedad
El sistema recibe o genera casos que requieren validación de inventario.
Priorización
La clasificación, tienda, grupo y subgrupo permiten ordenar el trabajo.
Auxiliar móvil
El personal toma la tarea y registra el conteo directamente desde el celular.
Conteo por ubicación
Un SKU puede registrarse en varias ubicaciones y consolidar su cantidad física total.
Supervisión
Se compara el resultado y se revisan diferencias antes de cerrar la novedad.
Reconteo
Cuando existe duda, el caso puede volver a la cola sin perder la trazabilidad previa.
Cierre
Se registra responsable, resultado, fecha y hora para conservar la historia del caso.
Retroalimentación
La existencia validada queda disponible como una mejor referencia para ROTAR.
ANTES DE CONTAR
Inventario teórico
100 undLo que la información transaccional indica que debería existir.
VALIDACIÓN FÍSICA
Diferencia
−38 und
−38 und
DESPUÉS DE CONTAR
Inventario real
62 undLo que realmente fue encontrado y validado en la tienda.
00 DELFÍN · CAPA DE DATOS
Delfín es la fuente.
La API la convierte en información utilizable.
La integración con Delfín permite que los programas consuman información operativa desde una fuente central. La API OData es canalizada mediante un conector que consulta, recorre, normaliza y entrega los datos con la estructura que necesitan los módulos.
01 · ORIGEN
DELFÍN
Sistema transaccional
GET
02 · EXPOSICIÓN
API OData
Entidades y consultas
DATA
03 · CANALIZACIÓN
Conector local
Paginación · lectura · normalización
SKU
04 · CONSUMO
Ecosistema PGC
Pronóstico · ROTAR · Inventarios
Demanda observada
Las entidades de ventas y sus detalles permiten conocer qué se vendió, cuándo, dónde y qué SKU participó.
Existencia teórica
La información de inventario se transforma en una referencia de disponibilidad para la toma de decisiones de compra.
Catálogo y relación
Los productos permiten homologar SKU y descripciones para que todos los módulos hablen el mismo lenguaje.
Contexto operativo
Entradas, salidas y demás movimientos disponibles ayudan a explicar cómo cambia la existencia.
Solo lecturaLas consultas utilizadas para esta integración se plantean como lectura GET.
Canalización localDelfín no necesita quedar expuesto directamente a Internet para alimentar el ecosistema.
NormalizaciónLa información se organiza para relacionar tienda, SKU, fecha y variables operativas.
Una sola verdadLos módulos consumen una estructura común y evitan construir versiones distintas del mismo dato.
EL VALOR DEL ECOSISTEMA
Menos incertidumbre.
Menos inventario innecesario.
Cuando conocemos la demanda esperada, la existencia real, la mercancía pendiente y la próxima oportunidad de compra, dejamos de compensar la incertidumbre con inventario adicional.
DELFÍNInformación
+
PRONÓSTICODemanda
+
ROTARDecisión
+
INVENTARIOSRealidad
=
MAXIOFERTAS PGCAbastecimiento preciso
Bajar días de inventario
Reducir quiebres
Aumentar rotación
Mejorar capital de trabajo
Estandarizar la operación