Del Big Data al Data Quality. La gestión de la calidad de los datos

El uso de datos está presente en casi todas las actividades o tareas de cualquier organización o compañía y se ha convertido en el gran recurso o activo en todos los ámbitos de la vida. Cada decisión a nivel operativo, táctico y estratégico se basa en grandes volúmenes de datos que son procesados y analizados desde diversas fuentes y con usos muy variados.

Foto: Pankaj Patel

La explosión de datos es imparable y todos estamos ya familiarizados con el concepto Big Data, el cual ha venido acompañado de cientos de tecnologías, herramientas o procesos que han permitido, entre otras cosas, la organización, administración o manipulación de enormes repositorios para ponerlos al servicio del negocio.

En esta línea, algunos de los beneficios que se pueden obtener al organizar y gestionar los datos también están claros.Comprender mejor las necesidades de los clientes, mejorar la calidad de los servicios ofrecidos, mejorar la planificación y la previsión o incluso predecir y prevenir riesgos. Estos son algunos de esos beneficios que, a su vez, llevan implícitos la propia evolución que estamos viviendo de disciplinas orientadas a la Inteligencia Artificial.

Sin embargo, para alcanzarlos y generar valor a partir de las soluciones basadas en Big Data y AI, es imprescindible tener en cuenta el significado y calidad de los datos, así como comprender su contexto de uso.

Nuevos retos en la era del Big Data

Hubo un tiempo que las organizaciones y grandes compañías utilizaban los datos generados única y exclusivamente a partir de sus propios entornos y sistemas. Los productores de datos eran, en su mayor parte, los mismos que los consumían y su calidad no representaba un problema.

Descubrir información que fuera relevante, y que permitiera tomar decisiones a partir de una gran cantidad y variedad de datos, puede que llevara tiempo pero no dejaba de ser una tarea más a conseguir para lograr la ansiada ventaja competitiva.

Ahora, los datos recogidos y analizados, provienen de una mayor diversidad de fuentes con tipologías muy variadas y estructuras más complejas. A su vez, el número de productores y consumidores de datos ha crecido y la diferenciación entre estos y otros perfiles de usuario puede ser mayor. En consecuencia, determinar la calidad en orden a la necesidad de cada uno de ellos implica más esfuerzo y recursos.

Añadimos más variables a este planteamiento. ¿Cuáles son las características que definen la calidad para un usuario determinado?. Si un data scientist está trabajando sobre un modelo predictivo con los datos de los clientes, puede que la precisión le parezca más importante que el volumen o la máxima actualidad de esos datos. Si por el contrario, es el departamento comercial el que está lanzando una oferta y requiere de esos mismos datos, no será tan importante la precisión o exactitud como la accesibilidad o la pertinencia de los mismos.

Para el departamento de contabilidad, la fecha de nacimiento del cliente no es un campo obligatorio. Ante su ausencia, ellos consideran que los datos de ese cliente no son de mala calidad. Pero marketing considera ese campo clave, así que dicho departamento puede valorar que los datos de contabilidad no tienen calidad.

Aun más, el trabajo de un equipo médico puede verse seriamente comprometido si los datos que utiliza son imprecisos, inaccesibles, irrelevante o incompletos.

Por tanto, la calidad de los datos puede ser definida por su valor de negocio, por objetivos concretos o por las prioridades que marque la propia organización. Pero en todo este planteamiento se demuestra también que los usuarios son un componente clave en la definición que se haga de esa calidad.

Alcanzar una calidad de datos óptima, hacerlo en un plazo de tiempo razonable y con un volumen de datos en continuo crecimiento se convierte en un desafío difícil de afrontar.

Ahora bien, definir y mejorar de forma continua la calidad de los datos tampoco es un objetivo que pueda quedar aislado ni relegado a un grupo de personas, departamento/s o tecnología.

Como señala Gartner, este desafío afecta a organizaciones de todos los tamaños y puede destruir el valor del negocio o producir perdidas pocas veces valoradas en los resultados de las compañías.

