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.

El problema no es la IA (Datos 1 de 2)

 DataDriven · 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

Comencé a trabajar con datos cuando a muy temprana edad, cuando era un archivo secuencial en cinta magnética o cartucho y después discos flexibles y la "consulta" era un programa en COBOL, BASIC, PASCAL, C que leía registro por registro de principio a fin. No había SQL Accesible en México. No había índices. No había joins. Solo registros de longitud fija, posición de byte y la disciplina brutal de saber exactamente qué ibas a necesitar antes de escribir la primera línea.

Tres décadas después, con todo el poder de la nube, de los data lakes, del procesamiento distribuido y ahora de la inteligencia artificial generativa, sigo viendo el mismo error de origen que veía en 1987 (siendo niño ya programaba): sistemas diseñados sin visión de datos, sin escalabilidad pensada desde el inicio, sin un modelo de datos que refleje cómo funciona realmente el negocio.

La tecnología cambió radicalmente. El error no. Y ya existía metodología de análisis, siendo niño aún aprendí Yourdon, después OMT y Booch, después CMM,  RUP, etc + ISOs. Pasando por Togaf, Zachman, NIST, DDD, ADM. Las modas driven: Event, data, flow, etc.

1980s

Archivos secuenciales · Cintas magnéticas · COBOL + ISAM

IBM S/370 · VSAM · Batch processing nocturno

1990s

RDBMS · SQL · Cliente/Servidor · Data Warehouses primigenios

Oracle 7 · Sybase · SQL Server · Informix · Crystal Reports

2000s

ERP · Web · XML · SOA · Business Intelligence 1.0

SAP · PeopleSoft · Cognos · Business Objects · ETL manual

2010s

Big Data · NoSQL · Hadoop · Data Lakes · APIs REST

Spark · Kafka · Cassandra · MongoDB · Tableau · Microservicios

2020s

Cloud nativo · Data Mesh · LLMs · AI/ML en producción · Real-time

Snowflake · Databricks · GPT · Glue · Purview · dbt · Great Expectations

He visto nacer y morir más modas tecnológicas de las que puedo contar. He visto que se decía que"el data warehouse nos va a resolver todo" en los 90s e incluso a fechas recientes se sigue usando igual que en ese tiempo, el "Hadoop va a cambiar todo" en los 2010s, "el IoT nos volverá locos con tan información en tiempo real" en los 2015, y hoy "la IA lo va a hacer por nosotros". Y en cada ciclo, las empresas que se quedan atrapadas en el mismo problema son las que corrieron hacia la tecnología sin resolver primero la arquitectura de datos sobre la que esa tecnología va a operar.

Por cierto, en ese tiempo ya leía sobre inteligencia artificial, redes neuronales, programación orientada a objetos, modem, hackers, etc.

No importa si estás migrando de COBOL, C, Java, .Net u otro a microservicios, de un ERP monolítico a una arquitectura de servicios, de un data warehouse a un data lake, o de análisis descriptivo a IA generativa. El primer obstáculo siempre es el mismo: datos inconsistentes entre sistemas, sin definición común, sin dueño, sin calidad medida. Ese problema no lo resuelve ninguna tecnología nueva. Solo lo amplifica. Sin olvidar que no se alinean a las necesidad y estrategia del negocio.

— Jorge Mercado · Cuatro décadas de observación de campo

El problema real no es la IA. 

Cuando la gente me llama hoy diciéndome que "sus proyectos de IA no funcionan", mi primera pregunta siempre es la misma: ¿cuántos sistemas tienes con datos del mismo cliente? Si la respuesta es más de uno —y casi siempre es más de tres—, el problema no es la IA. El problema es exactamente el mismo que tenías en 1995 cuando tu sistema de ventas y tu sistema de cobranza no se ponían de acuerdo en el saldo del cliente. Lo que cambió es el costo de ese error: antes se traducía en un reporte incorrecto. Hoy se traduce en un modelo que aprende patrones equivocados a gran escala.

Pero ojo: el patrón que voy a mostrarte no es exclusivo de iniciativas de IA. Lo veo en migraciones a cloud que fracasan porque los datos que se migran están sucios y sin esquema. Lo veo en implementaciones de ERP que van 3 años de retraso porque nadie limpió los datos maestros antes de arrancar. Lo veo en integraciones de sistemas post-fusión donde dos empresas llevan 4 años "integradas" pero operan con dos versiones del mismo cliente. Lo veo en proyectos de automatización de procesos (RPA, BPM) que se caen porque los datos de entrada son impredecibles. Los veo en juntas no se concoe el negocio lo que esperan de los datos.

