Un predictor de stock necesita cuatro tablas que ya tienes: y ningún dato de tus clientes.

¿Qué datos necesita un predictor de stock?

Un predictor de stock necesita cuatro conjuntos de datos: las ventas o salidas por producto, sitio y día; el stock de cada producto en cada sitio; las entradas y los pedidos pendientes, con sus fechas; y una ficha de productos y de sitios. Con eso se puede prever la demanda, medir el plazo real de cada proveedor y calcular cuánto mandar a cada sitio. Todo sale del programa de gestión que ya usas o de sus exportaciones a Excel.

Lo que no necesita es saber quién compra. Un predictor trabaja con cantidades por producto, sitio y fecha. Si tu exportación de ventas lleva el nombre o el correo de cada cliente final, se quita antes de cargarla. Más abajo está por qué y qué dice el RGPD.

• Ventas o salidas: fecha, producto, sitio y unidades.
• Stock: unidades de cada producto en cada sitio, en una fecha (o los movimientos que permiten calcularlo).
• Entradas y pedidos pendientes: fecha de pedido, fecha de entrada, proveedor, producto, sitio y unidades.
• Ficha de productos y sitios: unidades por caja, proveedor habitual, alta y baja de cada producto, apertura y cierre de cada sitio.

Ventas o salidas: el dato que más pesa.

La demanda se aprende de las ventas, así que es la tabla que más cuidado merece. Lo ideal es una línea por producto, sitio y día con las unidades vendidas. Si solo tienes facturas, se agregan; si solo tienes totales semanales, también se puede trabajar, aunque se pierde la diferencia entre el lunes y el sábado. Lo que no sirve son totales mensuales: esconden justo la variación que el predictor necesita ver para calcular el stock de seguridad.

Importa qué cuentas como venta. Las devoluciones van aparte, con su fecha, porque restarlas de la venta del día deforma la serie. Los traspasos entre almacenes no son venta, aunque en muchos programas salen en el mismo informe. Y los consumos internos (muestras, material que usa tu taller, producto que se rompe) tampoco: son salidas, pero no demanda de cliente.

Si reponer a tus sitios es mandar desde un almacén central, la «venta» que interesa es la de cada sitio al cliente final, no lo que el almacén mandó al sitio. Prever a partir de los envíos copia los errores de reparto del pasado.

Stock: la foto y los movimientos.

El predictor necesita saber cuánto hay hoy en cada sitio para calcular cuánto mandar, y cuánto había cada día del pasado para saber qué días no se vendió porque no había producto. Lo segundo es lo que casi nunca está a mano. Si tu programa guarda los movimientos (entradas, salidas, traspasos, ajustes), el stock de cada día se reconstruye. Si solo guarda el stock actual, se puede empezar a guardar una foto diaria desde hoy y, para el pasado, estimar los días a cero con las ventas.

La calidad del stock depende de tus recuentos. Si el programa dice 12 y en la estantería hay 4, el predictor calcula bien y pide mal. La guía de inventario cíclico explica cómo mantener el stock del programa cerca del real sin parar el almacén.

Entradas y plazos: lo que el proveedor tarda de verdad.

De cada pedido de compra o traspaso hacen falta la fecha en que se pidió y la fecha en que el producto estuvo disponible para vender. Con esas dos fechas se mide el plazo real de cada proveedor y de cada ruta, y su variación, que es lo que de verdad decide el stock de seguridad. El plazo que figura en la ficha del proveedor suele ser el que prometió cuando se dio de alta.

También hacen falta los pedidos pendientes: lo que ya está pedido y todavía no ha llegado. Sin ellos, el predictor propone pedir otra vez lo que viene de camino. La guía de stock en tránsito trata cómo se cuenta.

¿Cuánto histórico hace falta?

Para productos con venta regular y sin temporada, unos meses de ventas diarias bastan para empezar a prever. Si el negocio tiene temporada, el predictor necesita haber visto al menos un ciclo completo, es decir, un año, y con dos años puede distinguir lo que es temporada de lo que fue un año raro. Más de tres años rara vez ayuda: los productos, los sitios y los clientes ya no son los mismos.

