Un pedido puede constar en el ERP y no estar en el almacén sin que ninguno de los dos dé un error, porque cada uno cuadra consigo mismo. Este post cuenta cómo se detecta eso cruzando los dos sistemas en vivo, de dónde salen los umbrales que deciden qué es raro, y qué no demuestra.
El pedido que está en el ERP y no está en el almacén
Un sistema tiene nueve órdenes y el otro tiene ocho. Las dos listas cuadran consigo mismas, así que ninguno de los dos da un error.
El ERP tiene su pedido, con su fecha y su cliente, y para él todo va bien. El gestor del almacén tiene su cola de trabajo, y en ella ese pedido no está, así que para él tampoco falla nada.
Ninguno de los dos está equivocado, y esa es justo la clase de cosa que solo se ve con un modelo del negocio por encima de los sistemas, que contamos en cómo construimos la ontología de una empresa. El pedido solo desaparece cuando alguien pone los dos al lado, y hasta que eso ocurre nadie tiene motivo para mirarlo.
Publicamos otras tres del mismo juego: reposiciones abiertas, picking abandonado y órdenes retenidas. Y la de órdenes retenidas pide un matiz que el caso solo declara para el transporte: separar lo retenido a propósito de lo retenido sin querer. Si no, la lista de avisos se llena de cosas ya decididas y deja de leerse.
Ninguna de esas cuatro da un error, y las cuatro cuestan dinero. Pero no son iguales: las tres primeras las puede ver el sistema del almacén mirando sus propios datos, y la última no la puede ver ninguno de los dos, porque solo es cierta al cruzarlos.
Lo que el almacén avisó entre las 6:58 y las 7:06
Esa avería tiene una mañana concreta, publicada con el caso, y en ocho minutos el agente manda cuatro líneas.
Arriba está una mañana entera, y las cuatro líneas que publica el caso son estas. A las 6:58 se cierra la ola de picking de la mañana. A las 7:02 quedan verificados 1.180 bultos contra pedido. A las 7:04 las expediciones se asignan a transportista. A las 7:06 aparecen dos ubicaciones sin cuadrar y se avisa al jefe de turno.
Las tres primeras son contabilidad: dicen lo que ha pasado y no piden nada a nadie. La cuarta señala dos ubicaciones concretas y manda a una persona a mirarlas. Es la única que puede estar equivocada, y por eso es la única que vale.
La cuarta línea de esa mañana no dice «hay descuadres»: dice dos, y trae la ficha de cada una con su exportación. Un aviso que dice cuántos y no cuáles no es un aviso: es el mismo trabajo de antes, con una pantalla que lo recuerda.
Un almacén no es un sitio, son cinco: devoluciones, almacenaje, picking, reposición y expediciones. El reparto es nuestro, no del caso: nosotros publicamos reglas, no zonas. Y la avería de este post no cae en ninguna de las cinco.
Puestas sobre ese recorrido, las cuatro reglas publicadas caen en sitios distintos. Picking abandonado cae en picking y reposiciones abiertas en reposición: el almacén las ve mirando sus propios datos. Pero la orden que consta en el ERP y nunca llegó no está en ninguna zona, y ahí está la diferencia que importa: una avería dentro de una zona la ve un sistema solo; una avería entre dos sistemas no la ve ninguno.
De qué cuatro sistemas leemos antes de encender nada
Este almacén lleva registradas más de 30 millones de operaciones repartidas entre cuatro sitios que no se hablan: el gestor del almacén, el ERP, los datos de las agencias y los maestros comerciales. Lo primero es mirar qué hay en cada uno y de cuál se puede leer en vivo.
Nuestros agentes leen cuatro fuentes:
- El gestor del almacén, en vivo. Es lo que permite que un aviso de las siete de la mañana sea de las siete de la mañana y no del cierre de ayer.
- El ERP de la empresa, que es el otro lado del cruce.
- Los datos de las agencias de transporte, para lo que pasa una vez sale por la puerta.
- Los datos maestros comerciales, que es lo que convierte una referencia en un cliente con un compromiso.
Con esos cuatro se puede montar el cruce. Lo que todavía no se puede es poner los números, y esa es la otra mitad de la conversación.
De dónde sale cada umbral: del histórico de ese almacén, no de una tabla
Aparte de las veinticuatro reglas, vigilamos el transporte y detectamos «agencias lentas en recoger». Ese «lento» lo sabe el histórico de este almacén: se saca midiendo qué es lo normal aquí, y un transportista que aquí sea lento sería perfectamente corriente en un sitio con otro perfil de entrega.
La aritmética es toda la que hay, y con un ejemplo se ve. Los números que vienen ahora son inventados: los de cada instalación son suyos y no se publican. Si en el histórico de un almacén el 95 % de las recogidas se cierran en menos de cuarenta minutos, cuarenta es el umbral, y una recogida de cincuenta y cinco cae fuera.
Lo que hace útil ese cuarenta es que es de ahí. En un almacén de reparto rural la mediana puede estar en los cincuenta y cinco, y aplicarle el mismo umbral sería avisar de lo normal todas las mañanas. El número no está en ninguna tabla del proveedor: sale del percentil del propio almacén, y por eso no se puede enseñar antes de haberlo medido.
Un caso hace difícil esta regla, y es el que separa un sistema que sirve de uno que no. Un pedido creado en el ERP y volcado al almacén unos minutos después es, durante ese hueco, indistinguible de una orden perdida. Los dos se ven igual: existe en un sitio y no en el otro. Una regla que no tenga en cuenta ese desfase avisa cada noche de pedidos que están perfectamente bien, y a la tercera noche ya no la lee nadie.
De eso publicamos el resultado, no el método: que el sistema separa lo que se pausó a propósito de lo que va retrasado de verdad. Cómo resolvemos el desfase no lo publicamos, y por eso no lo cuento aquí.
Y al revés, que es como sirve para comprar: unos umbrales que se enseñan antes de haber mirado los datos del almacén son los umbrales de otro almacén.
Las veinticuatro reglas que comprueban el almacén, y las cuatro publicadas
De las veinticuatro reglas que corren de serie, solo hay cuatro nombradas en público.
Corren sobre los datos del almacén en tiempo real, y las cuatro nombradas son: órdenes retenidas, picking abandonado, reposiciones abiertas, y órdenes que constan en el ERP y nunca llegaron al almacén.
La cuarta es la interesante y es la del principio:
| Regla publicada | Qué detecta | ¿Puede verla un solo sistema? |
|---|---|---|
| Órdenes retenidas | Pedidos parados que nadie ha soltado | Sí, el gestor del almacén, mirando su cola |
| Picking abandonado | Recogidas empezadas y sin terminar | Sí, el gestor del almacén |
| Reposiciones abiertas | Huecos que nadie ha vuelto a llenar | Sí, el gestor del almacén |
| Órdenes que constan en el ERP y nunca llegaron | Un pedido que existe en un sistema y no en el otro | No. Hace falta cruzar los dos |
Las tres primeras las ve un sistema mirándose a sí mismo. La cuarta no la puede ver ninguno de los dos, porque cada uno tiene razón con sus propios datos.
Cruzar dos sistemas cada noche no es trabajo de una persona. El agente lo hace sin descanso. Cada incidencia que abre trae la lista exacta de órdenes afectadas, con su detalle y su exportación. La detección la hacen los datos; la redacción la hace el modelo, para quien tenga que leerla.
Aquí no hay un modelo detectando nada. Detectan veinticuatro reglas sobre datos en vivo. El modelo hace el último paso: convertir una salida de regla, del tipo «doce órdenes cumplen la condición 4», en una frase que el jefe de turno entiende a las siete de la mañana sin abrir una tabla. Cuando este post dice «el agente», se refiere a ese conjunto: reglas que miran, modelo que escribe.
Esa división es la decisión de diseño que sostiene todo lo demás. Una regla se puede leer, discutir y cambiar; su umbral es un número y se puede señalar con el dedo, así que cuando un aviso sale falso se sabe qué regla lo abrió y se corrige esa regla. Con un detector que no se puede abrir, un falso positivo es una anécdota: no hay nada que arreglar, solo que volver a probar. Tiene su precio, y es el límite de más abajo: una situación que nadie escribió como regla no produce ningún aviso.
Cómo se evita el aviso falso: separar lo pausado de lo retrasado
El modo de fallo abre este post. Falta la otra mitad: qué hace el sistema para no caer en él, que es donde está el trabajo fino. Está en no molestar.
En transporte se vigilan cuatro cosas, las cuatro publicadas. Y las cuatro son la misma trampa: agencias lentas en recoger, envíos parados o perdidos, destinos fuera de su plazo habitual y devoluciones por encima de lo normal. Las tres palabras que hacen el trabajo ahí dentro son «lentas», «habitual» y «lo normal». Ninguna de las tres existe fuera de este almacén.
Dos destinos con plazos habituales distintos no pueden compartir umbral, o uno de los dos avisa siempre. Y un envío parado en la agencia es, en los datos, idéntico a uno que alguien paró a propósito. Por eso el sistema separa lo pausado a propósito de lo retrasado de verdad: son dos cosas idénticas en la tabla y opuestas para quien recibe el aviso.
Hay un segundo límite, y toca saberlo antes de firmar: el sistema no sabe lo que no se le mandó vigilar. Las reglas cubren las situaciones que cubren; una situación nueva no produce ningún aviso, y ningún aviso se parece mucho a que todo va bien. Las veinticuatro reglas cubren lo que cubren, y de esas veinticuatro solo hay cuatro nombradas: nadie de fuera puede juzgar el hueco.
Qué más sale del mismo cruce: la productividad y el tamaño de lo vigilado
Vigilar incidencias es la mitad. La otra es que el mismo cruce de datos sirve para medir el trabajo.
Los agentes miden la productividad por persona y por máquina contra objetivo, calibrada con los datos reales del almacén, y con los plazos de entrega simulados día a día. Es el mismo cruce de antes usado al revés: en vez de buscar la orden que falta, compara lo que hizo cada turno con lo que el histórico dice que es normal en este almacén.
Lo publicamos al mismo nivel que la vigilancia de incidencias, no como un extra.
Y el mismo cruce da la escala de lo que hay debajo. Estas son las cifras que publicamos el 20 de agosto de 2026.
30 M+
operaciones de almacén registradas
900.000+
envíos procesados
460.000
ubicaciones bajo control
Dicen el tamaño del problema, no la calidad de la solución. La calidad está en el minuto 7:06, en que las dos ubicaciones señaladas sean exactamente esas dos.
Lo que los agentes no hacen: no mueven una orden ni cambian una prioridad
«Los agentes detectan, explican y avisan. No mueven una orden ni cambian una prioridad: eso queda en manos del almacén.»
Ese reparto entre lo que un agente puede hacer y dónde se detiene es el de siempre, y lo contamos entero en leer, avisar, ejecutar.
Un sistema que reordena solo una oleada de picking es otro producto, con otro riesgo, y con otra conversación pendiente sobre qué pasa cuando se equivoca a las seis de la mañana. Ese límite está publicado justamente para que se pueda exigir: escrito antes de la firma, es reclamable después.
Quién vigila ese almacén, y qué más tiene funcionando
Este almacén no es el único sistema que tenemos funcionando. Son cuatro, cada uno con su estado publicado, y el del almacén es el más callado de los cuatro.
Preguntas frecuentes
- ¿Hay que cambiar el gestor de almacén o el ERP?
- No. Los agentes leen los sistemas que ya hay y trabajan por encima de ellos. Lo que se monta antes es un modelo del negocio que cruza los dos, no un sistema que sustituya a ninguno.
- ¿Cómo se mide la tasa de avisos falsos?
- Se llama falsos sobre cerrados: de los avisos que una persona cerró el último trimestre, cuántos se cerraron como que no había nada. El denominador son los cerrados y no los abiertos, porque contando abiertos un trimestre con muchos sin revisar sale bien sin haber hecho nada. Lo juzga quien fue a mirar, no el sistema, y se mira por regla y no solo en total.
- ¿Puede un agente mover una orden o cambiar una prioridad?
- No, y está publicado con el caso. Los agentes detectan, explican y avisan; mover una orden queda en manos del almacén. Un sistema que reordena una oleada solo es otro producto y otra conversación de riesgo.
Lo que este post no demuestra
Todo lo de arriba sale de una sola instalación, y esa es la limitación principal: un almacén automático con su perfil de entrega, sus agencias y sus turnos. Lo que se traslada a otro es la forma del fallo y el juego de reglas, no la experiencia.
La pieza más floja de la demostración son las cuatro reglas nombradas. Son cuatro de veinticuatro, y las otras veinte no están publicadas, así que nadie de fuera puede juzgar si la cobertura es buena o si las cuatro publicadas son justo las cuatro que mejor quedan.
Y el sesgo tiene dirección, así que la digo: las cifras las publicamos nosotros. No las ha verificado un tercero. Si están inclinadas, están inclinadas a nuestro favor.
Y hay cuatro cosas concretas que este texto no cubre. Son justo las que cierran el post, convertidas en preguntas.
Así que la lectura correcta es esta: esto se lee como la demostración de tres cosas: que ese fallo existe, que cruzar dos sistemas lo detecta, y que un almacén lo hace en producción a ese tamaño. No se lee como la prueba de que sale a cuenta. Para eso haría falta el número de antes, y ese número no lo tenemos publicado.
Dos objeciones aprietan más que todo lo anterior.
La primera. Esta empresa publica una cronología al minuto, cuatro reglas nombradas y sus cifras de tamaño. ¿Por qué falta justo el único número que la juzgaría a ella? La lectura escéptica es la obvia: se calla porque no sale bien. No podemos descartarla, y decir «es que no lo publica nadie» no la responde, solo la esquiva. Lo que sí se puede decir es lo que hay: la definición está escrita y es la de este post, pero el número medido con ella no está publicado en ninguna ficha nuestra. Tener la vara y no enseñar la nota es peor de defender que no tener vara. Un lector que reste puntos por esto está restando bien.
La segunda es técnica y toca el cimiento. Todo el mecanismo supone que casar el pedido del ERP con la orden del almacén es fácil, y que lo difícil es afinar el umbral. En muchas instalaciones es al revés: los dos sistemas tienen claves distintas, referencias parciales y reintroducciones a mano, y emparejar bien es el trabajo caro. Este post no demuestra esa parte. Enseña la del umbral, que es la que el caso publica.
La tasa de avisos falsos, y por qué no la publica nadie
Un jefe de turno al que mandan a comprobar descuadres que no existen deja de ir.
La cifra que dice si eso ha pasado es una sola, y la llamamos falsos sobre cerrados: de los avisos que alguien cerró el último trimestre, cuántos se cerraron como «aquí no había nada». El nombre lleva dentro lo único que hay que discutir, que es el denominador. Sobre los cerrados, no sobre los abiertos: contando abiertos, un trimestre con muchos avisos sin revisar sale bien sin haber hecho nada. Y lo juzga quien fue a mirar, no el sistema.
El esquema de arriba enseña la aritmética con números pequeños: de nueve avisos abiertos, tres sin mirar, cuatro con algo detrás y dos sin nada; la tasa son esos dos sobre los seis que se cerraron. No la publica nadie en este sector. Y antes de escribir esto se repasaron nuestras cuatro fichas publicadas: tampoco la publicamos nosotros. Así que este post empieza suspendiendo la pregunta que él mismo va a proponer al final.
Nada de lo anterior cambia el mecanismo. Una orden que consta en un sistema y no en el otro sigue siendo invisible para los dos, y sigue apareciendo solo cuando alguien los pone al lado.
Y ese mecanismo no es de almacenes. Dos sistemas que cuadran cada uno consigo mismo y no entre sí es lo que ocurre en cualquier empresa con más de un sistema: un ERP y un gestor de almacén, una herramienta comercial y la de facturación, un archivo de expedientes y el correo. Cambian los nombres de las tablas y qué se considera normal aquí; no cambia que nadie da error.
Cuatro preguntas para cualquiera que venda un sistema así
Ninguna necesita saber de tecnología. Las tres primeras las contesta este post; la cuarta no.
¿De dónde sale cada umbral? Una respuesta que no mencione el histórico del almacén concreto está describiendo números de otro sitio.
¿Qué pasa cuando el aviso está equivocado? Si no hay respuesta, la va a dar el jefe de turno dejando de hacer caso.
¿Qué se mide antes de encender nada? El valor de un sistema así es una comparación, y no hay comparación honesta sin el número de antes. Si nadie mide el antes, dentro de un año no se podrá decir si sirvió.
Y la cuarta es con la que empieza este post, porque es la que de verdad decide, y es la que nosotros mismos suspendemos hoy:
¿Cuántos falsos sobre cerrados tuvo el último trimestre? Es la cifra que dice si el sistema se sigue leyendo a los seis meses, y ninguna de nuestras fichas la publica. Quien la dé encima de la mesa tiene algo que nosotros todavía no tenemos. Si no la da nadie, ya está localizada la pregunta de la segunda reunión. Todo esto sale de una instalación, cuatro reglas de veinticuatro, y unas cifras que publicamos nosotros.