Generalità

(4.4.1) Il fornitore deve predisporre e mantenere attive le procedure documentate relative al controllo e alla verifica della progettazione del prodotto per assicurare il soddisfacimento dei requisiti specificati.

Significato della norma

La Norma prevede di programmare, nell'ambito della realizzazione del progetto di un nuovo prodotto o di importanti modifiche su un prodotto già esistente, verifiche atte a ottimizzare gli aspetti del prodotto che riguardano:

• qualità
  
• affidabilità
  
• costo
  

Nel considerare il controllo della progettazione è importante notare che la si può applicare a vari aspetti dell'attività in modi e tempi differenti. Essi sono relativi ai prodotti, compresi servizi e software, come pure alla progettazione del processo produttivo.
Gli aspetti essenziali della qualità, quali la sicurezza, le prestazioni e la affidabilità di un prodotto, sono definiti durante la fase di progettazione e sviluppo. Di conseguenza, una progettazione carente può essere causa fondamentale di problemi di qualità.

Pianificazione della progrettazione e sviluppo

(4.4.2) Il fornitore deve elaborare piani per ciascuna delle attività di progettazione e sviluppo. Tali piani devono descrivere o richiamare e definire dette attività. Le attività di progettazione e sviluppo devono essere assegnate a personale adeguatamente qualificato e dotato di mezzi idonei. I piani devono essere aggiornati man mano che evolve la progettazione.

Significato della norma

