Menu

Guida all'analisi delle cause alla radice: passaggi, tecniche ed esempi

  • Principale
  • Altro
  • Guida all'analisi delle cause alla radice: passaggi, tecniche ed esempi

guide root cause analysis steps

Prova Il Nostro Strumento Per Eliminare I Problemi

Questo tutorial spiega cos'è l'analisi delle cause principali e diverse tecniche di analisi delle cause principali come l'analisi a lisca di pesce e la tecnica dei 5 perché:

RCA (analisi delle cause alla radice) è un processo strutturato ed efficace per trovare la causa principale dei problemi in un team di progetto software. Se eseguito sistematicamente, può migliorare le prestazioni e la qualità dei risultati finali e dei processi, non solo a livello di team ma anche in tutta l'organizzazione.

Questo tutorial ti aiuterà a definire e semplificare il processo di analisi della causa principale nel tuo team o organizzazione.

Analisi delle cause alla radice

Questo tutorial è destinato a Delivery Manager, Scrum Master, Project Manager, Responsabili della qualità, Team di sviluppo, Team di test, Team di gestione delle informazioni, Team di qualità, Team di supporto, ecc. Per comprendere le basi dell'analisi delle cause alla radice e fornisce modelli ed esempi di esso .

Cosa imparerai:

Che cos'è l'analisi delle cause alla radice?

RCA (analisi delle cause alla radice) è un meccanismo di analisi dei Difetti, per identificarne la causa. Facciamo brainstorming, leggiamo e analizziamo il difetto per identificare se il difetto era dovuto a ' signorina di prova ',' sviluppo miss 'O era un' requisiti o progetti mancano '.

Quando l'RCA viene eseguito accuratamente, aiuta a prevenire i difetti nelle versioni o nelle fasi successive. Se troviamo, che un difetto era dovuto a signorina di design , possiamo rivedere i documenti di progettazione e prendere le misure appropriate. Allo stesso modo, se troviamo che un difetto era dovuto a signorina di prova , possiamo esaminare i nostri casi di test o le nostre metriche e aggiornarli di conseguenza.

RCA non dovrebbe limitarsi solo a testare i difetti. Possiamo fare RCA anche sui difetti di produzione. Sulla base della decisione di RCA, possiamo migliorare il nostro Banco di prova e includere tali ticket di produzione come casi di test di regressione. Ciò garantirà che il difetto o simili tipi di difetti non si ripetano.

Processo di analisi della causa principale

introduzione

RCA non viene utilizzato solo per i difetti segnalati dal sito di un cliente, ma anche per difetti UAT, difetti di Unit Testing, problemi a livello di processo aziendale e operativo, problemi della vita quotidiana, ecc. Quindi viene utilizzato in più settori come Settore software, produzione, sanità, settore bancario, ecc.

La conduzione dell'analisi delle cause alla radice è simile al lavoro del medico che cura un paziente. Il medico capirà prima i sintomi. Quindi farà riferimento a test di laboratorio per analizzare la causa principale della malattia.

Se la causa principale della malattia è ancora sconosciuta, il medico farà riferimento per i test di scansione per capire ulteriormente. Continuerà la diagnosi e lo studio fino a quando non si restringerà alla causa principale della malattia del paziente. La stessa logica si applica all'analisi delle cause alla radice eseguita in qualsiasi settore.

Quindi, RCA mira a trovare la causa principale e non a trattare il sintomo, seguendo una serie specifica di passaggi e strumenti associati. È diverso dall'analisi dei difetti, dalla risoluzione dei problemi e da altri metodi di risoluzione dei problemi poiché questi metodi cercano di trovare la soluzione per il problema specifico, ma RCA cerca di trovare la causa sottostante.

Origine del nome Analisi della causa principale:

Origine del nome Root Cause Analysis

(Immagine fonte )

Foglie, tronco e radici sono le parti più importanti di un albero. Le foglie (Sintomo) e il tronco (Problema) che sono al di sopra del suolo sono visibili, ma le radici (Causa) che sono sottoterra non sono visibili e le radici crescono più in profondità e possono diffondersi più di quanto ci aspettiamo. Quindi, il processo di scavare fino in fondo al problema è chiamato analisi delle cause alla radice.

Vantaggi dell'analisi delle cause alla radice