El síntoma cambia. La causa raíz es invariablemente la misma: sistemas diseñados sin visión de datos, acoplados de forma frágil, con componentes que nunca fueron diseñados para escalar ni para ser confiables a largo plazo.

$12.9MPérdidas anuales promedio por mala calidad de datos en empresas medianas y grandes Gartner 2024

73%De proyectos de IA fallan por datos de mala calidad — no por algoritmos deficientes Gartner D&A 2024

74%De empresas no pueden escalar IA por falta de gobierno de datos — el mismo problema en sistemas tradicionales BCG AI Report 2024

6%Más rentables son las empresas genuinamente data-driven vs. sus competidores directos MIT Sloan Research

El proceso de ahorcamiento: cómo se sanean sistemas que no puedes apagar

Una de las preguntas que más me hacen cuando presento diagnósticos con este nivel de deuda técnica es: "¿Y cómo lo arreglamos sin detener la operación?" Es la pregunta correcta. La respuesta, que he aplicado docenas de veces con variaciones según el contexto, es lo que en arquitectura de software se conoce como el patrón Strangler Fig —o lo que yo llamo desde hace años, sin eufemismos, el proceso de ahorcamiento.

La imagen es precisa y no es gratuita: la higuera estranguladora tropical crece alrededor de un árbol huésped, tomando su forma y su lugar gradualmente, hasta que el árbol original desaparece y la higuera queda en pie, sola, con su propia estructura. Así es exactamente como se sanea un sistema de datos heredado sin detener el negocio.

El proceso de ahorcamiento aplicado a sistemas de datos y componentes deficientes

El objetivo no es reemplazar el sistema de la noche a la mañana. Es rodear gradualmente cada componente deficiente con una capa nueva, validada y gobernada, hasta que el componente original puede ser desconectado sin impacto en el negocio.

1. Diagnóstico de componentes deficientes. Antes de ahorcar nada, hay que saber exactamente qué está fallando y por qué. No qué tecnología es vieja, sino qué componente entrega datos con qué nivel de calidad, hacia qué sistemas, con qué frecuencia. El diagnóstico tiene que cuantificar el impacto de negocio de cada deficiencia —no en términos técnicos, sino en términos de decisiones incorrectas, reprocesos o riesgo regulatorio.
2. Envoltura y captura (Wrap & Capture). Sin tocar el sistema origen, se implementa una capa intermediaria —un API gateway, un bus de datos, un consumer de Kafka, un proceso ETL— que intercepta la salida del componente deficiente y la normaliza, valida y enriquece antes de distribuirla. El sistema original sigue corriendo igual. Los consumidores downstream empiezan a recibir datos limpios desde la nueva capa.
3. Saneamiento progresivo de datos. Con la capa de captura activa, se ejecuta el saneamiento retroactivo: deduplicación, corrección de formatos, normalización de catálogos, resolución de inconsistencias históricas. Este proceso no interrumpe la operación. Se trabaja en paralelo con datos históricos mientras el flujo en tiempo real ya sale limpio. La prioridad de saneamiento la define el impacto de negocio, no la antigüedad del dato.
4. Validación de calidad antes de cada promoción. Ningún dato pasa de la capa de captura a los sistemas de consumo sin pasar por reglas de calidad automatizadas (Great Expectations, dbt tests, SQL assertions). Si no cumple: se rechaza, se alerta al Data Steward y se registra el incidente. No hay excepciones. Esta es la parte del proceso que más resistencia genera —y la que más valor produce a largo plazo.
5. Migración de consumidores downstream. Uno a uno, los sistemas que consumían datos del componente deficiente son migrados para consumir de la nueva capa saneada. Este paso se hace de forma controlada, con período de coexistencia (ambas fuentes activas) y validación de consistencia entre la vieja y la nueva salida antes de cortar la dependencia con la fuente original.
6. Desconexión del componente ahorcado. Cuando el último consumidor se ha migrado y la nueva capa ha operado en producción de forma estable el tiempo acordado (típicamente 30-90 días), el componente original se puede desconectar. No con un big-bang, sino con un switch silencioso que nadie nota porque el negocio ya no depende de él.
7. Documentación del linaje y el catálogo. El proceso no termina con la desconexión. Termina cuando el nuevo componente tiene su ficha completa en el catálogo de datos: metadatos técnicos y de negocio, Data Owner, clasificación, regulación aplicable, retención, score de calidad. Sin esto, el ciclo se repite en 5 años con el componente que hoy es nuevo.