Questa sezione della normativa sottolinea l'importanza per il fornitore di stabilire delle procedure per la pianificazione della progettazione e sviluppo. Tramite queste procedure si deve cioè arrivare alla stesura di un piano di lavoro che stabilisca gli obiettivi di base, le responsabilità, le priorità, la data di evasione e tutti gli altri eventuali aspetti ritenuti importanti per la progettazione. La pianificazione dovrebbe, per esempio, portare l'ente o gli enti preposti alla stesura di un documento, in cui si può richiedere la verifica della completezza delle informazioni, affinché il progetto assolva l'obiettivo proposto, affrontare uno studio di massima del progetto, prevedere verifiche e sperimentazioni, assegnare le responsabilità, stabilire preventivamente i tempi di realizzazione per ogni attività coinvolta.
La norma specifica inoltre che questa attività di pianificazione può essere di volta in volta aggiornata per eventuali aggiunte o modifiche alle attività precedentemente stabilite (per esempio, durante lo sviluppo del progetto, l'ente preposto alla pianificazione potrebbe decidere di definire ulteriori attività di verifica non presenti nel documento iniziale).

Vediamo come potrebbe essere gestito il percorso di pianificazione e sviluppo della progettazione in conformità alla norma in una generica azienda di meccanica.
La richiesta di progetto per un nuovo prodotto viene generalmente attivata dalla direzione commerciale previo accordo con la direzione generale dell'azienda. La richiesta di progetto compilata in un apposito modulo dovrà essere, generalmente, inoltrata alla direzione tecnica, corredata di tutti i documenti che la direzione commerciale riterrà opportuno allegare per meglio focalizzare l'obiettivo proposto. La direzione tecnica provvederà, in base alla richiesta pervenuta, a riunirsi con la direzione commerciale, annotando su appositi moduli le indicazioni per raggiungere lo scopo fissato e la priorità degli interventi, il responsabile per la realizzazione del progetto, un tempo preventivo ed eventuali prove sperimentali o F.M.E.A. di progetto. In fase di sviluppo del progetto, il responsabile del progetto provvederà ad eseguire tutte le operazioni di calcolo e analisi, eseguire paralleli con le soluzioni progettuali già da tempo sperimentate in modo da trarre indicazioni utili per il progetto, definire le specifiche di progetto mediante l'emissione di un disegno complessivo corredato dallo schema di calcolo adottato con i valori calcolati, definire la classe del prodotto, eseguire a seconda della classe del prodotto piani di affidabilità e manutenibilità che, come già detto, avrebbero potuto essere già programmati in fase di pianificazione.

Cosa deve fare un software

Un software dovrebbe supportare la fase di pianificazione delle attività di progettazione e sviluppo attraverso una serie di moduli operativi che realizzino la suddetta documentazione. Questo tipo di gestione informatizzata della progettazione dovrebbe garantire un accesso immediato alle informazioni necessarie per stabilire il piano di lavoro. L'efficienza di questa operazione è molto elevata se il gruppo di lavoro impegnato nella pianificazione dispone delle informazioni aggiornate all'ultima modifica, senza quindi doverne attendere la registrazione, lasciando degli aspetti della pianificazione in sospeso. La registrazione delle decisioni intraprese dovrebbe essere effettuata rapidamente. La caratteristica peculiare di questi moduli è permettere di inserire le specificazioni relative alle richieste di intervento il più flessibilmente possibile, dato che da azienda ad azienda varia il modo di affrontare la pianificazione. Ad esempio, diversi possono essere gli obiettivi prefissati e i modi in cui vengono descritte le attività coinvolte. Pertanto, tramite la taratura di determinati parametri, il programma dovrebbe permettere di effettuare una documentazione standardizzata, ma sempre facilmente modificabile, per soddisfare le procedure di pianificazione della progettazione di una qualsiasi realtà aziendale.

Cosa fa il Q9000

Il Q9000 supporta la pianificazione della progettazione attraverso alcuni moduli operativi di carattere generale che, come vedremo, saranno utilizzati anche in altre fasi della gestione aziendale. L'obiettivo è fornire un supporto alla pianificazione, non solo dal punto di vista della trasmissione delle informazioni, ma anche della loro completezza. Infatti, tramite l'utilizzo dei campi a immissione obbligatoria (una delle caratteristiche generali del pacchetto) le informazioni di base per la pianificazione non vengono tralasciate.
Vediamo ora, analizzando alcuni moduli, come il Q9000 riesca a raggiungere questi obiettivi.
Esiste un modulo di immissione delle richieste di intervento, che permette di registrare una richiesta di progettazione originata da qualsiasi ente o componente interno o esterno all'azienda. Data la generalità del modulo, in prima istanza si deve specificare il tipo di intervento, nel nostro caso RDPR (Richiesta di progetto), che può essere selezionato collegandosi a una tabella generale in cui sono già stati inseriti da Sme.up alcuni tipi di intervento principali e facilmente modificabili.
Il secondo passo consiste nella scelta, anche questa tabellata, del tipo di griglia. In base alla selezione, nella seconda videata ci saranno tre campi, il cui significato e la cui obbligatorietà di immissione possono essere decisi dall'utente.
Negli esempi seguenti si evidenziano in grassetto questi aspetti del programma.

Fig. 1. Immissione della richiesta di un nuovo progetto da parte della direzione commerciale.

Questa schermata mostra che l'utente che avanza la richiesta di progetto, selezionando il tipo di griglia, sceglie il contenuto dei tre campi evidenziati nella schermata successiva.
La grande potenzialità del sistema è la possibilità di individuare i campi e renderli o meno di immissione obbligatoria, semplicemente andando in manutenzione tabelle per effettuare le scelte (vedere appendice sulle tabelle).
Un'azienda può quindi definire il proprio percorso personalizzato, che aiuta a realizzare la pianificazione secondo quanto previsto dalle relative procedure. Per esempio, se si desidera il tipo griglia RDL (richiesta di lavoro) caratterizzato dai campi "tipo di lavoro", "work-centre" e "parametro", di cui i primi due di immissione obbligatoria, si obbliga chi esegue la richiesta di progetto a rispettare queste richieste di specifica.
Si noti che per la scelta del responsabile dell'evasione, mettendo nell'apposito campo il carattere "/", il programma visualizza le persone con il profilo del tipo richiesto.
La fase successiva nella pianificazione della progettazione, in cui l'ente destinatario della richiesta stende le linee di base del lavoro, è supportata dal Q9000 tramite il modulo di gestione delle richieste di intervento, che permette la registrazione di tutte le decisioni intraprese: si possono specificare la richiesta collegata, il responsabile dell'evasione, i rapporti di prova, le ore a consuntivo, ecc...
I campi "obiettivo", "soluzione proposta", "note", "soluzione adottata", "esito soluzione adottata" ed "effetto soluzione adottata" dipendono dal tipo di richiesta (se è una sperimentazione RDSP, i campi saranno "specifica", "obiettivo", "rapporti di prova", "risultato debugger", "esito soluzione adottata" e "sentenza finale").
Gli altri campi non sono invece modificabili dall'utente, in quanto standard in ogni azienda. I campi "ente richiedente", "ente designato", "lista di distribuzione", "ore a preventivo", "costo a preventivo", "tipo di intervento" e "data effettiva evasione" sono di immissione obbligatoria perché fanno parte della documentazione minima richiesta dalla normativa.
Tutte queste osservazioni si possono notare nelle figure 2, 3, 4, 5, 6.
I campi evidenziati si riferiscono alle decisioni che, come anticipato, sono in funzione del tipo di richiesta (RDPR, RDSP,...).
Il Q9000 è strutturato in modo da ricollegarsi, dal campo richiesta, al modulo di immissione degli interventi e sceglierne uno che automaticamente riporti la problematica e il documento di origine della richiesta. Questi due campi, ad esempio, non possono essere modificati perché le informazioni, parte integrante della documentazione del progetto, non devono essere persi.

La figura 3 illustra la modalità di richiesta di sperimentazione in fase di pianificazione e la figura 4 la modalità di gestione dell'intervento.
L'ente designato gestirà la richiesta come illustrato nella figura 5.

Fig. 2. Descrizione e attribuzione ai responsabili della richiesta di progetto.

Fig. 3. Pianificazione delle attività di progettazione.

Fig. 4. Immissione della richiesta di sperimentazione legata al progetto.

Fig. 5. Analisi e pianificazione della richiesta di sperimentazione.

Fig. 6. Risultati della sperimentazione richiesta.

Con un pacchetto informatico di questo tipo si possono costruire le tabelle in modo da rendere le persone coinvolte nella progettazione abbiano a disposizione uno strumento che permetta la registrazione di qualsiasi attività intrapresa, per collegare tra loro tutte le attività inerenti al progetto.
Per l'ampiezza dell'argomento, un paragrafo a sè è dedicato all'assegnazione delle responsabilità.

Assegnazione delle attività

Significato della norma

Il fornitore è tenuto ad assegnare al personale designato la responsabilità di dirigere progettazioni specifiche e altre attività di progettazione in modo chiaro. Per queste funzioni il personale dovrebbe essere qualificato adeguatamente e avere accesso alle informazioni e alle risorse necessarie per completare il lavoro. Le attività di progettazione dovrebbero essere specificate con l'essenziale dettaglio per permettere lo sviluppo corretto del progetto e la soddisfazione dei requisiti da parte della progettazione.

Cosa deve fare un software

Un software dovrebbe supportare l'assegnazione delle responsabilità, rendendo disponibili all'ente competente (ad esempio la direzione tecnica) gli elementi su cui basare le scelte del responsabile delle attività di progettazione. Queste devoni basarsi sulle funzioni operative e sul background della persona addetta, affinché sia qualificata per lo svolgimento del lavoro richiesto. Devono quindi essere disponibili la più ampia documentazione sul profilo di ogni soggetto e le informazioni sulla posizione occupata e su tutte le attività svolte per l'azienda fino a quel momento.
Inoltre, un software deve rendere disponibili tutta la documentazione e ogni specificazione dettagliata dei requisiti di progetto ai responsabili della progettazione. Il responsabile deve conoscere in ogni momento tutto quanto richiesto, emesso, modificato in merito e deve avere la possibilità di essere informato su quanto accade nel modo più diretto possibile. Un sistema software di supporto a questa attività deve garantire un chiaro e istantaneo sistema di interrogazione e aggiornamento del flusso di informazioni, in modo che il responsabile abbia una visione d'assieme dell'avanzamento del progetto in tempo reale e possa verificare la conformità delle attività svolte con i requisiti richiesti.

Cosa fa il Q9000

Il Q9000 gestisce l'insieme della documentazione relativa ai profili di posizione del dipendente attraverso un opportuno modulo, assegnando al dipendente la valutazione dei profili di competenza e definendo le azioni da intraprendere e i corsi sostenuti. Permette, per ciascun dipendente, di evidenziare i costi, il trattamento economico, le valutazioni e la pianificazione dello sviluppo e dell'avanzamento della posizione.
Una spiegazione dettagliata su questo modulo é comunque rimandata nella sezione che riguarda l'addestramento del personale.
Il pacchetto assicura alle persone preposte all'assegnamento delle responsabilità la visione completa, rapida e chiara di tutte le competenze, attraverso la semplice interrogazione del modulo, che è costantemente aggiornato. La specificazione del responsabile viene inserita nel Q9000 all'atto della gestione della richiesta di progetto (RDPR) e la scelta viene effettuata considerando le funzioni operative e il background della persona, affinché quest'ultima abbia la qualifica per svolgere il lavoro richiesto come imposto dalla norma.
Infatti, inserendo il carattere "/", il programma mostra soltanto le persone con il tipo di profilo richiesto; esiste cioè una tabella collegata al campo "Responsabile evasione", contenente il campo "profilo", per mezzo del quale si tiene conto dei punteggi nel modulo sulla gestione del personale.
È riportato di seguito (Fig. 7) un esempio di RDPR in cui si evidenzia il campo in cui inserire il codice anagrafico del responsabile della gestione del progetto (la Direzione tecnica); il modulo consente inoltre di inserire una serie di informazioni che completano la documentazione sui tempi e modi in cui deve essere evaso il progetto.

Fig. 7. Attribuzione dei responsabili del progetto.

L'assegnazione delle responsabilità per le azioni necessarie allo sviluppo del progetto (es.: richieste di sperimentazione, azioni correttive, ecc...) è gestita nello stesso modo. Per una richiesta di sperimentazione, tale assegnazione avviene nella medesima modalità, specificando il codice anagrafico del responsabile nell'apposito campo. Si noti che i codici anagrafici sono consultabili collegandosi direttamente all'anagrafica dei dipendenti, tramite le regole esposte nell'introduzione; la gestione è affidata ad un sistema di tabelle. Il vantaggio di questa gestione software consiste principalmente nell'assicurare in tempo reale la rintracciabilità di tutte le competenze e il conseguente reperimento di ogni attività semplicemente, collegandosi con il relativo modulo di gestione. Ad esempio, interrogando la sezione riguardante le richieste di sperimentazione e selezionando quella desiderata (per la ricerca come sempre sono disponibili i "limiti"), è possibile conoscere immediatamente il responsabile designato.

Interfacce organizzative e tecniche

(4.4.3) Le interfacce organizzative e tecniche tra gruppi diversi coinvolti nel processo di progettazione devono essere definite e le necessarie informazioni devono essere documentate, trasmesse e sistematicamente riesaminate.

Significato della norma

Quando i dati e i requisiti di base della progettazione giungono da fonti diversificate, devono essere chiaramente definite, documentate, coordinate e tenute sotto controllo le relazioni e le interfacce. Molte funzioni organizzative possono contribuire al processo di progettazione. Tra queste possono essere incluse:

• ricerca e sviluppo;
  
• ricerca e studio di mercato;
  
• assicurazione della qualità e conduzione aziendale della qualità;
  
• ingegneria;
  
• tecnologia dei materiali;
  
• addetti alla comunicazione;
  
• sistema informativo.
  

L'insieme di queste funzioni deve risultare perfettamente integrato e i vari gruppi di progettazione, sia interni che esterni al fornitore, devono interagire in modo efficace; questo può essere realizzato previa chiara e sistematica definizione di:

• informazioni da ricevere e trasmettere;
  
• identificazione dei gruppi trasmittenti e riceventi;
  
• scopo della trasmissione delle informazioni;
  
• identificazione dei sistemi di trasmissione;
  
• registrazioni da conservare circa la trasmissione dei documenti.
  

Cosa deve fare un software

La gestione delle informazioni tramite un sistema software deve consentire a ogni operatore, una volta definito l'organigramma delle interfacce funzionali interessate nel progetto (in base alle opportune competenze), di reperire e fornire la documentazione richiesta in modo semplice e immediato. Il software deve permettere di conoscere tutte le specifiche riguardo le informazioni inviate (gli enti trasmittenti e i destinatari, lo scopo della trasmissione, ecc...). Ad ogni documentazione e richiesta di intervento deve quindi essere associato questo tipo di specificazione, in modo che l'ente interessato sappia da chi è stata inoltrata, quando e lo scopo della trasmissione; il tutto deve rimanere registrato e conservato nella "storia" del progetto, permettendo di ricostruire, quando richiesto, il percorso delle attività svolte.

Cosa fa il Q9000

Una delle caratteristiche peculiari del pacchetto consiste nella possibilità di accedere direttamente, da parte degli utenti collegati al sistema, a tutte le informazioni necessarie alla propria attività. In questo modo, ciascuno ha la possibilità di interrogare le emissioni delle funzioni con cui la richiesta è relazionata ed esaminare sistematicamente e in tempo reale l'evoluzione dello stato del progetto. L'efficienza del pacchetto consiste soprattutto nell'estrema semplicità i collegamenti interfunzionali sono realizzati. All'attivazione di una trasmissione di dati con inoltro, ad esempio, di una richiesta di intervento, devono essere specificati l'ente trasmittente e l'ente destinatario. Tale informazione viene indissolubilmente associata alla documentazione inserita nel sistema, in modo che l'ente destinatario possa consultare il modulo dedicato alla gestione delle richieste che lo riguardano per potersi collegare direttamente con quella emessa. Un dettagliato menù d'ingresso permette di selezionare, mediante i filtri di ricerca, le sole istanze di interesse dell'operatore tra tutte le informazioni. L'esempio (Fig. 8) illustra tutte le richieste rivolte a un determinato ente / responsabile che compaiono automaticamente alla consultazione del modulo.

Fig. 8. Visualizzazione delle richieste di intevento indirizzate a un ente.
La documentazione relativa al progetto viene di volta in volta aggiornata e resa disponibile "run time". Questo sistema supporta in modo efficiente l'interfaccia organizzativa e tecnica tra i singoli gruppi coinvolti nella progettazione.

Dati e requisiti di base della progettazione

(4.4.4) I dati su cui basare la progettazione del prodotto, compresi quelli di leggi e regolamenti, devono essere identificati, documentati e riesaminati dal fornitore per assicurarne l'adeguatezza. I requisiti della progettazione devono tenere conto dei risultati delle attività di riesame del contratto e quelli incompleti, ambigui o incongruenti devono essere chiariti con i responsabili che li hanno stabiliti.

Significato della norma

I dati e i requisiti di base della progettazione sono tipicamente sotto forma di:

• specifiche sulle prestazioni del prodotto;
  
• descrizione del prodotto con specifiche relative alla configurazione e composizione.
  

Tutti i requisiti di base della progettazione, quali quelli legislativi o relativi alle prestazioni, al funzionamento, alla descrizione, alle condizioni ambientali e alla sicurezza devono essere definiti, riesaminati e registrati dal fornitore in un appropriato documento descrittivo del progetto, che deve esprimerli tutti con la maggiore estensione possibile. Esso deve inoltre comprendere i dettagli contrattuali concordati tra il committente e il fornitore sulle modalità di adempimento dei requisiti stessi, nonchè la risoluzione di richieste incomplete, ambigue o contraddittorie riscontrate.
Nello stesso documento si dovrebbero identificare gli aspetti di progettazione, i materiali e i processi che richiedono analisi e sviluppo (compresa la prova di prototipi) per verificarne l'adeguatezza. Descrivendo il progetto in questo modo, verrà prodotto un documento di riferimento aggiornato man mano che la progettazione si sviluppa.

Cosa deve fare un software

L'efficienza di un software in questa fase consiste principalmente nella capacità di supportare la raccolta di tutte le informazioni disponibili sugli aspetti del progetto nel modo più completo possibile. Questo deve consentire ai responsabili di reperire e gestire l'intera documentazione delle specifiche e i requisiti su cui impostare una rapida e funzionale progettazione. Unificando tutte le Funzioni competenti (come la Direzione tecnica con quella commerciale), il software di gestione dei dati deve garantire che tutto quanto raccolto sia visionabile nell'immediato per consentire la verifica della completezza dei dati. Il software deve altresì permettere di specificare una serie di informazioni, come soluzione proposta, priorità di intervento in relazione al carico di lavoro, tempo a preventivo e verifiche necessarie allo sviluppo del progetto. È fondamentale, per questo tipo di software, essere flessibile e capace di adeguarsi alle necessità e alle esigenze del caso e permettere che si possa specificare al livello di dettaglio desiderato qualsiasi aspetto relativo al progetto, sia esso essenziale o meno.

Cosa fa il Q9000

Il Q9000 gestisce la documentazione delle specifiche di progetto tramite lo stesso modulo con cui viene inoltrata la richiesta di progettazione. Il pregio di questa gestione consiste nel possedere un'elevata compattezza, eliminando il pericolo di perdita di informazioni importanti.
Operativamente, l'ente richiedente il progetto specifica le caratteristiche su cui impostare il progetto nel modulo di immissione, che rende disponibili dei campi obbligatori dove specificare le informazioni fondamentali al progetto e altri non obbligatori dove inserire i dettagli. Come sempre l'estrema flessibilità permette all'utente di impostare la griglia del modulo, ovvero di decidere le caratteristiche dei campi in base al tipo di dati da raccogliere e alla loro importanza (obbligatorietà o meno del campo).
Riportiamo di seguito un esempio (Fig. 9) di modulo di RDPR in cui è stata scelta come griglia di impostazione la RDI (richiesta di intervento) caratterizzata dai campi evidenziati.
Oltre alla griglia impostabile, esistono una serie di altri campi, obbligatori o meno, che permettono di specificare ulteriori informazioni utili al progetto, quali procedura di riferimento, data di evasione programmata o ente designato.
Esiste poi la possibilità di gestire le note (per i particolari si rimanda alla sezione introduttiva), tramite cui è possibile allegare al modulo qualsiasi tipo di informazione, dettaglio, precisazione, specifica o commento, relativi al progetto. In questa fase le note libere sono sicuramente una peculiarità, infatti la loro completezza funzionale le rende versatili a soddisfare qualsiasi tipo di esigenza, per cui un pacchetto di questo tipo può risultare estremamente utile,
Le note rimangono parte integrante della RDPR e costituiscono l'insieme della documentazione di base indispensabile per l'avvio della progettazione. Ai dati raccolti in questo modo si aggiungono le correzioni, le integrazioni e le eventuali modifiche apportate durante le varie fasi dello sviluppo del progetto.
Quando l'ente incaricato alla gestione della RDPR consulta l'intera documentazione disponibile, è in grado, tramite le funzionalità fornite dalle note, di operare su di esse qualora siano state riscontrate inesattezze, ambiguità, specificazioni incomplete o mancanti.

Fig. 9. Immissione dei requisiti di base della progettazione.

Risultati della progettazione

_i_(4.4.5) I risultati della progettazione devono essere documentati ed espressi in modo da poter essere verificati e validati a fronte dei dati e requisiti di base della progettazione.
I risultati della progettazione devono:
- soddisfare i dati e i requisiti a base della progettazione;
- includere o richiamare i criteri di accettazione;
- indicare le caratteristiche della progettazione critiche e importanti per la sicurezza e la corretta utilizzazione del prodotto (relativi al funzionamento, immagazzinamento, movimentazione, manutenzione e smantellamento).
I documenti contenenti i risultati dalla progettazione devono essere verificati prima della loro emissione._n_

Significato della norma

Questa sezione della normativa dice che i disegni, le specifiche (incluse quelle dei materiali e del processo), le istruzioni, il software e le procedure di assistenza prodotte dal fornitore attraverso l'intero processo di progettazione devono essere opportunamente catalogate e documentate. Questa documentazione verrà utilizzata per l'approvvigionamento, la produzione, i collaudi e l'assistenza. La norma evidenzia inoltre come i risultati della progettazione debbano essere l'incremento delle linee di base sviluppate durante la pianificazione.

Cosa deve fare un software

Il primo punto di questa sezione, "I risultati della progettazione devono essere documentati", può essere supportato dal software per agevolare il lavoro di chi deve catalogare e documentare i risultati finali e per garantire una facile rintracciabilità da parte degli enti coinvolti nella realizzazione del progetto, dei documenti tecnici dettagliati elaborati nella fase di sviluppo della progettazione.
Per una spiegazione completa dei compiti e degli obiettivi del Q9000, si rimanda alla sezione della norma 4.5, "Controllo della documentazione".
I punti in cui globalmente si richiede di soddisfare i requisiti di base della progettazione non possono essere supportati da un software: una volta definiti gli obiettivi in sede di piaificazione, qualora essi non vengano rispettati in fase di sviluppo e di emissione del progetto, generando una documentazione finale non congruente, l'unica responsabilità è da attribuire ai singoli individui che li hanno sviluppati.

Riesame della progettazione

(4.4.6) In corrispondenza di appropriate fasi della progettazione, devono essere pianificati e condotti riesami formali e documentati dei risultati della progettazione. A ciascun riesame della progettazione devono partecipare rappresentanti di tutte le funzioni interessate alla fase oggetto di riesame e, ove necessario, altro personale specializzato. Le registrazioni di tali riesami devono essere conservate.

Significato della norma

La norma prescrive che il fornitore elabori per l'intero sviluppo del progetto la pianificazione e l'esecuzione di riesami sui risultati raggiunti, in funzione dell'importanza del progetto stesso e del numero di proposte di analisi avanzate. Si specifica che tali riesami devono essere:

• formali, nel senso che devono verificare la conformità delle azioni di progetto con gli standard dell'azienda e con tutte le prescrizioni tecniche a cui attenersi.
  

Questi momenti di verifica servono essenzialmente per fare il punto sull'evoluzione del progetto e ne riguardano di volta in volta vari aspetti e ambiti tecnici.
È importante che, per l'efficacia di queste verifiche, le Funzioni partecipanti abbiano a disposizione tutti gli elementi di valutazione necessari ad un esame valido, razionale ed aziendalmente produttivo. Queste verifiche devono generare un quadro chiaro sulle azioni da intraprendere per correggere e migliorare lo sviluppo del progetto, al fine di garantire validità tecnica e commerciale al prodotto/processo, sia come costo, sia come affidabilità. Si deve assicurare che ogni raccomandazione, perplessità operativa e idea innovativa siano esaminate in tutti i mimimi aspetti, anche se apparentemente trascurabili. Possono, ad esempio, essere richiesti controlli sulle modifiche (il relativo responsabile sottoporrà all'esame della Direzione Tecnica tutta la documentazione elaborata) e sui calcoli fatti prima di procedere alla modifica definitiva dei disegni.
Potrebbe dimostrarsi necessario un esame interfunzionale, sempre da giacenze in magazzino, valutando di estendere le modifiche, oppure ancora di valutare con la Direzione Tecnica l'opportunità di attivare eventuali prove sperimentali necessarie alla fase progettuale di modifica.
I riesami servono per analizzare lo stato di aggiornamento e approvazione di tutta la documentazione, assicurandosi che ogni Funzione aziendale coinvolta, dal Servizio Acquisti al responsabile della Programmazione dei lavori, abbia registrato e documentato tutte le osservazioni sul progetto riguardo i cambiamenti apportati che si discostano da quanto indicato dalla distinta stessa.

