La matriz para decidir qué proceso industrial automatizar primero

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

«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

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.

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 eliminar el re-tecleo entre ERP, Excel y correo. Si la consulta documental fuese prioritaria, habría que diseñar un asistente de IA con fuentes y criterios de evaluación.

Estimar el retorno sin inventar precisión

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.

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.

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.