Cuando la salud no puede esperar: el sistema médico global que funciona aunque todo falle

Cuando la salud no puede esperar: el sistema médico global que funciona aunque todo falle

A las 2:17 a.m., una mujer de 63 años sintió un dolor agudo en el pecho mientras estaba sola en casa.

Su reloj inteligente detectó anomalías cardíacas.
Su teléfono emitió una alerta.
Una plataforma médica analizó sus signos vitales en segundos.
Un cardiólogo fue notificado.
Una ambulancia fue despachada automáticamente al hospital adecuado.
Su historial clínico ya estaba disponible cuando llegó.

No fue suerte.
Fue infraestructura.

Detrás de esa experiencia había algo que rara vez aparece en las historias de salud:

Una arquitectura multinube diseñada para que la atención médica nunca dependa de un solo punto de falla.

---

El problema silencioso de la medicina moderna: sistemas fragmentados

Hoy, millones de pacientes enfrentan riesgos no por falta de médicos, sino por falta de información oportuna.

Historias clínicas incompletas.
Diagnósticos tardíos.
Falta de continuidad en tratamientos.
Saturación hospitalaria.
Errores evitables.

La World Health Organization estima que los errores médicos prevenibles causan millones de eventos adversos cada año a nivel global.

Mientras tanto, el envejecimiento poblacional y las enfermedades crónicas presionan sistemas ya sobrecargados.

La pregunta dejó de ser cómo atender más pacientes.

Ahora es:

¿Cómo atenderlos mejor, antes, y con precisión?

---

El salto conceptual: salud en tiempo real

Un consorcio ficticio de clínicas de especialidad —HealthSphere— decidió replantear la atención médica desde cero.

No como hospitales aislados.
No como expedientes dispersos.
No como consultas reactivas.

Sino como un sistema vivo, continuo y global.

Un ecosistema que integra:

• Atención presencial y remota

• Web y mobile

• Dispositivos IoT médicos

• Analítica avanzada

• IA y aprendizaje automático

• Centros de operación inteligentes

• Infraestructura multinube

El objetivo no era digitalizar la medicina.

Era hacerla predictiva, disponible y coordinada.

---

Multinube: más que disponibilidad, resiliencia inteligente

Tradicionalmente, la multinube se justifica por continuidad operativa.

Pero HealthSphere buscaba algo más ambicioso:

Combinar las fortalezas únicas de cada proveedor para crear un sistema superior a cualquiera por separado.

Participaron plataformas líderes:

• Amazon Web Services

• Microsoft Azure

• Google Cloud Platform

• Oracle Cloud Infrastructure

• IBM

Cada una aportó capacidades clave en áreas como:

• Analítica masiva

• Inteligencia artificial

• Bases de datos críticas

• Seguridad empresarial

• Integración con sistemas clínicos

• Procesamiento en tiempo real

• Infraestructura global

El resultado fue una plataforma resiliente por diseño.

Si una región falla, otra responde.
Si un proveedor se degrada, el servicio continúa.
Si hay picos de demanda, la capacidad se redistribuye.

En salud, eso no es comodidad.

Es supervivencia.

---

IoT médico: el paciente deja de ser invisible entre consultas

La mayoría de las decisiones médicas se toman con información incompleta.

Porque el paciente solo es “visible” cuando está en consulta.

HealthSphere integró dispositivos conectados:

• Monitores cardíacos

• Sensores de glucosa

• Dispositivos respiratorios

• Wearables clínicos

• Equipos domiciliarios de diagnóstico

Según estudios publicados en revistas médicas globales, el monitoreo remoto puede reducir hospitalizaciones en pacientes crónicos entre 20% y 30%.

Pero el verdadero cambio no es reducir ingresos hospitalarios.

Es detectar deterioros antes de que sean emergencias.

---

IA y ML: priorizar vidas cuando todo es urgente

En sistemas saturados, todos los casos parecen críticos.

La inteligencia artificial permite distinguir cuáles lo son realmente.

Desde el primer contacto —app, web, llamada o dispositivo— el sistema puede:

• Evaluar riesgo clínico

• Priorizar atención

• Recomendar nivel de urgencia

• Identificar patrones peligrosos

• Alertar especialistas adecuados

Investigaciones globales muestran que modelos de IA pueden igualar o superar la precisión diagnóstica humana en ciertas especialidades, como radiología o detección de retinopatía diabética.