Nella maggior parte dei casi lo sviluppo dei piani di affidabilità e manutenibilità avviati in fase di progettazione, modifica e autorizzazione a una deroga, necessitano di verifiche del tipo:

• esistenza o meno di altre applicazioni del tutto simili e quindi già collaudate dall'esperienza;
  
• analisi dei punti del progetto che necessitano del supporto della sperimentazione;
  
• analisi degli effetti creati dall'introduzione dell'azione correttiva.
  

I responsabili dell'azione correttiva attivata a seguito di piani di affidabilità devono presentare, in sede di verifica, informazioni che riguardano:

• la descrizione delle fasi attuate nella correzione intrapresa;
  
• i risultati di tale azione;
  
• le responsabilità di conduzione dell'azione correttiva documentate (i risultati del riesame devono essere registrati e resi noti per gli enti competenti).
  

Cosa deve fare un software

Un software in grado di rispondere alle esigenze dell'azienda per le fasi di riesame della progettazione deve rendere disponibile un complesso di strumenti atti a soddisfare i seguenti requisiti:

• gestire la documentazione elaborata nel corso della progettazione;
  
• organizzare e documentare l'attivazione, lo sviluppo, la conclusione e i risultati delle azioni correttive, sperimentazione e prova intraprese;
  
• documentare le risultanze dei riesami sotto forma di giudizi, commenti e osservazioni.
  

