Una aplicación mal diseñada causa un error de 81 trillones de dólares

Si tus aplicaciones internas dan auténtico miedo, ¿qué esperas que ocurra? ¿Y cuánto te puedes fiar de los datos generados por sistemas así?

Citigroup es el tercer banco más grande de EEUU. Cuenta con dos siglos de historia y más de doscientos mil empleados, de los que me apuesto que una buena parte son del área de IT (más, seguro, un ejército de consultores externos). Pues, en todo ese tiempo, toda esa gente junta no ha sido capaz de diseñar una aplicación ni medio decente para ordenar transferencias.

Resulta que, hasta abril del año pasado, la aplicación rellenaba con quince ceros el campo donde el empleado debía escribir la cantidad que desea mover de una cuenta a otra. ¿Para qué? No se me ocurre una explicación ni remotamente sensata. Así que cada vez que un empleado de Citi quería ordenar una transferencia (o sea, unas decenas de miles de veces al día), se veía obligado a eliminar primero los quince ceros innecesarios y, luego, a escribir el número real. Un papercut de libro, vamos.

Así que solo era cuestión de tiempo que a alguien se le fuera la pinza: en abril del año pasado, un empleado de Citigroup quiso hacer una transferencia de 281 dólares y, debido a la interfaz demoniaca de su aplicación interna, acabó haciendo una transferencia de 81 billones de dólares (nuestro billón es lo que los estadounidenses llaman “trillón”).

O sea: 281 se convirtió en 81.000.000.000.000

Casi nada.

¿Y sabes lo mejor? Que la transferencia se pudo hacer. Sí, una transferencia por una cantidad mucho mayor que todos los activos del banco sumados. ¿Confirmaciones? ¿Controles internos? ¿Límites de cantidad en función de tu perfil de usuario? Nada de nada, amiguetes.

El banco presume de que, en realidad, sí hubo controles que detectaron el error (más tarde, en otro departamento y casi por casualidad) pero, de verdad, yo no sé de qué presumen.

¿Y sabes lo mejor? (bis) Pues que pocos días antes, otro empleado del mismo banco había hecho un copia-pega salvaje y puso el número de cuenta donde debía poner el importe, lo que resultó en un envío de 6.000 millones de dólares, una vez más sin comprobaciones ni aprobaciones adicionales.

De este caso, saco dos pensamientos clave:

• Demasiado a menudo, las aplicaciones de uso interno reciben menos atención que el tercer hijo de una familia. Hacia fuera, todo muy bonito y bien pensado, pero a mis 200.000 empleados les voy a poner la aplicación más fea y enrevesada posible, con el impacto en la productividad que eso puede llegar a tener.

• Luego, cuando vamos a hacer analítica avanzada, nos sorprendemos del bajo nivel de calidad de datos que hay en todas partes pero, claro, si los sistemas transaccionales están como están, ¿qué esperamos encontrar al final del proceso? Llevo tiempo insistiendo en esto: el proceso de aseguramiento de la calidad del dato debe empezar allí donde el dato se crea, en lugar de ser el típico proceso a posteriori para resolver todos los problemas que el dato ha ido acumulando antes de llegarnos.