La IA no reemplaza al médico.

Amplía su capacidad para actuar a tiempo.

---

Atención omnicanal real: el paciente no se adapta al sistema, el sistema al paciente

HealthSphere eliminó la fragmentación entre canales.

Un paciente puede:

• Iniciar en una app móvil

• Continuar por teleconsulta

• Acudir a una clínica

• Ser hospitalizado

• Recibir seguimiento domiciliario

Sin repetir información.
Sin perder contexto.
Sin empezar de cero cada vez.

---

Data driven: decisiones clínicas y operativas con evidencia continua

La plataforma analiza millones de eventos en tiempo real:

• Evolución de pacientes

• Uso de recursos

• Resultados de tratamientos

• Tendencias epidemiológicas

• Riesgos emergentes

Esto permite optimizar:

• Distribución de personal

• Disponibilidad de camas

• Inventario médico

• Protocolos de atención

• Prevención poblacional

Durante la pandemia, sistemas con analítica avanzada demostraron ser cruciales para anticipar saturación hospitalaria.

---

Seguridad y privacidad: confianza como requisito, no como opción

Los datos de salud son de los más sensibles que existen.

La arquitectura incorporó protección integral:

• Cifrado extremo a extremo

• Control granular de acceso

• Trazabilidad completa

• Cumplimiento regulatorio internacional

• Segmentación de información

La seguridad no se añadió después.
Se diseñó desde el inicio.

---

Centros de operación con IA: hospitales que aprenden

El sistema no solo reacciona a eventos.

Aprende de ellos.

Los centros de comando utilizan analítica avanzada para:

• Detectar patrones de riesgo poblacional

• Identificar oportunidades de prevención

• Mejorar protocolos clínicos

• Reducir costos operativos

• Optimizar flujos de atención

La medicina deja de ser episódica y se vuelve continua.

---

Beneficios económicos: eficiencia sin sacrificar calidad

El gasto sanitario global supera los 9 billones de dólares anuales, según organismos internacionales.

Gran parte se destina a:

• Hospitalizaciones evitables

• Diagnósticos tardíos

• Ineficiencias operativas

• Duplicación de pruebas

• Eventos adversos

Los sistemas digitales integrados han demostrado reducir costos totales mientras mejoran resultados clínicos.

No es solo tecnología.

Es sostenibilidad del sistema de salud.

---

Impacto social: acceso, equidad y prevención

La multinube permite desplegar servicios en regiones con distinta infraestructura local.

Clínicas rurales pueden acceder a capacidades antes reservadas a grandes hospitales urbanos.

Pacientes con movilidad limitada pueden recibir atención continua.

Programas preventivos pueden escalar a poblaciones completas.

El beneficio no es solo individual.

Es sistémico.

---

La medicina que viene no será más grande, será más inteligente

HealthSphere no construyó más hospitales.

Construyó un sistema capaz de:

• Anticipar enfermedades

• Coordinar atención

• Aprender continuamente

• Escalar globalmente

• Operar sin interrupciones

• Proteger la información

• Poner al paciente en el centro

La multinube fue el habilitador invisible de todo ello.

---

La lección para líderes tecnológicos y sociales

Cuando se combinan:

✔ Infraestructura resiliente
✔ Datos confiables
✔ Inteligencia artificial responsable
✔ Dispositivos conectados
✔ Arquitecturas bien diseñadas
✔ Enfoque centrado en las personas

El resultado no es solo eficiencia operativa.

Es una mejora tangible en la calidad y esperanza de vida.

---

Porque en salud, el tiempo no es dinero

Es vida.

Y los sistemas capaces de actuar en tiempo real, con información completa y disponibilidad global, representan uno de los avances más significativos para la sociedad moderna.

La tecnología multinube no se ve en una sala de emergencias.

Pero puede ser la razón por la que alguien llegue con vida a ella.

Esta prueba de concepto, ha iluminado muchas cosas importantes al integrar multinubes sin que represente una inversión descabellada, sino pensada para que funcione con inversión adecuada. Si, podría correr en una sola nube con espejos activos en alta disponibilidad, si no es en la misma región; la experiencia nos deja ver ese alto riesgo. Aunado a que no todas las zonas manejan todas las opciones de herramientas necesarias, o bien, que algunos componentes por temas de golden data deben residir en el país donde se opera.