In questa fase il software deve assistere l'operatività delle verifiche, soprattutto rivelando grande efficienza nell'organizzazione delle informazioni elaborate e semplificando la gestione delle attività legate agli interventi sul progetto. Il supporto che ne risulta è di notevole importanza poiché consente di perseguire un esame valido e produttivo sul progetto.

Cosa fa il Q9000

Il riesame della progettazione così come concepito dalla nuova normativa prevede la stesura di un piano di revisione, per verificare l'esecuzione di quanto prefissato.
Questo piano di verifica può essere emesso con il Q9000 in due modi:

1. attraverso la gestione Audit per mezzo della quale, a fronte della richiesta di progetto, possono essere pianificate le date di verifica da eseguire e stesa, per ognuna, una griglia di riferimento delle verifiche stesse.
   
2. emettere delle richieste di intervento programmate in scadenza per eseguire la verifica sull'andamento del progetto e collegare tutte queste alla richiesta originaria.
   

Entrambi i due metodi permettono una stesura funzionale del piano, ma non perfettamente in linea con la nuova normativa: il primo è piuttosto macchinoso e, sebbene sia possibile legarlo alla richiesta di progetto, non appare immediatamente all'apertura della richiesta di progetto, ma è da ricercare tra le richieste collegate; il difetto del secondo consiste nel possibile collegamento dei punti della verifica al progetto in serie, cioè in sequenza l'uno con l'altro.
Un modo migliore per gestire il piano del riesame potrebbe essere il collegamento tra le varie richieste di intervento relative al progetto in parallello, in modo da visualizzare, all'apertura del progetto, un vero e proprio piano consultabile di pari passo con l'avanzamento del lavoro, per accertarsi che quanto pianificato venga eseguito.
Pertanto, nei due modi sopraccitati, il Q9000 permette la stesura delle richieste di intervento che costituiscono i punti del piano.
Le principali tipologie di richieste di intervento che possono interessare una fase di riesame sono:

• RDPR Richiesta di progettazione
  
• ACOR Azione correttiva
  
• RMAM Richiesta di modifica
  
• RDSP Richiesta di sperimentazione
  

Selezionando la richiesta da analizzare, è possibile conoscerne le relative specifiche. Per una RDSP, ad esempio, è immediato essere al corrente di ente richiedente, problematica trattata, soluzioni proposte, procedure di riferimento, ente designato per la gestione della richiesta, responsabile dell'evasione, richieste collegate, ore a consuntivo, esito della soluzione adottata, riferimento alla documentazione da allegare (disegni, calcoli) e commenti e osservazioni raccolte.
Per l'analisi della documentazione legata ai componenti di un articolo del progetto, contemplati nella distinta base aggiornata dal pacchetto gestionale dell'azienda, il collegamento è effettuato con le solite regole di entrata nei file in modo estremamente semplice, senza dover rintracciare la documentazione interessata ed evitare di disporre di informazioni non aggiornate.
L'attivazione dei provvedimenti di modifica necessari alla conformità del progetto con le specifiche di base avviene con il procedimento più volte menzionato. È da sottolineare solo che il programma realizza (con alcuni limiti) una connessione automatica tra tutte le attività introdotte durante lo sviluppo della progettazione. Ad esempio, in seguito a un riesame avente come oggetto una richiesta di sperimentazione, quest'ultima "ricorda" in ogni momento la sua origine.

Verifica della progettazione

(4.4.7) In corrispondenza di appropriate fasi della progettazione, devono essere eseguite verifiche della progettazione per assicurare che, per ciascuna fase, i risultati della progettazione soddisfino i relativi dati e requisiti di base.

Nota 10: La verifica della progettazione, oltre ai riesami (vedere 4.4.6), può comprendere attività quali:

• esecuzione di calcoli alternativi;
  
• confronto del nuovo progetto con uno simile già sperimentato, se disponibile.
  
