Cómo implementar un proceso de calidad de datos

La calidad de los datos (DQ) en los sistemas de almacenamiento de datos es cada vez más importante. Los crecientes requisitos normativos, pero también la creciente complejidad de las soluciones de almacenamiento de datos, obligan a las empresas a intensificar (o iniciar) una iniciativa de calidad de datos.

El enfoque principal de este artículo será el almacenamiento de datos “tradicional”, pero la calidad de los datos también es un problema en conceptos más “modernos”, como los lagos de datos. Mostrará algunos puntos principales a considerar y también algunas trampas comunes que se deben evitar al implementar una estrategia de calidad de datos. No cubre la parte de elegir la tecnología/herramienta adecuada para construir un marco DQ.

Uno de los problemas más obstructivos de un proyecto DQ es el hecho de que, a primera vista, crea mucho trabajo para las unidades de negocio sin proporcionar ninguna funcionalidad adicional. Una iniciativa de calidad de datos generalmente solo tiene fuertes defensores si:

• Hay problemas de calidad de datos con un impacto severo en el negocio.
• Los organismos reguladores hacen cumplir los estándares de calidad de datos (p. ej., BCBS 239 en la industria financiera).

El tratamiento de DQ es similar al de las pruebas en el desarrollo de software: si un proyecto se queda sin tiempo y/o presupuesto, esta parte tiende a reducirse primero.

Esto, por supuesto, no es toda la verdad. Un buen sistema de calidad de datos ayuda a detectar errores de forma temprana, acelerando así el proceso de entrega de datos de calidad "suficientemente buena" a los usuarios.

Definición de términos

Antes de discutir el tema, es importante un entendimiento común de los términos utilizados.

Almacén de datos (DWH)

Un almacén de datos (DWH) es un sistema no operativo utilizado principalmente para el apoyo a la toma de decisiones. Consolida los datos de los sistemas operativos (todos ellos o un subconjunto más pequeño) y proporciona datos optimizados para consultas para los usuarios del sistema DWH. El almacén de datos debe proporcionar "una única versión de la verdad" dentro de la empresa. Un almacén de datos generalmente se construye a partir de etapas/capas:

Los datos operativos se almacenan prácticamente sin cambios en una capa de ensayo. La capa central contiene datos consolidados y unificados. La siguiente etapa opcional es un área de derivación , que proporciona datos derivados (por ejemplo, una puntuación de ventas del cliente) y agregaciones. La capa de data mart contiene datos optimizados para un determinado grupo de usuarios. Los data marts a menudo contienen agregaciones y muchas métricas derivadas. Los usuarios del almacén de datos suelen trabajar solo con la capa de data mart.

Entre cada etapa, se lleva a cabo algún tipo de transformación de datos. Por lo general, un almacén de datos se carga periódicamente con extracciones delta de los datos operativos y contiene algoritmos para mantener los datos históricos.

Calidad de datos

La calidad de los datos generalmente se define como una métrica sobre qué tan bien un producto cumple con los requisitos del usuario. Diferentes usuarios pueden tener diferentes requisitos para un producto, por lo que la implementación depende de la perspectiva del usuario y es importante identificar estas necesidades.

La calidad de los datos no significa que los datos deban estar completamente o casi libres de errores; depende de los requisitos de los usuarios. Un enfoque "suficientemente bueno" es una buena opción para empezar. Hoy en día, las empresas más grandes tienen “una política de gobierno de datos (o información)”, y la calidad de los datos es parte de ella. Una política de gobierno de datos debe describir cómo su empresa trata los datos y cómo se asegura de que los datos tengan la calidad adecuada y que no se violen las reglas de privacidad de datos .

La calidad de los datos es un tema en curso. Se debe implementar un bucle de circuito DQ (consulte el capítulo siguiente). Los requisitos reglamentarios y las reglas de cumplimiento también tienen un impacto en la calidad de los datos necesarios, como TCPA (Ley de Protección al Consumidor de Teléfonos de EE. UU.) o GDPR en Europa para cuestiones de privacidad, pero también reglas específicas de la industria como Solvencia II para seguros en la UE, BCBS 239 y otros para la banca, y así sucesivamente.

