Auditorías de proceso por capas (LPA).

Qué son las auditorías de proceso por capas

Una auditoría de proceso por capas es una verificación corta y programada de que el trabajo que ocurre en una estación sigue coincidiendo con su estándar: los ajustes, la secuencia, las verificaciones y las condiciones que fija la hoja estándar. «Por capas» significa que cada nivel de la gestión verifica contra los mismos estándares, cada uno con su propia frecuencia: el líder de equipo a diario, el gerente de área cada semana, la dirección de planta cada mes. Cada auditoría se reduce a un puñado de preguntas que se contestan mirando el proceso, no revisando documentos en una oficina.

En español conviven «auditorías de proceso por capas», «auditorías por capas», «auditorías de proceso por niveles» y «auditorías escalonadas», pero en el piso de producción casi todo el mundo dice LPA, por Layered Process Audits. El método creció en la cadena de suministro automotriz, donde la AIAG lo formalizó como la guía CQI-8, y existe porque los estándares se degradan en silencio. Se sustituye una herramienta, un ajuste se corre, una verificación se salta un viernes ajetreado, y en una semana el atajo ya es conocimiento tribal. Las auditorías de sistema anuales encuentran esa desviación meses después, cuando ya costó algo. Una LPA la encuentra en días, mientras la corrección es barata y el rastro sigue fresco.

El resultado que importa es el hallazgo. Cada hallazgo es una afirmación concreta y fechada de dónde se separó la realidad del estándar, descubierta por su propia gente antes de convertirse en scrap, en una queja de cliente o en un accidente. Eso es consultoría gratis, y ahí está todo el retorno del programa. El porcentaje de conformidad es un subproducto, y un programa que celebra 98 por ciento de conformidad casi siempre dejó de hacer preguntas capaces de fallar.

Cuándo la auditoría sale contraproducente

Un programa de auditoría puede empeorar una planta, y suele hacerlo de una de tres maneras. No lo lance hasta descartar las tres:

• Todavía no hay nada que auditar. Una auditoría compara la realidad con un estándar; si los estándares no existen, o viven en una carpeta que nadie encuentra desde la línea, primero escriba y publique el estándar. Auditar opiniones produce opiniones.
• La auditoría se usa para calificar personas. En el momento en que un hallazgo afecta el bono de alguien o aparece en su evaluación de desempeño, la honestidad muere: los hallazgos se negocian a la baja, los auditores suavizan sus preguntas y los tableros se ponen de un verde cómodo. El programa conserva su costo y pierde su información.
• Nadie tiene capacidad de reaccionar. Si los hallazgos se acumulan sin decisión, cada auditoría le enseña a la organización que mirar de cerca no cambia nada. Cinco preguntas con un ciclo de reacción que funciona valen más que cuarenta preguntas sin él.

El hilo común: los programas de LPA fracasan socialmente antes de fracasar técnicamente. Casi todo el diseño que sigue es protección para la honestidad.

Cómo se hace una auditoría

Vaya al proceso y diga con claridad qué está haciendo. Las LPA no necesitan ser inspecciones sorpresa: usted audita el proceso, no embosca a la persona, y un estándar que solo se cumple cuando nadie mira es un hallazgo de todas formas. Observe antes de preguntar. Mire el ciclo, revise los ajustes, cuente las piezas, y solo entonces empiece la conversación.

Pida que le muestren, no que le cuenten. «Muéstreme cómo confirma el torque» produce evidencia; «¿confirma usted el torque?» produce tranquilidad. Y cuando algo se desvíe, escriba el hallazgo sin culpar a nadie, porque un estándar incumplido es un dato. O el estándar está equivocado o no se puede cumplir, o la capacitación no aguantó, o la condición se desvió. Los tres son problemas de sistema con soluciones distintas, y ninguno es un veredicto sobre el operador. La pregunta que carga un auditor es qué permitió esto, nunca quién hizo esto.

Dos comportamientos deciden la reputación del programa en el piso de producción. Primero, nunca corrija en silencio y siga de largo: restablecer una condición sin registrar el hallazgo esconde justo la señal que el programa existe para recoger. Segundo, agradezca lo que la gente le muestra. El operador que dice «este indicador se traba, todos le damos dos golpecitos» acaba de entregarle un hallazgo que ninguna lista habría sacado a la luz. Castigue esa honestidad una vez y el programa se queda ciego un año.

Del hallazgo a la acción

Cada hallazgo recibe una decisión en el plazo de una semana, y solo hay tres posibles:

1. 1 Corregir. El estándar es correcto y la condición se desvió: falta una herramienta, hay un ajuste equivocado, una etiqueta gastada. Restablezca la condición, verifíquela y anote si la misma corrección se repite una y otra vez.
2. 2 Capacitar. El estándar es correcto y se puede cumplir, pero la ejecución se desvió. Vuelva a capacitar en el proceso, no en un salón, y haga la pregunta difícil: ¿por qué la desviación fue invisible hasta que la encontró una auditoría?
3. 3 Cambiar el estándar. El estándar está equivocado, obsoleto o no se puede cumplir, y el operador lo estaba compensando. Corrija el documento, no a la persona. En un programa sano esta decisión explica una buena parte del total.

Cada mes se revisa la tendencia de los hallazgos y de sus decisiones en la revisión por la dirección: hallazgos abiertos y cerrados en una semana, hallazgos repetidos en la misma pregunta y cumplimiento de auditorías por capa. Lea el porcentaje de conformidad como una señal de honestidad, no como una meta. Un programa sano se queda cómodamente por debajo del 100 por ciento y produce un flujo constante de hallazgos pequeños y cerrados; que los hallazgos por auditoría caigan hacia cero con las preguntas sin cambiar es una alerta, no una victoria.

Qué pasa después

Un programa en marcha da valor por dos vías. La primera es el ciclo de sostener hallazgo a hallazgo que acabamos de describir. La segunda es el patrón: una pregunta que no deja de producir hallazgos marca un estándar bajo presión sistemática, un estándar de cambio de modelo que nunca sobrevive al turno de noche, una verificación que todas las capas encuentran omitida. Esos patrones son objetivos de mejora con evidencia adjunta, y alimentan la cartera de kaizen con mejor material que cualquier buzón de sugerencias.

Lo que mata a los programas de LPA en papel casi nunca es auditar; es el papeleo. Tres capas, juegos de preguntas que rotan y decenas de hallazgos al mes, cada uno con su responsable, su decisión y su fecha. Ahí es donde TeamGuru sostiene la práctica: el caso de uso de checklists y auditorías programa cada capa, permite contestar las preguntas en teléfono o tablet junto a la línea con evidencia fotográfica en los hallazgos, y entrega cada hallazgo a la gestión de proyectos y acciones como una acción con responsable y fecha, para que la revisión mensual de tendencia lea datos vivos y no una hoja de cálculo recopilada a mano.

En la hoja de ruta, las LPA no terminan; duran lo que duren los estándares que protegen. Son el músculo de auditoría de Estandarizar y escalar, y trabajan junto a la matriz de habilidades, que desarrolla la misma capacidad que las auditorías verifican: gente capaz de operar el proceso según el estándar, y líderes capaces de notar cuándo se está desviando.

Preguntas frecuentes