Jorge Mercado
#JMCoach

Aplicando gobierno de datos (Datos 2 de 2)

ataDriven · por Jorge Mercado   JMCOACH

Gobierno de Datos · Arquitectura · Negocio

Análisis de Caso · Edición 2025

Tres empresas,
una verdad incómoda

No es un problema de IA. No es un problema de tecnología. Es un problema de diseño, de datos y de la secuencia en que se toman las decisiones, No entender el negocio. Llevo tres décadas viéndolo. El patrón no ha cambiado.

JM

Jorge MercadoDesde archivos secuenciales en cinta hasta arquitecturas cloud — 20+ años en el oficio de los datos

Haciendo que las cosas sucedan

Pongamos los puntos sobre la i, pasemos de los buenos deseos a cómo se lleva a la práctica y para esto voy a simular con cifras del mundo real, tres escenarios ficticios, de alto valor para entender dónde falla la práctica, para entender por qué los resultados al implementar Gobierno de datos sin la visión adecuada y su resultados parciales, que harán que les caiga el veinte en varias cosas y aplica en IA, Arquitectura y demás áreas no solo en datos.

En la vida real, puedes encontrar similitudes, no solo en datos, en producto, alienación estratégica, tecnología, operaciones; es un universo de sabores y oportunidades por resolver.

 Caso 01 · Adopción Parcial

✈️

Industria: Aviación · México

Cielo Azteca Airlines

Aerolínea regional · 32 rutas · 3.8 millones de pasajeros/año · Flota de 39 aeronaves

Adopción Parcial

Contexto competitivo realCielo Airline opera con márgenes EBITDA del 28–32% en 2024 y ha construido ventaja competitiva desde el revenue management con datos. Su ingreso auxiliar (ancillary revenue) representó el 38.5% de sus ingresos totales según datos de CarTrawler. Delta invirtió 5 años construyendo su plataforma de datos antes de lanzar personalización a escala: multiplicó por 3.7× sus ingresos auxiliares en 8 años. Cielo Airline competía en las mismas rutas con márgenes del 11% y sin capacidad de personalización.

La situación: diez versiones del mismo cliente

Cielo Airline llegó después de perder tres licitaciones corporativas consecutivas frente a Flota Airline. No era un problema de precio: era que no podían responder en menos de 48 horas porque la información de vuelos disponibles, tarifas corporativas y capacidad vivía en cuatro sistemas sin integración: el GDS1, su propio sistema de reservaciones, pareçía casi un Excel de "control de asientos" y el sistema financiero.

Cuando levantamos el diagnóstico, el equipo de TI reveló la arquitectura real: 10 bases de datos distintas con información de pasajeros, ninguna era "la verdad". Revenue management decía 121,000 pasajeros frecuentes. Loyalty decía 86,000. Marketing decía 154,000. Todos tenían razón en su contexto. Ninguno era útil para tomar decisiones. Era el mismo problema que he visto desde los años 90 con los sistemas OLTP fragmentados —solo que ahora con más tecnología encima del pantano.

Cuando vi la arquitectura de integración de Cielo Airline, conté 24 conexiones punto a punto entre sus sistemas operativos. Cada una construida para resolver un problema inmediato, sin visión de conjunto, sin documentación, sin dueño. Algunos tenían 9 años de antigüedad y nadie en TI sabía exactamente qué hacían. Los llamamos "componentes zombi": no puedes matarlos porque no sabes qué muere si los apagas.

El plan de ahorcamiento que aplicaron — y cómo se interrumpió

El programa arrancó bien. CDO interino nombrado. Diagnóstico de madurez DAMA: 1.4/5.0. Seis Data Owners confirmados. Los primeros 90 días produjeron resultados concretos: glosario de 87 términos aprobados, catálogo levantado en AWS Glue con 29 activos documentados, y —lo más importante— el inicio del proceso de ahorcamiento sobre el componente más crítico: el sistema de sincronización de inventario de asientos entre el GDS y el sistema de reservaciones.

Se implementó la capa de captura: un bus de eventos Kafka que interceptaba cada actualización de disponibilidad de asientos en ambos sistemas, aplicaba reglas de reconciliación y publicaba una "verdad única" de disponibilidad. En las primeras 4 semanas, la discrepancia de asientos disponibles entre sistemas bajó del 12% al 1.8%.

