Cómo elegir software de optimización de inventario (y cómo probarlo antes de firmar)

¿Necesita realmente un software de optimización de inventario?

No todas las empresas lo necesitan, y las que compran demasiado pronto pagan dos veces: una por la licencia y otra por el proyecto que se atasca porque la organización no estaba preparada.

La madurez de planificación importa más que el tamaño de la empresa, y tiene tres niveles. En el primero, los pedidos se hacen con hojas de cálculo y experiencia. En el segundo, el ERP hace las cuentas con niveles mín.–máx. o puntos de pedido que alguien fijó una vez y rara vez revisa. En el tercero, una herramienta especializada prevé la demanda por referencia y ubicación, la convierte en propuestas de pedido que respetan formatos de embalaje, cantidades mínimas de pedido y lead times, y deja a las personas la gestión de excepciones. Son los mismos tres escalones por los que pregunta primero la calculadora de ROI de Veritico STOCK, porque la distancia entre dónde está y dónde llegaría determina la mayor parte del beneficio.

Saltarse un nivel rara vez funciona. Una empresa que hoy pide con hojas de cálculo no sacará valor de un motor de previsión el próximo trimestre, porque todavía no existe la disciplina de datos de la que depende ese motor. La compra típica es el paso del nivel dos al tres, y compensa cuando se dan varias cosas a la vez: las combinaciones activas de referencia y ubicación llegan a decenas de miles, una parte relevante de la demanda procede de promociones o estacionalidad, la cola larga de referencias lentas y con demanda intermitente es demasiado grande para una sola regla de reposición, y más de un puñado de personas dedica sus días a crear pedidos a mano. No son umbrales rígidos; son el patrón que vemos allí donde la herramienta se gana lo que cuesta.

Hemos recomendado esperar a clientes potenciales. El motivo no suele ser el software, sino que nadie en la empresa es responsable de los datos maestros o que nadie en la operación confía en los registros de stock. El consejo honesto entonces es arreglar los cimientos y hacer la selección un año después, con muchas más probabilidades de éxito.

Qué revisar en sus propios datos antes de redactar el RFP

Tres cosas deciden si un piloto puede dar un resultado con sentido: la exactitud de sus registros de stock, el estado de sus datos maestros y la calidad de su histórico de demanda. Una herramienta no arregla ninguna de ellas. Solo las convierte más rápido en propuestas de pedido.

La exactitud de los registros de stock va primero, porque todo motor de reposición pide contra el registro, no contra el lineal. El estudio más conocido sobre el problema, de DeHoratius y Raman, examinó cerca de 370 000 registros de inventario en 37 tiendas de un mismo retailer y concluyó que el 65 % no coincidía con el recuento físico. Eso fue en 2008, y los retailers con los que trabajamos hoy están mejor, pero rara vez tanto como creen. Donde una categoría muestra stock negativo en el sistema, o los recuentos cíclicos siguen encontrando stock fantasma, ningún algoritmo mejorará la disponibilidad. Hará lo contrario: el sistema ve un stock que no existe, deja de pedir y la rotura de stock se mantiene hasta que alguien corrige el registro. Por eso una mejor previsión, por sí sola, no acaba con las roturas de stock.

Los datos maestros son la segunda comprobación y, en la mayoría de los proyectos, la parte de trabajo más grande. Lead times en el ERP que dicen siete días cuando las entregas tardan doce. Formatos de seis unidades cuando el proveedor ya envía doce. Cantidades mínimas de pedido negociadas hace años y nunca actualizadas. Cada uno hace que el motor calcule bien sobre un dato erróneo, y el resultado parece un fallo del software cuando es un fallo de datos. Antes del RFP, tome una categoría representativa y contraste estos campos con la realidad. La parte que tenga que corregir le dirá cuánta preparación necesita el piloto.

El histórico de demanda es la tercera. Doce meses es el mínimo para que el modelo vea un ciclo estacional completo; de dieciocho a veinticuatro es mejor, porque deja margen para un periodo de reserva. Más importante que la longitud es lo que le falta al histórico. Las promociones nunca marcadas como tales parecen picos de demanda que el modelo intentará prever. Las semanas con rotura de stock parecen semanas de demanda cero, lo que enseña al modelo que la referencia no se vende. Ambas cosas tienen arreglo, pero hay que encontrarlas antes del piloto, no justificarlas después.

Qué criterios distinguen de verdad a los proveedores y cuáles no

