Come funziona il software di certificazione di sistemi? Processo digitale dalla domanda al certificato

Cosa gestisce il software di certificazione di sistema?

Il software di certificazione di sistema gestisce nella stessa pratica tracciabile la richiesta, l'esame dell'ambito, la durata dell'audit, la competenza degli auditor, le registrazioni della Fase 1 e della Fase 2, i rilievi, la revisione indipendente, la decisione, il certificato e il ciclo di sorveglianza.

Il valore qui è maggiore dello spostare un modulo cartaceo sullo schermo. L'organismo di certificazione deve poter mostrare, per ogni cliente, quale informazione è stata acquisita e quando, con quali input è stato costruito il piano, quale rilievo è supportato da quali evidenze di audit e sulla base di quale registrazione autorizzata è stata presa la decisione. Il software rende visibile questa catena; non si assume la responsabilità tecnica dell'organismo di certificazione, i suoi obblighi di imparzialità né la sua decisione autorizzata.

Come costruire la struttura portante della pratica digitale?

Una struttura solida non pone al centro la registrazione del cliente, bensì le evidenze decisionali tra loro collegate e versionate, dall'ambito della richiesta al ciclo del certificato.

La ISO/IEC 17021-1:2015 definisce i principi e i requisiti di competenza, coerenza e imparzialità per gli organismi che eseguono audit e certificazione di sistemi di gestione. Secondo il riassunto ufficiale dell'ISO, la certificazione di sistemi di gestione è un'attività di valutazione della conformità di terza parte. Per questo una “opportunità di vendita” aperta nel CRM non è, tecnicamente, una richiesta di certificazione esaminata. Le due registrazioni possono essere collegate; ma scopi, autorità e cancelli di approvazione sono diversi. [1]

Perché l'esame della richiesta non si riduce a un'approvazione di modulo?

L'esame della richiesta deve convertire la domanda dell'organizzazione in un ambito di certificazione; deve valutare congiuntamente attività, sedi, personale, norma, regole di programma e adeguatezza delle risorse.

Non è sufficiente che la schermata di richiesta contenga solo ragione sociale, numero di dipendenti e scelta della norma. Informazioni quali in quali sedi e turni si svolgono le attività, l'esistenza di sedi temporanee o virtuali, i processi critici esternalizzati, la richiesta di sistemi integrati, lo stato della certificazione precedente e l'esigenza di trasferimento modificano l'esame tecnico. Quando un'informazione inserita inizialmente viene aggiornata, il sistema non deve cancellare la risposta precedente; deve generare un compito di valutazione dell'impatto della modifica su offerta, durata, team e ambito.

TÜRKAK chiarisce che gli organismi di certificazione di sistemi di gestione devono rispettare, oltre alla ISO/IEC 17021-1, i documenti di qualifica specifici della norma del sistema di gestione pertinente, i documenti obbligatori IAF e i documenti EA/TÜRKAK applicabili. Ad esempio, i set di competenze e di documenti normativi supplementari delle pratiche ISO 9001, ISO 14001, ISO/IEC 27001 o ISO 45001 non sono gli stessi. Il software non deve ridurre questa differenza a un unico prodotto generico “certificato ISO”; deve gestirla per programma e per ambito. [2]

Come si collegano durata dell'audit e assegnazione del team?

Prima si esegue il calcolo motivato della durata dell'audit; poi si pianifica un team competente, imparziale e disponibile, in grado di coprire tale durata e l'ambito.

L'IAF MD 5:2023 indica che, per i sistemi di gestione qualità, ambiente e salute e sicurezza sul lavoro, la durata dell'audit iniziale, come somma della Fase 1 e della Fase 2, è parte dell'esame della richiesta. Il numero effettivo di addetti è il punto di partenza; ma non è l'unico fattore. Vengono considerati anche variabili quali rischio o complessità, struttura di sedi e turni, lingua, elevata densità normativa, processi esternalizzati e sedi temporanee. La base del risultato del calcolo e delle correzioni effettuate deve essere registrata. [3]

Per questo il software non deve essere progettato secondo l'approccio “seleziona il numero di addetti, ottieni il numero di giorni”. Devono essere conservati insieme la versione del set di regole, l'istantanea dei dati di ingresso, i fattori di aumento/riduzione, la spiegazione, l'approvatore e il motivo del ricalcolo. L'articolo che affronta in dettaglio la logica di calcolo di questo tema Guida alla durata dell'audit IAF MD 5, spiega perché la durata base e la correzione specifica dell'organismo debbano essere tenute distinte.

Anche nell'assegnazione del team non si verifica solo la disponibilità in calendario. Devono risultare la qualifica settore/codice dell'auditore, la competenza sulla norma pertinente, il ruolo, gli incarichi precedenti, la dichiarazione di imparzialità o conflitto di interessi e, se necessario, il supporto di un esperto tecnico. Se non si trova una persona idonea, il sistema non deve ridurre silenziosamente la durata né spostare l'ambito su un altro codice; deve inviare l'eccezione di pianificazione a un esame autorizzato.