Data Quality

La calidad de los datos o Data Quality es un area de trabajo e investigación que comenzó en la década de los 90, con el rápido crecimiento de las tecnologías de la información y la comunicación.

En la década anterior la preocupación había estado centrada en la calidad misma de los productos y en el grado en el que sus características y funcionalidades cumplían con los requisitos. Fue una época en la que se consolidó la definición ampliamente aceptada de calidad como conformidad con los requisitos.

El trabajo de Joseph M. Juran da buena cuenta de esa búsqueda constante de la calidad y satisfacción del producto e incorpora una nueva y sencilla definición: adecuación al uso (fitness for use). Esta definición ha sido ampliamente utilizada en la literatura sobre Data Quality y constituye un buen punto de partida para evaluar hasta qué punto los datos sirven para los fines o necesidades de los usuarios.

El grupo Total Data Quality Management del MIT University, liderados por el profesor Richard Y. Wang, dio continuidad al trabajo de Juran y llegó a definir un conjunto de atributos o dimensiones para medir y gestionar la calidad de los datos. Categorías útiles cuya evaluación puede ser automatizada para valorar la idoneidad y adecuación de los datos en orden a objetivos de negocio o necesidades de los usuarios.

Dimensiones de la calidad del dato

Wang y Strong (1996) en su artículo Beyond Accuracy: What Data Quality Means to Data Consumers (PDF) proponen una división en 4 categorías con un total de 15 dimensiones:
Intrínseca: Los valores de los datos se ajustan a los valores reales o actuales.
Dimensiones: Credibilidad, exactitud, objetividad, reputación.
Contextual: Los datos son aplicables (pertinentes) a la tarea del usuario del dato.
Dimensiones: Valor añadido, relevancia, pertinencia temporal, completitud, cantidad de datos.
Representativa: Los datos son presentados de forma inteligible y clara.
Dimensiones: Interpretabilidad, facil de comprender, consistencia representacional, representación concisa.
Accesibilidad: Los datos están disponibles o es posible acceder a ellos.
Dimensiones: Accesibilidad, seguridad de acceso.

Dimensions of Data Quality

Estudios posteriores han ido modificando esta clasificación y el listado de dimensiones que engloba. En 2013 Dan Myers hizo un estudio comparativo y propuso una nueva lista (Conformed Dimensions of Data Quality) evitando conflictos terminológicos y buscando la comprensión y la estandarización.

Algunas organizaciones como la Data Administration Management Association (DAMA) o Data Warehousing Institute (TDWI) han aportado sus propias clasificaciones y definiciones, llegando a un total de 6 dimensiones fundamentales para la gestión de la calidad del dato (PDF). Serían las siguientes:

  • Exactitud (Accuracy): Se mide el grado en el que los datos representan correctamente el objeto del mundo real o un evento que se describe.
    Ejemplo: La dirección de envío de pedidos a un cliente en la base de datos de clientes es la dirección real.
  • Completitud (Completeness): El grado en el que el dato tiene el valor esperado y cumple con los requerimientos marcados. Si un dato es opcional no debe considerarse para lograr el 100% de completitud.
    Ejemplo: Podemos establecer que los clientes tendrán sus datos completos si hemos registrado su nombre, primer apellido, segundo apellido, número de identificación, e-mail, dirección, código postal, ciudad y país. El segundo nombre será opcional.
  • Consistencia (Consistency): Mide si los datos están libres de contradicción y tienen coherencia lógica, de formato o temporal.
    Ejemplo: Para un cliente determinado tenemos ventas registradas pero no nos consta ninguna orden de pedido.
  • Pertinencia temporal (Timeliness): Mide el grado en que los datos están disponibles cuando se requieren.
    Ejemplo: Para la asignación de habitaciones en un hotel, la recepción debe contar con el número actualizado de habitaciones disponibles en el momento de registrar la llegada del cliente.
  • Unicidad (Uniqueness): Cada dato es único. Con esta dimensión se busca corregir la duplicidad inesperada en nuestros dataset.
    Ejemplo: En nuestra base de datos podemos tener dos clientes que se registraron como «Fran García» y «Francisco Juan García», siendo la misma persona pero sólo el último contiene todos los datos completos.
  • Validez (Validity): Medir si un valor se ajusta a una regla de negocio o a un estándar preestablecido en cuanto a formato, tipo de dato, valores posibles o rangos especificados.
    Ejemplo: En el seguimiento de entrega de un pedido, la última actualización es posterior a la hora actual. Dan Myers expone este caso en su blog explicando que si existiera una regla de negocio que indique que las actualizaciones no pueden producirse en una fecha y hora superior a la actual del sistema, este problema no se hubiera producido.

