Automatización de procesos en ORAN

Cómo la automatización nos permite optimizar los flujos de trabajo en ORAN

Prácticamente no existe industria capaz de eludir las tareas repetitivas. Actividades que exigen atención y sobre todo, horas y horas de trabajo. Es cierto que la tecnología está de nuestro lado en este asunto. Que cada vez tenemos más opciones para la automatización de tareas y que, cuando se detecta una oportunidad en este ámbito, hay un gran beneficio potencial si se toman las decisiones adecuadas.

Sin embargo, no existe una situación más común y al tiempo sencilla de resolver, como la que se da cada día en el entorno de oficinas de casi cualquier empresa. Hablamos de procesos desencadenados a partir de la llegada de un simple correo electrónico. Para profundizar en las posibilidades que existen en este aspecto, hoy os traemos una pequeña guía de mano de nuestro responsable del Departamento de Informática, Alberto Burgada, que ha elaborado este texto para arrojar un poco de luz sobre este tipo de automatizaciones.

Automatizaciones sencillas y útiles

Mi nombre es Alberto Burgada y en esta publicación quiero compartir con vosotros la mejora de un proceso interno de nuestra empresa. De paso hablar de las diferentes tecnologías que he utilizado para su ejecución, la extensibilidad de las diferentes partes que componen la solución y una estimación del ahorro de tiempos que nos puede suponer esta optimización en la operativa diaria.

El proceso físico consiste en la descarga y recepción de materia prima. Concretamente paquetes de chapa metálica para la estampación de piezas en nuestras instalaciones. Estas piezas son posteriormente utilizadas en la planta final de ensamblado junto al resto de componentes para la fabricación de nuevos vehículos.

En este caso, nuestro cliente final estima la demanda de piezas que va a tener y el proveedor de materia prima nos envía los paquetes de manera acorde a la misma. De esta forma, nos envía un email donde adjunta un albarán con los próximos paquetes que vamos a recibir en PDF.

Para poder seguir nuestro circuito normal de producción, compras, gestión, etc., debemos dar de alta en nuestro sistema un pedido con la información relativa al material en tránsito que nos proporciona el proveedor, generar posteriormente un albarán al recepcionar este pedido y asignarle un número de lote interno a cada paquete recibido. De esta forma mantenemos la trazabilidad de todo el proceso de fabricación y podemos detectar posibles defectos de calidad en el material con el que estampamos las piezas.

Análisis y obsevación de las tareas repetitivas

Este proceso se encontraba digitalizado, pero hemos considerado que algunas de las tareas que realizábamos eran repetitivas y susceptibles de ser automatizadas. Por ello hemos resuelto cada tarea para eliminar todos los trabajos innecesarios o redundantes. Buscamos en definitiva que el correo que el proveedor nos envía sea suficiente, junto con la ayuda del reconocimiento de imágenes, para tener toda la información en nuestro sistema y que la única intervención consista en la recepción final del material.

Robot moviendo formato de chapa.

Power Automate

Nuestro primer paso para conseguir la automatización será crear un flow automático mediante la unión de bloques ya preconstruidos que deberemos configurar para llegar al resultado deseado. Para ello nos servimos de Power Automate, herramienta con la que ya contamos sin coste adicional al tener licencias de Office365.

Creamos nuestro flow.

En nuestro caso, filtramos los correos que comiencen por “070” y contengan archivos adjuntos, ya que nuestro proveedor mantiene esa estructura al mandarnos la información. En caso de cambiar tendríamos que actualizar esto. Podríamos utilizar otros criterios para filtrar los emails como el correo del emisor, si alguien concreto se encuentra entre los receptores, etc.

Si el correo cumple esta primera condición, filtramos de nuevo cada archivo adjunto al correo mediante un bloque iterativo “Apply to each”; si comienza también por “070” guardamos este archivo en nuestro sitio de SharePoint en la librería concreta que nos interesa.

En caso de no darse alguno de los condicionantes en el correo, el flow no llegaría al final y nuestra librería de documentos se mantendría limpia.

Captura de los bloques.

SharePoint

Si el proceso anterior se ha ejecutado correctamente, nos irá dejando los archivos adjuntos que buscamos en la librería especificada. Dentro de esta librería contaremos con una carpeta de “Procesados” para mover los documentos una vez hayamos realizado la tarea completamente.

