Meny

Guide till analys av orsaker till orsaker - steg, tekniker och exempel

  • Huvud
  • Övrig
  • Guide till analys av orsaker till orsaker - steg, tekniker och exempel

guide root cause analysis steps

Prova Vårt Instrument För Att Eliminera Problem

Denna handledning förklarar vad som är analys av rotorsaker och olika tekniker för analys av orsaker som fiskbenanalys och 5 varför teknik:

RCA (Root Cause Analysis) är en strukturerad och effektiv process för att hitta grundorsaken till problem i ett Software Project-team. Om det utförs systematiskt kan det förbättra prestanda och kvalitet på leveranserna och processerna, inte bara på teamnivå utan också i hela organisationen.

Denna handledning hjälper dig att definiera och effektivisera analysprocessen för orsaken till ditt team eller din organisation.

Grundorsaksanalys

Denna handledning är avsedd för Delivery Managers, Scrum Masters, Project Managers, Quality Managers, Development Team, Test Team, Information Management Team, Quality Team, Support Team, etc. för att förstå grunderna i Root Cause Analysis och ger mallar och exempel på det. .

Vad du kommer att lära dig:

Vad är orsaksanalys?

RCA (Root Cause Analysis) är en mekanism för att analysera defekterna för att identifiera orsaken. Vi brainstormar, läser och gräver felet för att identifiera om felet beror på ” testa miss ',' utvecklingsfröken ”Eller var en” krav eller design missar ”.

När RCA görs exakt hjälper det till att förhindra defekter i senare utsläpp eller faser. Om vi ​​upptäcker att en defekt berodde på design miss kan vi granska designdokumenten och vidta lämpliga åtgärder. På samma sätt, om vi finner att en defekt berodde på testa miss kan vi granska våra testfall eller mätvärden och uppdatera det därefter.

RCA bör inte bara begränsas till att testa defekterna. Vi kan också göra RCA på produktionsfel. Baserat på beslutet från RCA kan vi förbättra vårt Testa sängen och inkludera dessa produktionsbiljetter som fall med regressionstest. Detta kommer att säkerställa att defekten eller liknande typer av defekter inte upprepas.

Process för analys av rotorsak

Introduktion

RCA används inte bara för defekter som rapporterats från en kundwebbplats, utan också för UAT-defekter, enhetstestfel, affärs- och operationella processnivåproblem, vardagliga livsproblem etc. Därför används den i flera branscher som Mjukvarusektor, tillverkning, hälsa, banksektor etc.

Genomförande av orsaken till analysen liknar arbetet hos den läkare som behandlar en patient. Läkaren först först symtomen. Sedan kommer han att hänvisa till laboratorietester för att analysera orsaken till sjukdomen.

Om orsaken till sjukdomen fortfarande är okänd, kommer läkaren att hänvisa till skanningstester för att förstå ytterligare. Han kommer att fortsätta diagnosen och studera tills han minskar till grundorsaken till patientens sjukdom. Samma logik gäller Root Cause Analysis som utförs i alla branscher.

Så RCA syftar till att hitta grundorsaken och inte behandla symptomet genom att följa en specifik uppsättning steg och tillhörande verktyg. Det skiljer sig från felanalys, felsökning och andra problemlösningsmetoder eftersom dessa metoder försöker hitta lösningen för den specifika frågan, men RCA försöker hitta den bakomliggande orsaken.

Ursprunget till namnet Root Cause Analysis:

Ursprunget till namnet Root Cause Analysis

(bild källa )

Löv, stam och rötter är de viktigaste delarna av ett träd. Löv (Symptom) och bagageutrymme (Problem) som ligger över marken är synliga, men rötter (Orsak) som är under marken är inte synliga och rötterna växer djupare och kan spridas längre än vi förväntar oss. Därför kallas processen för att gräva till botten av frågan Root Cause Analysis.

Fördelar med analys av rotorsaker

