ERP en Cobol: cómo automatizar con IA sin tocar el código
Tu ERP corre en Cobol y nadie se atreve a tocarlo. No hace falta migrarlo para usar IA: así se automatiza el trabajo manual que ocurre alrededor, sin tocar código.
El ERP antiguo que no se deja tocar tiene una versión más extrema: el que ni siquiera corre en un sistema comercial, sino en Cobol escrito a medida hace treinta o cuarenta años. Suele vivir en un mainframe o en un servidor que nadie de la empresa actual ha visto abrir. La persona que lo programó está jubilada, o algo peor.
Y aun así funciona. Factura, gestiona stock, cierra el mes. Nadie lo toca porque nadie sabe exactamente qué pasaría si se tocara, y esa incertidumbre pesa más que cualquier ventaja de cambiarlo.
Por qué no hace falta migrarlo para usar IA
Si el ERP en Cobol sigue funcionando, no hace falta migrarlo para usar IA. La IA se conecta a los exports que ya genera el sistema (ficheros, pantallas, informes) y automatiza el trabajo manual que ocurre alrededor: introducir pedidos, cruzar datos entre sistemas, montar informes. Migrar solo compensa si el propio Cobol es el cuello de botella, no la falta de IA.
Todo lo que se escribe en español sobre Cobol asume lo contrario: que el objetivo final es traducirlo, envolverlo en microservicios o sustituirlo, y que la única pregunta es el cómo y el cuándo. Tiene sentido si quien escribe es el equipo que vende la migración. Pero la mayoría de las empresas con un Cobol así no necesitan resolverlo. Necesitan dejar de perder horas al día puenteándolo a mano.
Por qué el Cobol sigue vivo en la industria
No es tozudez. Un sistema que lleva treinta años en producción ha absorbido treinta años de excepciones: el cliente que factura distinto, el descuento que solo se aplica los martes, la regla fiscal de 2003 que nadie recuerda por qué existe pero que sigue siendo correcta. Hemos visto Cobol con condiciones de ese tipo para un solo cliente, metidas hace una década y que nadie se atreve a tocar porque no hay forma de comprobar qué más depende de ellas. Reescribir eso no es traducir código: es reconstruir un conocimiento que en muchos casos ya no está escrito en ningún sitio, solo en el propio programa.
Los proyectos de modernización de Cobol que sí tienen sentido (banca, seguros, administración pública, logística) empiezan documentando qué hace el sistema real antes de tocar nada. La IA ha comprimido esa fase de meses a semanas, pero sigue siendo un proyecto deliberado, con presupuesto y riesgo reales. La mayoría de las empresas industriales que conocemos no está en ese caso: su Cobol no les falla, simplemente no habla con nada más.
Las tres formas de sacarle datos a un Cobol sin tocarlo
1. Automatizar la pantalla (screen scraping / RPA de terminal)
Cuando el Cobol solo se opera por una pantalla de texto (el terminal verde de toda la vida), se puede automatizar esa misma pantalla: un proceso que teclea y lee exactamente igual que la persona que hoy lo hace a mano. Es la vía más rápida cuando no hay ninguna otra salida, y también la más frágil: si alguien cambia una pantalla o el orden de un campo, la automatización se rompe con ella.
2. El export periódico, la vía menos elegante y más subestimada
Casi todo Cobol que lleva décadas en producción ya genera algún volcado: un listado que imprime cada noche, un fichero plano que sube a otro sistema, un informe que alguien exporta cada mañana. Por ejemplo, el informe de stock que cada mañana alguien exporta y pega a mano en un Excel para que lo vea el equipo comercial. Eso ya es una integración. Solo falta que lo recoja un proceso automático en lugar de una persona que lo copia a mano en otro sitio.
3. El fichero plano como contrato estable
Cuando ni la pantalla ni el export existente bastan, la vía más robusta suele ser pedir al propio Cobol (o a quien lo mantiene) que genere un fichero plano con un formato fijo y documentado (un CSV, un fichero de ancho fijo) en un intervalo conocido. Es la vía menos vistosa y también la más estable: cambia menos que una pantalla y no depende de que el sistema exponga nada que no tenía previsto exponer.
| Vía | Qué exige | Fragilidad | Cuándo aplica |
|---|---|---|---|
| Automatizar la pantalla | Ningún cambio en el Cobol | Alta — se rompe si cambia la pantalla | No hay ningún otro punto de salida |
| Export periódico existente | Nada, ya existe | Media — depende de que nadie lo desactive | El sistema ya genera un volcado que alguien recoge a mano |
| Fichero plano a medida | Un cambio pequeño y puntual en el Cobol, pactado una vez | Baja — formato fijo y documentado | Hay margen para pedir un cambio mínimo y quien mantiene el sistema colabora |
Las tres tienen algo en común: ninguna reescribe una línea de la lógica de negocio que lleva treinta años funcionando. Solo le dan una salida.
Cuándo SÍ hace falta migrar (y cuándo es una excusa para no decidir)
Migrar tiene sentido en pocos casos concretos: cuando cada vez cuesta más encontrar a alguien que sepa mantener el Cobol, cuando el propio hardware donde corre está descatalogado y el fabricante ya no da soporte, o cuando el sistema de verdad no aguanta el volumen actual y frena la operación. Ahí el problema es el Cobol en sí, y automatizar alrededor solo pospone lo inevitable.
Fuera de esos casos, “primero habría que migrarlo” suele ser otra cosa: una forma cómoda de aplazar la decisión sin decir que da miedo tocarlo. La pregunta que separa un caso del otro es simple: ¿el Cobol os falla a vosotros, o solo os falta conectarlo con el resto? Si es lo segundo, rodearlo cuesta semanas. Migrarlo, años.
Si no sabes cuál de los dos casos es el tuyo, eso es justo lo que responde un diagnóstico de procesos en tres semanas: qué exporta ya tu sistema, qué le falta y por dónde conviene entrar sin tocarlo. Lo firma quien después lo construye.
Y si el Cobol no es tu caso pero sí un ERP moderno que tampoco se deja tocar, la vía es la misma: está explicada en cómo integrar IA con un ERP antiguo sin cambiar de sistema.
Escrito por Daniel Magarzo, CTO de Made to Scale, que se dedica a integrar estos sistemas.