El nombre del algoritmo no distingue a los proveedores. Lo que los distingue es cómo se comporta la herramienta en los extremos de sus datos.

Los criterios que importan aparecen en los casos difíciles. ¿Cómo prevé la herramienta una referencia que se vende dos veces al mes? ¿Cómo separa el incremento promocional de la baseline y qué hace con la caída posterior a la promoción? ¿Trata una semana de rotura de stock como demanda cero o como demanda censurada que hay que estimar? ¿Cuántas propuestas tiene que abrir un planificador, explica la herramienta por qué una propuesta es como es y registra lo que cambió el planificador? ¿Quién es responsable de los datos maestros cuando la herramienta está en marcha y cómo fluyen los cambios entre ella y el ERP? ¿Qué parte del tiempo entre la firma y el primer pedido generado por el sistema es preparación de datos por su parte? ¿Y cómo se comporta el precio cuando abre diez tiendas más?

Los criterios que no importan llenan la mayoría de las presentaciones de los proveedores. «Basado en IA» describe todos los productos del mercado. El número de modelos de la biblioteca no dice nada sobre cómo elige la herramienta entre ellos. Los cuadros de mando son agradables, y agradable no es un criterio cuando tres planificadores usarán la herramienta ocho horas al día. Conviene mencionar la excepción: si la van a usar cuarenta jefes de tienda en lugar de tres planificadores, la usabilidad pasa a ser decisiva, porque la adopción es la restricción. Los criterios tienen que seguir el modelo operativo que usted quiere aplicar, no el que muestra el proveedor. El coste total también debe entrar en la comparación; hemos tratado aparte lo que cuesta de verdad desarrollar frente a comprar, y la licencia rara vez es la partida más grande.

Diseñe el piloto para que pueda fallar

Un piloto que no puede fallar es una demo con su logotipo. El piloto que le dice algo es un backtest sobre su propio histórico, frente a su proceso actual, con los criterios de éxito fijados antes de que nadie vea un resultado.

La mecánica es fácil de describir y fácil de saltarse. Tome de dieciocho a veinticuatro meses de histórico para el alcance del piloto. Separe los últimos tres a seis meses como periodo de reserva que la herramienta nunca ve. Deje que la herramienta genere propuestas de pedido semana a semana durante ese periodo, usando solo los datos que habría tenido en cada momento. Después compare esas propuestas con lo que su empresa pidió realmente esas mismas semanas y con lo que se vendió de verdad. La comparación no es «herramienta frente a una previsión ingenua»; esa prueba la gana siempre la herramienta. Es «herramienta frente a las personas y reglas con las que trabaja hoy», porque esa es la decisión que está tomando.

Fije los KPI antes de que empiece el backtest, por escrito: disponibilidad o nivel de servicio, días de stock o valor del stock, sesgo de la previsión por categoría y la parte de las propuestas que un planificador habría modificado. Los proveedores se ofrecerán a añadir métricas a posteriori. No lo acepte.

Elija un alcance que pueda doler: una categoría de alto volumen con mucha actividad promocional, más una muestra de la cola larga de referencias lentas. No la categoría con los datos más limpios, ni la que sugiere el proveedor. Seis a ocho semanas incluida la preparación de datos es realista. Cuando un piloto se alarga, la causa está casi siempre en los datos, y eso ya es en sí un hallazgo.

Las demos de los proveedores salen mejor que los pilotos porque los datos de una demo no tienen roturas de stock, ni cambios de surtido, ni promociones sin marcar, ni un proveedor que entregó tarde tres semanas en noviembre. Su histórico tiene todo eso. Esa es precisamente la cuestión.

Insistimos en este diseño porque hemos estado al otro lado. Hemos visto backtests sobre datos de clientes que salieron más débiles de lo que suponía el caso de negocio, y la respuesta correcta fue recalcular el caso, reducir el alcance o aplazar, no justificar la diferencia. Un piloto capaz de dar esa respuesta es el único que merece la pena.

Cómo leer los resultados y convertirlos en dinero

Un buen backtest muestra un potencial, no una garantía. La diferencia la marcan cosas que el backtest no puede contener: planificadores que modifican propuestas en la operación real, proveedores que entregan tarde, personal de tienda que confía o no en las cifras.

