En los datos, la calidad importa

DQ_lens-and-seal

Recientemente cobró notoriedad en los medios el caso del error cometido por el Ministerio de Hacienda, según su propia declaración, al imputar a la Infanta Cristina la venta de varias propiedades[1]. Hacienda atribuyó el error a los notarios, diciendo que al registrar las escrituras en la aplicación de Hacienda, habían introducido erróneamente en el campo del DNI el número 14, coincidente con el de la Infanta . El DNI de la Infanta Cristina es el “00.000.014-Z”. No está claro qué ocurrió realmente. Según parece, la aplicación permitía introducir un número sin la letra de verificación correspondiente y sin tener todos los dígitos, completando con ceros a la izquierda. Los notarios ponen objeciones a la explicación del error, porque dicen que en algunos casos el número 14 estaba en el campo “otros” del formulario y no en el del DNI. También dicen que el sistema de Hacienda se mejoró en 2007. Sin embargo el caso nos inspira algunas reflexiones sobre un tema cada vez más importante en IT: la calidad de los datos, Data Quality en inglés (DQ)[2].

En el caso mencionado, vemos que hubo errores en la captura de los datos, también en la interpretación que se hizo de un campo (el campo “otros” que mencionan los notarios), y también de traspaso, ya que si el dato no estaba en el campo DNI ¿cómo llegó a ocupar ese lugar en los informes de Hacienda? Y si debía ser un DNI, ¿cómo no se validó con la letra correspondiente?
Este error le costó el puesto a la entonces Directora de la Agencia Tributaria, que tuvo que cargar con la responsabilidad por el problema de los datos erróneos.  Otras veces, las consecuencias de la mala calidad de datos no son tan espectaculares, pero igual se dejan sentir al producir información falsa si no se detecta el problema a tiempo.

La calidad de los datos

Una pobre calidad en los datos acarrea menor eficacia en las operaciones marketing, con muchos correos electrónicos rechazados y correo postal devuelto, pérdida de oportunidades de negocio, stock no optimizado en el almacén, mayores posibilidades de fraude, procesos de reporting complejos, lentos y poco fiables, y fundamentalmente, entorpece la toma de decisiones.

Inicialmente, los proyectos de DQ se centraron en las direcciones postales, pero con el tiempo quedó claro que prácticamente todos los datos de una organización merecen ser considerados desde el punto de vista de la calidad.  Y uno de los problemas principales en la calidad de datos es que no suele haber alguien responsable de ello en la organización. Cuando se descubre que hay datos repetidos o inconsistencias serias que comprometen la fiabilidad de la información obtenida, se busca desesperadamente limpiar y conciliar las bases de datos, pero es necesario algo más. Está surgiendo una nueva disciplina, el Gobierno de Datos[3], con el fin de fijar procesos que aseguren los activos de datos gestionados por las organizaciones consideran la Calidad de Datos como uno de las áreas de actuación y seguimiento

Vivimos en la sociedad del conocimiento. Los datos son el origen en la cadena de valor datos → información → conocimiento, tal como he comentado un post anterior “De los datos al conocimiento“. Por lo tanto si los datos de que disponemos para realizar nuestra actividad y los que vamos generando con ella no son suficientemente buenos, no tendremos buena información y poco podremos aprender de la misma.

La inteligencia de negocio o Business Intelligence (BI) está en auge puesto que ahora muchas organizaciones de todo tamaño perciben que deben usar las IT para algo más que para registrar sus transacciones, llevar el inventario y la contabilidad.  Necesitan dar un salto y utilizar las tecnologías de la información para conocer, para saber lo realmente sucede, para tomar decisiones más informadas. Pero ¿qué sentido tiene encarar un proyecto de BI si los datos de que disponemos no tienen la suficiente calidad?

¿Qué se entiende por calidad en los datos?

Hay varios criterios para juzgar la calidad de un conjunto de datos. Según Joseph Juran “Los datos son de alta calidad si son aptos para los usos previstos en las operaciones, la toma de decisiones y la planificación“.

