El proceso de diseñar Fulfillment
Hace ya un poco más de un año que en Mercado Libre nos encontramos con un nuevo desafío: hacer Fulfillment. Particularmente en mi caso la tarea fue diseñar un WMS.
El WMS (Warehouse management system) es el software que se usa para gestionar depósitos. Existen muchos en el mercado, lo más común es comprar uno y usarlo, pero en este caso decidimos construir el nuestro.
La primera vez que fui a una reunión del proyecto, me hablaron de términos que nunca había escuchado en mi vida como: Inbound shipment, Pick-up, Waving, Outbound… ¡Y encima casi todo en portugués! Salí de la reunión con mucha información, ansiedad, mil preguntas y demasiado por hacer, pero sin ningún tipo de idea de ¿por dónde empezar? ¿cómo? ¿empiezo a dibujar? ¿cuándo? NADA.
Decidimos que lo primero que había que hacer era entender a qué nos estábamos enfrentando, eso incluía conocer el lugar en donde iba a vivir nuestro WMS (el depósito), en qué contexto se iba a usar (los procesos) y quiénes eran los usuarios que iban a interactuar con el sistema (los operarios).
Nos pusimos en modo de INVESTIGAR Y APRENDER.
1) Aprender warehousing
Lo primero que hicimos fue ir a conocer operaciones similares para entender cómo funcionan los depósitos y recaudar la mayor cantidad de información posible.
Durante las visitas, hicimos muchas preguntas sobre cómo están organizados los depósitos, con qué procesos operan, cómo se dividen las tareas entre los diferentes sectores, cómo manipulan los productos y qué dispositivos usan. Observamos cómo los operarios (nuestros nuevos usuarios) se desenvuelven usando los dispositivos y los productos a la vez. Preguntamos cómo son sus interfaces (en algunos casos nos dejaron verlas) y tratamos de entender qué tareas hace el operario interactuando con el sistema y cuáles son solamente operacionales.
En esta etapa aprendimos que:
- El warehousing es un universo enorme, hay muchos procesos y diferentes formas de hacer las cosas, por ejemplo, los productos se pueden almacenar por tipo, por vendedor, por valor, por rotación, etc.
- Cada persona se encarga de una tarea específica, por ejemplo, hay un operario que etiqueta los productos, otro que los guarda, otro que arma las cajas, etc.
- Es muy importante prestar atención al tipo de tarea que hace el operario y cómo interactúa con el dispositivo, por ejemplo, si se está moviendo por el depósito para almacenar productos es probable que no se vaya a detener a leer mucho texto en una pantalla.
El siguiente desafío fue entender qué de todo esto que aprendimos necesitábamos nosotros para empezar a operar. Fue ahí cuando empezamos a DEFINIR PROCESOS.
2) Definir procesos logísticos
Esta etapa empezó muy diferente a la anterior. Ya estábamos todos familiarizados con términos de logística y, gracias a haber visitado otros depósitos, sabíamos cuáles eran los flujos básicos que necesitábamos para operar:
- Inbound: ingresar los productos al depósito
- Put away: almacenarlos
- Picking: buscarlos cuando hay una venta
- Packing: armar la caja y despacharlos
Decidimos diseñarlos en ese orden, ya que era el orden natural en que se dan dentro del depósito.
¿Cómo lo hicimos? Tuvimos muchíiiiiisimas reuniones por flujo. En cada reunión participaban personas de UX, de desarrollo y líderes de la operación (gente que hoy en día trabaja en el depósito en el equipo de Mejora continua o lideran procesos).
La dinámica de las reuniones se dio de forma bastante natural: la operación nos contaba una idea general del flujo partiendo de su experiencia en otras operaciones y nosotros (IT) los llenábamos de preguntas:
- ¿El flujo es en desktop o handheld (dispositivo mobile que permite escanear productos)?
- ¿Quién es el operario que va a usar este flujo? ¿Qué rol tiene?
- ¿Qué es lo primero que van hacer? Entra al flujo ¿y…?
- ¿Cuál es el objetivo del flujo? ¿Contar productos? ¿Control de calidad?
- ¿Cuál es el orden de las tareas? ¿Primero cuenta y después etiqueta?
- ¿Qué pasa si el producto está dañado?
De esta forma, fuimos dándole forma a cada proceso y bajandolos a flujos.
Dentro de este proceso, pusimos en práctica un concepto que, a mí por lo menos, me cambió mucho la forma de encarar los problemas: el MVP (Minimum Viable Product). Consiste en entender qué es lo mínimo que necesita el producto para empezar a funcionar. Por ejemplo, los líderes de la operación necesitan reportes donde puedan ver todos los productos que están almacenados en el depósito. ¿Es necesario tener esto el día 1? No. Esto nos permitió enfocarnos en lo indispensable, anotar todo lo que estaba fuera del MVP para poder iterar después del Go Live.
Una vez que tuvimos todos los flujos del MVP definidos desde lo operacional, empezó una de las partes más divertidas: DIBUJAR.
3) Diseñar las pantallas
Primero wireframes
Dibujamos en pantallas de baja fidelidad todas los flujos que definimos en la etapa anterior. Por ejemplo, ¿cómo sería la pantalla para un operario que se encarga de “pickear” los productos? Para respondernos eso, tuvimos que hacernos otra pregunta: ¿cuál es la primer acción que va a hacer ese operario? Probablemente ir a la dirección donde está guardado el producto. ¿Y después qué? Escanearlo y sacarlo de su posición.
Este tipo de relato del “paso a paso” nos sirvió para pensar las pantallas con objetivos claros y sobre todo, guiar al operario con tareas cortas y concretas.
A diferencia de otros usuarios, los operarios reciben una capacitación previa sobre el trabajo que van a realizar y la herramienta que van a usar. Teniendo en cuenta esto, no necesitamos cargar la pantalla de contenido que le explique por qué tiene que contar los productos o etiquetarlos, podemos enfocarnos solamente en decirle cuál es la acción puntual que tiene que hacer en ese momento.
Les recomiendo leer “Pensar experiencias para nuevos usuarios” para más información sobre cómo escribimos el contenido.
Ahora el ALTA
Siempre tuvimos en claro que nuestro WMS iba a ser “user friendly”, algo no muy común en el mercado, je! Muchos WMS son impecables a nivel funcionalidad por todo lo que ofrecen para hacer, la cantidad de información que tienen, los reportes que generan, pero visualmente son sólo tablas en donde el operario debe interpretar la información.
Nosotros tratamos de hacer una buena combinación entre las dos cosas: ofrecer todas las funcionalidades que la operación necesita y hacerlo visualmente fácil de leer.
También nos pareció necesario involucramos desde el principio en la elección del handheld que íbamos a usar. Hicimos pruebas de usabilidad y los principales puntos que observamos fueron:
- ¿Cómo agarra el operario el handheld? ¿Necesita manija o es más cómodo agarrarlo como a un celular?
- ¿Cómo interactúa con la pantalla? ¿Necesita un lápiz?
- ¿Cómo manipula el dispositivo y los productos al mismo tiempo? ¿Escanea el producto desde su posición o lo agarra para escanearlo?
- ¿A qué distancia se escanea el producto? ¿5cm, 10cm, 15cm?
- ¿Qué sistema operativo es más conveniente? ¿Windows? ¿Android?
Y así fue como de a poquito fuimos construyendo nuestro WMS.
Fue un camino largo y por momentos difícil porque este mundo del warehousing y logística era nuevo para la mayoría de nosotros.
¡Pero lo logramos! Tenemos el WMS en producción hace 6 meses funcionando para México y Brasil. Y hasta podría decir que hoy en día todos nosotros ya somos expertos en procesos logísticos :).
