Cómo automatizar el control documental de calidad en industria: certificados, especificaciones y no conformidades

El certificado está guardado. Nadie puede demostrar rápidamente a qué lote corresponde.

La escena es habitual en entornos industriales con proveedores y documentación técnica. Llega un PDF por email, otro se descarga de un portal, un tercero se guarda en una carpeta compartida y alguien marca en una hoja que “el certificado está recibido”.

Meses después aparece la pregunta importante: ¿Ese certificado era realmente el del lote que se recibió? ¿Qué especificación era aplicable en ese momento? ¿Faltaba algún campo? ¿Quién revisó la discrepancia? ¿Se sustituyó después por una nueva versión?

Encontrar el archivo no resuelve ninguna de esas preguntas. El valor aparece cuando el documento está conectado con el objeto operativo que le da significado: proveedor, material, lote, recepción, pedido, producto, equipo, inspección u otro elemento definido por la empresa.

Esta pieza se centra en esa continuidad. No en cómo automatizar una fábrica completa, ni en cómo contabilizar facturas, ni en cómo implantar una norma ISO. Para el flujo transaccional de pedidos, albaranes y facturas hacia sistemas de gestión, el enfoque es distinto y se desarrolla en la guía sobre automatización de documentos hacia ERP.

La Cadena de evidencia de calidad: del documento esperado al cierre trazable

Para diseñar este proceso proponemos una estructura editorial propia de Yarvia. No es un estándar universal ni obliga a utilizar diez estados en todos los casos. Su función es hacer visible qué evidencia falta en cada momento.

La idea importante es que “recibido” no salta directamente a “correcto”. Entre ambos estados hay identidad, relación, completitud, criterio y responsabilidad.

Documento recibido, documentación completa y producto conforme no son lo mismo

La primera capa y buena parte de la segunda pueden automatizarse de forma sólida con integraciones, reglas e IA documental. La tercera exige más cuidado.

Si la empresa ha modelado de forma inequívoca un criterio técnico —por ejemplo, una característica, unidad, método y tolerancia concretos— una regla puede ejecutar una comparación. Si la decisión depende de contexto, una excepción técnica, métodos no equivalentes o interpretación profesional, la automatización debería preparar la revisión, no inventar la decisión.

Qué documentos pueden entrar en un circuito de calidad

No existe una lista universal. Dependerá del sector, producto, proveedor, contrato, cliente y sistema de gestión de cada empresa. Algunos ejemplos habituales son:

• Certificados de análisis o CoA cuando el proceso los utilice.
• Certificados de conformidad o CoC cuando correspondan.
• Informes de ensayo o inspección.
• Especificaciones de material o producto.
• Fichas técnicas.
• Certificados o informes remitidos por proveedores.
• Documentación vinculada a lotes, números de serie o equipos.
• Certificados de calibración o verificación cuando formen parte del mismo circuito.

CoC suele utilizarse como abreviatura de Certificate of Conformity, o certificado de conformidad. El nombre concreto y su función deben leerse siempre dentro del proceso real de la empresa.

El error sería diseñar primero una automatización “para certificados” y preguntar después qué significaba cada certificado. El orden correcto es el contrario.

Antes de leer documentos, el sistema debe saber qué documento espera

Una bandeja de entrada puede decir qué archivos llegaron. No puede decir qué falta si nadie ha definido previamente qué debía llegar. Esa lógica debe estar conectada con el proceso de compras y aprovisionamiento cuando el requisito nace de proveedor, pedido o recepción, sin convertir el control de calidad en una copia del proceso de compras.

Para cada combinación relevante, conviene poder responder:

• Qué documento se espera.
• Para qué proveedor, material, familia o producto.
• En qué evento se espera: pedido, recepción, lote, inspección, expedición u otro.
• Quién debe aportarlo.
• Qué campos mínimos debe contener.
• Qué versión o vigencia debe aplicar cuando proceda.
• Qué condición permite continuar.
• Qué ocurre si falta.
• Quién puede resolver o cerrar la excepción.

Identificar proveedor, material, lote y recepción antes de validar nada

En muchos proyectos de automatización documental se pone toda la atención en “leer bien el PDF”. En calidad industrial, el problema puede estar un paso antes: leer perfectamente un certificado que pertenece a otro lote sigue siendo un error.

El sistema puede utilizar referencias como código de proveedor, material o SKU, lote, número de serie, pedido, recepción, fecha, número de certificado, planta u orden de inspección. No todos los documentos contendrán todos esos datos.

Cuando existen identificadores estables, deben tener prioridad frente a coincidencias aproximadas. Un número de lote puede no ser único globalmente. Un nombre de proveedor puede tener variantes. Un material puede aparecer con abreviaturas diferentes.

La IA puede ayudar a proponer equivalencias semánticas cuando el documento no utiliza exactamente el mismo texto que el maestro del ERP. Pero esa propuesta es un candidato. Si existen varias coincidencias plausibles, la arquitectura debe aplicar reglas adicionales o pedir revisión.