Bucle de circuito de calidad de datos

Como con todos los temas de calidad, DQ es una actividad continua diseñada para mantener una calidad satisfactoria. Como resultado de un proyecto DQ, se debe implementar un bucle de circuito similar al siguiente:

Los pasos dentro de este bucle se describirán en los próximos capítulos.

Roles de calidad de datos

Para implementar una iniciativa de DQ exitosa, se necesitan los siguientes roles:

• Titular de los datos. El propietario de los datos es responsable de la calidad de los datos, pero también de la protección de la privacidad de los datos. El propietario de los datos "posee" un dominio de datos, controla el acceso y es responsable de garantizar la calidad de los datos y tomar medidas para corregir los hallazgos. En organizaciones más grandes, es común encontrar varios propietarios de datos. Los dominios de datos podrían ser, por ejemplo, datos de marketing, datos de control, etc. Si existe más de un propietario de datos en una empresa, debe haber una persona (un propietario de datos u otra persona) responsable del proceso general de calidad de datos. Un propietario de datos debe tener una autoridad sólida para hacer cumplir la calidad de los datos y respaldar el proceso de DQ; por lo tanto, los propietarios de los datos suelen ser partes interesadas de alto nivel. Una buena comprensión del dominio comercial junto con buenas habilidades de comunicación son importantes.
• Administrador de datos. Un administrador de datos ayuda a implementar la calidad de datos dentro de una empresa, apoyando a los usuarios de datos en preguntas sobre cómo interpretar los datos/el modelo de datos, problemas de calidad de datos, etc. Los administradores de datos suelen ser el personal del propietario de los datos o pueden organizarse en un centro de competencia de calidad de datos o un equipo DQ. Los administradores de datos pueden tener experiencia en TI o en negocios, pero deben conocer ambos lados. Las habilidades analíticas, junto con una buena comprensión del dominio comercial al que dan soporte, combinadas con sólidas habilidades de comunicación, son los principales requisitos previos para un administrador de datos exitoso.
• Usuario de datos. Estos son usuarios del almacén de datos que trabajan con datos. Los usuarios de datos suelen trabajar con la capa de data mart y son responsables de los resultados del trabajo con los datos. Los usuarios de datos se aseguran de que haya controles de calidad de datos adecuados para el nivel de calidad que necesitan. Los usuarios de datos necesitan una sólida comprensión de sus datos, dominio comercial y las habilidades analíticas requeridas para interpretar los datos. Es razonable encontrar algunas personas entre los usuarios de datos en cada unidad de negocios que serán responsables de los problemas de calidad de los datos.

Para asegurar el éxito, es importante tener estos roles claramente definidos y ampliamente aceptados dentro de su organización en las primeras etapas de su proyecto DQ. Es igualmente importante encontrar especialistas en datos competentes para estos roles que respalden el proyecto.

Definir las reglas

Encuentre e implemente comprobaciones/reglas DQ útiles . Definir reglas DQ requiere una buena comprensión de su almacén de datos y su uso.

¿Cómo encontrar reglas DQ?

Como se discutió anteriormente, los usuarios de datos (y el propietario de los datos) son responsables del uso de los datos y, por lo tanto, también del nivel necesario de calidad de los datos. Los usuarios de datos deben tener una buena comprensión de sus datos para que puedan dar la mejor entrada para las reglas de calidad de datos útiles.

Ellos también son los que analizan los resultados de las reglas de calidad de datos, por lo que siempre es una buena idea dejar que ellos definan sus propias reglas. Esto mejora aún más la aceptación para verificar y calificar el resultado de las reglas DQ asignadas a una unidad de usuario de datos (consulte el capítulo "Analizar").

