Esplorare le norme ISO con esempi concreti

Esplorare le norme ISO con esempi concreti

Esempi applicativi per interpretare i concetti e le definizioni comuni alle norme dei sistemi di gestione con uno sguardo diverso.

Un primo approccio alla lettura delle norme ISO sui sistemi di gestione (qualità, sicurezza, ambiente, etc.), per chi è a digiuno di questi argomenti, può risultare un po’ difficile da comprendere e digerire. Una terminologia tecnica, a volte derivante da una poco felice traduzione dall’originale inglese, una consuetudine di significati specifici ormai acquisita in decenni di utilizzo di queste norme possono non agevolare la comprensione per chi si avvicina per la prima volta.

Allora può essere utile bottinare ad esempi applicativi che, in modo più o meno centrato, possono comunque essere funzionali a cogliere i concetti chiave per destreggiarsi poi nei contenuti della norma al suo completo. IN questo pezzo faremo riferimento ad alcuni temi, ma gli esempi possono essere sviluppati, anche autonomamente, senza limiti. E questo potrebbe essere il suggerimento per il lettore: una volta colti gli spunti di queste righe, continuare a svilupparne di propri in modo funzionale ad impadronirsi della norma.

E’ utile cominciare da alcune definizioni citate nella norma per poi continuare con una selezione di contenuti specifici.

Sistema di gestione

Mettendo in insieme le varie definizioni contenute nella norma ISO 9000 (la norma delle definizioni, non la ISO 9001) risulta che un sistema di gestione consiste in un insieme di elementi correlati o interagenti per stabilire politica ed obiettivi e per conseguire tali obiettivi. Quando il sistema di gestione è per la qualità allora ha questo ha la funzione di guidare e tenere sotto controllo un’organizzazione con riferimento alla qualità. Tutto chiaro? Apparentemente sì, ma può essere utile esplicitare maggiormente il concetto per renderlo più concreto.

Pensiamo quindi ad un’azienda (la norma la chiama sempre organizzazione) come se fosse un organismo vivente.  Tale organismo vive e svolge delle funzioni di qualche tipo. Per svolgere queste funzioni in modo efficace l’organismo, consapevole o meno, segue delle regole proprie. Allora questo insieme di regole di funzionamento lo possiamo considerare come esempio di sistema di gestione: un modo di operare che è necessario per lo svolgimento delle attività che l’organizzazione svolge. Ci possono essere benissimo regole non scritte, ma solo prassi consolidate che vengono seguite: ecco questa è forse la differenza rispetto ad un sistema di gestione di impronta ISO. Normalmente, infatti, i sistemi di gestione che qui consideriamo prevedono che le attività siano tracciabili, che esista in qualche modo la possibilità di verificare a posteriori che l’attività è stata effettivamente svolta, che sia rintracciabile chi se ne è occupato effettivamente. Le organizzazioni, prima di implementare (mettere in piedi un sistema di gestione si dice “implementare”) un sistema di gestione conforme alle norme ISO, non hanno necessariamente esplicitato chiaramente chi deve fare cosa e ne risponde. Questo concetto è tipicamente presente, ma non esplicitato in modo univoco, molto spesso in modo articolato. Possiamo a questo punto sintetizzare che un sistema di gestione è costituito dalle regole di funzionamento di una organizzazione esplicitate in qualche modo, normalmente, ma non necessariamente, attraverso delle procedure scritte.

Pubblicità

RSPP - ASPP - RSPP - Aggiornamento 40 ore - Tutti i settori Corso online di aggiornamento per RSPP di attività appartenenti a tutti i settori di attività ATECO 2007. Il corso costituisce credito formativo per RSPP, Docenti-formatori e Coordinatori per la sicurezza sul lavoro.

Efficace ed efficiente

