Il forum sulla Qualità di QualitiAmo

[Rosko]

tutti i riesami sono stati fatti, tutte le verifiche sono state eseguite, il prototipo è stato realizzato e testato in laboratorio (prove di tipo). Tutto con esito positivo.
Ora devo fare la preserie con annesso FAI (First article ispection) e andare dal cliente ad installare e testare sul campo il primo sistema direttamente sulle sue macchine.

La mia domanda è: quando si esegue la validazione della progettazione? dopo le prove sul prototipo (i type test)? dopo il FAI sulla preserie? o dopo aver installato e testato il prodotto in campo direttamente dal cliente?

Sul FAI lo escluderei perchè non valido la progettazione ma il processo produttivo.
Invece non sono sicuro se dopo i test sul prototipo o direttamente sul campo.

NB l'installazione la fa il cliente, noi verifichiamo solo se il primo funziona. Se tutto va bene è il cliente dà l'OK allora si parte a produzione piena.

[dario]

Rosko, bella domanda, interessante!
Io (solo ad intuito) andrei a validare (a mettere il check sotto "validato" e a mettere nel dossier di progettazione le copie di documento a comprova) dopo che il cliente ti ha firmato l'accettazione.
significa che ha confrontato i requisiti che ti ha dato in sede di definizione degli input della progettazione ed ha dichiarato che è soddisfatto con l'output "hard" della progettazione, cioé con la fornitura sottoposta ad accettazione, sul campo.
Sarebbe inutile avere documenti FAI ok e poi il cliente che ti annulla gli ordini, no?
io sostengo che la tua ultima frase contiene la risposta utile: "se il primo funziona..."


Io ho vissuto un caso simile dove a macchina fornita (era una bellissima macchina che costava 1,5 Mio di Euro...) l'accettazione durò 16 mesi e costò circa 1 Mio Euro divisi tra cliente e noi... ti lascio immaginare.
La progettazione era "quasi" validata... ma non proprio.
Validarla costò mezzo milione...

[Rosko]

Purtroppo non sempre il cliente mi fornisce una "validazione", l'unico documento cui vengo in possesso è il report di intervento degli addetti dopo lo start-up firmato dal responsabile dei cantieri o dell manutenzione. Al limite il documento di validazione riporterà l'esito sia dello start-up che delle mie prove di tipo, e sulla base di questo rilascio la validazione.

gia che ci sono:

La progettazione di solito la dividiamo in 2 macro parti, lo studio/ideazione che, come output mi fornisce l'architettura e la struttura del prodotto che vado a progettare, e la seconda parte che riguarda l'esecuzione dei disegni veri e propri (schemi elettrici meccanici ecc.).

Al termine di una fase devo proseguire con la verifica, ma cosa è la verifica?

Per me, la verifica, è:

1- il controllo dei disegni/documenti, cioè: corretta redazione, corretta compilazione, disegni completi senza errori, moduli corretti, cartigli compilati correttamente, firme al loro posto, revisioni corrette e soprattutto che ci siano tutti i documenti richiesti.
2- la correttezza dei contenuti affinchè "si assicuri che gli elementi in uscita soddisfino i requisiti ecc. ecc.", pertanto ogni responsabile di area della progettazione, per competenza, dovrebbe controllare e, in caso di esito positivo, firmare il disegno per approvazione che sottointende la verifica.

Devo dare evidenza oggettiva della verifica (quindi modulo) e pertanto creo un documento "Verifica della progettazione".

Cosa inserisco? io faccio così:
elenco tutti i documenti (deliverable) da verificare e segno se sono OK o noOK sulla base dei controlli cui sopra.
Sul secondo punto (i contenuti) però, posso verificare che ci sia la firma di chi ha controllato i documenti e limitarmi a dare un OK o devo andare anche nel dettaglio sul tipo di verifica ecc. ecc.? No perchè altrimenti mi viene notte e non lo ritengo necessario.
Per me basterebbe solo il controllo della firma. Voi che dite?
Il senso della norma a mio avviso dovrebbe essere che chi emette un disegno deve farselo sempre controllare ed approvare da qualcun'altro. Verificare per l'appunto.

