Bacardi People MDM

Construir el golden record de personas de Bacardi: una visión única y confiable de quién trabaja dónde, a quién reporta y dentro de qué estructura comercial se sitúa. El pipeline ancla en el IdP corporativo (identidad HR-grade) y reconcilia de forma determinística contra el master comercial SAP y la vista comercial unificada, para que la analítica downstream y los agentes de IA dejen de reconstruir cada uno su propio lookup de personas.

Mi rol

Ingeniero de datos

Período

2026

Estado

En producción

Stack

DatabricksPythonDelta Lake

Pipeline Python de siete etapas sobre Databricks y Delta Lake que ancla la identidad en el IdP corporativo y enriquece con SAP y la vista comercial unificada en survivorship aditivo, con materialización dual silver/gold.

1. Caché de tablas de referencia con descripciones de la jerarquía de organización de ventas.
2. Filtro de miembros activos en el lado IdP y exclusión por flag de borrado en el lado SFA.
3. Normalización: lower/trim sobre email, upper/trim sobre nombres y sanity check ISO-2 de país.
4. Match en cascada determinística anclada en el UID del IdP, con Employee ID y email como pasos.
5. Routing del resultado a AutoApproved Full o Partial, IdpOnly o SFA Orphan según completitud.
6. Ensamblado por survivorship aditivo a través de cuatro zonas — sin conflicto cruzado entre fuentes.
7. Materialización dual: silver físico en SCD2 más golden expuesto vía CREATE OR REPLACE VIEW.

La vista comercial unificada como feeder de la zona de clasificación.

La identidad sigue anclada al IdP corporativo más la dimensión SFA; la clasificación comercial — distribuidor, equipo, status — viene de la vista unificada. Replica el patrón arquitectónico ya probado en el motor hermano de account matching, mantiene zonas distintas con fuentes distintas y previene conflictos a nivel de campo en el survivorship.

Match key en cascada determinística sin fuzzy en v1.

Primero el Employee ID corporativo cuando esté presente — determinístico pero con cobertura insuficiente para servir como join key universal —, después email lowercased y trimmed como puente universal. Sin fallback fuzzy, fonético ni proxy de dirección en v1: mantiene el comportamiento auditable y deja la decisión sobre fuzzy/ML para cuando los datos hablen.

Materialización dual silver/gold con SCD2 abajo y vista filtrada arriba.

El silver es una tabla SCD2 física donde ingenieros y auditores acceden a la historia completa de cambios; el gold es una vista que filtra registros vigentes para consumo analítico. Alinea con la convención masterdata establecida por el lead vendor y separa de forma limpia el contrato de auditoría del contrato de consumo.

Estrategia fuzzy/ML diferida hasta recomendación basada en datos.

El v1 entrega solo la cascada determinística. La incorporación de fuzzy o ML para residuales unmatched queda en espera del pre-flight sobre datos reales. Principio ancla: shipping determinístico primero, medir y luego decidir. El motor hermano de account matching usa ML porque procesa volúmenes mucho mayores; aquí los joins SAP son determinísticos y la escala es más baja, así que ML probablemente no aporte, pero la recomendación final será data-driven.

Estado actual

Cross-comparison report sobre el extracto del IdP cerrado; el strategy log está ratificado a través de cuatro decisiones; el esqueleto de la arquitectura productiva está dibujado con todas las firmas de etapa, definiciones de zona y reglas de survivorship.

En vuelo

Pre-flight de match-rate sobre datos silver reales, dry-run de la cascada determinística y recomendación sobre si v2 necesita fuzzy o ML según la fracción de unmatched que quede al cierre del análisis.

Próximos pasos

Implementación del pipeline de siete etapas y resolución de cuatro preguntas arquitectónicas abiertas: alcance del filtro de la vista golden, columna del flag de borrado, rank de survivorship multi-fila y aserción post-load sobre la consistencia de la cadena de manager.