• effettuazioni di prove e dimostrazioni;
  
• esame dei documenti della fase della progettazione considerata, prima del loro rilascio.
  

Significato della norma

La norma descrive quattro misure di controllo con cui il fornitore può attuare, nell'ambito del concepimento e della definizione del progetto di un nuovo prodotto, le verifiche interfunzionali atte ad ottimizzare i risultati sotto gli aspetti qualitativi, affidabilistici e di costo, al fine di rispettare i requisiti di base. In genere è appropriato impiegare due o più di questi metodi.
Talvolta risultano necessari riesami e prove esterne su particolari tipi di prodotto, tuttavia, anche in condizioni ordinarie, la verifica della progettazione deve coinvolgere personale diverso da quello responsabile dell'attività esaminata per rendere il più possibile imparziale l'esito delle verifiche stesse. In pratica, il controllo è affidato al personale che ha realizzato, o che comunque è coinvolto, nel progetto e che, naturalmente, deve possedere competenza adeguata.
La produzione può essere avviata solo a fronte del benestare di tutte le Funzioni aziendali interessate. In genere l'organizzazione e la conduzione delle riunioni di verifica, in cui le diverse Funzioni (Vendite, Produzione, Controllo Qualità, Acquisti, ecc...) portano i risultati delle proprie esperienze e conoscenze, sono affidate al responsabile del progetto e sono programmate in base all'importanza del progetto e ai problemi riscontrati durante il suo sviluppo.
Il responsabile del progetto dovrà perciò provvedere, oltre che al riesame dei vari aspetti tecnici e formali della progettazione (vedi 4.4.6), all'esecuzione di verifiche che provino il perseguimento degli intenti preposti. La verifica consente di sondare gli aspetti interessanti del progetto per rispondere a quesiti del tipo:

• i risultati raggiunti soddisfano tutti i requisiti di base?
  
• sono coperti gli aspetti di sicurezza?
  
• sono stati scelti materiali adeguati?
  
• il progetto del prodotto e le capacità del processo sono compatibili?
  

È importante che queste verifiche siano condotte con il massimo scrupolo per evidenziare tutte le incongruenze e gli errori che possono compromettere la validazione finale del progetto.
Per eseguire calcoli alternativi devono essere disponibili i fondamenti teorici necessari e gli strumenti di supporto per la loro effettuazione.
Il confronto del nuovo progetto con uno simile già sperimentato presuppone l'esistenza di un'efficiente gestione della documentazione che permetta di visitare senza complicazioni l'archivio delle attività di progettazione svolte dall'azienda fino a quel momento. La capacità di sfruttare l'esperienza del passato costituisce un importante punto di riferimento per condurre una valida verifica. Ciò suggerisce immediatamente l'utilità di un pacchetto software in grado di "tenere memoria" dei risultati conseguiti in attività già svolte. La sua efficienza si misura nella complessità dei collegamenti che è in grado di realizzare con l'archivio. Più informazioni sono recuperabili sui particolari del progetto, maggiore è il livello di approfondimento con cui è condotta la verifica. Se su un componente o un gruppo di componenti è già stata realizzata una serie di prove in passato, è fondamentale poterle recuperare velocemente per confrontarle con quelle realizzate nell'attuale fase di progettazione.
La fase di verifica si estende anche alla realizzazione del prototipo e le indicazioni e le osservazioni da parte delle competenze coinvolte vengono raccolte e documentate e rappresentano la base della discussione interfunzionale e di ulteriori e definitive correzioni al progetto.
A questo scopo possono dimostrarsi necessarie prove e dimostrazioni di qualifica, impiegate le quali, la sicurezza e le prestazioni del prodotto, sia esso materiale, software o servizio, dovrebbero essere verificate in condizioni rappresentative di tutte le situazioni nell'utilizzo reale. Le unità di prodotto utilizzate per le prove e le dimostrazioni a scopo di qualificazione dovrebbero essere prodotte nelle stesse condizioni per la produzione effettiva.
Per ciò che riguarda gli ambiti di applicazione di un software in questa fase di progettazione, vale sostanzialmente quanto è stato detto per il riesame del progetto.

Cosa fa il Q9000

Il Q9000 è in grado di realizzare collegamenti con l'archivio per reperire le informazioni sul passato delle esperienze realizzate.
Di un articolo, ad esempio, è possibile conoscere, se esistono, tutte le operazioni effettuate finora su di esso; quindi per una verifica avente per oggetto proprio quel particolare del progetto, è possibile accedere alla specifica porzione di archivio dedicata. Operativamente si entra in interrogazione nel modulo di Gestione delle Richieste di Intervento e si seleziona per quel prodotto l'ambito dei limiti di ricerca interessato.
Di seguito riportiamo un esempio (Fig. 10) di quanto detto.

Fig. 10. Interrogazione delle richieste di intervento effettuate sull'articolo selezionato con i limiti.
In questo modo si accede all'insieme delle azioni eseguite globalmente sul particolare (es.: Fig. 11).

Fig. 11. Interventi effettuati sull'articolo selezionato con i limiti.
Questa documentazione "storica" riguarda ogni aspetto della progettazione (articoli, personale, ecc...) e sono disponibili diverse possibilità di parzializzazione; si può quindi conoscere come il dipendente X abbia operato in passato sul componente Y, oppure quale tipo di articoli competano a una soluzione adottata per una certa modifica (vedere anche la sezione relativa alla FMEA) . Queste informazioni sono estremamente utili per confrontare le esperienze già sperimentate.

Validazione della progettazione

(4.4.8) La validazione della progettazione deve essere eseguita per assicurare che il prodotto soddisfi specifiche esigenze e/o requisiti dell'utilizzatore.

Nota 11: La validazione della progettazione va eseguita dopo positiva verifica della progettazione (vedere 4.4.7).
Nota 12: La validazione va di regola eseguita in condizioni operative definite.
Nota 13: La validazione viene di regola eseguita sul prodotto finale, ma può essere necessario farla in fasi intermedie prima del completamento del prodotto.
Nota 14: Possono essere eseguite validazioni multiple, se previste utilizzazioni diverse.

Significato della norma