El inconveniente de este enfoque es que los usuarios de datos normalmente solo conocen la capa del mercado de datos, no las capas anteriores del almacén de datos. Si los datos se corrompieron en las etapas "inferiores", esto no se detectará al verificar solo la capa "superior" de su almacén de datos.

Abordar errores

¿Qué tipo de errores conocidos pueden ocurrir en un almacén de datos?

• Lógica de transformación incorrecta en el almacén de datos
  • Cuanto más complejo sea su panorama de TI, más compleja tiende a ser la lógica de transformación. Estos son los problemas de DQ más comunes, y el efecto de dichos errores puede ser datos "perdidos", duplicados, valores incorrectos, etc.
• Proceso de carga inestable o manipulación incorrecta de las cargas
  • La carga de un almacén de datos puede ser un proceso complejo que puede incluir errores en la definición de la orquestación del trabajo (trabajos que comienzan demasiado pronto o demasiado tarde, trabajos no ejecutados, etc.). Los errores debidos a la intervención manual (p. ej., algunos trabajos se omiten, algunos trabajos se inician con una fecha de vencimiento incorrecta o con los archivos de datos de ayer) ocurren a menudo cuando el proceso de carga se ejecuta fuera de banda debido a alguna interrupción.
• Transferencia de datos incorrecta de fuentes de datos
  • La transferencia de datos a menudo se implementa como una tarea del sistema de origen. Las anomalías o interrupciones en los flujos de trabajo pueden provocar la entrega de datos vacíos o incompletos.
• Datos operativos incorrectos
  • Los datos en el sistema operativo contienen errores no reconocidos hasta el momento. Puede sonar extraño, pero es un lugar común en los proyectos de almacenamiento de datos que la calidad de los datos operativos a menudo no se ve hasta que los datos se incluyen en un DWH.
• Interpretación errónea de los datos
  • Los datos son correctos, pero los usuarios no saben cómo interpretarlos correctamente. Este es un “error” muy común que no es estrictamente un problema de calidad de los datos, sino algo que tiene que ver con el gobierno de los datos y es una tarea de los administradores de datos.

Estos problemas a menudo son causados ​​por personas que carecen de los conocimientos y habilidades adecuados para definir, implementar, ejecutar y trabajar con una solución de almacenamiento de datos.

Dimensiones de calidad de datos

Las dimensiones de DQ son una forma común de identificar y agrupar las comprobaciones de DQ. Hay muchas definiciones y el número de dimensiones varía considerablemente: puede encontrar 16 o incluso más dimensiones. Desde una perspectiva práctica, es menos confuso comenzar con algunas dimensiones y encontrar una comprensión general de ellas entre los usuarios.

• Integridad: ¿Todos los datos requeridos están disponibles y accesibles? ¿Están todas las fuentes necesarias disponibles y cargadas? ¿Se perdieron datos entre etapas?
• Coherencia: ¿Hay datos erróneos/contradictorios/incoherentes? Por ejemplo, la fecha de finalización de un contrato en estado "Terminado" debe contener una fecha válida superior o igual a la fecha de inicio del contrato.
• Singularidad: ¿Hay duplicados?
• Integridad: ¿Están todos los datos vinculados correctamente? Por ejemplo, ¿hay pedidos vinculados a identificaciones de clientes inexistentes (un problema clásico de integridad referencial)?
• Puntualidad: ¿Están actualizados los datos? Por ejemplo, en un almacén de datos con actualizaciones diarias, esperaría que los datos de ayer estén disponibles hoy.

Los datos generados por el proceso de carga del almacén de datos también pueden ser útiles.

• Tablas con datos descartados. Su almacén de datos puede tener procesos para omitir/retrasar datos que no se pueden cargar debido a problemas técnicos (p. ej., conversión de formato, valores obligatorios faltantes, etc.).
• Registro de información. Es posible que se escriban problemas notables en las tablas de registro o en los archivos de registro.
• Recibo de entrega. Algunos sistemas utilizan "albaranes de entrega" para los datos proporcionados por los sistemas operativos (p. ej., número de registros, número de claves distintas, sumas de valores). Estos se pueden utilizar para verificaciones de reconciliación (ver más abajo) entre el almacén de datos y los sistemas operativos.

