La mayoría de las organizaciones medianas y grandes operan varios sistemas centrales adquiridos en momentos distintos a proveedores distintos. Un ERP concentra los datos financieros y de abastecimiento, un CRM registra las interacciones con los clientes y, en el sector salud, un sistema de información hospitalaria, conocido como HIS, gestiona historias clínicas, órdenes y facturación. Conectarlos rara vez es la parte más visible de un proyecto, pero con frecuencia decide si el proyecto termina a tiempo. Este artículo recoge los problemas que aparecen con más frecuencia y las prácticas que ayudan a reducirlos.

Por qué se retrasan los proyectos de integración

Las estimaciones de integración suelen ser optimistas porque el trabajo permanece oculto hasta que comienza. Hay cuatro causas que se repiten.

  • Campos sin documentar. Una tabla tiene una columna usada para un fin que nadie recuerda, y la única forma de conocer su significado es preguntar a la persona que la configuró hace años.
  • Dos fuentes de verdad. Los datos de clientes o de productos existen en ambos sistemas y las dos copias no coinciden. Alguien debe decidir cuál prevalece y con qué reglas.
  • Expectativas de procesamiento por lotes frente a tiempo real. Un usuario de negocio pide datos actualizados, el sistema de origen solo puede exportar por la noche y la diferencia se descubre tarde.
  • Interfaces controladas por el proveedor. El proveedor decide qué interfaces están disponibles, cuánto cuestan y cuándo cambian, de modo que el equipo de integración depende de calendarios ajenos.

Opciones de interfaz

La elección de la interfaz depende de lo que admita el sistema de origen y de la frescura que deban tener los datos. Los servicios web REST y SOAP son la vía más habitual en los ERP y CRM modernos. Permiten el intercambio de solicitud y respuesta y son fáciles de monitorear, pero exigen que el sistema de origen exponga las operaciones adecuadas.

El intercambio de archivos sigue siendo muy común. Las exportaciones programadas en CSV o XML son sencillas y robustas, y se adaptan a informes y a sincronizaciones nocturnas. Las colas de mensajes desacoplan al emisor del receptor, de modo que uno de los dos puede quedar fuera de servicio un tiempo sin que se pierdan datos. Son adecuadas para flujos basados en eventos en los que importan el orden y la entrega.

En datos de salud, los mensajes HL7 versión 2 siguen siendo comunes para admisiones, órdenes y resultados, y FHIR se utiliza cada vez más para el intercambio basado en API. El uso de estos estándares reduce el mapeo personalizado, aunque los perfiles y extensiones locales deben acordarse con cada proveedor.

Mapeo y calidad de los datos

El mapeo es el núcleo del trabajo. Para cada campo, el equipo registra el origen, el destino, la transformación y la regla para resolver conflictos. Los catálogos de códigos, las unidades, los formatos de fecha, las codificaciones de caracteres y los identificadores requieren especial atención, ya que un paciente, un cliente o un producto puede tener un identificador distinto en cada sistema.

Los problemas de calidad de datos suelen salir a la luz en esta etapa: registros duplicados, valores obligatorios ausentes y campos de texto libre usados como códigos. Lo más conveniente es resolverlos en el origen, con reglas de depuración acordadas con los responsables de los datos, y no parchearlos dentro de la interfaz, donde dejan de ser visibles.

Seguridad y auditoría

Las cuentas de integración deben seguir el principio de mínimo privilegio, con acceso limitado a las operaciones que la interfaz necesita. Cada llamada que lea o modifique datos personales debe registrarse indicando quién, qué y cuándo, y los registros deben protegerse y conservarse conforme a la política vigente.

Los datos personales están sujetos a la KVKK en Türkiye y al RGPD en la UE. Para los datos de salud, los requisitos son más estrictos. El diseño de la integración debe definir qué datos se transfieren, con qué finalidad, cómo se protegen en tránsito y en reposo, y durante cuánto tiempo se conservan las copias.

Pruebas y reversión

Las interfaces deben probarse con datos realistas, incluidos casos límite como nombres largos, caracteres especiales, pedidos cancelados y resultados corregidos. Resulta valioso contar con entornos de prueba que reproduzcan las versiones de producción de ambos sistemas, porque el comportamiento suele variar entre versiones. El plan de puesta en marcha debe indicar el orden de los pasos, las verificaciones posteriores a cada paso y las condiciones en las que el equipo vuelve al estado anterior.

Operación después de la puesta en marcha

Una interfaz es un servicio en ejecución. Necesita monitoreo de fallos y demoras, una cola de errores donde se puedan inspeccionar y reprocesar los mensajes rechazados, y alertas que lleguen a una persona designada. Cada interfaz debe tener un responsable del lado del negocio y otro del lado técnico, con documentación que describa su finalidad, su frecuencia, su mapeo y sus límites conocidos. Sin esto, los fallos pequeños se acumulan hasta que los datos de ambos sistemas dejan de coincidir.