Todas estas dimensiones son atributos que no representan la calidad real de los datos. Una compañía con buena calidad de los datos no es necesario que cumpla, por ejemplo, con el 100% de completitud o de unicidad de los datos.

La calidad viene dada por cómo alineamos los requisitos de datos de negocio con los niveles de cada una de estas dimensiones.

Incluso es posible que los datos que estaban completos para un proceso dado, en un proceso futuro pueden estar incompletos o requieran de un nuevo planteamiento desde negocio.

Los procesos de negocio y los casos de uso que se vayan definiendo exigen una mejora continua de la calidad.

Pizarra digital de Herbert Spencer y la paradoja de Bricklin

Esto mas que un post es una agradecimiento público a Herbert Spencer (@hspencer) por compartir con todos Pizarra, una sencilla a la vez que útil aplicación creada con Processing para PC, Mac y Linux, que convierte la pantalla de tu ordenador en una pizarra proyectable.

La reflexión que hace Spencer sobre la necesidad de crear esta herramienta me parece soberbia. Viene a decir que el proceso de crear, dibujar, idear, es tan poderoso como el resultado en sí mismo. Por eso, una aplicación así, rápida y eficiente, resuelve la exposición pública y la compartición de dicho proceso ajustándose a las características del contexto.

Bocetos, wireframes de baja fidelidad, esquemas o explicaciones que demandan expresividad gráfica tienen cabida en Pizarra.

En cierta ocasión escribí sobre este asunto relacionado con la creación de aplicaciones que resuelven problemas específicos y lo llamé la paradoja de Bricklin, haciendo referencia a Dan Bricklin y Bob Frankston, creadores en 1978 de VisiCalc, el primer programa moderno de manipulación de datos a partir de hojas de cálculo.

Bricklin & Frankston
Imagen de Jim Raycroft

El resultado de su trabajo fue una importante aportación a la evolución de una potente herramienta utilizada por millones de personas en todo el mundo. Pero lo mas curioso es que, en el año 2007, después de toda la revolución en este género de programas, Bricklin «se vio obligado» a crear Shiva, una reducción razonada de una compleja hoja de cálculo.

Captura de la aplicación shiva

Se trata de un programa que no requiere bases de datos ni complicadas instalaciones o configuraciones. Fue creado inicialmente para la Newton Centre Minyam, una comunidad religiosa judía en la que Bricklin participa activamente, aunque su ideación y desarrollo responde a un objetivo mas amplio y compartido.

The Software Garden Shiva Signup program is a server-based program to facilitate keeping track of group member sign ups for attendance at events, providing food, etc. It is very general purpose. The program runs on a web server and is accessed using a browser connected to the Internet. Written in Perl, it comes with complete source code but is designed to be easily customized by users without needing to know Perl. The product is available as Open Source software under the GNU GPL license for no charge.

Sorprende que el mismo tipo que había trabajado sobre uno de los programas de tratamiento de datos mas revolucionario de la historia, descubriera que no había algo sencillo, fácil, rápido e intuitivo para gestionar los datos de una pequeña comunidad en un contexto determinado.

Shiva no tiene una interfaz revolucionaria y es posible que nunca llegue a ser una extendida herramienta de gestión pero resuelve una necesidad optimizando esfuerzo, tiempo, objetivos y aprendizaje, sin hacer mas de lo que debería realmente hacer.

