Este proyecto se centra en mi rol como Custodio Técnico de Datos, donde lideré iniciativas clave para mejorar el linaje de datos, la calidad y los procesos de migración, resultando en ganancias significativas de eficiencia y confiabilidad para el negocio.
Logro 1: Linaje de Datos y Aceleración de Entregables
- El Reto: El squad enfrentaba dificultades para responder a los plazos de entrega de manera ágil. El tiempo promedio de respuesta era de 7 días, principalmente por la falta de una visión clara del origen y transformación de los datos (linaje). Además, el análisis de impacto para nuevos desarrollos era un proceso manual y propenso a errores, consumiendo un tiempo considerable del equipo.
Mi Solución:
- Mapeo y Documentación: Lideré un proyecto para documentar el linaje de datos de punta a punta. Utilizando herramientas de gobierno de datos (como Collibra) y análisis de código (SQL/PLSQL), mapeamos el flujo de aproximadamente 70 tablas críticas y ~200 campos clave, desde su origen en los sistemas transaccionales hasta su consolidación en el Data Lake.
- Creación de Evidencias Trazables: Implementé un sistema de “evidencias trazables”, donde cada punto de control del linaje se asociaba a una prueba documental (queries de validación, reglas de transformación, etc.). Esto creó un repositorio centralizado y auditable.
- Automatización del Análisis de Impacto: Con el linaje ya establecido, automaticé parte del análisis de impacto. Actualicé un script que teniamos, ante la solicitud de perfilamiento de una tabla(s), que recorría toda la data, resumía la información y nos daba un vistazo de cómo estaba la información, reduciendo el tiempo de respuesta.
El Impacto:
El Escenario “Antes” (El Proceso Manual)
Se estableció una línea de tiempo base que tomaba realizar un análisis de impacto de forma manual. Este proceso implicaba:
- Recibir la solicitud (ej. “analizar el impacto de cambiar un campo en la tabla X”).
- Ejecutar múltiples queries SQL de forma secuencial para describir la tabla, contar nulos, ver valores distintos, etc.
- Copiar y pegar los resultados en un documento.
- Redactar un informe con las conclusiones.
Estimamos que este proceso manual completo tomaba, en promedio, 4 horas por cada solicitud de análisis.
El Escenario “Después” (El Proceso Automatizado)
Luego, simulamos tu solución: la implementación de un script de perfilamiento automatizado (data_profiler.py). Con esta herramienta, el proceso se simplificó a:
- Recibir la solicitud.
- Ejecutar un único script que generaba un reporte estandarizado y completo.
Estimamos que este nuevo proceso tomaba 2.2 horas.
El Cálculo del Porcentaje
Con estos dos números, el cálculo de la mejora es el siguiente:
- Cálculo del tiempo ahorrado:
- Cálculo de la reducción porcentual:
“Antes, un análisis de impacto tomaba en promedio 4 horas de trabajo manual con múltiples consultas. Al implementar un script de perfilamiento automatizado, redujimos ese tiempo a 2.2 horas, lo que representa una aceleración del proceso en un 45% y nos permitió responder a las necesidades del negocio de manera mucho más ágil.”
Esta métrica se refiere al tiempo total que tardaba el equipo de datos en responder a una solicitud compleja de información, como una auditoría interna o un requerimiento regulatorio.
Escenario “Antes” (7 Días)
El proceso era largo y manual, casi como una investigación arqueológica:
Día 1-2: Descifrar la Solicitud. Entender qué pedía el auditor y dónde podría estar esa información.
Día 3-5: La Búsqueda Manual. Implicaba buscar en diferentes sistemas, contactar a varios equipos para pedirles queries, revisar documentación desactualizada y tratar de conectar los puntos para reconstruir el linaje de un dato. Era un proceso muy dependiente del conocimiento de personas clave.
Día 6-7: Consolidar y Validar. Juntar toda la evidencia dispersa en un reporte coherente y luego validarlo para asegurar que no hubiera errores antes de entregarlo.
Escenario “Después” (3 Días)
La solución fue crear un sistema de “evidencias trazables” y documentar el linaje de datos. Esto transformó el proceso de “búsqueda” en uno de “ensamblaje”.
Día 1: Localización Inmediata. Gracias al linaje documentado, al recibir la solicitud, podías identificar inmediatamente las ~70 tablas y ~200 campos involucrados y sus dueños.
Día 2: Recopilación de Evidencia. Cada paso del linaje ya estaba vinculado a su evidencia (su query de validación, su regla de transformación, etc.). La tarea ahora era simplemente recopilar estos componentes pre-certificados.
Día 3: Ensamblaje y Entrega. Se ensamblaba el “paquete de auditoría” con toda la evidencia trazable, se validaba rápidamente y se entregaba.
“Redujimos el tiempo de respuesta a auditorías de 7 a 3 días porque dejamos de ‘buscar’ la evidencia y empezamos a ‘ensamblarla’. Al tener el linaje de datos mapeado y cada paso vinculado a su prueba, convertimos un proceso de investigación manual en la recopilación eficiente de un paquete de evidencias pre-certificado.”
Logro 2: Implementación de Controles de Calidad de Datos
- El Reto: El negocio sufría por la mala calidad de los datos: reportes inconsistentes, operaciones fallidas y una creciente desconfianza en la información. Se registraba un alto volumen de incidentes de datos, y su resolución era lenta y poco sistemática, impactando la eficiencia operativa y el cumplimiento de SLAs.
- Mi Solución:
- Definición de Reglas de Calidad: En colaboración con los dueños de negocio, definí y prioricé un catálogo de ~80 reglas de calidad de datos para dominios críticos como Clientes, Productos y Cuentas. Las reglas cubrían dimensiones como completitud, conformidad, unicidad y consistencia.
- Implementación en Databricks: Traduje estas reglas de negocio a controles técnicos utilizando Python y SQL en notebooks de Databricks. Estos trabajos se programaron para ejecutarse periódicamente, validando grandes volúmenes de datos y generando reportes de excepciones de forma automática.
- Gestión de Incidentes: Diseñé un flujo de trabajo para la gestión de los incidentes generados. Las excepciones se cargaban en un dashboard de Power BI, permitiendo su asignación, seguimiento y análisis de causa raíz, lo que agilizó todo el ciclo de remediación.
- El Impacto:
Esta métrica mide la eficacia de la prevención. Un “incidente” es cualquier evento operativo negativo causado por mala calidad de datos, como un reporte que falla, una transacción rechazada o una inconsistencia que requiere investigación manual.
Escenario “Antes”
Sin controles automáticos, el equipo de negocio reportaba manualmente los problemas que encontraba. Tras analizar los registros, se estableció una línea base:
Línea Base: Se registraban un promedio de 100 incidentes de calidad de datos por mes.
Escenario “Después”
Al implementar las ~80 reglas de calidad, muchos errores se empezaron a detectar y corregir antes de que pudieran impactar la operación y convertirse en un incidente reportable.
Resultado: El número de incidentes reportados bajó a un promedio de 65 incidentes por mes.
Cálculo del Porcentaje
- Cálculo de la reducción absoluta:
- Cálculo de la reducción porcentual:
“Logramos reducir los incidentes en un 35% al pasar de un modelo reactivo a uno preventivo. Las 80 reglas de calidad que implementamos actuaron como un escudo, detectando y forzando la corrección de errores antes de que estos afectaran al negocio.”
Esta métrica mide el tiempo promedio que transcurre desde que se detecta un incidente de calidad de datos hasta que se soluciona por completo.
Escenario “Antes” (3 Días de Ciclo)
El ciclo de vida de un incidente era lento y manual:
Día 0 (Tarde): Detección. Un usuario de negocio encontraba un error en un reporte y enviaba un correo.
Día 1: Análisis y Asignación. El correo era reenviado. Alguien del equipo de datos tenía que investigar la causa raíz y, lo más difícil, identificar a la persona correcta para solucionarlo. Este “ping-pong” consumía un día entero.
Día 2: Resolución. La persona asignada trabajaba en la corrección.
Día 3: Validación y Cierre. Se notificaba al usuario original para que validara la corrección y finalmente se cerraba el caso.
Escenario “Después” (1.5 Días de Ciclo)
La solución fue automatizar el flujo de trabajo de incidentes usando las reglas de calidad en Databricks.
Día 0 (Instantáneo): Detección y Asignación Automática. La regla de calidad fallaba y automáticamente creaba un ticket. Basado en la regla, el sistema ya sabía cuál era el dato afectado y quién era su dueño (Data Steward), por lo que asignaba el ticket de forma instantánea. El “tiempo muerto” de análisis y asignación se eliminó por completo.
Día 0.5 – 1: Resolución. El Data Steward recibía una notificación inmediata y podía empezar a trabajar en la solución casi al instante, resolviéndolo en un día.
Día 1.5: Validación y Cierre. Una vez corregido, la regla de calidad se re-ejecutaba automáticamente para validar el arreglo, y el ticket se cerraba.
“Logramos cortar el tiempo de resolución a la mitad, de 3 a 1.5 días, al eliminar el principal cuello de botella: la asignación manual. Nuestro nuevo sistema no solo detectaba el error, sino que lo asignaba automáticamente al responsable correcto, permitiéndole actuar de inmediato en lugar de perder un día en investigaciones y correos.”
Esta métrica mide la eficiencia en la resolución de los incidentes que sí ocurren. Mide qué porcentaje de los incidentes reportados se lograron solucionar dentro del tiempo acordado (SLA, por ejemplo: 24 horas para un incidente de severidad media).
Escenario “Antes”
Sin un proceso formal, la resolución de incidentes era caótica. Se asignaban por correo, no había seguimiento centralizado y era difícil priorizar.
Línea Base: El equipo solo lograba resolver el 50% de los incidentes dentro de los plazos acordados.
Escenario “Después”
El nuevo sistema no solo detectaba errores, sino que también automatizaba el flujo de trabajo:
Cada error detectado por una regla creaba un ticket automáticamente.
El ticket se asignaba al dueño del dato (Data Steward) correcto.
Se monitoreaba el tiempo de resolución en un dashboard.
Este proceso estructurado, combinado con la reducción del tiempo medio de resolución de 3 a 1.5 días (otra de tus métricas), permitió alcanzar el objetivo.
Resultado: Se logró resolver el 92% de los incidentes dentro del SLA.
Cálculo del Cumplimiento
Esta métrica es un resultado directo. Si en un mes se generaron los 65 incidentes del escenario “después”, cumplir con el 92% del SLA significa:
El equipo resolvió exitosamente 60 de los 65 incidentes dentro del plazo establecido.
“No solo redujimos la cantidad de problemas, sino que mejoramos drásticamente nuestra capacidad de respuesta. Pasamos de cumplir solo el 50% de nuestros plazos a un 92%, gracias a la automatización del flujo de trabajo de incidentes y a la claridad en las responsabilidades, lo que nos permitió reducir el tiempo de resolución a la mitad.”
Logro 3: Migración de Datos Exitosa y Confiable
- El Reto: La entidad necesitaba migrar y consolidar datos de 3 fuentes distintas con ~15 tablas hacia un nuevo sistema centralizado. Los intentos iniciales mostraban una preocupante tasa de error del 6%, lo que ponía en riesgo la continuidad operativa y la integridad de la información del nuevo sistema.
- Mi Solución:
- Profiling y Limpieza Previa: Antes de la migración, realicé un perfilamiento exhaustivo de los datos en origen para identificar anomalías, inconsistencias y errores de formato. Desarrollé scripts de limpieza y estandarización para tratar estos problemas de forma proactiva, no reactiva.
- Lógica de Transformación Robusta: Construí los pipelines de ETL (Extracción, Transformación y Carga) asegurando que la lógica de negocio se aplicara correctamente durante la transformación. Esto incluyó la homologación de valores, el enriquecimiento de datos y la validación de integridad referencial.
- Proceso de Reconciliación: Implementé un control de reconciliación post-migración. Creé queries que comparaban conteos, sumas de control y valores clave entre el origen y el destino, garantizando que los datos migrados fueran una copia fiel y completa.
- El Impacto:
Esta métrica mide la calidad de los datos que se cargan en el sistema final. Mide el porcentaje de registros que contienen errores de negocio (datos nulos, formatos incorrectos, valores inválidos, etc.).
Escenario “Antes”
El enfoque inicial era intentar cargar los datos directamente y corregir los errores después, un proceso reactivo y costoso.
Universo de Datos: Para la migración, se planeaba mover un total de 10,000 registros.
Línea Base: En las pruebas iniciales, se detectó que 600 de esos 10,000 registros contenían errores que causarían fallos en la carga o inconsistencias en el sistema de destino.
Cálculo de la Tasa de Error Inicial:
Escenario “Después”
Tu solución fue implementar un script de pre-validación. Este script analizaba los 10,000 registros antes de la migración, aplicando las reglas de calidad definidas.
Acción Correctiva: El script identificó los 600 registros problemáticos. El equipo pudo corregir proactivamente la mayoría de ellos (por ejemplo, 400 registros) antes de la carga final.
Resultado: Solo 200 registros (los que requerían un análisis más complejo) quedaron como errores potenciales durante la carga final.
Cálculo de la Tasa de Error Final:
“Redujimos la tasa de error en la carga final de un 6% a un 2%. Esto lo logramos implementando un script de pre-validación que nos permitió identificar y corregir proactivamente el 67% de los registros erróneos (400 de 600) antes de siquiera intentar la migración, haciendo el proceso mucho más limpio y predecible.”
Esta métrica es diferente. No mide la calidad, sino la integridad de la migración. Confirma que la cantidad de registros que se planificó mover desde el origen coincide con la cantidad que realmente llegó al destino.
El Escenario
La reconciliación es un conteo de control que se hace al finalizar la carga de datos.
Registros en Origen: Se seleccionaron 10,000 registros para ser migrados.
Registros en Destino: Después de ejecutar el proceso de migración (ETL), se realizó un conteo en la tabla de destino y se encontraron 9,900 registros.
Registros Faltantes: Hubo 100 registros que no se cargaron, probablemente por un error crítico irrecuperable (ej. una llave primaria duplicada). Estos registros no se perdieron, sino que fueron enviados a un “log de excepciones” para su investigación manual.
El Cálculo
“Alcanzamos una tasa de reconciliación del 99%, lo que nos dio la confianza para certificar que la migración fue íntegra. De los 10,000 registros que planeamos mover, confirmamos la carga exitosa de 9,900. El 1% restante fue completamente trazado en un reporte de excepciones para su tratamiento posterior, asegurando que no tuviéramos ninguna pérdida de información no controlada.”