Come avanza la registrazione dalla Fase 1 alla decisione di certificazione?

Ogni fase deve chiudersi con il proprio scopo e output; il passo successivo deve richiamare l'output approvato della fase precedente e la modifica retroattiva deve generare una nuova versione.

La registrazione della Fase 1 deve rendere visibili l'idoneità all'audit, le condizioni significative di sedi e ambito, i punti che influenzano il piano della Fase 2 e le questioni da seguire. Nella Fase 2 piano di audit, processi campionati, colloqui, evidenze documentali e applicative e rilievi vengono collegati nella stessa pratica. Un rilievo non è solo testo e classificazione; ha un ciclo di vita con l'evidenza su cui si basa, il requisito pertinente, il responsabile, il termine, la correzione presentata e l'esito della verifica.

Quando la pratica giunge alla fase decisionale, il sistema non deve passare alla logica “se tutte le caselle sono piene, genera automaticamente il certificato”. È utile verificare le registrazioni incomplete o contraddittorie e presentare al decisore sintesi e collegamenti alle fonti; tuttavia ambito, condizioni, motivazione, data e responsabile della decisione devono essere registrati separatamente. Se successivamente cambiano i dati di un rilievo o dell'ambito, la decisione precedente non deve essere aggiornata silenziosamente; deve nascere l'esigenza di una rivalutazione.

Le pratiche di trasferimento e audit a distanza rientrano nello stesso flusso?

Si può usare la struttura comune di registrazione; ma l'esame del trasferimento e l'audit a distanza devono essere scenari separati, con specifici controlli obbligatori ed evidenze proprie.

L'IAF MD 2:2023 definisce i controlli minimi per la validità del certificato, l'ambito di accreditamento e l'esame pre-trasferimento nel trasferimento di certificati di sistema di gestione accreditati. Il fatto che un certificato notoriamente sospeso non sia accettato come una normale pratica di trasferimento e che le informazioni necessarie siano valutate mediante esame documentale e, se necessario, con una visita pre-trasferimento può tradursi in una checklist nel software. Tuttavia il sistema non deve produrre da sé l'esito di questa verifica come “trasferimento idoneo”. [4]

Nell'uso tecnico a distanza devono invece essere registrate quale attività è svolta con tecnologie dell'informazione e della comunicazione, il metodo utilizzato, i partecipanti, la durata, la sicurezza della connessione, l'accesso alle evidenze e la collocazione nel piano. L'IAF MD 4:2023 fornisce una cornice per l'uso dell'ICT a fini di audit/valutazione. Un colloquio effettuabile a distanza e un processo da osservare in sede non sono la stessa cosa; il limite di programma e di rischio deve essere tutelato nella pianificazione autorizzata. [5]

Perché il processo non termina dopo l'emissione del certificato?

Il certificato è l'unico output del ciclo triennale; sorveglianza, modifica dell'ambito, sospensione, revoche, ricertificazione e registrazioni di verifica proseguono il ciclo di vita.

Nella scheda del certificato ambito, norma, sede, validità, decisione, prima emissione e revisioni devono essere distinti. Mentre il PDF del documento è conservato come output immodificabile, la correzione o la modifica dell'ambito deve generare una nuova versione. Il portale clienti deve mostrare il documento aggiornato; l'utente interno deve poter vedere perché e quando le versioni precedenti sono cambiate.

Secondo l'avviso di TÜRKAK del 2 dicembre 2024, l'infrastruttura TBDS è stata estesa a comprendere il monitoraggio delle informazioni di audit e, dal 1° gennaio 2025, gli organismi di certificazione di sistemi di gestione accreditati da TÜRKAK sono tenuti a inserire nel sistema le informazioni relative a prima certificazione, sorveglianza, rinnovo del certificato e altri audit. Ciò rende importante la corrispondenza della registrazione interna con i campi di notifica ufficiali; tuttavia lo stato “inviato” nel software non deve considerarsi riuscito senza la risposta tecnica reale del servizio e il numero di riferimento. [6]

Come appare una registrazione digitale difendibile in audit?

La registrazione difendibile non mostra solo il PDF finale, ma insieme l'input, la versione, chi ha eseguito l'operazione, il tempo, la motivazione, l'approvazione e il valore precedente.

