Escenario ilustrativo Distribución y logística

Automatización del back-office documental en un distribuidor B2B

Escenario de referencia: cómo se pasa de teclear facturas y albaranes de proveedor a un flujo que extrae, clasifica y concilia los documentos y deja a las personas únicamente las excepciones.

Escenario ilustrativo

Este caso no es un proyecto ejecutado

Es un escenario de referencia: un perfil de compañía compuesto, construido sobre problemas reales y recurrentes del sector, que explica cómo abordamos este tipo de trabajo, en qué orden y con qué criterio técnico. No describe a un cliente concreto y no ha ocurrido tal como se cuenta.

Todas las cifras de esta página son objetivos ilustrativos: el rango de mejora que consideramos razonable comprometer en un proyecto de este perfil, y que se fija con usted al cerrar el alcance tras medir su punto de partida. No son resultados obtenidos ni promesas de resultado.

Todavía no publicamos casos de cliente con autorización de publicación. Cuando exista, esta ficha dejará paso al caso real, con su nombre y sus cifras verificadas.

Parte 01 · Contexto

Sector
Distribución y logística
Perfil de compañía
Distribuidor B2B de recambios, 90 empleados, 2 almacenes y unos 400 proveedores
Soluciones aplicadas
Naturaleza de la ficha
Escenario ilustrativo cifras objetivo, no resultados

Parte 02 · Problema medible

Tres personas tecleando lo que ya venía escrito

Administración recibía cada mes miles de facturas y albaranes de proveedor por correo, en PDF y en papel escaneado, con decenas de formatos distintos. Se introducían a mano en el ERP, se cotejaban contra el pedido y, cuando aparecía una discrepancia de precio o cantidad, la incidencia se resolvía por correo y sin rastro. El coste no era solo el tiempo: los errores de tecleo llegaban hasta el margen y los pagos duplicados se detectaban tarde.

Almacén de distribución con estanterías de picking
Imagen ilustrativa del escenario. No corresponde a un proyecto entregado ni a datos de ningún cliente.
Esquema del orden de entrega: 4 bloques, cada uno apoyado en el anterior 01 02 03 04

Esquema del orden de entrega: cada bloque deja el terreno preparado para el siguiente. No es un calendario de proyecto.

Parte 03 · Hipótesis de solución

Qué se construye, bloque a bloque

El orden importa tanto como las piezas: cada bloque deja el terreno preparado para el siguiente y produce algo utilizable por sí mismo.

  1. 01

    Un único punto de entrada para los documentos

    Buzón dedicado, carpeta vigilada y captura desde el escáner desembocan en la misma cola, con acuse de recepción y numeración. Mientras haya cinco caminos de entrada no hay proceso que automatizar.

  2. 02

    Extracción y clasificación asistida por IA

    Un modelo de lenguaje acotado por esquema extrae proveedor, número, fecha, base, impuestos y líneas, y clasifica el documento por tipo. Cada campo sale con un nivel de confianza, y lo que no llega al umbral se envía a revisión humana en lugar de entrar al ERP.

  3. 03

    Conciliación automática a tres bandas

    Pedido, albarán y factura se cruzan por proveedor, referencia y cantidad. Lo que cuadra dentro de tolerancia se contabiliza solo; lo que no, genera una incidencia con motivo, responsable y plazo.

  4. 04

    Bandeja de excepciones y bucle de mejora

    El equipo trabaja sobre una cola priorizada por importe y antigüedad, con el documento y la propuesta lado a lado. Cada corrección humana queda registrada y alimenta la revisión mensual de reglas y umbrales.

Parte 04 · Arquitectura

Las decisiones técnicas, sin adornos

Publicamos la arquitectura porque es lo que separa una automatización que aguanta en producción de una demostración que impresiona un martes.

  1. 01

    Captura buzón dedicado y carpeta vigilada en el almacenamiento corporativo; los escaneos pasan por OCR antes de la extracción.

  2. 02

    Orquestación en Make o n8n, o en Power Automate cuando la compañía ya trabaja sobre Microsoft 365: una ejecución por documento, con reintentos y registro de errores.

  3. 03

    Extracción con un modelo de lenguaje acotado por esquema JSON: campos tipados, validación aritmética de bases e impuestos y nivel de confianza por campo.

  4. 04

    Umbral de confianza configurable por encima, contabilización automática; por debajo, cola de revisión humana con el documento original a la vista.

  5. 05

    Integración con el ERP por API, o mediante fichero intermedio cuando el ERP no expone una, siempre idempotente: una clave por documento impide el registro duplicado.

  6. 06

    Trazabilidad completa cada asiento conserva el documento de origen, la versión del esquema, el modelo utilizado y quién validó la excepción.

  7. 07

    Seguimiento en Power BI volumen, tasa de automatización, excepciones por motivo y coste por documento procesado.

Arquitectura del escenario: Captura → Orquestación en Make o n8n → Extracción con un modelo… → Umbral de confianza configurable → Integración con el ERP por API → Trazabilidad completa → Seguimiento en Power BI01Captura02Orquestación en Make o n8n03Extracción con un modelo…04Umbral de confianza configurable05Integración con el ERP por API06Trazabilidad completa07Seguimiento en Power BI
Esquema del flujo del escenario, de la captura del dato a la decisión. Diagrama de referencia, no la instalación de un cliente.

