La auditoría es un «mecanismo para sacar los problemas a la luz»
El propósito de la auditoría (que otra IA revise el contenido del trabajo) no es obtener el GO (aquí: la aprobación final para continuar).
Este es el núcleo del principio que hemos querido transmitir a lo largo de la segunda parte. La auditoría no está diseñada como un «rito de paso», sino como un «mecanismo para sacar los problemas a la superficie». En este capítulo ordenamos qué significa eso.
Hacer la auditoría «para conseguir el GO» desvía la atención de lo esencial
Cuando escuchas la palabra auditoría, es probable que imagines algo así: «si al final sale el GO, fue un éxito». Hay una revisión y la superas. Hay un examen y lo pasas. Es una sensación que viene de ese tipo de experiencias.
Sin embargo, la auditoría dentro de la organización que hemos diseñado en esta serie funciona de otra manera.
Cuando el objetivo se convierte en obtener el GO, la forma de hacer la auditoría cambia. Si empiezas a moverte con la pregunta «¿puedo pasar?», la atención se desplaza de encontrar problemas a decidir hasta dónde cuenta algo como problema. Si bajas el umbral (aquí: la línea que determina si algo se considera un problema), los problemas dejan de aparecer. El GO se vuelve más fácil de obtener, pero los problemas reales siguen ahí.
La auditoría auténtica funciona en sentido contrario. No se trata de «comprobar que no hay problemas», sino de «sacar a la luz cualquier problema que exista». Si el diseño no puede tolerar que el GO no salga, la auditoría se vacía de contenido (aquí: la estructura sigue en pie pero deja de funcionar).
¿En qué se diferencia de «buscar defectos»?
Aquí aclaramos una confusión frecuente.
Cuando escuchas «sacar los problemas», puede sonar a buscar defectos (aquí: rastrear los errores del otro para criticarlo). Sin embargo, lo que busca la auditoría es distinto.
Buscar defectos pone el énfasis en encontrar un problema para criticar a alguien o demostrar que falló. El problema encontrado se convierte en material para exigir responsabilidades o evaluar el desempeño.
La razón por la que la auditoría saca los problemas es diferente. Si los problemas quedan sin resolver y el trabajo avanza, el costo y el retrabajo serán mayores más adelante. El propósito es sacar los problemas a la superficie en una etapa temprana para poder corregirlos. Que aparezca un problema no es prueba de fracaso; es la confirmación de que «todavía estamos en la etapa en que se puede corregir».
Esta diferencia también afecta la psicología de quienes ejecutan la auditoría. En una cultura donde «sacar un problema significa recibir críticas», la IA encargada de la auditoría tiende a no sacarlo. Si el diseño establece que «sacar problemas es el trabajo», esa misma IA puede hacerlo sin dudar. El diseño que elijas cambia la calidad de la información que realmente llega.
Que aparezcan señalamientos es una señal de que la auditoría funciona
Cuando llevamos esto a la práctica, nos encontramos con situaciones como esta.
Ante el resultado de entrega de un ciclo, la IA encargada de la auditoría devolvió varios señalamientos. Al principio, la cantidad nos hizo pensar: «hay muchos problemas». Pero al leer cada señalamiento, ninguno podía ignorarse. Había desviaciones al comparar con los lineamientos, términos técnicos que no estaban suficientemente explicados, y huecos en la coherencia con los capítulos anteriores y siguientes.
Cuando colocamos la versión corregida junto al resultado original, la calidad de la versión corregida era claramente superior. No es que hubiera muchos problemas porque hubo muchos señalamientos; hubo muchos señalamientos porque había muchos problemas. Ese es el orden correcto.
La auditoría no crea problemas. Solo saca a la luz los que ya existían. Una auditoría con cero señalamientos no significa que no haya problemas. También puede significar que no se encontraron.
Que aparezcan señalamientos es una señal de que el mecanismo funciona con normalidad.
Diseñar para poder avanzar aunque haya problemas
La inquietud de «quizás aparezcan problemas» fácilmente se convierte en resistencia a poner la auditoría en marcha. Sin embargo, los problemas ya existen antes de que se saquen. Solo es que no se ven.
Si comparas que los problemas aparezcan en una etapa temprana con que salgan a la superficie en una etapa posterior, el costo de resolverlos es menor en el primer caso. Cuanto más tarde se descubre un problema, mayor es el alcance de las correcciones necesarias.
En el diseño que usamos en este proyecto, cuando la auditoría detecta un problema, se lo presentamos directamente a la persona a cargo de la aprobación. No como «hubo un problema, así que el GO queda en espera», sino con la forma de «se encontraron estos problemas, decide tú».
Que haya un problema y si hay que seguir adelante son asuntos separados. Según el tamaño del problema, su urgencia y su alcance, la persona a cargo de la aprobación decide: «corrijo y avanzo», «avanzo así», o «lo detengo por ahora». Lo que le corresponde a la auditoría es encontrar y registrar los problemas, no tomar la decisión que viene después.
Con este diseño, la persona a cargo de la auditoría tiene una estructura en la que le resulta fácil «sacar» los problemas. No hay razón para ocultarlos, y sacarlos equivale directamente a completar su rol.
Resumen del capítulo
El propósito de la auditoría no es obtener el GO, sino sacar los problemas a la luz.
Que aparezcan problemas no es una señal de fracaso; es una señal de que el mecanismo funciona. Al contrario, cuando los señalamientos son consistentemente cero, eso es una razón para revisar la granularidad de los criterios y la forma en que se mueve la auditoría.
La auditoría no es buscar defectos. Es un diseño para encontrar problemas en una etapa temprana y reducir el retrabajo en los pasos siguientes. Mantener una estructura en la que sacar problemas equivale directamente a completar el rol es la base para que la auditoría no se vacíe de contenido.