El error no lo comete el técnico

Un error de datos no cuesta lo que cuesta corregirlo. Cuesta las horas que alguien dedica, tres semanas más tarde, a reconstruir qué pasó en un turno, a rehacer el dato en los tres sitios a los que ya ha viajado y a dar explicaciones. La plantilla ha echado sus horas y nadie ha holgazaneado: buena parte de ese mes se ha ido en deshacer cosas. Ese trabajo tiene nombre, retrabajo, y no aparece en ningún informe con ese nombre.

El trabajo invisible: corregir

Un técnico termina el turno. Antes de irse rellena el parte: horas trabajadas, si hubo nocturnidad, si se ausentó y por qué. Lo hace de memoria, con prisa, en un formulario que acepta cualquier cosa. El error no se ve ese día. Se ve tres semanas después, cuando alguien tiene que usar ese dato para algo. Y ahí empieza lo caro: reconstruir qué pasó de verdad ese turno preguntando a quien se acuerde, corregirlo en los dos o tres sitios a los que ya ha viajado y, si llegó a la nómina, explicárselo al trabajador. Ahí ya deja de ser un problema de datos y pasa a ser una conversación incómoda.

Ninguna de esas tres cosas produce nada. Son horas de gente competente dedicadas a dejar las cosas como deberían haber estado hace tres semanas.

Por qué no sale en ningún informe

Y no sale en ningún informe porque nadie imputa «retrabajo». Se imputa a administración, a RRHH, al cierre de mes. En el resumen del trimestre esas horas se leen como carga de trabajo normal, indistinguibles de las que sí producen algo. Y lo que no se cuenta no se decide: no hay ninguna reunión en la que alguien proponga reducir una partida que no existe en ninguna tabla. De ahí salen las dos conclusiones caras de siempre: que hace falta contratar, o que hay que cambiar el sistema. Las dos cuestan dinero y ninguna toca el sitio donde se origina el problema, así que al mes siguiente vuelve a pasar.

Por qué es tentador culpar al técnico

También es tentador culpar al técnico. Se hace la formación, mejora dos meses, y vuelve. Vuelve porque el problema no es de rigor: se le está pidiendo a una persona cansada que recuerde con precisión algo que pasó hace ocho horas, y se le está dando un formulario que no le ayuda a acertar. Con esas condiciones el error no es un fallo, es el resultado previsible del diseño. La pregunta útil no es quién se equivocó: es en qué momento se pidió el dato.

Lo que cambia al mover la validación al punto de entrada

En un grupo industrial multi-planta el problema declarado era «necesitamos otro sistema». Al medirlo, no era eso: el ERP funcionaba. Lo que fallaba era el punto de entrada. Tres cambios, ninguno espectacular:

Lo que desaparece con los errores no es solo el error: es el mes de trabajo que se iba en corregirlos.

La regla general, que es lo que se lleva cualquiera

“Un error corregido donde se produce cuesta segundos. El mismo error corregido donde se detecta cuesta horas, y a veces cuesta una conversación con un trabajador.”

— La regla general

Por eso la pregunta que hay que hacerse ante un proceso que da problemas no es qué sistema comprar, sino cuánto tiempo pasa entre que el dato se introduce mal y alguien se entera. Si la respuesta se mide en días, ahí está el arreglo, y casi nunca es comprar software.

Cómo saber si os pasa

Cuántas horas al mes dedica vuestro equipo a corregir, reconstruir o perseguir datos que ya se habían introducido una vez; cuánto tarda administración en cerrar el mes y cuánto de eso es esperar correcciones; y cuando aparece un error, cuántos días han pasado desde que se introdujo. Si la primera no se sabe, ese es el primer trabajo. Si la tercera se responde en días o semanas, el problema no está donde se detecta.

Lo que este caso no demuestra

No demuestra que un sistema nuevo arregle una planta. De hecho demuestra lo contrario, porque el ERP se quedó como estaba. Lo que cambió fue dónde y cuándo se pide el dato. Si alguien os propone sustituir el sistema entero antes de haber medido en qué momento entra el error, está resolviendo su problema, no el vuestro.

Preguntas frecuentes

¿Cuánto cuesta realmente un error de datos?

Depende de una sola variable: cuánto tarda en detectarse. Corregido en el momento en que se introduce, cuesta segundos. Detectado tres semanas después, cuesta las horas de reconstruirlo, más las correcciones en cada sitio al que el dato ya ha viajado, más —si ha llegado a afectar a alguien— la conversación. Por eso los cálculos macro que circulan no sirven para decidir nada: el número que importa es el vuestro, y sale de contar días.

¿Qué es exactamente el retrabajo?

Trabajo que se hace por segunda vez porque la primera salió mal, y que por tanto no añade nada nuevo. Ocupa a gente competente y consume capacidad real, pero se contabiliza como carga de trabajo normal.

¿Esto no es simplemente poner validaciones?

En parte sí, y por eso sorprende lo poco que se hace. Lo difícil no es la validación: es saber cuál poner, y eso sale de mirar los errores reales del último año, no de imaginarlos.

¿Los operarios no se resisten?

Menos de lo que se teme, si el formulario les ahorra trabajo en vez de dárselo. Un formulario que valida es un formulario que evita que te llamen tres semanas después.

¿Hace falta cambiar el ERP?

En este caso no. Y conviene desconfiar de quien lo proponga antes de medir.