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
Comments