La revisión por excepción es un resultado, no un ajuste
La revisión por excepción aparece en casi todo business case de un proyecto de ejecución de manufactura, normalmente como un porcentaje. El tiempo de revisión baja porque los revisores dejan de leer cada línea de cada registro y miran solo lo que el sistema marcó como fuera de lo esperado.
El mecanismo es sólido. Lo que el business case suele omitir es que esto no es un modo que se habilita — es una consecuencia de que el sistema sea lo bastante fiable como para que un regulador, y su propia unidad de calidad, acepten su juicio sobre qué fue normal.
Qué está pidiendo realmente que se crea
Revisar por excepción es una afirmación: todo lo que no se mostró al revisor estaba dentro de su rango esperado, y el sistema lo determinó correctamente. Tres cosas deben sostenerse para que esa afirmación sobreviva al escrutinio.
- Los límites eran correctos. Lo que significa que vinieron de la especificación aprobada, están bajo control de cambios, y su historial es visible — no tecleados en una pantalla de configuración por quien montó la receta.
- Los valores eran reales. Un valor tecleado por un operador ya pasó por una persona antes de que el sistema lo juzgara. El juicio es entonces tan bueno como la transcripción que hay debajo.
- El juicio está evidenciado. La pista de auditoría debe mostrar qué se evaluó, contra qué y cuándo — de lo contrario "el sistema lo verificó" es una afirmación, no un registro.
No está pidiendo al revisor que lea menos. Le está pidiendo que confíe en una clasificación — algo que se gana en el diseño, no se declara en el go-live.
Por qué la transcripción socava más de lo que se cree
El eslabón más débil suele ser el origen del valor en proceso. Si el operador lee un visor y teclea el número, el registro muestra lo que se tecleó, a la hora en que se tecleó, por una persona que además es quien confirma que es correcto. La verificación de segunda persona existe precisamente para compensar eso.
Leer el valor de un historiador de proceso cambia la naturaleza del problema: el registro referencia una medición que ya existe, con la marca de tiempo que emitió el dispositivo y el código de calidad que llevaba el protocolo. Ya no se pide al revisor que confíe en una transcripción — puede seguir el valor hasta el evento bruto.
Es el mismo requisito que imponen la integridad de datos y ALCOA+ por razones completamente distintas, lo cual es una coincidencia útil: la arquitectura que satisface al regulador es la que hace viable la revisión por excepción.
El modo de fallo: excepciones que no significan nada
La otra forma de que esto salga mal es más silenciosa. Límites demasiado ajustados, o configurados sin aportación del proceso, generan marcas en lotes que estaban perfectamente bien. Los revisores aprenden que la mayoría de las excepciones son ruido, empiezan a cerrarlas rápido, y la revisión acaba siendo menos rigurosa que la exhaustiva a la que sustituyó.
Las señales de que esto ocurre aparecen antes de que nadie lo admita:
- la misma excepción se repite en la mayoría de los lotes y siempre se cierra igual
- los comentarios de cierre se copian entre registros
- el tiempo dedicado por excepción cae de forma sostenida mientras el número sigue alto
La corrección no es menos verificaciones — son límites que reflejen la capacidad real del proceso, revisados por control de cambios cuando el proceso enseña algo. Una excepción debería ser lo bastante rara como para que verla cambie lo que el revisor hace después.
Qué resolver antes de prometer la cifra
Si un plan de proyecto ya contiene una reducción de tiempo de revisión, estas son las preguntas que deciden si es alcanzable:
- ¿De dónde viene cada valor en proceso — de un dispositivo o de un teclado?
- ¿Los límites están versionados y son trazables a la especificación de la que salieron, o editables in situ?
- ¿La pista de auditoría puede evidenciar una evaluación concreta en un lote concreto, o solo que hubo un cambio?
- ¿Ha acordado calidad, por escrito, qué le permite omitir al revisor un registro sin excepciones?
Esa última es la más aplazada, y la que atasca el go-live. También pertenece al alcance de validación, y no a una discusión aparte una vez que el sistema ya funciona.
Dónde encaja
La revisión por excepción es una propiedad de un registro electrónico de lote bien diseñado, no un módulo a comprar — nuestra nota sobre qué cambia realmente un EBR cubre el lado de la imposición. Ambos viven dentro de la ejecución de manufactura y de la postura más amplia de cumplimiento digital que hace defendible la clasificación en primer lugar.
