Qué proceso industrial automatizar primero y cómo elegirlo

Cuando una empresa industrial empieza a explorar la IA aparecen decenas de ideas: predecir averías, consultar documentación, preparar informes, revisar calidad o conectar sistemas. La dificultad no está en ampliar la lista, sino en descartar hasta encontrar un primer proceso que pueda mejorar y medirse.

Un buen primer proyecto no es necesariamente el más llamativo ni el que promete el mayor ahorro teórico. Debe reunir tres condiciones: resolver un problema relevante, poder ponerse a prueba con el entorno actual y producir evidencia suficiente para decidir el siguiente paso.

Empezar por procesos, no por herramientas

Antes de comparar tareas, necesitamos entender una empresa que está cambiando. Puede estar migrando de ERP, sustituyendo la plataforma de compras o reorganizando quién mantiene la información. Esos cambios condicionan el alcance: un cuello de botella actual puede desaparecer con una funcionalidad prevista, o trasladarse al sistema nuevo.

La selección empieza por conocer el entorno de partida y el previsto. Qué herramientas seguirán, cuáles van a retirarse, cuándo estarán disponibles y qué responsables pueden confirmar esas decisiones. Construir una integración sobre una plataforma que se sustituirá pronto puede exigir rehacer trabajo; esperar sin analizarlo también puede mantener un problema importante durante meses.

No proponemos paralizar todo proyecto durante una migración. Proponemos separar las capacidades reutilizables de las dependencias temporales y comprobar si el nuevo sistema resolverá realmente el problema. Tener prevista una funcionalidad no equivale a que esté implantada y utilizada.

«Implantar IA en calidad» no define un proyecto. «Reducir el tiempo dedicado a reunir evidencias para las no conformidades de una línea» sí se acerca a uno.

Para convertir una idea en candidato, concretamos:

• Quién realiza hoy el trabajo.
• Qué evento lo inicia y cuándo termina.
• Cuántos casos se procesan.
• Qué información entra y de dónde procede.
• Qué decisión o resultado debe producirse.
• Cómo se comprueba que ese resultado es correcto.
• Qué sucede cuando el caso no sigue el camino habitual.

Si no podemos dibujar el proceso actual, todavía no podemos estimar el beneficio de automatizarlo.

Crear un inventario corto de oportunidades

Una sesión con operaciones, calidad, ingeniería y administración suele producir más ideas de las que se pueden atender. Para evitar un catálogo infinito, pedimos a cada equipo procesos que presenten señales observables:

• El mismo dato se copia entre herramientas.
• Se buscan documentos o antecedentes varias veces por semana.
• Se redactan documentos a partir de fuentes repetidas.
• Hay una cola de trabajo que crece en determinados periodos.
• El experto revisa muchos casos sencillos para encontrar unos pocos complejos.
• Los errores se descubren tarde porque la información está fragmentada.

Después describimos cada candidato en una sola frase: verbo, objeto, usuario y resultado. Por ejemplo, «extraer y validar los datos de pedidos recibidos por correo antes de registrarlos en el ERP».

La matriz para priorizar el primer proceso

En nuestra evaluación, tres variables ayudan a abrir la discusión: criticidad, volumen y profundidad. La criticidad describe las consecuencias de un error o interrupción. El volumen describe cuántas veces ocurre la tarea. La profundidad representa el esfuerzo y la complejidad de cada ejecución: fuentes, pasos, decisiones y detalle requerido.

Una tarea breve y poco frecuente puede ofrecer poco retorno. Un flujo profundo y recurrente puede consumir mucha capacidad, aunque ocupe a varios equipos en intervalos pequeños. Pero la criticidad no es un multiplicador de prioridad automático: también puede exigir empezar con revisión y sin acciones autónomas.

Puntuamos cada criterio de 1 a 5. La cifra no sustituye la discusión, pero obliga a utilizar las mismas preguntas para todos los candidatos.

Criterio	1 punto	5 puntos
Impacto	Ahorro o mejora marginal	Libera muchas horas o reduce un problema costoso
Frecuencia	Casos esporádicos	Volumen semanal suficiente para aprender
Estabilidad	Cada caso sigue un recorrido distinto	Pasos y salidas reconocibles
Datos	Inaccesibles o sin propietario	Localizables, utilizables y con responsable
Verificabilidad	El resultado depende de una opinión difícil de comparar	Existe evidencia o criterio para comprobarlo
Integración	Sistemas cerrados o proceso sin punto de entrada	Lectura y escritura mediante interfaces viables
Riesgo controlable	Un error produce consecuencias graves y difíciles de contener	Se puede revisar, revertir o limitar el alcance
Adopción	No existe responsable ni tiempo para probar	El equipo afectado participa y tiene un dueño operativo

