Hay un problema que se repite en casi cualquier cadena de suministro. El cliente pide cuando ya casi se ha quedado sin stock, el proveedor recibe el pedido con poco margen de reacción, y entre medias aparecen roturas de stock o, en el extremo contrario, almacenes llenos de producto que no se mueve. El modelo VMI nace precisamente para romper ese ciclo, cambiando quién decide cuándo y cuánto reponer. En este artículo vemos qué es el VMI, cómo funciona el reparto de responsabilidades entre cliente y proveedor, qué ventajas y qué riesgos trae consigo, cómo se implementa a nivel técnico y en qué sectores es más habitual encontrarlo.
VMI son las siglas de Vendor Managed Inventory, que en español se traduce como inventario gestionado por el proveedor. Es un modelo de gestión de la cadena de suministro en el que es el proveedor, y no el cliente, quien decide cuándo reponer stock y en qué cantidad, a partir de los datos de ventas e inventario que el propio cliente le comparte. El cliente deja de emitir pedidos de compra en el sentido tradicional. En su lugar, da acceso al proveedor a su información de demanda y niveles de stock, y es el proveedor quien planifica la reposición dentro de unos límites mínimos y máximos pactados de antemano.
Esto no significa que el proveedor haga lo que quiera con el inventario del cliente. El acuerdo de VMI fija de entrada qué niveles de stock son aceptables, qué referencias entran en el programa y con qué frecuencia se revisa el desempeño. Lo que cambia es quién toma la decisión operativa de reponer, no quién controla el negocio. Y aunque el término se usa sobre todo para inventario en el almacén del cliente, el mismo mecanismo se aplica igual a un fabricante que gestiona el stock de un distribuidor o a un proveedor que repone directamente en el lineal de un retailer.
El VMI cambia el flujo de información y de decisión respecto a la compra tradicional, pero no elimina la necesidad de acordar reglas claras entre las partes. Para entender el modelo hay que separar dos preguntas distintas. Qué información ve el proveedor, y quién toma la decisión final de reponer con esa información. Estas son las dos piezas que sostienen todo el proceso.
El punto de partida es el acceso del proveedor a los datos que antes solo manejaba el cliente. Esto incluye, como mínimo, las ventas o el consumo real de cada referencia, el nivel de stock actual en cada ubicación, y los umbrales mínimo y máximo pactados para cada producto. En integraciones más maduras también se comparten las previsiones de demanda, promociones planificadas y pedidos ya en tránsito, de forma que el proveedor no reponga a ciegas sobre una demanda que está a punto de cambiar por una campaña o una estacionalidad conocida. Sin este acceso continuo a datos fiables, el modelo VMI simplemente no funciona, el proveedor estaría reponiendo con la misma falta de visibilidad que tenía antes, solo que ahora con la responsabilidad añadida de decidir por el cliente.
Con esos datos en mano, es el proveedor quien decide cuándo lanzar una reposición y en qué cantidad, no el cliente. Pero esa decisión no es libre, se mueve dentro de un rango de stock mínimo y máximo que ambas partes han acordado previamente para cada referencia. Si el nivel de stock cae por debajo del mínimo pactado, el sistema del proveedor genera una propuesta de reposición, y dependiendo del acuerdo, esa propuesta se ejecuta automáticamente o pasa por una validación del cliente antes de convertirse en pedido real. Este último matiz importa, en un VMI totalmente autónomo el proveedor repone sin que el cliente intervenga pedido a pedido, mientras que en versiones más conservadoras el cliente conserva un visto bueno final, aunque ya no sea quien inicia el proceso.
El VMI no beneficia solo a una de las partes, aunque a primera vista parezca que es el proveedor quien asume más trabajo. Cuando el modelo está bien diseñado, ambos lados de la relación salen ganando, aunque de formas distintas. Estas son las ventajas que más pesan a cada lado.
Para el cliente, la ventaja más inmediata es dejar de gestionar manualmente cuándo pedir cada referencia, liberando tiempo del equipo de compras para tareas de mayor valor que lanzar pedidos rutinarios. Al mismo tiempo, al ser el proveedor quien ve la demanda real y ajusta la reposición en consecuencia, el cliente suele reducir tanto las roturas de stock como el exceso de inventario inmovilizado, dos problemas que normalmente van en direcciones opuestas y son difíciles de equilibrar a mano.
Para el proveedor, el VMI aporta algo que normalmente no tiene, visibilidad directa sobre la demanda real del cliente, en lugar de tener que inferirla a partir de los pedidos que van llegando. Esa visibilidad permite planificar la producción y la distribución con más antelación y menos incertidumbre, lo que reduce los picos y valles asociados al efecto látigo, la distorsión que amplifica pequeñas variaciones de demanda real en grandes oscilaciones de pedidos a medida que suben por la cadena de suministro.
El VMI no es un modelo sin fricciones, y buena parte de los proyectos que fracasan lo hacen no por un problema conceptual, sino por no anticipar estos retos antes de arrancar. Conviene tenerlos en cuenta desde el diseño del acuerdo, no descubrirlos ya en marcha.
Ceder la decisión de reposición a un tercero significa, por definición, perder parte del control directo sobre el propio inventario. Si el proveedor no da la talla, ya sea por capacidad, por errores de previsión o por priorizar a otros clientes en momentos de escasez, el cliente puede encontrarse con roturas de stock que antes gestionaba directamente y que ahora dependen de la calidad del trabajo de otra empresa. Este riesgo se mitiga en parte con contratos que fijan niveles de servicio claros, pero nunca desaparece del todo mientras el modelo siga activo.
Todo el modelo VMI depende de que los datos que ve el proveedor reflejen la realidad. Si el sistema del cliente reporta stock con retraso, o si hay diferencias entre el inventario físico y el registrado, el proveedor está tomando decisiones de reposición sobre información equivocada, y el resultado es el mismo problema que el VMI pretendía resolver, solo que ahora es más difícil de detectar porque nadie del lado del cliente está revisando pedido a pedido. Antes de lanzar un VMI conviene auditar la fiabilidad de los datos de inventario, no darla por hecha.
Un punto que hay que negociar explícitamente desde el principio es quién es propietario del stock mientras está en el almacén del cliente y en qué momento pasa a serlo de este, normalmente en el momento del consumo o la venta. Esta variante, más cercana a la consignación, cambia quién asume el riesgo financiero de un producto que no se vende, y confundir un VMI estándar con un modelo de consignación sin dejarlo por escrito es una fuente habitual de conflictos contractuales.
Ceder el control de la reposición a un proveedor externo choca a menudo con la forma de trabajar del equipo de compras, que pasa de decidir pedidos a supervisar un proceso automatizado, algo que no siempre se vive como una mejora sino como una pérdida de protagonismo. Sin una explicación clara de qué gana el equipo con el cambio, y sin un periodo de convivencia entre el modelo antiguo y el nuevo, es habitual que el proyecto encuentre más resistencia interna que técnica.
Pasar de la teoría a un VMI operativo exige resolver un problema muy concreto, cómo hacer llegar al proveedor los datos de ventas e inventario del cliente de forma fiable y con la frecuencia necesaria para que las decisiones de reposición tengan sentido. Esto es, ante todo, un problema de integración de sistemas, no solo de acuerdo comercial.
Como mínimo, el proveedor necesita conocer el stock disponible por referencia y ubicación, y las ventas o consumos del periodo, idealmente actualizados a diario o incluso en tiempo real si el volumen de la operación lo justifica. Una frecuencia de actualización semanal puede ser suficiente para productos de rotación lenta, pero se queda corta para referencias de alta rotación, donde un retraso de varios días en los datos puede traducirse directamente en una rotura de stock que el proveedor no vio venir a tiempo.
El intercambio de datos se resuelve tradicionalmente con EDI, Electronic Data Interchange, un estándar consolidado desde hace décadas en grandes cadenas de suministro, especialmente en retail y automoción, donde ya existe infraestructura EDI para otros documentos como pedidos o facturas. Las integraciones más recientes optan cada vez más por APIs, que suelen ser más rápidas de desplegar y más flexibles para actualizar datos en tiempo real, aunque exigen que ambas partes tengan sistemas con capacidad de exponer o consumir esa API. En la práctica, la elección depende menos de cuál es superior en abstracto y más de con qué tecnología ya trabaja cada parte. Forzar un cambio de EDI a API solo por el proyecto de VMI rara vez compensa el coste si el resto de la relación comercial sigue funcionando por EDI.
La forma más habitual de arrancar un VMI no es aplicarlo a todo el catálogo desde el primer día, sino elegir un grupo reducido de referencias, normalmente las de mayor volumen y previsibilidad, y probar el modelo durante varias semanas antes de escalarlo. Este piloto permite detectar problemas de calidad de datos, ajustar los umbrales mínimo y máximo que en teoría parecían correctos, y ganar confianza entre ambas partes antes de exponer todo el catálogo a un proceso de reposición automatizado. Solo después de validar el piloto tiene sentido extender el modelo a más referencias o a otros almacenes.
El VMI no está igual de extendido en todas las industrias. Funciona mejor cuando hay volumen suficiente para justificar la integración de datos, y cuando la relación entre cliente y proveedor es lo bastante estable como para sostener un acuerdo a medio plazo. Estos son los sectores donde el modelo aparece con más frecuencia.
Estas son las dudas que más surgen al evaluar si el VMI encaja en una operación concreta, más allá de la definición general ya vista.
No necesariamente. En un VMI estándar, el cliente sigue siendo propietario del stock una vez llega a su almacén, lo único que cambia es quién decide cuándo reponerlo. Existe una variante, más cercana a la consignación, en la que el proveedor mantiene la propiedad del inventario hasta que se vende o se consume, pero esto debe pactarse explícitamente, no se asume por defecto en cualquier acuerdo de VMI.
En el VMI, lo que cambia es quién decide la reposición, pero la propiedad del stock suele pasar al cliente en el momento de la entrega, igual que en una compra tradicional. En la consignación, la propiedad del inventario permanece en manos del proveedor hasta que el cliente lo vende o lo consume, y solo entonces se factura. Los dos modelos pueden combinarse en un VMI consignado, pero son decisiones contractuales independientes.
No exactamente. El reaprovisionamiento continuo describe la lógica de reponer stock de forma constante según reglas predefinidas, algo que puede hacer perfectamente el propio cliente con su sistema interno. El VMI es un paso más allá, no solo automatiza cuándo reponer, sino que traslada esa decisión y su ejecución al proveedor, que actúa con su propia visión del negocio y no solo siguiendo una regla fija programada por el cliente.
Como mínimo, un sistema del cliente capaz de compartir datos de stock y ventas de forma periódica, y un sistema del proveedor capaz de recibirlos y generar propuestas de reposición. Esto puede resolverse con EDI, con una API, o incluso con hojas de cálculo compartidas en implementaciones muy pequeñas, aunque este último formato rara vez escala más allá de un piloto con pocas referencias.
No, aunque históricamente ha sido más común entre grandes cadenas de distribución y sus proveedores principales, por ser quienes primero justificaron el coste de la integración. Con herramientas de gestión de inventario y plataformas de datos cada vez más accesibles, empresas medianas también pueden implementar versiones simplificadas de VMI con sus proveedores clave, especialmente si ya comparten visibilidad de inventario a través de un sistema común.