Master Data Management base critica de un negocio esta dentro de 4 puntos , gente , lugar , cosa y concepto , estas areas

son llamadas , subject areas . Por ejemplo el area de gente esta conformada por clientes , empleados , vendedores , en cosas tenemos producto , almacen etc , en concepto estan incluidos contrato garanta y licencia , por ultimo en lugares tenemos oficinas , locaciones y divisiones geogrficas Un proyecto de MDM debe de ser influenciado por requerimientos , prioridades , disponibilidad de recursos , cuadro de tiempos y tamao del problema La mayoria de los proyectos de MDM incluyen al menos estas fases : Identificar Fuentes de Master Data , este paso es usualmente un ejercicio revelador , algunas compaias encuentran que tienen docenas de bases de datos que contienen datos de clientes que el departamento de sistemas no saban que existian Identificar productores y consumidores de Master Data Cuales aplicaciones producen los datos maestros identificados en el primer paso (generalmente dificil de determinar) , cuales aplicaciones usan los datos maestros , dependiendo del approach que se use para el mantenimiento de datos maestros , este paso puede ser no necesario , por ejemplo , si todos los cambios son detectados y manejados a nivel de base de datos , probablemente no importa de donde viene los cambios Recolectar y analizar metadata sobre tus datos maestros Para todas las Fuentes identificadas en el paso 1 , cuales son los atributos de los datos y que significan , esto debe de incluir , nombre , tipo de dato , valores permitidos , valores por default , dependencias y quien es el dueo de la definicin y mantenimiento de los datos , el owner es el mas dificil de determinar , Si usted tiene un repositorio cargado con todos sus metadatos, este paso es fcil. Si usted tiene que comenzar a partir de tablas de bases de datos y cdigo fuente, esto podra ser un esfuerzo significativo. Nombrar a los administradores de datos. Estas deben ser las personas con el conocimiento de las fuentes de datos actuales y la capacidad de determinar la manera de transformar la fuente en el formato de datos maestros. En general, los delegados deben ser elegidos los propietarios de cada fuente de datos maestros, los arquitectos responsables de los sistemas de gestin de datos maestros y representantes de los usuarios de negocio de los datos maestros. Implementar un programa de datos-gobierno y del consejo de gobierno de datos. Este grupo debe tener el conocimiento y la autoridad para tomar decisiones sobre cmo se mantiene los datos maestros, lo que contiene, el tiempo que se mantiene, y cmo los cambios estn autorizados y auditados. Cientos de decisiones deben ser tomadas en el curso de un proyecto de datos maestros, y si no hay un rgano de toma de decisiones bien definido y el proceso, el proyecto puede fallar, porque la poltica impiden la toma de decisiones eficaz.

