Meniu

Ghid pentru analiza cauzei rădăcină - pași, tehnici și exemple

  • Principal
  • Alte
  • Ghid pentru analiza cauzei rădăcină - pași, tehnici și exemple

guide root cause analysis steps

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Acest tutorial explică ce este analiza cauzei rădăcină și diferite tehnici de analiză a cauzei rădăcinii, cum ar fi analiza osului de pește și tehnica 5 de ce:

RCA (Analiza cauzei radiculare) este un proces structurat și eficient pentru a găsi cauza principală a problemelor într-o echipă de proiect software. Dacă este realizat sistematic, poate îmbunătăți performanța și calitatea livrabilelor și a proceselor, nu numai la nivel de echipă, ci și în întreaga organizație.

Acest tutorial vă va ajuta să definiți și să eficientizați procesul de analiză a cauzei rădăcină în echipa sau organizația dvs.

Analiza cauzelor fundamentale

Acest tutorial este destinat managerilor de livrare, masteratilor Scrum, managerilor de proiect, managerilor de calitate, echipei de dezvoltare, echipei de testare, echipei de gestionare a informațiilor, echipei de calitate, echipei de asistență etc., pentru a înțelege elementele de bază ale analizei cauzelor principale și oferă șabloane și exemple ale acesteia. .

Ce veți învăța:

Ce este analiza cauzei principale?

RCA (Analiza cauzei radiculare) este un mecanism de analiză a Defectelor, pentru a identifica cauza acestuia. Facem o brainstorming, citim și sapăm defectul pentru a identifica dacă defectul s-a datorat „ testare domnișoară ',' dezvoltare dor ”Sau a fost un„ cerință sau modele dor ”.

Când RCA se face cu precizie, ajută la prevenirea defectelor în versiunile sau fazele ulterioare. Dacă descoperim că un defect s-a datorat proiecta domnișoară , putem revizui documentele de proiectare și putem lua măsurile adecvate. În mod similar, dacă constatăm că un defect s-a datorat testare domnișoară , putem examina cazurile sau valorile noastre de testare și le putem actualiza în consecință.

RCA nu trebuie limitat doar la testarea defectelor. Putem face RCA și pentru defectele de producție. Pe baza deciziei RCA, ne putem îmbunătăți Pat de testare și include acele bilete de producție ca cazuri de test de regresie. Acest lucru va asigura că defectul sau tipuri similare de defecte nu se repetă.

Procesul de analiză a cauzei principale

Introducere

RCA nu este utilizat numai pentru defectele raportate de la un site al clientului, ci și pentru defectele UAT, defecte de testare a unității, probleme de afaceri și operaționale la nivel de proces, probleme de viață de zi cu zi, etc. Prin urmare, este utilizat în mai multe industrii, cum ar fi Sectorul software, sectorul producției, sănătatea, sectorul bancar etc.

Analiza cauzei rădăcinii este similară lucrării medicului care tratează un pacient. Medicul va înțelege mai întâi simptomele. Apoi se va referi la testele de laborator pentru a analiza cauza principală a bolii.

Dacă cauza principală a bolii este încă necunoscută, medicul se va referi la testele de scanare pentru a înțelege mai departe. El va continua diagnosticul și studia până se va reduce la cauza principală a bolii pacientului. Aceeași logică se aplică și analizei cauzelor principale efectuate în orice industrie.

Deci, RCA are ca scop găsirea cauzei principale și nu tratarea simptomului, urmând un set specific de pași și instrumente asociate. Este diferit de analiza defectelor, depanarea și alte metode de rezolvare a problemelor, deoarece aceste metode încearcă să găsească soluția pentru problema specifică, dar RCA încearcă să găsească cauza care stă la baza acesteia.

Originea numelui Analiza cauzei principale:

Originea numelui Analiza cauzei rădăcină

(imagine sursă )

Frunzele, trunchiul și rădăcinile sunt cele mai importante părți ale unui copac. Frunzele (Simptom) și trunchiul (Problema) care sunt deasupra solului sunt vizibile, dar rădăcinile (Cauza) care sunt sub pământ nu sunt vizibile și rădăcinile cresc mai adânc și se pot răspândi mai mult decât ne așteptăm. Prin urmare, procesul de săpare în partea de jos a problemei se numește Analiza cauzei rădăcină.

Avantajele analizei cauzelor principale