Este proceso no es rápido. Un componente de mediana complejidad toma entre 3 y 6 meses para completar el ciclo. Pero es seguro y produce resultados visibles desde las primeras semanas porque la nueva capa ya empieza a entregar datos más limpios a los consumidores, incluso antes de que el componente original sea desconectado. OJO: con herramientas CASE se puede hacer refactor, más el apoyo de la IA correctamente preparada que reduce estos tiempos ahora.

⚠ La trampa de la "limpieza masiva" como proyecto únicoHe visto empresas contratar proyectos de "limpieza de datos" de 6 meses que limpian un snapshot histórico sin cambiar nada del flujo que produce los datos sucios. Resultado: 6 meses después, los datos están igual de sucios que antes. El proceso de ahorcamiento no limpia datos —cambia el proceso que los produce. Esa es la diferencia entre solucionar y parchar.

El estado de partida: lo que casi todos comparten

Antes de los tres casos, hay que ver el estado real del que partimos. No importa la industria —aerolínea, logística, seguros, fintech, retail, manufactura, gobierno. El diagnóstico inicial tiene siempre los mismos elementos:

El estado real que nadie documenta

• Datos maestros duplicados en 3 a 9 sistemas distintos, sin golden record
• "Cliente activo" tiene 4 definiciones distintas según el área que pregunte
• Reportes ejecutivos generados en Excel con macros frágiles y ajustes manuales
• Integraciones punto a punto: n sistemas generan n² dependencias sin gobernanza
• Componentes que "siempre han fallado" y que nadie toca por miedo a romper algo
• Flujos ETL sin monitoreo: se enteran del fallo cuando el reporte está vacío
• Accesos a datos sin clasificar: TI da permisos amplios porque es lo más fácil
• Proyectos de modernización que inician sin conocer la calidad real de los datos
• Cultura: "los datos son un problema de TI, no de negocio"

Lo posible con diseño correcto en 12 meses

• Golden record único por entidad maestra con linaje completo y Data Owner responsable
• Glosario de negocio con 200+ términos: una sola definición, aprobada por todos
• Reportes regulatorios y ejecutivos automatizados: 20+ horas/mes recuperadas
• Capa de integración gobernada: cambios en un sistema no propagan errores al resto
• Componentes saneados vía proceso de ahorcamiento: la deuda técnica tiene plan y fecha
• Alertas de calidad en tiempo real: el error se detecta en minutos, no en días
• Control de acceso por columna, auditado y revisado trimestralmente
• Datos confiables que aceleran —no bloquean— cualquier nueva iniciativa
• Cultura: "mis datos son mi responsabilidad y son un activo estratégico"

La diferencia entre esas dos columnas no es de años. Es de diseño, de secuencia y de quién lidera con qué convicción en los primeros 90 días. Ahora los tres casos.

En la parte 2, usaré unos caso simulados para comprender cómo se leva la práctica del gobierno de datos en tres escenarios diferentes, que abrirán tu mente y sin duda alguna te caerá el veinte, varias veces.

Jorge Mercado
#JMCoach

La startup que dejó de “planear datos” y empezó a hacer bien las cosas

 

La startup que dejó de “planear datos” y empezó a hacer bien las cosas —y a ganar por ello

Hay un momento incómodo en toda organización en crecimiento que no aparece en los reportes ni en las presentaciones estratégicas.

Se siente.

Es cuando todos trabajan más… pero el negocio se vuelve menos predecible.
Cuando hay más tecnología… pero menos claridad.
Cuando hay más datos… pero menos decisiones confiables.

Es sentir que se se nace en un boom, primer año caótico y últimos 2 rentables con patrocinio de las nubes, sin conocer el negocio con mayor claridad y aunado que la operación limita en experiencia y conciencia; por más que la tecnología se usa no rinde y se cursa un bache del cual se resurge con claridad trás un alto en el camino y replantear con otra visión y decisiones que nadie quería tomar.