La validazione mette in luce un aspetto molto importante della progettazione: i risultati che escono dalle calcolazioni possono essere formalmente validi ed ogni specifica tecnica può essere corretta; ma se il progetto ottenuto non risponde alle aspettative dell'utilizzatore l'intera progettazione non ha avuto successo ed è da rivedere. Se il progetto ottenuto risulta troppo complesso rispetto alle capacità e le conoscenze dell'utilizzatore, il progetto non è valido nonostante che la fase di verifica sia stata superata positivamente. Una lavatrice deve poter essere utilizzata, quotidianamente, da una persona qualunque senza che per farla funzionare debba ricorrere ad operazioni farraginose e complicate, o ricordarsi codici impossibili per poterla programmare. Per testare l'adeguatezza del progetto alle richieste di utilizzo, vengono effettuate delle prove di validazione che analizzano questi aspetti. Il livello di approfondimento e la frequenza di queste prove dipende, naturalmente dall'importanza del progetto stesso: la norma infatti prescrive l'effettuazione di validazioni intermedie e multiple nei casi in cui ciò sia necessario. La responsabilità di coordinare la validazione è affidata in genere alla Direzione Tecnica.
Quest'ultima provvede:

• a un controllo finale del progetto
  
• all'approvazione (tramite timbri, firme o altro) di ogni documento o disegno emesso.
  
• all'avvio della costruzione dei prototipi
  
• all'archiviazione di tutta la documentazione
  

Durante la realizzazione dei prototipi tutti gli enti interessati (ad esempio Acquisti, Produzione, Montaggio, Collaudo, Qualità, Programmazione Lavori ecc..) possono raccogliere le osservazioni e le indicazioni riscontrate. Alla fine il responsabile del progetto provvederà a verificare con la DT e con la DC che sia stato conseguito l'obiettivo proposto dalla DC in fase di emissione della RDPR.

Cosa fa il Q9000

Per ciò che riguarda gli ambiti di applicazione del Q9000 in questa fase di progettazione vale sostanzialmente quanto è stato detto per i punti precedenti della norma.

Modifiche alla progettazione

(4.4.9) Tutte le varianti e le modifiche devono essere identificate, documentate, riesaminate ed approvate da personale autorizzato prima della loro attuazione.

Significato della norma

Le modifiche alla progettazione possono essere dovute a numerose ragioni, per esempio ci potrebbero essere omissioni, errori, difficoltà di fabbricazione e installazione identificati dopo la fase di progettazione, inoltre potrebbero essere originate da richieste di modifica da parte del committente o del subfornitore, da esigenze di migliorare funzioni e prestazioni di un servizio o di un prodotto, dalla modifica di requisiti cogenti, di sicurezza, da verifiche della progettazione, da azioni correttive.
Vediamo come potrebbe essere gestito il percorso di modifica alla progettazione in conformità alla norma. La richiesta di modifica compilata tramite un apposito modulo dovrebbe essere inoltrata all'ente destinatario della richiesta, che in genere è la direzione tecnica, corredata di tutti i documenti e particolari che l'ente emittente riterrà opportuno allegare per meglio focalizzare l'obbiettivo proposto. La direzione tecnica in base alla richiesta pervenuta provvederà ad individuare un responsabile per la conduzione a buon fine della modifica registrandolo in apposito documento, a verificare la completezza delle informazioni affinché la modifica possa essere mirata ad assolvere l'obbiettivo proposto, a verificare quali complessivi o prodotti sono interessati alla modifica del particolare, a definire la data di inizio validità della modifica. Se la modifica al progetto è di grande rilevanza allora la direzione tecnica richiederà la riunione del comitato azioni correttive le cui decisioni (analisi FMEA, calcolazioni, prove sperimentali etc..) verranno registrate su di un apposito modulo. Nel caso invece di interventi minori la direzione tecnica collegialmente con il responsabile dell'evasione della modifica con eventualmente gli enti interessati procederanno all'analisi del problema definendo e dichiarando sull'apposito modulo la soluzione proposta.
La direzione tecnica provvederà a registrare la richiesta di modifica ed a consegnare quest'ultima al responsabile dell'evasione.
Il responsabile della modifica designato provvederà ad eseguire tutte le operazioni di calcolo ed analisi che possono garantire l'affidabilità del prodotto modificato, a verificare ed intervenire in modo che la modifica del particolare sia estensibile a tutti i complessivi su cui esso va montato, a verificare le giacenze a magazzino valutando la possibilità di estendere la modifica anche ad essi, a verificare che la modifica richiesta non contrasti con la storia delle modifiche richieste sul particolare medesimo, a richiedere eventuali prove sperimentali, a confrontare la modifica richiesta con una già sperimentata. Il responsabile della modifica se esplicitamente richiesto sottoporrà all'esame della direzione tecnica tutta la documentazione e le calcolazioni fatte prima di procedere alla fase di modifica definitiva dei disegni. Se le verifiche intermedie e quelle finali soddisfano gli obbiettivi si procede alla modifica definitiva dei disegni e delle specifiche, all'aggiornamento della distinta base e dell'anagrafica prodotto, all'indicazione a disegno del livello di modifica ed emissione della documentazione finale.

Cosa deve fare un software

Un software deve supportare la fase di modifica della progettazione con moduli operativi che permettano la trasmissione delle informazioni tra gli enti coinvolti fino alla registrazione dei codici della documentazione dettagliata, che costituiranno le nuove specifiche di progetto della la parte modificata.
In particolare, deve essere possibile creare un documento software di emissione della richiesta di modifica, in cui specificare l'ente richiedente, gli obiettivi prefissati, la documentazione a cui fare riferimento, per meglio focalizzare gli intenti e i destinatari della richiesta stessa. L'ente a cui quest'ultima è inviata è generalmente la direzione tecnica, che, a sua volta, dovrebbe poter creare nell'immediato un documento per la registrazione della soluzione adottata, della procedura a cui fare riferimento, del responsabile dell'evasione e della data programmata dell'evasione.
Nello sviluppo della modifica, il software deve poi permettere l'accesso a una documentazione che riporti in modo chiaro, ma sintetico, tutte le informazioni utili, per evitare di rifare sperimentazioni, calcoli (prova resistenza materiali, ecc...) eventualmente già svolti. Un applicativo di supporto dovrebbe dunque riportare la storia progettuale del complesso sottoposto a modifica e consentire collegamenti con gli archivi dell'azienda. In ultimo, deve poi essere possibile l'immissione dei risultati finali della modifica, tramite dei moduli di approvazione e rilascio della documentazione.

Cosa fa il Q9000

Il Q9000 gestisce la fase di modifica alla progettazione in modo formalmente analogo a quello visto nel paragrafo della pianificazione; l'unica differenza è che, in fase di immissione, nel campo "tipo di richiesta" verrà selezionata la RMAM (richiesta di modifica) oppure la RDLV (richiesta di lavoro), a seconda dell'organizzazione e delle convenzioni di un'azienda.
Quando si richiede di intervenire su un disegno di progetto, si attiva ad esempio una RMAM, entrando nel modulo di gestione delle Richieste di Intervento.
Viene qui riportato un esempio (Fig. 12, 13) di richiesta di modifica definitivamente evasa:

