En producción, una no conformidad es un problema. En I+D, es información. La diferencia es importante y explica por qué los sistemas de calidad pensados para planta funcionan mal en el laboratorio: están diseñados para que las desviaciones sean excepcionales, y en desarrollo son la norma.
Aun así, hay que registrarlas. Por un motivo muy concreto: para no volver a hacerlo.
Los tres tipos que hay que distinguir
Fallo de ensayo. La emulsión se cortó, el pH derivó, el sabor no funcionó. Es el resultado esperable de experimentar. No es una no conformidad en sentido formal, pero es la información más valiosa del laboratorio y hay que guardarla pegada a la revisión que la produjo.
Incidencia de ejecución. Se pesó mal, se olvidó un ingrediente, se calentó de más, se contaminó una muestra. Aquí no aprendimos nada de la fórmula: perdimos un lote por un fallo de proceso. Hay que registrarla para no contaminar los datos de coste y para detectar patrones (si se pesa mal a menudo, hay un problema de método o de balanza, no de personas).
No conformidad real. Algo que afecta a un producto que sale al mercado, a un compromiso con un cliente o a un requisito regulatorio. Esta sí entra en el sistema de calidad formal, con acción correctiva y seguimiento.
Mezclar los tres es el error clásico. Si tratas cada emulsión cortada como una no conformidad formal con análisis de causa raíz e informe, en tres semanas nadie registra nada.
Qué apuntar en cada caso
Para un fallo de ensayo, cuatro campos y treinta segundos:
| Campo | Ejemplo |
|---|---|
| Qué pasó | Separación de fases a las 48 h a temperatura ambiente |
| En qué revisión | Rev. 11 |
| Hipótesis | Emulsionante insuficiente para la carga de aceite (28 %) |
| Qué hacemos | Rev. 12 con 3,5 % de emulsionante y homogeneización a 4.000 rpm |
Y si tienes una foto, la foto. Una imagen de la separación vale más que un párrafo.
Para una incidencia de ejecución, lo mismo más el impacto en coste: si el lote se perdió, esas materias primas y esas horas se gastaron. Deben aparecer en el proyecto, aunque marcadas como incidencia para que no ensucien la media de estimado contra real.
El valor está en la consulta agregada
Un registro individual sirve poco. La rentabilidad aparece cuando puedes preguntar:
- ¿Cuántos lotes hemos perdido este año y por qué?
- ¿Qué tipo de fallo se repite más?
- ¿Qué proyectos consumen más ensayos fallidos?
- ¿Hemos tenido antes este problema de cristalización?
Esa última pregunta es la que justifica todo el sistema. Un técnico nuevo que se enfrenta a una separación de fases y encuentra que en 2024 el mismo problema se resolvió cambiando el orden de adición se acaba de ahorrar tres semanas.
Es la misma idea que en el cuaderno de laboratorio: el conocimiento que no es consultable no es conocimiento de la empresa.
Cómo evitar que se convierta en un tribunal
Este es el punto delicado. Un registro de fallos puede degenerar en un historial de errores por persona, y en el momento en que alguien lo percibe así, los registros se vuelven vagos, tardíos o inexistentes.
Cuatro medidas concretas:
- Sin nombres en el campo de causa. «Se añadió el conservante antes de enfriar» y no «Juan añadió el conservante antes de enfriar». El sistema ya guarda quién registró; no hace falta señalar en el texto.
- Registrar es obligatorio; explicar no. Un fallo sin hipótesis registrado hoy vale más que uno perfectamente analizado que nunca se escribe.
- Revisión periódica en grupo. Una vez al mes, media hora, los fallos del mes. En clave de aprendizaje. El que registra un fallo interesante hace un favor al equipo.
- Distinguir el error del riesgo asumido. Si se decidió saltarse un ensayo para llegar a una fecha y salió mal, la causa no es del laboratorio: es de la decisión. Y eso también se registra, en la checklist con su excepción.
Del fallo de laboratorio a la reclamación de cliente
Hay un caso especial que merece atención: la reclamación de un producto que ya está en el mercado. Ahí el registro de desarrollo se convierte en la herramienta de investigación.
El flujo, cuando el sistema está bien montado:
- Reclamación → identificar el lote.
- Lote → qué revisión de fórmula se usó y qué se consumió realmente.
- Revisión → qué cambió respecto a la anterior y por qué.
- Historial → ¿tuvimos este problema en desarrollo? ¿En qué condiciones?
- Conclusión y acción.
Los cinco pasos en media hora si el sistema existe. En dos días si hay que reconstruirlo. Y en «no lo sabemos» si el desarrollo se hizo en Excel y cuadernos, que es la respuesta que ningún cliente acepta.
Un apunte final
El indicador de un buen sistema de registro no es que haya pocos fallos. Es que haya muchos fallos registrados y pocos repetidos. Un laboratorio que reporta cero incidencias de ensayo no es un laboratorio excelente: es uno que no registra.