Desarrollar el modelo de datos maestros. Decida lo que los registros maestros ven como : qu atributos se incluyen , el tamao y el tipo de datos son, qu valores se les permite , y as sucesivamente. Este paso tambin debe incluir la asignacin entre el modelo de datos maestros y las fuentes de datos actuales. Esto es normalmente tanto el paso ms importante y ms difcil del proceso. Si usted trata de hacer felices a todos al incluir a todos los atributos de origen de la entidad principal, que a menudo terminan con los datos maestros que es demasiado complejo y engorroso para ser til. Por ejemplo, si usted no puede decidir si el peso debe estar en libras o kilogramos , una posibilidad sera incluir ( WeightLb y WeightKg ) . Si bien esto puede hacer que la gente feliz, que est perdiendo megabytes de almacenamiento para los nmeros que se pueden calcular en microsegundos , as como correr el riesgo de crear datos inconsistentes ( WeightLb = 5 y WeightKg = 5 ) . Si bien este es un ejemplo bastante trivial, un problema ms grande sera mantener mltiples nmeros de parte de la misma pieza. Como en cualquier esfuerzo del comit , habr peleas y ofertas resultantes de decisiones sub - ptimas. Es importante trabajar en el proceso de decisin , las prioridades y toma las decisiones finales con antelacin , para que las cosas funcionen bien .
Desarrollar el modelo de datos maestros. Decida lo que los registros maestros ven como : qu atributos se incluyen , el tamao y el datatype que elegir un conjunto de herramientas . Usted tendr que comprar o construir herramientas para crear las listas de maestros por la limpieza , transformacin, y la fusin de los datos de origen . Usted tambin necesitar una infraestructura de usar y mantener la lista maestra . Estas funciones se describen en detalle ms adelante en el documento. Puede utilizar un solo conjunto de herramientas de un solo proveedor para todas estas funciones , o es posible que desee adoptar un enfoque mejor de su clase . En general , las tcnicas para limpiar y combinar los datos son diferentes para los distintos tipos de datos, por lo que no hay un montn de herramientas que abarcan toda la gama de datos maestros. Las dos principales categoras de herramientas de integracin de datos del cliente (CDI ) herramientas para crear el maestro de clientes y gestin de la informacin de productos ( PIM ) herramientas para la creacin del maestro de productos . Algunas herramientas se hacen ambas cosas , pero por lo general son mejores a la una o la otra . El conjunto de herramientas tambin debe tener el apoyo para encontrar y solucionar problemas de calidad de datos y el mantenimiento de versiones y jerarquas. Versiones es una caracterstica fundamental , porque la comprensin de la historia de un registro de datos maestros es vital para mantener la calidad y la precisin en el tiempo. Por ejemplo , si una herramienta de combinacin combina dos registros para John Smith , en Boston, y usted decide realmente hay dos diferentes Smiths John en Boston, lo que necesita saber lo que los registros parecan antes de que se fusionaron , con el fin de " desunir " a .

El diseo de la infraestructura. Una vez que tenga los datos maestros limpios y consistentes, que tendr que exponer a sus aplicaciones y ofrecer procesos para gestionar y mantener. Este paso es un gran problema, lo suficiente, dedico un apartado a ella ms adelante en el documento. Cuando se lleva a cabo esta infraestructura, que tendr una serie de aplicaciones que dependen de l que est disponible, por lo que la fiabilidad y la escalabilidad son consideraciones importantes para incluir en su diseo. En la mayora de los casos, usted tendr que poner en prctica una parte significativa de la infraestructura de ti mismo, porque va a ser diseado para encajar en su infraestructura actual, plataformas y aplicaciones .

Generar y probar los datos maestros. Este paso es el que utiliza las herramientas que se han desarrollado o adquirido para combinar los datos de origen en su lista de datos maestros. Esto es a menudo un proceso que requiere retoques con las normas y los ajustes para obtener el derecho a juego iterativo. Este proceso tambin requiere de mucho control manual para asegurarse de que los resultados son correctos y cumplen los requisitos establecidos para el proyecto. Ninguna herramienta obtendr el juego se hace correctamente el 100 por ciento de las veces, por lo que tendr que sopesar las consecuencias de los falsos partidos contra partidos perdidos para determinar cmo configurar las herramientas de correlacin. Partidos falsos pueden conducir a la insatisfaccin del cliente, si las facturas son inexactos o la persona equivocada es arrestado. Demasiados partidos perdidos hacen que los datos maestros menos til, ya que no estn recibiendo los beneficios que invirti en MDM de conseguir. Modificar los sistemas de productores y consumidores . Dependiendo de la implementacin de MDM est diseada , puede que tenga que cambiar los sistemas que producen , mantienen o utilizan los datos maestros para trabajar con la nueva fuente de datos maestros. Si se utilizan los datos master en un sistema separado de la fuente de los sistemas de un almacn de datos , por ejemplo , los sistemas de origen puede que no tenga que cambiar . Si los sistemas de origen van a utilizar los datos maestros , sin embargo , es probable que haya cambios requeridos . Cualquiera de los sistemas de origen tendrn que acceder a los nuevos datos maestros y los datos maestros tendrn que estar sincronizado con los sistemas de origen , de modo que los sistemas de origen tienen una copia de los datos maestros limpiado - para usar . Si no es posible cambiar uno o ms de los sistemas de origen , ya sea que el sistema de origen puede que no sea capaz de utilizar los datos maestros o los datos maestros tendrn que integrarse con la base de datos del sistema de origen a travs de procesos externos, como disparadores y SQL comandos . Los sistemas de fuentes generadoras de nuevos registros deben ser cambiados para buscar conjuntos de registros maestros existentes antes de crear nuevos registros o actualizar registros maestros existentes. Esto asegura que la calidad de los datos que se generan aguas arriba es bueno , por lo que el MDM puede funcionar de manera ms eficiente y de la propia aplicacin gestiona calidad de los datos . MDM debe ser aprovechada no slo como un sistema de registro , sino tambin como una aplicacin que promueve el manejo ms limpio y ms eficiente de los datos en todas las aplicaciones de la empresa . Como parte de la estrategia MDM , los tres pilares de la gestin de los datos tienen que ser estudiado :