Los productos nuevos no tienen histórico, y ahí el predictor tira de otros parecidos (misma familia, mismo sitio, mismo precio) y marca la previsión como de confianza baja. Lo mismo para un sitio recién abierto. No hace falta esperar a tener años de datos para empezar: hace falta que el programa diga con qué confianza calcula cada cosa.

Si vas a probar un programa con tu histórico, lo más útil es exportar dos años de ventas y movimientos, aunque los primeros meses no se usen para prever: sirven para comprobar si habría acertado en fechas pasadas.

Los problemas de calidad que aparecen siempre.

No hay histórico limpio. En cualquier exportación de un programa de gestión aparecen los mismos problemas, y conviene saberlo antes de empezar para no pensar que tus datos son especialmente malos. Ninguno impide prever, pero todos hay que tratarlos antes de que el predictor aprenda de ellos.

• Días a cero porque no había stock, que parecen días sin demanda y hacen que el producto parezca vender menos de lo que vende.
• Códigos de producto que cambiaron (por un proveedor nuevo, un cambio de formato o una migración de programa) y parten la historia en dos.
• Traspasos entre almacenes registrados como venta y compra.
• Promociones y pedidos excepcionales (el cliente que se llevó el palé entero) sin marcar.
• Ajustes de inventario a fin de año que se registran como una salida enorme en un solo día.
• Unidades mezcladas: el mismo producto vendido por unidad en una tienda y por caja en otra.
• Sitios que cerraron o abrieron a mitad del histórico sin fecha en la ficha.

¿Hacen falta datos personales? No.

Para prever cuánto se va a vender de cada producto en cada sitio no hace falta saber quién lo compra. El Reglamento General de Protección de Datos define los datos personales como toda información sobre una persona física identificada o identificable (artículo 4.1) y exige que los datos sean adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que se tratan (artículo 5.1.c, el principio de minimización). La Agencia Española de Protección de Datos lo resume en tratar solo los datos que sean precisos para cada fin.

En la práctica: la exportación de ventas que se carga en un predictor lleva fecha, producto, sitio y unidades. Si tu programa la saca con nombre, NIF, teléfono o correo del cliente, esas columnas se quitan antes de entregarla. Si vendes a empresas y quieres prever por cliente (porque cada cliente es un sitio al que repones), basta con un código interno de cliente sin más datos, y conviene tener en cuenta que un autónomo es una persona física. Cuándo aplica el RGPD a tu caso concreto lo decide tu responsable de protección de datos o tu asesor; lo que sí podemos decir es que el predictor no necesita esos datos para funcionar.

Lo que ayuda pero no es imprescindible.

Hay datos que mejoran la previsión sin ser necesarios para empezar. Las fechas de promociones y su descuento, para no confundirlas con demanda normal. Los cambios de precio. El calendario de cada sitio: festivos locales, cierres por obras, horario de verano. Las fechas de lanzamiento y retirada de productos. Y en algunos sectores, datos externos como la temperatura en bebidas o el calendario escolar en papelería.

Todo esto se puede añadir después. Lo que no conviene es retrasar el arranque esperando a tenerlo: el predictor empieza con las cuatro tablas y se le añaden datos cuando se ve que un producto falla por algo que esos datos explicarían. Las guías de previsión de demanda y de demanda intermitente explican qué métodos aprovechan qué datos.

Cómo se entregan los datos.

Hay dos maneras. La primera es una exportación: un CSV o un Excel de cada tabla que alguien saca de tu programa de gestión, una vez para la prueba y después con la frecuencia que haga falta (normalmente semanal). La segunda es una conexión directa: un usuario de solo lectura en tu ERP o en tu base de datos desde el que el predictor lee lo que necesita sin que nadie exporte nada. La segunda es la que se usa en el día a día; la primera basta para probar.

En los sistemas que montamos en Arume la conexión es siempre de solo lectura, los datos se guardan en la UE con copias diarias y puedes llevarte la exportación completa cuando quieras. Conectamos con Odoo, Business Central, Sage, Holded, SAP Business One, Shopify, WooCommerce, PrestaShop, Power BI o un Excel. Si quieres saber qué saldría con tus datos, el análisis gratuito de tu stock empieza con una exportación de ventas y stock de los últimos meses.