Tenga en cuenta que cada verificación de calidad de datos debe ser analizada por al menos un usuario de datos (consulte el capítulo "Analizar") en caso de que se encuentren errores, para lo cual necesitará a alguien responsable y disponible para cuidar cada verificación implementada.

Dentro de un almacén de datos complejo, puede terminar con muchas (a veces miles) reglas DQ. El proceso para ejecutar reglas de calidad de datos debe ser lo suficientemente robusto y rápido para manejar esto.

No verifique los hechos que están garantizados por la implementación técnica. Por ejemplo, si los datos se almacenan en un DBMS relacional, no es necesario verificar si:

• Las columnas definidas como obligatorias contienen valores NULL.
• Los valores de los campos de clave principal son únicos en una tabla.
• No existen claves foráneas en una tabla con comprobaciones de integridad relacional habilitadas.

Dicho esto, siempre tenga en cuenta que un almacén de datos está en constante cambio y que la definición de datos de campos y tablas puede cambiar con el tiempo.

La limpieza es muy importante. Las reglas definidas por diferentes unidades de usuarios de datos pueden superponerse y deben consolidarse. Cuanto más compleja sea su organización, más limpieza será necesaria. Los propietarios de datos deben implementar un proceso de consolidación de reglas como una especie de "calidad de datos para reglas de calidad de datos". Además, las comprobaciones de calidad de los datos pueden volverse inútiles si los datos ya no se utilizan o si su definición ha cambiado.

Clases de reglas de calidad de datos

Las reglas de calidad de datos se pueden clasificar según el tipo de prueba.

• Comprobación de la calidad de los datos. El caso "normal", verificar datos dentro de una capa de almacenamiento de datos (ver Figura 1), ya sea dentro de una tabla o un conjunto de tablas.
• Reconciliación. Reglas que verifican si los datos se transportaron correctamente entre las capas del almacén de datos (consulte la Figura 1). Estas reglas se utilizan principalmente para verificar la dimensión DQ de "Completitud". La conciliación puede utilizar una sola fila o un enfoque resumido. La verificación de filas individuales es mucho más granular, pero deberá reproducir los pasos de transformación (filtrado de datos, cambios en los valores de campo, desnormalización, uniones, etc.) entre las capas comparadas. Cuantas más capas omita, más compleja debe implementarse la lógica de transformación. Por lo tanto, es una buena opción hacer la reconciliación entre cada capa y su predecesora en lugar de comparar la etapa de preparación con la capa de data mart. Si se deben implementar transformaciones en las reglas de reconciliación, ¡use la especificación, no el código del almacén de datos! Para la conciliación resumida, busque campos significativos (p. ej., resumen, recuento de valores distintos, etc.).
• Supervisión. Un almacén de datos generalmente contiene datos históricos y se carga con extractos delta de datos operativos. Existe el peligro de que aumente lentamente la brecha entre el almacén de datos y los datos operativos. La creación de series temporales resumidas de datos ayuda a identificar problemas como este (p. ej., comparar los datos del mes pasado con los datos del mes actual). Los usuarios de datos con un buen conocimiento de sus datos pueden proporcionar medidas y umbrales útiles para las reglas de monitoreo.

Cómo cuantificar un problema de calidad de datos

Una vez que haya definido qué verificar, deberá especificar cómo cuantificar los problemas identificados. Información como "cinco filas de datos violan la regla DQ con ID 15" tiene poco sentido para la calidad de los datos.

Faltan las siguientes piezas:

• Cómo cuantificar/contar los errores detectados. Puede contar el "número de filas", pero también puede usar una escala monetaria (por ejemplo, exposición). Tenga en cuenta que los valores monetarios pueden tener diferentes signos, por lo que tendrá que investigar cómo resumirlos de manera significativa. Podría considerar usar ambas unidades de cuantificación (recuento de filas y resumen) para una regla de calidad de datos.
• Población. ¿Cuál es el número de unidades verificadas por la regla de calidad de datos? "Cinco filas de datos de cinco" tiene una calidad diferente de "cinco de 5 millones". La población debe medirse utilizando la(s) misma(s) cuantificación(es) que para los errores. Es común mostrar el resultado de una regla de calidad de datos como un porcentaje. La población no debe ser idéntica al número de filas de una tabla. Si una regla DQ verifica solo un subconjunto de los datos (por ejemplo, solo contratos rescindidos en la tabla de contratos), se debe aplicar el mismo filtro para medir la población.
• Definición del resultado. Incluso si una verificación de calidad de datos encuentra problemas, esto no siempre tiene por qué causar un error. Para la calidad de los datos, es muy útil un sistema de semáforos (rojo, amarillo, verde) que utilice valores de umbral para calificar los hallazgos. Por ejemplo, verde: 0-2 %, amarillo: 2-5 %, rojo: más del 5 %. Tenga en cuenta que si las unidades de usuarios de datos comparten las mismas reglas, es posible que tengan umbrales muy diferentes para una regla determinada. A una unidad comercial de marketing podría no importarle la pérdida de algunos pedidos, mientras que a una unidad de contabilidad podría importarle incluso centavos. Debería ser posible definir umbrales en porcentaje o en cifras absolutas.
• Recopile filas de errores de muestra. Ayuda si una regla de calidad de datos proporciona una muestra de los errores detectados; normalmente, las claves (¡comerciales!) y los valores de datos verificados son suficientes para ayudar a examinar el error. Es una buena idea limitar el número de filas de error escritas para una regla de calidad de datos.
• A veces, es posible que encuentre "errores conocidos" en los datos que no se corregirán pero que se encuentran mediante verificaciones de calidad de datos útiles. Para estos casos, se recomienda el uso de listas blancas (claves de registros que deben ser omitidas por un control de calidad de datos).

Otros metadatos

Los metadatos son importantes para enrutar el "Analizar" y monitorear las fases del ciclo de control de calidad de datos.

• Artículos comprobados. Ayuda a asignar las tablas y campos marcados a una regla de calidad de datos. Si tiene un sistema de metadatos mejorado, esto podría ayudar a asignar automáticamente usuarios de datos y un propietario de datos a esta regla. Por razones reglamentarias (como BCBS 239), también es necesario demostrar cómo DQ verifica los datos. Sin embargo, asignar reglas automáticamente a usuarios/propietarios de datos a través del linaje de datos (*) podría ser un arma de doble filo (ver más abajo).
• Usuario de datos. Cada regla DQ debe tener al menos un usuario de datos/unidad de usuario de datos asignado para verificar el resultado durante la fase de "Analizar" y decidir si un hallazgo influye en su trabajo con los datos y cómo lo hace.
• Titular de los datos. Cada regla DQ debe tener asignado un propietario de datos.

(*) El linaje de datos muestra el flujo de datos entre dos puntos. Con el linaje de datos, puede encontrar todos los elementos de datos que influyen en un campo de destino determinado dentro de su almacén.

El uso del linaje de datos para asignar usuarios a las reglas puede ser problemático. Como se mencionó anteriormente, los usuarios comerciales generalmente solo conocen la capa del data mart (y el sistema operativo), pero no los niveles inferiores del almacén de datos. Al mapear a través del linaje de datos, a los usuarios de datos se les asignarán reglas con las que no están familiarizados. Para los niveles inferiores, es posible que se necesite personal de TI para evaluar un hallazgo de calidad de datos. En muchos casos, un mapeo manual o un enfoque mixto (mapeo a través del linaje de datos solo dentro del data mart) puede ayudar.

Medición de la calidad de los datos