los datos de originacin , gestin de datos , y los datos de consumo. No es posible tener una estrategia MDM nivel empresarial robusta si se omite uno cualquiera de estos aspectos

Modificar los sistemas de productores y consumidores . Dependiendo de la implementacin de MDM est diseada , puede que tenga que cambiar los sistemas que producen , mantienen o utilizan los datos maestros para trabajar con la nueva fuente de datos maestros. Si se utilizan los datos master en un sistema separado de la fuente de los sistemas de un almacn de datos , por ejemplo , los sistemas de origen puede que no tenga que cambiar . Si los sistemas de origen van a utilizar los datos maestros , Implementar los procesos de mantenimiento . Como hemos dicho antes, cualquier implementacin MDM debe incorporar herramientas , procesos y personas para mantener la calidad de los datos. Todos los datos deben tener un administrador de datos , que es responsable de asegurar la calidad de los datos maestros . El administrador de datos es normalmente una persona de negocios que tenga conocimiento de los datos, puede reconocer los datos incorrectos , y tiene el conocimiento y la autoridad para corregir los problemas . La infraestructura MDM debe incluir herramientas que ayudan al administrador de datos reconocer problemas y simplificar correcciones . Una buena herramienta de gestin de datos debe sealar partidos cuestionables que fueron confeccionados los clientes con diferentes nombres y nmeros de los clientes que viven en el mismo domicilio , por ejemplo. El administrador tambin puede que quiera revisar los artculos que se han aadido como nuevo, ya que los criterios de coincidencia estaban cerca pero por debajo del umbral. Es importante que el administrador de datos para ver el historial de cambios realizados en los datos de los sistemas de gestin de datos maestros , para aislar la fuente de errores y deshacer los cambios incorrectos. El mantenimiento tambin incluye los procesos para extraer los cambios y adiciones en el sistema MDM , y para distribuir los datos limpiados a los lugares requeridos .

Como puede ver , MDM es un proceso complejo que puede durar mucho tiempo. Como casi todo en software, la clave del xito es la implementacin de MDM forma incremental , por lo que la empresa se da cuenta de una serie de beneficios a corto plazo , mientras que el proyecto completo es un proceso a largo plazo . Ningn proyecto MDM puede tener xito sin el apoyo y la participacin de los usuarios de negocios. Los profesionales de TI no tienen el conocimiento del dominio para crear y mantener los datos maestros de alta calidad. Cualquier proyecto de MDM que no incluye cambios en los procesos que crean , mantienen y validar los datos maestros es probable que falle . El resto de este artculo cubrir los detalles de la tecnologa y los procesos para la creacin y el mantenimiento de datos maestros. Cmo se crea una lista maestra ? Si usted compra una herramienta o decide liar , hay dos pasos bsicos para la creacin de datos maestros : limpiar y normalizar los datos, y combinar datos de todas las fuentes para consolidar duplicados. Antes de empezar a limpiar y normalizar los datos , hay que entender el modelo de datos para los datos maestros . Como parte del proceso de modelado , el contenido