Aquí fue donde el programa tomó el primer desvío: al mes 4, el CEO recibió una propuesta de un proveedor de BI para un dashboard "ejecutivo en tiempo real" con datos de ocupación. El CDO advirtió que el proceso de ahorcamiento estaba a la mitad y que los datos base seguían teniendo deuda. La decisión fue: "implementamos el dashboard y terminamos el ahorcamiento después".

La frase más costosa del vocabulario de los datos"Lo terminamos después" es la frase que he escuchado más veces antes de que un programa de datos fracase. Un componente ahorcado a la mitad no es mejor que uno no ahorcado: es más peligroso, porque da apariencia de estar solucionado mientras la deuda sigue activa y ahora invisible.

El programa se pausó 11 semanas. El CDO interino fue contratado por la competencia. Los Data Owners volvieron a sus responsabilidades operativas. El impulso se perdió. El proceso de ahorcamiento de los 34 componentes punto a punto —que era el trabajo real— quedó con solo 1 de 34 completado.

Resultados a 12 meses

+18% Mejora en precisión del forecast de demanda por ruta

$2.8M MXN recuperados en revenue management por mejor control de disponibilidad

1.9/5 Score DAMA al mes 12 (vs. 1.4 inicial). Meta era 2.5.

21/24 Componentes punto a punto sin ahorcamiento completado. La deuda técnica sigue activa.

Mes 1–3

Arranque sólido. CDO nombrado, diagnóstico completo, glosario aprobado, catálogo activo. Proceso de ahorcamiento del componente GDS iniciado: discrepancia de asientos baja del 12% al 1.8%.

Mes 4 · Punto de inflexión

El bypass fatal. CEO aprueba dashboard BI sin esperar el fin del ahorcamiento. Programa pausado 11 semanas. CDO se va. 21 de 24 componentes deficientes sin tocar.

Mes 5–8

Dashboard con datos parcialmente limpios. El componente ahorcado funciona bien. Los otros 21 siguen enviando datos sucios. El dashboard mezcla ambas fuentes. Revenue management toma 3 decisiones de pricing incorrectas.

Mes 9–12

Recuperación parcial. Nuevo DG Manager contratado. MDM de pasajeros completado al 60%. Score cierra en 1.9. Potencial bloqueado por los 21 componentes no saneados.

Caso 02 · Adopción Parcial

🚛

Industria: Logística y Distribución · México / LATAM

Ruta Segura Logistics

3PL regional · 2,010 unidades · 16 centros de distribución · $3,900M MXN de ingresos anuales

Adopción Parcial

Contexto competitivo realMcKinsey documenta reducciones del 12.7% en costos logísticos y 20.3% en niveles de inventario para empresas que implementan IA en supply chain con datos gobernados. UPS ahorra más de $400M anuales con su plataforma ORION de optimización de rutas —construida sobre 8 años de datos de alta calidad. El mercado de IA en supply chain alcanzó $19.8B en 2025 con CAGR del 45.3%. Ruta Segura competía con márgenes del 6.2% contra actores internacionales con 11–15%.

La situación: crecimiento que creó una trampa de datos

Ruta Segura creció 340% en 7 años, principalmente a través de 4 adquisiciones de empresas regionales de transporte. Cada adquisición trajo su propio TMS2, su propio catálogo de clientes, su propia definición de "entrega exitosa" y sus propias integraciones punto a punto. En 2024, cuando el equipo intentó implementar ruteo dinámico con IA, descubrieron el problema real: 140,000 registros de clientes con calidad de dirección del 61%. Ningún algoritmo de optimización funciona con ese nivel de calidad.

Pero el problema de fondo era más profundo. Cuatro TMS distintos significaban cuatro formas distintas de registrar una entrega, cuatro modelos de datos distintos para el mismo concepto, y cuatro equipos de TI que habían construido integraciones de emergencia entre sí para que "funcionara". El resultado: un ecosistema de 64 integraciones punto a punto, de las cuales 19 tenían fallos silenciosos documentados y 11 nadie sabía cómo funcionaban exactamente. Igual que las cintas de los 80: el sistema "funcionaba" hasta que no funcionaba, y cuando no funcionaba nadie sabía por qué.

