SAM’S CLUB (WALMART MÉXICO)
Automatización de pedidos de consumo interno
De un Excel con macros a un módulo que genera las órdenes de compra.
- Research E2E
- Mapeo de procesos
- Pruebas de usabilidad
- Iniciativa
- Automatización de pedidos de consumo interno para las 174 tiendas mayoristas de Sam’s Club (Walmart) en México.
- Mi rol
- Product Designer E2E, con responsabilidad en investigación, diseño, validación e iteración.
- Duración
- Octubre 2024 - enero 2025.
01.Resumen
Cada mes, las 174 tiendas mayoristas de Sam’s Club México pedían el material con el que operan a través de un Excel con macros que circulaba por correo. Consolidar esos pedidos y generar las órdenes de compra dependía de trabajo manual repartido entre varias áreas.
Lideré la investigación y el diseño de un módulo que automatiza ese proceso. Mapeé un flujo que no estaba documentado a partir de 14 entrevistas con 20 participantes de nueve áreas, diseñé la solución y la validé en 7 pruebas de usabilidad. El módulo se lanzó en producción y, al cierre del proyecto, estaba en etapa de adopción.
02.Contexto y problema
Consumo interno es el material con el que una tienda opera y que no se le vende al cliente: charolas, domos, bolsas y empaques para panadería y perecederos. Es gasto operativo, no compra para reventa.
Cada mes, las 174 tiendas mayoristas pedían estos insumos llenando un archivo de Excel con macros que circulaba por correo y Teams. El proceso dependía de varias áreas y de un equipo de soporte que había pasado de 16 personas a 4.
El problema no era solo el archivo: el proceso completo estaba sostenido por trabajo manual, seguimiento fragmentado y falta de visibilidad.
Pedir material tomaba cinco etapas. Eficiencia operativa, el área que asignaba el presupuesto de cada tienda, actualizaba el catálogo a mano. Comunicación interna lo enviaba a las cuatro asistentes de distrito, que atendían unas 45 tiendas en promedio cada una; cada asistente lo repartía a sus tiendas y hacía seguimiento hasta reunir nuevamente los archivos completados. Después, eficiencia operativa consolidaba todo para que resurtido, el área con acceso al sistema de compras, corriera las macros y generara las órdenes de compra.
Nadie tenía ese proceso documentado. Lo mapeé a partir de entrevistas con las áreas involucradas para entender quién hacía qué, en qué orden y cuánto tiempo tomaba.
El costo principal estaba en la consolidación de pedidos y la generación de órdenes de compra:
25 h / mes
en limpiar el archivo consolidado, revisando fila por fila que no hubiera líneas vacías, cantidades negativas, unidades incorrectas ni tiendas faltantes.
20 h / mes
en generar órdenes de compra, trabajo que hacía resurtido porque eficiencia operativa no tenía acceso al sistema.
Macro que bloqueaba el ordenador
Requería una versión antigua de Office y no permitía hacer nada más mientras se ejecutaba.
“Del lunes 4 de noviembre a hoy 14 de noviembre llevo 43 horas invertidas.”
Además, el archivo era compartido, así que una tienda podía sobrescribir a otra. Los archivos llegaban incompletos y cada categoría pedía en unidades distintas, por lo que era común introducir kilos donde iban piezas.
En un gasto de unos 26 millones de euros anuales, había tiendas con desabasto y tiendas con sobreinventario al mismo tiempo, sin una forma clara de medir ninguno de los dos.
03.Mi rol y con quién trabajé
Trabajé con producto, developers, business analysts, content design y stakeholders de operación. Las decisiones no fueron individuales: mi responsabilidad fue llevar la evidencia que ayudara a orientar la discusión.
Mi liderazgo estuvo en:
- •Planear y ejecutar la investigación de principio a fin.
- •Reclutar y entrevistar a participantes de nueve áreas.
- •Mapear un proceso que no estaba documentado.
- •Traducir hallazgos operativos en decisiones de producto.
- •Validar la solución con pruebas de usabilidad.
- •Sostener decisiones frente a negocio con evidencia.
Mis líderes de investigación y diseño mentoreaban y validaban el enfoque y los entregables. Eso me dio autonomía sobre las decisiones del día a día y responsabilidad para defenderlas con stakeholders.
04.Objetivos
Objetivo principal
Automatizar la generación de órdenes de compra para reducir el desabasto y mostrar cuánto presupuesto se había usado y cuánto quedaba disponible.
Objetivo operativo
Hacer viable pasar de un resurtido mensual a uno quincenal.
Objetivo de investigación
Mapear el flujo completo: áreas involucradas, herramientas, tiempos, dolores y dependencias.
Hipótesis de partida: aumentar la frecuencia de resurtido mejoraría el abasto y el control del presupuesto en cada tienda.
Criterios de la solución
- •Pedidos solo dentro de una ventana de tiempo definida y configurable.
- •Consolidación automática.
- •Generación automática de órdenes de compra.
- •Cantidad sugerida con base en pronóstico.
- •Flujo de aprobación para excedentes.
05.Decisiones y en qué evidencia me apoyé
Fuentes: 14 entrevistas con 20 participantes de nueve áreas, sesiones con producto y stakeholders, revisión del proceso operativo, análisis del archivo Excel y entendimiento de reglas de negocio.
Hallazgos clave
- •El proceso no estaba documentado y vivía en el conocimiento distribuido de varias áreas.
- •La carga operativa recaía en pocas personas que hacían seguimiento manual a 174 tiendas.
- •El Excel compartido permitía errores críticos: sobrescritura entre tiendas, archivos incompletos, unidades incorrectas y cantidades inválidas.
- •El cuello de botella principal no era introducir los pedidos, sino consolidarlos y generar las órdenes de compra.
- •La falta de visibilidad hacía que desabasto y sobreinventario coexistieran sin una medición clara.
Usé IA para acelerar el análisis de las entrevistas y generar síntesis por área y borradores de hallazgos, siempre supervisando cada resultado. Como conduje las entrevistas y participé en las sesiones con stakeholders, podía identificar rápidamente lo que no correspondía a lo observado y corregirlo. También la usé para explorar alternativas de diseño a partir de los hallazgos, y algunas ideas sirvieron como punto de partida para discutir con el equipo de UX.
Cómo enmarcamos el problema
El reto no era digitalizar un Excel, sino rediseñar un proceso operativo distribuido entre tiendas, asistentes de distrito, eficiencia operativa y resurtido.
El proyecto llegó con el supuesto de montar consumo interno sobre un flujo existente para perecederos. Era razonable desde negocio, pero no estaba validado con los usuarios.
Validé la solución con 7 pruebas de usabilidad repartidas en tres flujos: 4 usuarios en generación de pedidos, 2 en aprobaciones y 1 en configuración.
En las pruebas, 3 de 4 usuarios del flujo de pedidos no encontraron la herramienta donde estaba. Para ellos, los empaques eran inventario, no perecederos. Por eso la solución terminó como un módulo propio.
Las pruebas ayudaron a tomar decisiones clave:
Antes, cada tienda calculaba su pedido con ventas del año anterior, tendencia de crecimiento y un objetivo de merma cercano al 6%. En la solución, el sistema hace ese cálculo y entrega una cantidad sugerida prellenada. El usuario revisa y ajusta solo donde hace falta.
En pruebas, “Venta prospectada” y “Consumo esperado” no se entendían. Con content design quedó “Consumo sugerido (en cajas)”, con nombre claro y unidad explícita.
Las celdas se comportan en dos estados:
- •Azul claro: valor sugerido por el sistema.
- •Azul oscuro: valor modificado por el usuario.
En una tabla larga, esto permite identificar rápidamente qué se tocó y qué se dejó como venía. Además, el patrón ya existía en otros módulos de la plataforma, por lo que aprovechaba un modelo mental aprendido.
Exceder el presupuesto era normal y previsto: ya existían autorizaciones por monto, pero ocurrían por correo. El diseño llevó esa regla al producto con un flujo escalonado, desde gerente de tienda hasta subdirección de distrito según el monto, con la justificación visible para quien autoriza.
El pedido no se puede enviar hasta que pasa una validación. Los artículos fuera de rango se señalan en la propia celda.
06.Limitaciones y restricciones
La muestra de pruebas fue menor a la ideal por disponibilidad operativa, así que algunas recomendaciones quedaron como validaciones futuras.
07.Impacto
El módulo se lanzó en producción con el proceso completo llevado por primera vez a una herramienta digital.
Al cierre de mi participación, el módulo estaba en etapa de adopción, por lo que este caso documenta el diseño del proceso y las decisiones que lo sustentan, no resultados de negocio ya medidos.
08.Qué aprendí
El mapeo del proceso fue la pieza que más cambió la conversación. Permitió mostrar que el dolor no estaba solo en el Excel, sino en cómo el trabajo estaba distribuido entre áreas; sin ese mapa, la solución habría sido solo digitalizar el archivo.
Un requerimiento también puede ser un supuesto. El de usar el flujo de perecederos se sostuvo por meses, y una validación temprana de arquitectura de información lo habría descartado antes. Aunque venga de producto y tenga lógica de negocio, necesita validarse con el comportamiento y el lenguaje de las personas usuarias.
Medir es parte del diseño. Si el equipo de diseño no participa desde el inicio en la definición de métricas, después puede ser difícil saber si los datos disponibles responden preguntas reales de experiencia.
Investigar con usuarios en operación exige un plan B desde el inicio, como sesiones remotas más cortas o ejercicios asíncronos.