Parto con una definizione “forte” per poi chiarirla: “le norme ISO pretendono l’efficacia ed auspicano la massima efficienza”. E’ sottinteso che pretendono ed auspicano nei confronti delle organizzazioni che hanno deciso di adottare le norme ISO. Vediamo prima di distinguere i due concetti che NON sono sinonimi. Lo illustro con un esempio: una soluzione è efficace quando permette di raggiungere il risultato prefissato. Due soluzioni distinte possono essere parimenti efficaci, cioè permettono di pervenire ad uno stesso risultato, ma eventualmente si differenziano per l’efficienza. Faccio un esempio: pensiamo di dover partire da un punto A e dover raggiungere un punto B a qualche chilometro di distanza e possiamo scegliere tre vie alternative distinte. La prima è un percorso autostradale, il secondo, più breve, è una strada provinciale e la terza è percorribile con un traghetto. Con quella autostradale arriviamo prima (risorsa considerata il tempo), con quella provinciale percorriamo meno strada (risorsa considerata la lunghezza del percorso) la terza considerata è la più economica (biglietto del traghetto che trasporta l’auto è molto basso). Ecco allora che le tre soluzioni sono parimenti efficaci perché permettono tutte di raggiungere il punto B, ma sono diversamente efficienti in termini di risorsa che prendiamo in considerazione: tempo, lunghezza del percorso, costo. Ecco svelata la differenza tra efficacia ed efficienza. La soluzione efficiente è implicitamente efficace. Domanda: vale anche il viceversa? Una soluzione efficace è anche efficiente? Svelerò la risposta solo alla fine. Adesso concludo con la distinzione tra “pretendere” l’efficacia ed auspicare l’efficienza. La norma ISO prevede che siano rispettati dei requisiti e le soluzioni organizzative adottate dall’azienda devono essere efficaci per il rispetto dei requisiti. Questo è necessario. Che poi sul fatto che la soluzione organizzativa sia più o meno efficiente la norma non è rigida: invita a perseguire il miglioramento continuo, ma non dice ne’ in quali processi ne’ in quale misura. E’ per questo che ho sintetizzato il concetto con il termine “auspica”: spinge verso, stimola per, senza essere troppo coercitiva.

Requisiti

Riprendiamo il concetto di “requisito” prima citato. Per poter dire di aver implementato un sistema di gestione conformemente ad una norma ISO presa a riferimento, l’organizzazione deve dimostrare di aver efficacemente soddisfatto TUTTI i requisiti previsti dalla norma. Sottolineo il termine “tutti” che non significa né la maggior parte, né i più importanti. Ma quali sono e come si identificano i requisiti previsti da una norma? E’ semplice: tutte le volte che la norma esprime il concetto “l’organizzazione DEVE” allora quello che segue il verbo DOVERE rappresenta un requisito che la norma chiede sia rispettato. Allora la norma conterrà tanti requisiti quante sono le parole “deve/devono” che sono state espresse nel documento. Domanda legittima:” ma come si deve prevedere di soddisfare questi requisiti?”. La norma non lo dice, lascia la più ampia discrezionalità al progettista del sistema di gestione dell’organizzazione che può definire la modalità che ritiene più congrua e funzionale al buon funzionamento dell’organizzazione. Indipendentemente dalla modalità, per la norma ISO la cosa importante è che il requisito sia soddisfatto. Nessuno meglio di chi vive l’azienda è in grado di trovare le soluzioni applicative più adeguate per soddisfare il requisito. Questo concetto lo riprenderemo quando tratteremo il concetto delle azioni correttive correlate alle non conformità generate in fase di audit (probabilmente quello appena scritto è troppo tecnico, ma più avanti sarà chiarissimo).

Altro dubbio legittimo:” ma perché devono essere soddisfatti proprio tutti i requisiti?”. L’adozione di una norma ISO di processo per la sua implementazione è una scelta libera e quasi mai obbligata. E’ una scelta strategica dell’organizzazione. Potrebbe non arrivare alla certificazione del sistemi di gestione implementato, ma ci sarebbe il rischio dell’autoreferenzialità: “io dico che io sono conforme”. Nel momento che l’azienda sceglie di assoggettarsi ad una valutazione di parte terza indipendente, concetto che viene definito come “certificazione di parte terza”, allora è chiamata a dare soddisfazione completa a tutti requisiti. NON è un obbligo: è una scelta che, se adottata, deve essere completa.

Non conformità o anomalia?

