Integración de sistemas: cuando el problema no es automatizar
Integrar es hacer que dos sistemas intercambien datos de forma confiable y repetible. Automatizar es reducir el esfuerzo humano de una tarea. Cuando el trabajo manual consiste en copiar información de una pantalla a otra, el problema es de integración, y automatizar la copia solo esconde la causa.
A continuación: cómo distinguir los dos problemas, qué opciones de integración existen, cuándo cada una es la correcta y qué deuda genera elegir mal.
Hay un patrón que se repite en los diagnósticos de procesos: alguien describe una tarea que consume horas y, al detallarla, resulta que consiste casi por completo en tomar un dato de un sistema y escribirlo en otro.
La reacción instintiva es automatizar esa transcripción. Funciona, y deja intacta la razón por la que existía: dos sistemas que deberían conversar y no lo hacen.
Cómo distinguir los dos problemas
La pregunta que separa uno del otro es sencilla: si los sistemas intercambiaran datos solos, ¿quedaría trabajo humano? Si la respuesta es no, el problema es de integración. Si queda criterio, validación o decisión, hay además un problema de automatización.
La distinción importa porque las soluciones tienen vidas útiles muy distintas. Una integración bien hecha sobrevive a cambios de interfaz; una automatización que opera sobre pantallas se rompe cuando alguien mueve un botón.
Las opciones, de más estable a más frágil
API nativa. Si ambos sistemas exponen una interfaz, es el camino correcto: estable, documentado y barato de mantener. Debería descartarse solo cuando no existe.
Intercambio de archivos. Un fichero depositado en un lugar acordado, con un formato fijo. Poco elegante y sorprendentemente duradero; sigue siendo la forma en que se integran muchos sistemas contables y bancarios en la región.
Base de datos intermedia. Un espacio común donde uno escribe y otro lee. Funciona, y crea un acoplamiento que hay que gobernar: dos sistemas que dependen de la misma tabla ya no se pueden cambiar por separado.
Automatización sobre la interfaz. El robot hace lo que haría una persona. Es la respuesta correcta cuando no hay ninguna de las anteriores, y deuda innecesaria cuando sí la había.
Cuándo la opción frágil es la correcta
Conviene decirlo sin rodeos, porque el discurso habitual la descarta por principio. Automatizar sobre la interfaz es la decisión acertada cuando el sistema es de un tercero que no expone nada, cuando va a ser reemplazado en un plazo corto y no justifica inversión, o cuando el volumen es tan bajo que construir una integración cuesta más de lo que ahorra.
Lo que la convierte en un error no es la técnica, es usarla por defecto. La pregunta que hay que poder responder es: ¿existía una API y no la usamos? Si la respuesta es sí, se está contrayendo deuda a sabiendas.
La deuda que genera elegir mal
Una integración por interfaz acumula tres costos que no aparecen en la estimación. Se rompe con cada cambio visual del sistema de origen. Necesita credenciales que rotan. Y no deja rastro útil: cuando falla, hay que reconstruir qué pasó a partir de capturas de pantalla en lugar de un registro.
Ese último punto pesa más de lo que parece en operaciones auditadas. Un intercambio por API deja evidencia de qué se envió y cuándo; un robot que llenó un formulario, mucho menos.
El orden que evita rehacer
Cuando un proceso necesita integración y automatización a la vez, el orden importa. Integrar primero reduce el alcance de lo que hay que automatizar, y a veces lo elimina: buena parte de las tareas candidatas desaparecen solas cuando los datos dejan de moverse a mano.
Hacerlo al revés produce una automatización dimensionada para un problema que después cambia. El robot que copiaba entre dos pantallas queda sin función el día que se construye la integración, y ese trabajo se descarta completo.
La excepción razonable es el plazo: si la integración depende de un tercero y va a tardar meses, automatizar mientras tanto es una decisión legítima — siempre que se tome sabiendo que es temporal y se registre como tal, no que se descubra dos años después.
Cómo se decide con evidencia
Con un inventario de los intercambios que hoy hacen personas: qué dato se mueve, desde dónde, hacia dónde, con qué frecuencia y qué interfaces existen en cada extremo. Es una tabla, no un proyecto, y responde la mayoría de las preguntas de arquitectura.
Ese levantamiento es parte de un assessment de automatización de procesos, que evalúa la viabilidad técnica de cada candidato además de su volumen. De ahí sale qué pasa a automatización y qué debería resolverse integrando.
El caso de negocio se calcula con costos locales: una hora de transcripción ahorrada no vale lo mismo en Bogotá, en Ciudad de México o en una casa matriz europea.
Preguntas frecuentes
¿Cuándo el problema es de integración y no de automatización?
Cuando el trabajo manual consiste en mover datos de un sistema a otro y no quedaría tarea humana si los sistemas se comunicaran solos. Si además hay criterio, validación o decisión, entonces hay ambos problemas.
¿Es malo automatizar sobre la interfaz de un sistema?
No en sí mismo. Es la respuesta correcta cuando no hay API disponible, cuando el sistema será reemplazado pronto o cuando el volumen no justifica una integración. Es deuda innecesaria cuando existía una interfaz y no se usó.
¿El intercambio de archivos sigue siendo válido?
Sí. Es poco elegante y muy duradero, y sigue siendo la forma en que se integran muchos sistemas contables y bancarios de la región. Un formato fijo y un lugar acordado resuelven más de lo que su reputación sugiere.
¿Qué se necesita para decidir?
Un inventario de los intercambios que hoy hacen personas: qué dato se mueve, entre qué sistemas, con qué frecuencia y qué interfaces existen en cada extremo. Es una tabla, y responde la mayoría de las preguntas.
