Pedidos bloqueados: el problema no está dentro de tu ERP, está en los huecos que tu ERP no ve

Porque el ERP solo sabe lo que pasa dentro del ERP. Cuando el pedido sale hacia el almacén, hacia el transportista o hacia el buzón de un proveedor, deja de estar bajo su vigilancia: el ERP guarda el último estado que alguien le contó y lo da por bueno hasta que alguien le cuente otro. Un pedido bloqueado no es un pedido con un error dentro de un sistema. Es un pedido que se ha quedado en tierra de nadie entre dos sistemas, y que no tiene a nadie asignado porque formalmente no está en ninguna bandeja.

Por eso la mayoría de estas incidencias se descubren tarde y por el canal peor: el cliente que llama preguntando por un pedido que en tu pantalla figura como expedido. En ese momento el coste ya no es solo el tiempo de resolverlo, es el de haberlo sabido el último.

No, y la distinción ahorra muchas conversaciones cruzadas con el equipo de sistemas. Tu ERP sabe nombrar tres clases de parada y las tiene en una lista que se puede abrir ahora mismo: bloqueo de crédito, bloqueo de entrega y bloqueo de facturación. Son frenos que alguien puso a propósito, con un motivo registrado y un procedimiento para levantarlos. Funcionan, y no son de lo que habla esta página.

Un pedido bloqueado en el sentido de aquí es el que nadie ha frenado: simplemente ha dejado de avanzar porque la decisión que lo mueve no es de ningún sistema. Y un pedido que nadie ha frenado no tiene estado de bloqueo, así que no está en esa lista ni en ninguna otra. Están enumerados uno a uno, con la costura en la que ocurre cada uno, en los siete sitios donde se queda parado un pedido entre el ERP y la entrega.

Se calcula con cuatro números que ya tienes, y sale más alto de lo que nadie espera porque casi todo el mundo cuenta solo el tercero: cuántas incidencias hay al mes, cuánto tiempo pasa cada una parada antes de que alguien se entere, cuántos minutos cuesta resolverla y cuánto dinero queda quieto mientras tanto. Los tres primeros son horas de personas; el cuarto convierte el problema operativo en un problema de caja, que es el idioma en el que se aprueban los proyectos.

El método completo, con la aritmética a la vista para que puedas discutir los supuestos en vez de creértelos, está en cuánto cuesta de verdad una incidencia de pedido. Si tus incidencias están sobre todo en pedidos que no avanzan —bloqueos de precio o crédito, falta de stock, diferencias al preparar, enviado y no facturado— o en la franja de factura de proveedor —duplicados, cambios de cuenta, facturas atascadas— puedes calcular lo que te cuestan al año con tus números. Esa calculadora cubre esas costuras y no la cadena completa del pedido: la cadena entera se mide en el diagnóstico operativo, que es donde entran los datos de tu operación.

Porque las dos soluciones escalan con el volumen, y el volumen es exactamente lo que está creciendo. Son respuestas razonables —de hecho son las que usa casi todo el sector— y cada una funciona hasta un punto muy concreto.

El patrón común de las cuatro: ninguna cambia el hecho de fondo, que es que el traspaso entre dos sistemas no tiene dueño. Le ponen más personas encima, o más visibilidad, pero el hueco sigue ahí.

Vale para mover un dato de A a B, y no vale para cerrar un trabajo que dura días. La diferencia es el estado: un flujo se dispara, hace sus pasos y termina; si falla a mitad, no recuerda qué había hecho antes, así que nadie sabe si el pedido se actualizó y el correo no salió, o al revés. Cuando eso pasa con cientos de pedidos al mes, el resultado es un flujo que hay que vigilar, y vigilarlo cuesta lo mismo que hacerlo a mano.

Un pedido bloqueado no es un evento: es un expediente abierto que puede estar tres días esperando un albarán, reintentar, escalar a una persona y acabar con un abono. Eso necesita memoria de lo que ya se intentó, un plazo y un responsable. Es una categoría de herramienta distinta, no una versión mejor de la misma. Si lo que estás valorando ahora mismo es cómo conectar los sistemas, están comparadas las cuatro formas de conectar el ERP con el almacén con lo que cada una deja fuera.

Tres cosas, y ninguna de las tres es «más automatizaciones». La primera, que el trabajo parado tenga expediente y no aviso: un aviso se lee y se olvida, mientras que un expediente tendría objetivo, bloqueo actual, plazo, responsable y todo lo que ya se ha intentado, y seguiría abierto aunque quien lo llevaba esté de vacaciones. La segunda, que hubiera una respuesta única sobre el estado real, porque hoy la pregunta «¿qué pasa con este pedido?» se responde abriendo seis pantallas y juntando las respuestas en la cabeza de alguien. Y la tercera, que las decisiones las tomaran reglas tuyas, escritas por ti: hasta dónde se abona sin preguntar, qué desviación de precio pasa sola, qué se para siempre.

Esto último está escrito en condicional a propósito. El motor que sostendría esos expedientes se está construyendo con las primeras distribuidoras y no se puede comprar hoy. Lo que sí está construido y en producción es la capa que decide qué puede tocarse y qué no: reglas deterministas sin ningún modelo en el camino crítico, aprobación humana de lo que se sale de la regla, registro verificable y botón de parada. Está explicado en qué puede tocar Pliuz en tus sistemas y qué no, que es la página que suele pedir el responsable de sistemas antes de dejar avanzar nada.