de cada atributo se definieron , y un mapeo se definen a partir de cada sistema de origen para el modelo de datos maestros - . Esta informacin se utiliza para definir las transformaciones necesarias para limpiar los datos de origen . Limpieza de los datos y su transformacin en el modelo de datos principal es muy similar a la extraccin, transformacin y carga ( ETL) de los procesos utilizados para rellenar un almacn de datos. Si ya dispone de herramientas ETL y transformacin definida , podra ser ms fcil simplemente modificar estos como se requiere para los datos maestros , en vez de aprender una nueva herramienta. Estas son algunas de las funciones tpicas de limpieza de datos : Normalizar los formatos de datos . Haz que todos los nmeros de telfono tienen el mismo aspecto , transformar direcciones (y as sucesivamente ) a un formato comn. Reemplazar los valores perdidos . Inserte defecto , buscar los cdigos postales de la direccin , consultar el nmero de Dun & Bradstreet . Estandarizar los valores . Convertir todas las mediciones al mtrico decimal, convertir los precios a una moneda comn , cambie los nmeros de parte de un estndar de la industria . Atributos de Ruta. Analizar el nombre y apellido de un campo de contacto , nombre, mueva Parte # partno y al campo PartNumber . La mayora de las herramientas se limpiar los datos que pueden, y poner el resto en una tabla de errores para el procesamiento de la mano. Dependiendo de cmo funciona la herramienta a juego, los datos limpiados sern puestos en una tabla maestra o en una serie de organizar mesas. Como cada fuente se limpia, la salida debe ser examinada para garantizar el proceso de limpieza est funcionando correctamente. Coincidencia de los registros de datos de master para eliminar duplicados es a la vez el paso ms difcil y ms importante en la creacin de datos maestros. Partidos falsos en realidad pueden perder datos ( dos Corporaciones Acme se convierten en uno , por ejemplo) y partidos perdidos reducir el valor de mantener una lista comn . La precisin a juego de herramientas de MDM es uno de los criterios de compra ms importantes . Algunos partidos son bastante trivial que hacer . Si usted tiene los nmeros de Seguro Social de todos sus clientes , o si todos sus productos utilizan un esquema de numeracin comn, una base de datos de unin se encuentra la mayora de los partidos . Esto casi nunca sucede en el mundo real , sin embargo , por lo que algoritmos de correspondencia son normalmente muy complejos y sofisticados . Los clientes pueden coincidir en el nombre , el apellido de soltera , apodo, direccin, nmero de telfono, nmero de tarjeta de crdito, y as sucesivamente, mientras que los productos coinciden en el nombre , descripcin , referencia , especificaciones y precio. El atributo ms partidos y ms cerca del partido, el mayor grado de confianza en el sistema MDM tiene en el partido . Este factor de confianza se calcula para cada partido , y si se supera un umbral , de acuerdo con los registros . El umbral se ajusta normalmente en funcin de las consecuencias de una falsa coincidencia . Por ejemplo, puede especificar que si el nivel de confianza es superior al 95 por ciento, los registros se combinan automticamente , y si la confianza est entre 80 por ciento y 95 por ciento, un administrador de datos debe aprobar el partido antes de que se fusionan .

