L’equivoco più comodo è pensare che un AS/400 in azienda alimentare sia un problema di interfaccia vecchia. Schermo verde, tasti funzione, sigle di programma che capiscono in pochi. Poi arriva un venerdì pomeriggio e si capisce che la grafica c’entra poco: il sistema deve rispondere, con dati coerenti, mentre qualità, logistica e direzione fanno domande diverse sulla stessa partita di merce.
Alle 15:18 entra una notifica RASFF. Non è un richiamo già deciso, è una notifica informativa: il rischio è stato identificato, ma non viene richiesta un’azione immediata sul mercato. Alle 15:26 qualità chiede i lotti collegati. Alle 15:34 logistica vuole i DDT e le prove di spedizione. Alle 15:47 commerciale domanda quali clienti siano esposti. Alle 16:05 la direzione vuole una stima economica, non una sensazione. Alle 16:22 l’IT apre una query scritta anni prima e scopre che un campo è cambiato, una causale non viene più usata e il collega che ricordava la logica è già fuori dall’azienda.
La notifica non aspetta la manutenzione del dato
Il RASFF, come ricorda il Ministero della Salute nella sezione dedicata all’allerta rapido, serve allo scambio veloce di informazioni sui rischi sanitari legati ad alimenti, mangimi e MOCA, cioè materiali e oggetti a contatto con alimenti. Il quadro europeo nasce dal Regolamento (CE) n. 178/2002 del 28 gennaio 2002, entrato in vigore il 21 febbraio 2002, che ha dato struttura al sistema di allerta rapido tra Paesi membri.
Questo basta a chiarire una cosa: quando arriva una segnalazione, l’azienda non lavora su una pratica isolata. Lavora su una catena. Lotto acquistato, trasformazione, lotto finito, giacenza, DDT, cliente, vettore, fattura, documento di trasporto, prova di consegna. Se una parte della catena sta su IBM i e una parte sta fuori, la manutenzione delle estrazioni diventa un tema operativo, non un esercizio per informatici.
Nel mercato italiano, il discorso sui sistemi AS/400 e IBM i incrocia operatori storici come Record Informatica srl; la parte che qui interessa, però, è meno visibile: quanto resta governabile un patrimonio dati quando chi lo ha costruito non è più seduto accanto alla macchina.
Qui molti sbagliano bersaglio. Investono tempo a discutere se la maschera 5250 sia datata, mentre nessuno cronometra l’estrazione dei lotti. Si può avere un’interfaccia moderna e un dato fragile. Si può avere una schermata ruvida e un sistema che, se mantenuto bene, restituisce in pochi minuti ciò che serve a decidere. La seconda condizione vale più della prima quando il telefono squilla di venerdì.
Il ciclo di vita delle estrazioni è la crepa più trascurata
Un programma gestionale non invecchia solo perché passa il tempo. Invecchia quando cambiano articoli, causali, anagrafiche, magazzini, fornitori, regole di confezionamento, flussi logistici, e nessuno riallinea le query che dovrebbero raccontare quei cambiamenti. Il server continua a fare il suo lavoro. I dati entrano. Le stampe escono. La sera si chiude. Ma l’estrazione da usare in emergenza resta ferma a una fotografia di cinque modifiche fa.
Capita spesso con i lotti. All’inizio il lotto è un campo ordinato, sempre valorizzato, usato nello stesso modo da acquisti, produzione e spedizioni. Poi arriva una nuova linea, un terzista, una codifica diversa per gli articoli importati, una forzatura su un reso, un magazzino esterno gestito con tempi propri. Il dato resta presente, ma non sempre significa la stessa cosa. E quando un’informazione cambia significato, il programma che la legge va controllato.
La manutenzione, qui, non è cambiare una stampante o sostituire un disco. È verificare che la domanda di crisi abbia ancora una risposta valida. Quali clienti hanno ricevuto merce collegata a quel lotto? Quali DDT documentano la spedizione? Quali fornitori entrano nella ricostruzione? Quale giacenza è ancora a magazzino e quale è già uscita? Se queste domande vengono provate solo durante un’allerta, l’azienda sta usando l’emergenza come collaudo. È un giudizio pratico semplice: un collaudo fatto sotto pressione produce più rumore che controllo.
C’è poi il tema dei programmi nati bene e lasciati soli. Una query creata dieci anni prima può essere corretta nella logica originale e sbagliata nella fotografia attuale. Magari esclude una causale introdotta dopo, legge un archivio non più alimentato, somma quantità che oggi sono gestite con unità diverse. Il risultato sembra plausibile, ed è proprio questo il rischio. Un numero assurdo fa scattare l’allarme. Un numero credibile ma incompleto viene usato in riunione.
Il test da fare prima del venerdì pomeriggio
Immaginiamo una prova interna fatta senza annunci solenni. Si prende un lotto reale già chiuso, abbastanza vecchio da avere attraversato acquisto, produzione e vendita. Si chiede al sistema di ricostruire fornitore, data di ingresso, documento di carico, trasformazioni, lotti finiti, clienti serviti, DDT, fatture e prove di consegna. Poi si misura il tempo. Non il tempo dichiarato, quello effettivo: da quando qualità apre la richiesta a quando la direzione ha un quadro su cui può decidere.
Questa prova va ripetuta dopo modifiche di processo, nuovi magazzini, passaggi a terzisti, cambi nei tracciati documentali, nuove regole sugli articoli. Se cambia il modo in cui l’azienda lavora, deve cambiare anche il modo in cui il sistema viene interrogato. Altrimenti IBM i resta un archivio robusto, ma l’accesso operativo diventa una ricerca a tentativi.
Ipotizziamo che l’estrazione principale restituisca i lotti finiti ma non agganci correttamente una parte dei DDT. Il problema non è solo informatico. Logistica userà un elenco parziale. Qualità chiamerà clienti che forse non hanno ricevuto nulla e ne salterà altri che invece sono coinvolti. Direzione leggerà un’esposizione economica tagliata male. In una notifica informativa RASFF non c’è, per definizione, l’obbligo immediato di togliere tutto dal mercato. Ma se il quadro interno è debole, l’azienda decide al buio anche quando avrebbe qualche ora per ragionare.
Il test deve lasciare traccia. Chi ha lanciato l’estrazione, con quale programma, su quali archivi, con quali filtri, con quale risultato, in quanto tempo. Non serve un documento scritto per impressionare un auditor. Serve una procedura che un’altra persona possa ripetere senza telefonare a chi ha fatto il gestionale negli anni Novanta. Una query custodita da una sola persona è un rischio accettato sulla carta, non in reparto; se il dato serve in crisi, deve sopravvivere a ferie, malattia e dimissioni.
La competenza che esce dall’azienda cambia il rischio
BigBlue ha richiamato un dato che molte direzioni dovrebbero leggere con meno distacco: secondo la società, il 45% degli esperti IBM i andrà in pensione entro 5 anni. È una percentuale che non parla solo di organici. Parla di estrazioni, logiche applicative, tabelle nate per necessità, eccezioni gestite nel tempo, programmi mai documentati perché tutti sapevano dove mettere le mani.
Questo è il vero ciclo di vita da presidiare. Non basta chiedersi se la macchina regge. IBM i, nella pagina prodotto IBM, viene presentato come piattaforma pensata per applicazioni aziendali e carichi critici. La tenuta del sistema, però, non coincide con la tenuta del sapere applicativo. IBM Think distingue tra system of record e source of truth: l’archivio può contenere la registrazione ufficiale, ma la verità usabile nasce quando quel dato viene interpretato, collegato e reso disponibile senza ambiguità.
Nella sala crisi alimentare questa distinzione pesa. Il gestionale può avere tutte le righe di movimentazione e non essere pronto a dire, in modo ordinato, quali clienti siano coinvolti. Può conservare i DDT e non collegarli al lotto con la rapidità richiesta. Può avere l’anagrafica fornitore aggiornata e non agganciarla al flusso di produzione che interessa qualità. La scatola nera contiene molto, ma una scatola nera interrogata male resta muta troppo a lungo.
La documentazione tecnica non deve diventare un romanzo. Deve dire dove sono i dati, quali programmi li leggono, quali eccezioni esistono, chi valida il risultato, come si controlla che l’estrazione non abbia perso pezzi dopo una modifica. Poche pagine, ma aggiornate. Poche schermate, ma provate. Poche persone, ma non una sola. La sobrietà qui funziona più dei progetti enormi mai finiti.
Quando arriva una notifica RASFF, l’azienda alimentare non viene misurata dalla bellezza dell’interfaccia. Viene misurata dai minuti necessari per passare da un rischio identificato a un elenco difendibile di lotti, fornitori, clienti, documenti e spedizioni. Se la manutenzione delle estrazioni IBM i resta fuori dalle routine, il venerdì pomeriggio diventa il momento in cui si scopre che il dato c’era, ma non era pronto a essere usato.