Enumerate mai jos sunt câteva dintre beneficii, veți obține:

  • Preveniți reapariția aceleiași probleme în viitor.
  • În cele din urmă, reduceți numărul de defecte raportate în timp.
  • Reduce costurile de dezvoltare și economisește timp.
  • Îmbunătățiți procesul de dezvoltare software și, prin urmare, ajutați la livrarea rapidă pe piață.
  • Îmbunătățește satisfacția clienților.
  • Sporiți productivitatea.
  • Găsiți probleme ascunse în sistem.
  • Ajută la îmbunătățirea continuă.

Tipuri de cauze principale

# 1) Cauza umană: Eroare provocată de om.

Exemple:

  • Sub priceput.
  • Instrucțiuni care nu sunt respectate în mod corespunzător.
  • A efectuat o operație inutilă.

# 2) Cauza organizațională: Un proces pe care oamenii îl folosesc pentru a lua decizii care nu au fost adecvate.

Exemple:

  • Au fost date instrucțiuni vagi de la conducătorul echipei către membrii echipei.
  • Alegerea persoanei nepotrivite pentru o sarcină.
  • Instrumentele de monitorizare nu sunt în vigoare pentru a evalua calitatea.

# 3) Cauza fizică: Orice articol fizic a eșuat într-un fel.

Exemple:

  • Calculatorul continuă să repornească.
  • Serverul nu pornește.
  • Zgomote ciudate sau puternice în sistem.

Pași pentru analiza cauzei rădăcină

Este necesară o abordare structurată și logică pentru o analiză eficientă a cauzei rădăcină. Prin urmare, este necesar să urmați o serie de pași.

Pași pentru a face analiza cauzei rădăcină

# 1) Formați echipa RCA

Fiecare echipă ar trebui să aibă un dedicat Manager analiză cauză rădăcină (Manager RCA) cine va colecta detaliile de la echipa de asistență și va iniția procesul de lansare pentru RCA. El va coordona și aloca resursele care trebuie să participe la ședințele RCA, în funcție de problema menționată.

Echipele, care participă la ședință, ar trebui să aibă personal din fiecare echipă (Cerință, Proiectare, Testare, Documentare, Calitate, Suport și Întreținere) care sunt cei mai familiarizați cu problema. Echipa ar trebui să aibă oameni care au legături directe cu defectul. De exemplu, inginerul de asistență care a dat o soluție imediată clientului.

Împărtășiți detaliile problemei cu echipa înainte de a participa la ședință, astfel încât să poată face o analiză inițială și să vină pregătiți. Membrii echipei adună, de asemenea, informații legate de defect. În funcție de raportul incidentului, fiecare echipă va urmări ce a greșit w.r.t la acest scenariu în fazele lor respective. Pregătirea va spori eficiența discuției viitoare.

# 2) Definiți problema

Colectați detaliile problemei, cum ar fi, rapoarte de incidente, dovezi ale problemei (captură de ecran, jurnale, rapoarte etc.), apoi studiați / analizați problema punând întrebările de mai jos:

  • Care este problema?
  • Care este succesiunea evenimentelor care au dus la problemă?
  • Ce sisteme erau implicate?
  • Cât timp a existat problema?
  • Care este impactul problemei?
  • Cine a fost implicat și a stabilit cine ar trebui să fie intervievat?

Utilizați regulile „SMART” pentru a vă defini problema:

  • S PECIFIC
  • M UȘOR
  • LA ORIENTAT LA CION
  • R ELEVANT
  • T NUME-LIGAT

Citatul lui John Dewey

# 3) Identificați cauza principală

Efectuați BRAINSTORMING sesiune în cadrul echipei RCA formată pentru identificarea cauzelor. Folosește Diagrama osului de pește sau 5 De ce Analiză metoda sau ambele pentru a ajunge la cauza / cauzele principale.

Managerul RCA ar trebui să modereze întâlnirea și să stabilească regulile pentru sesiunea de brainstorming. De exemplu, regulile pot fi:

  1. Nu trebuie permisă criticarea / învinovățirea celorlalți.
  2. Nu judeca ideile altora. Nici o idee nu este rea, încurajează ideile sălbatice.
  3. Construiți pe ideile celorlalți. Gândiți-vă la modul în care vă puteți baza pe ideile altora și să le îmbunătățiți.
  4. Acordați fiecărui participant timpul necesar pentru a-și împărtăși opiniile.
  5. Încurajați gândirea din cutie.
  6. Rămâi concentrat.