En general podemos decir que los datos son buenos si reflejan con cierta fidelidad la realidad. Esto se traduce en algunas características que los datos deben tener para ser de calidad, entre las que podemos destacar:
  • Exactitud. Los datos tienen que reflejar lo más fielmente posible los atributos que representan. Por ejemplo, las direcciones postales deben estar correctamente descriptas, sin ambigüedades. Exactitud también implica ausencia de sesgo en la evaluación, como por ejemplo cuando se valora el monto de una oportunidad comercial. Si siempre somos demasiado optimistas, tendremos luego unas previsiones infladas.
  • Precisión. Los datos deben tener un formato suficientemente preciso, según la finalidad con la que se recoge. Así por ejemplo, es necesario capturar el importe de una transacción al céntimo, pero carece de sentido especificar al céntimo una previsión de ventas.  También se puede hablar de falta de precisión cuando el campo “nombre” de una persona no tiene la longitud suficiente y obliga a ignorar alguno de ellos o a abreviarlos, como suele pasar en las tarjetas de crédito. No es lo mismo exactitud que precisión [4].
  • Representación consistente. La representación del mismo dato en distintas instancias debe ser igual. Por ejemplo, si para la ciudad de Santa Cruz de Tenerife a veces encontramos el nombre completo y otras veces uno abreviado como “S. Cruz de Tenerife”, vamos a tener un problema al intentar agrupar o filtrar datos que tengan este atributo en común.
  • Unicidad. No puede haber varios valores en el mismo campo. Las listas separadas por coma deben evitarse como cuando se ponen varios números de teléfono en un solo campo, ya que trae muchas complicaciones para extraerlo o compararlo. Este criterio también implica que las taxonomías para clasificar deben estar correctamente estructuradas. Una lista de categorías de actividad que tenga “Administración Pública” y “Justicia” dará lugar a una ambigüedad y dispersión de criterios cuando se tenga que asignar a organismos que son tanto de una como de la otra categoría. La unicidad también se refiere a que tengamos un único registro para la misma entidad, es decir sin registros duplicados.
  • Actualidad. Los datos deben mantenerse actualizados, deben revisarse periódicamente o cada vez que se tenga oportunidad. Por ejemplo, si durante una visita un comercial es informado de que una persona de uno de sus clientes ha cambiado de dirección de correo, debe actualizarla en los sistemas. Para esto deben ponerse en marcha procedimientos y prácticas de actualizaciones permanentes.
  • Reputación. El origen del dato debe ser suficientemente fiable para los fines perseguidos. Si se basa en suposiciones puede introducir mucha distorsión. Imaginemos que tenemos en nuestro ERP el campo “Límite de crédito” en la ficha de cada cliente. Si se le asigna su valor según el parecer del administrativo en lugar de hacerlo a partir de informes bancarios o de entidades especializadas, este dato será poco efectivo en el control del riesgo.
  • Completitud. Un conjunto de datos debe tener sus atributos suficientemente completos según el propósito deseado. Alguna gente piensa que los campos que no son obligatorios en un formulario no deben rellenarse para ahorrar tiempo en la entrada de datos. Pero la razón por la que no son obligatorios puede ser porque su valor puede ser desconocido en el momento de dar de alta el registro, pero puede obtenerse posteriormente.  Supongamos que tenemos el dato del “Sector de Actividad” en la ficha de una cuenta en un CRM. Si sólo unos pocos registros lo tienen asignado, este campo no nos servirá para segmentar.
  • Valor añadido. Los datos que se recogen, almacenan y procesan deben tener un valor como atributo de la entidad a que pertenecen relacionado con los problemas que los sistemas intentan resolver. Por ejemplo, no aportaría valor tener el campo “Color de cabello” en la ficha de un cliente si somos un taller de mecánica del automóvil, pero podría ser importante si nos dedicamos a la venta de cosméticos.

Mejorando la calidad de los datos

