A las instituciones públicas y a las utilities rara vez les faltan sistemas. Lo que les falta es otra cosa: un camino coherente por el que los datos viajen entre ellos. Un registro nacional responde por una API, el ERP financiero por otra completamente distinta, los controladores SCADA hablan un protocolo industrial y el archivo documental guarda su propio formato. El resultado son copias manuales, datos que se van separando y procesos que se atascan en una sola hoja de cálculo.
Por nuestra experiencia, el problema no es ninguna tecnología concreta, sino unir mundos que nunca se diseñaron para cooperar. Aunque aquí no señalemos un caso de éxito con nombre, sí aportamos a las personas que conectan estos sistemas cada día: ingenieros de integración, arquitectos y especialistas que entienden la infraestructura crítica. Construimos la capa que ata registros, ERP, SCADA y archivos en un flujo de datos predecible.
¿Por qué son tan difíciles las integraciones en el sector público y en las utilities?
Porque una institución suele ser capas de tecnología de épocas distintas que nadie puede apagar. Un sistema construido hace quince años sostiene un proceso crítico y todavía funciona, así que se queda, y las soluciones nuevas se van apilando a su lado. Con el tiempo sale una arquitectura en la que cada componente vive su propia vida.
Tres cosas conspiran a la vez:
- silos de datos - cada departamento tiene su sistema y su versión de la verdad sobre el mismo ciudadano o el mismo punto de medida,
- legacy - aplicaciones antiguas sin API moderna, a menudo sin documentar y sin ningún autor a quien preguntar,
- seguridad y regulación - datos personales, infraestructura crítica y reglas que prohíben «sacar sin más un endpoint al mundo».
Por eso no puedes tratar una integración institucional como un proyecto corriente de cablear dos aplicaciones. Hay que reconciliar lo viejo con lo nuevo sin interrumpir servicios de los que la gente depende todos los días.
¿Cómo es la integración con los registros nacionales?
Los registros nacionales son una especie aparte. Imponen sus propios estándares de intercambio, sus procedimientos de acceso y unas ventanas de mantenimiento sobre las que no tienes ningún control. Así que la integración con registros nacionales va menos de escribir un cliente de API y más de envolverlo para que el resto de tus sistemas nunca note que al otro lado hay un servicio ajeno y a veces caprichoso.
En la práctica construimos una capa mediadora que traduce los formatos del registro al modelo de datos de la institución, cachea las respuestas, gestiona la autenticación y las firmas y registra cada petición para auditoría. Cuando el registro no está disponible, el sistema no se cae; encola las peticiones y las reintenta según reglas acordadas. El funcionario o el proceso dentro de la institución obtiene una interfaz estable en lugar de una conexión en crudo con el mundo exterior.
¿Cómo conectar el ERP y los sistemas financieros con el resto de la organización?
El ERP suele ser el corazón de una institución y, sin embargo, rara vez está abierto. Lo atamos con el flujo documental, los sistemas de negocio y los registros para que los datos financieros dejen de viajar a mano y circulen por un canal controlado.
Lo entregamos la mayoría de las veces mediante:
- integración por API y bus (ESB, API gateway) en lugar de enlaces punto a punto frágiles,
- sincronización de datos maestros (contrapartes, diccionarios, plan de cuentas) entre el ERP y los sistemas de negocio,
- automatización de los flujos de facturas y pagos conservando la ruta de aprobación y el rastro de auditoría,
- reporting y declaraciones obligatorias alimentados con datos de varios sistemas a la vez.
La coherencia es aquí la clave: si la misma contraparte lleva tres identificadores distintos en tres sistemas, no habrá automatización que aguante. Por eso, antes de conectar nada, ponemos orden en el modelo de datos.
¿Cómo integrar SCADA y la medida sin perturbar el mundo OT?
En una utility, la frontera más dura pasa entre TI y OT, entre el mundo de las aplicaciones de negocio y el del control de procesos. SCADA, los PLC y los sistemas de medida viven en una red industrial donde la operación ininterrumpida y la seguridad están por encima de la comodidad de la integración.
La integración de SCADA exige prudencia, porque aquí un error no significa un fallo en una pantalla, sino un efecto real sobre la infraestructura. Por eso recogemos los datos OT a través de pasarelas dedicadas y protocolos industriales (como OPC UA, Modbus, MQTT), los almacenamos en buffer y solo después exponemos el flujo depurado a las aplicaciones de negocio, a la analítica o a la facturación. Dejamos que el tráfico corra en un único sentido controlado, manteniendo las redes separadas, para que el lado del negocio pueda leer la telemetría sin llegar nunca a poder tocar el control. Ese reparto de responsabilidad es un cimiento, no una opción.
¿Cómo meter el flujo documental y los archivos en un mismo circuito?
La gestión electrónica de documentos, los repositorios y los archivos digitales son el punto donde un proceso se atasca más a menudo. Los conectamos con los registros y con el ERP para que un documento se cree, circule y llegue al archivo sin exportaciones e importaciones manuales.
En esta área solemos:
- unir la gestión documental con los sistemas de negocio, para que el expediente y el documento formen un solo flujo en vez de dos separados,
- automatizar los metadatos y la clasificación a partir de datos que ya están en otros sistemas,
- cablear el archivo conforme a los requisitos de conservación y a los formatos de preservación a largo plazo.
Un flujo documental bien conectado deja de ser un cuello de botella y pasa a ser una etapa natural del proceso, donde los datos introducidos una vez no hay que teclearlos nunca más.
¿Cómo hacer que las integraciones sean fiables y seguras?
Una integración institucional tiene que seguir funcionando incluso cuando uno de los sistemas se calla un rato. Por eso la diseñamos tolerante a fallos, y no como una cadena que se rompe en el primer eslabón.
La apoyamos en unos cuantos pilares:
- colas de mensajes (como Kafka o RabbitMQ) que desacoplan los sistemas y absorben los picos de tráfico,
- reintentos e idempotencia, para que repetir una petición nunca duplique una operación,
- cifrado en tránsito y en reposo, más control de acceso alineado con los requisitos de la institución,
- monitorización y un rastro de auditoría completo que muestra quién intercambió qué datos y cuándo.
Con esta arquitectura, un registro que se apaga un momento o un ERP bajo carga pasan a ser un evento que el sistema gestiona solo, no un incidente que exige un arreglo manual de madrugada.
¿Qué competencias aportamos a un proyecto de integración?
En proyectos así damos forma al equipo en torno a la arquitectura concreta, no «por si acaso». Lo más habitual es que cubramos los roles de:
- un arquitecto de integración que diseña el flujo completo y fija los estándares,
- ingenieros de backend e integración (Java, .NET, Python) que construyen conectores, API y el bus,
- especialistas de DevOps y seguridad que se ocupan de las colas, la infraestructura y el bastionado,
- especialistas OT / industriales allí donde entran en juego SCADA y la medida.
Tenemos experiencia real en proyectos para la administración pública y en integración de sistemas, además de en infraestructura crítica, así que entendemos tanto el rigor regulatorio como la realidad de trabajar con el mundo OT. No lo colgamos de un único despliegue, porque aquí hablamos de la competencia que aportamos al equipo del cliente.
¿Cómo lo hacemos en RITS?
Trabajamos como partner nearshore desde Polonia que suma al equipo de la institución o de la utility las competencias que faltan. En proyectos de integración eso significa que:
- cubrimos los roles de arquitecto e ingenieros de integración entrenados para trabajar con legacy y con rigor regulatorio,
- verificamos las competencias antes de empezar y ajustamos el equipo a la arquitectura y a los protocolos concretos,
- entramos en el ritmo existente del cliente, en sus revisiones de código y en sus procedimientos de seguridad sin un arranque largo,
- tendemos un puente entre TI y OT respetando la separación de redes y los requisitos de infraestructura crítica.
Lo más habitual es hacerlo mediante refuerzo de equipo o un equipo dedicado y, allí donde una institución construye desde cero una nueva capa de integración, como software a medida creado por nuestro equipo.
¿Por dónde empezar con la integración de sistemas en una institución?
Empieza por el flujo que más duele - por ejemplo, el punto donde alguien copia datos a mano entre un registro y el ERP todos los días. Describir ese único camino de principio a fin revela qué conectores, qué capa de seguridad y qué roles necesitas de verdad, antes de abordar toda la arquitectura. Las diferencias entre los modelos de colaboración las tratamos en nuestro artículo sobre modelos de colaboración en TI.
¿Quieres atar registros nacionales, ERP, SCADA o archivos en una misma institución? Hablemos - ajustamos un equipo y una arquitectura a tu panorama de sistemas.