Eso fue exactamente lo que vivió NovaCreditX, una fintech de crédito digital que crecía rápido -su nombre lo he cambiado, contrataba talento brillante y lanzaba productos sin parar… mientras, silenciosamente, perdía el control de su propia operación.

Lo mismo le pasó a otras empresas como una de logística que creció en el boom de la pandemia, que retomó con visión y resultados, tras implementar una solución tecnológica simple, flexible y útil; pero esa, es otra historia...

---

El crecimiento sin control no es éxito: es deuda oculta

Desde fuera, la empresa era un caso ejemplar:

• Miles de solicitudes diarias

• Aprobaciones en minutos

• Expansión acelerada

• Inversión en tecnología de punta

• Equipos altamente calificados

Desde dentro, el panorama era distinto.

La operación se había convertido en un mosaico de soluciones parciales:

• Procesos manuales incrustados en sistemas automáticos

• Hojas de cálculo “temporales” convertidas en infraestructura crítica

• Reglas de negocio que nadie podía explicar completamente

• Datos duplicados o contradictorios

• Decisiones dependientes de personas específicas

• Incidentes que se resolvían… pero no se prevenían

Funcionaba, sí.
Pero solo mientras nada saliera de lo esperado.

No había control del sistema. Había supervivencia operativa.

 

---

La tentación moderna: “metamos IA y se arregla”

Como en muchas organizaciones, la presión llegó desde arriba.

Había que “subirse a la ola”.
Había que “innovar”.
Había que “no quedarse atrás”.

Se aprobaron iniciativas simultáneas:

• Modelos predictivos sin bases de datos confiables

• Automatización de procesos no estandarizados

• Plataformas analíticas sin adopción real

• Dashboards elegantes con información inconsistente

• Consultorías con visiones incompatibles

Las ocurrencias estratégicas —muchas bien intencionadas, pocas aterrizadas— terminaron desarticulando a los equipos.

El problema no era la falta de capacidad.
Era la desconexión con la operación real.

Se estaba construyendo sofisticación sobre cimientos inestables.

---

El momento en que “cae el veinte”

El cambio no vino de un gran plan maestro.

Vino de una pregunta simple, incómoda y honesta:

“¿Entendemos realmente cómo funciona nuestro negocio día a día?”

La respuesta fue clara: no completamente.

Así que la empresa hizo algo contraintuitivo en el mundo corporativo moderno:

Detuvo la carrera por soluciones complejas y volvió a observar lo básico.

---

Entender antes de optimizar

Se mapearon los procesos completos del ciclo de crédito:

Desde la adquisición del cliente hasta la liquidación final.

Lo que emergió no fue un sistema ordenado, sino un organismo improvisado:

• Variaciones ocultas en la evaluación de riesgo

• Decisiones manuales críticas sin trazabilidad

• Cuellos de botella invisibles

• Dependencia excesiva de experiencia individual

• Falta de indicadores operativos en tiempo real

Era imposible mejorar lo que no se comprendía.

---

De operación reactiva a operación gobernada por datos

La transformación no empezó con tecnología nueva.
Empezó con control.

Se estableció una base data-driven simple pero poderosa.

Datos confiables desde la fuente

Se identificó qué información realmente sostenía el negocio:

• Identidad y perfil del cliente

• Historial crediticio

• Comportamiento de pago

• Variables de riesgo

• Estado de cada crédito

• Interacciones con la empresa

Se eliminaron duplicidades y “traducciones manuales”.

---

Visibilidad operativa en tiempo real

Por primera vez, la organización pudo ver lo que estaba ocurriendo mientras ocurría:

• Volumen de solicitudes

• Tiempos reales de decisión

• Saturación de procesos

• Incidentes operativos

• Desempeño de modelos

La operación dejó de ser una caja negra.

---

IA aplicada donde sí hacía diferencia

Solo después de estabilizar datos y procesos, la inteligencia artificial empezó a generar valor real:

• Identificación temprana de fraude

• Priorización de solicitudes rentables

• Ajuste dinámico de límites de crédito

• Predicción de morosidad

• Automatización de decisiones repetitivas

La IA dejó de amplificar el caos y empezó a amplificar la eficiencia.

---

Mejor cartera, mejores clientes, mejor negocio

Con decisiones más precisas, cambió la composición de la base de clientes.

La empresa dejó de perseguir volumen y comenzó a construir valor.

