Il forum sulla Qualità di QualitiAmo

[gibbosky]

Buongiorno a tutti,
sto pensando di realizzare una procedura per descrivere il 7.3 che possa essere poi fruibile da qualsiasi tipo di organizzazione ...sia essa di prodotto che di servizi.
La mia idea è quella di realizzare un flusso molto scarno, perfettamente ricalcante quanto richiesto dal 7.3 e che incentra la pianificazione sul Piano di Progetto !
Detto questo, vorrei sapere i vostri pareri in merito al modo di procedere, in effetti la logica del mio ragionamento condurrebbe ad una cosa del genere:

1) esigenza di progettazione di un prodotto/servizio
2) analisi dei dati sulla base dei quali progettare il prodotto/servizio
3) pianificazione della progettazione del prodotto/servizio
4) verifica delle fasi di progettazione
5) riesame delle fasi di progettazione
6) validazione delle fasi di progettazione
7) gestione di eventuali modifiche da apportare alla progettazione

Tutto questo chiaramente molto sinteticamente.
Sostanzialmente da questo semplice flusso devono uscire dai punti che riporto sotto:

3) PIANO DI PROGETTO
4) REGISTRAZIONE DI AVVENUTE VERIFICHE
5) REGISTRAZIONE DI AVVENUTO RIESAME
6) REGISTRAZIONE DI AVVENUTA VALIDAZIONE
7) Le registrazioni sopra relative alle modifiche.

Ora...quello che più rappresenta il core della progettazione, diviene senza dubbio il Piano di Progetto.
La mia idea è quella di realizzare un piano di progetto essenziale, snello e contenente i soli punti che possano permettermi di condurre una progettazione a prova di chiavistello, inattaccabile e che non permetta errori.
Inoltre, data la necessità di realizzare il prodotto/servizio progettato, il mio ipotetico Piano di Progetto dovrà contenere il rimando al Piano di Qualità (concordato con la produzione) in base al quale verrà prodotto/erogato il prodotto/servizio progettato.

In sostanza la procedura dovrebbe condurre l'organizzazione dall'arrivo di richiesta di un nuovo prodotto/servizio di un cliente, alla corretta vendita/erogazione del prodotto/servizio allo stesso.
Il punto cruciale della procedura rimane il piano di progetto...
La norma sulla progettazione in effetti non ti spiega nel dettaglio come costruirlo, a differenza invece della norma sui piani di qualità (riportante esempi pratici) per cui... mi piacerebbe se potessimo tirar fuori insieme un bel piano di progettazione...semplice snello ed essenziale.

grazie a tutti

gibbosky

[gibbosky]

Le norme a cui faccio riferimento sono le seguenti:

UNI ISO 10006 : LINEE GUIDA PER LA GESTIONE DELLA QUALITA' NEI PROGETTI

UNI ISO 10005 : LINEE GUIDA PER I PIANI DELLA QUALITA'

saluti a tutti

gibbosky

[dario]

Gibby, se ci riesci sei un mito!
Adattabile ad ogni tipo di organizzazione?
A me francamente pare un obiettivo alieno...
Ma mai dire mai.
Ciao carissimo!

[gibbosky]

[bull]

la vedo anch'io un po' difficile, gibby. dato l'argomento, poi, il livello di personalizzazione richiesto dalle diverse organizzazioni è notevole, come fai a fare una cosa che vada bene per tutte?
sì, ok, personalizzeresti il piano di progetto ma secondo me è davvero difficile.

ma come mai sei giunto a questa decisione? da discorsi fatti in passato mi pareva di aver capito che fossi contrario a soluzioni preconfezionate e adattate sulla pelle di ogni singola azienda.

cosa non ho capito?

[gibbosky]

[bull]

ma allora scusami...che differenza c'è tra le tue procedure e un libro di procedure preconfezionate? se sono fatti entrambi bene, ben vengano, no?

guarda che non sto criticando l'idea (che, però, sull'argomento in questione mi sembra difficilmente realizzabile) sto solo puntualizzando che i tanto vituperati documenti standard una mano possono darla in più di un'occasione se si sanno utilizzare!

[gibbosky]

[bull]

uhm...non mi hai convinto del tutto ma così è decisamente più chiaro! ciao, vecchio...buone pedalate!

[gibbosky]

uhm...non mi hai convinto del tutto ma così è decisamente più chiaro! ciao, vecchio...buone pedalate!

Zitto va...dieci giorni di audit continuati... dieci pranzi a ristorante... minimo un paio di Kg in più...non ho il coraggio di montare sulla bilancia :cry:
Pedalare è sempre più dura...cazzarola !!

ciao

gibbosky

[Paoloruffatti]