Medir la calidad de los datos significa ejecutar las reglas de calidad de datos disponibles, lo que debe hacerse automáticamente , desencadenado por los procesos de carga del almacén de datos. Como hemos visto antes, puede haber una cantidad notable de reglas de calidad de datos, por lo que las comprobaciones llevarán mucho tiempo.

En un mundo perfecto, un almacén de datos se cargaría solo si todos los datos están libres de errores. En el mundo real, este rara vez es el caso (siendo realistas, casi nunca es el caso). Dependiendo de la estrategia de carga general de su almacén de datos, el proceso de calidad de los datos debería o no (lo último es mucho más probable) gobernar el proceso de carga. Es un buen diseño tener procesos de calidad de datos (redes de trabajo) paralelos y vinculados a los procesos de carga de almacenamiento de datos "regulares".

Si hay acuerdos de nivel de servicio definidos, asegúrese de no frustrar las cargas del almacén de datos con los controles de calidad de los datos. Los errores o anomalías en los procesos de calidad de datos no deberían detener el proceso de carga normal. Los errores inesperados dentro de los procesos de calidad de datos deben informarse y mostrarse para la fase "Analizar" (consulte el próximo capítulo).

Tenga en cuenta que una regla de calidad de datos puede fallar debido a errores inesperados (tal vez la regla en sí se implementó incorrectamente o la estructura de datos subyacente cambió con el tiempo). Sería útil si su sistema de calidad de datos proporcionara un mecanismo para desactivar dichas reglas, especialmente si su empresa tiene pocos lanzamientos por año.

Los procesos de DQ deben ejecutarse e informarse lo antes posible , idealmente, inmediatamente después de que se cargaron los datos verificados. Esto ayuda a detectar errores lo antes posible durante la carga del almacén de datos (algunas cargas complejas del sistema de almacén tienen una duración de varios días).

Analizar

En este contexto, "analizar" significa reaccionar a los hallazgos de calidad de los datos. Esta es una tarea para los usuarios de datos asignados y el propietario de los datos.

La forma de reaccionar debe estar claramente definida por su proyecto de calidad de datos. Los usuarios de datos deben estar obligados a comentar sobre una regla con hallazgos (al menos reglas con luz roja), explicando qué medidas se están tomando para manejar el hallazgo. El propietario de los datos debe estar informado y debe decidir junto con los usuarios de los datos.

Las siguientes acciones son posibles:

• Problema grave: Hay que solucionar el problema y repetir la carga de datos.
• El problema es aceptable: intente arreglarlo para futuras cargas de datos y maneje el problema dentro del almacén de datos o los informes.
• Regla DQ defectuosa: repare la regla DQ problemática.

En un mundo perfecto, todos los problemas de calidad de los datos se solucionarían. Sin embargo, la falta de recursos y/o tiempo a menudo resulta en soluciones alternativas.

Para poder reaccionar a tiempo, el sistema DQ debe informar a los usuarios de datos sobre “sus” reglas con hallazgos. Usar un tablero de control de calidad de datos (tal vez con el envío de mensajes de que surgió algo) es una buena idea. Cuanto antes se informe a los usuarios sobre los hallazgos, mejor.

El panel de calidad de los datos debe contener:

• Todas las reglas asignadas a un rol dado
• Los resultados de las reglas (semáforo, medidas y filas de ejemplo) con la capacidad de filtrar reglas por resultado y dominio de datos
• Un comentario obligatorio que los usuarios de datos deben ingresar para los hallazgos
• Una característica para "anular" opcionalmente el resultado (si la regla de calidad de datos informa errores debido a una implementación defectuosa, por ejemplo). Si más de una unidad de negocio tiene asignada la misma regla de calidad de datos, la "anulación" solo es válida para la unidad de negocio del usuario de datos (no para toda la empresa).
• Mostrar reglas que no se ejecutaron o que se anularon

El tablero también debe mostrar el estado actual del proceso de carga del almacén de datos reciente, brindando a los usuarios una vista de 360 ​​grados del proceso de carga del almacén de datos.

