Skip to main content
Agenda una reunión
Robotipy
Logística

Por Danilo Toro, Fundador de Robotipy

RPA en la cadena de suministro: los procesos que rinden con automatización

RPA en la cadena de suministro: cómo automatizar el three-way match, las alertas de quiebre de stock y el seguimiento de pedidos en portales de proveedores.

Una empresa que compra insumos a una docena de proveedores recibe la documentación por canales distintos. Unos proveedores la mandan por correo y otros la suben a su propio portal. Alguno sigue con un EDI que se instaló hace diez años y que nadie quiere tocar. Si es tu caso, lo más probable es que el cuello de botella esté antes del transporte y del almacén, en el momento de cuadrar lo que llegó con lo que se pidió y con lo que registra el sistema. Mientras ese cuadre no esté hecho, no se puede pagar, facturar ni reponer sin arrastrar errores al mes siguiente.

En las empresas medianas con las que trabajamos, ese cuadre casi siempre se hace a mano. La orden de compra está en el ERP. La nota de entrega viene con el camión y la factura llega por separado. Ninguna de esas fuentes se comunica sola con las otras, y conectarlas con una integración tradicional suele ser un proyecto aparte, caro y lento de justificar.

Con RPA ese proyecto se puede evitar, porque el robot entra a cada sistema por la misma pantalla que hoy usa el equipo de compras o de recepción. Tampoco hace falta esperar a que un proveedor externo habilite una API, algo que puede no ocurrir nunca.

Three-way match: cruzar orden de compra, recepción y factura

En compras se llama three-way match a verificar que lo pedido, lo recibido y lo facturado coincidan antes de autorizar el pago. De los procesos de este artículo, es el que mueve más dinero, y casi siempre justifica el proyecto por sí solo. Hecho a mano, alguien abre tres pantallas o tres papeles y compara cantidades, precios y códigos de producto uno por uno. A las cuatro de la tarde nadie relee dos veces la misma fila, y así se cuela un error de digitación.

El robot toma la factura y la nota de entrega apenas llegan, por correo o desde el portal del proveedor. Si todavía vienen en papel, se escanean. Los datos se extraen con el mismo motor de lectura de documentos que describimos en IDP: procesamiento inteligente de documentos y se cruzan contra la orden de compra abierta en el ERP.

Cuando los tres documentos coinciden dentro de la tolerancia de ese proveedor, el registro pasa a la cola de pago sin intervención. Cada documento procesado queda anotado en la base SQLite local del proyecto, así que una segunda ejecución en el mismo día no vuelve a cargar la misma factura.

Si alguno de esos datos no cuadra, el robot aparta el caso y deja anotado qué campo falló y por cuánto. Compras recibe la diferencia ya calculada y no tiene que reconstruir el cruce desde cero.

Algunos proveedores aceptan un 2% de diferencia en precio y otros exigen coincidencia exacta. Esas tolerancias las negocia compras y cambian con cada renovación de contrato, por eso se guardan en el archivo de configuración del proyecto. Si estuvieran escritas dentro del flujo, habría que modificar el robot cada vez que cambian.

Alertas de reposición y quiebre de stock

El segundo flujo vigila el stock y avisa cuando un producto se acerca a su punto de reposición, antes de que falte. Es más pequeño que el three-way match, y cada quiebre que evita se refleja en las ventas. La alternativa manual es revisar una hoja de cálculo de stock una vez por semana, cuando alguien se acuerda, y suele fallar en la semana de mayor demanda.

El robot hace la revisión en un horario fijo. Lee el stock en el ERP y en el sistema de almacén (lo habitual es que sean sistemas separados) y lo compara con las ventas o el consumo proyectados a partir de los últimos periodos. Si un ítem va a llegar a su punto de reposición antes de la próxima ejecución, genera una alerta o un borrador de orden de compra con el proveedor y la cantidad sugerida. Esa cantidad sale de las reglas que ya están definidas para cada categoría.

El borrador no se envía solo. Alguien de compras lo confirma o lo ajusta, por ejemplo para pedir más antes de una promoción o para dejar de comprarle a un proveedor problemático.

Seguimiento de pedidos en portales de proveedores

Entrar a diario al portal de cada proveedor para ver si un pedido ya salió o si cambió la fecha de entrega consume muchas horas sueltas. Con diez proveedores son diez inicios de sesión al día. Alguien los hace entre otras tareas y muchas veces quedan para después.

El robot entra a cada portal, toma el estado actual del pedido y lo registra en el ERP o en un tablero centralizado. Si detecta una demora mayor al plazo acordado, o un cambio de estado a "rechazado" o "en revisión", genera un aviso con el motivo que informó el portal para que una persona lo gestione. Es el mismo seguimiento diario que usamos para autorizaciones médicas en automatización en el sector salud.

