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.
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 GDS, 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.
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 TMS, 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ño. La adopción parcial capturó el 35–40% del valor posible.
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.
- 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.
- 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.
- 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%.
- 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.
- 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.
- 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.
- 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.
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.
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 datos. 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
No hay comentarios.:
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.