Vores naturlige reaktion, når vi ser ”en fejl” – noget, der afviger fra, hvad vi forventer – er at drage forhastede konklusioner. Hvis sagsbehandlingssystemet kører langsomt, eller hvis en maskine fremstiller defekte enheder, tænker vi noget i stil med: ”Det må være fordi…” og griber straks til handling for at løse problemet – men er det nødvendigvis den bedste måde at løse problemet på?
Inden for IT-verdenen beskæftiger vi os med (og skelner mellem) Incidents, dvs. fejl, og Problems. Begrebet Incident betyder en ”ikke planlagt afbrydelse eller reduktion i kvaliteten af en service”1, og er altså et udtryk for en ændring i tilstanden af en service – eller for den sags skyld et produkt – der medfører en hel eller delvis forringelse af kvaliteten, og som ikke er planlagt. (Planlagte ændringer betragtes ikke i sig selv som fejl.) Målet vil normalt i første omgang være at hjælpe kunden eller brugeren videre med sit arbejde. Det kan sammenlignes med, hvad man lærer på et førstehjælpskursus: Stands ulykken! Opdager vi en fejl, søger vi i første omgang at begrænse omfanget af skaden og undgå yderligere forværring. Når det er overstået, og kunden er hjulpet videre, kommer havarikommissionen efterfølgende og afdækker den grundlæggende årsag til fejlen med henblik på at sikre mod gentagelse.
Disse principper om afhjælpning af fejl og udbedring af underliggende problemer finder anvendelse i alle sammenhænge, uanset branche eller erhverv – men hvordan kan vi blive bedre til at finde og afhjælpe årsagen til problemer, så vi undgår, at de opstår igen? Dette spørgsmål stillede to amerikanske sociologer Charles Kepner og Benjamin Tregoe, sig selv i 1950’erne. De undrede sig over, at nogle virksomheder tilsyneladende var bedre end andre til på effektiv vis at fjerne problemer, og de begyndte at undersøge, hvad der adskilte disse virksomheder fra dem, der var knapt så effektive.

Mønstergenkendelse

Den første fejl vi begår, er at følge vores menneskelige natur og basere vores tilgang til en problemstilling på antagelser. Belært af tidligere erfaringer tror vi, at vi umiddelbart kan udpege årsagen til en hændelse, hvis den ligner noget, vi har set før. Årsagen kan dog meget vel vise sig at være en ganske anden, om end symptomet lader til at være det samme. Hvad skal vi gøre i stedet? Gå struktureret til værks og tage hensyn til alle fakta, for kun sådan kan vi finde den egentlige årsag.
En vigtig egenskab her er evnen til at kunne genkende mønstre. Hvad nu, hvis vi i det ovennævnte eksempel forestillede os, at sagsbehandlingssystemet altid kører langsomt lige omkring frokost, eller hvis maskinen altid fremstiller defekte enheder mandag morgen? Kunne det give os anledning til at tro, at der kunne være en anden, dybereliggende årsag til problemet?

Objekt og afvigelse

Teknikken, der er blevet kendt som Kepner-Tregoe-metoden, omfatter følgende aktiviteter:

  1. Beskriv problemet.
  2. Specificér problemet.
  3. Opstil mulige årsager (hypoteser), der kan forklare problemet.
  4. Afprøv de mulige årsager mod det beskrevne problem.
  5. Fastslå den mest sandsynlige årsag.
  6. Bekræft, observer, eksperimentér eller afprøv løsningen og overvåg dens fremdrift.

Hvis det ud fra denne fremgangsmåde ikke er muligt at identificere en gyldig årsag til problemet, har vi måske ikke tilstrækkeligt med information, så vi må tydeliggøre beskrivelsen af problemet. Når vi har en fyldestgørende problembeskrivelse, er næste skridt at specificere problemet ud fra følgende fire dimensioner:

  1. Hvad er afvigelsen, og hvilket objekt har afvigelsen?
  2. Hvor på objektet og i processen ses afvigelsen?
  3. Hvornår opstår afvigelsen?
  4. Hvad er omfanget af afvigelsen?

Næste skridt er at opstille al den information, der gør sig gældende (hvad fejlen ER, hvor fejlen ER osv.), kontra hvad der ikke gør (hvad/hvor fejlen IKKE ER men KUNNE VÆRE; se skema på næste side). Lad os forsøge med et praktisk eksempel2: Et oliefilter i en maskine lader til at være utæt, og maskinen spilder olie ud på fabriksgulvet. Fejlen ses kun på maskine nr. 1, der står tættere på en pumpe end de øvrige maskiner. Antagelsen er derfor i første omgang, at maskine nr. 1 er udsat for flere rystelser. ”Det må være fordi…” Alt bliver skilt ad og efterspændt. Dagen efter er der mere olie på gulvet. En medarbejder tænker tilbage på en tidligere hændelse, hvor filteret ikke er blevet strammet med et bestemt stykke værktøj. ”Det må være fordi…”, udbryder han, og værktøjet bliver fundet frem. Den tredje dag er der endnu mere olie på gulvet, og fabrikschefen begynder at interessere sig for problemet og forlanger handling. Ved nærmere eftersyn viser det sig, at en pakning i maskine nr. 1 er anderledes end i de øvrige maskiner. Der er indkøbt en ny model, som er en smule billigere. Straks pakningen bliver erstattet med den gamle udgave, ophører oliespildet.
Hvad gik galt i fejlsøgningen? Den første dag drager en medarbejder en forhastet konklusion og efterspænder alle dele i filteret. Det løser ikke problemet. På anden-dagen gør en medarbejder den antagelse, at fejlen er magen til en tidligere situation. Heller ikke dette løser problemet. Først da man går mere struktureret til værks og undersøger, hvordan maskine nr. 1 adskiller sig fra de øvrige, finder man årsagen til problemet. Moralen i historien, som i så mange andre af den slags scenarier, er, at man kunne have fundet årsagen til fejlen med det samme og derved undgået flere dages produktionsstop, ressourcespild, risiko for arbejdsskader som følge af oliespild på gulvet og så videre.
Kan man ikke identificere årsagen til fejlen ud fra svar på spørgsmålene inden for de fire dimensioner, er næste skridt at undersøge, hvorledes det påvirkede objekt adskiller sig fra de øvrige. Endelig må man spørge, hvad der er foretaget af ændringer omkring det påvirkede objekt, som kan have forårsaget fejlen.