La validazione invece è semplicemente la prova del 9. Se il prodotto funziona nelle condizioni richieste e fa ciò che è richiesto allora valido la progettazione.

Ditemi che ci sono arrivato vicino perchè altrimenti sono rovinato (tra 3 settimane ho la certificazione)


Dario, sei ufficialmente il mio Angelo custode per la qualità.

[Paoloruffatti]

Caro Rosko,
ti rimane poco tempo! corri a vedere nel sito la guida ragionata, come consiglia Stefania e così ti chiarisci le idee su che cosa è verifica. In un altro post (non ricordo per chi) l'altro giorno ho chiarito che cosa significa Verifica e che differenza c'è con il riesame (clicca sui miei interventi e lo troverai).
Un consiglio: per carità non fare moduli aggiuntivi!
La tua suddivisione di due "macro parti" è inutile: pensa piuttosto ad un processo, che comincia dal riesame dei dati di ingresso (per vedere se ci sono tutti, se sono sufficienti e chiari, se non ci sono dubbi o discrepanze dal contratto). Ppi c'è la fase di ideazione e alla fine di questa fase fai una verifica sia sul dimensionamento di parti importanti sia solo e semplicemente per vedere se i risultati sono congruenti(vicini) a quelli ottenuto in progetti precedenti simili.
Poi c'è la fase di sviluppo e qui i riesami e le verifiche si sprecano.
I riesami sono ad esempio quando lo sviluppatore fa un disegno poi va dal capo che gli "corregge i compiti" facendo una battaglia navale sulla plottata che il ragazzo gli porta. Il riesame in questo caso è che il ragazzo quando torna al suo video e fa le correzioni, se le spinta col pennarello giallo per essere sicuro di averle fatte tutte e come dice il capo, poi il ragazzo torna dal capo. il quale non ha più bisogno di andare a rivedere se il ragazzo h fatto bene i compiti per casa (deve delegare, altrimenti finisce per correggere compiti mezza giornata al giorno, peggio di una maestrina). Le verifiche sono ovviamente delle calcolazioni alternative (anche con calcoletto spanometrico di massima per capire se digitando dentro al programma hai digitato 10 anzicè 100) a quelle fatte dal progettista con l'utilizzo dei suddetti sw di calcolo.
Quella che tui chiami verifica in realtà è la validazione!
La validazione va fatta per tutto ciò che esce dall'azienda, fosse anche un solo disegno, ma quando va in mano al cliente bisogna essere sicuri che sia a posto; capita spesso di mandare fuori pezzi che tu chiami delivrables o cantierabili.
La validazione può essere richiesta a contratto dal cliente sotto forma di verbale di prova di accettazione; so anche che certi clienti si rifiutano di firmare qualsiasi cosa (pensando così di tenere il fornitore sotto scacco vita natural durante), ma per te il verbale positivo di prova è già validazione della tua progettazione e nel contempo è accettazione di corretta esecuzione degli obblighi contrattuali (...e anche per qualsiasi giudice). Certo che se hai il pezzo di carta firmato l'avvocato ti dirà che fa molta meno fatica a vincere la eventuale causa che il cliente disonesto provasse ad intentarti.

[QualitiAmo - Stefania]

Ecco le pagine:

Riesame della progettazione

Verifica della progettazione

Validazione della progettazione

E questo dovrebbe essere l'intervento di Paolo (è questo, vero, Paolo?)
_________________
Stefania - Staff di QualitiAmo

ISO 9001:2015 - SI AGGIUNGE ALLA COLLANA DEI LIBRI DI QUALITIAMO IL NUOVO TESTO CHE SVELA I SEGRETI DELLA FUTURA NORMA



IL PRIMO LIBRO NATO SULLE PAGINE DI QUALITIAMO



HAI DATO UN'OCCHIATA AL REGOLAMENTO DEL FORUM PRIMA DI SCRIVERE IL TUO MESSAGGIO?

[Paoloruffatti]

Si Stefania, proprio questo intendevo. Grazie!.
Sempre vigili e attentissimi i nostri ospiti, vero ragazzi?
...Ah!, se non ci fosse Stefania bisognerebbe inventarla!!

[Rosko]

no no no.... Basta.

