Convalida WMS in GDP: Data Integrity e Audit Trail per RP

Convalida WMS in GDP: Data Integrity e Audit Trail (cosa chiede davvero l’ispettore)

Se in ispezione ti chiedono: “Chi ha modificato la scadenza di questo lotto e perché?”, non stanno testando il magazziniere. Stanno testando il tuo sistema.

E qui arriva il punto: oggi, in GDP, la compliance non si gioca solo su celle frigo e DDT, ma su record elettronici, audit trail e governance IT.

In 30 secondi

  • Un WMS “GDP-compliant” non è quello che funziona: è quello che dimostra cosa è successo, chi lo ha fatto e quando.
  • La CSV (Computer System Validation) in logistica fallisce quasi sempre su: URS deboli, test superficiali, accessi troppo larghi, audit trail mai revisionato.
  • Il mito pericoloso: “Stampiamo un PDF e siamo a posto” (spoiler: no).

Il lessico che trovi nei rilievi (LSI “da ispettore”)

Nel perimetro GDP digitale, preparati a sentire (e a dover dimostrare): CSV, URS, matrice di tracciabilità, IQ/OQ/PQ, GAMP 5, EU Annex 11, 21 CFR Part 11, ALCOA+, audit trail review, RBAC (role-based access control), segregation of duties, change impact assessment, backup/restore test, disaster recovery.

Quali dati del WMS sono davvero “GDP-critical”

In audit, la domanda implicita è sempre: “Se questo dato fosse errato o manipolato, potrei perdere tracciabilità o rilasciare prodotto non idoneo?”.

Tabella: dati critici e controlli attesi

Dato/oggetto nel WMS/ERP

Rischio GDP se errato

Controllo atteso “audit-proof”

Lotto / batch

recall incompleto, tracciabilità rotta

Audit trail attivo, report one-step-back/forward, controlli in ingresso

Scadenza

FEFO falsato, spedizione di scaduti

Blocco logico, audit trail su modifica, workflow autorizzativo

Status stock (quarantena/rilasciato/bloccato)

rilascio improprio

Quarantena elettronica, autorizzazioni segregate, log eventi

Quantità movimentate

mismatch inventario, furti interni non rilevati

riconciliazioni, exception report, controlli su adjustment

Timestamp operazioni

ricostruzione eventi non affidabile

time sync (NTP), timezone governance, controlli su clock drift

Interfacce (portale ordini, serializzazione, TMS)

perdita/alterazione dati

interface validation, controlli di completezza, gestione errori

Dalla prospettiva della produzione, il WMS è spesso visto come “fuori dal perimetro GMP”. In audit GDP, invece, diventa un sistema qualità: se non è governato, l’RP resta senza “prova oggettiva”.

CSV in GDP: come farla senza “papier-mâché validation”

In fase di audit, il problema che riscontro più spesso è questo: aziende con un bel “Validation Report” ma senza logica di rischio, senza tracciabilità requisiti→test, e con test che non coprono i veri failure mode.

Un approccio pratico (che regge in ispezione)

  1. Scoping GxP & Risk Assessment
    • Identifica funzioni GxP-impact (es. blocco scadenze, quarantena, tracciabilità, serial integration).
    • Classifica il sistema secondo logiche tipo GAMP 5 (configurato? custom? SaaS?).
  2. URS robuste (non “il sistema deve funzionare”)
    • Esempio URS utile: “Il sistema deve impedire la spedizione di lotti con expiry < data spedizione e registrare l’evento in audit trail.”
  3. Matrice di tracciabilità
    • Ogni URS deve finire in test case. Se manca il link, in audit è un buco.
  4. Testing IQ/OQ/PQ (con casi “sporchi”)
    • IQ: installazione/ambiente
    • OQ: funzioni e controlli (ruoli, blocchi, audit trail, timestamp)
    • PQ: processi reali (ricevimento→stoccaggio→picking→spedizione→rework)
  5. Data migration & master data governance
    • Se importi anagrafiche/prodotti/scadenze: serve evidenza che non hai “sporcato” i dati.
    • Qui nascono incidenti tipo: unità di misura interpretata male (box vs pack) → spedizioni errate.
  6. Go-live con “quality gate”
    • Non è IT che decide: il go-live deve avere un gate qualità con evidenze minime chiuse.