El CEO de Ruta Segura me dijo: "Tenemos todos los datos, lo que necesitamos es el algoritmo". Le pregunté qué porcentaje de sus registros de dirección del cliente tenían colonia, municipio, código postal y coordenadas GPS completos y consistentes. Revisamos juntos: 39%. Le expliqué que con ese 39% de calidad, el problema no era el algoritmo. Era que 7 años de crecimiento acelerado habían acumulado una deuda de datos que nadie había cuantificado y que ahora bloqueaba cada iniciativa nueva que el negocio quería lanzar.

El plan de ahorcamiento: excelente diseño, ejecución interrumpida

El diagnóstico reveló un score DAMA de 1.6/5.0, con el dominio de "Activos vehiculares" en 1.2 —el más crítico. Se aprobó un plan de 12 meses con $6.1M MXN de inversión. La diferencia positiva de Ruta Segura vs. Cielo Airline: dedicaron 2 semanas al diseño del proceso de ahorcamiento antes de escribir la primera línea de código. Identificaron los 12 componentes más críticos y los priorizaron por impacto en la calidad de direcciones y datos de unidades.

Los primeros 90 días ejecutaron el ahorcamiento de los 3 componentes de mayor impacto: el integrador de datos entre el TMS 1 (la empresa original) y el TMS 3 (la adquisición más grande). El resultado fue inmediato: la calidad de datos de unidades vehiculares subió del 54% al 78% en 8 semanas. La calidad de direcciones pasó del 39% al 57%.

El desvío llegó en forma de una promoción: el DG Manager que lideraba el programa fue ascendido a Director de Operaciones. El puesto quedó vacante 6 semanas. El nuevo perfil —más técnico que de negocio— continuó el trabajo de ahorcamiento técnico pero perdió el hilo de adopción cultural. Los Data Stewards dejaron de actualizar metadatos. El dashboard de calidad siguió mostrando métricas que nadie usaba en reuniones operativas. La arquitectura mejoró. La cultura no.

El proceso de ahorcamiento técnico sin la dimensión culturalUn componente puede ser perfectamente saneado a nivel técnico y seguir siendo inútil a nivel de negocio si los Data Stewards no lo adoptan como su responsabilidad. La deuda técnica tiene una solución técnica. La deuda cultural solo tiene una solución cultural. Y la segunda es más difícil y más lenta que la primera.

Resultados a 12 meses

+31% Mejora en precisión del ETA para clientes clave

$7.4M MXN en reducción de costos de combustible por optimización parcial de rutas

3/12 Componentes ahorcados completamente (vs. 12 identificados en el plan original)

61% Calidad de direcciones al mes 12 — vs. 39% inicial. Avance real, pero aún insuficiente para ruteo IA completo (meta: 90%)

Con el modelo MDM completado y el 90% de calidad de direcciones, los algoritmos de ruteo podrían haber generado entre $18M y $24M MXN adicionales, según el benchmark CSCMP para empresas del mismo tamaño3. La adopción parcial capturó el 35–40% del valor posible.

Caso 03 · Proceso Completo — El Diferencial

🛡️

Industria: Seguros de Vida y Daños · México

ProtegeMás Seguros

Aseguradora mediana · 1.1M asegurados · $9,400M MXN primas emitidas · 5to lugar nacional por siniestralidad

Proceso Completo ✦

Contexto competitivo realLa industria aseguradora en México movió $636B MXN en primas emitidas en 2024. El fraude representa aproximadamente el 10% de las pérdidas en seguros de daños, equivalente a ~$30B anuales a nivel global según la Insurance Information Institute. Aseguradoras con analítica predictiva madura pasaron del 50% al 80% en tasa de detección de fraude. Willis Towers Watson documenta reducción del 5.7pp en combined ratio para aseguradoras con data-driven underwriting. El tiempo de resolución de siniestros se reduce entre 55–75% con automatización sobre datos gobernados.

La situación: el CEO que diagnosticó solo antes de llamar

ProtegeMás no llegó en crisis. Llegó porque su CEO, con 21 años en la industria aseguradora, tenía un diagnóstico propio que quería validar: la empresa crecía al 7.2% anual en primas pero su siniestralidad crecía al 10%. Esa brecha era de $264M MXN de valor destruido cada año. Y su hipótesis era que el problema no era el riesgo asegurado, sino la calidad de los datos con los que se calculaba ese riesgo.