Di seguito sono elencati alcuni dei vantaggi, otterrai:

  • Prevenire il ripetersi dello stesso problema in futuro.
  • Alla fine, ridurre il numero di difetti segnalati nel tempo.
  • Riduce i costi di sviluppo e fa risparmiare tempo.
  • Migliora il processo di sviluppo del software e quindi aiuta la consegna rapida al mercato.
  • Migliora la soddisfazione del cliente.
  • Aumenta la produttività.
  • Trova problemi nascosti nel sistema.
  • Aiuta al miglioramento continuo.

Tipi di cause alla radice

# 1) Causa umana: Errore causato dall'uomo.

Esempi:

  • Sotto qualificato.
  • Istruzioni non debitamente seguite.
  • È stata eseguita un'operazione non necessaria.

# 2) Causa organizzativa: Un processo che le persone usano per prendere decisioni che non erano corrette.

Esempi:

  • Vaghe istruzioni sono state date dal Team Lead ai membri del team.
  • Scegliere la persona sbagliata per un'attività.
  • Strumenti di monitoraggio non in atto per valutare la qualità.

# 3) Causa fisica: Qualsiasi oggetto fisico ha fallito in qualche modo.

Esempi:

  • Il computer continua a riavviarsi.
  • Il server non si avvia.
  • Rumori strani o forti nel sistema.

Passaggi per eseguire l'analisi delle cause principali

Un approccio strutturato e logico è necessario per un'efficace analisi della causa principale. Quindi, è necessario seguire una serie di passaggi.

Passaggi per eseguire l

# 1) Forma il team RCA

Ogni squadra dovrebbe avere un dedicato Responsabile analisi delle cause principali (RCA Manager) che raccoglierà i dettagli dal team di supporto e avvierà il processo di avvio per RCA. Coordinerà e assegnerà le risorse che hanno bisogno di partecipare alle riunioni RCA a seconda del problema dichiarato.

I team, che partecipano alla riunione, dovrebbero disporre di personale di ciascun team (Requisiti, Progettazione, Test, Documentazione, Qualità, Supporto e Manutenzione) che abbia maggiore familiarità con il problema. Il team dovrebbe avere anche persone direttamente collegate al difetto. Per esempio, l'ingegnere del supporto che ha fornito una soluzione immediata al cliente.

Condividete i dettagli del problema con il team prima di partecipare alla riunione in modo che possano fare alcune analisi iniziali e venire preparati. I membri del team raccolgono anche informazioni relative al difetto. A seconda del rapporto sull'incidente, ogni squadra rintraccerà cosa è andato storto in questo scenario nelle rispettive fasi. Essere preparati aumenterà l'efficienza della discussione imminente.

# 2) Definisci il problema

Raccogli i dettagli del problema come, rapporti sugli incidenti, prove del problema (screenshot, registri, rapporti, ecc.), Quindi studia / analizza il problema ponendo le seguenti domande:

  • Qual è il problema?
  • Qual è la sequenza di eventi che ha portato al problema?
  • Quali sistemi sono stati coinvolti?
  • Da quanto tempo esisteva il problema?
  • Qual è l'impatto del problema?
  • Chi è stato coinvolto e determina chi dovrebbe essere intervistato?

Utilizza le regole 'SMART' per definire il tuo problema:

  • S PECIFIC
  • M FACILE
  • PER ORIENTATO ALL'AZIONE
  • R ELEVANT
  • T LEGATO AL NOME

Citazione di John Dewey

# 3) Identifica la causa principale

Conduci il BRAINSTORMING sessione all'interno del team RCA formato per identificare le cause. Usa il Diagramma a lisca di pesce o 5 Perché analisi metodo o entrambi per arrivare alla causa / e principale / e.

Il manager RCA dovrebbe moderare la riunione e stabilire le regole per la sessione di brainstorming. Ad esempio, le regole possono essere:

  1. Non dovrebbe essere consentito criticare / incolpare gli altri.
  2. Non giudicare le idee degli altri. Nessuna idea è cattiva, incoraggiano idee selvagge.
  3. Sviluppa le idee sugli altri. Pensa a come puoi costruire sulle idee degli altri e renderle migliori.
  4. Concedi a ciascun partecipante il tempo necessario per condividere le proprie opinioni.
  5. Incoraggia il pensiero fuori dagli schemi.
  6. Rimanere concentrati.

