Menu

Gids voor analyse van hoofdoorzaken - Stappen, technieken en voorbeelden

  • Hoofd
  • Andere
  • Gids voor analyse van hoofdoorzaken - Stappen, technieken en voorbeelden

guide root cause analysis steps

Probeer Ons Instrument Voor Het Oplossen Van Problemen

In deze tutorial wordt uitgelegd wat de analyse van de oorzaak is en verschillende technieken voor de analyse van de oorzaak, zoals visgraatanalyse en de 5 waarom-techniek:

RCA (Root Cause Analysis) is een gestructureerd en effectief proces om de hoofdoorzaak van problemen in een softwareprojectteam te vinden. Als het systematisch wordt uitgevoerd, kan het de prestaties en kwaliteit van de te leveren producten en processen verbeteren, niet alleen op teamniveau maar ook in de hele organisatie.

Deze tutorial helpt je bij het definiëren en stroomlijnen van het Root Cause Analysis-proces in je team of organisatie.

Oorzaakanalyse

Deze tutorial is bedoeld voor Delivery Managers, Scrum Masters, Project Managers, Quality Managers, Development Team, Test Team, Information Management Team, Quality Team, Support Team, etc. om de basisprincipes van Root Cause Analysis te begrijpen en biedt sjablonen en voorbeelden hiervan .

Wat je leert:

Wat is een analyse van de oorzaak?

RCA (Root Cause Analysis) is een mechanisme om de defecten te analyseren, om de oorzaak ervan te identificeren. We brainstormen, lezen en graven het defect om vast te stellen of het defect te wijten was aan ' testen missen ​ ontwikkeling missen 'Of was een' vereiste of ontwerpen missen ​

Wanneer RCA nauwkeurig wordt uitgevoerd, helpt het defecten in de latere releases of fasen te voorkomen. Als we ontdekken dat een defect te wijten was aan ontwerp missen kunnen we de ontwerpdocumenten beoordelen en passende maatregelen nemen. Evenzo, als we ontdekken dat een defect te wijten was aan testen missen kunnen we onze testcases of statistieken bekijken en deze dienovereenkomstig bijwerken.

RCA moet niet beperkt blijven tot het testen van defecten. We kunnen ook RCA doen op productiefouten. Op basis van de beslissing van RCA kunnen we onze Proefbank en neem die productiekaarten op als regressietestgevallen. Dit zorgt ervoor dat het defect of soortgelijke defecten niet worden herhaald.

Oorzaak analyseproces

Invoering

RCA wordt niet alleen gebruikt voor defecten die worden gemeld vanaf de locatie van een klant, maar ook voor UAT-defecten, defecten bij het testen van eenheden, problemen op zakelijk en operationeel procesniveau, dagelijkse problemen, enz. Daarom wordt het gebruikt in meerdere industrieën zoals Softwaresector, productie, gezondheidszorg, banksector, enz.

Het uitvoeren van een Root Cause Analysis is vergelijkbaar met het werk van de arts die een patiënt behandelt. De arts zal eerst de symptomen begrijpen. Vervolgens zal hij naar laboratoriumtests verwijzen om de oorzaak van de ziekte te analyseren.

Als de oorzaak van de ziekte nog steeds onbekend is, zal de arts scantests doorverwijzen om er meer inzicht in te krijgen. Hij zal doorgaan met de diagnose en het onderzoek totdat hij zich beperkt tot de oorzaak van de ziekte van de patiënt. Dezelfde logica is van toepassing op Root Cause Analysis die in elke branche wordt uitgevoerd.

RCA is dus gericht op het vinden van de hoofdoorzaak en het niet behandelen van het symptoom, door een specifieke reeks stappen en bijbehorende hulpmiddelen te volgen. Het verschilt van defectanalyse, probleemoplossing en andere probleemoplossende methoden, aangezien deze methoden proberen de oplossing voor het specifieke probleem te vinden, maar RCA probeert de onderliggende oorzaak te vinden.

Oorsprong van de naam Root Cause Analysis:

Oorsprong van de naam Root Cause Analysis