• Versionamento: Le modifiche a richiesta, calcolo, piano, rapporto, rilievo e certificato non sovrascrivono i dati precedenti.
• Separazione dei ruoli: Vendite, pianificazione, auditore, revisore tecnico, decisore e direzione hanno set di autorizzazioni diversi.
• Collegamento delle evidenze: Ogni rilievo è collegato al requisito pertinente e all'evidenza di verifica; ogni decisione alla versione della pratica utilizzata.
• Motivazione dell'eccezione: La modifica di durata, team, data o ambito non è una nota libera, ma produce una registrazione approvata da un responsabile autorizzato.
• Evidenza di notifica: La consegna via e-mail o portale si basa non solo sul pulsante di invio, ma sull'esito tecnico e sull'orario di consegna.
• Registro degli accessi: Visualizzazione, download e modifiche dei contenuti critici sono tracciati per cliente e limite di ruolo.

La ISO 19011:2026 fornisce indicazioni aggiornate sui principi di audit, sulla gestione dei programmi di audit e sulla competenza degli auditor; la pagina ufficiale dell'ISO evidenzia anche chiaramente che questa norma da sola non conduce alla certificazione. Nella progettazione del software si può trarre vantaggio da questa guida per la gestione del programma e la disciplina di audit, ma non può sostituire i requisiti di certificazione di terza parte. [7]

Come attuare il passaggio al software di certificazione di sistema?

Il passaggio più sicuro consiste prima nell'estrarre la mappa dei processi e delle autorizzazioni reali, poi nell'eseguire un pilota su un unico programma e nell'estendere in modo controllato il modello verificato.

1. Smontate la pratica attuale nelle sue parti

Estraete modulo di richiesta, foglio di calcolo, offerta, fascicolo dell'auditore, piano, rapporto, rilievo, verbale di decisione, certificato e registrazioni di notifica. Determinate in quali file si ripete la stessa informazione, quale sia considerato la fonte e chi possa modificarla.

2. Eseguite un pilota con un unico programma e un gruppo limitato di clienti

Non scegliete l'eccezione più complessa, ma un ambito gestibile rappresentativo del processo reale. Il criterio di successo del pilota non deve essere solo la velocità operativa; vanno misurati anche dati mancanti, motivo della ripianificazione, avvisi di errata assegnazione del team, visibilità dei rilievi aperti e accesso alla pratica decisionale.

3. Verificate le integrazioni con evidenza

Nelle connessioni ERP/CRM, e-mail, firma elettronica, TBDS o portale clienti non va testato solo lo scenario di successo. Reinvio, errore di autorizzazione, interruzione del servizio, trasferimento parziale e scenari di correzione devono essere gestiti senza produrre perdita di registrazioni.

4. Versionate regole e norma

Quando cambiano un documento IAF, una regola di programma, una norma o una procedura dell'organismo, occorre determinare con quale versione proseguiranno le pratiche aperte. La pratica precedente non deve essere riscritta con il calcolo attuale; la regola del periodo deve restare visibile.

Quali sono gli errori di progettazione più frequenti?

Gli errori più comuni sono scambiare lo stato del CRM per una decisione tecnica, ridurre la competenza alla disponibilità in calendario e modificare le registrazioni approvate senza conservare lo storico.

• Forzare ogni norma nello stesso flusso di lavoro: Si può costruire una struttura comune; le differenze di programma e di documenti normativi devono rimanere in un set di regole separato.
• Fornire la durata dell'audit con una formula nascosta: L'utente deve poter vedere input, versione della regola, fattore di correzione e motivazione.
• Automatizzare la decisione tecnica: Il sistema può segnalare una carenza; la decisione di certificazione deve essere una valutazione umana autorizzata e tracciabile.
• Rendere il PDF del certificato la registrazione principale: Il PDF è un output; non sostituisce i dati di decisione, ambito, sede, versione e ciclo.
• Dare per assunto l'esito dell'integrazione: L'invio a TBDS, e-mail o portale deve essere verificato con la risposta tecnica reale.
• Eliminare la pratica precedente: La revisione non deve annullare la relazione con le evidenze e le decisioni precedenti.

Come Vizyon Alia supporta questo flusso?

Vizyon Alia è configurata per gestire la pratica di certificazione in un'unica struttura processuale, dalla richiesta e dall'offerta alla pianificazione degli auditor, dalle registrazioni di sede/audit alla decisione e al ciclo del certificato.

Pagina della soluzione Vizyon Alia potete esaminare l'approccio a moduli tramite nella pagina dei servizi del software di certificazione potete vedere le opzioni di processo e integrazione. In fase di installazione, invece di copiare direttamente i moduli e le procedure esistenti, le regole di ambito, ruolo, decisione, versione e integrazione devono essere verificate insieme al reale funzionamento dell'organizzazione.

Prima della demo, preparare una richiesta resa anonima, un calcolo reale della durata dell'audit, una matrice delle competenze, un esempio di rilievo e uno scenario di revisione del certificato rende concreto il risultato. Quando pianificate l'analisi del processo con VizyonTech su questi cinque esempi si può costruire un flusso pilota end-to-end.

Domande frequenti