Cuando levantamos el diagnóstico, confirmamos su intuición con números: el 32% de las pólizas de vida tenían inconsistencias entre el sistema de emisión y el sistema de siniestros. La definición de "siniestro fraudulento" tenía 5 interpretaciones distintas entre ajustadores. Y el modelo actuarial de pricing usaba variables cuya calidad promedio era del 73%. En el sistema de emisión de pólizas —construido en los 2000s y parcheado 4 veces— había 7 integraciones punto a punto heredadas de las que 6 generaban datos inconsistentes de forma silenciosa. El sistema "funcionaba" en producción desde hacía 16 años. Nadie lo había tocado. Era un componente zombi clásico.

Lo que distinguió a ProtegeMás desde el primer día fue la pregunta que hizo el CEO: no me preguntó qué tecnología necesitábamos. Me preguntó qué cambios culturales eran necesarios y cuánto tiempo tomaría que su equipo tomara decisiones con datos como primera respuesta, no como validación de lo que ya habían decidido con el instinto. Esa pregunta revela que entiende que el problema real no está en los sistemas. Está en cómo la organización se relaciona con sus datos. Eso lo cambia todo.

El diseño antes del código: 6 semanas sin una sola línea técnica

ProtegeMás invirtió las primeras 6 semanas exclusivamente en diseño. No se configuró un crawler, no se abrió una consola de AWS, no se escribió una consulta SQL. En cambio: se nombró al CDO interno —el Director de Actuaría, con visión de negocio y credibilidad en toda la organización—, se identificaron los 9 componentes más deficientes por impacto en la siniestralidad, se diseñó el plan de ahorcamiento de los 7 más críticos con secuencia, responsable, fecha y criterio de éxito para cada uno, y se hicieron talleres con todos los Data Owners para entender los problemas reales —no los percibidos.

Solo después de esas 6 semanas pusieron la primera línea de código. Este aparente "desperdicio de tiempo" fue la razón del éxito: el programa técnico arrancó sabiendo exactamente qué componente ahorcar primero, por qué, y qué resultado de negocio esperaba.

El proceso de ahorcamiento ejecutado: 7 componentes en 12 meses

Mapa de ahorcamiento ProtegeMás — 7 componentes, 12 meses

El siguiente orden no fue arbitrario: fue determinado por el impacto en la siniestralidad y la complejidad técnica de cada componente. Se priorizó el mayor impacto con el menor riesgo operativo.

1. Integración Sistema de Emisión → Sistema de Siniestros (mes 2–3). El componente más crítico: el 34% de inconsistencias en pólizas venía de aquí. Se implementó un bus de eventos que sincronizaba en tiempo real los cambios de póliza con el sistema de siniestros. Resultado: inconsistencias reducidas del 34% al 2.1% en 6 semanas.
2. Catálogo de asegurados — deduplicación y golden record (mes 3–5). Tres fuentes distintas del asegurado (emisión, siniestros, cobranza). Se ejecutó el MDM completo: matching por RFC + fecha de nacimiento, golden record construido campo a campo con la fuente de mayor calidad. 487,000 asegurados depurados a 461,000 únicos.
3. Pipeline de datos para el modelo actuarial (mes 4–6). Las variables del modelo de pricing tenían calidad del 71%. Se identificaron las 12 variables más influyentes en el modelo y se construyó un pipeline dedicado con validaciones Great Expectations antes de cada ejecución. Calidad de variables del modelo: 71% → 94%.
4. Sistema de alertas de fraude — fuentes de datos limpias (mes 5–7). Con el golden record activo y el pipeline de siniestros saneado, se entrenó el primer modelo de detección de fraude sobre datos gobernados. Primera vez en la historia de la empresa que el modelo tenía datos confiables.
5. Integraciones legadas con corredores y agentes (mes 6–8). 4 integraciones punto a punto con sistemas de corredores externos que generaban duplicados en altas de pólizas. Ahorcadas con una capa de API management que normalizaba y validaba antes de ingresar al sistema central.
6. Pipeline de reportes regulatorios CNSF (mes 7–9). 11 reportes generados manualmente en Excel. Se automatizaron los 11 sobre el data lake gobernado. Resultado: 22 horas/mes de trabajo manual eliminadas, cero errores de cálculo en los últimos 4 reportes.
7. Sistema de cobranza — datos de cuenta (mes 9–11). El componente con menor urgencia regulatoria pero con impacto en NPS. Saneado en último lugar. Reducción de errores de domiciliación del 8.3% al 0.4%.