E' la trentesima versione che sento che spiega la differenza tra validazione verifica e riesame.
L'OdC mi fa una NC sulla progettazione in merito a questi tre punti e me la spiega in un modo, il corso la spiegava diversamente, su internet se si prova a cercare ognuno ha la sua versione.
Su Qualitiamo questo argomento salta fuori ogni 2 settimane, e credo che molti non ne siano ancora molto convinti.

7.3.5
"Alcuni metodi per effettuare una verifica possono essere:
- controlli/collaudi su prototipi o parti/componenti"
7.3.6
"La validazione può consistere:
- nella realizzazione di un prototipo o pre-serie"

Cosa cambia?

[Paoloruffatti]

Caro Rosko, abbi pazienza ti avevo risposto in modo circostanziato, ma quando ho dato l'invio è scomparso tutto.
Cara Stefania, capisco che può essere un limite della tenuta in linea per un tempo troppo lungo come facco io spesso (faccio molte altre cose o vengo interrotto per riprendere più tardi, lasciando la connessione aperta), sta di fatto che ho perso tutto il testo e non ho nessuna voglia di riscrivere.

In sostanza ti dicevo che se hai dei delivrables da mandare al cliente li devi considerare ciascuno come una "progettazione" a sè stante e quindi fare riesami, verifiche e validazione PRIMA che lascion il tuo studio. Se il cliente vuole anche le prove in bianco o primo pezzo ecc ecc. allora andiamo sul contratto e quindi il Cliente può volere anche il caffe, oltre ai riesami/verifiche e validazione CHE SONO ATTIVITA' interne e che tu devi fare comunque e sempre per evitare di mandare via porcate.
Le citazioni dei punti 7.3.5 e 7.3.6 sono interpretazioni della norma?, guarda che la norma è chiarissima, per chi vuole leggerla senza fare elucubrazioni se la verifica o validazione sia da fare a macchina funzionante (ci ha provato anche il Sincert allora con una suo documento, ma poi hanno capito che esistono due documenti distinti: la norma e il contratto! e ovviamente si sono scatenati gli ispettori, molti dei quali hanno esperienze limitate di ufficio tecnico!)
Ti dicevo che mi piacerebbe vedere la NC che ha scritto l'ispettore e/o capire se le evidenze "insufficienti" che gli hai presntato non fosse un moduletto con crocette che puzza di falso lontano un miglio: le plottate scarabocchiate sono il vero strumento che usate quotidianamente e che vi tutela dalle porcate.
ciao

[pingo]

Ciao Paolo e scusa se mi intrometto. Mi permetto di darti un piccolissimo consiglio, tu,naturalmente, potrai anche mandarmi al diavolo.

Quando tengo le sessioni aperte per tanto tempo, prima di schiacciare invio faccio un semplice copia-incolla di ciò che ho scritto. Se la sessione è andata (capita quando superi un certo periodo di tempo) potrai tranquillamente ricollegarti e incollare il tuo testo. E' un modo sicuro per non perdere ciò che stai scrivendo!!!

Non hai nemmeno bisogno di incollare fisicamente il testo da qualche parte: basta un semplice ctrl C - ctrl V e resta in memoria!

Ciao e scusa se mi sono permesso.

[bikor]

Ciao Rosko,
ti propongo tre banali equazioni che in passato mi sono servite per non perdermi nel "mare delle versioni contrastanti":

riesame = controllo della completezza (rispetto ai requsiiti da soddisfare)
verifica = controllo della correttezza
validazione = controllo della funzionalità

certamente semplicistico ma può essere d'aiuto.

Riguardo alla validazione se progetto un prodotto che deve garantire una certe resa nel tempo, dubito che lo si possa validare con il solo collaudo iniziale.

[Rosko]

[2p71828]

In campo automotive esistevano (da cui la norma secondo me ha attinto) 3 fasi per la validazione/riesame della progettazione RP1 RP2 e RP3

RP1 verifico la funzionalità dell'idea.
Utilizzo prototipi di tipo A ovvero qualsiasi tecnologia che mi dia un sottocomponente con le medesime funzionalità (per assurdo potrebbe ci potrebbe essere un raccordo tornito in acciaio quando il definitivo è in plastica). Vedo che la funzionalità è ok (non controllo durate e resistenze).
Riunione verifica input-output disegni risultati e passo alla fase due