Toate ideile ar trebui înregistrate. Managerul RCA ar trebui să desemneze un membru pentru a înregistra procesele-verbale ale ședinței și actualizarea șabloanelor RCA.

# 4) Implementați acțiunea corectivă pentru cauza principală (RCCA)

Acțiunea de corectare implică soluționarea soluției prin identificarea cauzei reale reale. Pentru a facilita acest lucru, trebuie să fie prezent un manager de livrare care poate decide în ce versiuni trebuie să fie implementată soluția și care ar trebui să fie data livrării.

RCCA ar trebui implementat în așa fel încât această cauză rădăcină să nu mai apară în viitor. Corecția dată de echipa de asistență va fi temporară pentru site-ul clientului unde este raportată problema. Când această soluție este îmbinată într-o versiune în desfășurare, efectuați o analiză de impact adecvată pentru a vă asigura că nici o caracteristică existentă nu este defectă.

Dați pașii pentru validarea remedierii și monitorizați soluția implementată pentru a verifica dacă soluția este eficientă.

# 5) Implementați acțiunea preventivă a cauzei principale (RCPA)

Echipa trebuie să elaboreze un plan pentru modul în care o astfel de problemă similară poate fi prevenită în viitor. De exemplu, Actualizați manualul de instrucțiuni, îmbunătățiți setul de competențe, actualizați lista de verificare a evaluării echipei etc. Urmați documentele corespunzătoare ale acțiunilor preventive și monitorizați dacă echipa respectă acțiunile preventive întreprinse.

Vă rugăm să consultați acest lucru lucrare de cercetare pe „Analiza și prevenirea defectelor pentru îmbunătățirea calității proceselor software” publicat în International Journal of Software Engineering & Applications pentru a vă face o idee despre tipurile de defecte raportate în fiecare fază software și a sugerat acțiuni preventive pentru acestea.

Informațiile obținute din RCA pot fi introduse ca date de intrare Modul de eșec și analiza efectului (FMEA ) pentru a identifica punctele în care soluția poate eșua.

Implementați Analiza Pareto cu cauzele identificate în timpul RCA pe o perioadă, să spunem semestrial sau trimestrial, ceea ce va ajuta la identificarea principalelor cauze care contribuie la defecte și să se concentreze asupra acțiunii preventive pentru acestea.

Citatul Duke Ellington

Tehnici de analiză a cauzei principale

# 1) Analiza osului de pește

Diagrama Fishbone este un instrument vizual de analiză a cauzelor principale pentru identificarea cauzelor posibile ale problemelor identificate și, prin urmare, se numește și diagramă Cauză și efect. Vă permite să ajungeți la adevărata cauză principală a problemei, mai degrabă decât să rezolvați simptomul acesteia.

Se mai numește și Diagrama Ishikawa așa cum a fost creată de Dr. Kaoru Ishikawa (un statistician japonez de control al calității). Este, de asemenea, cunoscut sub numele de Herringbone sau diagrama Fishikawa.

Analiza osului de pește este utilizată în faza de analiză a DMAIC de șase sigme abordare pentru rezolvarea problemelor. Este unul dintre 7 instrumente de bază pentru controlul calității .

Pași pentru crearea unei diagrame Fishbone:

Diagrama osului de pește seamănă cu scheletul unui pește cu problema formării capului de pește și cauzează formarea coloanei vertebrale și a oaselor peștilor.

Urmați pașii de mai jos pentru a crea o diagramă a osului de pește:

  1. Scrie problemă la cap de pește .
  2. Identificați categoria cauzelor și scrie la capătul fiecărui os (categoria de cauză 1, categoria de cauză 2 …… categoria de cauză N)
  3. Identificați cauzele primare sub fiecare categorie și marcați-o ca cauză primară 1, cauză primară 2, cauză primară N.
  4. Extindeți cauzele la secundar, terțiar și mai multe niveluri după caz.

FIshbone_template

Un exemplu al modului în care o diagramă a osului de pește este aplicată unui defect de software (vezi mai jos).

FIshbone_softwareDefect

Există o mulțime de instrumente gratuite și plătite disponibile pentru crearea unei diagrame de pește. Diagrama Fishbone din acest tutorial a fost creată folosind „ Creately ' instrument online . Mai multe detalii despre șabloanele și instrumentele pentru osul de pește vor fi explicate în următorul nostru tutorial.

# 2) Tehnica celor 5 de ce