Documento a procesar.

A través de nuestro ERP Maldivas (de desarrollo interno en la empresa), desarrollaremos un método que orqueste el resto de la solución. Este puede ser ejecutado manualmente por un usuario, o lo podemos automatizar para que se ejecute en periodos de tiempo que nosotros definamos.

Dentro de esta herramienta de gestión ya contamos con una integración previa con SharePoint enfocada al gestor documental, organizando estos documentos por librerías según el departamento o subdivisión de los mismos. Los métodos de autenticación, lectura / subida de documentos y otros ya estaban desarrollados. En este punto nuestra solución sólo requirió hacer un método para mover documentos de un sitio a otro dentro de la librería y así poder mover el PDF de la carpeta principal a la carpeta de “Procesados”.

ERP Maldivas

Como comentábamos en el paso anterior, será el encargado de orquestar el resto de la solución.

En él guardaremos la información relativa a la librería de Sharepoint que utilizamos, el modelo de Azure Form Recognizer encargado de analizar los documentos y los pasos a dar posteriormente. En nuestro caso, guardamos la dirección del Endpoint de una API REST interna a la que enviaremos la respuesta recibida de Azure. Este último paso es el más importante pues será el que haga uso de la información que extraemos finalmente del reconocimiento automático del documento.

Información relevante para orquestar la solución.

Esta información queda estructurada en una tabla de nuestra base de datos SQL Server, pudiendo de esta forma reutilizar la misma estructura para configurar nuevos métodos a futuro y aprovecharnos así de nuestro desarrollo.

> ModelId -> Id del modelo entrenado en Azure que analizará nuestro documento.
> SharepointFolder -> La carpeta donde alojamos los documentos a procesar. Esta carpeta se encontrará siempre dentro de la misma librería FormRecognition que es la que utilizaríamos para otros documentos, así que la estructura siempre sería la siguiente:

[ urlXXX/sites/sitioXXX/FormRecognition/sharepointFolderXXX]
> SharepointFolderProcessed -> La carpeta donde movemos los documentos ya procesados, siempre dentro de la carpeta principal SharepointFolder.
> Endpoint -> El método encargado de utilizar la información que nos devuelve el modelo (con un procesado extra que se explica en el siguiente punto) dentro de una API REST interna.

Azure Form Recognizer

Azure cuenta entre sus servicios con Form Recognizer, un algoritmo de reconocimiento de documentos que podemos entrenar mediante ejemplos para extraer información relevante de ellos.

Nos permite reconocer hasta 500 páginas al mes de manera gratuita.

El documento que queremos analizar nos lo envía el proveedor siguiendo una misma estructura y en este caso nosotros queremos extraer:
> Referencia: El número de albarán del proveedor.
> Artículo: El código interno el formato de chapa que nos envía el proveedor. En este caso, al ser siempre la misma referencia, podríamos incluso no extraerlo, en caso de enviarnos diferentes formatos sí sería obligatorio.
> Detalle de los paquetes (Etiqueta, Cantidad, Peso): Con ello sabemos cuántos paquetes nos van a enviar, con qué cantidad de formatos cada uno, el peso total de los mismos, y la etiqueta con la que vendrá codificado cada paquete. Esta información será muy relevante para la recepción final del material y la integración en nuestra cadena logística.

El documento que nos envía el proveedor siempre cuenta con esta misma estructura.