RP2
questa volta utilizzo dei prototipi realizzati con la tecnologia definitiva, ma linee prototipali. riverifico funzionalità, accoppiamenti. Riunione finale con per verifica input output modifiche etc.

RP3
tutti i sottocomponenti sono da tecnologia definitiva, prodotti da linee definitive, assemblati su linea prototipale (le lavorazioni devono però essere da macchine definitive). diciamo che abbiamo il prodotto finale senza le dispersioni naturali del processo definitivo.
Con questi pezzi ci faccio sia le prove funzionali che di durata.
Riunione finale risultanze dalle prove, modifiche apportate etc e se tutto ok la progettazione è validata

[Paoloruffatti]

Caro Rosko,
per andare avanti dovrei conoscere bene i tuoi prodotti, sia HW che SW: fare una consulenza per chat è davvero difficile.
Per esempio io ho preparato un'azienda che progetta SW per slot machines, con tutta la complicazione dei collegamenti in rete con l'ente statale di controllo (e l'omologazione fatta da un ente terzo che esegue le prove, con adeguati SW di simulazione). Con loro abbiamo trovato i sistemi di verifica in modo semplice, è bastato ragionarci su un po'.
Per lo sviluppo del SW di gioco siamo partiti dalla costatazione del fatto che la progettazione part da un Kit di sviluppo, su cui si basano tutte le attività, come capita ormai per la progettazione dei Sw più disparati (è raro trovare chi parte da zero per sviluppare un SW).

Se abiti lontano mi dispiace per te, ma se abiti vicino, vediamoci: vengo gratis, così la piantiamo di riempire il forum di cose che forse non interessano a molti e che per il mio scarso comprendonio non riesco ad inquadrare bene. Dimenticavo: io abito a Padova e tu?

[Rosko]

Sono di Brescia.

No dai non ti preoccupare, faccio una prova (rischiosa) presentando quello che ho fatto, dopodichè vediamo cosa mi dicono durante la loro visita.
Se l'esito è positivo vi rimando il feedback. Altrimenti ...pace!



Gia che ci sono, volevo un consiglio sempre restando in tema con la progettazione.

Sto creando un indicatore per il monitoraggio delle modifiche della progettazione (troppe modifiche dovute ad errori significa per me progetti non controllati sufficentemente, e qua il discorso V&V di prima che purtroppo sto obbligando a gestire "correttamente" solo in questo ultimo periodo).

In pratica abbiamo un SW per la gestione della documentazione/rilasci, ed ogni rilascio è registrato nel nostro sistema o come modifica o come nuovo documento.

Ammettiamo che:
nel 2008 siano state emesse mediamente circa 800 modifiche e 300 nuovi rilasci.

nel 2009 siano state emesse mediamente circa 700 modifiche e 500 nuovi rilasci. (

Da qui si capisce che circa la metà del lavoro della progettazione è correggere gli errori.

Vorrei fissare un obiettivo, ma credo che un valore assoluto non sia corretto (esempio non più di 600 per il 2010, 500 per il 2011 ecc.) perchè è relativo a diversi fattori influenti.

A mio avviso, il rapporto tra documenti rilasciati e documenti modificati potrebbe essere la soluzione migliore.
Nel primo caso ho un 72% (documenti modificati sul totale rilasciato)
Nel secondo caso ho oltre il 50% pertanto vedo un miglioramento.

Il problema è che le modifiche riguardano progetti di prodotti vecchi anche di 10 anni, mentre i nuovi rilasci valgono solo per i progetti attivi. Se miglioro la progettazione non è detto che riesca a vedere il migliormento dell'indice subito l'anno successivo

voi cosa ne pensate?

[Paoloruffatti]

Beh, la prima cosa che mi viene in mente è di "pulire" il dato modifiche da quelle fatte su prodotti vecchi; intendendo per vecchi quelli che definisci tu, ad es quelli relativi a progetti emessi dopo il corretto funzionamento della progettazione secondo i criteri della ISO 9001.