Nedan listas några av fördelarna du får:

  • Förhindra att samma problem återkommer i framtiden.
  • Så småningom kan du minska antalet rapporterade defekter över tiden.
  • Minskar utvecklingskostnader och sparar tid.
  • Förbättra mjukvaruutvecklingsprocessen och följaktligen snabb leverans till marknaden.
  • Förbättrar kundnöjdheten.
  • Öka produktiviteten.
  • Hitta dolda problem i systemet.
  • Hjälper till kontinuerlig förbättring.

Typer av orsaker

# 1) Människors orsak: Människans skapade fel.

Exempel:

  • Under skicklig.
  • Instruktioner som inte följs ordentligt.
  • Utförde en onödig operation.

# 2) Organisatorisk orsak: En process som människor använder för att fatta beslut som inte var korrekta.

Exempel:

  • Vaga instruktioner gavs från Team Lead till teammedlemmar.
  • Att välja fel person för en uppgift.
  • Övervakningsverktyg finns inte för att bedöma kvaliteten.

# 3) Fysisk orsak: Alla fysiska föremål misslyckades på något sätt.

Exempel:

  • Datorn fortsätter att starta om.
  • Servern startar inte upp.
  • Konstiga eller höga ljud i systemet.

Steg för att analysera orsaken

Ett strukturerat och logiskt tillvägagångssätt krävs för en effektiv rotorsaksanalys. Därför är det nödvändigt att följa en serie steg.

Steg för att göra Root Cause Analysis

# 1) Form RCA Team

Varje lag ska ha en dedikerad Root Cause Analysis Manager (RCA Manager) som kommer att samla in detaljer från supportteamet och initiera startprocessen för RCA. Han kommer att samordna och fördela resurser som behöver delta i RCA-möten beroende på det angivna problemet.

Lag som deltar i mötet bör ha personal från varje team (Krav, design, testning, dokumentation, kvalitet, support och underhåll) som är mest bekanta med problemet. Teamet bör också ha personer som är direkt kopplade till defekten. Till exempel, Supportingenjören som gav en omedelbar fix till kunden.

Dela problemuppgifterna med teamet innan de deltar i mötet så att de kan göra en första analys och komma förberedda. Teammedlemmar samlar också in information relaterad till defekten. Beroende på incidentrapporten kommer varje lag att spåra vad som gick fel w.r.t till detta scenario i sina respektive faser. Att vara beredd kommer att öka effektiviteten i den kommande diskussionen.

# 2) Definiera problemet

Samla in detaljerna om problemet som incidentrapporter, problembevis (skärmdump, loggar, rapporter etc.) och studera / analysera sedan problemet genom att ställa frågorna nedan:

  • Vad är problemet?
  • Vad är den händelseförlopp som ledde till problemet?
  • Vilka system var inblandade?
  • Hur länge fanns problemet?
  • Vilken är effekten av problemet?
  • Vem var inblandad och bestäm vem som skulle intervjuas?

Använd 'SMART' -regler för att definiera ditt problem:

  • S PECIFIK
  • M LÄTTBAR
  • TILL CTION-orienterad
  • R ELEVANT
  • T NAMNBUNDEN

John Dewey citat

# 3) Identifiera orsaken

Genomföra BRAINSTORMING session inom RCA-teamet som bildades för att identifiera orsakerna. Använd Fishbone diagram eller 5 Varför analys metod eller båda för att komma fram till grundorsaken.

RCA-chef bör moderera mötet och ställa in reglerna för Brainstorming-sessionen. Till exempel kan reglerna vara:

  1. Det bör inte tillåtas att kritisera / skylla på andra.
  2. Bedöm inte andras idéer. Inga idéer är dåliga, de uppmuntrar vilda idéer.
  3. Bygg vidare på idéerna om andra. Tänk på hur du kan bygga på andras idéer och göra det bättre.
  4. Ge varje deltagare rätt tid att dela sina åsikter.
  5. Uppmuntra out of box-tänkande.
  6. Vara fokuserad.

Alla idéer bör spelas in. RCA-chef ska tilldela en medlem att spela in protokollet från mötet och uppdatera RCA-mallar.