Para el entrenamiento del modelo con estos documentos, Azure proporciona una herramienta (https://fott.azurewebsites.net/) con la que podremos etiquetar el texto que reconoce de cada documento y definirle qué estructura de datos tiene para nosotros. En nuestro caso tenemos los datos de la referencia del albarán del proveedor, el artículo de chapa y las líneas de detalle, que pueden variar, ya que con cada recepción nos puede llegar un número diferente de paquetes. Para esto último etiquetaremos estas líneas de detalle como una tabla con 3 campos, etiqueta, cantidad y peso.

Bastaría con utilizar al menos 5 ejemplos para poder entrenar el modelo, y que este sea capaz de reconocer documentos posteriormente. En caso de utilizar más, el modelo lógicamente ganaría en robustez y fiabilidad.

Herramienta de entrenamiento de modelo customizado para el documento que queramos.

Una vez entrenado y guardado su ModelId en nuestra base de datos, podemos conectarnos a Azure a través de su API para mandarle documentos y que nos devuelva una respuesta en formato Json con lo que reconoce el modelo.

Yo he aislado esas llamadas a su vez en un endpoint interno de nuestra API REST para poder atacarlo desde diferentes puntos, pensando en la posibilidad de extender esta solución a una foto con un móvil, subir un documento deste una web, etc. y no ser rehenes de nuestro ERP para esto.

Los endpoints que usaremos para reconocimiento de texto.

Dentro de nuestra API, que utiliza el framework .NET6, nos servimos de un paquete NuGet que proporciona Azure para facilitarnos la conexión a su servicio, autenticándonos con la clave que podemos ver a través de nuestro portal de Azure.

Paquete de Azure Form Recognizer.

El modelo que hemos entrenado nos devuelve una respuesta que contiene mucha información. Para poder trabajar de manera más cómoda tendremos que limpiarla para extraer lo más importante y llegar a una estructura estandarizada para futuros usos.

Respuesta de Form Recognition, demasiada información que me devuelve el modelo no relevante para mí (Json con 7000 líneas).

Tras tratar el Json, lo convierto para conseguir una estructura de este tipo:

Objeto estandarizado que quiero para la respuesta de cualquier modelo.

Una vez obtenida la información con la estructura que busco, guardamos tanto la respuesta tratada como la respuesta en crudo. Así, en el caso de tener que volver a analizar esta por algún error, no me requeriría llamar al modelo otra vez. De esta forma, obtendríamos un objeto fácilmente tratable como respuesta del endpoint /FormRecognition.

Respuesta tratada.

Por último, desarrollo el endpoint para crear un pedido en base a estos datos, que se encarga de dejarlo en nuestro sistema sin más intervención.

Endpoint que utiliza la respuesta tratada de Form Recognizer.
El pedido en nuestro sistema; se ve la referencia, el sinónimo del artículo del proveedor, las etiquetas y cantidades.

Recepción del material

Al llegar a nuestras instalaciones, a cada etiqueta que viene en el paquete se le pone una pegatina con un código de lote que utilizaremos para nuestros procesos internos. Este será el que identifique el material en fábrica y estará relacionado con el lote del proveedor.

Previamente se tenía que crear cada lote manualmente dando de alta una serie de datos sobre cada uno, proceso que resultaba tedioso y requería bastante tiempo.

Para ahorrar esto, tenemos un endpoint preparado para crear lotes de diferentes maneras. Una de ellas es a través de la etiqueta del proveedor, que relacionada con el pedido, nos da prácticamente toda la información que necesitamos. Este endpoint podemos atacarlo desde cualquier sitio, a través de una aplicación móvil, o de una página en nuestra intranet para hacer el proceso muy rápido. Esta web está desarrollada también en .NET6 con Blazor.

Web para crear el lote en base a esos 3 datos.

Conclusiones

Como hemos visto, utilizando diferentes tecnologías podemos optimizar mucho este proceso para minimizar la intervención de personas en él. Para ello el flujo que hemos seguido es:
> Power Automate recibe un correo y deja el documento en una librería de SharePoint
> Nuestro programa comprueba si hay documentos nuevos en ella para tratarlos.
> Azure Form Recognizer analiza el documento y nos devuelve la información que reconoce en él.
> Tratamos este JSON complejo para extraer la información relevante que buscamos.
> Con esta información automatizamos la introducción de pedidos en nuestro sistema.
> Recepcionamos el material con mucho menos esfuerzo a través de nuestra web Blazor o desde un móvil.

Sin esta automatización, el proceso anteriormente requería estar atentos al correo, generar el pedido manualmente y posteriormente los lotes. Actualmente el sistema es prácticamente autónomo y sólo tenemos que recepcionar el material con una inversión de tiempo mínima. Podríamos decir que el proveedor al enviarnos el correo está introduciendo la información necesaria en nuestro sistema.

Con una consulta rápida a nuestra base de datos, vemos que llevamos cerca de 50 pedidos de este tipo gestionados en los 4 primeros meses del año. Extrapolándolo al ejercicio completo, podemos estimar una gestión de entre 100 y 150 recepciones de este tipo por año. Si ahorramos entre media y una hora por cada una, tenemos entre 50 y 150 horas de ahorro de tiempos de personas, es decir, entre 6 y 18 días más de trabajo disponible.