Tutte le idee dovrebbero essere registrate. Il responsabile RCA dovrebbe incaricare un membro di registrare i verbali della riunione e l'aggiornamento dei modelli RCA.

# 4) Implementare l'azione correttiva per la causa principale (RCCA)

L'azione correttiva consiste nel dare una soluzione alla soluzione identificando la vera causa principale. Per facilitare ciò, deve essere presente un responsabile delle consegne che può decidere in quali versioni deve essere implementata la correzione e quale dovrebbe essere la data di consegna.

L'RCA dovrebbe essere implementato in modo tale che questa causa principale non si ripresenti in futuro. La correzione fornita dal team di supporto sarà temporanea per il sito del cliente in cui viene segnalato il problema. Quando questa correzione viene fusa in una versione in corso, eseguire un'analisi dell'impatto adeguata per assicurarsi che nessuna funzionalità esistente venga interrotta.

Fornire i passaggi per convalidare la correzione e monitorare la soluzione implementata per verificare se la soluzione è efficace.

# 5) Implementare un'azione preventiva contro la causa principale (RCPA)

Il team deve elaborare un piano su come prevenire un problema simile in futuro. Per esempio, Aggiornare il manuale di istruzioni, migliorare le competenze, aggiornare l'elenco di controllo della valutazione del team, ecc. Seguire i documenti appropriati delle azioni preventive e monitorare se il team sta aderendo alle azioni preventive intraprese.

Si prega di fare riferimento a questo documento di ricerca su 'Analisi e prevenzione dei difetti per il miglioramento della qualità dei processi software' pubblicato in Giornale internazionale di ingegneria e applicazioni del software per avere un'idea delle tipologie di difetti segnalati in ogni fase del software e suggerire loro azioni preventive.

Le informazioni ottenute da RCA possono essere utilizzate come input Modalità di guasto e analisi degli effetti (FMEA ) per identificare i punti in cui la soluzione può fallire.

Strumento Analisi di Pareto con le cause identificate durante la RCA in un periodo, diciamo semestrale o trimestrale, che aiuterà a identificare le cause principali che contribuiscono ai difetti e si concentrerà sull'azione preventiva per loro.

Citazione di Duke Ellington

Tecniche di analisi della causa principale

# 1) Analisi a lisca di pesce

Il diagramma a lisca di pesce è uno strumento di analisi visiva delle cause alla radice per identificare le possibili cause dei problemi identificati e quindi è anche chiamato diagramma causa ed effetto. Ti consente di arrivare alla vera causa principale del problema piuttosto che risolverne il sintomo.

È anche chiamato diagramma di Ishikawa poiché è stato creato da Dr. Kaoru Ishikawa (uno statistico giapponese di controllo della qualità). È anche noto come diagramma a spina di pesce o Fishikawa.

L'analisi a lisca di pesce viene utilizzata nella fase di analisi di DMAIC di six sigma approccio per la risoluzione dei problemi. È uno dei 7 strumenti di base del controllo qualità .

Passaggi per creare un diagramma a lisca di pesce:

Il diagramma a lisca di pesce ricorda lo scheletro di un pesce con il problema che forma la testa del pesce e le cause che formano la colonna vertebrale e le ossa del pesce.

Segui i passaggi seguenti per creare un diagramma a lisca di pesce:

  1. Scrivi la problema al testa di pesce .
  2. Identifica il categoria di cause e scrivi a fine di ogni osso (causa categoria 1, causa categoria 2 …… causa categoria N)
  3. Identifica il cause primarie sotto ciascuna categoria e contrassegnarla come causa primaria 1, causa primaria 2, causa primaria N.
  4. Estendi le cause a secondario, terziario e più livelli a seconda del caso.

FIshbone_template

Un esempio di come un diagramma a lisca di pesce viene applicato a un difetto del software (vedi sotto).

FIshbone_softwareDefect

Sono disponibili molti strumenti gratuiti ea pagamento per creare un diagramma a lisca di pesce. Il diagramma Fishbone in questo tutorial è stato creato utilizzando ' Creativamente ' strumento online . Maggiori dettagli sui modelli e sugli strumenti a lisca di pesce verranno spiegati nel nostro prossimo tutorial.

# 2) La tecnica dei 5 perché