Quando un requisito non viene soddisfatto, allora cosa succede? In questo caso siamo in presenza di una non conformità! La norma la definisce come “mancato soddisfacimento di un requisito” (3.1.2). Ciò significa che tutte le volte che ci accorgiamo che un requisito, un “deve/devono”, non è rispettato allora siamo in presenza di una non conformità, di una carenza, di una mancanza, di qualcosa che era previsto venisse effettuato, ma non lo è stato. La non conformità può essere a qualcosa che non è stato pensato, pianificato, previsto come per esempio non aver definito un processo relativo alla gestione dei fornitori, oppure può essere riferita a qualcosa che era stato previsto dalle procedure del sistema, ma che poi non è stato effettuato come previsto. Il primo esempio si riferisce ad una carenza del sistema che risulta aver un “buco”, non avendo previsto in qualche modo di soddisfare uno specifico requisito. Un esempio di questo tipo lo ritroviamo quando ci è scappato di definire una procedura per qualche attività che la norma considera importante: per esempio la gestione della qualifica preventiva dei fornitori. Un esempio riferito invece ad una carenza applicativa è riferibile alla situazione nella quale la procedura è presente e chiara, ma per qualche motivo in una o più situazioni non è stata applicata: chi se ne doveva occupare non ha attuato quanto previsto nella procedura, in tutto o in parte. Anche questa è una non conformità. Per valutare se e quale dei due tipi di NC sia più grave rimando al punto in cui trattiamo la classificazione delle NC. Penso sia chiaro che la non conformità così come espressa sia uno scostamento da quanto previsto o dalla norma o dalle procedure. In questo senso potremmo considerarla come sinonimo di “anomalia” o di sistema o di applicazione dello stesso. Ma si può distinguere tra il segnalare le anomalie ed il registrare le NC? In altre parole: è legittimo “pesare” le anomalie nel momento in cui vengono rilevate, emergono e classificarne alcune come vere e proprie NC ed altre come più semplici anomalie senza rilevanza? Ripeto che, per quanto riguarda la classificazione, ne parleremo più avanti, ma si può comunque rispondere affermativamente a questa domanda: se è stato chiarito in modo solido quando una carenza sia definibile come NC e quando sia definibile come anomalia, in modo chiaro, immediato e certo da chiunque, allora la cosa potrebbe essere portata avanti. Tuttavia, a giudizio dello scrivente, non è conveniente. Infatti la distinzione chiara, immediata e certa da parte di chiunque si trovi a segnalare una NC/anomalia non è una distinzione agevole e facilmente condivisibile tra tutti gli attori che la devono padroneggiare. A mio avviso è più semplice usare il concetto di NC per poi a posteriori farne una classificazione che può arrivare anche a depotenziare l’urgenza o la gravità della stessa.

Attenuatori

Se ci fate caso, leggendo la norma, il redattore alcune volte non si esprime in termini tassativi, nel senso che i “deve/devono” non sono proprio così rigidi e vincolanti perché ha inteso in qualche modo contenerne il rigore lasciando all’interpretazione del progettista del sistema di gestione la modalità di soddisfazione più efficace in relazione alla realtà specifica, permettendogli, nel contempo, di non considerare il requisito così vincolante. Io ho così discrezionalmente battezzato come “attenuatori” una serie di espressioni utilizzate nelle norme ISO in accompagnamento con i “deve”. Riporto di seguito a titolo di esempio non necessariamente esaustivo:

• Se possibile
• Se o per quanto applicabile
• Nella misura necessaria
• Quando ritenuto opportuno
• Se praticabile
• Etc

Queste espressioni, gli attenuatori appunto, rappresentano un’opportunità per il progettista del sistema di gestione ed un’insidia per l’auditor. Il progettista, infatti, si trova più margini di manovra avendo la possibilità di muoversi nel rispetto del requisito specifico con meno vincoli e più possibilità di spaziare tra le soluzioni alternative ragionevolmente giustificabili e funzionali all’organizzazione. Si trova a poter scegliere tra più modi diversi di soddisfare lo stesso requisito avendo la cura di giustificare adeguatamente le proprie scelte. L’auditor, invece, deve tener presente che quel requisito che sta indagando deve essere visto in modo non troppo rigoroso e come tale deve avere la flessibilità necessaria a comprendere e valutare se il soddisfacimento parziale sia legittimo e coerente con tutti gli altri requisiti della norma. Questo può rappresentare un terreno di confronto insidioso perché l’interpretazione può avere un alto grado di soggettività portando ad un confronto non sempre agevolmente risolvibile.

Informazione documentata: una storiella