Lungi da me l'idea di fare il polemico con l'amico Gibbosky ....tanto ci ha pensato l'attento Bull, con commenti che potrei aver scritto io!!.
Mi piace solo dire che Gibbosky pare sia venuto nel mio carrugio (stradina del centro storico genovese), per dire che è giunto alle mie stesse conclusioni!
Per entrare nel merito e per dare un'idea sul piano di progetto, direi che bisognerebbe entrare pesantemente nel merito del prodotto/servizio da progettare, e innanzitutto su come definire/trovare/richiedere gli elementi di ingresso della progettazione, sui metodi di progettazione (simultaneous engineering, analisi del valore. se si parte da un prodotto già esistente, ecc ecc).
Poi, se per piano di prodotto si vuole indicare solo l'attività di pianificazione/programmazione e scheduling, allora bisogna partire da un WBS che, ovviamente, non è standardizzabile (è la pianificazione vera e propria di ogni prodotto/servizio perchè definisce le parti da progettare, le interfacce, le attività e le priorità), …. Il fare le barrette di gantt è l’ultimo dei problemi.
Negli schemi che io ho previsto per le attività di progettazione (e relativa pianificazione) delle diverse società di progettazione (quattro grandi famiglie, aventi problemi operativi simili) ho evidenziato le sostanziali differenze che esistono in questa attività.
Figuratevi se dovessimo creare degli standard per ogni tipo di azienda produttiva: almeno tre grandi famiglie:
1) prodotti su specifica del Cliente,
2) prodotti a catalogo (di piccola e grande serie. …lasciamo perdere il settore automotive!)
3) prodotti di impiantistica (altro mare magnum! … e mi pare di capire che Gibbosky ne sa qualcosa!)
Nello standard che ho creato nel mio secondo libro che ho citato in un altro di questi argomenti, io ho cercato di dare delle direzioni di comportamento (sempre e solo per gli studi professionali) mutuando ed estendendo il metodo impiantistico del project management, anche per i piccoli progetti.
Credetemi: funziona e molto bene devo dire.

Tra le altre cose sottolineo la grande importanza che ha lo strumento dello scheduling settimanale (rolling, con visione di 3 settimane ad esempio) con l’assegnazione delle singole voci di WBS agli operatori, che si rivela come un elemento essenziale si di controllo dell'avanzamento e dei costi, sia di creazione della squadra e di coinvolgimento reale dell’operatore che si sente investito da una vera delega e ha uno stimolo fortissimo a sentirsi responsabile, per il suo pezzettino, del risultato dell’intero progetto, di cui si sente parte integrante (non pedina irresponsabile e non riconosciuta di un lavoro di cui caricarsi le spalle per portare a casa quei quattro soldi maledetti!). Ma qui andiamo sul filosofico…….

PS tra le voci delle WBS ci sono anche le attività di riesame, verifica e validazione (ovviamente!!)
PS2: il piano prodotto è in realtà il “piano della qualità” citato nella nota 1 del cap 7.1 della norma (abbiamo cominciato a farli nel nucleare nei primi anni ’70 )
E davvero una buona idea …. ma ci penserei due volte ad applicarli in tante aziende!
Cordiali saluti a tutti
Paolo Ruffatti

[dario]

il discorso è diventato interessante e avvincente.
grazie a tutti carissimi, per le opinioni e controopinioni che permettono di fare delle belle riflessioni.
io ho la sfiga di dover saltare dall0ospedale all'università all'asilo nido al comune, alla fabbrica di puntine di penna a sfera o roller alla fabbrica di centri di lavorazione transfer all'antenna per il recupero di tossici... (sorry).
Progettare un'attività pedagogico-didattica è assai lontano dal progettare una nuova terapia dallo sviluppare un'unità mandrino a sostentamento magnetico per una rettifica cnc...

Ho dovuto riconoscere che la checklist sviluppata da alcuni colleghi basandosi sul 7.3 (colleghi dell'industria), applicata alla scuola dava idiosincrasie da voltastomaco e se poi la snellivo per l'asilo nido la direttrice mi diceva: dario, di cosa parliamo? ma lo sai che progettare un programma per un bimbo H lo si fa in modo molto diverso?
...
Meglio capire il 7.3 e costruire ad hoc le procedure che sarà di (banalizzo) 5 righe per la scuola dell'infanzia e di 5 pagine per l'ospedale e di 15 pagine per l'ufficio R&D della mia ditta che sviluppa landing gear per la US Navy...
ok?
sole1

[gibbosky]

Ciao tutti,
ringrazio Paolo per i suoi spunti sempre interessantissimi e senza dubbio a grande VA.

[dario]

no, no...
ciao gib,
non escludo il piano di progetto in molti casi utilissimo (a valore aggiunto) ma in molti casi o inutile o controproducente.

Lo so che "customizzare" non ti piace, ma solo personalizzando in modo flessibile incontri l'obiettivo nostro primario: soddisfazione del cliente...

Ti vorrei fare due esempi, ma sarebbero due casi speciali, di personalizzazione e il tuo caso, il prossimo, sarebbe diverso e l'applicazione non incontrerebbe i bisogni del tuo cliente.
Se vuoi ti passo un esempio che io ho ritenuto poco adatto e ho poi dovuto personalizzare (ti do il prima ed il dopo l'ottimizzazione)...

Tu sei un ottimo consulente, lo ritengo dai tuoi interventi, no conoscendoti priofessionalemente, purtroppo... e da ottimo consulente sai che non trovi due casi uguali, sebbene parliamo sempre di modelli e standard.
Facendo bene il lavoro non vai mai a vendere la soluzione copy&paste... pena una bassa soddisfazione del cliente.
You agree?
sole1

[gibbosky]

Ciao Dario,