Il paragrafo 8.3 della ISO 9001:2026 - Progettazione e sviluppo di prodotti e servizi

di Stefania Cordiani

Nell'aprile del 1990 lo shuttle Discovery porta in orbita il telescopio spaziale Hubble, uno dei progetti scientifici più ambiziosi e costosi realizzati fino a quel momento. Il suo cuore è uno specchio di due metri e quaranta che la Perkin-Elmer ha impiegato anni a levigare: è una superficie ottica lavorata con una precisione eccezionale. Se lo specchio fosse largo quanto l'Atlantico, la sua imperfezione più grande sarebbe alta pochi centimetri.

Poi arrivano le prime immagini...e sono sfocate.

Non di poco, e non per un problema di messa a fuoco: le stelle, invece di essere punti, sono aloni. Dopo settimane di analisi arriva la diagnosi: aberrazione sferica. Il bordo dello specchio è troppo piatto di circa due micron (un cinquantesimo dello spessore di un capello) ma su un'ottica di quella classe è un abisso. Lo specchio era stato levigato con una precisione straordinaria, ma rispetto a una geometria sbagliata.

La commissione d'inchiesta ricostruisce la sequenza di errori che aveva portato a quel risultato. Per controllare la forma dello specchio durante la lavorazione, la Perkin-Elmer usava uno strumento chiamato correttore nullo riflettente: un banco ottico di precisione che proiettava sullo specchio il "modello" della forma ideale. Quello strumento era stato montato male: una delle sue lenti era fuori posto di 1,3 millimetri, perché durante la taratura il laser di misura si era riflesso non sull'estremità dell'asta metrica di riferimento, ma sul cappuccio usurato che la copriva. Da quel momento, ogni misura confermava che lo specchio era perfetto.

L'aspetto più interessante dal punto di vista della gestione della progettazione emerge però da altri due controlli. Durante la lavorazione, altri due strumenti di controllo indipendenti, un correttore nullo rifrattivo e un correttore inverso, avevano segnalato l'aberrazione. Quelle anomalie vennero attribuite agli strumenti secondari, perché il correttore riflettente era considerato il riferimento più affidabile. E il collaudo finale del telescopio assemblato, quello che avrebbe simulato l'uso reale puntando l'ottica completa su una sorgente, non fu mai eseguito: troppo costoso. Di fatto, il comportamento dell'ottica completa venne verificato nelle condizioni reali soltanto dopo il lancio, quando le prime immagini furono osservate dalla comunità scientifica.

Riesame, verifica e validazione hanno scopi diversi, e la vicenda di Hubble mostra bene che cosa può accadere quando questa distinzione si indebolisce: la verifica si affidava a un riferimento che non venne rimesso in discussione, i risultati discordanti non produssero un riesame sufficientemente approfondito e il comportamento del sistema completo non venne validato prima del lancio. È una vicenda particolarmente utile per leggere il punto 8.3 della ISO 9001:2026, dedicato alla progettazione e sviluppo di prodotti e servizi.

Nota terminologica

Prima di entrare nell'ambito dei requisiti conviene chiarire due aspetti del titolo e del lessico utilizzato.

La prima riguarda la "e" di "progettazione e sviluppo" (design and development). I due termini descrivono attività diverse che la norma riunisce all'interno dello stesso processo. La progettazione traduce i requisiti in caratteristiche del prodotto o del servizio; lo sviluppo porta quelle caratteristiche verso una soluzione concretamente producibile o erogabile. Può accadere che la definizione delle caratteristiche sia molto accurata mentre venga considerata meno attentamente la loro traducibilità nei processi produttivi o di erogazione. Considerarli nello stesso processo significa quindi verificare anche che ciò che è stato progettato possa essere effettivamente realizzato o erogato.

La seconda osservazione riguarda una modifica terminologica presente anche in altre parti della bozza: in linea con la nuova struttura armonizzata, la formula "mantenere informazioni documentate" viene sostituita da "essere disponibile come informazione documentata". La formulazione sposta l'attenzione sulla disponibilità dell'informazione documentata nel momento in cui deve essere utilizzata, più che sull'atto formale della sua conservazione.

Lo scheletro che non cambia

L'architettura in sei sotto-punti introdotta nel 2015 rimane sostanzialmente invariata anche nella ISO 9001:2026.

