«¿Y si se equivoca?»

Es la primera pregunta, siempre. Le cuentas a alguien que un sistema va a leer sus albaranes y meterlos en su programa sin que nadie los toque, y antes de terminar la frase te interrumpe: «¿y si se equivoca?».

Es una buena pregunta. Lo que pasa es que casi todo el mundo la contesta mal, y las dos respuestas malas son las que se oyen en todas partes.

La primera es «no se equivoca». Es mentira. Todo sistema se equivoca, el mío también, y quien te diga lo contrario o no lo ha medido o no te lo va a contar.

La segunda es «por eso lo revisa una persona». Suena responsable y es lo que la mayoría quiere oír. También es la peor de las dos, pero eso da para otro día.

La respuesta buena no va de evitar el error. Va de qué pasa después.

Un error no es un error

Mete todo lo que puede salir mal en un proceso administrativo y verás que no se parece en nada entre sí:

• La factura llega en una foto torcida y borrosa.
• El proveedor cambió el formato del albarán el mes pasado y nadie avisó.
• El programa de gestión está caído esta mañana.
• El número de pedido existe, pero es de otro cliente.
• El importe se ha leído bien, pero en dólares en vez de euros.

Tratarlos todos igual —«ha fallado, avisa a alguien»— es lo que convierte una automatización en un incordio. Tres de esos cinco casos se resuelven solos si el sistema sabe que existen. Uno se resuelve esperando veinte minutos. Y sólo uno debería llegar hasta ti.

La diferencia entre un sistema que sirve y uno que no es cuántos de esos cinco casos estaban previstos antes de escribir la primera línea.

Las cuatro cosas que tiene que hacer

Cuando algo sale mal, un sistema bien hecho hace cuatro cosas, y en este orden.

1. Darse cuenta

Parece obvio y es donde falla casi todo. Un sistema que mete datos incorrectos con la misma tranquilidad con la que mete los correctos no tiene un problema de precisión: tiene un problema de ceguera.

Darse cuenta no es comprobar que el programa no ha dado error. Es comprobar que el resultado tiene sentido: que la suma de las líneas cuadra con el total, que la fecha no está en el futuro, que el proveedor existe, que ese importe no es cien veces mayor que cualquier otro de ese cliente.

Lo caro no es el error. Es el error que nadie ve durante cuatro meses.

2. Parar a tiempo

Un sistema que detecta algo raro y sigue adelante «por si acaso» es peor que uno que no detecta nada, porque además te da confianza.

Parar significa parar esa operación, no el sistema entero. Si un albarán de doscientos viene ilegible, los otros ciento noventa y nueve tienen que entrar igual. Una automatización que se cae entera porque un documento venía torcido no te ha quitado trabajo: te lo ha cambiado de sitio.

3. Dejar rastro

De cada cosa que hace tiene que quedar constancia de qué entró, qué salió y por qué decidió lo que decidió. No para cumplir con nadie: para que el día que algo salga raro se pueda contestar la pregunta «¿por qué hizo eso?» en cinco minutos y no en dos días.

Si un sistema no puede explicar una decisión suya de hace tres semanas, no está automatizando tu proceso. Está escondiéndolo.

4. Arreglarlo

Aquí es donde se separan las cosas. La mayoría de los errores de un proceso administrativo tienen arreglo sin que intervenga nadie, porque no son errores de criterio: son datos en el sitio equivocado, en el formato equivocado o en el momento equivocado.

Una imagen ilegible se puede procesar de otra manera. Un programa caído estará levantado dentro de un rato. Un formato nuevo se puede reconocer. Que un sistema mande a un humano a resolver eso no es prudencia, es no haberlo terminado.

Lo que sí llega hasta ti

Queda un resto. Es pequeño y es real: lo que no se puede decidir sin saber algo que no está en ningún documento.

Un pedido que dice cuarenta unidades cuando ese cliente nunca pasa de diez. Un precio que no cuadra con el acuerdo que cerraste tú por teléfono. Un proveedor nuevo que nadie ha dado de alta.

Eso no es un fallo del sistema. Es información que no existe dentro del proceso, y ningún sistema, por bueno que sea, puede inventársela. Ahí sí tiene sentido que suene tu teléfono.

La pregunta útil, entonces, no es «¿y si se equivoca?». Es esta otra:

¿Cuántas veces al mes va a sonar mi teléfono, y por qué motivos?

Si quien te lo vende no sabe contestarla, todavía no sabe lo que te va a construir.