Documentación de comercio exterior

Si tu empresa importa, también se puede automatizar la documentación de despacho. El robot reúne la factura comercial, el packing list y el certificado de origen y los compara con lo declarado. Con eso deja la carpeta armada antes de que la pida el agente de aduanas o la propia aduana, y nadie tiene que salir a buscar cada papel cuando ya lo están pidiendo. No todos los proyectos lo necesitan, por eso lo tratamos como un módulo aparte que se suma al alcance cuando corresponde.

Con pocos proveedores, el cruce manual alcanza

Si compras a dos o tres proveedores de bajo volumen y una sola persona hace el cruce entre orden, recepción y factura en menos de una hora a la semana, automatizarlo no recupera la inversión en un plazo razonable. La cuenta cambia cuando el número de proveedores, de sistemas o de documentos crece más rápido que el tiempo disponible de esa persona, y los errores empiezan a aparecer todas las semanas.

Hay dos decisiones que conviene dejar fuera del robot en cualquier caso: negociar con un proveedor y aprobar una compra fuera de presupuesto. El robot arma el caso con los números correctos y la decisión la toma tu equipo.

Precio y plazo del proyecto

Un desarrollo de este tipo cuesta en promedio unos USD 6.000 e incluye la estabilización después de la puesta en producción. En cuánto cuesta automatizar un proceso está el detalle de cómo se arma esa cifra. El soporte posterior es opcional y cuesta desde USD 300 al mes.

El plazo depende más de la cantidad de sistemas que hay que integrar que del volumen de documentos. Un sistema de almacén separado o los portales de varios proveedores alargan el proyecto, porque cada portal es una integración distinta, con pantallas y lógica de inicio de sesión propias.

Si ya tienes algo integrado, por ejemplo el ERP con un proveedor específico, esa parte se reutiliza, igual que en cualquier integración de RPA con tu ERP.

Por qué empezar por el three-way match

Si vas a automatizar uno solo de estos procesos, empieza por el three-way match. Con los criterios de priorización le gana a la reposición y al seguimiento de portales porque su impacto en caja es directo. Un error de conciliación que nadie detecta termina en dinero pagado de más o en una nota de crédito que nunca se reclama. La reposición automática libera más horas de planificación que el three-way match, aunque ese ahorro tarda varias semanas en notarse.

Preguntas frecuentes

¿El robot decide cuánto stock pedir?+
No. Arma un borrador con las reglas de reposición de esa categoría, y compras confirma o ajusta la cantidad antes de enviar la orden.
¿Sirve si algunos proveedores trabajan con EDI y otros con portales manuales?+
Sí. Esa mezcla es habitual en empresas medianas de la región. El robot usa el canal de cada proveedor: si hay EDI, toma ese archivo, y si no, opera el portal como lo haría una persona. Las reglas de cada proveedor, incluido su canal, quedan en la configuración del proyecto.
¿Qué pasa si un proveedor cambia su portal de un día para otro?+
El robot se detiene solo para ese proveedor, hasta que se ajusta la parte que lee su pantalla. Los demás siguen funcionando con normalidad. Toda automatización que depende de una interfaz de terceros tiene ese riesgo, y por eso conviene monitorear las ejecuciones en lugar de suponer que siempre salen bien. Lo explicamos en cómo monitorear robots RPA en producción.
¿Cuánto tarda un proyecto de three-way match?+
Contra un solo ERP y con datos de entrada limpios, estimamos que puede quedar en producción en pocas semanas. Cada sistema adicional alarga ese plazo.
¿Y si ya tenemos un robot de facturación electrónica funcionando?+
Se puede reutilizar buena parte de la lógica de extracción de documentos y de la base de datos local de control. Antes de cotizar un proyecto nuevo desde cero, conviene revisar juntos lo que ya existe. Esa revisión también aplica si ya automatizaste cuentas por pagar.

Si tu empresa también factura a sus clientes, varios de estos procesos se cruzan con lo que explicamos en cómo automatizar la facturación electrónica. Y si estás evaluando a quién encargarle un proyecto de este tamaño, revisa cómo elegir un partner de RPA en LatAm.

Danilo Toro
Danilo Toro
Fundador de Robotipy
Danilo es un desarrollador y un emprendedor. Cuenta con más de 7 años de experiencia en automatización de procesos y desarrollo de software.

¿Tu equipo cuadra órdenes de compra, recepciones y facturas a mano?

Revisamos tus proveedores, tus sistemas y los canales por donde llegan los documentos, y te decimos qué proceso conviene automatizar primero.