# 4) Implementera Root Cause Corrective Action (RCCA)

Korrigeringsåtgärd innebär att fixa lösningen genom att identifiera den verkliga orsaken. För att underlätta detta måste en leveranschef vara närvarande som kan bestämma i vilka versioner fixen ska implementeras och vad som ska vara leveransdatum.

RCCA bör implementeras på ett sådant sätt att denna grundorsak inte kommer att inträffa igen i framtiden. Fix som ges av supportteamet är tillfällig för kundwebbplatsen där problemet rapporteras. När den här korrigeringen slås samman till en pågående version gör du korrekt konsekvensanalys för att säkerställa att ingen befintlig funktion bryts.

Ge stegen för att validera fixen och övervaka den implementerade lösningen för att kontrollera om lösningen är effektiv.

# 5) Implementera rotorsaken förebyggande åtgärder (RCPA)

Teamet måste komma med en plan för hur en sådan liknande fråga kan förhindras i framtiden. Till exempel, Uppdatera bruksanvisningen, förbättra skicklighetsuppdateringen, uppdatera checklistan för teambedömning etc. Följ korrekta dokument om förebyggande åtgärder och övervak ​​om teamet följer de förebyggande åtgärder som vidtagits.

Se detta uppsats om 'Defektanalys och förebyggande för förbättring av mjukvaruprocessens kvalitet' som publicerades i International Journal of Software Engineering & Applications för att få en uppfattning om vilka typer av fel som rapporterats i varje programvarufas och föreslagna förebyggande åtgärder för dem.

Den information som erhållits från RCA kan användas som inmatning Felläge och effektanalys (FMEA ) för att identifiera punkter där lösningen kan misslyckas.

Genomföra Pareto-analys med de orsaker som identifierats under RCA under en period, säg halvårsvis eller kvartalsvis vilket hjälper till att identifiera de främsta orsakerna som bidrar till bristerna och fokuserar på förebyggande åtgärder för dem.

Duke Ellington citat

Root Cause Analysis Techniques

# 1) Fiskebenanalys

Fishbone diagram är ett visuellt verktyg för analys av rotorsaker för att identifiera möjliga orsaker till de identifierade problemen och därför kallas det också Cause and Effect diagram. Det låter dig komma ner till den verkliga grundorsaken till problemet snarare än att lösa dess symptom.

Det kallas också Ishikawa Diagram som det skapades av Dr. Kaoru Ishikawa (en japansk statistik för kvalitetskontroll). Det kallas även fiskbens- eller Fishikawa-diagram.

Fishbone-analys används i analysfasen av sex sigmas DMAIC metod för problemlösning. Det är en av de 7 grundläggande verktyg för kvalitetskontroll .

Steg för att skapa ett Fishbone Diagram:

Fishbone-diagram liknar en fisks skelett med problemet som bildar fiskhuvudet och orsakar att ryggraden och benen på fisken bildas.

Följ stegen nedan för att skapa ett fiskbendiagram:

  1. Skriv problem vid fiskens huvud .
  2. Identifiera orsakskategori och skriv på slutet av varje ben (orsakskategori 1, orsakskategori 2 …… orsakskategori N)
  3. Identifiera främsta orsakerna under varje kategori och markera den som primär orsak 1, primär orsak 2, primär orsak N.
  4. Utöka orsakerna till sekundära, tertiära och fler nivåer som tillämpligt.

FIshbone_template

Ett exempel på hur ett fiskbendiagram tillämpas på en programvarufel (se nedan).

FIshbone_softwareDefect

Det finns många gratis såväl som betalda verktyg för att skapa ett fiskbendiagram. Fishbone-diagrammet i denna handledning skapades med hjälp av ' Kreativt ' online-verktyg . Mer information om mallar och verktyg för fiskben kommer att förklaras i vår nästa handledning.

# 2) The 5 Whys-tekniken