También conviene conservar cómo se realizó la relación: coincidencia exacta, regla, candidato validado o decisión humana. Esa información permite investigar errores más tarde.

Extraer no es validar: OCR, Document AI y decisión de calidad

Conviene separar varias funciones porque suelen venderse como si fueran una sola.

OCR significa reconocimiento óptico de caracteres. Document AI es un término utilizado para soluciones que combinan OCR, modelos de extracción, clasificación y otras técnicas para trabajar con documentos de forma más estructurada.

Un confidence score o puntuación de confianza puede indicar cuánto “cree” un extractor que ha leído correctamente un campo. No significa que el material sea conforme. Tampoco existe un umbral universal que sirva para todos los campos y procesos.

Dónde puede ayudar la IA y qué conviene resolver con reglas o APIs

Las reglas son preferibles cuando la condición puede expresarse de forma exacta: existe o no existe un documento, un campo es obligatorio, una fecha está vencida, una versión coincide, una unidad puede transformarse mediante una conversión aprobada o un valor está dentro de un rango definido.

Una API —interfaz que permite que dos sistemas intercambien datos de forma estructurada— es adecuada para consultar maestros, lotes, recepciones, pedidos, requisitos, estados o registros de calidad y para escribir resultados controlados.

Y una persona de calidad debe conservar el control cuando el criterio no está modelado, existe ambigüedad técnica, hay que aceptar una desviación, cambiar un criterio o decidir si una incidencia merece una no conformidad formal.

Especificaciones y versiones: “la última” no siempre es la que corresponde

Una especificación puede cambiar. El sistema debe saber contra qué versión corresponde revisar un documento concreto.

En algunos procesos será la versión vigente en la fecha de recepción; en otros puede depender del pedido, contrato, lote, cliente o decisión interna. Por eso conviene registrar, cuando proceda, el identificador de especificación, revisión, fecha de vigencia, objeto al que aplica y fuente autorizada.

Una automatización mal diseñada puede comparar un certificado histórico con la especificación actual simplemente porque es la más reciente en una carpeta. Eso puede producir una discrepancia artificial.

La empresa debe decidir cuál es la fuente de verdad de la especificación. No tiene por qué ser siempre el ERP.

Qué es un CoA y cuándo sus valores pueden compararse automáticamente

CoA son las siglas de Certificate of Analysis, en español Certificado de Análisis. Es un documento utilizado en determinados sectores y procesos para comunicar resultados de análisis, ensayos o características de un material o producto. No todas las industrias utilizan el mismo formato ni los mismos contenidos.

Un CoA puede incluir, por ejemplo, una característica, el resultado medido, la unidad, el método de ensayo y límites o referencias. Microsoft Dynamics 365 documenta la generación de certificados de análisis a partir de órdenes de calidad, mientras SAP documenta certificados asociados a resultados de inspección y lotes; son ejemplos de cómo plataformas industriales pueden representar este tipo de información, no una definición universal del documento.

La comparación automática solo es razonable cuando la automatización puede identificar sin ambigüedad:

• Qué característica se está evaluando.
• Qué valor original se ha extraído.
• Qué unidad utiliza.
• Qué método corresponde cuando el método afecta a la comparación.
• Qué especificación y versión son aplicables.
• Qué tolerancia o criterio exacto debe utilizarse.

Si, por ejemplo, el certificado utiliza una unidad distinta, la normalización puede convertirla únicamente cuando existe una regla aprobada. Si dos métodos no son equivalentes o la aceptación depende de contexto técnico, la automatización debe escalar.

Para auditoría puede ser útil conservar tanto el valor original como el normalizado. Así se puede reconstruir qué leyó el sistema y qué transformación aplicó.

Falta documental, incidencia, discrepancia y no conformidad no son lo mismo

No toda incidencia documental debería convertirse automáticamente en una no conformidad. Esa decisión depende del sistema de gestión y de la política de calidad.

Cuando existe una excepción, el proceso debería registrar qué falta o discrepa, a qué objeto afecta, qué regla la originó, quién es responsable, qué queda bloqueado, qué acción se espera y qué evidencia permite cerrarla.

Una bandeja genérica de “pendientes de calidad” puede ocultar tanto trabajo como una carpeta desordenada si nadie es propietario de cada excepción.

Qué sistema manda en cada dato: ERP, QMS, DMS e integración explicados sin jerga

En una empresa industrial pueden convivir varios sistemas. La automatización funciona mejor cuando cada dato tiene una autoridad clara.

La pregunta práctica: ¿quién tiene autoridad sobre cada dato?

Un ejemplo: el ERP puede ser la fuente de verdad del lote recibido; el QMS, de la decisión de calidad; el DMS, del archivo y su versión; y la capa de integración, del proceso técnico que lleva la referencia de un sistema a otro.

No existe un reparto universal. Una empresa puede tener funciones de calidad dentro del ERP, otra utilizar un QMS independiente y otra gestionar determinados documentos en un DMS corporativo.

