Cuando una empresa tiene un ERP a medida, cada nueva necesidad parece terminar en el mismo sitio: otro botón, otra pantalla y más código dentro de la aplicación. En un sistema maduro esa estrategia aumenta la dependencia y hace que cualquier cambio cueste más de probar.
Caso real anonimizado. El flujo se construyó alrededor de una aplicación industrial Java. Los identificadores y resultados de las imágenes son ficticios y sirven únicamente para explicar el proceso.
La decisión clave: no meterlo todo en el ERP
Los partes de trabajo ya se gestionaban en la aplicación. Lo que necesitábamos era coordinar tareas auxiliares: comprobar datos, calcular valores, generar un resumen, actualizar estados y avisar cuando faltaba información.
En vez de ampliar el núcleo Java con cada paso, utilizamos n8n como capa de orquestación. El ERP sigue siendo la fuente operativa; el flujo recibe información normalizada y ejecuta acciones alrededor.
Cómo se diseñó el flujo
- Recepción. El ERP entrega los datos del parte mediante un punto de integración controlado.
- Normalización. Se convierten formatos y nombres para que las etapas siguientes trabajen con una estructura estable.
- Validación. Se comprueban campos obligatorios y coherencia básica.
- Procesamiento. Se calculan horas o cantidades y se genera el documento correspondiente.
- Actualización y aviso. El resultado vuelve al sistema y se notifica al responsable cuando es necesario.
La rama de error es tan importante como la de éxito. Un parte incompleto no debe desaparecer ni continuar con valores inventados: queda registrado y pasa a revisión.
Por qué n8n encajó en este caso
n8n permite ver el proceso completo, ejecutar pasos por separado y revisar qué ocurrió en cada intento. También facilita incorporar más adelante correo, almacenamiento, APIs u otras herramientas sin tener que recompilar la aplicación de escritorio.
Eso no significa que cualquier lógica deba trasladarse a n8n. Las reglas que forman parte del corazón del ERP siguen perteneciendo al ERP. La automatización se utilizó para coordinar tareas, no para duplicar la lógica del negocio.
Qué se consiguió
El sistema ganó una vía de evolución menos invasiva. Se pudieron automatizar procesos auxiliares y dejar trazabilidad de sus ejecuciones sin convertir cada mejora en una modificación profunda del ERP.
No publicamos un porcentaje de tiempo ahorrado porque no se realizó una medición antes y después. El resultado comprobable es arquitectónico y operativo: existe un flujo visible, reejecutable y separado del núcleo antiguo.
Cuándo no usaríamos este enfoque
- Cuando el proceso necesita respuesta en tiempo real estricto.
- Cuando la lógica es inseparable de una transacción crítica del ERP.
- Cuando no existe una interfaz estable para leer o escribir datos.
- Cuando el coste de mantener otra herramienta supera el valor del flujo.
Preguntas frecuentes
¿n8n sustituye a un ERP?
No. Coordina aplicaciones y tareas. Puede reducir trabajo manual y conectar sistemas, pero no reemplaza por sí solo la gestión de pedidos, producción, clientes o facturación.
¿Qué ocurre si el flujo falla?
Debe existir registro de ejecución, reintento controlado y una salida de revisión. Automatizar sin diseñar el error solo hace que los fallos sean más rápidos.
En automatización de procesos explicamos cómo empezar por un flujo pequeño y comprobable antes de ampliar el alcance.