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?+
¿Sirve si algunos proveedores trabajan con EDI y otros con portales manuales?+
¿Qué pasa si un proveedor cambia su portal de un día para otro?+
¿Cuánto tarda un proyecto de three-way match?+
¿Y si ya tenemos un robot de facturación electrónica funcionando?+
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.
