Lo esencial desde el principio: cuando una mala configuración de permisos en el WMS corrompe los datos, la causa casi nunca es una sola casilla. Son tres fugas actuando juntas: roles concedidos con demasiada amplitud, ámbitos de ubicación que ignoran al cliente y estados de documento que nadie restringe. Si se pasa por alto cualquiera de ellas, los datos erróneos fluyen por el sistema sin un solo mensaje de error, hasta que un recuento de existencias o una reclamación de un cliente obliga a desenredarlo todo.
He visto este mismo fallo tres veces, en tres almacenes distintos, con tres síntomas distintos. La causa raíz fue la misma en todos los casos: durante la puesta en marcha, alguien copió una plantilla de permisos de un rol a otro para ahorrar tiempo, y nadie volvió después a recortarla.
Fuga 1: Roles concedidos con demasiada amplitud
En septiembre de 2024, un almacén de logística de terceros en el este de China puso en marcha un nuevo WMS. El equipo de implantación, bajo la presión de los plazos, copió la plantilla de permisos del controlador de inventario para crear el rol de picker y le cambió el nombre. Un ajuste sobrevivió a la copia: los pickers podían ajustar manualmente las cantidades de inventario.
Tres semanas después de la puesta en marcha, las diferencias en los recuentos cíclicos empezaron a aumentar. La investigación descubrió que los pickers que no encontraban existencias en la ubicación asignada estaban editando en silencio la cantidad del sistema para que coincidiera con lo que veían delante de ellos. Normalmente la mercancía estaba en el pasillo contiguo, pero el sistema ahora decía que el recuento era correcto. En un mes, más de 120 SKUs estaban desincronizados entre el stock contable y el stock físico, dos pedidos se enviaron mal y el almacén perdió un fin de semana entero en un recuento físico completo.
La solución es una disciplina, no una función: conceder permisos por acción, no por puesto de trabajo. Un picker necesita confirmación de picking, notificación de excepciones y validación por escaneo. Un picker no necesita ajuste de inventario, anulación de documentos ni edición de datos maestros. Un controlador de inventario puede solicitar un ajuste, pero esa solicitud debe pasar por aprobación. Un supervisor puede aprobar, pero nunca debe introducir y aprobar la misma transacción. Escribe la lista de acciones, revísala línea por línea, y detectarás lo que el nombre de un rol oculta.
| Rol | Puede hacer | Nunca debe hacer |
|---|---|---|
| Picker | Confirmar pickings, notificar excepciones, validar escaneos | Ajustar inventario, anular documentos, editar datos maestros de ubicaciones |
| Operario de putaway | Confirmar putaway, escanear ubicaciones, notificar diferencias | Trabajar entre clientes, editar datos maestros de productos |
| Controlador de inventario | Solicitar ajustes, realizar recuentos | Aprobar su propio ajuste |
| Supervisor | Aprobar ajustes, ver informes de todo el almacén | Introducir y aprobar el mismo documento |
Fuga 2: Ámbitos de ubicación que ignoran al cliente
La segunda fuga es más sutil, y golpea con más fuerza en los almacenes multicliente. En marzo de 2025, un almacén en el sur de China servía a dos marcas de cosméticos. Los permisos de ubicación se establecieron solo por zona, no por cliente. Un operario de la Marca A podía ver las ubicaciones de la Marca B, y cuando elegía una ubicación equivocada de una lista, el sistema no lo detenía.
Un lote de crema facial de la Marca A terminó en el frente de picking de la Marca B. El stock contable decía Marca A, el stock físico estaba en la estantería de la Marca B. Los recuentos de ambas marcas fallaron, y cada parte culpó a la otra de una transferencia de stock que nunca ocurrió. Hicieron falta cuatro días de búsqueda estante por estante para encontrar las cajas, además de un envío aéreo urgente para cubrir un pedido retrasado.
En una operación multicliente, los permisos de ubicación deben bloquear dos cosas a la vez: lo que un usuario puede ver y lo que un usuario puede tocar. Bloquear solo la visibilidad no basta, porque un operario puede teclear un código de ubicación de memoria. Bloquear solo las acciones tampoco basta, porque los informes y consultas que filtran datos de otro cliente igualmente inducirán a error en las decisiones. La configuración correcta vincula cada rol a un ámbito de cliente, y luego filtra el selector de ubicaciones, el conjunto de tareas y cada informe a través de ese ámbito. Una operación entre clientes no debería aparecer para luego dar un error; no debería aparecer en absoluto.
Fuga 3: Estados de documento que nadie restringe
La tercera fuga vive en los documentos. En junio de 2025, un almacén de repuestos de automóvil en el norte de China tenía un defecto de larga data: un pedido de salida aprobado podía devolverse para editarlo, cambiar sus líneas y luego liberarse para picking sin una nueva aprobación. La aprobación cubría la versión uno. Nadie aprobó lo que realmente se envió.
El daño fue concreto. Un pedido de salida de 86 líneas se editó después de la aprobación: tres líneas vieron aumentadas sus cantidades, el almacén preparó las cantidades editadas y el cliente recibió más de lo pedido. La conciliación con el pedido original falló, y el registro de auditoría mostraba al editor, al picker y al aprobador todos dentro de un mismo grupo indiferenciado de "operario de almacén". Reconstruir la responsabilidad era imposible.
Los permisos de documento deben aplicarse mediante una máquina de estados, no mediante la confianza. Para cada tipo de documento, traza los estados — borrador, aprobado, liberado, enviado — y define exactamente qué campos pueden cambiar en cada estado. Cuando cambia un estado, los campos editables se restringen de inmediato. Cuando cambia un campo clave, el documento vuelve a pendiente de aprobación. Esa regla pertenece a la configuración del sistema, no a un manual de operaciones. La gente olvida los manuales. Los sistemas no.
La lista de verificación de la noche de puesta en marcha para la mala configuración de permisos en el WMS
Esta es la lista de verificación que aplico la noche de la puesta en marcha, siempre, y no doy el visto bueno hasta que está en verde:
- Exporta la lista completa de permisos de cada rol. Compara cada rol con una lista de puede-hacer / nunca-debe-hacer, prestando especial atención al ajuste de inventario, la anulación de documentos y la edición de datos maestros.
- Inicia sesión como picker de prueba. Intenta ajustar una cantidad de stock, anular un documento y abrir la ubicación de otro cliente. Los tres intentos deben ser bloqueados. Un solo éxito es una fuga.
- Simula un error entre clientes: haz que una cuenta de prueba de la Marca A escanee un código de ubicación de la Marca B. El sistema debe rechazarlo o no mostrar nunca esa ubicación.
- Simula una aprobación editada: cambia un campo clave en un documento aprobado y confirma que el estado vuelve a pendiente de aprobación, y que el editor y el aprobador no pueden ser la misma cuenta.
- Revisa la cadena de aprobación: para cada tipo de ajuste y anulación, la lista de aprobadores debe excluir a la persona que introdujo la transacción. Las anulaciones de emergencia deben dejar igualmente un rastro de auditoría.
- Revisa los permisos de informes: un rol limitado a un cliente no debe poder exportar los datos de otro cliente a través de un informe.
Esta es la parte contraintuitiva: conceder demasiados permisos es más peligroso que conceder demasiado pocos. Conceder demasiado pocos falla de forma ruidosa: un operario topa con un error el primer día y la brecha se corrige. Conceder demasiados falla en silencio. Los operarios trabajan sin problemas, los errores se acumulan en silencio, y cuando un recuento de existencias o una reclamación de un cliente saca el problema a la luz, estás reparando meses de datos corrompidos, no solo un ajuste.
Una advertencia más para los equipos de puesta en marcha: la configuración de permisos no es una tarea de una sola vez. Cada nuevo cliente, cada nueva zona, cada nuevo rol de trabajo debería activar la misma lista de verificación. La mayoría de los almacenes no rompen sus permisos con un gran error. Los rompen con una serie de pequeños favores de "añade esto solo temporalmente" que nadie revoca jamás. Tres meses después, nadie recuerda por qué existe ese acceso.
Ese patrón de fallo silencioso es exactamente por lo que la mala configuración de permisos en el WMS merece una lista de verificación en lugar de una revisión puntual: el sistema nunca se queja, así que la lista de verificación tiene que quejarse por él.
Si los permisos están bien, el sistema dice la verdad. Si están mal, registrará errores con total confianza, todos los días.
Por Lin Xiao, Consultor de Implementación de WMS
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