Puede que Pizarra no se convierta en una aplicación universal (aunque, como dice la frase, las oportunidades pequeñas son el principio de las grandes empresas) pero responde a un planteamiento maduro y bien razonado donde la tecnología no es lo mas importante. Gracias Spencer.

Hábitos y comportamientos convertidos en mapas de calor

En la evaluación de interfaces web los heatmaps o mapas de calor son representaciones que nos muestran patrones de exploración visual y nos ayudan a detallar donde han centrado su atención los usuarios. Su utilidad está muy asociada con el eye-tracking ya que constituye una de las posibles representaciones del conjunto de datos que esta tecnología es capaz de recoger.

Sin embargo su alcance como forma de representación y visualización de datos es mayor y así nos lo demuestra el programador alemán Martin Dittus. Su colección de heatmaps estructurados, construidos a partir de la actividad individual de usuarios de last.fm, nos descubre posibles patrones en los hábitos de escucha.

Heatmaps by Martin Dittus

Cada mapa se construye a partir de la periodicidad en la escucha de música. El año, mes, día de la semana, horas del día… Un año completo de datos se organiza a partir de una fila, agrupada en 12 bloques horizontales, una para cada mes. A su vez cada mes se organiza a partir de un mosaico de 7 columnas para los días de la semana y 24 filas para las horas del día.

El código de colores muestra la medida de la intensidad relativa. A partir de un número determinado (Gris – verde – amarillo – rojo) se resalta la actividad mantenida durante todo el día. Así, una tira de luz gris resalta las horas más activas del día durante todo el período.

Cualquier cambio o cese de la actividad queda registrado y si se suceden regularmente pueden interpretarse patrones en los hábitos y comportamientos de los usuarios.

Frequently people’s graphs are detailed enough to provide a fairly good summary of big life changes. New jobs, busy weekends, holidays, the month when they bought an iPod, or picked up running again, or moved to a different timezone, … I found that showing these graphs to the people portrayed often stimulated interesting conversation about their habits and their choices.

David Singleton, amigo de Dittus y participante en el experimento, publicó en su blog una explicación a los mapas que él mismo generó.

Mid-2005 to 2006 – Finished Uni, got a job and spent the first 6+ months comuting without an iPod after moving to London was still missing a laptop for a long time.
Late 2007 – An increase in evening listening, a sign of joining the Last.fm team and getting stuck in to startup culture of late nights.
Early 2008 – Evening listening, but with more separation from daytime listening. I suspect this was nights spent playing albums with my flatmate Ben Ward.
2009 – Less evening music, which I think stems from different flat mates, a different flat and starting (an unscrobbled) vinyl collection.
February 2010 – A quiet month for scrobbling, most of which on holiday in New York, little time for digital music.

underpangs

La parte humana de la experiencia de usuario

Gord Hotchkiss habla en su artículo Understanding The Human Part Of The User Experience sobre algo que parece evidente pero que es necesario recordar para no alterar el significado de la experiencia de usuario.

Tratar de entender qué necesita o quiere el ser humano significa evaluar su comportamiento como seres humanos, no como máquinas que ofrecen datos y que están preparadas para alcanzar objetivos.

Se trata de un aspecto que no es fácil respetar porque acostumbramos a procesar muchos datos y los convertimos automáticamente en respuestas y comportamientos humanos. ¿Es esa la mejor y la única manera de entender y trabajar la experiencia de usuario?.

My point, and there is one, is that we consider user experiences and test usability, we have to have a fine appreciation for what makes humans human. All too often, usability testing relies on reams of data, crunched and analyzed in a zillion different ways. We examine bounce rates and benchmarks, as if our users were machines and the answers we seek can be arrived at mathematically.

The irony of usability is that, most often, we try to understand what humans want without ever talking to one directly. We rely on a spreadsheet to reveal the mysteries and subtleties of the human condition. We reduce the magnificence of the human brain to nothing more than a machine, something that can be understood by examining inputs and outputs.