Lo siento Sr Smith, de acuerdo a nuestros registros usted está muerto

Hace un par de días recibí un correo con la información de un vuelo que debo hacer la semana próxima. En él figuraba el código de reserva que debía usar para hacer el checkin on-line. Hoy, 72 horas antes, intenté hacer el checkin como otras tantas veces pero el sistema me dijo que no alegando que el susodicho código estaba mal. Luego de varios intentos, llamé al call center de la aerolínea para ver que había pasado y allí me enteré que estaba usando un código incorrecto. “¿Incorrecto?” dije yo “pero si ustedes me enviaron el código”.

La pregunta que me hacía luego es ¿cómo pudieron mandarme el código mal? ¿Alguien que se equivocó al tipear? ¿Había un error en alguno de los tantos sistemas por los que mi reserva pasó? 

Un checkin que usualmente demora 10 minutos terminó llevándome 25 minutos. Imaginen que en una persona cualquiera esto produce irritación pero dada mi área de expertise (ingeniería de software, calidad, informática) la frustración es peor.

Las empresas pierden mucho tiempo y dinero por no prestarle atención a sus datos.

El título de este post está extraído de la página 3 del libro Data Quality for the information age de Thomas Redman. En ese primer capítulo el autor da 3 motivos por los que la calidad de los datos debería ser una preocupación para las empresas:

1. Poor data quality is pervasive. [..] Poor data quality is a plague to wich no industry is inmune - nor is goverment or academia.

2. Poor data quality is costly. It Lowers customer satisfaction, adds expense, and makes it more difficult to run a business and pursue tactical improvements such as data warehouses and re-engineering.

3. Data quality can be improved and the impacts noted above mitigated. Indeed, it seems that improved data quality can be a source of competitive advantage.

Ya no es suficiente probar nuestros sistemas pensando en las variaciones que el código puede producir. Ahora debemos probarlos según las variaciones que pueden producir sus datos también.

Sí, es cierto. Antes de que lo digan lo digo yo. Antes también debíamos probar nuestros sistemas pensando en los datos. Pero lo cierto es que ahora es mucho más necesario puesto que la probabilidad de mal comportamiento en el software debido a problemas en los datos de configuración o customización es mucho mayor.

Los sistemas de hoy en día cambian radicalmente su comportamiento según estos datos. Además utilizan información obtenida de bases de datos externas todo el tiempo. El paradigma de mis datos fueron generados por mi y yo soy el único que los toca ya no existe.

Debemos desempolvar los libros de “data quality” y las técnicas de “data testing”. Mi sensación es que si no, estaremos dejando pasar muchos problemas y entonces todos tendremos anécdotas divertidas como la del Sr. Smith.

Seguimos pensando..