Para facilitar la comparación, puede calcularse una puntuación sobre 40. No recomendamos decidir únicamente por el total. Datos, verificabilidad y riesgo funcionan también como condiciones mínimas.

La puntuación es una herramienta ilustrativa de comparación, no una fórmula validada ni un método obligatorio de Feynman. En procesos críticos, un total alto no compensa un control insuficiente. Tampoco la profundidad se mide solo en documentos o páginas: importa el trabajo que exige producir y comprobar el resultado.

Cómo influye una migración de ERP o compras

Para cada candidato que dependa de un sistema en sustitución, preguntaríamos si el cambio previsto elimina la tarea, modifica sus datos o solo cambia la interfaz. Conviene contrastarlo con el responsable de la migración y con quienes realizan el trabajo.

Situación	Decisión posible	Qué validar antes
La nueva plataforma incluye el flujo necesario	Probar primero esa capacidad	Alcance real, fecha y adopción por el equipo
El problema seguirá, pero cambiará la interfaz	Diseñar reglas reutilizables y aplazar el conector	Datos y mecanismo de acceso del sistema nuevo
La migración tardará y el coste actual es relevante	Acotar una solución temporal	Beneficio durante su vida útil y coste de retirada
El calendario o los datos no están claros	Priorizar un proceso menos dependiente	Que su piloto pueda medirse sin esas incertidumbres

Esta revisión reduce el riesgo de automatizar un síntoma que otro proyecto ya está abordando. También puede revelar que la migración necesita mejorar los datos antes de que una automatización tenga sentido. Las reglas, casos de prueba y conocimiento del proceso pueden seguir siendo útiles aunque cambie la herramienta.

Utilizar filtros antes de comparar puntos

Descartaríamos o reformularíamos un candidato si:

• No existe un responsable operativo.
• No se puede obtener una muestra representativa.
• Nadie puede definir qué significa un resultado correcto.
• El piloto necesita reemplazar primero varios sistemas centrales.
• El coste de un error no puede limitarse mediante revisión o alcance.
• Solo ocurren unos pocos casos y habría que esperar meses para medir.

Estos filtros evitan que una puntuación alta de impacto o visibilidad oculte una ejecución inviable.

Ejemplo de comparación

Supongamos que una empresa valora tres candidatos. Las cifras son hipotéticas y solo muestran el método.

Criterio	Pedidos de correo a ERP	Consulta de manuales	Predicción de averías
Impacto	4	3	5
Frecuencia	5	4	2
Estabilidad	4	3	2
Datos	4	3	2
Verificabilidad	5	4	2
Integración	3	4	2
Riesgo controlable	4	4	2
Adopción	4	4	3
Total	33	29	20

La predicción de averías promete un impacto elevado, pero todavía faltan datos, frecuencia de eventos y una forma clara de evaluar el piloto. El traspaso de pedidos ofrece más casos, reglas conocidas y un resultado comprobable. Podría ser mejor primer proyecto aunque tenga menos atractivo tecnológico.

En este escenario, el siguiente paso sería mapear el flujo para integrar el ERP con el resto de sistemas. Si la consulta documental fuese prioritaria, habría que diseñar un asistente de IA con fuentes y criterios de evaluación.

Ejemplo hipotético: reunir datos para un informe

Una empresa prepara documentos técnicos con mediciones, hojas de cálculo y antecedentes dispersos. Cada entrega exige localizar fuentes, transcribir datos y comprobar versiones. La estructura final se repite, pero existen variantes según la instalación y el servicio ofrecido.

Es un ejemplo hipotético, no la descripción del flujo de un cliente. Lo priorizaríamos si la preparación consume muchas horas, el volumen permite evaluar suficientes casos y las ramificaciones pueden formalizarse. La primera automatización podría reunir evidencias y preparar apartados, manteniendo las conclusiones para revisión técnica.

La criticidad define dónde termina el alcance. Si un dato incompleto afecta a una conclusión relevante, el sistema marca el apartado pendiente. No rellena el hueco con una suposición para entregar un documento que parezca terminado. La guía de automatización de informes técnicos desarrolla esos controles.

