«Muéstrame cómo lo verificas» — la pregunta que rompe la mayoría de los sistemas de calidad
Hay una pregunta que hacen los auditores que suena inofensiva y no lo es.
No es ¿tienen un procedimiento? — todo el mundo tiene un procedimiento. No es ¿está aprobado? — claro que está aprobado, tiene número de revisión y una firma. La pregunta que de verdad hace daño es más callada que eso:
"Muéstrame cómo verificas que las actividades de calidad requeridas efectivamente se ejecutaron, se revisaron y se cerraron."
He visto a equipos capaces entrar a esa pregunta con absoluta confianza y salir por el otro lado con una no conformidad. No porque no estuvieran haciendo el trabajo. Porque lo estaban haciendo de una manera que solo tenía sentido para quienes lo hacían.
Si quieres saber si tu propio sistema sobreviviría, sigue leyendo. Aunque sospecho que ya sabes la respuesta, y esa incomodidad leve que sientes es el artículo funcionando.
El hallazgo más común no es el que imaginas
Pídele a un gestor de proyectos que adivine su peor hallazgo de auditoría y normalmente buscará algo ausente. Un procedimiento que falta. Una calibración vencida. Un documento sin control.
En mi experiencia, el hallazgo más común en organizaciones basadas en proyectos no es ninguno de esos. Es este: la organización no puede demostrar de forma consistente que sus actividades de calidad estuvieron controladas y verificadas.
Fíjate en lo que dice eso. No dice "las actividades de calidad no estaban ocurriendo". Sí ocurrían. Se hicieron inspecciones. Se revisaron entregas. Se detectaron defectos y se levantaron. Hubo reuniones, se tomaron fotos, salieron comentarios, y gente que sabía lo que hacía lo hizo con competencia.
El hallazgo es más estrecho y más incómodo: nadie fuera del proyecto puede probar nada de eso con los registros.
La Cláusula 8.5.1 de ISO 9001:2015 exige el control de la producción y la prestación del servicio — incluyendo la implementación de actividades de seguimiento y medición en las etapas apropiadas para verificar que se cumplen los criterios. La obligación no es hacer la verificación. Es controlarla. Y un control que no puede evidenciarse no es control. Es costumbre.
Qué está haciendo realmente el auditor
Entiende la mecánica y el hallazgo deja de ser un misterio.
Un buen auditor no ataca el procedimiento. El procedimiento normalmente está bien — se escribió con cuidado, probablemente por alguien sénior, y dice cosas sensatas. Atacarlo es desperdiciar la mañana de todos.
En vez de eso escoge un proyecto, escoge un requisito, y sigue el hilo. No preguntando ¿esto existe?, sino ¿puedo llegar de un extremo al otro sin que tú me ayudes?:
- ¿Cuál era el requisito de calidad aplicable?
- ¿Qué inspección o revisión se hizo contra él?
- ¿Cuál fue el resultado?
- ¿Contra qué criterios de aceptación se juzgó ese resultado?
- ¿Quién lo aceptó, y estaba autorizado para hacerlo?
- Si se encontró algo, ¿qué acción se requirió, de quién, para cuándo?
- ¿Se verificó el cierre — y por alguien distinto de quien hizo el trabajo?
- ¿Algo de esto fue visible para la dirección mientras seguía abierto?
Ocho eslabones. El auditor no está evaluando si tu gente es buena. Está evaluando si la cadena aguanta sin la gente.
Y aquí está la parte que vale la pena sostener un momento: un auditor es, por definición, un extraño sin contexto. No estuvo en la reunión. No sabe que Miguel siempre revisa el acero antes del vaciado, ni que la razón de que no haya registro de la tercera inspección es que se fusionó con la segunda cuando cambió la secuencia. Tiene los documentos y nada más.
Así que la auditoría no evalúa realmente tu calidad. Evalúa si tu calidad sobrevive al contacto con alguien que no se sabe ya la respuesta.
La mayoría de los sistemas no pasa esa prueba, y sus dueños se llevan una sorpresa sincera.
Una ilustración
Auditoría de seguimiento. El equipo está tranquilo, y con razón. La calidad es un área donde se consideran fuertes. Hay planes de calidad. Hay registros de inspección. Hay informes de proyecto que mencionan temas de calidad, y hay fotos — muchísimas fotos.
El auditor escoge dos proyectos y empieza a tirar del hilo.
Encuentra un informe que dice que se revisó una entrega y se emitieron comentarios. Bien. Pide ver los comentarios. Están en un correo. Perfecto — pregunta qué pasó con ellos. Alguien explica que el contratista respondió y se resolvió. Pide ver la resolución. Hay un correo posterior, de otra cadena, donde el tema se menciona de pasada como cerrado.
Pregunta: cerrado por quién, contra qué criterios, y verificado por quién.
La sala se queda callada — no porque la respuesta sea mala, sino porque todos en ella saben la respuesta y ninguno puede señalar dónde está escrita. El ingeniero de obra explica lo que pasó. Es completamente creíble. Recuerda el detalle. También está, en ese preciso momento, funcionando como el eslabón faltante de una cadena de control documentada, que es exactamente el problema.
El auditor intenta con un segundo proyecto. Misma forma: trabajo real, competencia real, resultados reales — y un rastro que solo se sostiene si ya te sabes la historia.
No conformidad menor, Cláusula 8.5.1. No por calidad ausente. Por calidad que no pudo demostrarse como controlada.
Por qué el equipo no lo vio venir
Esta es la parte que me parece más interesante, y es la razón de que este hallazgo se repita en organizaciones que, bajo cualquier medida razonable, son buenas en lo que hacen.
El equipo no estaba ciego. Estaba compensando.
La gente con experiencia carga el sistema en la cabeza. Sabe qué inspecciones importan y cuáles son ceremonia. Sabe que el PIE dice una cosa pero la secuencia cambió en la semana seis. Sabe que el pendiente de marzo se cerró porque estaba ahí parado cuando se cerró. Conecta las piezas automáticamente, y como la conexión ocurre en su cabeza, no nota que nunca ocurrió en papel.
Desde dentro, el proceso parece funcionar. Y funciona. Justo hasta que quitas a la gente.
Lo que lleva a algo que vale la pena decir sin rodeos:
El personal competente y experimentado es lo que mejor esconde los defectos de un sistema de gestión de la calidad.
Y es también, por eso mismo, la razón de que el defecto sea peligroso. Un sistema débil con gente débil falla temprano, de forma visible y barata. Un sistema débil con gente fuerte falla tarde — cuando alguien se va, cuando un proyecto crece, cuando dos personas clave están en otra obra a la vez, o cuando por fin sale algo mal y buscas un registro que nunca se creó.
Todos pasaron por al lado del hueco durante años porque el hueco estaba lleno de gente.
La causa aparente, y la real
Saca el reporte de no conformidad de un hallazgo así y la causa declarada será alguna versión de: los registros no se completaron o archivaron de forma consistente.
Es cierto. También es casi inútil, porque apunta la acción correctiva a la cosa equivocada — un recordatorio, una charla de cinco minutos, un correo severo sobre disciplina de archivo. Seis meses después vuelve el mismo hallazgo y nadie entiende nada.
La causa raíz real es estructural, y es esta:
El proceso se diseñó alrededor de ejecutar actividades técnicas, no alrededor de demostrar el ciclo de control.
Lee el procedimiento de cualquier organización que reciba este hallazgo y lo verás. El documento es rico en qué hacer — inspecciona esto, revisa aquello, verifica lo otro. Es delgado hasta el silencio sobre cómo la ejecución de ese trabajo se vuelve visible, asignable, trazable y cerrable por alguien que no estuvo ahí.
Debajo hay un supuesto no dicho, y es el que de verdad hizo el daño: que la gente competente mantendrá el control de forma natural. No lo hará. No por descuido — porque mantener un rastro demostrable es una tarea distinta de hacer bien el trabajo, y nadie se lo pidió nunca, ni lo dotó de recursos, ni lo hizo inevitable.
Así que el cumplimiento acaba descansando en la práctica individual y no en el proceso organizacional. Que es otra forma de decir que no es un sistema. Es un conjunto de costumbres que dan la casualidad de ser buenas.
Qué lo arregla de verdad
No más formatos. Los formatos son lo primero a lo que todo el mundo echa mano y no tocan la causa raíz.
Lo que funciona es hacer que el ciclo de control sea inevitable en vez de opcional:
Define el mínimo. Cada proyecto lleva un contenido mínimo de calidad definido — no al criterio del PM sobre qué necesita esta obra en particular. El criterio es por donde entra la variación.
Haz el plan específico del proyecto. Un plan de calidad genérico clonado entre proyectos es un documento que nadie lee, porque no habla de su proyecto. Los planes de calidad y los PIE específicos del proyecto sí se leen, porque son relevantes.
Estructura el seguimiento. Inspecciones, no conformidades y acciones correctivas en un registro con responsable y fecha límite — no en correos, no en minutas, no en la memoria de alguien. Si vive en una bandeja de entrada, no está siendo seguido.
Asigna la verificación del cierre a una persona. Explícitamente. Y ojalá no a quien hizo el trabajo. Un "cerrado" sin verificador es una afirmación, no un control.
Enruta la calidad hacia el reporte y la revisión por la dirección. Si los pendientes de calidad nunca suben por encima del nivel de proyecto, la dirección no tiene visibilidad, y la Cláusula 9.3 también tiene un hueco. Dejar algo abierto debería resultar incómodo.
Controla la evidencia. El control de documentos no es teatro burocrático. Es la diferencia entre tener un registro y poder encontrarlo dieciocho meses después, cuando importa.
Audita la implementación, no la existencia. Esta es la que más programas de auditoría interna hacen mal. Verificar que existe un procedimiento y un formato no es auditar. Es inventariar. Audita el rastro — escoge un proyecto, escoge un requisito, camina los ocho eslabones, y mira dónde se rompe. Hazte a ti mismo lo que el auditor externo te va a hacer.
El hilo que conecta todo
Si has leído lo que he escrito sobre notificaciones FIDIC y registros contemporáneos, quizá notes que este es el mismo argumento con otra ropa.
Una reclamación de retraso muere porque los registros que la habrían probado nunca se crearon — no porque el derecho no fuera real, sino porque nadie sabía, un martes cualquiera de marzo, que ese martes iba a importar.
Un sistema de calidad falla una auditoría porque el rastro que habría demostrado el control nunca se construyó — no porque el control no estuviera ocurriendo, sino porque nadie sabía, en su momento, que alguien tendría que reconstruirlo.
El mismo fallo. El registro que necesitas el día malo hay que crearlo el día normal, por alguien que no tiene ni idea de que el día malo viene en camino.
Esa es toda la disciplina, sinceramente. Lo demás es detalle.
Una prueba que puedes hacer esta semana
Escoge un proyecto. Escoge un requisito de calidad — cualquiera. Ahora entrégaselo a alguien sin ninguna participación en ese proyecto y pídele que reconstruya, solo con evidencia objetiva y sin hacerle a nadie una sola pregunta, qué se requería, qué se verificó, contra qué criterios, por quién, qué se encontró, qué se hizo al respecto, quién confirmó el cierre, y si la dirección llegó a verlo.
Si puede, tu sistema es real.
Si necesita preguntarle a alguien — y va a necesitarlo — entonces lo que tienes no es un sistema de gestión de la calidad. Es un grupo de buena gente, y un documento que describe lo que estarían haciendo si tuvieran tiempo.
El hallazgo de auditoría será menor. Lo que te dice, no.
Matriz de riesgos
Puntuación 5×5, mapa de calor en vivo, y la columna que casi ninguna matriz tiene.
Descargar gratis
