Es difícil encontrar una
empresa que no tenga algún problema de calidad de datos. Incluso si una
aplicación de línea de negocio (LOB) utiliza un modelo relacional adecuado con
todas las restricciones, aún esto no garantiza que los datos siempre sean
precisos. Los modelos de bases de datos y las restricciones realizan la
integridad de datos. La integridad de
datos significa que los datos cumplen con las reglas del negocio. La calidad de datos es un término muy
estricto; incluso si los datos cumplen con las reglas del negocio, todavía
pueden ser erróneos. Por ejemplo, considere una regla de negocio que dice que
una columna que contiene enteros representando un porcentaje de descuento puede
tomar valores de un dominio de enteros entre 0 y 100. Si la columna contiene un
valor de 45 en lugar de 54, este cumple con las reglas de negocio, pero los
datos aún no son precisos.
La calidad de datos trata
con cuestiones tales como la precisión y problemas similares: ¿Está la
información completa? ¿Es confiable? ¿Están los datos disponibles en el momento
oportuno? Todos estos son problemas de calidad de datos. Puede resolver problemas
de calidad de datos de una manera reactiva, por constantemente perfilar y
corregir los datos. También puede resolver problemas de calidad de datos de una
manera proactiva. Esto puede ser hecho definiendo los datos más importantes,
los datos maestros, y luego
implementar una solución de gestión de
datos maestros (MDM). La base de datos de solución MDM es entonces un
origen autorizado de datos maestros.
La calidad de datos utiliza
dos características en la suite de Microsoft SQL Server 2014: Microsoft SQL
Server 2014 Data Quality Services (DQS)
y Microsoft SQL Server 2014 Master Data
Services (MDS). El DQS ayuda a perfilar y corregir los datos, y el MDS es
una solución de gestión de datos maestros.
La calidad de datos está
indivisiblemente intercalada con la Gestión de Datos Maestros (MDM). El
objetivo más importante de una solución MDM es elevar la calidad de los datos
maestros. Los problemas de calidad de datos deben ser abordados en cualquier
proyecto MDM. Sin embargo, las actividades de calidad de datos, tales como el
perfilado de datos, encuentran la causa raíz de la pobreza de los datos, y las
mejoras de la calidad pueden ser también independientes de un proyecto MDM. Es
posible para una empresa definir las políticas y los procesos de calidad de datos
a través de aplicaciones existentes, pero una solución especializada MDM puede
mitigar mucho la implementación de estas políticas.
Antes de
definir sus actividades de calidad de datos, debe decidir para qué aspectos
medirá y mejorará la calidad de sus datos. Las dimensiones de calidad de datos capturan un aspecto específico de
la calidad de datos en general. La medida de la calidad de datos, también
conocida como perfilado de datos,
debería ser una parte integral de la implementación de una solución MDM.
Siempre debe obtener una comprensión a fondo de los datos de origen antes de
empezar a fusionarlos. También debe medir las mejoras de calidad de datos sobre
el tiempo, para entender y explicar el impacto de la solución MDM. Esta post
empieza por describir las dimensiones de calidad de datos, explicando los
diferentes aspectos de calidad de datos que pueden ser medidos y la mejor
manera de medirlos. Entonces trata con actividades de calidad de datos y las
personas que ejecutan estas actividades. Aprenderá acerca de los roles específicos de calidad de datos y
de gestión de datos maestros.
Dimensiones de
Calidad de Datos
Las dimensiones de calidad
de datos pueden referirse a valores de datos o a su esquema. La evaluación de
la calidad de un modelo relacional o dimensional no puede ser hecha con Data
Quality Services. Este capítulo se centra en las dimensiones puras de calidad
de datos y de Data Quality Services, aunque en aras de la exhaustividad, las
dimensiones de calidad de esquema son también descritas en este post.
No hay un consenso sobre
qué dimensiones de calidad de datos deberían ser inspeccionadas. Diferentes
herramientas y diferentes libros enumeran diferentes conjuntos de dimensiones.
Sin embargo, algunas dimensiones son analizadas con más frecuencia que otras.
Esta lección se enfoca en las analizadas con más frecuencia.
Puede medir
algunas dimensiones de calidad de datos con herramientas como las consultas
Transact-SQL. Las dimensiones medibles son llamadas dimensiones duras. En contraste, algunas dimensiones dependen de la
percepción de los usuarios de los datos; éstos se llaman dimensiones suaves. No puede medir las dimensiones suaves
directamente; puede medirlas en forma indirecta a través de entrevistas con los
usuarios de los datos o de cualquier otro tipo de comunicación con los
usuarios. Tenga en cuenta que esta comunicación puede incluir lamentablemente
eventos desagradables, como las quejas de los clientes, que son los eventos que
desea evitar. Este post describe las dimensiones duras en detalle y toma sólo
una visión rápida de las dimensiones suaves y de esquema.
Integridad (Completeness)
La Integridad es una de las
dimensiones más fáciles de medir. Puede empezar a medirlo a un nivel de
población. En un supuesto mundo cerrado, se puede afirmar que no hay otros
valores excepto los valores actualmente presentes en una tabla relacional, que
representan hechos en el mundo real. Si la relación no tiene valores
desconocidos (NULLs), la relación está completa desde la perspectiva de la
población. En un supuesto mundo abierto, no se puede afirmar la integridad de
la población, incluso si su relación no contiene valores desconocidos. Con el
fin de evaluar la integridad de una relación en un supuesto mundo abierto,
necesita obtener una relación de referencia que contiene toda la población.
Cuando se tiene una relación de referencia, se puede definir la integridad como
la proporción del número de tuplas presentadas en la relación y el número de
tuplas en la relación de referencia. Debido a la privacidad y restricciones
regladas, normalmente no es posible adquirir la relación de referencia. Sin
embargo, usualmente puede obtener al menos el número de tuplas en una relación
de referencia. Por ejemplo, puede obtener fácilmente el número de ciudadanos de
un país. Desde un punto de vista técnico, es muy fácil medir la integridad de
una relación cuando se tiene el número de tuplas en una relación de referencia.
En un supuesto
mundo cerrado en una base de datos relacional, la presencia de NULLs es lo que
define la integridad. Se podría medir la integridad
de atributo (el número de NULLs en un atributo específico), la integridad de tupla (el número de
valores desconocidos de los atributos en una tupla), y la integridad de relación (el número de tuplas con valores de
atributos desconocidos en la relación). Por último, también se puede medir la integridad de valor, lo que tiene
sentido para las columnas complejas, semi-estructuradas asi como las columnas
de tipo de datos XML. En una instancia XML, un elemento completo o un atributo
puede estar faltando. Además, los estándares XML también definen un atributo
xsi:nil especial como un marcador de posición para los valores faltantes; esto
es similar al NULL relacional.
Precisión (Accuracy)
La precisión es una
dimensión complicada. Primero, tiene que determinar que es impreciso. La
precisión es más estricta que sólo ajustarse a las reglas de negocio; esta
última debe cumplir con la integridad de datos. Para los datos que deberían ser
únicos, los valores duplicados son imprecisos. Encontrar valores duplicados
podría llevarse a cabo con bastante facilidad con consultas simples, o puede
ser muy difícil, si tiene que encontrar los duplicados a través de diferentes
sistemas. Encontrar otros datos imprecisos puede implicar algún trabajo manual.
Con varios algoritmos, puede extraer datos que son sólo potencialmente imprecisos.
Podemos ofrecer
algunos consejos sobre cómo aislar los datos imprecisos. Para los valores de
datos discretos, puede utilizar la distribución de frecuencias de los valores.
Un valor con una frecuencia muy baja es potencialmente incorrecto. Para las
cadenas, se puede buscar por distribución de longitud de cadena. Una cadena con
una longitud muy atípica es potencialmente incorrecta. Para las cadenas,
también puede tratar de encontrar patrones y luego crear la distribución de
patrones. Los patrones con baja frecuencia probablemente denotaran valores
erróneos. Para los atributos continuos, puede utilizar estadísticas
descriptivas. Sólo mirando a los valores mínimos y máximos, se puede fácilmente
detectar a los datos potencialmente problemáticos. No importa cómo encuentra
los datos imprecisos, puede marcarlo y luego medir el nivel de precisión. Puede
medir esto para las columnas y las tablas.
Información
Otra dimensión
medible es la información. La Teoría de la Información, es una rama de las
matemáticas aplicadas, define la entropía como la cuantificación de la
información en un sistema. Puede medir la entropía sobre un nivel de columna y
de tabla. Los valores más dispersos que tiene y los de mayor distribución de
frecuencia de una columna discreta son igualmente repartidos entre los valores,
cuanta más información tenga la columna. La información no es una dimensión
directa de calidad de datos; sin embargo, puede decirle si sus datos son
adecuados para el análisis o no.
Consistencia
La consistencia mide la equivalencia de la información
almacenada en diferentes bases de datos. Puede encontrar muchos datos
inconsistentes por comparar los valores con un conjunto predefinido de valores
posibles; puede encontrar algunas inconsistencias por comparar los datos entre
los sistemas. Puede encontrar algunas inconsistencias manualmente. No importa
cómo encuentra las inconsistencias, puede marcarlas y luego medir el nivel de
inconsistencia sobre el nivel de columna o de tabla.
Analizar tanto la dimensión
de calidad de datos dura como la suave es considerada una buena práctica.
Dimensiones
Suaves de Calidad de Datos
Puede medir la dimensión
suave indirectamente, a través de la interacción con los usuarios. Los
cuestionarios, encuestas rápidas, quejas de usuarios, o cualquier otro tipo de
comunicación con los usuarios de datos, son sus herramientas para medir la
calidad de las dimensiones de datos suaves. La siguiente lista incluye algunas
de las dimensiones suaves típicas:
·
Disponibilidad
(Timeliness). Esto le indica el grado en que los datos están actualizados y
disponibles cuando se necesitan. Siempre hay un cierto retraso entre el cambio
en el mundo real y el momento cuando este cambio es ingresado a un sistema.
Aunque los datos obsoletos pueden aparecer en cualquier sistema, esta dimensión
es especialmente importante para los sitios y aplicaciones web. Un problema
común en la web es que los propietarios no actualizan los sitios en una manera
oportuna; puede encontrar un montón de información obsoleta en la web.
·
Facilidad de Uso. Esta es una dimensión muy
típica que confía en la percepción del usuario. La facilidad de uso depende de
la aplicación o de la interfaz de usuario. Además, los usuarios de datos
también perciben el uso como complejo porque no están capacitados.
·
Proposito (Intention). ¿Es el dato, el dato
correcto para su uso previsto? A veces no tiene los datos exactos que necesita;
sin embargo, puede sustituir los datos necesarios con los datos del que tiene
información similar. Por ejemplo, puede utilizar los códigos de área telefónica
en lugar de los códigos postales para localizar clientes aproximadamente.
Aunque los números de teléfono no estaban destinados para el análisis, pueden
darle resultados razonables. Un ejemplo de un uso no intencionado inútil es el
uso de una columna en una tabla para almacenar la información no relacionada,
tal como usar la columna del nombre del producto para almacenar la taxonomía
del producto. Este es un uso no intencionado del esquema, que conduce a muchos
problemas con la limpieza y la integración de datos.
·
Confianza (Trust). Tiene que preguntar a los
usuarios si confían en los datos. Esta es una dimensión muy importante. Si los
usuarios no confían en los datos de los sistemas operacionales, crearán sus
propias pequeñas, probablemente no estructuradas, bases de datos. La
integración de datos maestros de orígenes no estructurados es muy difícil. Si
los usuarios no confían en los datos de las aplicaciones analíticas,
simplemente dejaran de usarlos.
·
Calidad de Presentación. Esta es otra dimensión que
depende de la percepción del usuario. Cuando una aplicación presenta datos, el
formato y la apariencia deben apoyar el uso adecuado de la información. En los
sistemas operacionales, esta dimensión está estrechamente relacionado con la
facilidad de uso de la dimensión y depende mucho de la interfaz de usuario. Por
ejemplo, una aplicación puede obligar a los usuarios a introducir fechas manualmente
o guiarlos a través de un control de calendario. En los sistemas analíticos, la
presentación es probablemente aún más importante. ¿Se muestran los datos en
gráficos o en tablas? ¿Cuánta interactividad debería poner en sus reportes?
Preguntas como esta y respuestas a estas preguntas pueden tener una gran
influencia en el éxito o el fracaso de los sistemas analíticos.
Dimensiones
Esquema de Calidad de Datos
Una percepción común es que
la calidad del esquema no puede ser medida automáticamente. Bueno, esto es
cierto para algunas dimensiones; no puede medirlas sin profundizar en un
problema del negocio. Sin embargo, es posible encontrar algoritmos y crear
procedimientos que ayuden a medir alguna parte de la calidad del esquema.
Seguido se lista las dimensiones de calidad de esquema más importantes, con una
breve descripción de cómo medirlos, cuando es aplicable.
·
Integridad de Esquema Esto le dice para extender
a cual esquema cubre el problema del negocio. No se puede medir esta dimensión
sin un análisis profundo del problema de negocio y sus necesidades.
·
Exactitud de Esquema. La exactitud de un modelo
se refiere a la representación correcta de los objetos del mundo real en el
esquema y la representación correcta de los requerimientos. Por ejemplo, un
nombre puede ser modelado como una entidad con una relación uno-a-uno a la
entidad Customers o como un atributo de la entidad Customers. Por supuesto,
esta última es la correcta. El nombre no puede ser identificado únicamente, por
lo que no es una entidad. Este es el problema con los intentos de representar
correctamente los objetos del mundo real. Un ejemplo de inexactitud que tiene
que ver con los requerimientos es el siguiente modelo de departamentos y
directores. Si un requerimiento dice que un director puede gestionar un solo
departamento y que cada departamento tiene un único director, entonces, la
relación entre los directores y los departamentos debe ser uno a uno. Modelar
esta relación como de muchos a muchos sería un esquema incorrecto. Puede medir
esta dimensión manualmente, investigando los requerimientos del negocio y las
definiciones de objetos y su representación en el esquema.
·
Documentación Esto le indica si el
esquema está debidamente documentado. Los diagramas de esquema, como los
diagramas entidad-relación, siempre deben ser parte de la documentación.
Además, todas las reglas de negocio que no pueden ser representadas en un diagrama, deberían ser
documentadas en formato de texto. En resumen, debe tener la documentación
completa de un esquema conceptual. Puede comprobar la calidad de esta dimensión
manualmente, con una vista general de la documentación del esquema.
·
Conformidad con los modelos
teóricos ¿Está el
esquema de base de datos para aplicaciones transaccionales en un esquema
relacional especializado y normalizado adecuadamente, y el esquema para un data
warehouse consta de esquemas de Estrella? Esta dimensión debe ser parcialmente
medida manualmente, con una visión general del modelo de datos. Sin embargo, se
puede encontrar algunas áreas problemáticas en el esquema proceduralmente. Por
ejemplo, puede comprobar las correlaciones entre los atributos no-llave; los
atributos con muy alta correlación en una tabla pueden indicar que el esquema
no está normalizado, o al menos no lo está en la tercera forma normal. Además,
muchos NULLs pueden indicar que no hay suficiente especialización, es decir,
subtipos en el esquema. Esto es especialmente cierto si algunos valores de un
atributo siempre conducen a NULLs en otro atributo. Puede medir esto con consultas
de base de datos.
·
Minimalización. La abstracción es una
técnica de modelado muy importante. Esto significa que debería tener solo
objetos en un modelo que sean importantes para los problemas del negocio que
está resolviendo. El número de entidades de esquema debería ser mínimo y no
debería incluir objetos que no son pertinentes al problema del esquema que está
resolviendo. Una vez más, puede medir esta dimensión con una visión general
manual y la comparación a los requerimientos del negocio.
Actividades y
Roles de Calidad de Datos
Los proyectos de calidad de
datos son muy intensivos en términos de recursos necesarios. Con el fin de
ejecutar un proyecto exitosamente, tiene que mostrar los posibles beneficios a
los principales interesados. En primer lugar, es necesario entender las
necesidades del negocio. Puede utilizar entrevistas, descripciones de los
organigramas, análisis de las prácticas existentes en una empresa, y otras
fuentes de información. Debe priorizar
los problemas del negocio y hacer un plan de proyecto claro. Para que un
proyecto sea exitoso, es importante empezar con un área de negocio que sea muy
critico para los interesados o con un problema de negocio que sea bastante
simple de resolver. Siempre debe implementar proyectos de calidad de datos paso
a paso.
Antes de empezar cualquier
proyecto de calidad de datos o MDM, tiene que entender los orígenes y destinos
de los datos problemáticos. Por lo tanto, las actividades de calidad de datos
deben incluir una visión general. Debe tener una visión general amplia de todos
los esquemas de las bases de datos que se refieren a los datos del problema.
Deberia entrevistar a los expertos de dominio y usuarios de datos. Esto es
especialmente importante para obtener una comprensión de la calidad de las
dimensiones de esquema. Además, después de este paso, debe también tener un
claro entendimiento de la tecnología que la empresa está utilizando. Si es
necesario, puede necesitar planificar el incluir expertos en tecnología
adecuados en el proyecto. Durante la visión general de los datos, también debe
centrarse en el ciclo de vida de los datos de manera que pueda comprender los
períodos de retención y similares.
El siguiente paso es la
evaluación de la calidad de datos. Puede evaluar las dimensiones duras con el
análisis procedural de los datos, también conocido como perfilado de datos. Hay
muchas herramientas diferentes para el perfilado de datos. Debe aprovechar todo
el conocimiento que tiene y todas las herramientas disponibles para esta tarea.
Deberia medir las dimensiones suaves de calidad de datos en este paso también.
Puede obtener una gran cantidad de conocimiento sobre el estado de la empresa
por la comparación de las dimensiones duras y suaves. Si su evaluación de las
dimensiones duras es mala, pero obtiene buenas evaluaciones de las dimensiones
suaves, entonces la compañía no se dará cuenta de que tiene problemas con los
datos. En tal caso, la valoración adicional de los potenciales daños causados
por los malos datos puede ayudar a los principales interesados a comprender los
problemas de calidad de datos. Si ambas dimensiones suaves y duras son
evaluadas bajas, entonces la empresa está lista para un proyecto de calidad de
datos y/o MDM. Si las dimensiones duras obtienen buenas evaluaciones, mientras
que las dimensiones suaves obtienen malas evaluaciones, esto significa que por
alguna razón los expertos de dominio y los usuarios no confían en los datos.
Por lo general, esta situación se debe a un sistema anterior, una versión
anterior del sistema, o la falta de educación. Si ambas dimensiones duras y
blandas obtienen buenas evaluaciones, la empresa no necesita un proyecto de
calidad de datos especial; sin embargo, la empresa aún podría decidir iniciar
un proyecto MDM con el fin de minimizar los gastos con el mantenimiento de
datos maestros.
Después de terminar con la
evaluación de los datos, puede volver a evaluar el impacto en el negocio de los
datos de calidad baja. Debe reunirse de nuevo con los principales interesados a
fin de revisar las prioridades y elaborar la parte de las mejoras del plan del
proyecto en detalle.
Antes de que pueda empezar
a mejorar la calidad de los datos, es necesario encontrar las causas raíces de
los malos datos. Encontrar las causas raíces puede reducir sustancialmente el
volumen de trabajo necesario para la mejora de la calidad de datos. Para
encontrar las causas raíces, puede utilizar el método de los "cinco
porqués" introducido por Sakichi Toyoda y utilizado primero en la Toyota
Motor Corporation. Con este método, simplemente pregunta "por qué"
cinco veces. Por ejemplo, supongamos que el problema es con los registros
duplicados para los clientes. Aplicar el enfoque de los "cinco
porqués" para encontrar la causa raíz, luce como esto:
·
Puede preguntar por qué hay registros duplicados. Una respuesta podría
ser, debido a que los operadores con frecuencia insertan nuevos registros de
clientes en lugar de utilizar los ya existentes.
·
Debe preguntar el segundo por qué: ¿Por qué los operadores crean nuevos
registros para los clientes existentes? La respuesta podría ser, debido a que
los operadores no buscan los registros existentes de un cliente.
·
A continuación, debe preguntar el tercer por qué: ¿Por qué no buscan? La
respuesta podría ser, debido a que la búsqueda tarda mucho tiempo.
·
El siguiente por qué es, por supuesto, ¿Por qué tarda mucho tiempo? La
respuesta podría ser, porque es muy difícil buscar los clientes existentes.
·
Ahora la pregunta final, el quinto por qué: ¿Por qué la búsqueda es tan
difícil? La respuesta podría ser, debido a que el operador puede buscar sólo
valores exactos, no por cadenas aproximadas, y el operador no tiene un nombre,
una dirección o un número de teléfono exacto de un cliente en la memoria. Ha
encontrado la causa raíz de la duplicación para este ejemplo, el problema es
con la aplicación, específicamente con la interface de usuario. Ahora ya sabe
dónde poner el esfuerzo con el fin de reducir el número de duplicados.
Por supuesto, el método de
los "cinco porqués" no es la única técnica para la búsqueda de las
causas raíces. También puede hacer un seguimiento de una pieza de información a
través de su ciclo de vida. Por su seguimiento, puede fácilmente observar el
momento en que se convierte en inexacta. Puede encontrar causas raíces para
algunos problemas procedurales también. Por ejemplo, puede encontrar que los
NULLs están en el sistema debido a la ausencia de subtipos con consultas. No
importa cómo encuentres las causas raíces, tiene que utilizar esta información
para preparar un plan de mejora detallado.
Un plan de mejora debería incluir
dos partes: la corrección del dato
existente y, aún más importante, la prevención
de errores futuros. Si se centra en la corrección de los datos existentes
solamente, tendrá que repetir la parte de corrección de las actividades de
calidad de datos regularmente. Por supuesto, necesita dedicar algún tiempo a
corregir los datos existentes; sin embargo, no hay que olvidar la parte de
prevención. Cuando tiene las dos partes del plan de mejora, puede empezar a
implementarla.
La implementación de
medidas correctivas implica métodos de limpieza automática y manual. Los
métodos de limpieza automática pueden incluir sus propios procedimientos y
consultas. Si tiene conocimiento de la lógica para corregir los datos, debe
utilizarla. Puede resolver problemas de consistencia por definir una sola
manera de representar los datos en todos los sistemas y, entonces, reemplazar
las representaciones inconsistentes con las recientemente definidas. Por
ejemplo, si el género está representado en algún sistema con los números 1 y 2,
pero han decidido que deben estar representados con las letras F y M, puede
sustituir los números por letras en una sola sentencia de actualización. Para
la de-duplicación y la fusión de diferentes orígenes, puede utilizar algoritmos
de coincidencia de cadenas. Para corregir direcciones, puede utilizar
herramientas de validación y de limpieza que ya existen en el mercado y
utilizar algunos registros de direcciones válidas. Sin embargo, debería siempre
estar preparado para el hecho de que parte de la limpieza de datos debe ser
realizada manualmente.
Prevenir nuevas inserciones
de datos inexactos implica diferentes técnicas también. La más importante es la
implementación de una solución MDM. Para una solución MDM, necesita una
aplicación MDM. SQL Server Master Data Services es un ejemplo de la herramienta
que podría utilizar.
Además de permitir el
almacenamiento central de datos maestros y sus metadatos, la aplicación MDM
tiene que soportar flujos de trabajo de stewardship de datos explícitos,
control de versiones, auditoría, y gobierno
de datos El gobierno de datos se
refiere a las actividades realizadas para mejorar y mantener la calidad de los
datos; los stewards de datos son las
personas responsables de estas actividades. Para que un proyecto de calidad de
datos y/o gestión de datos maestros sea exitoso, los roles para stewardship de datos explícitos deben
ser definidos. Además de la solución de calidad de datos o MDM, también debería
enfocarse en los sistemas de origen. Es muy poco probable que su solución
siempre cubra todas las posibles entidades maestras con todos sus atributos.
Por lo tanto, parte de los datos todavía serán mantenidos en el origen, en
aplicaciones operacionales. Tiene que aplicar los modelos de datos apropiados,
restricciones y buenas interfaces de usuario siempre que sea posible.
Después de haber
implementado las soluciones correctivas y preventivas de calidad de datos,
debería medir cómo se realizan. Incluso mejor, debería preparar la
infraestructura de mejora de antemano, antes de comenzar a implementar sus
soluciones. Midiendo las mejoras, se puede mostrar fácilmente el valor de las
soluciones a los principales interesados. Además, este enfoque le permite un
cierto grado de control sobre su trabajo, en caso de que su mejora falle y
conduzca a problemas aún peores de calidad de datos. Puede medir las
dimensiones suaves realizando entrevistas continuas con los usuarios finales y
expertos de dominio. Puede guardar los resultados de las entrevistas en un data
warehouse de calidad de datos especial para rastrear la calidad de datos a través
del tiempo. Para las dimensiones duras, puede medirlas automáticamente en un
calendario predefinido, y de nuevo almacenar los resultados en el data
warehouse de calidad de datos.
Aunque esto no fue mencionado como un paso de la
actividad de calidad de datos explicito, es muy importante comunicar acciones y resultados a través del proyecto. Mientras más
comunicación tenga, mejor. Los expertos de dominio siempre pueden ayudarle con
sus conocimientos. Los profesionales de TI y los usuarios finales ponen mucho
más esfuerzo en ayudar a un proyecto a alcanzar el éxito si están involucrados,
si consideran que el proyecto es su proyecto. Los principales interesados
siempre deben saber cómo avanza el proyecto y deben estar involucrados en
todas las etapas de decisión.
