Cuando tenemos que elaborar un nuevo APPCC y ya disponemos de otro correspondiente a un producto, proceso o instalación similar, utilizarlo como punto de partida parece una decisión lógica. Gran parte del trabajo ya está hecho y, en principio, bastaría con copiarlo y modificar aquello que sea diferente.
Es una práctica perfectamente comprensible: no tendría sentido volver a analizar desde cero peligros, etapas, medidas de control o criterios sobre los que ya hemos trabajado. El problema viene después de hacer la copia, cuando debemos comprobar que todo lo heredado sigue siendo válido y, al mismo tiempo, detectar aquello que debería estar pero nunca formó parte del APPCC utilizado como referencia.
El problema: una copia contiene mucho más de lo que queremos reutilizar
Al duplicar un APPCC no copiamos únicamente aquello que sabemos que nos va a servir. Copiamos todas las decisiones tomadas para el anterior: etapas, materias primas, peligros, medidas de control, límites, prerrequisitos, criterios de evaluación y muchas otras particularidades de aquel producto o proceso.
A partir de ahí debemos decidir qué mantenemos, qué modificamos, qué eliminamos y qué falta. Los cambios evidentes —una nueva etapa, un equipo sustituido o un ingrediente incorporado— suelen ser relativamente fáciles de localizar. El mayor riesgo está en la información heredada que continúa pareciendo correcta y, precisamente por ello, puede escapar a la revisión.
Puede quedar asociado un peligro correspondiente a una materia prima que ya no se utiliza, una medida de control diseñada para otra operación o un límite establecido para un producto diferente. Y puede ocurrir justamente lo contrario: que falte un peligro o una condición relevante porque nunca existió en el APPCC que hemos tomado como modelo.
La dificultad aumenta porque un APPCC no es una suma de tablas independientes. Una materia prima se relaciona con determinados peligros; una etapa incorpora entradas, salidas y peligros; esos peligros se evalúan y, cuando son significativos, conducen a medidas de control. Las etapas, a su vez, se relacionan entre sí para representar el proceso en el diagrama de flujo.
Por eso podemos tener un APPCC perfectamente presentado y, sin embargo, incoherente. El problema no está únicamente en revisar con mayor o menor detalle: cuando gestionamos el APPCC principalmente como un documento, resulta difícil identificar de forma sistemática qué otras partes deben revisarse cada vez que modificamos una de ellas.
El cambio de enfoque: de un documento a un conjunto de piezas relacionadas
Estamos acostumbrados a visualizar el APPCC como el documento final: sus capítulos, tablas, diagramas y anexos. Pero para gestionarlo correctamente resulta más útil pensar en las piezas que lo componen.
Una etapa es una pieza. Un peligro es otra. También lo son una materia prima, una entrada, una salida, un prerrequisito o una medida de control. Y todas pueden guardar relaciones de dependencia entre sí.
Una etapa, por ejemplo, no debería entenderse como un bloque de texto aislado. En ella confluyen determinadas entradas y salidas y, por sus características, pueden resultar aplicables unos peligros concretos. Esos peligros se evalúan y, si resultan significativos, pueden dar lugar a medidas de control. Por tanto, modificar una característica relevante de la etapa puede obligarnos a reconsiderar los peligros asociados; modificar un peligro puede afectar a su evaluación y a las medidas de control que dependen de él. Lo importante no es solo mantener correctamente cada una de esas piezas, sino conocer y controlar las relaciones que hacen que un cambio en una pueda tener consecuencias sobre las demás.
Por tanto, definir bien las piezas no es suficiente. El verdadero valor está en definir también sus relaciones. Visto así, el APPCC deja de ser el lugar donde acumulamos información y pasa a ser la representación de un sistema de elementos relacionados que debemos mantener coherente.
Lo importante no es la herramienta, sino aplicar bien el concepto
Este planteamiento no exige necesariamente una aplicación especializada. Puede construirse con hojas de cálculo estructuradas, listas de SharePoint, una base de datos corporativa u otras herramientas disponibles en la empresa. Lo importante es evitar que el conocimiento quede enterrado y duplicado dentro de documentos independientes.
Podemos mantener maestros para aquellas piezas que queremos gestionar de forma coherente —peligros, etapas, prerrequisitos, materias primas o medidas de control— y registrar después sus relaciones: dónde se utiliza cada elemento y de qué otros elementos depende. A partir de ahí, cada cambio debería permitirnos identificar qué relaciones y qué partes del APPCC necesitan ser revisadas.
Las relaciones permiten convertir los cambios en revisiones concretas
Una sistemática bien diseñada no debería limitarse a decir “si algo cambia, revisar el APPCC”. Debería ayudarnos a determinar qué tenemos que revisar en función de qué ha cambiado.
Algunos ejemplos permiten verlo con claridad:
- Si modificamos en el maestro de un peligro una característica que debe mantenerse coherente, como su gravedad, el cambio no termina en esa ficha. Debemos revisar cómo afecta a la evaluación de ese peligro en todos los APPCC donde aparece, porque su valor de significancia puede cambiar y, con él, las decisiones posteriores sobre su control.
- Si incorporamos un nuevo peligro a una etapa, no basta con añadirlo a una tabla. Debemos evaluarlo y, si resulta significativo, determinar cómo debe controlarse y completar los pasos posteriores que correspondan. Un único cambio puede desencadenar, por tanto, toda una cadena de revisiones.
- Si añadimos o eliminamos una etapa del proceso, debemos revisar los peligros, entradas y salidas afectados. Y si cambia la estructura del proceso o la relación entre sus etapas, debemos comprobar de nuevo que el diagrama de flujo representa correctamente la realidad.
- Un peligro puede identificarse en una etapa y decidirse que será controlado en otra posterior. En ese caso, ambas decisiones deben quedar relacionadas: no podemos considerar resuelto el peligro inicial si después desaparece la etapa o la medida en la que habíamos previsto controlarlo. Esta es precisamente la clase de dependencia que resulta difícil de mantener cuando la información está repartida entre tablas y documentos independientes.
La idea común a todos estos ejemplos es sencilla: no basta con controlar las piezas; debemos controlar también las consecuencias de sus relaciones.
Así, la revisión deja de consistir en releer periódicamente un documento extenso buscando qué puede haber cambiado. Podemos partir de las piezas modificadas e identificar de forma sistemática qué relaciones y qué partes del APPCC necesitan ser revisadas.
Codex establece que el sistema APPCC debe revisarse periódicamente y siempre que exista un cambio significativo que pueda afectar a los peligros o a las medidas de control, por ejemplo, un nuevo proceso, ingrediente, producto o equipo. Pensar el APPCC mediante piezas y relaciones no es una exigencia de Codex, pero sí una forma práctica de hacer esa revisión mucho más sistemática y trazable.
El cambio de lógica es importante: en lugar de copiar un APPCC anterior y buscar después qué debemos quitar o modificar, partimos del proceso real que queremos analizar y aplicamos sobre él el conocimiento que ya tenemos. Seguimos aprovechando el trabajo previo, pero dejamos de permitir que un documento anterior determine por defecto el contenido del nuevo APPCC.
Cómo lo abordamos en Smel Food
Esta forma de entender el APPCC está en el origen del módulo APPCC de Smel Food. Etapas, peligros, entradas, salidas, prerrequisitos, evaluaciones y medidas de control se gestionan como elementos relacionados, de manera que el propio sistema conoce las dependencias existentes entre unas partes y otras.
Donde esta lógica adquiere especial valor es en el mantenimiento. Si añadimos un nuevo peligro a una etapa ya evaluada, Smel vuelve a dejar pendiente la evaluación de peligros. Si ese peligro resulta significativo, quedarán también pendientes los pasos posteriores necesarios para controlarlo. Del mismo modo, añadir o eliminar una etapa o modificar las relaciones del proceso obliga a verificar nuevamente el diagrama de flujo, aunque existiera una verificación anterior todavía vigente. Incluso cambiar en el maestro la gravedad de un peligro actualiza ese criterio en todos los APPCC donde está asignado y puede alterar su significancia. El sistema no se limita a guardar el cambio: identifica qué parte del APPCC ha dejado de estar completa y qué debe revisarse a continuación.
Todo este enfoque puede aplicarse sin Smel, definiendo las piezas, sus relaciones y las reglas de revisión mediante las herramientas de las que disponga la empresa. La diferencia es que esa sistemática tendrá que diseñarse, validarse, mantenerse y ejecutarse internamente. En Smel Food ese modelo ya está construido y probado en el uso real: la empresa no necesita diseñar desde cero cómo relacionar las piezas de su APPCC ni qué debe revisar cuando una de ellas cambia; puede empezar a trabajar directamente sobre una lógica que ya incorpora esas dependencias. La tecnología automatiza el trabajo, pero el principio es exactamente el mismo.
En la práctica, esta forma de trabajar permite mantener una sistemática común de evaluación, reducir revisiones basadas únicamente en la memoria del técnico y conservar mejor la coherencia cuando el APPCC evoluciona.
En definitiva, copiar un APPCC puede ahorrarnos trabajo al principio. El salto realmente importante consiste en dejar de pensar únicamente en documentos y empezar a gestionar las piezas que forman el APPCC, las relaciones entre ellas y las consecuencias que tiene modificar cada una.
Más información de cómo funciona el módulo de APPCC en esta página. Contáctanos sin ningún compromiso.