Ocho meses después del go-live, el maestro de artículos tenía más de 1,700 descripciones duplicadas y la precisión de picking había caído del 99.6% al 97.1%. El año pasado, el dueño de un almacén 3PL en Rancho Cucamonga me puso esos números enfrente y me preguntó: ¿compramos el WMS equivocado?

Revisamos juntos los registros del sistema. El sistema estaba bien. Los datos eran el problema. Un SKU se había creado tres veces: ventas lo registró como "Bluetooth earbuds - black", servicio al cliente lo volvió a crear como "BT earbud blk" al apurarse con un backorder, y el líder de recepción, con prisa, creó un tercer código. Tres personas, tres descripciones, un producto físico. Los pickers estaban frente a la ubicación con el RF en la mano, mirando tres nombres en la pantalla sin saber cuál tomar.

Al momento del go-live, los datos estaban limpios. El equipo del proyecto pasó dos meses depurándolos, y los consultores de implementación revisaron cada registro de SKU. Pero seis meses después, ya nadie era dueño de ellos. IT decía que los datos maestros eran responsabilidad del negocio; operaciones decía que el sistema era responsabilidad de IT. Así que no fue responsabilidad de nadie. Los datos se pudrían un poco más cada semana, el sistema se volvía más difícil de usar cada mes, y el dueño empezó a preguntarse si el dinero se había desperdiciado.

El dinero no se desperdició. Lo que faltaba era un rol.

Empieza por las reglas: quién crea, quién edita, quién entra

La mayoría de los almacenes pequeños y medianos no tienen un administrador de datos maestros. Los permisos de creación de SKU están en manos de una docena de personas: ventas crea SKUs para ingresar pedidos más rápido, servicio al cliente los crea para empujar la reposición, el líder de recepción los crea porque es más rápido que pedirlos. Cuanto más dispersos los permisos, menos responsable se siente nadie.

Mi consejo es directo: recoge los derechos de creación de vuelta a dos o tres personas, y nombra a una de ellas data steward. El mejor candidato suele ser el super user del WMS, o el supervisor de recepción con un segundo sombrero — toca producto físico todo el día, y cuando una descripción está mal es el primero a quien le gritan los pickers. Eso le da un incentivo natural para hacerlo bien.

Escribe tres cosas y píntalas en la pared: quién puede crear un SKU nuevo; quién aprueba cambios a los atributos de ubicación y las reglas de lote; quién limpia los datos sucios heredados y con qué frecuencia. Ponlo en papel. Los acuerdos verbales tienen una vida útil de unos tres meses.

Me preguntan: somos una empresa de treinta personas, ¿un rol dedicado es exagerado? No necesita ser de tiempo completo — un segundo sombrero está bien. Pero "segundo sombrero" no puede significar "cuando me apetezca". Tiene que estar escrito en la descripción del puesto, con medio día al mes reservado para ello. El trabajo que no está en la descripción del puesto no se hace.

Un steward sin una puerta de entrada sigue adivinando, así que también necesitas una lista de verificación de ingreso. La nuestra es así: los códigos de SKU se generan por regla, nunca se escriben a mano como "temporales"; las descripciones deben incluir marca, especificación y unidad de medida — nada de "el azul" ni "caja grande"; largo, ancho, alto y peso son obligatorios y deben venir de una báscula real, porque las dimensiones de caja que da el proveedor están mal nueve de cada diez veces; las reglas de código de barras son fijas, un código por SKU, empaque nuevo significa código nuevo; la clasificación ABC se hace con una llamada inicial y se revisa después de tres meses de datos de velocidad; los requisitos de lote y vencimiento se deciden el primer día, porque agregarlos después es el retrofit más doloroso de todos; la estrategia de putaway también se decide al ingreso — almacenamiento de tarima completa o picking por pieza — porque eso determina a qué zona va.

Un líder de recepción verificando etiquetas de ubicación con un escáner de mano

La lista parece quisquillosa. En la práctica agrega unos cinco minutos. Pero piénsalo: un SKU malo envenena la recepción, el putaway, el picking y el conteo cíclico — cuatro procesos río abajo. Arreglarlo después cuesta cien veces lo que cuesta hacerlo bien al ingreso. No es un cálculo difícil.

