Cómo investigar un descuadre de inventario antes de culpar al sistema

Hace más de veinte años recibí una llamada en la que todavía pienso. Faltaban unos 10.000 dólares en un recuento de inventario, los usuarios informaban de errores y el propietario ya había sacado su conclusión: el sistema que acabábamos de implantar no funcionaba.

Por entonces yo dirigía una delegación regional de implantación, y habíamos ganado un concurso para automatizar diecisiete estaciones de servicio. Las quejas empezaron después de la puesta en marcha, y había desaparecido mucho dinero. Su lectura no era descabellada. El orden de los hechos nos señalaba directamente a nosotros.

Además, era algo personal, como rara vez lo es un contrato. Yo mismo había negociado el acuerdo, y los propietarios habían vinculado el proyecto a mí, no a la empresa que había detrás. En la reunión de cierre me dieron la mano y me dijeron, sin rodeos, que esperaban que yo respondiera por cualquier dinero que el proyecto les hiciera perder. Allí donde yo trabajaba, un apretón de manos así pesaba más o menos lo mismo que una cláusula firmada.

Nuestro primer error fue no mirar la forma de las quejas

Soporte llevaba semanas registrando incidencias. Nadie había hecho la pregunta obvia sobre ese registro: ¿era un mismo defecto que se repetía, varios sin relación entre sí, un problema local de operativa o el mismo hecho comunicado una y otra vez por personas distintas?

Es una trampa clásica en cualquier implantación. El sistema falla sin falta mientras la gente trabaja y se porta de maravilla en cuanto un especialista se pone a su lado. Si nadie interviene, esa distancia se convierte en desconfianza mutua: los usuarios deciden que el software no funciona, el equipo de implantación decide que los usuarios son descuidados y nadie mira las pruebas.

Pregunta qué forma tiene el problema, no lo grande que es

Antes de la reunión con el propietario, le pedí a nuestro equipo algo distinto del total. Cinco preguntas, ninguna ingeniosa:

• Dónde: ¿en cuál de las diecisiete estaciones está la diferencia, y cómo se compara cada una con las demás?
• Cuándo: ¿en qué periodo se acumuló, y empezó antes o después de la puesta en marcha?
• Quién: ¿en qué turnos, y qué personas los cubrían?
• Qué: ¿qué categorías de producto, y qué tienen en común esos productos, física y comercialmente?
• En otros sitios: ¿aparece el mismo patrón en alguna otra ubicación que use la misma versión?

Lo que mostró el desglose

Todos los avisos de error venían de una sola estación, en un solo turno. El descuadre, unos 10.000 dólares acumulados en un mes, tampoco se repartía por igual en el surtido. Estaba en tres categorías: tabaco, licores premium y chocolate. Artículos pequeños, caros y fáciles de sacar de un edificio sin que nadie se dé cuenta.

Llevé los listados impresos a la reunión, porque aquello fue mucho antes de que nadie abriera un desglose en el móvil. Hasta ese momento, el propietario y yo habíamos mirado el mismo total y habíamos leído en él dos situaciones distintas. Él veía una implantación fallida en toda su red. Lo que mostraba la distribución era que, fuera lo que fuera, estaba en una ubicación, en un turno y en un grupo concreto de productos.

La cifra no cambió en esa reunión. Lo que cambió fue qué parte del negocio quedaba implicada y, por tanto, dónde había que dedicar la semana siguiente a buscar.

Una investigación posterior confirmó que las pérdidas venían de una conducta indebida deliberada, no de un error de cálculo. Quiero ser preciso sobre lo que los datos hicieron y no hicieron ahí. No demostraron nada. La prueba salió de documentos, recuentos de stock y conversaciones, que es de donde debe salir. Lo que hizo el desglose fue dirigir la investigación hacia un sitio donde de verdad podía encontrar algo.

Si la explicación fuera cierta, ¿cómo serían los datos?

Esa pregunta es la parte de esta historia que más he usado desde entonces, y no solo con descuadres. Toma la explicación que está sobre la mesa, supón por un momento que es correcta y pregúntate qué patrón tendría que dejar:

• Un error de cálculo de todo el sistema debería aparecer en todas las ubicaciones, turnos, usuarios y categorías, porque la misma lógica funciona en todos ellos. Rara vez se limita a un rincón de la red.
• Un problema de formación o de uso suele seguir a determinadas personas o turnos, y desaparecer en las ubicaciones donde la misma versión funciona con un equipo con experiencia.
• Un error de configuración suele empezar en la fecha en que se cambió algo y detenerse en las ubicaciones donde no se cambió.
• La pérdida por conducta indebida tiende a concentrarse en artículos compactos, valiosos y fáciles de mover, y a menudo en una franja de tiempo estrecha.

Las cifras actuales del retail apuntan en la misma dirección. En la National Retail Security Survey de Estados Unidos, los minoristas atribuyeron el 36 % de su merma al robo externo, el 29 % a sus propios empleados y el 27 % a fallos y errores de procesos y controles¹. Y un recuento que no coincide con el sistema no siempre es una pérdida: cuando unos investigadores contrastaron los registros de stock de una cadena de alimentación del Reino Unido con un recuento físico, el 64,7 % no coincidía².

Nada de esto es un veredicto. Es una forma de decidir por dónde empezar una investigación, que es algo realmente distinto de decidir qué pasó. El valor está en descartar las explicaciones cuyas huellas, sencillamente, no están ahí.

Diez quejas no son diez fallos

La misma disciplina vale para todo lo que señala un sistema. Diez quejas pueden ser un único defecto comunicado diez veces. Una anomalía generada automáticamente puede ser inusual desde el punto de vista estadístico e irrelevante para la operativa, mientras que una desviación pequeña en una categoría sensible merece atención esta misma semana. El volumen no es gravedad, y la desviación típica tampoco.

Por eso desconfío de los sistemas que lanzan alarmas sin ayudar a nadie a valorarlas. Una alerta que dice que una cifra se ha movido deja a quien la lee exactamente donde estábamos el propietario y yo antes de sacar los listados. Por qué los informes tienen que pasar de registrar lo que ocurrió a orientar lo que hay que hacer después es otro argumento, que expuse en De la contabilidad a la navegación; este texto trata de una pregunta más acotada y más práctica: cómo leer una anomalía cuando aparece.

Qué significa esto para las alertas de tu propio sistema

Es la razón por la que marql se construyó para responder con el desglose, no solo con el total. Cuando aparece una diferencia en el stock, el margen o la caja, la siguiente pantalla útil es la distribución: qué ubicaciones, qué periodos, qué turnos, qué categorías y proveedores. Lee los sistemas de TPV, contabilidad y stock que la cadena ya utiliza, con alojamiento en la UE, y la siguiente pregunta es el siguiente mensaje de la misma conversación, no una nueva petición a alguien de finanzas (la fricción de la que escribí en el coste oculto de los informes manuales).

Los límites merecen decirse con la misma claridad que las capacidades. No establece la intención, no sustituye a un recuento de stock y no lleva a cabo una investigación. Lo que hace es poner a un responsable de operaciones o a un responsable financiero ante los mismos listados que yo llevaba a aquella reunión, en minutos y no tras una semana pidiéndolos, con precios desde 200 € al mes.