Parte 05 · Cómo se mediría el resultado

Sobre qué indicadores se mide el proyecto

Ninguna de estas cifras es un resultado obtenido. Son objetivos de referencia para un proyecto de este perfil: se fijan con usted al cerrar el alcance, después de medir el punto de partida, para que el antes y el después sean comparables.

objetivo:

80 %

Documentos procesados sin intervención humana

objetivo:

≈120 h/mes

Horas de administración liberadas

objetivo:

< 24 h

Registro de una factura desde su recepción

objetivo:

Idempotencia

Control de duplicados por clave de documento

criterio de diseño

Escenario construido con datos de mercado, no un proyecto entregado.

¿Quiere saber qué cifras son realistas en su caso? Talk to an expert

El caso en detalle

El punto de partida

Este caso es un escenario de referencia: describe cómo abordamos un problema recurrente en distribución y comercio B2B, con un perfil de compañía compuesto y unas cifras que son objetivos de trabajo, no resultados obtenidos con un cliente concreto. Lo publicamos porque el detalle del proceso vale más que una lista de tecnologías. Cuando cerremos proyectos con autorización de publicación, esta ficha se sustituirá por el caso real.

El diagnóstico habitual en este tipo de empresa es incómodo de escuchar y fácil de comprobar: una parte relevante del coste administrativo se dedica a transcribir información que ya llegaba escrita. El proveedor emite un documento estructurado, se convierte en PDF, y en destino tres personas lo vuelven a convertir en datos. Es un trabajo caro, tedioso y, precisamente por eso, propenso al error justo en los campos que afectan al margen.

Qué se construye

La automatización no empieza por la inteligencia artificial, empieza por ordenar la entrada. Un único punto de recepción con acuse y numeración es lo que convierte un caos de correos en una cola gobernable, y es también lo que permite medir. Solo después entra la extracción: un modelo de lenguaje acotado por un esquema, que devuelve campos tipados y validados aritméticamente, no texto libre que alguien deba interpretar.

La pieza que hace viable el conjunto es el umbral de confianza. Un sistema que aspira a acertar siempre es un sistema que falla en silencio; uno que reconoce su incertidumbre y deriva el caso dudoso a una persona es un sistema que se puede poner en producción sin miedo. La conciliación a tres bandas aplica la misma lógica: lo que cuadra dentro de tolerancia se contabiliza solo, y lo que no se convierte en una incidencia con motivo, responsable y plazo, en lugar de en un correo perdido.

Decisiones de arquitectura

Dos decisiones no son negociables en este tipo de flujo. La primera es la idempotencia: cada documento lleva una clave estable y el ERP rechaza el segundo intento, porque un reintento automático sin esa clave es la forma más rápida conocida de duplicar pagos. La segunda es la trazabilidad: cada asiento guarda el documento de origen, la versión del esquema, el modelo empleado y la persona que validó. Sin eso, la automatización es imposible de auditar y una discusión con un proveedor se vuelve un ejercicio de memoria.

Cómo deben leerse los resultados

Las cifras de la ficha son objetivos de referencia para un volumen y una diversidad documental como los descritos. En la práctica, el porcentaje de automatización depende de cuántos formatos distintos entren y de cuánta disciplina exista en los pedidos: en una primera fase suele empezarse por los proveedores que concentran el mayor volumen y ampliar desde ahí. El compromiso que sí asumimos es de método: medir el punto de partida antes de automatizar nada y publicar la tasa real de automatización cada mes, aunque no favorezca.

Después del proyecto: mejora continua

Un flujo documental vive con los proveedores, y los proveedores cambian de formato, de tarifa y de sistema. Por eso el proyecto se plantea unido a un retainer de mejora continua: revisión mensual de excepciones por motivo, ajuste de umbrales y reglas de tolerancia, incorporación de nuevos proveedores al circuito automático y control del coste por documento. Cada excepción que se repite es una mejora pendiente, y ese es exactamente el trabajo de la capa recurrente: convertir el histórico de errores en una tasa de automatización que sube trimestre a trimestre.

Continuidad

El proyecto termina; el sistema, no

Un cuadro de mando, una automatización o un CRM se degradan en cuanto cambian los procesos, los proveedores o las preguntas de dirección. Por eso planteamos cada implantación conectada a BGS Continuous Improvement, nuestra capa de mejora continua: una cuota mensual con bolsa de capacidad para revisar KPIs, ajustar automatizaciones, incorporar fuentes nuevas, lanzar experimentos y detectar la siguiente oportunidad.

El criterio con el que trabajamos es explícito: el proyecto se considera terminado cuando su equipo puede sostenerlo sin nosotros. El retainer existe para llevarle más lejos, no para que dependa de un proveedor.

  • 01 Revisión periódica de KPIs y de calidad del dato.
  • 02 Ajuste de automatizaciones, umbrales y excepciones.
  • 03 Incorporación de fuentes, procesos y equipos nuevos.
  • 04 Backlog de mejoras priorizado con dirección.
  • 05 Informe mensual de impacto y de coste de operación.

Hablemos de su caso, no del nuestro

Si algo de lo que ha leído se parece a su día a día, la primera conversación es gratuita y concreta: qué datos tiene, dónde se va el tiempo y qué se podría medir antes de proponer nada.