5 De ce tehnica a fost dezvoltată de Sakichi Toyoda și a fost folosit la Toyota în industria lor de fabricație. Această tehnică se referă la o serie de întrebări la care fiecare răspuns este răspuns cu o întrebare De ce. Poate fi legat de modul în care un copil va pune întrebări adulților. Pe baza răspunsului oferit de adulți, ei vor pune întrebări „De ce” din nou și din nou până când vor fi mulțumiți.

5 De ce se folosește tehnica independentă sau ca parte a analizei osului de pește pentru a explora cauza principală a problemei. Numărul de pași nu este limitat la 5. Poate fi mai mic sau mai mare de 5 până la diagnosticarea problemei. 5 De ce sunt relativ o tehnică mai simplă și o modalitate mai rapidă de a ajunge la cauzele principale. Facilitează diagnosticul rapid pentru a exclude simptomele și pentru a ajunge la cauza principală.

Succesul tehnicii depinde de cunoașterea persoanei. Pot exista răspunsuri diferite la aceeași întrebare De ce. Așadar, este important să selectați direcția corectă și să vă concentrați.

Pași pentru a crea o diagramă de 5 de ce

Începeți discuția de brainstorming definind problema. Apoi urmați cu De ce ulterior și răspunsurile lor.

5De ce_sablon

Un exemplu despre modul în care diagrama 5 De ce este aplicată unui defect de software:

Exemplu 5De ce_Software_Defect

5 De ce sunt desenate șabloanele și imaginile utilizând software-ul online Creately.

Factori care cauzează defecte

Există mulți factori care provoacă apariția defectelor:

  • Cerințe neclare / lipsă / incorecte
  • Proiectare incorectă
  • Codare incorectă
  • Testare insuficientă
  • Probleme de mediu (hardware, software sau configurații)

Acești factori ar trebui să fie întotdeauna luați în considerare în timpul efectuării procesului RCA.

RCA începe și continuă cu brainstorming-ul asupra defectului. Singura întrebare pe care ne-o punem în timp ce facem RCA este „DE CE?” si ce?' Putem săpa în fiecare fază a ciclului de viață pentru a urmări, unde defectul persistă.

Să începem cu „DE CE?” întrebări (lista nu este limitată). Puteți începe de la faza exterioară și vă puteți deplasa spre faza interioară a SDLC.

câte gazde utilizabile sunt disponibile având o adresă IP de clasă c cu masca implicită de subrețea?
  • „DE CE” Defectul nu a fost surprins în timpul testării?
  • „DE CE” Defectul nu a fost surprins în timpul examinării cazului Test?
  • „DE CE” Defectul nu a fost surprins în timpul „Design Review”?
  • „DE CE” Defectul nu a fost surprins în faza Cerințelor?

Răspunsul la această întrebare vă va oferi faza exactă, în care există defectul. Acum, odată ce identificați faza și motivul, vine partea „CE”.

„Ce veți face pentru a evita acest lucru în viitor?

Răspunsul la această întrebare „CE”, dacă este implementat și îngrijit, va împiedica să apară din nou același defect sau tipul de defect. Luați măsuri adecvate pentru a îmbunătăți procesul identificat, astfel încât defectul sau motivul defectului să nu se repete.

Pe baza rezultatelor RCA, puteți determina care dintre faze are zone cu probleme.

De exemplu, dacă determinați că majoritatea RCA a defectelor se datorează cerință domnișoară , atunci puteți îmbunătăți faza de colectare / înțelegere a cerințelor prin introducerea mai multor recenzii sau sesiuni de parcurgere.

În mod similar, dacă constatați că majoritatea defectelor se datorează testare domnișoară , trebuie să îmbunătățiți procesul de testare. Puteți introduce valori cum ar fi Valori de trasabilitate a cerințelor , Măsurători de acoperire a testului sau puteți ține o verificare a procesului de revizuire sau a oricărui alt pas care credeți că ar îmbunătăți eficiența testării.

Concluzie

Este responsabilitatea întregii echipe să stea și să analizeze defectele și să contribuie la îmbunătățirea produsului și a procesului.

În acest tutorial, aveți o înțelegere de bază a RCA, pașii care trebuie urmați pentru realizarea unui RCA eficient și diferite instrumente care trebuie utilizate, cum ar fi analiza Fishbone și 5 De ce tehnică. În tutorialele viitoare, vor fi prezentate diferite șabloane RCA, exemple și cazuri de utilizare cu privire la modul de implementare a acestuia.

Lectură recomandată

^