“Qualità, hai visto la notifica?”. “Sì, lotto 24L, etichetta sospetta, venerdì alle 17:42. Dimmi solo una cosa: da quale versione è uscita quella stampa?”. La conversazione, nelle aziende alimentari, parte spesso così: poche parole, telefoni già caldi, magazzino che chiede se bloccare le spedizioni e commerciale che vuole sapere quali clienti sono stati serviti.
Il Ministero della Salute chiarisce che, se un alimento oggetto di notifica RASFF è ancora sul mercato, l’operatore deve attivare misure di ritiro e richiamo. Fin qui la procedura è nota. La parte meno comoda arriva subito dopo: ricostruire a ritroso il dato. Lotto, distinta base, ricetta, tabella allergeni, template etichetta, spool di stampa, archivio versioni. Sembra una catena ordinata. In fabbrica, sotto pressione, diventa un cold case informatico con timer acceso.
Il lotto misura quanto in fretta si risale al dato giusto
La prima misura non è il numero di etichette stampate. È il tempo necessario per passare dal lotto fisico alla sua fotografia gestionale. Su IBM i, in molte aziende food, il lotto vive dentro procedure stabili, spesso robuste, ma stratificate: produzione, magazzino, controllo qualità, spedizioni. Ognuno vede un pezzo. Quando arriva una segnalazione, serve la sequenza intera.
La domanda tecnica da chiudere in poche ore è semplice solo sulla carta: quale anagrafica articolo era valida quando quel lotto è stato prodotto? Non quella aggiornata il lunedì dopo. Non quella corretta al volo da un operatore per mandare avanti un ordine. Quella effettiva, agganciata alla produzione reale.
Se il sistema conserva solo lo stato corrente, l’indagine parte già zoppa. Il codice lotto può riportare data, linea, turno, stabilimento, ma senza un legame pulito con la versione dell’articolo resta un indizio parziale. In un richiamo, “probabilmente” è una parola che crea lavoro inutile: blocchi più prodotto del necessario, chiami clienti non coinvolti, perdi ore a confrontare stampe cartacee con videate aggiornate.
Situazione ricorrente: un lotto è stato confezionato prima di una modifica anagrafica sugli ingredienti, ma la ricerca fatta il venerdì sera mostra solo il dato aggiornato. Il reparto qualità crede di vedere la verità, invece sta guardando una versione successiva. Da lì partono telefonate, verbali e rettifiche. Tutto evitabile se il lotto porta con sé l’identificativo della versione articolo usata in produzione.
Distinta base e ricetta devono dire quale formula era in macchina
Dopo il lotto viene la ricetta. Nel food non è una riga decorativa del gestionale: è il punto in cui materie prime, semilavorati, rese e sostituzioni autorizzate diventano prodotto vendibile. Se la ricetta cambia, cambia anche ciò che l’etichetta deve dichiarare. E se la distinta base non conserva la storia, il sistema racconta una mezza verità.
La misura da tenere sotto controllo è il disallineamento tra ricetta approvata e ricetta usata. Può nascere da una modifica tecnica non chiusa, da una sostituzione ingrediente gestita fuori flusso, da una codifica duplicata, da un semilavorato che eredita allergeni non aggiornati. Sono errori poco spettacolari. Però sono quelli che, quando arriva un controllo, obbligano a scavare nei turni, nelle bolle di carico e nelle note di produzione.
La domanda tecnica è questa: per il lotto contestato, quale versione di distinta base era rilasciata, chi l’ha rilasciata e da quale data era utilizzabile? La risposta deve stare nel sistema, non nella casella di posta di un capo reparto. Una mail può aiutare a capire, ma non può diventare l’archivio ufficiale di una formula alimentare.
Caso tipico: un ingrediente viene sostituito con un equivalente tecnologico, il codice interno cambia, il reparto acquisti registra il nuovo fornitore, ma la ricetta resta agganciata al vecchio semilavorato per due cicli produttivi. Nessuno se ne accorge subito perché il prodotto esce, il peso torna, la linea non si ferma. Il problema emerge quando l’etichetta deve spiegare cosa c’era davvero dentro.
Qui una regola pratica regge bene: ogni modifica di ricetta che può influire su ingredienti, allergeni o dichiarazioni deve generare una nuova versione chiusa, non una correzione muta sul record esistente. La correzione muta fa risparmiare tre minuti a video e consegna al controllo qualità una caccia manuale tra schermate, stampe e appunti di turno.
Allergeni e indicazioni obbligatorie non sopportano tabelle senza storia
Il Regolamento (UE) n. 1169/2011 del Parlamento europeo e del Consiglio del 25 ottobre 2011 disciplina le informazioni sugli alimenti ai consumatori e, all’art. 9, elenca le indicazioni obbligatorie che devono comparire in etichetta. Il MIMIT, nelle pagine dedicate all’etichettatura alimentare, richiama lo stesso terreno operativo: informare correttamente chi acquista e mettere gli operatori nelle condizioni di dichiarare ciò che vendono.
Dentro un ERP su IBM i, questo significa una cosa molto concreta: la tabella allergeni non può essere trattata come una nota libera. Deve avere regole, validazioni, date di efficacia, collegamenti con materie prime e semilavorati. Se un allergene entra da una materia prima, passa alla ricetta e poi al template etichetta, ogni salto deve essere tracciato.
Le allerte alimentari citano spesso irregolarità microbiologiche come Salmonella, E. coli e Listeria monocytogenes. Sono casi diversi dagli errori di etichetta, ma insegnano una lezione comune: quando scatta l’allerta, la catena del dato deve reggere. Per gli allergeni, il cedimento tipico non è il batterio nel campione, è la mancata coerenza tra tabella, formula e stampa.
La domanda tecnica da porre al sistema è netta: da quale fonte anagrafica l’etichetta ha preso l’allergene dichiarato o non dichiarato? Se la risposta è “lo ha scritto l’ufficio grafico”, il processo è fragile. L’ufficio grafico può impaginare, ma non deve inventare il contenuto regolatorio. Se invece il testo nasce da campi controllati, con versioni e autorizzazioni, l’errore resta possibile, ma diventa circoscrivibile.
Situazione ricorrente: la materia prima contiene un allergene, la scheda fornitore viene aggiornata, ma il campo interno resta vuoto perché l’aggiornamento è stato caricato come allegato PDF e non come dato strutturato. L’etichetta successiva sembra corretta, graficamente pulita, ma non pesca l’informazione nuova. Il venerdì alle 17:42 nessuno ha voglia di aprire venti allegati per capire quale sia quello valido.
Template etichetta e spool: la stampa deve provare da dove nasce
Arrivati al template, molti pensano alla grafica: logo, font, spazi, codici a barre, tabella nutrizionale. In emergenza, però, la grafica è quasi l’ultima preoccupazione. Conta sapere quale template è stato usato, quale spool è stato generato, chi ha autorizzato la versione e se il PDF archiviato corrisponde alla stampa mandata in linea.
Il controllo serio parte dai file e dai tracciati: nel fascicolo operativo che contiene specifiche di coda, manuali interni, tracciati dei template, https://www.recordinformatica.it/it/software-gestione-stampe-iseries-as400.htm, campioni PDF e regole di invio, il responsabile deve ritrovare lo stesso identificativo di versione che compare sul lotto. Se quell’identificativo manca, si torna alla ricostruzione manuale. E la ricostruzione manuale, quando i telefoni squillano, diventa lenta e nervosa.
Su AS/400 e IBM i lo spool è spesso visto come un passaggio tecnico, roba da sistemisti o da chi segue le stampe. In realtà è una prova di processo. Dice quale programma ha prodotto il documento, quando, con quali parametri, verso quale coda e, se il flusso è stato progettato bene, verso quale template. La domanda tecnica è: posso ristampare oggi l’etichetta esatta di quel lotto, senza usare dati aggiornati dopo?
Questa prova va fatta prima dell’emergenza. Non dopo. Una ristampa conforme deve recuperare dati e template della data di produzione, non comporre una bella etichetta con l’anagrafica attuale. Se il sistema ripesca campi vivi, la ristampa è una replica solo in apparenza. Può essere comoda per l’archivio interno, ma non aiuta a dimostrare cosa è uscito dalla linea.
Caso tipico: il template viene corretto per aggiungere una frase obbligatoria, ma il nome del file resta identico. Lo spool del lotto precedente mostra lo stesso nome template del lotto successivo. A video sembrano parenti stretti; in verifica sono due oggetti diversi. Senza un codice versione, una data di rilascio e un blocco sulle modifiche non autorizzate, la differenza resta affidata a chi ricorda la modifica. E le persone, sotto pressione, ricordano a pezzi.
Archivio versioni: la checklist che evita una caccia al tesoro
L’ultimo tratto della ricostruzione è l’archivio versioni. Non serve un museo digitale pieno di copie inutili. Serve una catena minima, completa, interrogabile. Il dato deve raccontare quando è nato, chi lo ha cambiato, perché è stato cambiato e quali lotti ha toccato. Se manca uno di questi passaggi, la gestione del richiamo diventa più larga del necessario.
La checklist per un sistema IBM i nel food dovrebbe stare in poche righe, ma va provata davvero, non firmata una volta all’anno:
- Versionamento delle etichette: ogni template deve avere codice versione, stato, data di rilascio e data di fine uso.
- Blocco delle modifiche non autorizzate: ingredienti, allergeni e testi regolatori non devono cambiare senza profilo abilitato e traccia dell’intervento.
- Storico allergeni: la tabella deve conservare le versioni legate a materie prime, semilavorati e ricette, con date di efficacia.
- Collegamento lotto-template: ogni lotto confezionato deve sapere quale modello etichetta e quale versione dati sono stati usati.
- Prova di ristampa conforme: il sistema deve generare la stessa etichetta del lotto originario, usando archivio storico e non campi correnti.
Questi controlli non eliminano gli errori. Li rendono più piccoli, più rapidi da isolare, meno costosi da gestire. Una contaminazione microbiologica, una segnalazione su allergeni o un dubbio sul testo in etichetta richiedono decisioni veloci; ma una decisione veloce non nasce dal fiuto, nasce da dati che si lasciano interrogare senza litigare con il sistema.
Il venerdì alle 17:42 non è il momento per scoprire che il template vecchio è stato sovrascritto, che la ricetta non ha storico o che lo spool è stato cancellato perché “tanto c’è il PDF”. Il PDF serve, ma da solo non racconta la catena. Il lotto racconta il prodotto, la ricetta racconta la formula, la tabella allergeni racconta il rischio dichiarativo, lo spool racconta la stampa, l’archivio versioni racconta la prova. Se domani arrivasse una notifica su un vostro lotto ancora in distribuzione, quale evidenza riuscireste a produrre nelle prime due ore?