Un processo di progettazione già costruito correttamente sui requisiti della ISO 9001:2015 non richiede quindi una revisione strutturale: fasi, controlli e informazioni documentate richieste restano quelli. Le due nuove note introducono però un chiarimento significativo: il processo reale di progettazione può essere iterativo e gli input possono evolversi nel corso del lavoro. Per capire la portata di questo chiarimento conviene prima seguire la sequenza logica del punto 8.3: pianificazione, input e controlli.

La pianificazione: il progetto del progetto

L'8.3.2 chiede di determinare, prima di cominciare: le fasi del processo, i riesami, le verifiche e le validazioni appropriate per ciascuna fase, le responsabilità e le autorità coinvolte, le risorse interne ed esterne necessarie, le esigenze di controllo delle interfacce tra le persone che partecipano, l'eventuale coinvolgimento di clienti e utilizzatori, le informazioni documentate necessarie a dimostrare che i requisiti sono stati soddisfatti.

Tra gli elementi dell'elenco merita particolare attenzione il controllo delle interfacce. Nel 1975 Fred Brooks, dopo l'esperienza maturata nei grandi progetti software di IBM, pubblicò The Mythical Man-Month, diventato un classico del project management. La sua legge più famosa dice:

Aggiungere persone a un progetto in ritardo lo rende ancora più in ritardo.

Fred Brooks, The Mythical Man-Month, 1975

Una parte del problema riguarda l'aumento delle interfacce di comunicazione che accompagna la crescita del gruppo di progetto. Ogni nuova interfaccia aumenta le occasioni in cui requisiti, modifiche o ipotesi di lavoro possono essere interpretati o trasferiti in modo diverso. Ecco perché il punto 8.3.2 mette il controllo delle interfacce tra le cose da pianificare prima: perché la struttura delle relazioni tra le persone può incidere sulla qualità del progetto tanto quanto alcuni aspetti strettamente tecnici.

Una buona pianificazione della progettazione dovrebbe permettere di rispondere con chiarezza ad almeno cinque domande:

1. Quali fasi?
2. Chi decide cosa, a ogni fase?
3. Quali controlli, e di che tipo, a ogni passaggio?
4. Chi deve parlare con chi e attraverso quale canale?
5. Cosa deve restare documentato?

Gli input e gli output: la ricetta e il piatto chiarito

L'8.3.3 elenca cosa deve entrare nella progettazione: i requisiti funzionali e prestazionali, le informazioni provenienti da progettazioni simili, i requisiti cogenti, le norme e i codici di pratica che l'organizzazione si è impegnata ad applicare, le conseguenze potenziali di un guasto legate alla natura del prodotto o del servizio. Il punto 8.3.5 definisce, invece, le caratteristiche richieste agli output della progettazione: output che soddisfino gli input, adeguati ai processi successivi di fornitura, con i riferimenti ai criteri di accettazione e con la specifica delle caratteristiche essenziali per un uso sicuro e appropriato.

Il ragionamento può essere accostato a una distinzione molto più antica. Nel De architectura, Vitruvio indicava tre qualità fondamentali dell'opera architettonica:

Si deve tener conto della solidità, dell'utilità e della bellezza.

Vitruvio, De architectura, I secolo a.C.

Firmitas, utilitas, venustas. Il parallelo non va preso alla lettera, ma è interessante: la firmitas richiama prestazioni e sicurezza, l'utilitas l'adeguatezza all'uso, mentre la venustas introduce una dimensione legata alla percezione e all'esperienza dell'utilizzatore. Il linguaggio e gli strumenti sono cambiati radicalmente, ma alcune domande fondamentali della progettazione restano riconoscibili. Il parallelo può essere esteso anche all'adeguatezza ai processi successivi: una soluzione progettuale deve poter essere tradotta nelle attività necessarie per realizzarla.

La nuova nota dell'8.3.3 chiarisce inoltre un aspetto importante: all'inizio del processo gli input possono non essere ancora completamente definiti. Alcuni requisiti sono disponibili fin dall'inizio, mentre altri possono precisarsi o emergere durante le successive iterazioni. La versione della norma del 2015 non esplicitava questa possibilità; la nuova nota riconosce invece che gli input possono evolversi attraverso cicli successivi e questo rende il requisito più aderente al funzionamento reale di molti processi di progettazione.

I tre controlli: riesame, verifica, validazione

Il punto 8.3.4 distingue i tre principali controlli della progettazione: riesame, verifica e validazione. La norma chiede tre controlli con tre scopi diversi e, nella pratica, la distinzione tra queste tre attività non è sempre altrettanto netta.