Da ricordare

Un WMS non è “validato” perché il vendor dice che lo è.
È validato quando tu dimostri che la configurazione e l’uso nel tuo processo GDP sono sotto controllo.

Audit trail: abilitarlo non basta (serve la review)

Contrarian insight (mito comune): “L’audit trail lo attiviamo così, se serve, lo guardiamo.”
È una pratica obsoleta perché:

  • trasforma l’audit trail in strumento reattivo, non di controllo
  • lascia aperta la porta a data integrity drift (errori ripetuti o comportamenti opportunistici)

Che cosa significa “audit trail review” in pratica

  • Definisci campi critici (expiry, lotto, status, adjustment quantità, override blocchi).
  • Definisci frequenza risk-based (mensile su campioni, trimestrale su trend, ad-hoc su eventi).
  • Cerca pattern tipici:
    • modifiche ripetute sulle scadenze
    • cancellazioni/override anomali
    • attività “fuori orario” non giustificate
    • uso eccessivo di profili admin

In fase di audit, la domanda killer è: “Mi mostri l’evidenza che l’audit trail viene revisionato prima che un problema diventi un recall?”

Accessi, ruoli e segregazione: qui cascano anche i bravi

In fase di audit, il problema che riscontro più spesso è l’account condiviso sui palmari (“MAGAZZINO1”) o profili troppo potenti “per comodità”.

Contromisure che funzionano davvero

  • RBAC: ruoli minimi necessari (picking ≠ master data ≠ release/quarantena).
  • Joiner–Mover–Leaver: flusso per creare/modificare/disattivare accessi.
  • User access review periodica (almeno annuale, meglio se semestrale su ruoli critici).
  • MFA dove possibile, soprattutto su accessi remoti e ruoli admin.
  • Segregation of duties: chi crea/aggiorna master data non dovrebbe approvare eccezioni.

Patch e upgrade: quando l’IT “migliora” e la GDP peggiora

Aggiornare un sistema è normale. Farlo senza controllo è un rischio GDP.

Checklist pratica:

  • ogni patch/upgrade passa da change impact assessment
  • esiste ambiente TEST separato
  • fai regression test sui processi GDP-critici
  • documenti esito e rilascio
  • se SaaS: qualifica fornitore + evidenza di release notes e valutazione impatto

Dalla prospettiva della produzione, un change software è spesso “routine IT”.
Dalla prospettiva GDP, può essere l’origine di:

  • blocchi scadenza non più funzionanti
  • audit trail degradato
  • report di tracciabilità non riproducibili

Box “Da ricordare” (takeaway)

  • CSV GDP = processo + evidenze, non un PDF in cartella condivisa.
  • Audit trail = attivo + protetto + revisionato.
  • I 3 killer in audit: accessi, mancanza review, change IT non governati.
  • Se perdi data integrity, perdi anche la capacità di recall efficace.

FAQ 

Serve la 21 CFR Part 11 in un’azienda EU?
Non sempre come obbligo diretto, ma i concetti (audit trail, firme elettroniche, controlli accesso) sono spesso richiesti come best practice quando gestisci record elettronici GxP.

Quali sistemi devo validare per GDP?
Tutti quelli che impattano tracciabilità, stock status, scadenze, temperatura, serializzazione e reporting di recall: tipicamente WMS/ERP, sistemi di monitoraggio T, eventuali moduli di serializzazione e interfacce ordini.

Ogni quanto fare audit trail review?
Approccio migliore: risk-based (mensile su campioni per campi critici, più spesso se hai molte eccezioni).

Torna al blog

Cerchi qualcosa di specifico?