Esta separación evita preguntas peligrosas: “¿Cuál de los dos sistemas tiene la decisión correcta?”, “¿qué pasa si una no conformidad se cierra en uno pero queda abierta en otro?” o “¿qué especificación utilizó realmente la automatización?”.

Además, cuando se escriben datos en varios sistemas conviene utilizar identificadores estables, reconciliar errores y diseñar reintentos idempotentes. Idempotente significa que repetir una operación después de un fallo no debería crear duplicados ni aplicar dos veces el mismo efecto.

Los casos límite son donde se demuestra si la automatización está realmente bien diseñada

Un circuito documental puede funcionar perfectamente durante semanas y fallar justo en los casos que más tiempo consumen al equipo. Por eso el piloto no debería probar únicamente certificados limpios, proveedores conocidos y referencias exactas.

Hay situaciones especialmente útiles para comprobar el diseño:

• Certificado correcto enviado para otro lote.
• Proveedor correcto con material equivocado.
• Documento sin identificador de lote cuando ese dato es obligatorio.
• Mismo número de lote utilizado por proveedores diferentes.
• PDF escaneado con calidad insuficiente para extraer un campo crítico.
• Tabla con unidades distintas de la especificación.
• Certificado duplicado recibido por email y portal.
• Nueva versión del documento para el mismo lote.
• Especificación modificada después de fabricar o recibir el lote.
• Característica expresada mediante un sinónimo o abreviatura.
• Documento que parece un certificado, pero en realidad es una ficha comercial.
• QMS temporalmente no disponible cuando hay que registrar una excepción.

Estos casos ayudan a definir qué debe hacer el sistema cuando no puede continuar con seguridad. A veces será suficiente con dejar el documento pendiente de revisión. En otros casos habrá que solicitar una nueva evidencia, bloquear un estado concreto o crear una tarea para calidad.

La trazabilidad debe permitir reconstruir qué ocurrió

Cuando un documento termina aceptado, bloqueado o escalado, debería ser posible reconstruir el camino. Según la criticidad del proceso, puede ser útil conservar el documento original, el tipo detectado, los campos extraídos, el valor original y el normalizado, las reglas aplicadas, las comprobaciones automáticas, la intervención humana y los cambios posteriores.

En una empresa agroalimentaria, esa reconstrucción puede extenderse a la trazabilidad por lotes entre documentos, ERP y calidad, especialmente cuando hay que conservar relaciones entre recepciones, transformaciones, evidencias y expediciones.

Esto no implica guardar información sin límite. La trazabilidad debe diseñarse con proporcionalidad y evitando datos que no sean necesarios para investigar el proceso.

También conviene registrar la versión del extractor o modelo cuando un cambio técnico pueda modificar cómo se leen los documentos. Así, si de repente aumenta el número de incidencias, el equipo puede diferenciar un problema de proveedor de una regresión en la automatización.

Métricas para saber si el circuito documental funciona mejor

No hace falta atribuir a la automatización una reducción de defectos de producto para demostrar que el proceso documental ha mejorado.

Algunas métricas operativas útiles son:

• Documentos esperados frente a documentos recibidos.
• Documentos pendientes de relación con material, lote o recepción.
• Documentos incompletos o ilegibles.
• Tiempo desde recepción hasta disponibilidad para revisión.
• Backlog de revisión de calidad.
• Excepciones abiertas por motivo.
• Tiempo de resolución de excepciones.
• Duplicados recibidos por distintos canales.
• Reincidencias por proveedor, documento o requisito.
• Intervenciones humanas por tipo de motivo.
• Errores de extracción detectados en campos críticos.

Estas métricas ayudan a localizar fricción y carga manual. No deben convertirse en benchmarks inventados ni en promesas de calidad de producto.

Cómo empezar con un piloto sin intentar automatizar todos los certificados

El mejor perímetro inicial suele ser pequeño y verificable.

El éxito del piloto consiste en mejorar trazabilidad y reducir comprobaciones manuales repetitivas sin automatizar decisiones técnicas que todavía no están modeladas.

Qué revisaría Yarvia antes de automatizar este proceso

• Qué documentos se esperan realmente y por qué.
• Qué proveedores, materiales, lotes o recepciones deben relacionarse.
• Qué sistema tiene autoridad sobre cada dato.
• Qué campos puede extraer la IA y cuáles son críticos.
• Qué normalizaciones están aprobadas.
• Qué comprobaciones pueden convertirse en reglas deterministas.
• Qué decisiones deben permanecer en calidad.
• Qué excepciones existen hoy y cómo se resuelven.
• Qué documentos o estados se duplican entre sistemas.
• Qué trazabilidad necesita el equipo para reconstruir una decisión.

Si los certificados llegan por email, portales o carpetas y el equipo sigue comprobando manualmente a qué lote pertenecen, qué falta y qué debe revisarse, se puede mapear el circuito y decidir qué parte conviene resolver con extracción documental, reglas, integraciones o IA.

Revisar el circuito documental de calidad