Ogni progetto di automazione, che si tratti di un impianto grass-root, di un revamping di sistemi esistenti o di semplice automazione a bordo macchina, ha una chiave di successo imprescindibile: la corretta organizzazione, impostazione, gestione e verifica della documentazione di progetto.

Questa chiave può ‘aprire’ la porta ad flusso di lavoro lineare e semplificato che guida il progetto non solo nella fase di design, ma anche in quelle di procurement, construction, commissioning e change control. Le GAMP (Good Automated Manufacturing Practices) sono in tal senso il faro di riferimento non solo laddove abitualmente applicate come in ambito farmaceutico, ma anche in ambiti diversamente regolati come quello petrolchimico. Quando non si scrive in modo sufficientemente preciso ciò che si vuole, non si dice come lo si vuole realizzare, non si identificano ruoli, responsabilità e carichi di lavoro, non si indicano chiari orizzonti temporali e scadenze e non si stabiliscono criteri di verifica di ciò che si è implementato univoci e non interpretabili, si aprono aree di rischio che portano sempre a costi non pianificati e ritardi anche importanti.

Quante volte vi è capitato di dover affrontare un progetto di automazione partendo da specifiche scritte sulla “carta del formaggio” o trasmesse a voce dal classico tecnico molto esperto che è in impianto da anni e conosce tutti i risvolti e i dettagli del processo ma non ha alcuno strumento per renderli condivisi e condivisibili? A noi di Italia Automazione è capitato e quando questo è successo ha sempre significato un impatto netto e quantificabile sulle tempistiche sia di design che di commissioning e startup. Cosa abbiamo imparato da queste esperienze? Una cosa molto semplice: che non si può verificare ciò che non si è ADEGUATAMENTE documentato. Per questo serve un metodo chiaro e consolidato per la gestione del flusso di lavoro che proprio sulla documentazione faccia leva per garantire che il sistema di automazione finale faccia ciò che ci si aspetta e rispetti le performance attese.

Nella panoramica delle metodologie disponibili abbiamo abbracciato da sempre l’approccio fornito dalle GAMP (Good Automated Manufacturing Practices) di ISPE (International Society for Pharmaceutical Engineering) che seppur nate e applicate tipicamente in ambito farmaceutico, forniscono a nostro parere un metodo di gestione del ciclo di vita di un sistema di automazione che è valido per tutti i settori. Nella loro introduzione le GAMP si pongono, infatti, il seguente obbiettivo: “The purpose of this guide is to provide a cost effective framework of good practice to ensure that computerized systems are fit for intended use and compliant with applicable regulations”.

Il ciclo di vita di un nuovo sistema di automazione parte con la stesura della specifica dei requisiti utente (URS), documento fondamentale sviluppato dall’end-user (non dalla società di ingegneria e neppure dal system integrator!) ed orientato alla comprensione chiara e
precisa del prodotto/processo includendo ove possibile indicazione dei CQA (Critical Quality Attributes) o comunque dei parametri di performance attesi. L’estensione ed il dettaglio dei requisiti dovranno essere commisurati ai rischi ed alla complessità del processo e dovranno essere sufficienti per le successive fasi di analisi dei rischi, specifica, configurazione/sviluppo e verifica del sistema.
Sulla base delle URS verrà sviluppato (tipicamente dalla società di ingegneria o direttamente dal system integrator) il documento di Specifica Funzionale (FS) che dovrà definire cosa ci si aspetta che il sistema faccia e quali funzioni devono essere previste. E’ buona pratica far si che le FS traccino in modo chiaro e sistematico i requisiti utente definiti nelle URS e che documentino in modo esplicito tutti i vincoli di design evitando ambiguità, duplicazione di informazioni, contraddizioni. L’utilizzo di naming convention consistenti, la definizione chiara delle interfacce interne ed esterne, l’indicazione dei limiti di configurazione e delle modalità di gestione delle eccezioni, errori, guasti e l’applicazione di modalità descrittive chiare e non interpretabili, aiuteranno il riutilizzo efficace di tale documento nella fase di verifica del sistema.
A questo punto potrà essere sviluppato (tipicamente dal system integrator) il documento di Specifica di Design (DS) che dovrà definire in modo non abiguo, chiaro e preciso come è stato implementato quanto indicato in FS. La DS può essere talvolta suddivisa in due documenti distinti di Specifica di Design Hardware (HDS) e Specifica di Design Software (SDS). Lo scopo di tale documento è quello di dettagliare i componenti Hardware del sistema, definire ad alto livello i moduli che compongono il Software del sistema, definire le interfacce tra i vari moduli e con i sistemi esterni, definire nel dettaglio le operazioni svolte dai singoli moduli software ed indicare le configurazioni di tutti i parametri e settaggi.

