Un error frecuente en aseguradoras es detener el proyecto de CRM hasta reemplazar el sistema de pólizas. El argumento suena prudente: el core tiene décadas, no expone datos y sistemas propone cambiarlo primero. El problema es el calendario. Reemplazar el core es un proyecto de años, y el CRM espera todo ese tiempo.
Para tener CRM casi nunca hace falta reemplazar el core. Hace falta una capa de integración y una decisión dato por dato: qué se sincroniza, qué se consulta en línea y qué se queda donde está. La modernización del core puede venir después, por partes.
Los sistemas legados son aplicaciones antiguas que siguen operando procesos críticos, como pólizas, siniestros, cartera o facturación, con tecnología difícil de cambiar y conocimiento concentrado en pocas personas. Frenan el CRM porque guardan los datos que el CRM necesita y no tienen formas modernas de compartirlos.
En seguros es muy común. El sistema de emisión funciona, los procesos regulatorios dependen de él y nadie quiere tocarlo. Esa prudencia es razonable. El problema aparece cuando la prudencia se convierte en el argumento para no conectar nada, y el área comercial sigue trabajando con reportes exportados cada semana.
En la mayoría de los casos, no hace falta. El CRM necesita ver ciertos datos del core, como pólizas vigentes, pagos o siniestros abiertos, y registrar ciertos eventos de vuelta. Eso se resuelve con integración. Reemplazar el core es una decisión de modernización de aplicaciones con su propio caso de negocio y su propio calendario.
Martin Fowler, que acuñó el patrón Strangler Fig, lo explica en un texto que reescribió en agosto de 2024: los reemplazos completos de un sistema importante «se van a pique la mayoría de las veces», según lo que él y sus colegas han visto, porque toman mucho tiempo y es difícil entender todo lo que el sistema viejo hace. Su alternativa es modernizar de forma gradual, construyendo piezas nuevas alrededor del sistema existente.
Conectar el CRM con una capa de integración encaja con esa idea: el core sigue operando y el CRM se alimenta de él sin depender de que alguien lo reescriba.
Con tres preguntas por cada dato: ¿con qué frecuencia cambia?, ¿qué tan grave es mostrar un valor desactualizado?, y ¿el CRM necesita filtrar o reportar sobre ese dato? Los datos estables y usados en reportes se sincronizan. Los que cambian seguido y se necesitan al momento se consultan en línea. El resto se queda en el core.
En una aseguradora, los datos del cliente y de la póliza pueden sincronizarse una vez al día, porque cambian poco y ventas necesita segmentar con ellos. El estatus de un siniestro conviene consultarlo en línea cuando el asesor abre la ficha, porque un dato de ayer puede causar una mala conversación. Y el detalle de coberturas y reaseguro se queda en el core, porque el CRM no tiene por qué tocarlo.
Esta matriz es la base de la arquitectura de integración. Sin ella, cada proyecto conecta lo que se le ocurre y la deuda técnica crece.
Es la tabla que armo en las primeras semanas. Filas: los datos que el CRM podría necesitar. Columnas: sincronizar (con qué frecuencia y en qué dirección), consultar en línea (desde qué pantalla y con qué tiempo de respuesta), o no tocar. Cada fila tiene un responsable en el negocio y otro en sistemas.
La matriz sirve también para la conversación con el área de sistemas. En lugar de pedir «acceso al core», se piden cosas concretas y acotadas. Eso baja la resistencia y permite estimar el esfuerzo con más precisión. También sirve para la automatización, porque muchos procesos que el negocio quiere automatizar dependen de estos mismos datos; cuando llegue el momento de decidir por dónde empezar la automatización, la tabla ya dirá qué datos están disponibles.
El reporte de conectividad 2025 de MuleSoft, publicado en enero de 2025, encontró que la empresa promedio maneja 897 aplicaciones y solo el 29 % está integrada. También reporta que el 95 % de las organizaciones enfrenta retos para integrar la IA a sus procesos existentes.
Son datos de un proveedor de integración, así que hay que leerlos con ese contexto. Aun así, coinciden con lo que encuentro en los proyectos que reviso: sistemas de sobra y muy pocas conexiones bien gobernadas entre ellos. Cada iniciativa nueva, sea CRM o IA, choca con la misma pared.
Conectar punto a punto cada necesidad es lo más rápido para el primer proyecto. El costo aparece en el tercero o el cuarto, cuando nadie sabe qué conexión alimenta qué. Por eso, desde la primera integración, alguien en sistemas tiene que responder por ellas y mantener un inventario documentado.
Copiar todo el core al CRM «por si acaso» parece prudente y hace lo contrario: duplica datos, crea conflictos sobre cuál es la versión correcta y vuelve el CRM pesado.
¿Qué pasa con la calidad del dato de origen? Si el core tiene clientes duplicados, el CRM los hereda. Y si esos datos alimentan el forecast de ventas, el director comercial va a desconfiar de los números del CRM desde el primer mes.
La consulta en línea también necesita plan B. Si el core tarda o no responde, el asesor abre la ficha y ve un hueco donde debería estar el siniestro. Hay que definir qué muestra la pantalla en ese caso y quién recibe la alerta.
Cuando el core ya no puede soportar el negocio: no admite productos nuevos, el proveedor dejó de darle soporte, solo una o dos personas saben operarlo, o su costo de mantenimiento supera claramente al de modernizarlo. En esos casos, la modernización se planea por partes, con el CRM ya conectado.
Si hoy alguien en el comité propone que el CRM espere al nuevo core, ¿ese reemplazo ya tiene presupuesto aprobado y fecha?
Es conectar el CRM con aplicaciones antiguas para que comparta datos con ellas, ya sea sincronizando información periódicamente o consultándola en línea, sin modificar la lógica del sistema legado.
Es el costo acumulado de soluciones rápidas que después hay que mantener o rehacer, como conexiones punto a punto sin documentar o copias de datos duplicadas. Crece con cada proyecto que integra sin una arquitectura común.
Es el proceso de actualizar o reemplazar sistemas antiguos para que soporten mejor las necesidades actuales del negocio. Puede hacerse de forma gradual, reemplazando partes del sistema mientras el resto sigue operando.
Es el diseño de cómo se conectan los sistemas de una empresa: qué datos se comparten, por qué canales, con qué frecuencia y quién gobierna cada conexión. Evita que cada proyecto cree conexiones aisladas.
Si quieres revisar tu caso con alguien que no vende la plataforma, agenda una conversación.