Et eksempel fra det virkelige liv

Et konkret eksempel fra IT-branchen stammer fra en finansiel virksomhed, som oplevede, at et sagsbehandlingssystem var begyndt at ”gå i stå”. Medarbejderne kunne ikke forstå hvorfor, men kunne hver gang selv afhjælpe symptomet ved at lukke applikationen ned og starte den op igen. Det eneste generende var, at man mistede arbejdet på den sag, man var i gang med, men hvis man blot huskede at gemme hyppigt, var det ikke så slemt endda. Da fejlen havde stået på i et par måneder, begyndte ledelsen at interessere sig for problemet. Ved en mere struktureret fejlsøgning opdagede den ansvarlige for sagsbehandlingssystemet, at fejlen opstod hver dag på nogenlunde samme tidspunkt, nemlig når de enkelte medarbejdere vendte tilbage fra frokost. Hvis en medarbejder ikke gik til frokost, sås symptomet ikke.
Her var altså tale om en fejl, der ramte sagsbehandlingssystemet, men ikke øvrige applikationer. Symptomet påvirkede alle medarbejdere på nogenlunde samme tidspunkt – men ikke nødvendigvis hver dag, ikke på nøjagtigt samme tidspunkt for alle, og ikke på nøjagtigt samme tidspunkt hver dag. Fejlen opstod, når medarbejderen gik til frokost, men ikke, hvis medarbejdere sprang frokosten over. Fejlen opstod som regel, når medarbejderen var midt i behandlingen af en sag, men ikke i nogen bestemte funktioner eller handlinger. Eftersom fejlen havde stået på i nogen tid, kunne ingen længere huske, nøjagtigt hvornår fejlen opstod første gang.
En nærmere undersøgelse viste, at sammenhængen med frokostpausen var, at fejlen opstod ved længere tids inaktivitet. Hypotesen var altså, at hvis man ikke arbejdede i sagsbehandlingssystemet i et stykke tid, kunne man ikke efterfølgende komme videre med sit arbejde. Hypotesen blev efterprøvet ved at lade systemet være inaktivt i kortere og længere intervaller på andre tidspunkter end omkring frokost. Resultatet var det samme; efter omtrent en halv times inaktivitet var det ikke længere muligt at fortsætte arbejdet uden først at genstarte applikationen. Yderligere undersøgelser ledte frem til årsagen. Efter nogen tids inaktivitet mistede brugergrænsefladen i applikationen forbindelsen til den underliggende database. Den simple afhjælpning af problemet var en instruks til medarbejderne om at huske at lukke applikationen, inden de gik til frokost eller til andre aktiviteter end sagsbehandling.
Læringen af denne situation er den samme som i eksemplet med oliefilteret; hvis man fra begyndelsen var gået mere struktureret til værks og havde stillet spørgsmålene: ”Hvad er det, og hvad er det ikke?” og ”Hvornår opstår fejlen, og hvornår opstår den ikke?” og så videre, havde man kunnet afhjælpe fejlen i løbet af nogle timer frem for adskillige måneder med frustration, forringet ydeevne, lavere medarbejdereffektivitet, risiko for fejl i sagsbehandlingen og unødvendige udgifter til fejlsøgning med hjælp fra IT-personale og konsulenter.
Som Gandhi engang skal have sagt: ”Alle problemer kunne have været løst, mens de endnu var små.”

1 Oversat fra engelsk fra ITIL® Service Operation, 2011 Edition, Norwich: The Stationery Office.
2 Eksemplet stammer fra bogen The New Rational Manager af Charles Kepner og Benjamin Tregoe, Princeton, NJ: Princeton Research Press, 1965.

Dimension Specificering ER ER IKKE Afvigelse Ændring
Hvad Hvilket objekt har afvigelsen? Maskine nr. 1 lækker olie.

Maskine nr. 2 – 6 (de øvrige).

Hvordan adskiller maskine nr. 1 sig fra de øvrige?
Hvor Hvor på objektet er afvigelsen? Hvor er objektet i processen, når afvigelsen opstår?

Olien lækker fra filteret.
Olien lækker kun, når maskinen er i brug.

Andre steder på maskinen.
Olien lækker ikke, når maskinen ikke er i brug.

Hvornår Hvornår blev afvigelsen først observeret? Hvornår er afvigelsen observeret siden? Fejlen sås første gang for en uge siden. Spildet er sket hver dag siden da. Fejlen har ikke været set tidligere end for en uge siden. Er der foretaget nogen ændringer, der kan forklare, at maskinen er begyndt at lække?
Omfang Hvor mange objekter har afvigelsen? Hvor stor er afvigelsen? Hvor mange afvigelser er der på hvert objekt? Maskinen lækker ca. 20 liter olie i timen. Mængden af spildt olie er konstant. Mængden af spildt olie varierer ikke.