I tre pilastri documentali sopra descritti sono alla base di altrettanti step di verifica del sistema e ciascuno di essi costituisce il riferimento da utilizzare per la relativa fase di verifica:

Verifica della Configurazione: meglio indicato in ambito GAMP con il termine Installation Qualification (IQ), questo step di verifica del sistema ha lo scopo di assicurare che il sistema sia configurato ed installato secondo quanto indicato nella Specifica di Design (DS). Come verificare, infatti, le funzionalità di un sistema se non si è prima certi che esso sia stato installato e configurato correttamente secondo quanto previsto nella fase di design?

Verifica Funzionale: meglio indicato in ambito GAMP con il termine Operational Qualification (OQ), questo step di verifica del sistema ha lo scopo di assicurare che il sistema operi secondo quanto indicato nella Specifica Funzionale (FS). Come verificare, infatti, le performance di un sistema se non si è prima certi che esso si comporti secondo quanto specificato?

Verifica dei Requisiti: meglio indicato in ambito GAMP con il termine Performance Qualification (PQ), questo step di verifica del sistema ha lo scopo di assicurare che il sistema rispetti tutte le aspettative dell’end-user indicate nella Specifica dei Requisiti (URS) ed in particolare che garantisca le performance richieste.
Questo meccanismo di corrispondenza tra documentazione di progetto e protocolli di verifica del sistema garantisce da un lato l’affinamento progressivo delle informazioni da requisiti utente fino a dettagli di configurazione e dall’altro la presenza di criteri di accettazione chiari e ben referenziati nella documentazione di progetto per le attività di verifica e test.

Uno strumento ottimale per tracciare le non conformità durante le verifiche ed assicurarsi di non lasciare nulla indietro, sono le cosiddette Punch List. Si tratta tipicamente di un documento operativo utilizzato durante l’esecuzione delle verifiche su cui tracciare la non conformità identificata, l’azione correttiva, l’owner della risoluzione dell’azione correttiva e relativa scadenza. E’ buona norma indicare sempre l’impatto sulla documentazione di progetto, in modo da assicurare un riferimento documentale aggiornato nel momento in cui si vuole chiudere il punto di punch list procedendo a riverifica.

_

Gestire il mantenimento della configurazione del sistema

Una volta completata la fase di verifica e rilasciato il sistema per la produzione, la gestione di eventuali modifiche al sistema stesso può essere affrontata anch’essa secondo metodologia GAMP. Eventuali modifiche richieste al sistema saranno gestite tramite Change Control, verranno analizzate in un Impact Assessment in modo da identificare gli impatti della modifica sul sistema stesso, sulla sua documentazione e sulla necessità di ripetere eventuali verifiche. verranno confrontate con il sistema di Configuration management per essere poi finalizzate in un documento di Specifica di Configurazione.

_

Documentare la gestione del progetto

In parallelo agli strumenti forniti dalle GAMP, ci sono strumenti di documentazione della gestione del progetto stesso che facilitano ulteriormente uno sviluppo lineare del progetto. Ne citiamo solo alcuni che riteniamo fondamentali e per i quali nel caso faremo approfondimenti successivi.