Los resultados: cuando el diseño correcto genera resultados no lineales

−4.3pp Reducción en combined ratio (96.8% → 92.5%) — $421M MXN en valor recuperado

+127% Mejora en detección de fraude: de 41% a 93% — sobre datos gobernados

−62% Reducción en tiempo de resolución de siniestros: de 14.2 días a 5.4 días

6/6 Componentes deficientes ahorcados completamente en los 12 meses del programa

$43M MXN en fraude prevenido en los primeros 6 meses del modelo IA activo

3.1× ROI del programa en 12 meses (inversión: $8.4M MXN · valor capturado: $26.9M MXN)

2.9/5 Score DAMA al mes 12 (vs. 1.6 inicial). Meta era 2.5. La superaron en 0.4 puntos.

75% Del personal con Data Literacy completado. Índice de cultura: 2.1 → 3.4/5.0

El posicionamiento que nadie anticipó

A los 12 meses, cuando el CEO convocó la revisión anual, fueron los Data Owners de Siniestros y Actuaría —no el CDO— quienes presentaron los resultados al Consejo de Administración. Con orgullo. Con datos. Sin necesitar a TI para explicar qué había pasado el mes anterior con la siniestralidad.

El diferenciador de mercado inesperadoEn el Congreso de la AMIS de octubre 2024, el CDO de ProtegeMás fue panelista en la mesa de "Innovación y Datos". Tres corredores de seguros corporativos los contactaron para incluirlos en sus paneles de proveedores preferidos. Un competidor de primer nivel les propuso una alianza de datos para modelos conjuntos de suscripción. El gobierno de datos y el saneamiento sistemático de componentes se había convertido en un diferenciador de mercado, no en un costo de cumplimiento.

El Patrón · La Lección

La tabla que nadie quiere ver pero todos necesitan

Tres industrias. Tres programas. El mismo punto de partida. Tres resultados radicalmente distintos. La diferencia no fue el presupuesto ni la tecnología.

Variable	✈ Cielo AIRLINE	🚛 Ruta Segura	🛡 ProtegeMás ✦
Madurez DAMA inicial	1.4 / 5.0	1.6 / 5.0	1.6 / 5.0
Madurez DAMA mes 12	1.9 / 5.0	2.1 / 5.0	2.9 / 5.0 ✦
Inversión total	$4.8M MXN	$6.1M MXN	$8.4M MXN
Valor capturado (12m)	$3.2M MXN — 0.67×	$7.4M MXN — 1.21×	$26.9M MXN — 3.2× ✦
Semanas de diseño antes del código	0 semanas	2 semanas	6 semanas ✦
Componentes ahorcados / identificados	1 / 34 (3%)	3 / 12 (25%)	7 / 7 (100%) ✦
Proceso de ahorcamiento interrumpido	Sí — mes 4	Sí — mes 4	No ✦
% personal con Data Literacy	23%	41%	78% ✦
Cultura de datos (índice 1–5)	2.0	2.4	3.4 ✦
Siguiente iniciativa habilitada	Bloqueada por 33 componentes sin sanear	Parcialmente habilitada (9 componentes pendientes)	Habilitada — base limpia para cualquier iniciativa ✦
Posicionamiento competitivo	Sin cambio notable	Mejora operativa invisible al mercado	Nuevo diferenciador de mercado ✦

El pulso que distingue al que diseña del que improvisa

Si hay una sola cosa que separa a ProtegeMás de las otras dos empresas, es la pregunta que hizo el CEO en la primera reunión. Cielo Airline preguntó cuándo podían tener el dashboard. Ruta Segura preguntó en cuánto tiempo mejoraría el ETA. ProtegeMás preguntó qué cambios culturales eran necesarios y cómo sabrían si estaban funcionando.

Esa diferencia de pregunta no es semántica. Revela una comprensión completamente distinta de dónde vive el problema real. El CEO de ProtegeMás entendía que los sistemas de datos no fallan porque la tecnología es vieja. Fallan porque fueron diseñados sin visión de datos, sin escalabilidad, sin flexibilidad para evolucionar. Y que sanearlos requiere paciencia, metodología y la convicción de no ceder al primer atajo que se presenta.

