Il Suo Template dei dati per la gestione della qualità
Il Suo Template dei dati per la gestione della qualità
- Attributi consigliati per una raccolta completa dei dati
- Attività principali da monitorare per garantire la visibilità del processo
- Guida passo dopo passo all’estrazione dei dati da ETQ Reliance
Attributi della gestione della qualità
| Nome | Descrizione | ||
|---|---|---|---|
|
Evento di qualità
QualityEvent
|
L'identificativo univoco di un singolo evento di qualità, che collega tutte le attività correlate dall'identificazione alla chiusura. | ||
|
Descrizione
Quality Event è l'identificativo principale del caso per il processo di gestione della qualità. Rappresenta un singolo problema di qualità distinto, come una non conformità, un reclamo del cliente o una deviazione, mentre attraversa le fasi di indagine e risoluzione. Nell'analisi di Process Mining, questo attributo è essenziale per ricostruire il percorso end-to-end di ogni evento di qualità. Consente agli analisti di visualizzare le mappe di processo, misurare i tempi di ciclo dall'inizio alla fine e analizzare le varianti per comprendere come vengono gestiti i diversi eventi. Tutte le attività e i dati vengono raggruppati in base a questo identificativo, offrendo una visione completa del caso.
Perché è importante
È l'attributo fondamentale per il Process Mining, poiché collega tutte le fasi di processo correlate in un unico caso e consente l'analisi end-to-end del ciclo di vita della risoluzione del problema di qualità.
Dove reperirlo
È la chiave primaria del modulo principale Quality Event o Non-conformance in ETQ Reliance. Consulti la documentazione di ETQ Reliance per conoscere il nome specifico della tabella e del campo.
Esempi
QE-2023-00123NC-2023-0456CAPA-2023-7890
|
|||
|
Nome dell'attività
ActivityName
|
Il nome dell'attività o dell'evento specifico che si è verificato nel processo di gestione della qualità. | ||
|
Descrizione
Questo attributo descrive una singola fase o tappa del ciclo di vita dell'evento di qualità, come «Issue Categorized And Prioritized» o «Root Cause Analysis Performed». Ogni attività rappresenta un'azione distinta intrapresa per portare l'evento di qualità verso la risoluzione. L'analisi delle attività è il fulcro del Process Mining. Questo attributo viene utilizzato per costruire la mappa di processo, mostrando il flusso del lavoro. Consente di identificare colli di bottiglia, deviazioni dal processo standard e loop di rilavorazione, elementi fondamentali per il miglioramento dei processi.
Perché è importante
Definisce le fasi del processo, necessarie per visualizzare il flusso di processo, individuare i colli di bottiglia e analizzare le deviazioni.
Dove reperirlo
Queste informazioni derivano in genere dagli Event Log, dalle modifiche dello stato del Workflow o dagli audit trail all'interno dei moduli di ETQ Reliance.
Esempi
Indagine avviataRoot Cause Analysis eseguitaPiano di azioni correttive approvato
|
|||
|
Timestamp dell'evento
EventTimestamp
|
La data e l'ora precise in cui si è verificata una specifica attività. | ||
|
Descrizione
Il timestamp dell'evento indica il momento esatto in cui un'attività è stata registrata nel sistema. Ogni attività del ciclo di vita di un evento di qualità ha il proprio timestamp, creando una sequenza cronologica di eventi. Questo attributo è fondamentale per tutte le analisi basate sul tempo nel Process Mining. Viene utilizzato per calcolare i tempi di ciclo tra le attività, identificare i tempi di attesa e i colli di bottiglia e misurare la durata complessiva di un evento di qualità. Consente inoltre di analizzare l'andamento delle prestazioni nel tempo.
Perché è importante
Questo attributo è essenziale per calcolare le durate, ordinare cronologicamente gli eventi ed eseguire qualsiasi analisi basata sul tempo, come l'identificazione dei colli di bottiglia.
Dove reperirlo
Si trova in genere nelle tabelle degli audit trail oppure in un campo data «last modified» o «status change» associato a ogni attività o fase del Workflow in ETQ Reliance.
Esempi
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
|
|||
|
Categoria della causa principale
RootCauseCategory
|
La classificazione della causa principale identificata per l'evento di qualità. | ||
|
Descrizione
Dopo aver eseguito un'analisi della causa principale, la ragione alla base del problema viene spesso classificata. Tra gli esempi rientrano 'Guasto dell'apparecchiatura', 'Errore umano', 'Carenza del processo' o 'Problema del fornitore'. Questo attributo è essenziale per il Dashboard Root Cause Category Trends. Analizzando nel tempo la frequenza delle diverse categorie di cause principali, le organizzazioni possono individuare problemi sistemici e concentrare gli interventi di miglioramento sulle fonti più comuni dei problemi di qualità. Aiuta a passare dalla risoluzione reattiva dei problemi alla prevenzione proattiva.
Perché è importante
Consente di analizzare strategicamente i problemi ricorrenti, aiutando a individuare le criticità sistemiche e a stabilire le priorità per le azioni correttive e preventive a lungo termine.
Dove reperirlo
Si tratta generalmente di un campo compilato durante la fase Root Cause Analysis del Workflow in ETQ Reliance.
Esempi
Carenza del processoDifetto del materialeErrore umanoMalfunzionamento dell'apparecchiatura
|
|||
|
Eseguita da
ActionPerformedBy
|
L'utente o la risorsa che ha eseguito una specifica attività. | ||
|
Descrizione
Questo attributo identifica la persona o l'utente di sistema responsabile del completamento di un'attività nel ciclo di vita dell'evento di qualità. Collega le attività di processo alle persone o ai team che le eseguono. L'analisi delle prestazioni per utente aiuta a comprendere la distribuzione del carico di lavoro, a individuare le esigenze formative e a riconoscere le persone o i team con le migliori prestazioni. È inoltre essenziale ai fini della conformità e degli audit, poiché fornisce una registrazione chiara di chi ha eseguito ciascuna azione.
Perché è importante
Questo attributo consente di analizzare le prestazioni delle risorse, bilanciare il carico di lavoro e individuare opportunità di formazione.
Dove reperirlo
Queste informazioni sono generalmente archiviate nei log dell'audit trail o nei dettagli delle transazioni, spesso collegate a un campo con l'ID utente in ETQ Reliance.
Esempi
j.doeasmithqa_manager
|
|||
|
Esito della verifica
EffectivenessVerificationOutcome
|
Il risultato della verifica volta a stabilire se un'azione correttiva è stata efficace. | ||
|
Descrizione
Dopo l'implementazione di un'azione correttiva, viene spesso eseguita una verifica per confermare che l'azione abbia effettivamente risolto il problema. Questo attributo registra l'esito della verifica, generalmente come 'Efficace' o 'Non efficace'. Questo attributo è centrale per il Dashboard Corrective Action Effectiveness e per il KPI CAPA Effectiveness Verification Rate. Misura direttamente il successo del processo di risoluzione, aiutando a individuare i problemi ricorrenti e a migliorare la qualità dei piani di azione correttiva.
Perché è importante
Misura direttamente il successo delle azioni correttive, contribuendo a ridurre le rilavorazioni e a prevenire il ripetersi dei problemi di qualità.
Dove reperirlo
Sarebbe un campo nella sezione di verifica dell'efficacia del modulo CAPA o Quality Event in ETQ Reliance.
Esempi
EfficaceNon efficaceIn sospeso
|
|||
|
Livello di gravità
SeverityLevel
|
Una classificazione dell'impatto dell'evento di qualità, ad esempio critico, maggiore o minore. | ||
|
Descrizione
Il livello di gravità è una valutazione del potenziale impatto del problema di qualità sui clienti, sui prodotti o sulla conformità normativa. Viene utilizzato per stabilire le priorità delle risorse e determinare l'urgenza della risposta. Questo attributo è fondamentale per i Dashboard Issue Triage and Prioritization e High Severity Event Resolution. Consente di segmentare gli eventi di qualità per verificare se i problemi ad alta gravità vengono risolti più rapidamente rispetto a quelli a bassa gravità e aiuta ad assicurare che i problemi critici ricevano un'attenzione immediata.
Perché è importante
Consente di stabilire le priorità e segmentare i casi, assicurando che i problemi di qualità più critici vengano affrontati con il giusto livello di urgenza.
Dove reperirlo
È un campo standard nella maggior parte dei moduli di gestione della qualità di ETQ Reliance, spesso incluso nel modulo iniziale di registrazione del problema.
Esempi
CriticaMaggioreMinore
|
|||
|
Ora di fine dell'evento
EventEndTime
|
La data e l'ora in cui un'attività è stata completata, utilizzate per calcolarne il tempo di elaborazione. | ||
|
Descrizione
L'ora di fine dell'evento indica il completamento di un'attività. Insieme all'Event Timestamp (ora di inizio), definisce la durata di una singola fase del processo. Non tutti i sistemi registrano esplicitamente un'ora di fine per ogni evento; in questi casi, può essere ricavata dall'ora di inizio dell'evento successivo. Questo attributo è fondamentale per calcolare il tempo di elaborazione delle singole attività, distinto dal tempo di attesa tra un'attività e l'altra. Consente di individuare le attività che richiedono più tempo e di definire interventi mirati per rendere il processo più efficiente.
Perché è importante
Consente di calcolare il tempo di elaborazione delle singole attività, distinguendo il tempo di lavoro effettivo dal tempo di attesa.
Dove reperirlo
Alcuni moduli di ETQ Reliance possono registrare sia l'ora di inizio sia l'ora di fine per determinate attività. Se questo dato non è disponibile, può essere ricavato durante la preparazione dei dati.
Esempi
2023-10-26T11:30:00Z2023-10-27T15:00:10Z2023-11-05T10:00:00Z
|
|||
|
Reparto responsabile
ResponsibleDepartment
|
Il reparto o l'area funzionale responsabile dell'evento di qualità o di una specifica attività. | ||
|
Descrizione
Questo attributo indica l'unità organizzativa incaricata di gestire l'evento di qualità o di eseguire determinate fasi, ad esempio 'Quality Assurance', 'Engineering' o 'Production'. Può essere assegnato a livello di caso oppure cambiare quando il caso passa da un reparto all'altro. Questo attributo è fondamentale per il Dashboard Departmental Performance Analysis. Consente di filtrare e confrontare le prestazioni dei processi, ad esempio i tempi di ciclo e i volumi degli eventi, tra diversi reparti. Aiuta così a individuare i colli di bottiglia dei reparti, i vincoli sulle risorse o le aree di eccellenza.
Perché è importante
Consente di confrontare le prestazioni e analizzare i colli di bottiglia tra diverse unità aziendali, contribuendo a ottimizzare l'allocazione delle risorse.
Dove reperirlo
Si tratta generalmente di un campo del modulo principale dell'evento di qualità in ETQ Reliance, che indica il responsabile o il gruppo incaricato.
Esempi
Assicurazione della qualitàProduzioneRicerca e sviluppo
|
|||
|
Descrizione del problema
IssueDescription
|
Una descrizione in testo libero del problema di qualità individuato. | ||
|
Descrizione
Questo attributo contiene la descrizione dettagliata e narrativa del problema di qualità. Fornisce un contesto qualitativo che i campi strutturati non sono in grado di acquisire. Sebbene non venga generalmente utilizzata direttamente nella visualizzazione del flusso di processo, la descrizione del problema è preziosa per l'analisi dettagliata dei casi. Può inoltre essere utilizzata con tecniche di text mining per individuare temi ricorrenti o parole chiave associate a determinati tipi di deviazioni o ritardi di processo.
Perché è importante
Fornisce un contesto qualitativo essenziale per comprendere i dettagli di un evento di qualità ed è utile per l'analisi approfondita dei singoli casi.
Dove reperirlo
È generalmente una casella di testo standard o un campo memo nel modulo iniziale di segnalazione dell'evento di qualità in ETQ Reliance.
Esempi
Il componente XYZ non ha superato il test di resistenza presso la stazione 4.Il cliente ha segnalato un difetto estetico sul lotto 789.Sono state rilevate impostazioni di calibrazione errate sulla macchina A.
|
|||
|
Durata RCA
RootCauseAnalysisDuration
|
Il tempo necessario dall'avvio di un'indagine al completamento dell'analisi della causa principale. | ||
|
Descrizione
Questa metrica misura la durata di una fase specifica del processo di qualità. Viene calcolata come differenza temporale tra l'attività 'Indagine avviata' e l'attività 'Analisi della causa principale eseguita'. Questo attributo è essenziale per il KPI 'Average Root Cause Analysis Time' e per il Dashboard 'Root Cause Analysis Bottlenecks'. Aiuta a individuare i ritardi nella fase analitica del processo, che spesso contribuisce in modo significativo all'allungamento dei tempi di ciclo complessivi.
Perché è importante
Isola le prestazioni di un sottoprocesso critico, aiutando a individuare e affrontare i ritardi nell'analisi e nell'indagine del problema.
Dove reperirlo
Questo attributo non è presente nel sistema di origine. Viene calcolato durante la trasformazione dei dati determinando la differenza temporale tra i timestamp di attività specifiche.
Esempi
8640001209600432000
|
|||
|
È rilavorazione
IsRework
|
Un flag che indica se un'attività o una sequenza di attività rappresenta una rilavorazione. | ||
|
Descrizione
Questo attributo booleano viene derivato per identificare il verificarsi di un ciclo nel processo, ad esempio quando una verifica dell'efficacia non va a buon fine e avvia una nuova indagine, oppure quando un Corrective Action Plan viene rifiutato e restituito per la revisione. Segnala le attività che costituiscono la ripetizione di fasi precedenti. Questo attributo viene utilizzato per calcolare il KPI 'Rework Rate for Corrective Actions'. Evidenziare le rilavorazioni è fondamentale per comprendere le inefficienze del processo, poiché consumano risorse e prolungano i tempi di ciclo senza avvicinare il caso alla risoluzione.
Perché è importante
Quantifica l'inefficienza del processo segnalando il lavoro ripetuto, aiutando a individuarne le cause principali e a ridurre gli sprechi.
Dove reperirlo
Questo attributo non è presente nel sistema di origine. Viene calcolato in base alla sequenza delle attività all'interno di un caso durante la trasformazione dei dati.
Esempi
truefalse
|
|||
|
ID dell'azione preventiva
PreventiveActionId
|
Un identificativo univoco per ogni azione preventiva creata in risposta all'evento di qualità. | ||
|
Descrizione
Questo attributo collega un evento di qualità a una o più azioni preventive create per affrontare la causa principale e prevenire il ripetersi del problema in altre aree. Un singolo evento di qualità può generare più azioni preventive. Questo ID è importante per il Dashboard Preventive Action Management. Aiuta a monitorare il tasso di implementazione delle azioni preventive individuate e può essere utilizzato per identificare attività duplicate o ridondanti, assicurando che i miglioramenti proattivi siano gestiti in modo efficiente.
Perché è importante
Collega gli eventi di qualità reattivi alle iniziative di miglioramento proattive, consentendo di analizzare quanto efficacemente l'organizzazione prevenga problemi futuri.
Dove reperirlo
Sarebbe un record correlato o un campo nella sezione Preventive Action del modulo CAPA in ETQ Reliance.
Esempi
PA-2023-0088PA-2023-0089PA-2023-0090
|
|||
|
Normativa associata
AssociatedRegulationStandard
|
La normativa o lo standard di qualità specifico associato all'evento di qualità. | ||
|
Descrizione
Questo attributo collega un evento di qualità a uno specifico requisito normativo o standard di settore, come ISO 9001, FDA 21 CFR Part 820 o le policy aziendali interne. È particolarmente importante nei settori regolamentati. È l'attributo chiave per il Dashboard Quality Compliance Overview. Analizzare gli eventi in base allo standard associato aiuta a monitorare la conformità, individuare le aree in cui si verificano più frequentemente deviazioni e assicurare che tutti i requisiti normativi vengano soddisfatti tempestivamente.
Perché è importante
Consente di analizzare gli eventi di qualità nel contesto della conformità, contribuendo ad assicurare il rispetto di specifiche normative e standard di settore.
Dove reperirlo
Può essere un campo dedicato o un elenco selezionabile nel modulo dell'evento di qualità in ETQ Reliance, in particolare nei moduli orientati alla conformità.
Esempi
ISO 9001:201521 CFR Part 820IATF 16949
|
|||
|
Prodotto interessato
AffectedProduct
|
Il prodotto, il materiale o il componente oggetto dell'evento di qualità. | ||
|
Descrizione
Questo attributo identifica il prodotto specifico o il codice componente associato al problema di qualità. Collega i dati di processo ai dati anagrafici dei prodotti. Analizzare gli eventi di qualità per prodotto consente all'azienda di individuare eventuali prodotti con tassi più elevati di problemi di qualità, segnalando potenziali criticità di progettazione o produzione. Aiuta a concentrare gli interventi di miglioramento sui prodotti che ne hanno maggiore necessità.
Perché è importante
Collega il processo di qualità a prodotti specifici, consentendo di analizzare quali prodotti siano maggiormente soggetti a problemi.
Dove reperirlo
È generalmente un campo chiave nel modulo dell'evento di qualità, spesso collegato a una tabella dei dati anagrafici dei prodotti in ETQ Reliance o in un sistema ERP integrato.
Esempi
PROD-1001-APROD-2050-BRAW-MAT-55
|
|||
|
Sistema di origine
SourceSystem
|
Il sistema dal quale sono stati estratti i dati. | ||
|
Descrizione
Questo attributo identifica l'origine dei dati di gestione della qualità. In questa vista di processo, il valore sarà costante e indicherà che i dati provengono da ETQ Reliance. Sebbene possa non variare all'interno di un singolo dataset, questo attributo è fondamentale per la governance dei dati e negli scenari in cui vengono uniti dati provenienti da più sistemi. Garantisce chiarezza sulla provenienza dei dati e contribuisce a gestire le attività di integrazione.
Perché è importante
Fornisce un contesto essenziale sull'origine dei dati, importante per la governance, la convalida e l'integrazione con altri sistemi.
Dove reperirlo
In genere si tratta di un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati per identificarne la fonte.
Esempi
ETQ Reliance
|
|||
|
Stato CAP
CorrectiveActionPlanStatus
|
Lo stato del Corrective Action Plan, ad esempio Proposto, Approvato o Rifiutato. | ||
|
Descrizione
Questo attributo tiene traccia dello stato del Corrective Action Plan (CAP), una tappa fondamentale dell'evento di qualità complessivo. Indica se una soluzione proposta è stata esaminata e accettata. L'analisi di questo attributo può evidenziare i colli di bottiglia nel processo di approvazione. Un numero elevato di piani rifiutati o lunghi ritardi tra gli stati 'Proposto' e 'Approvato' possono indicare problemi nell'analisi della causa principale o un disallineamento tra gli stakeholder.
Perché è importante
Aiuta a individuare ritardi e inefficienze nel ciclo di approvazione delle azioni correttive, un collo di bottiglia frequente nella gestione della qualità.
Dove reperirlo
Sarebbe un campo di stato nella sezione o nel modulo Corrective and Preventive Action (CAPA) di ETQ Reliance.
Esempi
PropostaApprovataRifiutataImplementazione in sospeso
|
|||
|
Stato dell'evento di qualità
QualityEventStatus
|
Lo stato complessivo attuale dell'evento di qualità, ad esempio aperto, chiuso o annullato. | ||
|
Descrizione
Questo attributo fornisce una sintesi di alto livello della posizione dell'evento di qualità nel suo ciclo di vita. Indica se il caso è ancora in lavorazione, se è stato risolto con successo oppure se è stato annullato per qualche motivo. Nell'analisi di processo, viene utilizzato per filtrare i casi attivi e quelli completati. È fondamentale per calcolare il backlog degli eventi di qualità aperti e per assicurare che analisi come quella del tempo di ciclo vengano eseguite solo sui casi che hanno raggiunto uno stato finale definitivo.
Perché è importante
Consente di filtrare i casi aperti e chiusi, un'operazione essenziale per calcolare i backlog e analizzare con precisione i flussi di processo completati.
Dove reperirlo
È il campo di stato principale dell'oggetto evento di qualità in ETQ Reliance.
Esempi
ApertaChiusaAnnullataIn attesa di approvazione
|
|||
|
Stato SLA
SLAState
|
Indica se l'evento di qualità è entro i limiti, è a rischio di violazione o ha violato il proprio service level agreement (SLA) definito. | ||
|
Descrizione
Questo attributo è un campo calcolato che confronta il tempo di ciclo attuale o complessivo di un evento di qualità con obiettivi predefiniti. Ad esempio, per un problema critico potrebbe essere previsto uno SLA di risoluzione entro 15 giorni. Lo stato può essere 'In linea', 'A rischio' o 'Violato'. È prezioso per il Dashboard Quality Compliance Overview, poiché fornisce un indicatore visivo immediato della tempestività e della conformità. Aiuta i responsabili ad affrontare proattivamente gli eventi a rischio di mancato rispetto delle scadenze, invece di intervenire solo dopo la violazione.
Perché è importante
Fornisce una visione chiara e immediata delle prestazioni rispetto agli obiettivi di tempestività, consentendo di gestire proattivamente i casi a rischio di ritardo.
Dove reperirlo
Questo attributo viene calcolato durante la trasformazione dei dati confrontando il tempo trascorso di un caso con le regole aziendali relative agli SLA, che possono basarsi su attributi come il livello di gravità.
Esempi
In linea con il pianoA rischioViolata
|
|||
|
Tempo di ciclo dell'evento di qualità
QualityEventCycleTime
|
Il tempo totale trascorso dall'identificazione di un problema di qualità alla sua chiusura definitiva. | ||
|
Descrizione
È una metrica calcolata che rappresenta la durata end-to-end di un singolo evento di qualità. Viene calcolata determinando la differenza tra il timestamp della prima attività, ad esempio 'Problema di qualità identificato', e quello dell'ultima attività, ad esempio 'Evento di qualità chiuso'. Questo attributo supporta direttamente il KPI 'Average Quality Event Cycle Time' ed è una misura primaria dell'efficienza complessiva del processo. Viene utilizzato nei Dashboard per monitorare i risultati rispetto agli obiettivi di riduzione del tempo di ciclo e confrontare la durata tra diverse categorie di eventi.
Perché è importante
È un indicatore chiave di prestazione che misura l'efficienza complessiva del processo di gestione della qualità dall'inizio alla fine.
Dove reperirlo
Questo attributo non è direttamente disponibile in ETQ Reliance. Viene calcolato nello strumento di Process Mining o durante l'ETL, sottraendo il timestamp del primo evento da quello dell'ultimo evento per ciascun caso.
Esempi
25920006048008640000
|
|||
|
Ultimo aggiornamento dei dati
LastDataUpdate
|
Il timestamp che indica quando i dati del processo sono stati aggiornati l'ultima volta. | ||
|
Descrizione
Questo attributo registra la data e l'ora dell'estrazione più recente dei dati dal sistema di origine. È un campo di metadati che si applica all'intero dataset, non ai singoli eventi. In qualsiasi analisi di processo, comprendere l'aggiornamento dei dati è fondamentale. Questo attributo consente di sapere quanto siano attuali i dati utilizzati nell'analisi, assicurando che le decisioni si basino su informazioni aggiornate e permettendo di gestire le aspettative relative alla latenza dei dati.
Perché è importante
Indica l'aggiornamento dei dati, un elemento fondamentale per comprendere la tempestività dell'analisi e degli insight.
Dove reperirlo
Questo valore viene generato durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) e registra il timestamp di esecuzione del job.
Esempi
2024-05-20T08:00:00Z
|
|||
|
Unità aziendale
BusinessUnit
|
La divisione o unità aziendale più ampia in cui ha avuto origine l'evento di qualità. | ||
|
Descrizione
Questo attributo assegna l'evento di qualità a una specifica unità aziendale dell'organizzazione, come 'Elettronica di consumo' o 'Dispositivi medicali'. Fornisce un contesto organizzativo di livello più alto rispetto al reparto. Consente di confrontare ad alto livello le prestazioni tra diverse aree dell'azienda. Può aiutare il senior management a comprendere quali unità aziendali affrontino le criticità di qualità più rilevanti e ad allocare di conseguenza le risorse.
Perché è importante
Consente di confrontare ad alto livello le prestazioni dei processi di qualità tra diverse divisioni dell'azienda.
Dove reperirlo
Queste informazioni possono essere un campo del modulo dell'evento di qualità oppure essere ricavate da altri attributi, come il reparto responsabile o il prodotto.
Esempi
Dispositivi medicaliComponenti automobilisticiSoluzioni industriali
|
|||
Attività di gestione della qualità
| Attività | Descrizione | ||
|---|---|---|---|
|
Azione correttiva implementata
|
Rappresenta il completamento delle attività definite nel piano di azioni correttive approvato. Spesso viene registrato quando il responsabile dell'implementazione contrassegna come completati gli elementi di azione assegnati. | ||
|
Perché è importante
Misura la durata della fase di implementazione, che può evidenziare vincoli di risorse o difficoltà pratiche nell'esecuzione delle azioni correttive.
Dove reperirlo
Deducibile dalla data di completamento dell'ultima attività correttiva associata o da una modifica manuale dello stato a «Actions Implemented».
Acquisizione
Deducibile dalla data di completamento dell'ultima attività CAPA associata.
Tipo di evento
inferred
|
|||
|
Efficacia dell'azione verificata
|
Questa attività conferma che l'azione correttiva implementata ha risolto con successo la causa alla radice e ha impedito il ripetersi del problema. Si tratta di una fase formale di verifica, che spesso si svolge dopo un periodo di monitoraggio prestabilito. | ||
|
Perché è importante
È una fase critica per chiudere il ciclo della qualità ed è direttamente collegata ai KPI di efficacia delle CAPA. Garantisce che le soluzioni siano permanenti ed efficaci.
Dove reperirlo
Registrato nella data di completamento della fase o della sezione del modulo «Effectiveness Verification» nel Workflow. Spesso si tratta di un'attività distinta, con timestamp.
Acquisizione
Dalla data di completamento del modulo o dell'attività «Effectiveness Check».
Tipo di evento
inferred
|
|||
|
Evento di qualità chiuso
|
L'attività finale, che indica la risoluzione corretta e la chiusura amministrativa del record dell'evento di qualità. Rappresenta il principale punto finale del processo. | ||
|
Perché è importante
Definisce la fine del processo per il calcolo del tempo di ciclo complessivo. Analizzare gli eventi chiusi è fondamentale per misurare il throughput e le prestazioni complessive.
Dove reperirlo
Deducibile dal passaggio dello stato a «Closed» o «Completed» nel registro storico dell'evento, quasi sempre accompagnato da un timestamp.
Acquisizione
Deducibile dal timestamp del passaggio dello stato a «Closed».
Tipo di evento
inferred
|
|||
|
Indagine avviata
|
Segnala l'inizio formale della fase di indagine, finalizzata a determinare la causa alla radice del problema di qualità. In genere viene dedotto dal passaggio dello stato a «Under Investigation» o dall'assegnazione di un responsabile dell'indagine. | ||
|
Perché è importante
Questa attività rappresenta una tappa fondamentale, poiché avvia il conteggio del tempo della Root Cause Analysis. Aiuta a identificare i ritardi tra la valutazione del problema e l'avvio dell'indagine formale.
Dove reperirlo
Deducibile da un timestamp associato al passaggio dello stato a «Investigation» nel registro storico dell'evento oppure dalla data di assegnazione del ruolo di responsabile dell'indagine.
Acquisizione
Deducibile dal passaggio dello stato a «Under Investigation».
Tipo di evento
inferred
|
|||
|
Piano di azioni correttive approvato
|
Indica l'approvazione ufficiale del piano di azioni correttive proposto da parte dell'autorità designata, che consente di avviarne l'implementazione. In genere si tratta di un'azione di approvazione esplicita, con timestamp, all'interno del Workflow. | ||
|
Perché è importante
Si tratta di una tappa fondamentale e di un passaggio di approvazione critico. I ritardi in questa fase possono prolungare significativamente il tempo di ciclo complessivo della risoluzione.
Dove reperirlo
Registrato nel timestamp di approvazione della firma elettronica dell'evento o del registro storico del Workflow. ETQ Reliance utilizza ampiamente i Workflow di approvazione.
Acquisizione
Dal timestamp della fase di approvazione nella cronologia del Workflow.
Tipo di evento
explicit
|
|||
|
Problema di qualità identificato
|
Indica la creazione di un nuovo record di evento di qualità, che rappresenta il punto di avvio del processo. In genere viene registrato quando un utente invia un nuovo modulo per segnalare un problema di qualità in ETQ Reliance. | ||
|
Perché è importante
Stabilisce l'ora di inizio del caso, essenziale per calcolare il tempo di ciclo end-to-end e analizzare il tasso di arrivo dei nuovi eventi di qualità.
Dove reperirlo
In genere deriva dal timestamp di creazione del record dell'evento di qualità nella tabella principale Quality Event o nel relativo audit trail.
Acquisizione
Dal timestamp di creazione del record dell'evento di qualità.
Tipo di evento
explicit
|
|||
|
Root Cause Analysis eseguita
|
Rappresenta il completamento dell'indagine, durante il quale la causa alla radice, o le cause alla radice, sono state identificate e documentate. In genere questo evento viene registrato quando la sezione del modulo RCA viene completata e salvata. | ||
|
Perché è importante
Segna la conclusione della fase di indagine. La durata tra «Investigation Initiated» e questa attività è una metrica fondamentale per identificare i colli di bottiglia nel processo di analisi.
Dove reperirlo
Deducibile dalla data di compilazione del campo «Root Cause Category» o dal timestamp di completamento della fase RCA nel relativo audit trail.
Acquisizione
Deducibile dalla compilazione dei campi «Root Cause» o dal passaggio dello stato a «RCA Complete».
Tipo di evento
inferred
|
|||
|
Azione preventiva identificata
|
Rappresenta l'identificazione di un'azione preventiva (PA) finalizzata a eliminare la causa di potenziali non conformità. Può essere gestita come record separato, ma collegato all'evento di qualità originale. | ||
|
Perché è importante
È fondamentale per analizzare la proattività dell'organizzazione nella gestione della qualità e supporta la Dashboard «Preventive Action Management», monitorando il momento di avvio delle azioni preventive.
Dove reperirlo
Richiede un'analisi del sistema. Probabilmente deriva dalla data di creazione di un record di azione preventiva collegato al record dell'evento di qualità di origine.
Acquisizione
Dalla data di creazione di un record di azione preventiva collegato.
Tipo di evento
inferred
|
|||
|
Azione preventiva implementata
|
Indica il completamento delle attività associate a un'azione preventiva identificata, a conferma che le misure proattive sono state adottate. | ||
|
Perché è importante
Questa attività è fondamentale per misurare il KPI «Preventive Action Implementation Rate» e garantisce che i miglioramenti proattivi della qualità vengano effettivamente realizzati.
Dove reperirlo
Richiede un'analisi del sistema. Probabilmente viene dedotta dalla data di completamento del record di azione preventiva collegato o delle relative attività.
Acquisizione
Dalla data di completamento di un record di azione preventiva collegato.
Tipo di evento
inferred
|
|||
|
Evento di qualità annullato
|
Un punto finale alternativo, in cui l'evento di qualità viene terminato senza una risoluzione completa, ad esempio perché si tratta di un inserimento duplicato o non valido. | ||
|
Perché è importante
Aiuta a distinguere i casi risolti con successo da quelli terminati anticipatamente. Analizzare gli annullamenti può far emergere problemi nelle fasi iniziali di segnalazione e triage.
Dove reperirlo
Deducibile dal passaggio dello stato a «Canceled», «Void» o «Withdrawn» nel registro storico dell'evento.
Acquisizione
Deducibile dal timestamp del passaggio dello stato a «Canceled».
Tipo di evento
inferred
|
|||
|
Piano di azioni correttive proposto
|
Questa attività si verifica quando un piano formale per affrontare la causa alla radice viene documentato e sottoposto ad approvazione. Spesso viene registrata quando la sezione Corrective Action Plan del modulo è compilata e lo stato viene aggiornato. | ||
|
Perché è importante
Analizzare il tempo che intercorre dal completamento della RCA a questa fase aiuta a evidenziare i ritardi nella pianificazione delle misure correttive, un collo di bottiglia comune nei processi di qualità.
Dove reperirlo
Deducibile dal passaggio dello stato a «Pending CAPA Approval» o dal timestamp di invio del modulo del piano di azioni correttive all'interno del record dell'evento di qualità.
Acquisizione
Deducibile dal passaggio dello stato a «Pending Approval» o dalla data di invio del piano CAPA.
Tipo di evento
inferred
|
|||
|
Piano di azioni correttive rifiutato
|
Indica che il piano di azioni correttive proposto è stato esaminato e respinto, rendendo necessarie la revisione e una nuova presentazione. Questa attività crea un loop di rilavorazione nel processo. | ||
|
Perché è importante
Questa attività è fondamentale per identificare i loop di rilavorazione, comprendere le ragioni del rifiuto e misurare la percentuale di approvazione al primo passaggio del processo di pianificazione.
Dove reperirlo
Registrato nel timestamp del rifiuto nel registro storico del Workflow. Rappresenta l'azione contrapposta all'approvazione all'interno di un Workflow.
Acquisizione
Dal timestamp della fase di rifiuto nella cronologia del Workflow.
Tipo di evento
explicit
|
|||
|
Problema classificato e prioritizzato
|
Indica il momento in cui il problema è stato classificato per tipologia, gravità e priorità, elementi che spesso determinano il Workflow successivo. Viene registrato quando i campi relativi alla classificazione e alla priorità sono compilati e il record viene salvato. | ||
|
Perché è importante
Si tratta di un punto decisionale fondamentale. Analizzare il tempo necessario per arrivare a questa fase è essenziale per la Dashboard «Issue Triage and Prioritization» e per comprendere l'instradamento del processo.
Dove reperirlo
Deducibile dal timestamp in cui campi obbligatori come «Severity Level» e «Quality Event Type» vengono compilati per la prima volta, come registrato nell'audit trail del sistema.
Acquisizione
Deducibile dal timestamp della prima compilazione dei campi «Severity» o «Priority».
Tipo di evento
inferred
|
|||
|
Revisione finale eseguita
|
Controllo finale dell'intero record dell'evento di qualità per verificare che tutta la documentazione sia completa e che siano state seguite tutte le fasi procedurali prima della chiusura. Spesso si tratta di una fase di approvazione esplicita. | ||
|
Perché è importante
Rappresenta l'ultimo controllo qualità prima della conclusione del processo, garantendo Conformità e integrità dei dati. I colli di bottiglia in questa fase possono ritardare la chiusura definitiva.
Dove reperirlo
Registrato nel timestamp della fase di approvazione «Final Review» o «Ready for Closure» nella cronologia del Workflow.
Acquisizione
Dal timestamp della fase di approvazione «Final Review» nel Workflow.
Tipo di evento
explicit
|
|||
|
Stakeholder informati
|
Rappresenta l'azione di comunicare formalmente la risoluzione dell'evento di qualità agli stakeholder pertinenti. Può essere monitorata tramite una fase dedicata del Workflow o un record di comunicazione registrato. | ||
|
Perché è importante
È essenziale per misurare l'efficienza della comunicazione e supporta la Dashboard «Stakeholder Notification Timeliness». I ritardi in questa fase possono incidere sulla soddisfazione dei clienti.
Dove reperirlo
Richiede un'analisi del sistema, poiché spesso si tratta di una fase manuale. Può essere dedotta dal completamento di un'attività «Notify Stakeholders», se configurata.
Acquisizione
Deducibile dalla data di completamento di un'attività manuale «Notify Stakeholders».
Tipo di evento
inferred
|
|||
|
Valutazione iniziale eseguita
|
Rappresenta la revisione iniziale o il triage del problema di qualità appena identificato, finalizzato a raccogliere i fatti di base e determinarne la validità. Spesso viene dedotto quando viene completata una sezione del modulo di valutazione iniziale o quando lo stato passa da «New» a «Under Assessment». | ||
|
Perché è importante
Consente di analizzare l'efficienza del processo di triage iniziale e di misurare il tempo necessario per passare dalla segnalazione alla valutazione attiva del problema.
Dove reperirlo
Deducibile da una modifica dello stato, ad esempio da «New» a «Assessing», oppure dalla data di completamento di un'attività di valutazione iniziale nel Workflow dell'evento.
Acquisizione
Deducibile dal passaggio dello stato a «Under Assessment» o «In Triage».
Tipo di evento
inferred
|
|||
|
Verifica dell'efficacia non superata
|
Indica che l'azione correttiva implementata non ha risolto il problema, attivando spesso una nuova indagine o un nuovo ciclo CAPA. Questo evento segnala un grave malfunzionamento del processo e un loop di rilavorazione. | ||
|
Perché è importante
Mette in evidenza le soluzioni non riuscite e incide direttamente sui tassi e sui costi di rilavorazione. Analizzare questi casi è fondamentale per migliorare i processi di Root Cause Analysis e di pianificazione delle CAPA.
Dove reperirlo
Deducibile dal passaggio dello stato a «Effectiveness Check Failed» o dalla creazione di un evento di qualità successivo collegato a quello originale.
Acquisizione
Deducibile da un passaggio dello stato come «Verification Failed» o da un indicatore nel record della verifica.
Tipo di evento
inferred
|
|||
Guide all’estrazione
È pronto per iniziare?
Utilizzi questo Template per preparare in modo efficiente i dati sulla gestione della qualità e iniziare a individuare informazioni preziose sul processo. Il percorso verso operazioni ottimizzate inizia qui.
Ottimizzi subito la gestione della qualità: riduca il tempo di ciclo
Individui ed elimini i colli di bottiglia, puntando a ridurre il tempo di ciclo del 30%.
Non è richiesta alcuna carta di credito. La configurazione richiede pochi minuti.