LA CULPA NO ES DEL SGA ( WMS )

LA CULPA NO ES DEL SGA ( WMS ) *

A lo largo de mi carrera profesional he tenido la oportunidad de ver y trabajar en almacenes de varias empresas. En los almacenes visitados que habían implantado un software de gestión de stocks hacía poco tiempo, me gustaba preguntar a los operarios de almacén que si notaban la diferencia y si trabajaban mejor o peor que antes. En la inmensa mayoría de los casos respondían casi sin dejar de terminar la pregunta, que trabajaban de largo mucho mejor con el SGA ( WMS ) que sin él. Pero, en un pequeño número de ocasiones, el descontento con el software, sin ser exagerado, existía y además se le echaba la culpa de ciertas situaciones de las que el SGA ( WMS ) no era responsable y que ahora expondré.

Todos los que mostraron descontento tenían razón en una cosa y no la tenían en otra. Tenían razón en que el SGA ( WMS ) no conseguía adaptarse a su forma de trabajar. Y NO la tenían en echarle la culpa al software. En este post veremos que el origen de los problemas de un software implantado en un almacén, NO ES EL SOFTWARE. ¿Dónde está entonces?

Veámoslo con dos ejemplos.

1. Primer ejemplo: SGA empresa de recambios

En una ocasión yo era el encargado de elegir un software adecuado para la empresa en la que trabajaba. Insistí al delegado comercial del proveedor de software, en que era imprescindible para mí el poder ver en funcionamiento su software en una compañía real. Se organizó una visita comercial a una pequeña empresa en la que el software estaba recién implantado y en funcionamiento. Nos recibió el jefe de almacén y la primera impresión fue buena. En un momento determinado de la visita le dije al jefe de almacén: seguro que habréis notado la diferencia entre trabajar sin software a trabajar con él, ¿no? Su respuesta no fue la esperada: este SGA es muy lento, si viene un cliente por ventanilla, tardamos más que antes en servir el producto. Eso es imposible le repliqué y en lugar de rebatirme, sin mediar palabra, el jefe de almacén que era un hombre tranquilo y de gran templanza me dedicó media sonrisa y me hizo una demostración.

Cuál fue mi sorpresa cuando al tratar de servir un producto que se había solicitado por un pedido real que debía salir por ventanilla, el software le obligaba a introducir un número de contenedor que en realidad no estaban usando. Era un almacén de recambios y los productos se servían por unidades en sus cajas originales y se transportaban a mano ya que eran ligeros. El SGA ( WMS ) obligaba para hacer cualquier operación, fuera la que fuese a que el operario introdujera un número de contenedor, que no se repitiera nunca, en una empresa que no usaba contenedores nunca. Además, era un paso obligatorio para cualquier movimiento de almacén (ubicación, traslado, entrada, expedición, reubicación) que no se podía cambiar, no era opcional. Cuando le pregunté que por qué habían elegido ese software su respuesta fue: yo no lo elegí y nadie me preguntó antes de elegirlo.

La culpa no es del SGA.

No es que el SGA ( WMS ) sea lento, lo que ocurre es que, en la definición de procesos si la hubo, se obvió el detalle de que en esta empresa no se usan contenedores de ninguna clase. Imaginen lo que era hacer un picking en esas condiciones. Los operarios debían inventarse un número de contenedor ficticio y que no existiera ya, para cada paso que daban. Si el picking era largo, de muchas líneas el problema era menor. Pero para pedidos de una referencia o dos, como los de ventanilla, el proceso era insufriblemente lento. El operario le echaba la culpa al SGA, pero el SGA funcionaba a las mil maravillas, el problema no era el software. El problema fue la elección de éste. Eligieron un software no adecuado a sus necesidades. Este problema trajo otro. En determinadas ocasiones, algunos productos de ventanilla se servían primero y se “fingía” el picking” a posteriori. Ese picking fingido a veces se olvidaba y provocaba descuadres temporales en el stock, lo que ralentizaba más aún algunas operaciones. Luego pude averiguar que la elección del software fue demasiado sencilla, se limitaron a elegir el que les proporcionaba su proveedor de estanterías sin más. El SGA supuso una mejora para la mayoría de los procesos, pero se trata de que lo sea para todos.

2. Segundo ejemplo: SGA empresa fabricante

En otra ocasión una empresa productora me contó que el SGA ( WMS ) no iba bien, que si podía echarle un vistazo. En esta empresa la materia prima entraba y se almacenaba a la espera de ser usada por producción. Para no complicarlo vamos a imaginar que entraban minas de grafito por un lado y barritas de madera perforadas por otro, juntando ambos se producían lápices. Mientras no se produjera nada, el SGA era perfecto, pero en el momento empezaban a producir, se descuadraba los stocks de materia prima y perdía la trazabilidad. Tanto producción como almacén culpaban al software, pero ¿cuál era el verdadero motivo? Que el SGA no podía transformar una mina + una madera en un lápiz de manera que, tanto minas como maderas se daban de baja a mano por la administración de almacén a posteriori, cuando acababa la producción. Luego, producción daba de alta tantos lápices como se hubieran producido. Eso si todo iba bien, por decir algo.

Lo que en realidad terminaba ocurriendo era que almacén daba de baja en la mayoría de las ocasiones, las minas y las maderas. A veces no lo hacía por descuido, prisas, pérdida de la nota de papel que llevaba la orden… De manera que lo que no se daba de baja, figuraba en almacén como existencias que, en realidad, no estaban. De manera que se juntaban dos consecuencias no deseables: una, el stock de minas y maderas nunca cuadraba, no era fiable y a veces, producción planificaba producir un lote de lápices confiando en que disponía de materia prima y a mitad de producción debía parar por falta de existencias. Dos, se perdía completamente la trazabilidad ya que al dar de baja la materia prima, con ella se perdían todos los datos.

El stock de producto final (lápiz) también se descuadraba ya que, con las prisas, a veces sólo se daban de alta los necesarios para que salieran los pedidos y no la totalidad de los producidos.

La culpa no es del SGA.

Pero, aunque todo el mundo se ensañaba contra el software la realidad era que la culpa no era del SGA. Aquí no es que hubieran elegido mal el software por falta de definición de procesos previa, sino que la compañía no había adquirido el módulo de producción del que sí disponía el software, porque simplemente consideró que dar de baja materia prima y de alta producto terminado era cuestión de “un momento” y nadie previno la catastrófica situación que iba a generar en los stocks de materia prima y producto terminado. Téngase en cuenta que aquí he expuesto un único caso con una única referencia sencilla como un lápiz, pero la empresa real trabajaba a dos turnos y manejaba miles de referencias de extraordinaria complejidad productiva con lo que el caos llegó a adquirir dimensiones considerables.

Conclusión

Nadie puede impedir que su personal deje una referencia donde no debe, invente almacenes que no existen, ubicaciones ficticias y otras ocurrencias con el objetivo de suplir las carencias del tipo que sean de un software porque lo que seguro que no van a hacer es parar de trabajar, pero no debemos confundir el mal manejo de un SGA, la mala definición de procesos previa o la negación de medios para adquirir un paquete completo, con un supuesto mal funcionamiento del SGA.

Al SGA lo que es del SGA y al humano lo que es del humano. En mi trayectoria profesional nunca he visto un SGA que no supusiera una mejora notable en la gestión de un almacén que antes no disponía de él, debemos ser honestos y no culpar al SGA de los errores que son propiamente nuestros.