Come ultimo argomento di questa prima carrellata di esplicazione dei temi della norme ISO mi azzardo a dare una mia personale spiegazione del concetto di “informazione documentata”. Lasciatemi fare una digressione semiseria per illustrare il mio punto di vista.

C’erano una volta i sistemi di gestione della qualità che si basavano suo concetto di “documento di registrazione”. I documenti di registrazione erano costituiti da tutti i fogli cartacei nei quali chi faceva qualcosa sia di carattere operativo che di verifica o controllo lo doveva segnare su un foglio e spesso doveva firmarlo. Il documento di registrazione rappresentava nei tradizionali sistemi di una volta la modalità con la quale si poteva dare evidenza a posteriori del fatto che una cosa era stata effettivamente effettuata e chi lo dichiarava: spunta, data, firma ed eventuali note. Era un approccio molto formale e con un livello di burocratizzazione dei processi molto spinto, ancora non sovietico o paramilitare, ma sicuramente oneroso. Con lo sviluppo delle organizzazioni, la velocizzazione dei processi produttivi e l’aumento della produttività delle aziende, varcata la soglia dell’anno 2000, ci fu una rivolta silenziosa degli imprenditori che, battendo i pugni sui tavoli di negoziazione, vollero che la qualità venisse alleggerita, resa meno formale e burocratica e più allineata con la velocità dei processi del nuovo millennio. Le pressioni furono tali per cui il Comitato ISO dovette farsi carico delle istanze provenienti da tutto il mondo e misero mano ad una revisione che doveva essere più “easy”, alleggerita, maneggevole. “Pensa che ti ripensa”, nelle menti del comitato venne un’idea geniale: smettiamo la vecchia espressione ed adottiamo la nuova definizione di “informazione documentata” definendola come “informazioni che devono essere tenute sotto controllo e mantenute da parte di un’organizzazione e il mezzo che le contiene”. “Evviva!” esclamarono tutti entusiasti i membri del comitato ISO quando il termine arrivò alla sua descrizione definitiva. In realtà in cuor loro ogni membro manteneva una legittima perplessità perché non ben era chiaro il significato di quello che avevano scritto, ma c’era l’imperativo di cancellare il termine “documento di registrazione” ed in questo modo l’obiettivo era raggiunto. Quello che sarebbe successo poi era eventualmente faccenda di altri… Anche gli imprenditori che si erano tanto lamentati portarono a casa la novità come un successo: erano riusciti ad imporsi ed adesso la norma ISO 9001 non conteneva più quella maledetta definizione, ma anche loro, sotto sotto, si chiedevano cosa fosse tuttavia questa “informazione documentata” che così definita non si riusciva a prenderla chiaramente! Furono i consulenti, che annusato il bisogno e l’opportunità di business, dichiararono che il concetto era invece di facile comprensione e si prestarono prontamente ad aiutare gli imprenditori bisognosi nella rivisitazione dei loro sistemi convertendo i vecchi documenti di registrazione in informazioni documentate.

E qui finisce la favola. La sostanza è comunque che è stata riconosciuta la validità di tutte le modalità alternative alla carta (che comunque resta) per poter tracciare o descrivere un’attività: video, audit, file excel, procedure informatizzate sono esempi di informazione documentata che risponde al principio di verificabilità da parte di terzi, identificabilità e collocazione temporale precisa.

E ancora…

Ci sarebbe ancora da parlare di ulteriori spunti riferiti a:

• Il gioco degli evidenziatori colorati
• Norma e linea guida
• PDCA in pratica
• Tutti i vari riesami della norma
• Scopo o Campo di applicazione
• Correzione ed Azione correttiva
• Analisi di contesto
• Politica
• Per fare un’azione preventiva è necessario essere veggenti.
• Risk assessment
• Stakeholder
• Obiettivi e requisiti
• Procedure e processi
• Competenza e consapevolezza
• Riesame, verifica e validazione nella progettazione
• Controllo, autocontrollo ed audit
• Il cambiamento: prima, durante e dopo
• Appaltare ed esternalizzare (outsourcing)
• Stato evolutivo di un sistema di gestione
• Consultazione e partecipazione
• Classificazione delle NC

Ma ne parleremo altrove o più avanti.

Ing. Davide Biasco

Licenza Creative Commons

I contenuti presenti sul sito PuntoSicuro non possono essere utilizzati al fine di addestrare sistemi di intelligenza artificiale.