Il riesame valuta l'avanzamento: il progetto sta procedendo come pianificato? I risultati intermedi sono in grado di soddisfare i requisiti? Serve a valutare l'andamento del progetto e a decidere se proseguire, correggere o rivedere quanto pianificato.

La verifica confronta gli output con gli input: quello che abbiamo prodotto risponde a quello che avevamo chiesto? È il confronto tra ciò che la progettazione ha prodotto e i requisiti utilizzati come input.

La validazione, infine, confronta il risultato con l'uso previsto: il prodotto o il servizio, nelle condizioni reali o rappresentative di impiego, fa quello per cui è nato? È il controllo che mette il risultato della progettazione alla prova rispetto all'uso previsto e alle condizioni nelle quali dovrà effettivamente funzionare.

Con questa distinzione possiamo rileggere la vicenda dello specchio di Hubble. La verifica c'era, ed era persino ossessiva: ogni misura confermava la conformità degli output allo strumento di riferimento. Ma nessuno aveva verificato lo strumento: il correttore nullo era diventato un input non riesaminato, un metro di giudizio fuori discussione. Il riesame c'era, formalmente: ma davanti a due collaudi indipendenti in disaccordo con il principale, invece di trattare il conflitto come un'informazione da indagare, lo si archiviò con la spiegazione più comoda (si attribuì maggiore affidabilità allo strumento ritenuto più preciso, senza approfondire sufficientemente la causa della discordanza). Il test dell'ottica completa in condizioni rappresentative d'uso non venne invece effettuato prima del lancio; il problema diventò evidente soltanto osservando le prime immagini provenienti dallo spazio.

La validazione serve proprio a questo: verificare che il risultato soddisfi l'uso previsto nelle condizioni reali o rappresentative nelle quali dovrà funzionare.

Il cambiamento vero: la progettazione diventa un ciclo chiarito

Le due nuove note dell'8.3.1 e dell'8.3.3 possono essere lette insieme perché descrivono due aspetti dello stesso processo iterativo. La prima riconosce che il processo di progettazione può includere cicli di feedback, verifica e validazione flessibili; la seconda riconosce che gli input possono essere incompleti all'inizio ed evolversi durante il progresso attraverso cicli ripetuti. In termini operativi, la progettazione può quindi procedere attraverso iterazioni successive nelle quali si progetta, si prova, si acquisiscono nuove informazioni e si aggiornano le soluzioni.

Le nuove note, tuttavia, non riducono gli obblighi relativi a riesami, verifiche, validazioni e gestione delle modifiche. L'ingegnere e storico della tecnica Henry Petroski lo sintetizzò con questa osservazione:

Ogni singolo calcolo che un ingegnere fa è un calcolo di fallimento.

Henry Petroski, To Engineer Is Human, 1985

Progettare, per Petroski, è per sua natura anticipare i modi in cui le cose possono non funzionare: ogni iterazione può essere utilizzata per mettere alla prova ipotesi, individuare criticità e raccogliere informazioni prima che le conseguenze di un errore diventino più difficili da gestire. La differenza sta quindi nella capacità di trasformare ogni iterazione in apprendimento documentato e utilizzabile nelle fasi successive: nel ciclo, ogni giro produce un apprendimento registrato (gli input vengono aggiornati, le nuove informazioni vengono riesaminate e le eventuali modifiche vengono gestite secondo il punto 8.3.6). In un processo iterativo i controlli devono accompagnare le diverse iterazioni, anziché essere concentrati soltanto nelle fasi finali. La possibilità di modificare gli input durante il processo richiede quindi che le variazioni siano comunque identificate, riesaminate e documentate quando necessario.

Da dove viene tutto questo: la ISO 9004:2018 e i future concepts

Il confronto con la ISO 9004:2018 e con i future concepts aiuta a leggere alcune evoluzioni dell'8.3, soprattutto sul piano della flessibilità del processo, dell'innovazione e dell'attenzione a sostenibilità, etica ed esperienza del cliente. Questi temi compaiono nella nuova revisione soprattutto attraverso note e chiarimenti dell'allegato A, senza modificare in modo sostanziale l'architettura dei requisiti del punto.