Fig. 12. Immissione della richiesta di modifica.

Quando una modifica è evasa definitivamente (correzione o aggiornamento di un disegno di progetto), si completa la stesura dei campi (Fig. 13) e si procede alla fase di Rilascio e Approvazione della Documentazione.
L'ultimo campo in evidenza permette di collegarsi al modulo di gestione della richiesta di approvazione e rilascio della documentazione (Fig. 13) e, selezionandolo, viene richiesto di specificare il documento da rilasciare.
Nel caso si tratti di un disegno, si deve definire:

• il Tipo;
  
• la Griglia;
  
• il Livello di modifica.
  

Fig. 13. Risultati della modifica al progetto.

In merito al Livello di modifica il progettista incaricato all'approvazione/rilascio del nuovo disegno di un particolare, può conoscere l'ultimo livello di modifica emesso per l'articolo, interrogando il campo relativo ai Livelli di Modifica.
Il programma consulta l'archivio, cercando tutti i documenti emessi in precedenza e riportando lo stato di rilascio/approvazione, corredato di una serie di altre informazioni utili. Ciò che appare è quanto riportato qui di seguito (Fig. 14):

Fig. 14. Visualizzazione della storia delle modifiche apportate al disegno del particolare con indicazione dello stato di evasione e di rilascio.

In base all'ultimo livello di modifica emesso, il progettista decide, tramite una convenzione tabellata, quale livello assegnare al nuovo documento da rilasciare.
Il livello di modifica è un'informazione fondamentale per l'articolo poichè, essendoci, in genere, per uno stesso particolare più disegni legati ai vari interventi apportati, all'emissione di un ordine di produzione, quest'ultimo deve fare riferimento a un particolare livello di avanzamento del progetto.
Tuttavia, perché il disegno possa essere utilizzato in produzione, è necessario verificare l'avvenuta approvazione e rilascio.
Inoltre, perché l'eventuale fase di collaudo introdotta per la modifica a quel determinato livello sia effettivamente applicata, è necessario che il documento risulti rilasciato. Il programma attua queste verifiche e consente di evitare errori provocati dall'utilizzo improprio di disegni non aggiornati.

Nella figura 15 vengono specificate tutte le informazioni fondamentali relative al rilascio e all'approvazione della modifica (Stato del documento, se è stato evaso o meno, Tipo di modifica, ecc...). La forzatura permette l'approvazione immediata del documento da parte degli enti abilitate.
Al termine di questa fase, risultano inoltrate la Richiesta di Rilascio e di eventuale Approvazione (se non è stata direttamente effettuata) del documento di modifica allo specifico livello.
Successivamente, avviene il collegamento con il modulo di Gestione dei Cicli di Collaudo. In generale, infatti, modificando un progetto, si richiede anche di alterarne una o più fasi di collaudo, per il controllo di quel particolare.
Per una spiegazione dettagliata dei cicli di collaudo si rimanda al capitolo 10.
In questa sede ci si sofferma solo sull'aspetto relativo al livello di modifica. Inserendo una nuova fase del ciclo di collaudo, è necessario specificare il livello di modifica del disegno corrispondente, in modo da evitare che tale ciclo venga emesso su un disegno non ancora rilasciato (a quel livello di modifica).
In seguito all'immissione dell'eventuale ciclo di collaudo, si conclude definitivamente la fase di Richiesta di Rilascio, con il documento in attesa di rilascio (tale stato è definito nel campo Stato Rilascio Approv.: ****** ed è evidente quando si interroga la tabella riassuntiva dei livelli di modifica).
A questo punto, l'ente responsabile del rilascio deve collegarsi con il modulo di gestione di rilascio dei cicli di collaudo e selezionare il documento da rilasciare. I dettagli sul modulo della documentazione, sono rimandati al capitolo dei cicli di collaudo.
L'ente responsabile di Approvazioni e Rilasci può, tramite opportune parzializzazioni, ottenere un quadro di tutti i documenti non ancora approvati e li può consultare, modificare e interrogarne la tabella con i livelli di modifica.
Di seguito proponiamo un esempio (Fig. 16) dei livelli di modifica relativi a un disegno per un certo articolo.
È da notare che lo stato del documento è identificato da un codice tabellato per segnalare che su quel documento non è ancora stato concluso il rilascio/approvazione.

Fig. 15. Richiesta dell'approvazione per il rilascio del disegno modificato.

Fig. 16. Visualizzazione delle modifiche apportate al disegno del particolare con indicati lo stato di evasione e di rilascio.

Una volta entrati nel documento (ad esempio un disegno) è possibile collegarsi con la richiesta di modifica che l'ha generato, attraverso il solito campo di accesso. A questo punto il responsabile può rilasciare/approvare (non è detto che chi approva e rilascia sia la medesima persona), selezionando il comando opportuno e collegandosi con il seguente modulo (Fig. 17):

Fig. 17. Gestione del disegno tecnico.

L'esempio (Fig. 17) mostra il Rilascio del documento emesso in seguito a una Richiesta di Lavoro RDLV per una modifica ad un disegno (anche qui ci si può collegare con la RDLV). Viene cambiato lo stato del documento, come evidenziato nell'esempio (tramite la tabella legata al campo). Da qui è possibile concludere la gestione del documento con la Distribuzione della Documentazione.
Questo argomento è rimandato al capitolo relativo alla Documentazione.
Dal momento in cui il documento è rilasciato, il suo stato viene aggiornato immediatamente e ciò è evidente se si torna a consultare la tabella dei Livelli di modifica (Fig. 18).

Fig. 18. Visualizzazione delle modifiche apportate al disegno del particolare con indicati lo stato di evasione e di rilascio.

La modifica a questo punto può ritenersi conclusa con la fine del rilascio del documento (ovviamente seguirà la stampa dei documenti). I programmi che fanno riferimento a questa documentazione (ad esempio per la gestione degli ordini di produzione) hanno da questo momento l'abilitazione a utilizzare il disegno a quel livello di modifica.

N.B.: Il programma permette di affrontare la situazione che si può presentare quando interviene una modifica di progetto tra la fase di emisione del l'ordine e la fase di dichiarazione di collaudo.
In automatico il programma avverte l'utente che quanto sta per registrare nella griglia si riferisce ad un articolo il cui livello di modifica è stato aggiornato: ciò avviene grazie al fatto che il programma confronta l'esponente di modifica riportato nella dichiarazione di collaudo con la tabella che contiene tutti i livelli di modifica relativi a quell'articolo (si rimanda la spiegazione dettagliata al capitolo 10).