Ekstern IT‑chef

De samme IT‑fejl igen og igen: fra brandslukning til årsag

En skærm med en uskarp fejlbesked på en arbejdsplads på et lager, med en stregkodescanner ved siden af

Kender I det, at telefonsystemet hænger hver mandag, eller at økonomiprogrammet skal genstartes, hver gang der er månedsafslutning? Medarbejderen ringer, leverandøren retter det, og sagen lukkes. En uge senere er den der igen. Hver enkelt sag er håndteret korrekt, og alligevel bliver problemet ved. Vejen ud består af tre skridt. Skriv fejlene ned ét sted, find mønstrene, og bed leverandøren om en årsagsanalyse, altså en skriftlig forklaring på, hvorfor fejlen opstår, og hvad der skal til, for at den forsvinder for altid.

Hvorfor brandslukning bliver normalen

Sagssystemer behandler hver henvendelse for sig. En tekniker får en sag, løser den og går videre til den næste, og det er også det, der måles på. Næste gang fejlen dukker op, sidder der måske en anden tekniker, som ikke kender forhistorien. Ingen har til opgave at se på tværs.

Betaler I pr. time, tjener leverandøren desuden på gentagelsen, uden at nogen har ment det sådan. Hos jer vænner medarbejderne sig til det. De genstarter, venter eller beder kollegaen om hjælp, og så når fejlen aldrig frem til nogen, der kan gøre noget ved den. Det koster også arbejdstid, som medarbejdernes tid på IT handler om.

Fejlloggen er et enkelt ark

En fejllog er en liste over de driftsfejl, der er opstået. Et fælles regneark er rigeligt. Hver linje skal rumme:

  • dato og klokkeslæt,
  • system eller udstyr,
  • hvem der blev ramt,
  • hvad der skete, med brugerens egne ord,
  • leverandørens sagsnummer,
  • hvordan det blev løst,
  • omtrent hvor lang tid, der gik tabt.

Lad én person føre arket, så det ikke bliver medarbejdernes ekstra opgave. Den, der i forvejen modtager klagerne, er oplagt. Bed også leverandøren om et udtræk af sagerne for det seneste halve år. Det er ofte den hurtigste vej til et første billede, og derefter fanger jeres eget ark det, der aldrig blev til en sag.

Find mønstrene

Når I har nogle måneders data, så sæt jer med listen, og sortér den. Se efter fem ting:

  1. Det samme system eller stykke udstyr.
  2. Det samme tidspunkt, fx mandag morgen eller ved månedsskiftet.
  3. De samme personer eller den samme maskine.
  4. Fejl, der begyndte efter en opdatering eller en ændring.
  5. Fejl, hvor to leverandører peger på hinanden.

Et tænkt eksempel: En grossist med 40 ansatte oplever, at ordresystemet er langsomt. Hver sag er oprettet for sig som “langsomt system” og lukket, når det igen gik bedre. Fejlloggen viser, at det næsten altid sker mellem klokken 10 og 11. Det passer med tidspunktet for en dataoverførsel, som ingen hos virksomheden kendte til. Rettelsen tager en eftermiddag, når først nogen har stillet spørgsmålet.

Sådan kræver I en årsagsanalyse

Beslut en enkel regel for, hvornår I beder om analysen. Det kan være, at samme fejl er opstået tre gange på et kvartal, eller at en enkelt fejl stoppede arbejdet for mange. Reglen gør det lettere at bede om den, for så er det en fast fremgangsmåde og ingen kritik af en enkelt tekniker.

Analysen skal fylde lidt og svare på fem spørgsmål. Hvad skete der? Hvorfor skete det? Hvad er rettet varigt? Hvornår er det gjort? Hvordan kan I se, at det virkede? Svaret “vi har genstartet serveren” besvarer det første spørgsmål og ingen af de andre. Står årsagsanalyser ikke i jeres aftale, kan leverandøren tage betaling for tiden, og det kan være givet godt ud. Tag det op som en del af opfølgningen på SLA’en, og bliver sagen ved med at stå stille, findes vejen videre i eskalering hos IT-leverandøren.

Når årsagen ligger mellem to leverandører

Nogle fejl hører til mellem internetleverandøren, driftsleverandøren og systemhuset. Hver af dem tester sin egen del og melder alt i orden. Så skal nogen samle dem om samme sag, med fejlloggen på bordet og en person, der har ansvaret for at komme til bunds. Den opgave er beskrevet i artiklen om koordinering af flere leverandører.

Når årsagen er en beslutning

Af og til ender analysen med, at udstyret er for gammelt, internetforbindelsen for lille, eller at et system har nået sin grænse. Så er det ledelsens tur. Fejlloggen er et godt grundlag, fordi den viser, hvad det koster i tabt tid at lade tingene være. Beslutningen hører til i budgettet og måske i vurderingen af, om et system skal udskiftes.

Hvad gør I nu?

Opret arket i dag, og udpeg den, der fører det. Bed leverandøren om udtrækket af de seneste sager. Vælg den fejl, der irriterer flest, og send den som første bestilling på en årsagsanalyse. Tag resultatet op på næste møde.

Det skal I lade være med

  • At lade medarbejderne finde sig i det · bed dem melde fejlen, også når en genstart klarede den.
  • At bede om analyser af alt · start med de få fejl, der koster mest.
  • At lade sagen lukke på en omgåelse · en midlertidig løsning skal følges af en varig.

Det skal I kræve af den eksterne

  • ☐ En fejllog, der bliver holdt ved lige uden at belaste medarbejderne.
  • ☐ En kort gennemgang af mønstrene hvert kvartal.
  • ☐ Årsagsanalyser, der bliver læst, vurderet og fulgt til dørs.
  • ☐ Koordinering, når fejlen ligger mellem flere leverandører.

Senest gennemgået: november 2026.

Næste skridt

Læs også: Fem IT-leverandører og ingen, der har overblikket · Driftsstatus på én side hver måned

→ Kontakt · Tlf. 70 13 63 23 · Ekstern IT-driftschef hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Mangler I en IT‑chef?

Fortæl kort, hvad der fylder: serveren, leverandørerne, regningerne eller en nøgleperson, der stopper. Rådgivningen er uvildig og uden bindinger til leverandører, så svaret tager udgangspunkt i jeres situation.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.