Hay dos resultados típicos. La herramienta iguala su disponibilidad actual con bastante menos stock, o eleva la disponibilidad con aproximadamente el mismo nivel de stock. Ambos valen dinero por partidas distintas: el primero libera caja del inventario y reduce el coste de mantenimiento; el segundo recupera margen de ventas perdidas por lineales vacíos. La tercera partida son las personas. Si el backtest muestra propuestas que los planificadores rara vez tendrían que tocar, el tiempo que hoy se dedica a crear pedidos pasa a dedicarse a excepciones y proveedores, que es donde los planificadores aportan valor.

Es el momento de introducir sus propias cifras en la calculadora de ROI. Pide cinco datos: segmento, madurez de planificación, facturación anual, valor del inventario y número de personas que trabajan en los pedidos. Devuelve una estimación del beneficio anual, el plazo de amortización, la caja liberada y un desglose de dónde procede el beneficio. Es una estimación, no un caso de negocio, pero en minutos le dice si merece la pena convertir el resultado del backtest en uno.

Como referencia, los resultados publicados de nuestros propios proyectos están en este rango. En Dr.Max, una red de 490 farmacias, la implantación de Veritico STOCK se asocia a un aumento de la facturación del 5 %, una mejora de la disponibilidad del 4 % y dos horas al día ahorradas por farmacia en pedidos. En SIKO, la disponibilidad en el lineal pasó del 97 al 98,5 % mientras el valor del inventario bajaba 1,65 millones de euros en un año. En Košík, la disponibilidad llegó al 97 % mientras las mermas bajaban un 75 %. Son negocios distintos con puntos de partida distintos, y por eso precisamente un backtest sobre sus propios datos vale más que leer los casos de éxito de cualquiera, incluidos los nuestros.

Trampas del contrato y del despliegue que aparecen después de la firma

La mayoría de las disputas tras la firma tratan del alcance, no del software. Tres preguntas resuelven casi todas, y su lugar es el contrato, no la reunión de arranque. ¿Quién limpia los datos maestros y quién los mantiene limpios tras la puesta en marcha? ¿Quién construye y mantiene las integraciones con el ERP y el sistema de almacén, y quién paga cuando se actualiza el ERP? ¿Y qué se lleva usted si se va: histórico de demanda, parámetros ajustados y reglas de excepción, en un formato que otro sistema pueda leer?

Después, contraste dos cifras con su plan de crecimiento. Un precio por referencia o por ubicación parece barato en la firma y crece con cada apertura de tienda; pida la cifra para el doble de su red actual. Una puesta en marcha en ocho semanas solo es posible cuando la preparación de datos queda fuera de esas ocho semanas. Nuestras propias implantaciones de Veritico STOCK duran unos cuatro meses incluida esa preparación, y preferimos decirlo antes que descubrirlo juntos en el tercer mes. Por último, lea qué cubre el acuerdo de nivel de servicio: la disponibilidad del sistema es fácil de garantizar; la calidad de las propuestas es lo que usted está comprando.

No tiene que hacer la selección solo ni fiarse de la palabra del proveedor en nada de esto. Actuamos con frecuencia del lado del cliente en la selección e implantación de sistemas de planificación y suministro, también de sistemas que no son nuestros, y las preguntas anteriores son las que hacemos en nombre del cliente.

Cuándo la respuesta correcta es no comprar

A veces el backtest da un resultado claro, y el resultado es que el software no es su problema.

Tres señales apuntan en esa dirección. Una exactitud de los registros de stock por debajo del nivel en el que puede funcionar cualquier motor, normalmente cuando un recuento de muestra en la categoría piloto muestra una parte grande de registros desviados en más de un embalaje. Datos maestros sin responsable: si hoy nadie responde de los lead times y los formatos de embalaje, la herramienta trabajará con datos obsoletos a los tres meses de la puesta en marcha, y la culpa será del proyecto. Y una tasa de modificaciones que se mantiene alta por motivos que la herramienta no puede ver, como acuerdos informales con proveedores o un proceso de planificación que ocurre en reuniones y nunca llega al sistema. Como regla práctica de nuestros proyectos, cuando los planificadores habrían cambiado aproximadamente un tercio de las propuestas o más, hay que arreglar el proceso antes que la herramienta.

En cada uno de estos casos la herramienta desplaza el problema en lugar de resolverlo. La secuencia mejor es primero el proceso y los datos, y después un segundo piloto unos meses más tarde con el mismo alcance y los mismos KPI, para que los dos resultados se puedan comparar. Las empresas que siguen este camino suelen acabar comprando, y comprando con un caso de negocio que pueden defender.