Un segundo candidato podría ser visibilidad de solicitudes entre fábrica y compras. Si la empresa está sustituyendo la plataforma de compras, comprobaríamos primero qué seguimiento ofrecerá la nueva. La necesidad puede ser prioritaria, pero el conector previsto para retirarse pronto quizá no sea la mejor primera inversión.

Ambos candidatos responden a trabajo repetitivo. La decisión depende de qué puede probarse ahora, qué seguirá siendo necesario y qué resultado puede comprobar el equipo. La comparación no exige afirmar que el trabajo manual ya no tenga sentido en ninguna circunstancia: exige identificar qué parte concreta puede reducirse con calidad y control.

Estimar el retorno con el entorno previsto

Para cada candidato calculamos primero el coste actual:

casos al mes × minutos de trabajo por caso × coste por minuto

Después añadimos esperas, correcciones y coste de errores cuando puedan medirse. La estimación del proceso futuro debe incluir revisión humana, excepciones, infraestructura y mantenimiento.

Un ejemplo hipotético: 400 casos mensuales requieren 12 minutos cada uno. Son 80 horas de trabajo. Si el piloto reduce el trabajo medio a 5 minutos, libera unas 47 horas antes de descontar operación y mantenimiento. La cifra debe comprobarse con una muestra, no presentarse como ahorro garantizado.

También conviene valorar capacidad, no solo reducción de costes. Procesar antes un pedido, responder a una incidencia o entregar un informe puede mejorar plazos sin reducir plantilla.

Cuando un sistema va a cambiar, añadiríamos el coste de adaptación o retirada. Un ahorro anual teórico no representa el retorno de una integración que solo estará operativa tres meses. La estimación debe reflejar su vida útil prevista y la incertidumbre del calendario.

Diseñar un piloto que responda una pregunta

El piloto no debería demostrar que la tecnología funciona. Debe responder una pregunta empresarial concreta, por ejemplo: «¿Podemos reducir a la mitad el tiempo humano por pedido manteniendo el nivel de errores actual?».

Un alcance útil especifica:

• Un proceso y una familia de casos.
• El equipo y responsable participantes.
• Las fuentes y sistemas permitidos.
• El volumen o periodo de evaluación.
• Las métricas de tiempo y calidad.
• Los casos que siempre requieren revisión.
• Las condiciones para continuar, corregir o detener.

Durante las primeras iteraciones, el sistema puede trabajar en paralelo sin escribir en los sistemas reales. Así se comparan sus propuestas con el resultado aprobado antes de aumentar la autonomía.

Las condiciones de continuidad se acuerdan antes de probar. En un flujo documental, podrían incluir menos tiempo total, referencias que permiten revisar las afirmaciones y ausencia de errores bloqueantes en la muestra evaluada. Eso no garantiza ausencia de errores futuros: define qué evidencia falta para ampliar el alcance.

Si el resultado exige muchas correcciones, puede ser necesario mejorar fuentes o reducir la familia de casos. Si desaparece la necesidad durante una migración, detener el piloto puede ser la decisión correcta. Continuar por haber invertido esfuerzo no convierte una tarea obsoleta en una oportunidad.

Medir las excepciones desde el primer día

Una media de ahorro oculta dónde se concentra el trabajo. Registramos qué porcentaje sigue el flujo previsto, qué excepciones aparecen y cuánto cuesta resolverlas.

Las excepciones suelen revelar tres posibilidades:

1. Falta una regla que puede formalizarse.
2. El dato de origen necesita mejorar.
3. El caso requiere criterio y debe permanecer en manos del equipo.

El objetivo no es eliminar todas. Es conseguir que el sistema resuelva lo repetible y entregue las demás con el contexto necesario.

Qué resultado esperar del primer proyecto

Al terminar, la empresa debería disponer de algo más valioso que una demostración:

• Una línea base del proceso anterior.
• Resultados de calidad y tiempo sobre casos reales.
• Un mapa de excepciones.
• Un responsable operativo y un procedimiento de revisión.
• Una estimación actualizada del retorno.
• Una decisión explícita sobre ampliar, corregir o parar.

En Nabla Wind Hub, automatizar la generación de informes técnicos extensos permitió ahorrar más de 1.000 horas de ingeniería. El dato demuestra el potencial de un proceso documental bien elegido, pero no permite asumir el mismo resultado en otra empresa. Cada caso necesita su línea base y su propia validación.

Si todavía no existe un inventario comparable, el diagnóstico de madurez en IA industrial ayuda a detectar oportunidades en integración, datos, adopción, gobernanza y medición. El resultado puede convertirse después en una matriz como esta y en un primer alcance de 90 días.