Consideraciones al construir una solución de Master Data Management (MDM)
-
Upload
software-guru -
Category
Software
-
view
545 -
download
1
description
Transcript of Consideraciones al construir una solución de Master Data Management (MDM)
Master Data Management Consideraciones al implementar una solución a la medida
Artemio Mendoza García
-‐ CEO TaeIT US: -‐ [email protected]
-‐ CTO Sullexis: -‐ [email protected]
De acuerdo a David Loshin*, una iniciativa MDM trata de:
“crear un registro que, de manera única, enumere todas las instancias de una clase de objetos de
información, que son relevantes a una comunidad participante”
* Loshin David, Master Data Management, Morgan Kaufman, 2009
¿Qué es MDM?
MDM y el Fútbol Chicharito Hernandez México # 14
Chicharito Manchester
Little Pea Red Devils
Chicharito Hernandez Guadalajara #14
Javier Hernandez México # 14
El Chicharito
Golden Record (Golden Pea?)
Chicharito Hernández México # 14
Little Pea Manchester
Chicharito Red Devils
Chicharito Guadalajara #14
Javier Hernández México # 9
Javier Hernández Balcázar México #14 Manchester United F.C. #14
Diferente Clase de chícharo!
* Objetivo: compartir guias prácticas para construir soluciones MDM * Los consejos expuestos son el resultado de la experiencia personal * Los errores expuestos fueron cometidos previamente (mea culpa) * No es una guía exahustiva, sin embargo, abarca errores comunes * Interrumpir para compartir experiencias
Objetivo y premisas
Cuandrante mágico de Gartner
• MDM es una práctica Madura • Existen diversos proveedores de
soluciones en el mercado • Integrados a ERPS, uso “automático” de
dominios por módulos – CRM, HR, MM, etc • Especialización por dominios:
• Clientes • Proveedores • Materiales • Empleados
• Nuevos jugadores, tendencia hacia MDM ágil y multidominio
MDM a la Medida
Independientemente de si es conveniente o no, o si es económicamente viable, las soluciones a la medida existen en el mundo real
* Crear llaves artificiales (surrogate key) para todos los objetos provienientes de la fuente
* Identificar cada registro con el Sistema de Origen * CRM, ERP, Sistema de Crédito, Sistema de Ventas, etc
* Usar funciones hash para comparar registros existentes y para validar la integridad de datos * Agregar columnas de metadat para: * Fechas ingreso/update * Usuario que insertó/modificó * Motivo de cambio * Estado del registro (válido, inválido) * Borrado lógico
Consideraciones iniciales: ¡quick wins!
* Por razones técnicas y razones legales, todo cambio realizado a los datos debe ser auditable, mínimamente: * Cual era el valor original * Cual es el valor actual * Quien lo cambió * Motivo del cambio * Fecha de cambio
Usar Area de Landing/Staging
• El uso de Area de Staging y area de Landing facilita mantener la historia
• Si es necesario, crear llaves artificiales (surrogate keys) en Landing
* Evitar Modelos E-‐R complejos * Uso de Modelos Canónicos simples (tipo estrella)
Uso de modelos simples
Simple, fácil de leer, Entender y mantener Complejo, dificil de leer, de implementar
y mantener. Probablemente contiene transacciones
* Crear Golden Record como un registro artificial: !No Seleccionar un registro como Golden y descartar el resto!
* La clave consiste en crear clusters, y luego asociarlos a un Golden Record creado artificialmente. Fácil mantenimiento, sin perdida de datos * Los objetos similares se agrupan en clúster * Los objetos duplicados se marcan como duplicados y
(eventualmente) se resuelven en la fuente
Crear cluster, luego Golden Records
* En DWH (tradicional) : * !No modificar datos! * El objetivo es reportar lo que existe
* En MDM: * es perfectamente razonable, y esperado, que los datos de la
fuente sean erroneos (o incompletos). * Uno de los objetivos es encontrar esas inconsistencias y
corregirlas * Enviar datos erróneos a la fuente, uno de los objetivos a
mediano y largo plazo -‐ Harmonización.
Técnicas de DWH vs MDM
* Evitar la tentación de “recargar y reprocesar” el universo completo * Para los Data Stewards, verificar datos puede ser eterno * Posible consecuencia: deprecación no deseada/manejo complejo. * Posible fragmentación de datos
* ¿Que hacer? * Carga inicial con un SOE (Trusted Source) * Primer ronda de DQ & Match & Merge -‐ Golden * Segunda y tercer ronda -‐ publicar * Cargar siguiente fuente (s), y compara contra Golden * Solo cargar lo que haya cambiado (uso de Hash keys) * !Cuidar los datos que ya han sido cargados y validados!
Técnicas de DWH vs MDM
* Identificar Datos Maestros ¿tarea fácil?
son aquellos que no cambian (mucho) en el tiempo. Las transacciones son aquellas que existen durante un periodo del tiempo, son dinámicas, y ocurren sobre los datos maestros.
* Diferenciarlos, en la práctica, puede ser tarea complicada:
* Contratos: supermercado vs Agencia de Publicidad/compañías de reaseguros * Ordenes de Compra: ¿que pasa con blanket POs? – estáticas en naturaleza * Ciudades, estados, países – ¿datos de referencia? Para algunas empresas, existen países que son
creados artificialmente, o sus datos son enriquecidos en forma tal, que tienen que ser centralizado
* ¿Que pasa cuando se introducen Transacciones en la solución de Datos Maestros? * ¿esto nunca ocurre en la práctica? * ¿Como minimizar, por diseño, que esto suceda?
Master vs Transactional
* La implementación de una iniciativa de MDM es una solución que necesita ser planeada con cuidado * No importa el cuidado que se ponga al planear, seguramente habrá que modificar el diseño y re-‐trabajar los modelos * Por lo tanto, la mejor estrategia es aquella que nos permite adaptarnos rápidamente * ¿MDM ágil?
Conclusiones
¿Preguntas, comentarios?
“No vale la pena llegar a la meta si uno no disfruta del viaje”
-Roger Martínez
González