![Indice del forum](templates/subSilver/images/logo_phpBB.gif) |
Il forum sulla Qualità di QualitiAmo Torna all'homepage di QualitiAmo
|
Precedente :: Successivo |
Autore |
Messaggio |
rhox Forumista classe "oro"
![](images/avatars/gallery/animali/orca.gif)
Registrato: 05/05/15 12:57 Messaggi: 2134 Residenza: Prov. Torino
|
Inviato: Ven Apr 15, 2016 9:25 am Oggetto: differenza tra procedure e istruzioni |
|
|
ciao,
sto tirando giù le bozze delle documentazioni per l'iso 9001:2015.
sono in dubbio su come strutturarle, nel senso ho sempre usato le procedure per gestire processi più generici ed eventualmente collegandoci un modulo e le istruzioni (generate da una procedura o con una "vita autonoma") dove invece si definiscono dei passaggi per eseguire le cose.
mi spiego meglio con un esempio: ho una procedura per la creazione dei modelli produttivi che spiega chi, cosa e come nascono descrivendo il macroprocesso, poi un'istruzione collegata che spiega informaticamente i vari passaggi da fare.
in azienda invece fino ad ora quando creavano una procedura in realtà facevano un file con i vari passaggi eventualmente divisi tra servizi (prima produzione fa questo, poi logistica fa quello) senza nessun'altra indicazione. ovvero quella che io considero un'IO
dovendo mettere mani su quanto presente e guidando per le creazioni future conviene mantenere la differenza o potrei strutturare la parte praticamente tutta con istruzioni (convertendo nel caso anche le mie procedure) e lasciare solo delle macroprocedure per i processi generici (es. smaltimento rifiuti) che non richiedono ulteriori istruzioni operative? |
|
Top |
|
![](templates/subSilver/images/spacer.gif) |
|
![](templates/subSilver/images/spacer.gif) |
KK King of Kuality
![](images/avatars/1966509517604b162e265c9.jpg)
Registrato: 23/04/09 14:36 Messaggi: 10266
|
Inviato: Gio Giu 16, 2016 8:05 am Oggetto: |
|
|
Non conoscendo il tuo sistema e la tua azienda, non so se la mia risposta sarà adeguata al lavoro che intenderati fare.
Nel mio modo di immaginare un sistema documentale, io terrei a livello di procedura solo la descrizione di quei processi collegati ai KPI, collegati a quello che una volta era il 4.1 della vecchia norma.
Per farla più semplice: quando fai gli audit, quali sono i processi che metti sotto controllo?
Ecco, io farei una procedura per ognuno di quei processi che intendi auditare, il resto sono istruzioni.
Che dici? |
|
Top |
|
![](templates/subSilver/images/spacer.gif) |
QualitiAmo - Stefania Moderatore
![](images/avatars/5759742446eec9961d3e0.png)
Registrato: 16/09/07 18:37 Messaggi: 26601
|
|
Top |
|
![](templates/subSilver/images/spacer.gif) |
MikiMarru Come da manuale
Registrato: 21/11/07 22:34 Messaggi: 1321 Residenza: Brescia
|
Inviato: Ven Giu 17, 2016 8:19 am Oggetto: |
|
|
QualitiAmo - Stefania ha scritto: | A me piace di più come hai descritto all'inizio la tua idea di differenza tra procedura e istruzione operativa. |
Mi associo _________________ Credo fermamente nel detto: "Non ti do il pesce, ma la canna da pesca, e ti insegno a usarla, perché tu possa pescare da solo". E' possibile che la mia risposta sia da intendere in tal senso. |
|
Top |
|
![](templates/subSilver/images/spacer.gif) |
rhox Forumista classe "oro"
![](images/avatars/gallery/animali/orca.gif)
Registrato: 05/05/15 12:57 Messaggi: 2134 Residenza: Prov. Torino
|
Inviato: Ven Giu 17, 2016 9:16 am Oggetto: |
|
|
grazie per le risposte.
alla fin fine ho optato per fare delle procedure generiche per i processi che danno valore aggiunto al prodotto.
per adesso pochissime I.O. in quanto spessissimo sono verbali o variano in corso d'opera... |
|
Top |
|
![](templates/subSilver/images/spacer.gif) |
Paoloruffatti Yoda
Registrato: 26/07/08 11:05 Messaggi: 4071
|
Inviato: Ven Giu 24, 2016 2:06 pm Oggetto: |
|
|
Ciao Rhox,
io chiamo procedure dei processi di attraversamento principali quelle che puoi fare con dei semplci flow chart (quelli con i quali hai fatto la mappatura "As is", poi convertita in "to do".
Poi chiamo procedure di supporto quelle definscono bene i processi che NON aggiungono valore (gli audit, le procedure amministrative, la gestione del personale, ecc) e tutti quelle che comunque che non essendo stata relegate nel capitolo 7, sono finite nei capitoli 9 e 10 (scritti soprattutto per il "common frame" a cui si devono uniformare tutte le altre norme di organizzazione di sistema come la 14001, la 18001 (prossima 45000) e le altre.
Pensa, per restare all'ottimo esempio che porti tu, io ho scritto un libro (cartaceo) a cui si accompagna un SW per la gestione dei costi di commessa e dello studio professionale di ingegneria e ricordo di uno studio che aveva scritto un "vademecum" per i ragazzi-progettisti, che in pratica era una favolosa serie di informazioni di "standardizzazione" (I.O.), che i capi davano agli ultimi arrivati perchè uniformassero, oltre che in pratica la WBS (secondo la quale veniva fatta la programmazione generale di tutte le commesse) ad esempio la scelta dei layers su cui disegnare tutte le strutture come porte e finestre o tracciati per gli impianti termo/idraulici/elettrici di un fabbricato, in modo che il cliente potesse leggere immediatamente il tracciato elettrico, ad esempio chiudendo tutti i lucchetti di autocad, lasciando fuori solo il n° 1 (muri) ad il 4 che faceva vedere solo la sottodistribuzione interna dell'impianto elettrico (la parte di forza era in un altro layer).
Questo vedemecum ora va modificato anche perchè c'erano tutte le istruzioni per la archiviazione di tutti i documenti che circolavano in azienda;
(secondo quel LIBRO che era la vecchia 4.2 pensata per una organizzazione fatta per funzioni); ora la costituzione del "dossier di commessa", oltre che a semplificare enormemente le cose per chi lavora su di una commessa, permette una rintracciabilità immediata di qualsiasi pezzo di carta/e-mail nato anche anni fa.
Comunque la norma non definisce affatto come chiamare ad esempio i documenti di input di una fase del processo di attraversamento, dell'azienda tutta: dall'offerta al Cliente fino alla bolla di consegna/fattura del servizio: al capitolo 7.5 le chiama tutte genericamente "documented information" ....anche le vecchi e care "registrazioni" che devi confermare tutte (o questa è una buonissim aoccasione per eliminare quelle che non servono a nessuno, [Direzione sopratutto!].
Tu puoi chiamarle procedure, o I.O., o Pimpiricchio; ricordati solo di inserire nelle tue "vecchie" procedure, dove è necessario (non dappertutto), i due cqpitoletti sull'analisi del rischio (imprenditoriale e strategico, NON di prodotto) e sui KPI che intendi utilizzare per leggere l'efficienza di quella fase di cui la procedura/I.O./ Pimpiricchio racconta l'operatività.
Infatti, Pimpiricchio fa vedere da dove e quando arriva il semilavorato (con l'aiuto della programmazione [attività che oggi NON ESISTE ANCHE IN AZIENDE da 400 persone!!]) per essere lavorato li in quella fase e dove andrà consegnato (non buttato a prendere polvere in un angolo dove SOLO il capo officina ha deciso di metterlo e SOLO lui sa dove l'ha messo [che se si rompe una gamba [corni da supersitziosi dovuti], il giorno dopo è di nuovo in fabbrica col gesso a dirigere lo smistamento!, come ho visto fare in una fonderia (ora fallita) a nordi di Padova].. . poi lo viene a sapere anche la Finanza, o fiamme gialle [magazzino/ nascondiglio di risorse, non dichiarato...lo chiamano!!] .....e giù! multe salatissime!
Ciao
Paolo
PS: se le tue I.O. sono a tradizione orale perchè cambiano spesso....sei nei casini più neri; quella non è un'azienda, ma un casino vero e proprio....eliminato dal 1954: legge Merlin!, dove le puttane cambiavano ogni quindicina, per evitare innamoramenti tra Cliente e prestatrice d'opera e conseguente perdita di "risorse"! |
|
Top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
Non puoi inserire nuovi argomenti Non puoi rispondere a nessun argomento Non puoi modificare i tuoi messaggi Non puoi cancellare i tuoi messaggi Non puoi votare nei sondaggi
|
|