Il forum sulla Qualità di QualitiAmo

[clockwork_orange]

Buongiorno a tutti,
sono un pivello da poco iscritto, quindi vi prego di perdonare eventuali errori o domande stupide...
Avrei bisogno dei vostri consigli; lavoro per una società che opera negli aeroporti ed è certificata ISO 9001-2015 e ora mi trovo a dover aiutare la nostra quality manager nella transizione da procedura "paper" a "paperless". Saremo obbligati ad un periodo di transizione in cui i moduli di carta,
saranno affiancati a moduli elettronici, ho quindi pensato di aggiungere alla "lista dei moduli" la "lista dei moduli elettronici" e ad aggiornare ogni procedura aggiungendo, tra i documenti applicabili, anche le versioni elettroniche a cui ho dato una numerazione apposita.

Fin qui (secondo me, ma magari sbaglio...) tutto bene , il problema viene ora... nella procedura tradizionale era compreso anche
una copia dei moduli impiegabili, ed essendo tutto un documento Word, non era certo un problema, ma con i moduli elettronici la cosa
è un po' più complicata... Questo perché il modulo "risiede" su una piattaforma, che lo genera in automatico in base ai dati inseriti
da un comune smartphone e quando lo consegna, ha l'aspetto grafico che il produttore della piattaforma ha deciso di dargli, mentre io
posso decidere solo le informazioni che deve raccogliere. Per me è impossibile stampare, anche solo virtualmente, i moduli (in bianco...)
da allegare alla procedura.

L'idea che mi sono fatto io è che allegare i moduli elettronici sia comunque inutile; chi li usa non deve stamparli né fotocopiarli da
un raccoglitore. Accende il "device", in base al compito da eseguire, sceglie il modulo "Pluto" o "Paperino", di cui comunque avrà a disposizione
sempre e soltanto l'ultima versione messa a disposizione... Su pressione di un auditor interno li abbiamo anche dovuti numerare e ci può stare
ma penso che allegare una versione vergine non sia indispensabile.

Grazie mille per il vostro aiuto e le vostre opinioni

Christian

[KK]

Ciao,
ti dico come vedo io la questione moduli.

Ai clienti suggerisco di "inserirli a sistema", ossia di attribuire una codifica e una revisione, quando il modulo è modificabile, secondo due concetti: modificabile inavvertitamente da chi lo usa o revisionabile di chi lo gestisce e lo emette.

Questo perchè il sistema deve servire a tenere traccia delle modifiche e a capire qual è il modello in ultima revisione da utilizzare.