5 Perché Technique è stata sviluppata da Sakichi Toyoda ed è stato utilizzato da Toyota nella loro industria manifatturiera. Questa tecnica fa riferimento a una serie di domande in cui a ciascuna risposta viene risposto con una domanda Perché. Può essere correlato al modo in cui un bambino farà domande agli adulti. Sulla base della risposta data dagli adulti, faranno domande 'Perché' ancora e ancora finché non saranno soddisfatti.

5 Perché la tecnica viene utilizzata autonomamente o come parte dell'analisi a lisca di pesce per approfondire la causa principale del problema. Il numero di passaggi non è limitato a 5. Può essere inferiore o superiore a 5 finché non è arrivata la diagnosi del problema. 5 Perché sono una tecnica relativamente più semplice e un modo più rapido per arrivare alle cause profonde. Facilita la diagnosi rapida per escludere i sintomi e arrivare alla causa principale.

Il successo della tecnica dipende dalla conoscenza della persona. Possono esserci risposte diverse alla stessa domanda Perché. Quindi, selezionare la giusta direzione e concentrarsi nella riunione è importante.

Passaggi per creare il diagramma dei 5 perché

Inizia la discussione di brainstorming definendo il problema. Quindi seguire con i successivi Perché e le loro risposte.

5Why_Template

Un esempio di come il diagramma dei 5 perché viene applicato a un difetto del software:

5Why_Software_Defect Esempio

5 Perché il modello e le immagini vengono disegnati utilizzando il software Creately online.

Fattori che causano difetti

Ci sono molti fattori che provocano il verificarsi dei Difetti:

  • Requisiti poco chiari / mancanti / errati
  • Design errato
  • Codifica errata
  • Test insufficienti
  • Problemi ambientali (hardware, software o configurazioni)

Questi fattori dovrebbero sempre essere tenuti a mente durante l'esecuzione del processo RCA.

RCA inizia e procede con il brainstorming sul difetto. L'unica domanda che ci poniamo mentre facciamo RCA è 'PERCHÉ?' e cosa?' Possiamo scavare in ogni fase del ciclo di vita per tracciare, dove il difetto persiste.

Cominciamo con il 'PERCHÉ?' domande, (l'elenco non è limitato). Puoi iniziare dalla fase esterna e passare alla fase interna dell'SDLC.

come trovare la chiave di sicurezza di rete su Windows 10
  • “PERCHÉ” il difetto non è stato rilevato durante il test?
  • 'PERCHÉ' il difetto non è stato rilevato durante la revisione del caso di test?
  • “PERCHÉ” il difetto non è stato rilevato durante la “Design Review”?
  • “PERCHÉ” il Difetto non è stato rilevato durante la fase di Requisito?

La risposta a questa domanda ti darà la fase esatta in cui esiste il difetto. Ora, una volta identificata la fase e il motivo, arriva la parte 'COSA'.

“COSA farai per evitarlo in futuro?

La risposta a questa domanda 'COSA', se implementata e risolta, eviterà che lo stesso difetto o il tipo di difetto si ripresenti. Adottare misure adeguate per migliorare il processo identificato in modo che il difetto o il motivo del difetto non si ripeta.

Sulla base dei risultati di RCA, è possibile determinare quale delle fasi presenta aree problematiche.

Per esempio, se si determina la maggior parte dell'RCA dei difetti sono dovuti requisito perdere , quindi puoi migliorare la fase di raccolta / comprensione dei requisiti introducendo più revisioni o sessioni dettagliate.

Allo stesso modo, se trovi che la maggior parte dei difetti sono dovuti a signorina di prova , è necessario migliorare il processo di test. Puoi introdurre metriche come Metriche di tracciabilità dei requisiti , Verifica le metriche di copertura o puoi tenere sotto controllo il processo di revisione o qualsiasi altro passaggio che ritieni possa migliorare l'efficienza del test.

Conclusione

È responsabilità dell'intero team sedersi e analizzare i difetti e contribuire al miglioramento del prodotto e del processo.

In questo tutorial, hai una comprensione di base dell'RCA, i passaggi da seguire per eseguire un RCA efficiente e diversi strumenti da utilizzare come l'analisi Fishbone e 5 Why Technique. Nei prossimi tutorial, ci sarà una copertura su diversi modelli RCA, esempi e casi d'uso su come implementarli.

Lettura consigliata

^