La tecnología resuelve, tarde o temprano, los problemas correctamente planteados. No me estoy refiriendo a algo que no conozca: la logística de almacenes.
Desde que empecé a trabajar en esto asumí una forma de hacer el picking que era normal, la que usaban y usan todos los WMS (Warehouse Management System).
- Yo le comunico al preparador a donde tiene que ir (hueco) y qué cantidad coger. Cuando el preparador lee la ubicación que yo le he dicho, con el lector de código de barras, sabemos que:
El preparador está enfrente de la ubicación leída.
2. Luego asume que el preparador:
Agarraba la cantidad que le había pedido.
De la ubicación que había leído
He convivido desde siempre con los dos errores que este sistema lleva implícitos:
El operario no agarra la mercancía de la ubicación que lee, sino de otra.
El operario no agarra la cantidad que yo le he dicho, sino otra.
Aunque el primer error se produce de pascuas a ramos (si se produce a menudo estamos ante un comportamiento deshonesto adrede), el segundo sí se produce a menudo y puede imputarse a un error, debido a la rutina y a lo pesado que es hacer picking. Un buen preparador fallará cuando la secuencia sea agarra 1, agarra 1, agarra 1, agarra 1, agarra 2… y preparará menos cantidad de la que dice el pedido.
Hemos intentado resolver estos problemas con controles de peso, pero la fiabilidad que da este control está lejos de ser la solución.
Además, existe otro problema, esta forma de hacer picking es de rendimiento malo,
a) lo que tarde en llegar al hueco de picking (“taxi”),
b) un segundo para leer la ubicación,
c) el tiempo que tarde en hacer el picking (depende de peso, volumen, cantidad, …).
Los buenos sistemas hacen 100 cajas a la hora y los malos 80 o menos. Pero esto será motivo de otro artículo.
Curiosamente, la tecnología para resolver estos problemas ya existe, pero no se ha aplicado. Hace tiempo (en “los ochenta”) los lectores de código de barras cambiaron de tecnología (direccional a omnidireccional).
En lugar de fijar un punto en el centro del código de barras luego hacer un barrido de izquierda a derecha, desde entonces hacen una “foto” del código de barras y luego es el software el que analiza el grosor de cada barra y devuelve el código leído. (Esta tecnología se ha depurado con el uso de Android, los smartphones son capaces de detectar un código de barras, enfocarlo y leerlo automáticamente. Estamos hartos de hacerlo al leer el código de barras QR de la carta de un restaurante).
Ahora apliquemos esta tecnología al picking. El hueco de picking en Europa es bastante normal que aloje un euro-pallet (80×120 cm):
Imaginemos que el preparador hace una foto del código de barras. El lector devuelve el valor del código de barras y hace una foto que guarda. El siguiente preparador que prepara en ese hueco también hace una foto.
Obviamente sería útil que el sistema fuera como el de ahora, es decir, el sistema ilumina el código de barras. Android podría detectar el código de barras, hacer la foto, guardarla y hacer el típico bip. Todo esto en menos de un segundo.
Dejo para otra ocasión otro enunciado: comparar dos fotos y ver qué cantidad falta entre las dos. Lo que sí es cierto es que las fotos del hueco de picking deben tomarse más o menos desde el mismo sitio. Para ello debemos fijar tres puntos en el espacio y decirle a Android que haga la foto cuando estén los tres en la foto. Las fotos deben ser comparables y analizables por el ojo humano.
¿Qué informático no haría como reto un algoritmo para comparar las dos fotos para decirme que ha cogido 5 cajas, de verdad, sabiendo que la base de la foto es un euro pallet de 80 x 120 cm.