(beeld bron ​

Bladeren, stam en wortels zijn de belangrijkste onderdelen van een boom. Bladeren (Symptoom) en stam (Probleem) die boven de grond zijn, zijn zichtbaar, maar wortels (Oorzaak) die onder de grond zijn, zijn niet zichtbaar en wortels groeien dieper en kunnen zich verder verspreiden dan we verwachten. Daarom wordt het proces van naar de bodem van het probleem graven, Root Cause Analysis genoemd.

Voordelen van oorzaakanalyse

Hieronder vindt u enkele van de voordelen die u krijgt:

  • Voorkom dat hetzelfde probleem zich in de toekomst opnieuw voordoet.
  • Verminder uiteindelijk het aantal defecten dat in de loop van de tijd wordt gemeld.
  • Verlaagt ontwikkelingskosten en bespaart tijd.
  • Verbeter het softwareontwikkelingsproces en help zo een snelle levering op de markt.
  • Verbetert de klanttevredenheid.
  • Verhoog de productiviteit.
  • Zoek verborgen problemen in het systeem.
  • Helpt bij continue verbetering.

Soorten hoofdoorzaken

# 1) Menselijke oorzaak: Door mensen gemaakte fout.

Voorbeelden:

  • Onder geschoold.
  • Instructies niet naar behoren opgevolgd.
  • Heeft een onnodige handeling uitgevoerd.

# 2) Organisatorische oorzaak: Een proces dat mensen gebruiken om beslissingen te nemen die niet juist waren.

Voorbeelden:

  • Teamlead gaf vage instructies aan teamleden.
  • De verkeerde persoon kiezen voor een taak.
  • Monitoring tools niet aanwezig om de kwaliteit te beoordelen.

# 3) Fysieke oorzaak: Elk fysiek item is op de een of andere manier mislukt.

Voorbeelden:

  • De computer blijft opnieuw opstarten.
  • De server start niet op.
  • Vreemde of harde geluiden in het systeem.

Stappen om een ​​hoofdoorzaakanalyse uit te voeren

Voor een effectieve oorzaakanalyse is een gestructureerde en logische aanpak vereist. Daarom is het noodzakelijk om een ​​reeks stappen te volgen.

Stappen om een ​​hoofdoorzaakanalyse uit te voeren

# 1) Vorm RCA-team

Elk team zou een toegewijde moeten hebben Hoofdoorzaakanalysebeheerder (RCA Manager) die de details van het ondersteuningsteam zal verzamelen en het startproces voor RCA zal starten. Hij coördineert en wijst middelen toe die RCA-vergaderingen moeten bijwonen, afhankelijk van het vermelde probleem.

Teams die de vergadering bijwonen, moeten personeel van elk team (vereiste, ontwerp, testen, documentatie, kwaliteit, ondersteuning en onderhoud) hebben dat het meest vertrouwd is met het probleem. Het team moet ook mensen hebben die direct met het defect te maken hebben. Bijvoorbeeld, de ondersteuningsingenieur die de klant een onmiddellijke oplossing gaf.

Deel de probleemdetails met het team voordat u de vergadering bijwoont, zodat ze een eerste analyse kunnen uitvoeren en voorbereid kunnen zijn. Teamleden verzamelen ook informatie met betrekking tot het defect. Afhankelijk van het incidentrapport zal elk team in hun respectievelijke fasen traceren wat er mis is gegaan met dit scenario. Voorbereid zijn zal de efficiëntie van de komende discussie vergroten.

# 2) Definieer het probleem

Verzamel de details van het probleem, zoals incidentrapporten, bewijsmateriaal (screenshot, logboeken, rapporten, enz.), En bestudeer / analyseer het probleem door de onderstaande vragen te stellen:

  • Wat is het probleem?
  • Wat is de opeenvolging van gebeurtenissen die tot het probleem hebben geleid?
  • Welke systemen waren erbij betrokken?
  • Hoe lang bestond het probleem?
  • Wat is de impact van het probleem?
  • Wie was erbij betrokken en bepaalt wie er geïnterviewd moet worden?

Gebruik ‘SMART’ regels om uw probleem te definiëren:

  • S PECIFIC
  • M. GEMAKKELIJK
  • NAAR CTIE-GERICHT
  • R ELEVANT
  • T NAAM-GEBONDEN

John Dewey citaat

# 3) Identificeer de hoofdoorzaak

Voer het BRAINSTORMING sessie binnen het RCA-team dat is gevormd om de oorzaken te identificeren. Gebruik de Visgraat diagram of 5 Waarom analyse methode of beide om tot de hoofdoorzaak / oorzaken te komen.

De RCA-manager moet de vergadering leiden en de regels voor de brainstormsessie bepalen. De regels kunnen bijvoorbeeld zijn:

  1. Het bekritiseren / beschuldigen van anderen mag niet worden toegestaan.
  2. Beoordeel andermans ideeën niet. Geen enkel idee is slecht, ze moedigen wilde ideeën aan.
  3. Bouw voort op de ideeën van anderen. Bedenk hoe u kunt voortbouwen op de ideeën van anderen en deze kunt verbeteren.
  4. Geef elke deelnemer de tijd om zijn mening te geven.
  5. Moedig out-of-box-denken aan.
  6. Blijf gefocust.

Alle ideeën moeten worden vastgelegd. De RCA-manager moet een lid toewijzen om de notulen van de vergadering op te nemen en de RCA-sjablonen bij te werken.

# 4) Implementeer corrigerende actie voor de hoofdoorzaak (RCCA)

Correctiemaatregelen omvatten het oplossen van de oplossing door de echte hoofdoorzaak te identificeren. Om dit mogelijk te maken moet er een bezorgmanager aanwezig zijn die kan beslissen in welke versies de fix geïmplementeerd moet worden en wat de opleverdatum moet zijn.

RCCA moet zo worden geïmplementeerd dat deze grondoorzaak in de toekomst niet meer voorkomt. De oplossing die door het ondersteuningsteam wordt gegeven, is tijdelijk voor de klantsite waar het probleem wordt gerapporteerd. Wanneer deze fix wordt samengevoegd in een lopende versie, voer dan een goede impactanalyse uit om er zeker van te zijn dat er geen bestaande functie wordt verbroken.

Geef de stappen om de fix te valideren en controleer de geïmplementeerde oplossing om te controleren of de oplossing effectief is.

# 5) Implementeer preventieve actie voor hoofdoorzaken (RCPA)

Het team moet een plan bedenken hoe een dergelijk probleem in de toekomst kan worden voorkomen. Bijvoorbeeld, Werk de instructiehandleiding bij, verbeter de vaardigheden, werk de checklist voor teambeoordeling bij, enz. Volg de juiste documenten van preventieve maatregelen en controleer of het team zich houdt aan de genomen preventieve maatregelen.

Gelieve hiernaar te verwijzen onderzoekspaper over 'Defect Analysis and Prevention for Software Process Quality Improvement' gepubliceerd in het International Journal of Software Engineering & Applications om een ​​idee te krijgen van de soorten defecten die in elke softwarefase worden gerapporteerd en om preventieve maatregelen te nemen.

De informatie die met RCA wordt verkregen, kan als invoer worden gebruikt Storingsmodus en effectanalyse (FMEA ) om punten te identificeren waar de oplossing kan mislukken.

Implementeren Pareto-analyse met de oorzaken die tijdens RCA zijn geïdentificeerd over een periode, bijvoorbeeld halfjaarlijks of driemaandelijks, wat zal helpen om de belangrijkste oorzaken te identificeren die bijdragen aan de defecten en zich te concentreren op preventieve maatregelen voor hen.

Duke Ellington citaat

Technieken voor analyse van hoofdoorzaken

# 1) Visgraatanalyse

Fishbone-diagram is een visuele analyse-tool voor de hoofdoorzaak om de mogelijke oorzaken van de geïdentificeerde problemen te identificeren en wordt daarom ook het Oorzaak-en-gevolgdiagram genoemd. Hiermee kunt u de echte oorzaak van het probleem achterhalen in plaats van het symptoom ervan op te lossen.

Het wordt ook wel het Ishikawa-diagram genoemd zoals het is gemaakt door Dr. Kaoru Ishikawa (een Japanse statisticus voor kwaliteitscontrole). Het is ook bekend als Herringbone- of Fishikawa-diagram.

Visgraatanalyse wordt gebruikt in de analysefase van six sigma's DMAIC aanpak voor probleemoplossing. Het is een van de 7 basisinstrumenten voor kwaliteitscontrole ​

Stappen om een ​​visgraatdiagram te maken:

Visgraatdiagram lijkt op het skelet van een vis met het probleem om de kop van de vis te vormen en veroorzaakt de vorming van de ruggengraat en de botten van de vis.

Volg de onderstaande stappen om een ​​visgraatdiagram te maken:

  1. Schrijf de probleem bij de kop van de vis ​
  2. Identificeer de categorie van oorzaken en schrijf op uiteinde van elk bot (oorzaak categorie 1, oorzaak categorie 2 …… oorzaak categorie N)
  3. Identificeer de primaire oorzaken onder elke categorie en markeer deze als primaire oorzaak 1, primaire oorzaak 2, primaire oorzaak N.
  4. Breid de oorzaken uit naar secundair, tertiair en meer niveaus zoals van toepassing.

FIshbone_template

Een voorbeeld van hoe een visgraatdiagram wordt toegepast op een softwarefout (zie hieronder).

FIshbone_softwareDefect

Er zijn veel gratis en betaalde tools beschikbaar voor het maken van een visgraatdiagram. Het Fishbone-diagram in deze tutorial is gemaakt met ‘ Creatief ' online tool ​ Meer details over visgraatsjablonen en -hulpmiddelen zullen in onze volgende tutorial worden uitgelegd.

# 2) De 5 waarom-techniek

5 Waarom techniek is ontwikkeld door Sakichi Toyoda en werd bij Toyota gebruikt in hun maakindustrie. Deze techniek verwijst naar een reeks vragen waarbij elk antwoord wordt beantwoord met een waarom-vraag. Het kan te maken hebben met hoe een kind vragen stelt aan volwassenen. Op basis van het antwoord dat volwassenen geven, zullen ze keer op keer 'waarom'-vragen stellen totdat ze tevreden zijn.

5 Waarom de techniek op zichzelf staand wordt gebruikt of als onderdeel van visgraatanalyse om de oorzaak van het probleem te achterhalen. Het aantal stappen is niet beperkt tot 5. Het kan minder of meer zijn dan 5 totdat de diagnose van het probleem is gearriveerd. 5 Waarom is een relatief eenvoudigere techniek en een snellere manier om tot de grondoorzaken te komen. Het vergemakkelijkt een snelle diagnose om de symptomen uit te sluiten en tot de oorzaak te komen.

Het succes van de techniek hangt af van de kennis van de persoon. Er kunnen verschillende antwoorden zijn op dezelfde waarom-vraag. Het is dus belangrijk om de juiste richting en focus in de vergadering te kiezen.

Stappen om een ​​5 Whys-diagram te maken

Start de brainstormdiscussie door het probleem te definiëren. Volg daarna met het daaropvolgende Waarom en hun antwoorden.

5Why_Template

Een voorbeeld van hoe het 5 Whys-diagram wordt toegepast op een softwarefout:

5Why_Software_Defect Voorbeeld

5 Waarom sjablonen en afbeeldingen worden getekend met Creately online software.

Factoren die defecten veroorzaken

Er zijn veel factoren die ervoor zorgen dat de gebreken optreden:

  • Onduidelijke / ontbrekende / onjuiste vereisten
  • Onjuist ontwerp
  • Onjuiste codering
  • Onvoldoende testen
  • Omgevingsproblemen (hardware, software of configuraties)

Deze factoren moeten altijd in gedachten worden gehouden tijdens het uitvoeren van het RCA-proces.

RCA begint en gaat verder met brainstormen over het defect. De enige vraag die we onszelf stellen tijdens het doen van RCA is 'WAAROM?' en wat?' We kunnen in elke fase van de levenscyclus graven om bij te houden waar het defect aanhoudt.

Laten we beginnen met het 'WAAROM?' vragen, (de lijst is niet beperkt). U kunt beginnen vanuit de buitenste fase en naar de binnenste fase van SDLC gaan.

hoe client server applicatie te testen
  • 'WAAROM' het defect niet werd opgemerkt tijdens de Sanity Test in de maak?
  • 'WAAROM' het defect niet werd opgemerkt tijdens het testen?
  • 'WAAROM' het defect niet werd opgemerkt tijdens de beoordeling van de testcase?
  • 'WAAROM' het defect niet werd opgemerkt tijdens 'Design Review'?
  • 'WAAROM' het defect niet werd opgemerkt tijdens de vereiste fase?

Het antwoord op deze vraag geeft u de exacte fase waarin het defect bestaat. Als je nu eenmaal de fase en de reden hebt geïdentificeerd, komt het 'WAT' -gedeelte.

“WAT ga je doen om dit in de toekomst te voorkomen?

Het antwoord op deze 'WAT' -vraag zal, indien geïmplementeerd en aangepakt, voorkomen dat hetzelfde defect of hetzelfde soort defect zich opnieuw voordoet. Neem de juiste maatregelen om het geïdentificeerde proces te verbeteren, zodat het defect of de reden voor het defect niet wordt herhaald.

Op basis van de resultaten van RCA kunt u bepalen welke van de fase probleemgebieden heeft.

Bijvoorbeeld, als u vaststelt dat de meeste RCA van de defecten te wijten zijn aan vereiste missen , dan kunt u de fase van het verzamelen / begrijpen van vereisten verbeteren door meer beoordelingen of doorloopsessies te introduceren.

Evenzo, als u merkt dat de meeste defecten te wijten zijn aan testen missen , moet u het testproces verbeteren. U kunt statistieken introduceren zoals Metrieken voor traceerbaarheid van vereisten , Testdekkingsstatistieken, of kan het beoordelingsproces of een andere stap in de gaten houden waarvan u denkt dat deze de efficiëntie van het testen zou verbeteren.

Gevolgtrekking

Het is de verantwoordelijkheid van het hele team om de defecten te analyseren en bij te dragen aan de product- en procesverbetering.

In deze tutorial heb je een basiskennis van RCA, de stappen die je moet volgen om een ​​efficiënte RCA uit te voeren en verschillende tools die je kunt gebruiken, zoals Fishbone-analyse en 5 Why Technique. In de komende tutorials zal er aandacht zijn voor verschillende RCA-sjablonen, voorbeelden en use cases voor het implementeren ervan.

Aanbevolen literatuur

^