PutAway Put2Light
El ¿Por qué? y el ¿Cómo? de un sistema de PutToLight para PutAway.
TradeOff PutAway — Picking.
En el afán de buscar una mejora en las productividades y los rendimientos, en general, siempre priorizamos el picking o los flujos de salida antes que los flujos de entrada a los FulFillment center. Pocas veces en cambio, nos tomamos el tiempo de entender la relación entre ambos flujos y la real afectación que puede tener uno sobre el otro.
Escenarios:
- Cuando usamos zonas vacías para realizar el PutAway (PA). El operador tiene infinita disponibilidad para ir llenando las estanterías, puede elegir siempre los bins mas ergonómicos y llevar al máximo su productividad. Este efecto no es común, ya que pocas veces disponemos de una parte del site con 100% de disponibilidad.
-Por lo que el escenario más realista seria, zonas semi-llenas donde el operador tiene disponibilidad de realizar el PA, sin embargo tiene diferentes complicaciones a la hora de colocar ítems. Deberá dejar ítems en bins ergonómicamente incomodos o colocar ítems en bins donde ya hay unidades y esto puede entrar en conflicto con reglas del sistema (*). En ambos casos, el operador de putaway vera su productividad afectada.
*Cuando hablamos de reglas de PutAway, nos referimos a trabas sistémicas impuestas para proteger la calidad de la operación (Ejemplo: cantidad de SKUs diferentes en un Bin). Cualquiera sea el tipo de arquitectura de tu WMS, cada vez que intentamos colocar un item en una posición necesitamos generar una petición para preguntar si esa posición esta libre y en algunos casos si es apta para ese item en particular.
Como resumen:
1. PA en zonas poco densas = Aumento de la productividad de PA = Rutas menos densas de picking= Disminución de la productividad de Picking.
2. Aumento productividad de Picking = PA en zonas mas densas = Más fails en pantalla y dificultad para encontrar bin = Disminución de la productividad de PA.
Como comentábamos, en general las soluciones siempre vienen del lado del picking ya que no solo tiene un componente de costo si no que además maneja SLAs menores. Por lo que en general deberíamos apuntar al escenario 2.
Que podemos hacer, de la manera más económica posible, para aumentar la productividad de PA, sin ir en detrimento del Picking. La opción que salta a la vista rápidamente, puede ser generar rutas de PA, así como generamos rutas de Picking. Esto tiene tanto de buena idea como de problemas en su ejecución:
- Con un sistema demasiado básico no podemos tener en cuenta la gran cantidad de variables que necesitamos.
- Por el otro lado si el sistema es demasiado complejo y tiene en cuenta todas las variables, probablemente se vuelva antieconómico tanto en su desarrollo como en su ejecución.
Con todas estas premisas, es que empiezo a desarrollar la idea de un PutToLight (P2T) económico y escalable, que le deje los grados de libertad necesarios a la operación, pero que de alertas tempranas sobre que posiciones son las recomendables para realizar la tarea de PA.
El sistema
Escala:
Para poner en contexto, un FC mediano/Grande puede tener entre 500k y 1M posiciones de estantería. Con 1M de ítems a la semana de Troughput con un ratio IN:OUT de 1:1, hablamos entonces de PA con productividades de 110 ítems por minuto.
Con todo lo anterior, podemos ver que un sistema de luces para 1M de posiciones que necesita actualizarse cada menos de un minuto, no es viable y de serlo no seria economico.
Para empezar a reducir el problema necesitamos entonces agregar el concepto de deslocamento y para eso necesitamos zonas. Digamos que nosotros tenemos nuestro site dividido en pasillos (de estanterías) y estos agrupados en zonas. Para nosotros no perder productividad de picking, necesitamos densidad del 80% (Ejemplo). Queda entonces definido que nuestra operación normal va a trabajar con un heatmap de zonas y enviara a hacer PA a las zonas con menor densidad hasta llegar al threshold marcado.
El tamaño de la zona lo podemos definir de varias maneras:
* Pasillos son abastecidos por la misma fuente o buffer
* Pasillos que pueden ser abastecidos por cada batch de entrada
* Pasillos que pueden ser abastecidos en un determinado tiempo
* Otros…
La elección en este caso es operativa, pero para el caso, dividimos el site en 20 zonas, cada una con 50.000 direcciones.
Nuestro Hardware todavía deberá atender las 1M direcciones, pero la arquitectura que tenemos que armar deberá atender de a 50k direcciones por vez, ya que entendemos que nuestro equipo de PA operaciones trabajara deslocandose.
- Representar el numero 50.000 requiere de 16 bits (2bytes)
- Todavía debemos realizar consultas por las 50.000 posiciones x minuto.
Como ya vimos, no es necesario tener todo el site con información RealTime para hacer el PA, de ahí nace la repregunta:
¿Es necesario mapear todas las direcciones dentro de una zona?
Para este approach, encuentro necesario mapear una primera vez (Cuando se activa la zona) todas las posiciones, con 2 resultados posibles:
- Las direcciones que ya están completas las vamos a dejar en ese estado hasta una próxima consulta total.
- Las direcciones que están disponibles, siguen con mapeo RealTime
Para este ejemplo, el promedio de ocupación cuando llegamos a atender el área es del 60% (Ya que si tenemos zonas que se vacian mas que esto, es preferible comenzar a cerrar zonas y consolidar en otras).
Por lo que de las 50.000 posiciones debemos estar mapeando RealTime 30.000 posiciones.
Para continuar, pensemos en la ergonomía del operador: Las posiciones/bins centrales serán las mas fáciles de alcanzar, por lo que siempre preferiríamos que nuestros operadores realizaran PA en estas y luego hacia los extremos superior e inferior.
¿Por que no, simplemente, mapeamos una de las direcciones del nivel y en caso este ocupado mapeamos la siguiente y así sucesivamente?
Con esto y teniendo en cuenta que hicimos un primer mapeo de todas las posiciones, nuestras consultas pasarían (6 niveles por shelve) de 30.000 posiciones a 5.000 posiciones(+ las reconsultas en caso de nuevas estanterías ocupadas)
Por ultimo debemos definir cada cuanto tiempo deberíamos refrescar todo el sistema de luces y la respuesta tendrá diferentes matices por operación, pero por ejemplo si decimos que cada operador completa un pasillo en 10 minutos (Recomendable tener un operador por pasillo para evitar choques e interrupciones), con tener un refresh total de las 5k direcciones cada 10 minutos cumpliríamos las premisas.
Es conveniente dividir los 5k request en 10 request de 500 posiciones por minuto.
Sistema:
Ahora que tenemos un volumen manejable de Request necesitamos planificar como será nuestro sistema a nivel de Hard y soft.
A nivel de Hard tendremos un Orquestador que atendera todos los request y alojara el GUI para habilitar y deshabilitar zonas segun se requiera. Estos cambios se realizaran en el futuro via APIrest.
Cada modulo de 50k posiciones sera atendido por un master de 16 bits que seran las encargadas de dar la señal de encendido a cada una de las luces (Sistema biestable para mantener estado lógico). Por el otro lado tendremos un sistema de potencia para generar la energía necesaria para el encendido de las mismas.
A nivel Soft, el orchestador manejara un sistema de mapas , donde tendrá asociadas todas las posiciones a cada una de las zonas.
El sistema de niveles por estantería podrá ser parseado de la misma dirección.
Mediante un puerto serial se comunicara con cada uno de las 20 zonas y les pasara en simultaneo el resultado de las request del ultimo minuto.
El master será el encargado de recibir la información y persistirla, reescribiendo los cambios por dirección en caso de ser necesarios.
Conclusiones finales:
El costo de componentes de un sistema así es de aproximadamente 0,1 Usd por posición. Importante ver que no se tuvo en cuenta el desarrollo, pruebas, ajustes comerciales y montaje en planta, que probablemente sean lo que mas eleve el costo del mismo.
Al margen del resultado de lo anterior, la mayoría de los conceptos aqui mostrados se pueden usar para realizar mejoras en la productividad, sin necesidad de equipamiento o inversiones en Ingeniería. La reducción del problema, la conceptualización de lo IN:OUT y la constante repregunta en busca del tradeoff son partes esenciales en la logística competitiva de la coyuntura actual.
Por ultimo, este sistema es realista + realizable, de hecho, con algunas modificaciones y buen diseño del proceso , puede ser adaptado para realizar Pick2Light, sin embargo eso podemos dejarlo para una próxima edición…