Es evidente que la calidad de los datos comienza con el diseño del modelo de datos de las aplicaciones y con el proceso de captura de los mismos. Pero muchas veces, eso no está en nuestra mano, porque las aplicaciones son estándares y son lo que son, o porque los datos provienen de una fuente externa como una base de datos de asistentes a una feria o el catálogo de productos de un fabricante, o bien porque se trata de datos ya existentes. ¿Cómo hacemos para mejorar la calidad de los datos? Es necesario realizar una serie de acciones coordinadas que van desde la limpieza o curado de los datos hasta la revisión de sus procedimiento de captura y del modelo de las aplicaciones.

Contratar a becarios para limpiar las bases de datos no va a resolver el problema. En primer lugar, las personas que hacen la limpieza deberán conocer algo de la naturaleza de los datos que están tratando. Por ejemplo, cómo decidir si las cuentas “IBERIA LAE SA” e “IBERIA SA” se refieren a la misma empresa o no? Se necesita un cierto conocimiento de las cuentas de la organización para diferenciar las que se parecen pero son realmente distintas de las que están duplicadas. En segundo lugar, el mantenimiento de la calidad de datos es un proceso continuo. A partir de la limpieza inicial deben ajustarse  procedimientos y aplicaciones y hacer luego una medición y un seguimiento, de lo contrario los datos volverán a perder calidad en poco tiempo.

Por lo tanto, se necesitan herramientas específicas que nos permitan hacer análisis y correcciones semiautomáticas para encarar una mejora en la calidad de datos. Las propias aplicaciones pueden tener algunas facilidades, como la detección de posibles registros duplicados, pero en general carecen de un enfoque integral para este propósito. Una herramienta muy poderosa, que es software libre, es OpenRefine (antes Google Refine) sobre la que hablaremos en otro post.

Para el curado de los datos se aplican varias técnicas como:
  • Perfilado (profiling) para encontrar patrones y distribuciones en los datos.
  • Normalización. La representación consistente de nombres, domicilios, teléfonos, etc.
  • Clustering o agrupamiento para identificar discrepancias, erratas y duplicidades.
  • Reglas de asociación, para encontrar dependencias entre valores en un registro.
  • Comparación con bases de datos externas de exactitud conocida
  • Enriquecimiento mediante el cruce con otras bases de datos o la consulta automatizada de fuentes de datos externas

Dependiendo de las necesidades, el curado de los datos puede hacerse off-line u on-line. El curado off-line es un problema para sistemas operacionales, pero es la solución más adecuada para migraciones o actualizaciones de sistemas. Los datos necesarios se exportan de los sistemas existentes y se someten al proceso de curado utilizando alguna herramienta, reglas de negocio y quizás fuentes externas para validar parte de los datos. El resultado se exporta y se transfiere al nuevo sistema. El curado on-line es el necesario para sistemas operacionales. El resultado de la limpieza se traduce en una serie de operaciones que se aplicarán cuidadosamente al sistema para no romper las reglas de consistencia.

Los momentos en los que se suele poner de relieve la necesidad de una acción de calidad de datos suelen ser la migración de un sistema, la integración y conciliación de datos de sistemas diferentes, la realización de un proyecto de BI, la necesidad de segmentar, la proximidad de una campaña de marketing, la fusión de empresas y cumplimiento de normativas, por citar los casos más conocidos.

La labor de un consultor externo para estos proyectos puede ayudar mucho a las organizaciones al aportar una visión fresca de las reglas y procedimientos para establecer un proceso de mejora y seguimiento de la calidad de los datos. Sin buenos datos no hay buena información, y sin ella no se puede conocer realmente y las decisiones que se tomen tendrán más riesgo. No esperemos a que el problema nos desborde.

Referencias

[1] Los notarios asumen errores en cinco de las fincas atribuidas a la Infanta
[2] Wikipedia: Data Quality
[3] Wikipedia: Data governance
[4] Wikipedia: Precisión y exactitud

 

 

No se aceptan nuevos comentarios.