Se observó un efecto dominó:

• Mejor calificación de solicitantes

• Menor morosidad temprana

• Mayor cumplimiento de pagos

• Incremento en recurrencia

• Adopción de nuevos productos

Clientes que antes tomaban un crédito aislado comenzaron a establecer relaciones financieras continuas.

Pagaban.
Regresaban.
Confiaban.

---

Engagement basado en comprensión, no en presión

Al conocer mejor a sus usuarios, la empresa pudo ofrecer:

• Límites acordes a su capacidad real

• Ofertas personalizadas

• Calendarios de pago viables

• Productos relevantes en el momento correcto

El crédito dejó de ser un recurso de emergencia y se convirtió en una herramienta útil.

---

Seguridad y privacidad: de obligación a ventaja

El crecimiento acelerado había dejado vulnerabilidades importantes.

La nueva estrategia incorporó protección de datos desde el diseño:

• Clasificación de información sensible

• Acceso basado en roles

• Monitoreo de uso indebido

• Trazabilidad de cambios

• Protección de datos financieros

Se alinearon prácticas con estándares internacionales como:

• Gestión de riesgos de ciberseguridad del NIST

• Protección de datos de pagos del PCI Security Standards Council

Esto no solo redujo riesgos legales.

Incrementó la confianza de clientes, socios e inversionistas.

---

Arquitectura simple, escalable y orientada al dato

El sistema original había crecido por acumulación de soluciones.

El rediseño siguió un principio radical:

Que la tecnología refleje el negocio, no su historia de parches.

Se construyó una plataforma:

• Modular

• Interoperable

• Escalable

• Preparada para analítica

• Orientada a dominios de negocio

Una arquitectura pensada para ser data-driven desde su base.

---

Tableros que permiten decidir, no solo reportar

El Cuadro de Mando Integral dejó de ser un ritual corporativo y se volvió una herramienta diaria.

Financiero

Rentabilidad real por cliente y producto.

Clientes

Valor de vida y comportamiento.

Procesos

Eficiencia y puntos críticos.

Innovación

Capacidad de adaptación.

Las decisiones comenzaron a basarse en información actual, no en reportes históricos.

---

El cambio decisivo fue cultural

La tecnología dio control.
La cultura le dio dirección.

Se instauró una mentalidad simple y poderosa:

• Resolver antes que justificar

• Medir antes que opinar

• Priorizar impacto sobre apariencia

• Aprender del campo, no solo de los dashboards

Equipos pequeños, autónomos y responsables comenzaron a cerrar ciclos completos de valor.

---

Cuando la empresa recuperó su capacidad de anticipar

Con el tiempo, algo cambió en la calidad de las conversaciones estratégicas.

Los problemas se identificaban antes de escalar.
Las negociaciones se volvían más sólidas.
Las decisiones eran coherentes incluso bajo presión.

Habían alcanzado lo que internamente se denominó:

El “pulso de la empresa”

Un conocimiento vivo del negocio que integra:

• Operación diaria real

• Dinámica financiera

• Comportamiento de clientes

• Riesgos latentes

• Entorno competitivo

• Capacidades reales

Este concepto —conocido como el “pulso de la empresa” de Jorge Mercado— no es un dashboard ni un modelo analítico.

Es conciencia organizacional.

La capacidad de:

• Decidir con información al momento

• Negociar con fundamento

• Anticipar escenarios

• Actuar con claridad en incertidumbre

---

Por qué este artículo importa para cualquier líder (no solo fintech)

No importa si eres fundador, C-Level, gerente o líder de equipo.

El problema es el mismo en casi todas las organizaciones:

Trabajar más no equivale a trabajar mejor.
Invertir más en tecnología no garantiza mejores decisiones.
Implementar IA no sustituye comprender el negocio.

---

La lección que hace “caer el veinte”

Las empresas que prosperan no son las más sofisticadas.

Son las más claras.

Las que:

✔ Entienden su operación real
✔ Gobiernan sus datos
✔ Protegen la información crítica
✔ Deciden con evidencia
✔ Construyen capacidades sostenibles
✔ Mantienen coherencia entre estrategia y ejecución

Porque al final:

La ventaja competitiva no es la tecnología.
Es entender tu negocio mejor que nadie… y actuar en consecuencia.

Por Jorge Mercado

#JMCoach