Lo más difícil de controlar es el "SKU temporal". Llega la temporada alta, ventas cierra un pedido urgente, el SKU aún no existe y el camión ya está en la puerta. Mi regla: los códigos temporales están permitidos, pero deben convertirse a SKUs reales en 30 días, con un recordatorio del sistema al vencimiento. Al convertir, se completan de una vez todos los campos faltantes. Temporal está bien. Podrido no.

Primera línea de defensa: deja que el sistema lo bloquee

La gente se vuelve perezosa. Así que la primera línea de defensa le pertenece al sistema.

Bloquea las reglas de validación en el WMS: los campos obligatorios no se pueden guardar vacíos; los campos de descripción llevan una verificación de similitud que avisa ante casi-duplicados; los códigos de barras son únicos en toda la base de datos, los duplicados se rechazan de plano; un peso o dimensión de cero — o algo absurdo — se bloquea. Estas configuraciones parecen menores. Detienen aproximadamente el ochenta por ciento de los errores de bajo grado antes de que existan.

Un movimiento más duro: separar la creación del SKU de "vendible". Un SKU recién creado queda por defecto en "pendiente de revisión" y solo sale en vivo cuando el data steward lo aprueba. Por más urgente que esté ventas, esperan esos cinco minutos. Esos cinco minutos son el equilibrio entre calidad de datos y velocidad del negocio. Mi veredicto: los cinco minutos valen la pena, porque un SKU podrido liberado al mundo no crea más que problemas río abajo.

Segunda línea de defensa: los humanos hacen muestreos

El sistema puede bloquear formatos malos. No puede bloquear contenido incorrecto en el formato correcto — una descripción completa con la especificación equivocada. Eso requiere un humano.

El método es el muestreo, no auditorías completas — las auditorías completas no son realistas. Cada semana, saca 20 SKUs recién creados o modificados, y el steward verifica cada uno contra el producto físico: ¿la descripción está bien?, ¿las dimensiones son correctas?, ¿el código de barras escanea? Cuando algo está mal, rastrea quién lo creó y corrígelo en el acto.

Suma encima un muestreo mensual de atributos de ubicación. Los atributos de ubicación son lo que más rápido se pudre: una ubicación marcada solo para tarima completa termina llena de piezas seis meses después; una ubicación marcada "sin entrada en pico" no significa nada para un montacarguista contratado el mes pasado. Muestrea 50 ubicaciones, corrige lo que no coincida con la realidad y escribe por qué — ¿se configuró mal originalmente o alguien la usó mal después? Son dos problemas distintos con dos soluciones distintas.

El peligro del muestreo es el teatro. Mi solución cruda: el registro de muestreo debe anotar cuántos problemas se encontraron. Tres meses seguidos de "cero problemas" significa que el muestreo mismo está roto. En un almacén real, cero problemas básicamente no ocurre.

Tercera línea de defensa: átalo al salario

Si las primeras dos líneas están en su lugar y los datos aún se deterioran, hay exactamente una razón: las personas que crean datos malos no lo sienten.

Así que la tercera línea es la rendición de cuentas. Pon la precisión de los datos maestros en los KPIs del departamento — o más directamente, atribuye los errores de picking y los envíos equivocados causados por problemas de datos maestros a quien creó los datos. No es una multa. Es un registro de error que afecta las evaluaciones de desempeño. La calidad de los datos nunca sube en la lista de prioridades hasta que está atada al sustento de alguien.

El steward también necesita la zanahoria. Pasa medio día al mes depurando datos, nadie lo nota, y su revisión de fin de año se ve igual que si no hubiera hecho nada — la próxima vez no se molestará. Yo pongo "precisión de datos maestros" como una línea de bono separada para él: datos más limpios, número más grande. La zanahoria no tiene que ser grande. Tiene que existir.

Tres líneas juntas: el sistema bloquea el ochenta por ciento, el muestreo humano atrapa las fugas, la rendición de cuentas arregla la motivación. Ninguna línea por sí sola es una bala de plata. Combinadas, funcionan.

Mañana por la mañana, haz dos cosas. Primero, recoge los derechos de creación de SKU en tu WMS de vuelta de una docena de personas a dos o tres. Segundo, imprime la lista de verificación de ingreso y pínnala en la pared de la oficina de recepción. Solo esas dos — nada más por ahora. Revisa tu tasa de errores de picking en un mes. Los números hablarán.

Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.