Tutto quello che deriva da un software (ad esempio un gestionale) tendo a non farlo inserire nemmeno a sistema, citando solo in procedura la sua esistenza e il punto in cui viene utilizzato (ad esempio la conferma d'ordine o il DDT, per citare i più comuni), ma nulla più.
Questo proprio perchè tanto non è modificabile e quindi è già garantito l'utilizzo della sua ultima revisione.

Quindi direi che la tua considerazione finale si sposa con la mia visione.
_________________
Konsulente Kualità

[2p71828]

[KK]

Hai perfettamente ragione, ma il tutto credo che vada calato nel contesto dell'organizzazione.

In effetti, la maggioranza dei clienti che seguo da consulente hanno un software gestionale gestito esternamente dalla software house che ha venduto lo strumento software.
L'utilizzo è in prevalenza l'emissione per l'offerta, la conferma d'ordine, l'ordine di produzione e ddt e fattura, e chi li emette si limita a pigiare un tasto per la stampa del documento.

La validazione è avvenuta a monte, quando è stato scelto e configurato il software (presumibilmente dalla direzione o dall'IT manager, nei casi più strutturati), ma dopo oltre 3 anni di consulenza e quasi 15 di responsabile qualità, la richiesta di un ente terzo della validazione dei moduli software mi è capitata solo con Accredia al momento dell'accreditamento di un laboratorio di taratura come centro LAT. Quindi nemmeno in ambito aeronautico ho avuto occasione di vedermi richiesto un tale dettaglio.

Ora mi calo nei panni di Christian, il quale deve gestire la patata bollente dei moduli e della transizione. Un suggerimento più efficace potrebbe essere dato conoscendo l'utilizzo di ognuno dei moduli per i quali deve effettuare questa virtualizzazione, ma considerando che prima erano gestiti in formato word (nemmeno in pdf quindi), oso supporre che il loro contenuto non fosse così top secret o di elevatissima criticità.

Alla luce di questo, seppure in linea di principio hai ragione, rimango comunque convinto che la semplicità della scelta che ho proposto possa comunque mantenere il sistema conforme e passare le verifiche ispettive dell'ente di certificazione.

PS: bentornato! Era un secolo che non ti leggevo
_________________
Konsulente Kualità

[clockwork_orange]

Innanzitutto vi ringrazio per il tempo che mi avete dedicato! I dati che raccogliamo con il software (di cui non faccio il nome essendo a pagamento) sono tutt'altro che top secret, si tratta, ad esempio, dei dati dell'imbarco di un volo (orari, numero di volo, numero di passeggeri, ecc...).
Noi non abbiamo nessuna possibilità di modificare il software, che risiede sui server di chi lo ha creato e mantiene, ma possiamo solo realizzare dei moduli che il personale riempie in base alla parte di operativo che sta monitorando. Alla fine si chiude il report, che viene inviato al cliente via mail, o che rimane a disposizione sul cloud. Una volta chiuso, il report questo non è più modificabile ed il modulo non si può riaprire per essere ritoccato.
Ho preferito classificare i moduli in modo da poter tenere traccia delle modifiche, che solo un limitato gruppo di persone può fare in base ad esigenze lavorative emerse durante l'uso, in base a richieste del cliente o in base a richieste di qualche ente regolatore.

[KK]

Ciao Christian,
rileggendo il tuo post iniziale, dopo aver letto quest'ultima risposta, ho il timore che siamo andati leggermente fuori strada rispetto alla tua domanda iniziale, che invece si focalizzava sull'allegare o meno i moduli alle procedure.

Sperando di non tirarmi nuovamente addosso le ire di 2p71828 ( ), ti dico che è sufficiente se li citi in procedura, sia nel corpo del testo, sia magari in un paragrafo finale (o iniziale, nei riferimenti) che elenca i documenti correlati.

Estendo l'argomento a tutti i documenti per dirti questo: di solito faccio uso di un elenco generale dei documenti di sistema, dove incido il codice, il titolo, indice e data di ultima revisione. Se l'intenzione è quella di gestire poi tutto elettronicamente, a questo registro aggiungerei anche il link al documenti presente in rete, così da avere una immediata e completa rintracciabilità di ogni documento.
Per assurdo, con un giro meno immediato, basterebbe che in ogni procedura tu citassi il registro dei documenti e con due passaggi invece di uno avresti comunque soddisfatto il requisito.
_________________
Konsulente Kualità

[clockwork_orange]

Grazie mille KK,
le eventuali ire di 2p71828 possono essere girate a me , dato che forse non mi sono spiegato bene...

Il fatto che le tue idee siano totalmente simili alle mie mi conforta e mi spinge a continuare con questa modalità.

Grazie ancora per il fondamentale aiuto!!!!!!!!!!!!!!

Christian

[MikiMarru]

Discorso apparentemente semplice....

Premessa
Mi soffermo considerando il caso di un'azienda che utilizza un gestionale, che utilizza per gestire dei dati in ambiti NON soggetti ad obblighi di legge in merito alla validazione.
In qs casi le prescrizioni legislativi sono chiare: il sw deve essere validato (es. sw utilizzato per la progettazione di strutture edili).


In linea di massima, se non ci sono esigenze particolari, per la registrazione "nel SGQ" applico la stessa logica descritta da KK, con la differenza che inserisco i moduli (che poi possono anche essere tool o funzioni di un gestionale" ) anche nell'elenco dei "documenti" del SGQ, senza indice di revisione.
Quando possibile con una codifica, se non è possibile senza.

E' il caso anche di considerare che un modulo cartaceo compilato "contiene" la registrazione, i dati, mentre un "modulo sw" "compilato" non necessariamente "contiene" i dati, sono registrati in un database, ed il "modulo" in fin dei conti non è altro che una interfaccia per immissione (prima) o visualizzazione (successiva) dei dati stessi.
In termine di salvaguardia ne derivano livelli di criticità differenti : per il modulo, in linea di massima, mi preoccupo di garantire l'operatività del processo, mentre per i database mi devo preoccupare di tutto ciò che concerne la potenziale perdita/alterazione ecc. dei dati, con una criticità di livello differente.

Quindi ho casi diversi, a cui applicare modalità di validazione differenti.
Se modulo SW = interfaccia di raccolta/visualizzazione dati mi è necessaria una verifica di "idoneità all'uso" (="sono presenti/sono visualizzati i campi che servono")
In questo caso, con un metodo ammetto alquanto sbrigativo, descrivo il metodo di verifica e chi ne è responsabile in una procedura o in una istruzione, ma l'evidenza della verifica con esito positivo è data dalla "messa online" dell'interfaccia.

Diverso è il caso in cui all'interno del "modulo" software sono presenti sia campi di immissione dati, che campi in cui viene visualizzato il risultato di una operazione effettuata dal sw (es con un algoritmo di calcolo): qui ritengo sia opportuna una documentazione più approfondita in merito ai test eseguiti prima del rilascio e sui loro risultati, per tutelarmi da un rilascio magari troppo sbrigativo con conseguenti problemi nei processi operativi che utilizzano poi i tool (già visto....) .
_________________
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.

[clockwork_orange]

Ciao MikiMarru e grazie,
diciamo che qui si tratta solo di un SW che raccoglie e visualizza dati sotto forma di rapporto, ad operazioni chiuse. Per ora niente calcoli, né obblighi di legge, quindi è la situazione più semplice.

Il problema può essere costituito da chi viene a fare le audit, che alle volte pensa al senso della parola "paperless" (scusate l'inglesismo..) e crede sia quello scrivere sullo schermo invece che sulla carta... Come sostieni tu: "i dati sono in registrati in un database", non devo fare i buchi al tablet ed infilarlo dentro ad un raccoglitore...

Christian

[2p71828]

e vogliamo possiamo vedere la questione in ottica diversa

a) quale impatto hanno i report sul mio servizio?

b) cosa succede se il server è down ?

c) se il db perde i dati?

d) se l'azienda che fornisce il servizio chiude?

e) chi decide quando cambiare i moduli?

f) come faccio a dimostrare di aver formato i dipendenti sull'ultima release del form?

se hai una risposta a tutto sei posto

Nota ai margini
già da un po' di tempo nel campo automotive alcune aziende sconsigliano il cloud.
Dopo i server andati a fuoco con perdita anche dei backup finalmente ci si è interrogati sui reali costi/rischi dei servizi in outsourcing

Ps pochi giorni fa ero al Marco Polo
_________________
=fixed(exp(1);5)
sha-1=661bf49e78e9d958032859e811fa1ca27699207a