La mayora de herramientas de combinacin se combinan una serie de entradas en la lista principal , por lo que el mejor procedimiento es comenzar la lista con los datos de los que tiene ms confianza , y luego fusionar las otras fuentes de uno a la vez . Si usted tiene una gran cantidad de datos y un montn de problemas con l , este proceso puede tomar mucho tiempo . Es posible que desee comenzar con los datos de los que usted espera para obtener el mayor beneficio habiendo consolidado ; ejecutar un proyecto piloto con esos datos , para asegurar los procesos de trabajo y que estn viendo los beneficios de negocio que se pueden esperar , y luego empezar a aadir otras fuentes , como el tiempo y los recursos lo permitan . Este enfoque significa que su proyecto se necesitar ms tiempo y posiblemente costar ms , pero el riesgo es menor. Este enfoque tambin permite iniciar con algunas organizaciones y agregar ms a medida que el proyecto demuestra el xito , en lugar de tratar de hacer que todos a bordo desde el principio. Otro factor a considerar cuando la fusin de los datos de origen en la lista maestra es la privacidad. Cuando los clientes se convierten en parte del maestro de clientes , su informacin puede ser visible para cualquiera de las aplicaciones que tienen acceso a el maestro de clientes . Si los datos de los clientes han sido obtenidos en una poltica de privacidad que limita su uso a una aplicacin particular , no podra ser capaz de combinar en el maestro de clientes . Es posible que desee aadir un abogado a su equipo de planificacin de MDM . En este punto , si su objetivo era producir una lista de los datos maestros , ya est. Imprimirlo , o grabarlo en un CD , y seguir adelante. Si desea que sus datos maestros para mantenerse al da a medida que se aade y cambia los datos , tendr que desarrollar la infraestructura y procesos para gestionar los datos maestros a travs del tiempo . La siguiente seccin ofrece algunas opciones sobre la manera de hacer precisamente eso. Cmo mantener una lista maestra ? Hay muchas herramientas y tcnicas diferentes para la gestin y uso de los datos maestros. Vamos a cubrir tres de los escenarios ms comunes aqu : enfoque en una sola copia de este enfoque, slo hay una copia maestra de los datos maestros . Todas las adiciones y los cambios se hacen directamente a los datos maestros . Todas las aplicaciones que utilizan datos maestros se vuelven a escribir para utilizar los nuevos datos en lugar de sus datos actuales . Este enfoque garantiza la coherencia de los datos maestros , pero en la mayora de los casos no es prctico . Modificacin de todas las aplicaciones que utilizan una nueva fuente de datos con diferentes esquemas y datos diferentes es , por lo menos , muy caro , y si algunas de sus aplicaciones se compran , que incluso podra ser imposible. Las copias mltiples , mantenimiento individual de este enfoque , se aade de datos maestros o cambiado en la copia maestra nica de los datos, pero los cambios se envan a los sistemas de origen en el que las copias se almacenan localmente . Cada aplicacin puede actualizar las partes de los datos que no son parte de los datos maestros , pero no pueden cambiar o aadir datos maestros. Por ejemplo, el sistema de inventario puede ser capaz de cambiar las cantidades y ubicaciones de las piezas , pero las nuevas piezas no puede ser aadido , y los

atributos que se incluyen en el principal producto no puede ser cambiado. Esto reduce el nmero de cambios en las aplicaciones que sern necesarios , pero las solicitudes se mnimamente tenga que deshabilitar las funciones que agregan o actualizan los datos maestros. Los usuarios tendrn que aprender nuevas aplicaciones para agregar o modificar datos maestros , y algunas de las cosas que normalmente no funcionar ms . Continuo fusionan - En este enfoque , las aplicaciones se les permite cambiar su copia de los datos maestros. Los cambios realizados en los datos de origen se envan al maestro , en el que se combinan en la lista maestra . Los cambios en el patrn se envan a los sistemas de origen y se aplican a las copias locales . Este enfoque requiere algunos cambios en los sistemas de origen , si es necesario, la propagacin de cambios se puede manejar en la base de datos , por lo que no se cambia el cdigo de aplicacin . A primera vista, esto parece ser la solucin ideal. Cambios de aplicacin se reducen al mnimo , y no se requiere reentrenamiento . Todo el mundo sigue haciendo lo que estn haciendo, pero con datos de mayor calidad y ms completas. Este enfoque tiene varios problemas : conflictos de actualizacin son posibles y difciles de conciliar. Qu sucede si dos de los sistemas de cdigo cambia la direccin del cliente en diferentes valores ? No hay manera de que el sistema MDM para decidir cul desea mantener , por lo que se requiere la intervencin del administrador de datos , mientras tanto , el cliente tiene dos direcciones diferentes . Esto debe abordarse mediante la creacin de normas de datos de gobierno y procedimientos normalizados de trabajo, para asegurar que los conflictos de actualizacin se reducen o eliminan . Las adiciones deben remerged . Cuando se aade un cliente , hay una posibilidad de que otro sistema ya ha aadido el cliente . Para hacer frente a esta situacin, todas las adiciones de datos deben pasar por el proceso de emparejamiento de nuevo para evitar duplicados en el nuevo maestro. El mantenimiento de valores coherentes es ms difcil . Si el peso de un producto se convierte de libras a kilogramos y luego de vuelta a la libra , el redondeo se puede cambiar el peso original. Esto puede ser desconcertante para un usuario que entra en un valor y luego lo ve cambiar a los pocos segundos .

