Validación de datos de tus productos de BI
- Matias Zayas
- Jul 3, 2024
- 14 min read

Introducción
No hay mayor satisfacción que la de concebir productos de datos ampliamente utilizados y apreciados por usuarios satisfechos, desarrollados con elevados estÔndares de calidad. En esta ocasión, abordaré cómo intentar asegurar calidad de los datos a través de métodos y procesos de validación, para intentar incrementar la tasa de uso y satisfacción. Mi enfoque abarcarÔ aspectos teóricos como prÔcticos.
Aclaración importante: No pretendo hablar de cómo llegar a la āverdadā (que por cierto, probablemente no exista en su estado mĆ”s puro, aunque con datos trabajemos y seguros nos podamos sentir al respecto), hablarĆ© de validez y del mĆ©todo, que nos permitirĆ” seguir razonamientos lógicos, para aceptar o rechazar hipótesis (intento de respuesta) altamente contrastadas y contextualizadas, es decir, conocimiento vĆ”lido (o validado) o invalido, en la medida que siga un mĆ©todo.
Validación de datosĀ podrĆa definirse como un proceso para asegurar la calidad de los datos,Ā lo cual implica asegurar laĀ precisiónĀ (el grado de fidelidad, libre de errores), la integridadĀ (en quĆ© grado representan todas las propiedades de la realidad; los datos son de mayor calidad si estĆ”n completos e incluyen toda la información relevante) y la coherenciaĀ (sigue los estĆ”ndares y convenciones establecidos, y el grado de ausencia de contradicciones en los datos).
Verificar la exactitud y la integridad es un paso esencial para evaluar la calidad de los datos. Esto implica verificar que los datos sean precisos y completos, y asegurarse de que reflejen la realidad de la situación prevista. Se implementa mediante la creación de varias comprobaciones en un sistema, para garantizar la coherencia lógica de los datos de entrada, almacenados y utilizados posteriormente.
ĀæTe has preguntado quĆ© significa āasegurarā?
He encontrado las siguientes definiciones:
Garantizar:Ā Hacer que algo sea seguro o cierto, proporcionando garantĆas o medidas para evitar problemas o riesgos.
Afirmar con certeza: Declarar o afirmar algo con seguridad y convicción.
Proteger contra pérdidas o daños: Tomar medidas para prevenir riesgos o daños a algo o alguien.
Hacer seguro:Ā Proporcionar condiciones o medidas que garantizan la seguridad o estabilidad de algo.
Obtener o adquirir:Ā Conseguir algo de manera segura o cierta.
Convencer: Lograr que alguien esté seguro o convencido de algo.
En el contexto de este post, me quedarĆ© con āgarantizarā, āhacer seguroā, āconvencerā y āafirmar con certezaā, aunque me permitirĆ© adaptarla a āafirmar con relativaĀ certezaā.
¿Te has preguntado qué significa calidad?
La RAE me brinda varias definiciones, sin embargo, he decidido exponer las que considero mƔs relacionadas con la temƔtica del post:
Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor.
Adecuación de un producto o servicio a las caracterĆsticas especificadas.
LuĆs Cuatrecasas menciona que Calidad āes el conjunto de caracterĆsticas que posee un producto o servicio obtenidos en un sistema productivo, asĆ como su capacidad de satisfacción de los requisitos del usuarioā. (āGestión integral de la calidad. Implementación, control y certificaciónā, ediciones gestion 2000, 3era edición, Barcelona, 2005).
La norma ISO 9000:2005 plantea que la calidad es el grado en el que un conjunto de caracterĆsticas inherentes que cumplen con los requisitos. (ISO 9000:2005. āSistema de gestión de la calidad Fundamentos y vocabularioā).
Desde las distintas definiciones (que por cierto he dejado fuera las de Feigenbaum, Juran, Crosby, Deming, Ishikawa y Taguchi) y distintos puntos de vista sobre calidad, se observan dos comunes denominadores: la satisfacción del cliente y el cumplimiento de los requisitos. Por lo tanto, se puede entender que el objetivo principal de la calidad va enfocada al cliente, donde cumplir con las expectativas del destinatario final.
¿Qué es y para qué buscamos asegurar determinados niveles de calidad de nuestros productos de datos?
āEl aseguramiento de la calidad es clave en cualquier desarrollo de producto y en todos los procesos implicados, para garantizar que el producto final cumpla con todos los requisitos y alcance el mayor nivel de garantĆa y seguridad.ā (Infinitia consulting)
Basado en todo lo anterior, ĀæserĆ” que lo que buscamos es generar confianza? En lo personal, creo que sĆ.
¿Te has preguntado qué es la confianza?
āNadie utilizarĆ” un producto en el que no pueda confiar. Entonces, ĀæquĆ© significa confiar en un producto de datos y, lo que es mĆ”s importante, quĆ© se necesita para confiar? Para entender esto, me gusta utilizar el concepto de āconfianzaā ofrecido por Rachel Botsman: el puente entre lo conocido y lo desconocido. Un producto de datos necesita cerrar la brecha entre lo que los usuarios de datos saben con confianza sobre ellos y lo que no saben, pero necesitan saber para confiar en ellos.ā (Zhamak Dehghani, Data Mesh)
A partir de la referencia anterior, comencĆ© a investigar sobre el vĆnculo entre el conocimiento y la confianza.
Por lo tanto, todo lo que continúa a partir de ahora, se enfocarÔ en cómo lograr esa confianza (y calidad) sobre nuestros productos de datos, a partir de procesos y buenas prÔcticas que nos aseguren precisión, integridad y coherencia, que entreguen datos que reflejen veracidad del negocio, en un marco de comprensión, entendimiento, accesibilidad y transparencia para stakeholders, colegas de equipo, otros dominios y end-users.
"La confianza se gana en gotas y se pierde en litros" Jean Paul Sartre
PrÔcticas en búsqueda del aseguramiento de la calidad
Ahora toca tratar de materializar los distintos aspectos que permitan asegurar calidad desde el punto de vista de negocio, abstrayĆ©ndonos de procesos meramente tĆ©cnicos y programĆ”ticos, mĆ”s bien, validar datos que ya han pasado por procesos anteriores de aseguramiento de la calidad (por cierto, muchos de ellos, procesos continuos y no necesariamente āanterioresā). Si te interesa tener una visión un poco mĆ”s tĆ©cnica de otras fases del aseguramiento dela calidad, visita mi post anterior en el siguiente enlace.
ĀæQuĆ© caracterĆsticas deben cumplir esas personas para ser capaces de "asegurar calidad"?
ComenzarĆ© con un fragmento de una clase de filosofĆa de la ciencia (epistemologĆa):
āLos filósofos, para clasificar la naturaleza y función de la filosofĆa de la ciencia, distinguen dos sentidos en que se puede hablar del saber, en relación a una prĆ”ctica o actividad:
En un primer sentido, el saber relativo a una actividad, consiste simplemente en realizar dicha actividad satisfactoriamente.
En otro sentido, del saber relativo a una actividad, consiste en conocer y ser capaz de formular, explĆcitamente, determinadas propiedades o caracterĆsticas de esa actividad.
La capacidad de realizar correctamente una actividad, por tanto, no basta por sĆ sola para poder formular explĆcitamente en quĆ© consiste la prĆ”ctica correcta de dicha actividad. Por otro lado, si bien quizĆ”s menos manifiesto, es igualmente cierto, que lo primero tampoco es condicion necesaria para lo segundoā.Ā MartĆn Prebble, profesor de filosofia de la UBA (Universidad de Buenos Aires).
Por trazar un paralelismo, bajo mi interpretación, las personas expertas, al abordar la validación de datos en un contexto organizacional, a menudo enfrentan dos aspectos clave relacionados con el conocimiento y la habilidad:
Realización efectiva de la actividad: En primer lugar, la habilidad para validar datos implica ejecutar los procesos de validación de manera satisfactoria, es decir, asegurarse de que los datos sean precisos, completos y confiables para su uso en anÔlisis y toma de decisiones.
Comprensión y formulación explĆcita de las caracterĆsticas del proceso:Ā Sin embargo, ademĆ”s de simplemente realizar la validación de datos, tambiĆ©n es importante comprender y poder articular explĆcitamente las propiedades y caracterĆsticas fundamentales del proceso de validación de datos. Esto implica tener un conocimiento profundo de las tĆ©cnicas, metodologĆas y estĆ”ndares aplicables, asĆ como la capacidad de comunicar claramente los resultados y hallazgos a las partes interesadas.
Es crucial destacar que tener la habilidad para realizar correctamente la validación de datos no garantiza automĆ”ticamente la capacidad de explicar en detalle cómo se lleva a cabo este proceso y cuĆ”les son sus aspectos crĆticos. Del mismo modo, la comprensión profunda de los conceptos y principios subyacentes de la validación de datos no siempre se traduce directamente en la capacidad de implementarlos eficazmente en la prĆ”ctica.
Por lo tanto, para llevar a cabo procesos de validación de datos de manera efectiva en un entorno empresarial, se requiere una combinación de habilidades técnicas para ejecutar los procedimientos de validación, habilidades comunicativas para explicar y documentar claramente el proceso, los métodos, el contexto y sus resultados a diversas audiencias dentro de la organización, y finalmente, creatividad y curiosidad para explorar alternativas y caminos.
Dicho lo anterior, en mi humilde opinión, deberĆas buscar y encontrar:
las personas mÔs expertas del proceso en cuestión;
las personas que mƔs conocimiento y experiencia en la materia;
Las personas con experiencia en técnicas y procesos de validación y aseguramiento de calidad;
personas que pertenezcan a las unidades de negocio o unidades funcionales, y que estĆ©n lo mĆ”s cerca del origen de los datos y de las casuĆsticas.
personas que puedan inferir la validez o invalidez sobre los datos que tenemos disponibles.
personas que tengan habilidades de comunicación, para transmitir los mĆ©todos, supuestos, criterios aplicados, y los resultados logrados en función a la casuĆstica planteada para su resolución.
Suele resultar difĆcil encontrar personas que dominen todos los ejes temĆ”ticos susceptibles de ser validados, por lo que serĆ” necesario dividir responsabilidades y trabajar en equipo; por ejemplo, anĆ”lisis de la producción desde distintos enfoques: a) la perspectiva productiva con un enfoque de ingenierĆa o de procesos de fĆ”brica; b) la perspectiva productiva con un enfoque de calidad de la producción; c) un anĆ”lisis de la producción desde la perspectiva de cotrol de gestión (importes, cantidades, centro de coste, cuenta contable, etcĆ©tera); d) un anĆ”lisis contable para cierre de balance segĆŗn IFRS, y asĆ tantos ejes como sean necesarios.
Al final, es el conjunto de experiencia, conocimiento tĆ©cnico, el conocimiento del proceso de negocio y la tĆ©cnica de validación. Esto nos permitirĆ” seguir aportando al objetivo final: asegurar calidad para la casuĆstica determinada de un usuario Ā”y crear confianza!.
Esquema general de pruebas
Las pruebas ayudan a identificar y solucionar cualquier problema o error en el producto de datos y garantizan que satisfaga las necesidades y expectativas de los usuarios.
Antes de que las personas hagan pruebas, es necesario darles un contexto, ya sea de lo que se espera del desarrollo como de lo desarrollado. De ser posible documentación o un esqueleto de las pruebas o esquema que se usaron para validar los desarrollos.
Algunos pasos que se pueden seguir para probar el producto de datos:
Definir los casos de prueba: el primer paso para probar el producto de datos es definir los casos de prueba. Los casos de prueba son escenarios o condiciones especĆficos bajo los cuales se debe probar el producto de datos.
Configurar el entorno de prueba. Esto implica crear una réplica del entorno de producción en el que se utilizarÔ el producto de datos y garantizar que esté configurado correctamente.
Ejecutar los casos de prueba. Luego, los casos de prueba se pueden ejecutar utilizando el producto de datos y verificando que funcione como se esperaba. Los problemas o errores de hormigas que se identifiquen deben documentarse y rastrearse.
Revisar los resultados de las pruebas. Una vez que se hayan ejecutado los casos de prueba, se deben revisar los resultados de las pruebas para identificar cualquier problema o Ɣrea de mejora.
Solucionar cualquier problema. Cualquier problema o error identificado durante las pruebas debe solucionarse antes de que se lance el producto de datos.
¿Qué aspectos es recomendable testear?
Antes de continuar, quiero recordar, que antes ha habido un equipo de desarrollo que crea los productos de datos (modelos semĆ”nticos, APIs, objetos de bases de datos, excels, etcĆ©tera) que durante la construcción deberĆan haber hecho su trabajo de aseguramiento de calidad, y que ahora, lo que nos compete es darle sentido de negocio al proceso. Dicho esto, continĆŗo con los algunos ejemplos de aspectos importantes a testear:
Que los datos sean actuales, precisos y completos.
Verificacar la coherencia: ****Una verificación de coherencia es un tipo de verificación lógica que confirma que los datos se ingresaron de manera lógicamente consistente. Un ejemplo es comprobar si la fecha del pedido es anterior a la fecha de entrega.
CasuĆsticas particulares de los procesos de negocio. ĀæExisten facturas sin albarĆ”n?
Seguridad y privacidad, incluyendo aspectos legales. Por ejemplo RLS, datos sensibles, etcƩtera.
Adaptación de las normas de la industria u otros estÔndares: la organización deberÔ definir la necesidad o requerimiento de adaptación a las normas necesarias.
Presupuestos: evaluar que se estÔn considerando los presupuestos aprobados (importes, tipos de cambio, cantidades, por cada dimensión y según la granularidad de los mismos).
¿Y contra qué debemos contrastar?
Utiliza datos históricos como punto de referencia, dado que proporcionan un punto de referencia valioso.
Construye benchmarks: Crea benchmarks o estÔndares internos basados en datos históricos o en comparaciones con otras empresas del mismo sector. Por ejemplo: KPIs corporativos, datos de la industria.
ĀæNo tienes datos históricos fiables? SerĆ” mĆ”s duro, pero usa lo que tengas para compararte, apóyate en las casuĆsticas de negocio para realizar cĆ”lculos y validar a mĆ”s bajo nivel de detalle y hazlo en equipo, con las personas que estĆ”n mĆ”s cerca del origen de los datos, para crear entre todos el nuevo estĆ”ndar. Este aƱo me ha pasado este caso y lo resolvimos trabajando en equipo los especialistas de las bases de datos especĆficas, desarrolladores y personas de operaciones que nos brindaron criterio y muchas horas de anĆ”lisis y validación. Un Ć©xito total.
¿No tienes absolutamente nada con lo que comparar? TendrÔs que crear predicciones basadas en modelos y datos de la industria, que luego tendrÔs que ir ajustando en la medida que generas datos.
Documentación
En el Ć”mbito de los datos, la documentación desempeƱa un papel fundamental en la garantĆa de la calidad y la confianza en la información. Es crucial proporcionar visibilidad mediante la documentación de los criterios adoptados, las transformaciones realizadas, los resultados de los controles de calidad, las validaciones de negocio, la estadĆstica de los datos y todo lo referido al tema. Esta documentación no solo establece las expectativas de los usuarios en cuanto a la utilidad de los datos para el anĆ”lisis, sino que tambiĆ©n brinda transparencia sobre el proceso de preparación de los datos. Sin embargo, es importante reconocer que no todos los usuarios son tĆ©cnicos y pueden necesitar una documentación que sea comprensible y accesible para ellos. Es aquĆ donde a menudo enfrentamos desafĆos, ya que la comunicación efectiva con personas de negocios no tĆ©cnicas puede resultar compleja.
Es fundamental que la documentación sea legible para el ser humano, lo que implica presentar la información de manera clara, concisa y fÔcil de entender para todos los interesados. Para obtener mÔs información sobre distintos sistemas de documentación, se puede consultar el enlace proporcionado por la empresa Divio en este enlace.
Cuando estés realizando pruebas de validación, documenta cada caso:
Escribe en un excel (por ejemplo) cada casuĆstica que en ese momento sabes que quieres testear y ve actualizando dicho excel con las casuĆsticas que vas identificando. Intenta crear una plantilla (template) para el futuro (El excel es una idea š ).
Guarda las queries, excels, .pbix o lo que uses para ejecutar las pruebas. AyudarÔn en la trazabilidad y a recordar cómo has hecho en el pasado las pruebas.
Escribe en un documento (word, notion, confluence, Power Point, etcĆ©tera) el desarrollo de cada casuĆstica antes definida: cómo lo has hecho, los resultados (ok, no ok), las discrepancias, filtros aplicados y todas aquellas evidencias y contextos que permitan, al equipo de desarrollo, encontrar y corregir errores (debugging) y realizar mejoras sobre los productos.
Otra idea es grabar (Stream, Teams, Loom, Meets o cualquier otra herramienta), para evitar al equipo de desarrollo leer tanto.
Y como siempre, tanto como se pueda automatizar, mejor.
Puntos crĆticos
Tiene que haber responsables de la validación (calidad de datos), alguien que sea responsable de la propiedad del dato (data owners), esto es altamente recomendado, por no decir Obligatorio.
Tiene que existir formación. Hay que enseñar a validar con métodos eficientes, hay que enseñar el contedio de los modelos de datos.
Tiene que haber soporte durante el proceso. El equipo de desarrollo (técnico/funcional) tiene que estar a disposición de las data owners durante el proceso de validación para resolver dudas, realizar mejoras o lo que fuera necesario para culminar la tarea. El equipo técnico-funcional debe entender que es parte del scope de la tarea y de la funcionalidad creada. El Data owner tiene que tender puentes entre el equipo de desarrollo y el equipo que valida. Hablar sobre la carga cognitiva (abstraer la complejidad).
Tiene que haber health para mantener viva la validación. Crear reporting ad hoc que nos de visibilidad y alertas sobre los puntos de control. Si creas un report de Power BI (por ejemplo) y creas alertas sobre los objetos (con las reglas que sean necesarias), podrĆ”s resolver las incidencias a tiempo. El health tambiĆ©n pueden ser procesos automĆ”ticos que detecten anomalĆas a travĆ©s del uso de mĆ©todos estadĆsticos.
Explicitar los test y validación que se realizaron; con los resultados esperados y logrados. Esto darÔ un un marco o contexto a la usuaria, definiendo expectativas y contextos para su uso (final o cómo parte de otro proceso). Hay que entender el origen de los resultados, que lógica tienen, si hablamos de una correlación o de un resultado causal. Entender y conocer de donde viene, como conseguimos lo datos. Debemos preguntarnos siempre la validez.
Tiene que haber procesos de validación aceptados por la organización y buenas prÔcticas compartidas. Crea una wiki con procesos, plantillas, ejemplos o lo que consideres necesario para compartir conocimiento.
Beneficios de la validación de datos
Mejora la calidad de las decisiones.
Fortalece la estrategia de transformación de la organización a data-driven decisions
Puede ayudar a evitar información imprecisa la cual puede costar dinero al negocio, y al mismo tiempo, ponerlo en riesgo.
Permite detectar problemas y errores fƔcilmente, y solucionarlos antes de que se conviertan en un problema para el negocio.
Complementario al punto anterior, ahorro de tiempo, dinero y recursos al aplicar procesos adecuados de validación. Evitar conversaciones y reuniones extras para debatir sobre inconsistencias, evitar reprocesos, disminuir la cantidad de incidencias, evitar procesos paralelos por desconfianza
La información precisa y completa puede permitir identificar oportunidades de negocio, tomar mejores decisiones de optimización de costes e incrementar rentabilidades.
Aumenta la confianza sobre tus productos de datos (Data as a Product), consolida la estrategia data-driven y fortalece la cultura empresarial basada en datos. Mejora la reputación del producto y del Owner del producto.
Aumenta el valor de la empresa (al considerar el dato como un activo), y cuanto mÔs valor se agrega a la empresa a través de lo información, mÔs valor se le asigna al activo, y en consecuencia, mÔs valor tiene la empresa.
Aumenta la satisfacción de los End-Users y del equipo Owner de los datos. Y la autorrealización del equipo Owner del producto, al menos asà lo vivo yo.
La calidad de datos no depende de una persona, depende de la organización: desde que se origina un dato hasta que se usa en su extremo opuesto. Cómo lo genero, como lo gestiono, como lo documento, con lo modelo, como lo distribuyo, como lo consumo, el aporte que hago para su mejora, la apertura y receptividad a feedback para su mejora.
DesafĆos
La validación de datos es compleja. En general, asegurar la precisión es una tarea difĆcil. La dificultad aumenta a medida que la base de datos (o los modelos de datos, datasets) comienza a extraer datos de mĆŗltiples fuentes, cuando tienes orĆgenes diversos con datos estructurados y no extructurados.
La validación de datos conlleva mucho tiempo, especialmente para bases de datos complejas y de diversos orĆgenes. Sin embargo, es crĆtico para todo proyecto para dar buenos resultados.
Reducir la carga cognitiva del proceso. Mejor documentado y mejor explicado favorece el entendimiento de quien quiera analizarlo.
La validación de datos se adapta a casuĆsticas especĆficas. Cuando diseƱamos un sistema de validación de datos, a menudo lo hacemos teniendo en mente un conjunto particular de requisitos. Si ese conjunto de requisitos alguna vez cambia, debemos modificar nuestro sistema de validación de datos para adaptarlo a los nuevos requisitos.
Compromiso con el producto que creamos. La validación de nuestros datos estĆ” directamente relacionada con la calidad de nuestros productos de datos, calidad a la cual nos comprometemos con nuestras usuarias, ya sea implĆcitamente o explĆcitamente (data contract).
Cultura de Calidad de Datos: La validación y verificación de datos no es solo una tarea tĆ©cnica, sino tambiĆ©n una cuestión de cultura organizacional. La cultura de calidad de datosĀ es fundamental para garantizar que todos los miembros de la organización comprendan la importancia de los datos precisos y estĆ©n comprometidos con mantener altos estĆ”ndares de calidad.Ā Educa y concientiza, lidera con el ejemplo, incentiva y reconoce, crea e implementa procesos de revisión y auditorĆa, aprende de los errores a partir de comunidades de aprendizaje, comparte historias de fracasos y Ć©xitos sobre la temĆ”tica, y por Ćŗltimo, y mĆ”s difĆcil, crea un sistema de medición de la calidad.
Conclusión
Tu estrategia de Gobernanza de datos deberĆa considerar los procesos relacionados a validación de datos. Si es que no tienes una estrategia de gobernanza, al menos, te recomiendo que tengas estos procesos, y que ademĆ”s, sean explĆcitos: escritos, publicados, revisados, mejorados, pĆŗblicos (dentro de la empresa, a tu pĆŗblico objetivo) y por sobre todo, co-creados. Los procesos deberĆan incluir los mĆ©todos y las tĆ©cnicas en las que confĆa la organización para ejecutar la validación.
Los datos no hablan por sĆ solos siempre, los datos no son la verdad en sĆ misma, sino que estĆ”n mediados por la experiencia, las casuĆsticas a las que se busca responder (contexto), los mĆ©todos utilizados para su estandarización, su contraste.
Por cerrar, te dejo dos conceptos:
Verdad: es la relación entre pensamiento y realidad. Como resultado tenemos verdadero o falso.
Validez: esquema lógico, el esqueleto que subyace a todo razonamiento; los razonamientos serÔn vÔlidos o invÔlidos.
Gracias š¤
Matias