El propietario de los datos es responsable de asegurarse de que todos los hallazgos hayan sido comentados y que el estado de la calidad de los datos (original o anulado) sea al menos amarillo para todos los usuarios de los datos.

Para obtener una descripción general rápida, sería útil crear una especie de KPI (indicadores clave de rendimiento) simples para los usuarios/propietarios de los datos. Tener un semáforo general para los resultados de todas las reglas asociadas es bastante fácil si a cada regla se le da el mismo peso.

Personalmente, creo que calcular un valor general de la calidad de los datos para un dominio de datos determinado es bastante complejo y tiende a ser cabalístico, pero al menos podría mostrar la cantidad de reglas generales agrupadas por resultado para un dominio de datos (por ejemplo, "100 reglas DQ con resultados 90% verde, 5% amarillo y 5% rojo”).

Es tarea del propietario de los datos asegurarse de que los hallazgos se corrijan y se mejore la calidad de los datos.

Mejorando Procesos

Como los procesos del almacén de datos cambian con frecuencia, el mecanismo de calidad de los datos también necesita mantenimiento.

Un propietario de datos siempre debe cuidar los siguientes puntos:

• Manténgalo actualizado. Los cambios en el almacén de datos deben ser capturados en el sistema de calidad de datos.
• Mejorar. Implemente nuevas reglas para errores que aún no están cubiertos por las reglas de calidad de datos.
• Línea de corriente. Deshabilite las reglas de calidad de datos que ya no sean necesarias. Consolide reglas superpuestas.

Supervisión de procesos de calidad de datos

El seguimiento de todo el proceso de calidad de los datos ayuda a mejorarlo con el tiempo.

Las cosas que vale la pena ver serían:

• La cobertura de sus datos con reglas de calidad de datos
• El porcentaje de hallazgos de calidad de datos dentro de las reglas activas a lo largo del tiempo
• La cantidad de reglas de calidad de datos activas (esté atento: he visto a usuarios de datos resolver sus hallazgos simplemente deshabilitando más y más reglas de calidad de datos).
• El tiempo necesario dentro de una carga de datos para calificar y corregir todos los hallazgos

Conclusión

Muchos de los siguientes puntos son importantes en cualquier tipo de proyecto.

Anticipar la resistencia. Como hemos visto, si no hay un problema de calidad urgente, la calidad de los datos a menudo se ve como una carga adicional sin ofrecer una nueva funcionalidad. Tenga en cuenta que podría crear una carga de trabajo adicional para los usuarios de datos. En muchos casos, las exigencias normativas y de cumplimiento pueden ayudarlo a convencer a los usuarios de que lo vean como un requisito inevitable.

Encuentra un patrocinador. Como se señaló anteriormente, DQ no es un artículo de venta rápida, por lo que se necesita un patrocinador/accionista poderoso: cuanto más alto en la gerencia, mejor.

Encuentra aliados. Al igual que con el patrocinador, cualquier persona que comparta la idea de una calidad de datos sólida sería de gran ayuda. El bucle del circuito DQ es un proceso continuo y necesita personas para mantener vivo el bucle del circuito.

Empieza pequeño. Si hasta ahora no ha habido una estrategia DQ, busque una unidad de negocios que necesite una mejor calidad de datos. Cree un prototipo para mostrarles el beneficio de mejores datos. Si su tarea es mejorar o incluso reemplazar una determinada estrategia de calidad de datos, mire las cosas que funcionan bien/son aceptadas en la organización y consérvelas.

No pierdas de vista el cuadro completo. Aunque comience de a poco, tenga en cuenta que algunos puntos, especialmente los roles, son requisitos previos para una estrategia DQ exitosa.

Una vez implementado, no lo sueltes. El proceso de calidad de datos debe ser parte del uso del almacén de datos. Con el tiempo, el enfoque en la calidad de los datos tiende a perderse un poco y depende de usted mantenerlo.