En general, todas estas cosas pueden ser planificadas y tratados , por lo que la vida del usuario ms fcil , a expensas de una infraestructura ms complicado de mantener y ms trabajo para los administradores de datos . Esto podra ser un compromiso aceptable , pero es uno que debe hacerse conscientemente. Versiones y Auditora No importa cmo usted maneja sus datos maestros , es importante ser capaz de entender cmo los datos llegaron a la situacin actual . Por ejemplo, si un registro de cliente se consolid a partir de dos registros combinados diferentes , es posible que necesite saber lo que los registros originales parecan , en caso de que un administrador de datos determina que los expedientes se fusionaron por error y realmente debera haber dos clientes diferentes . La gestin de versiones debe incluir una interfaz sencilla para mostrar versiones y revertir todo o parte de un cambio a una versin anterior. La ramificacin normal de versiones y la agrupacin

de los cambios que el uso de los sistemas de control de fuente tambin puede ser muy til para el mantenimiento de los diferentes cambios de derivacin y de grupos de revertir los cambios en una rama anterior. Requisitos de la administracin y el cumplimiento de datos incluirn a menudo una forma de determinar quin hizo cada cambio , y cuando se hizo. Para apoyar estos requisitos , un sistema MDM debe incluir un mecanismo de auditora de cambios en los datos maestros . Adems de mantener un registro de auditora , el sistema MDM debe incluir una forma sencilla de encontrar el cambio en particular que busca . Un sistema MDM puede auditar miles de cambios de un da , por lo que la presentacin de informes de bsqueda y servicios para el registro de auditora son importantes. Gestin Jerarqua Adems de los propios datos maestros , el sistema MDM debe mantener jerarquas de datos de ejemplo, la lista de materiales para los productos , la estructura de ventas de territorio , estructura de la organizacin para los clientes, y as sucesivamente. Es importante para el sistema MDM para capturar estas jerarquas , pero tambin es til para un sistema MDM para ser capaz de modificar las jerarquas de forma independiente de los sistemas subyacentes . Por ejemplo, cuando un empleado se traslada a un centro de costo diferente , podra haber repercusiones en el sistema de gastos de viaje y , nminas, informes de tiempo , las estructuras de presentacin de informes y la gestin del rendimiento . Si el sistema MDM administra jerarquas , un cambio a la jerarqua en un solo lugar se puede propagar el cambio a todos los sistemas subyacentes . Tambin puede haber razones para mantener jerarquas en el sistema MDM que no existe en los sistemas de origen . Por ejemplo , podra ser necesario enrollado en el territorio o de organizacin estructuras que no existen en ningn sistema de una sola fuente de ingresos y gastos. La planificacin y la previsin tambin podra requerir jerarquas temporales para calcular nmeros " qu pasara si" los cambios organizativos propuestos. Jerarquas histricas tambin estn obligados en muchos casos a rodar la informacin financiera en las estructuras que existieron en el pasado, pero no en la estructura actual. Por estas razones , una funcin de gestin de jerarqua potente, flexible es una parte importante de un sistema MDM . Conclusin El reciente nfasis en el cumplimiento de la normativa , SOA , y las fusiones y adquisiciones ha hecho de la creacin y el mantenimiento de los datos maestros precisos y completos de un imperativo del negocio . Tanto grandes como pequeas empresas deben desarrollar procesos y procedimientos de gobierno de datos y mantenimiento , para obtener y mantener datos maestros exactos. Mientras que es fcil pensar en la gestin de datos maestros como un problema tecnolgico, una solucin puramente tecnolgica sin los correspondientes cambios en los procesos operativos y controles probablemente dejar de producir resultados satisfactorios. En este trabajo se ha cubierto las razones para la adopcin de la gestin de datos maestros , el proceso de desarrollo de una solucin , y varias opciones para la aplicacin tecnolgica de la

solucin. Trabajos futuros en esta serie le explicar los aspectos tecnolgicos y de procedimiento que se deben resolver para poner en prctica un sistema MDM . los datos limpiados a los lugares requeridos .