Un primo collegamento riguarda customer experience ed etica. La ISO 9004:2018 suggerisce di andare oltre i bisogni espressi per anticipare le aspettative; la nuova ISO 9001 lo recepisce nell'allegato A.8.3, specificando che la progettazione non riguarda solo caratteristiche fisiche ma anche sostenibilità, etica ed esperienza del cliente. Il collegamento tra i due punti è concreto: i requisiti determinati e riesaminati nell'8.2 diventano input che la progettazione deve tradurre in caratteristiche e soluzioni. Un secondo collegamento riguarda la gestione della conoscenza. I future concepts sul knowledge management sottolineano come evitare di ripetere errori già commessi; il recepimento passa dal rafforzamento del punto 7.1.6, che alimenta gli input di progettazione dell'8.3.3 b) con le lezioni apprese dai progetti precedenti, creando un collegamento tra l'apprendimento maturato nei progetti precedenti e gli input utilizzati nei progetti successivi. Un terzo tema è l'innovazione. La ISO 9004 le dedica ampio spazio come leva del successo durevole; la bozza non crea un requisito separato, ma chiarisce nell'allegato A che la progettazione può essere finalizzata a soluzioni innovative, richiedendo in tal caso controlli più approfonditi. Nei progetti caratterizzati da maggiore incertezza può quindi essere necessario intensificare o adattare i controlli nel corso dello sviluppo.

A questi si aggiunge l'integrazione con la sostenibilità: la ISO 9001:2026, influenzata dalle raccomandazioni della ISO 9004 sulle risorse naturali, chiede di considerare il cambiamento climatico e la sostenibilità come fattori di contesto del punto 4.1 che influenzano direttamente i requisiti della progettazione.

In sintesi, la nuova revisione rende più esplicita la possibilità di gestire la progettazione in modo iterativo, con requisiti che possono evolvere, feedback successivi e controlli distribuiti lungo il processo.

Come si verifica, in pratica

Possiamo tradurre questi elementi in quattro verifiche operative.

Test dei tre verbi. Sull'ultimo progetto concluso, individuate le evidenze del riesame, della verifica e della validazione e controllate che corrispondano effettivamente a tre scopi differenti. Se un'unica attività viene presentata contemporaneamente come riesame, verifica e validazione, vale la pena controllare se i tre obiettivi previsti dal requisito siano stati realmente coperti.

Test dello strumento. Individuate gli strumenti, i software, i modelli o i riferimenti utilizzati per verificare gli output e chiedete su quali basi ne considerate affidabili i risultati. Il banco di prova è tarato? Il foglio di calcolo che tutti usano da anni è mai stato validato? Il software di simulazione, la specifica di riferimento, il campione master: anche il riferimento utilizzato per verificare un risultato deve avere un livello di affidabilità adeguato allo scopo per cui viene impiegato.

Test del disaccordo. Cercate nell'ultimo progetto un risultato di prova o un dato di controllo in contrasto con le altre evidenze e ricostruite come è stato gestito. Poi guardate come è stato chiuso: è stato indagato fino ad arrivare alla causa?

Test della validazione. Prendete l'ultima validazione registrata e verificate se le condizioni utilizzate erano realmente rappresentative dell'uso previsto. Poi guardate i reclami dei primi mesi di vita dei vostri ultimi prodotti o servizi e chiedetevi quanti riguardino condizioni d'uso che avrebbero potuto essere esplorate durante la validazione.

Lo stesso ragionamento può essere applicato anche al sistema di gestione. Un esercizio interessante consiste nel considerare il sistema di gestione stesso come un oggetto di progettazione. Procedure, moduli, indicatori e flussi di approvazione hanno utenti, requisiti funzionali e conseguenze quando non funzionano come previsto; possono quindi essere analizzati con alcune delle stesse domande utilizzate nella progettazione. Chi ha raccolto gli input da chi li usa davvero? Chi ha verificato che il modulo risponda ai requisiti, e chi lo ha validato nelle condizioni reali? Provate allora a chiedervi quante procedure siano perfettamente conformi al formato previsto ma poco adatte alle condizioni reali nelle quali devono essere utilizzate. Un altro segnale interessante sono le soluzioni parallele create dagli utilizzatori per compensare ciò che lo strumento ufficiale non permette di fare con facilità. Applicare questa logica anche agli strumenti del sistema di gestione significa chiedersi se siano stati progettati a partire dalle esigenze di chi li utilizza, verificati rispetto ai requisiti e soprattutto validati nelle condizioni reali di lavoro. Se questa validazione non avviene prima, saranno gli utilizzatori a farla nella pratica quotidiana, quando correggere gli errori sarà inevitabilmente più difficile.

Tutti gli articoli sulla ISO 9001