Desde que trabajaba con archivos en cinta en los 80s, el problema nunca fue la cinta. El problema fue el diseño del registro, el diseño del acceso, la falta de visión de qué pasaría cuando ese archivo tuviera 10 veces más datos. Treinta años después, el problema no es la nube, ni el data lake, ni el modelo de IA. El problema es que alguien tomó una decisión de arquitectura sin pensar en el negocio que esa arquitectura tenía que servir en 3 años. El proceso de ahorcamiento no es una técnica moderna. Es el reconocimiento de que ese error existe, que tiene nombre, que tiene costo medible, y que hay una manera metódica de corregirlo sin detener la empresa.

Lo que esto significa para cada iniciativa nueva que estés considerando

La razón por la que este tema es urgente ahora —no en tres años— es que las iniciativas de mayor valor que las empresas están evaluando en 2025 tienen todas el mismo prerrequisito: datos confiables, con linaje, con calidad medida y con componentes saneados. No importa si la iniciativa es IA generativa, automatización de procesos, migración a microservicios, integración post-fusión, implementación de ERP o rediseño del sistema de cobranza. El primer obstáculo es siempre el mismo, y es el mismo que tenías en 1995.

BCG encontró que el 74% de las empresas no pueden escalar IA por problemas de gobierno y accesibilidad de datos4. Pero yo lo formularía de otra manera, porque lo he visto antes de que existiera la IA: el 74% de las iniciativas de transformación —de cualquier tipo— encuentran su primer obstáculo insalvable en datos inconsistentes entre sistemas acoplados de forma frágil, con componentes que nadie se ha atrevido a ahorcar.

Lo que ProtegeMás construyó en 12 meses no es solo un programa de gobierno de datos. Es la plataforma desde la cual puede lanzar cualquier capacidad nueva —IA, automatización, personalización, integración regulatoria— sin volver a empezar desde cero. Esa es la diferencia entre escalar y reinventar. Entre crecer y reparar.

La ecuación que nadie quiere calcularEl costo de hacer el saneamiento bien ahora, con proceso de ahorcamiento disciplinado, es siempre menor que el costo de lanzar la iniciativa siguiente sobre una base deficiente y tener que hacer el saneamiento después, con más urgencia, más presión y más deuda técnica acumulada. He hecho este cálculo decenas de veces. Nunca he encontrado una excepción.

La pregunta para tu organización, hoy

Antes de cerrar: la misma pregunta que hago al inicio de cada diagnóstico. ¿Cuántos de tus sistemas tienen datos del mismo cliente, producto o proveedor? ¿Cuántas de esas versiones son consistentes entre sí?

Si la respuesta incluye más de un sistema y la palabra "depende", ya tienes el diagnóstico. El trabajo es identificar cuáles de esas inconsistencias están bloqueando decisiones de negocio hoy, ponerles nombre, medirles el costo, y construir el plan de ahorcamiento en el orden correcto.

No en paralelo con todo lo demás. No "cuando tengamos tiempo". Como la prioridad que es, porque hasta que no se haga, todo lo demás —el dashboard, el algoritmo, la migración a cloud, el modelo de IA— va a encontrar el mismo obstáculo que encontraron Cielo Azteca y Ruta Segura en el mes 4.

Por Jorge Mercado
#JMCoach

Fuentes y notas

1. ¹ GDS: Global Distribution System — sistema de distribución de inventarios de vuelos para agencias y portales de reserva.
2. ² TMS: Transportation Management System — sistema de gestión de transporte para planificación y ejecución de rutas.
3. ³ CSCMP State of Logistics Report 2024: benchmarks de mejora en empresas 3PL con analítica predictiva madura.
4. ⁴ BCG AI & Data Report 2024. Gartner D&A Research 2024. McKinsey AI in Supply Chain 2024. Willis Towers Watson Insurance Analytics 2024. Insurance Information Institute 2024. CSCMP Logistics Report 2024. CarTrawler Ancillary Revenue Report (Volaris). MIT Sloan Management Review — Data-driven performance research. Los tres casos presentados son ficticios y construidos sobre patrones, benchmarks y dinámicas observadas en organizaciones reales. Las cifras de contexto competitivo son de fuentes públicas.