5 Varför Teknik utvecklades av Sakichi Toyoda och användes hos Toyota i tillverkningsindustrin. Denna teknik hänvisar till en serie frågor där varje svar besvaras med en Why-fråga. Det kan relateras till hur ett barn ställer frågor till vuxna. Baserat på det svar som vuxna ger kommer de att ställa 'Varför' frågor om och om igen tills de är nöjda.

5 Varför teknik används fristående eller som en del av fiskebenanalys för att borra ner till orsaken till problemet. Antalet steg är inte begränsat till 5. Det kan vara mindre eller mer än 5 tills diagnosen av problemet har kommit. 5 Varför är relativt en enklare teknik och snabbare sätt att nå de grundläggande orsakerna. Det underlättar snabb diagnos för att utesluta symtomen och komma fram till grundorsaken.

Framgången för tekniken beror på personens kunskap. Det kan finnas olika svar på samma varför-fråga. Så det är viktigt att välja rätt riktning och fokus i mötet.

Steg för att skapa 5 Whys-diagram

Starta brainstorming-diskussionen genom att definiera problemet. Följ sedan med efterföljande varför och deras svar.

5Varför_mall

Ett exempel på hur 5 Whys-diagram tillämpas på en programvarufel:

5Why_Software_Defect Exempel

5 Varför mallar och bilder ritas med Creately online-programvara.

Faktorer som orsakar defekter

Det finns många faktorer som orsakar att defekterna uppstår:

  • Oklara / saknade / felaktiga krav
  • Felaktig design
  • Felaktig kodning
  • Otillräcklig testning
  • Miljöfrågor (hårdvara, programvara eller konfigurationer)

Dessa faktorer bör alltid hållas i åtanke när du utför RCA-processen.

RCA startar och fortsätter med brainstorming på defekten. Den enda frågan som vi ställer oss när vi gör RCA är 'VARFÖR?' och vad?' Vi kan gräva in i varje fas av livscykeln för att spåra, där defekten kvarstår.

Låt oss börja med 'VARFÖR?' frågor, (listan är inte begränsad). Du kan börja från den yttre fasen och gå mot den inre fasen av SDLC.

bästa wow-servern för nya spelare 2017
  • 'VARFÖR' bristades inte defekten under Sanity Test i produktion?
  • ”VARFÖR” upptäcktes inte felet under testningen?
  • “VARFÖR” upptäcktes inte felet under granskningen av testfallet?
  • ”VARFÖR” upptäcktes inte felet under ”Design Review”?
  • ”VARFÖR” upptäcktes inte felet under kravfasen?

Svaret på denna fråga kommer att ge dig den exakta fasen, där felet finns. När du väl har identifierat fasen och anledningen kommer 'VAD' -delen.

”VAD kommer du att göra för att undvika detta i framtiden?

Svaret på denna ”VAD” -fråga, om den implementeras och tas om hand, kommer att förhindra att samma defekt eller vilken typ av defekt uppstår igen. Vidta lämpliga åtgärder för att förbättra den identifierade processen så att defekten eller orsaken till defekten inte upprepas.

Baserat på resultaten från RCA kan du bestämma vilken av fasen som har problemområden.

Till exempel, om du bestämmer att de flesta av RCA-bristerna beror på krav miss , då kan du förbättra kravuppsamlings- / förståelsefasen genom att införa fler recensioner eller genomgångssessioner.

På samma sätt, om du upptäcker att de flesta brister beror på testa miss måste du förbättra testprocessen. Du kan införa mått som Krav Spårbarhetsmätvärden , Testtäckningsstatistik, eller kan hålla koll på granskningsprocessen eller något annat steg som du tycker skulle förbättra testningens effektivitet.

Slutsats

Det är hela teamets ansvar att sitta och analysera defekterna och bidra till produkt- och processförbättring.

I denna handledning har du en grundläggande förståelse för RCA, steg som ska följas för att göra en effektiv RCA och olika verktyg som ska användas, till exempel Fishbone-analys och 5 Why Technique. I de kommande självstudierna kommer det att täckas över olika RCA-mallar, exempel och användningsfall om hur man implementerar det.

Rekommenderad läsning

^