Hvorfor opstår der fejl?

I et ERP-projekt, som er afsluttet for nylig, har HerbertNathan & Co medvirket til at gennemføre en årsagsanalyse på fejl, som blev fundet i implementeringsforløbet og efter go-live. Formålet med opgaven var at finde ud af, hvor og hvornår fejl opstår, og hvordan det kunne være forhindret.

Implementering af standard ERP-system indeholder normalt mindre fejl, end hvis man udvikler et system fra bunden. Dette skyldes bl.a., at funktionalitet i standard ERP-systemer anvendes af mange andre virksomheder, og derfor er blevet gennemtestet flere gange. Samtidig må det forventes, at især de større ERP-leverandører er mere professionelle og tester funktionalitet grundigt, inden systemet frigives på markedet. Fejl findes typisk de steder, hvor virksomheden selv har lavet tilpasninger (enhancements), eller hvor der er udviklet integration til andre systemer. Det anbefales derfor også, at der i testforløbet for implementering af et nyt ERP-system fokuseres på disse områder, i stedet for at teste standardfunktionalitet.

I test anvender man normalt ”V-modellen” til at beskrive, hvornår i projektforløbet, der gennemføres test, og på hvilket niveau test er relevant at gennemføre. Man kan således tale om forskellige test-faser, som f.eks. komponenttest, integrationstest, brugertest og overtagelsestest. Afhængig af projektet kan der også gennemføres andre typer tests, som f.eks. performancetest og brugervenlighedstest (usability-test). Generelt kan man sige, at jo før fejlen findes, jo billigere er det at rette. Når først systemet er gået i drift, kan selv små fejl være problematiske, fordi de er sværere at rette, og det udstilles overfor brugere og måske endda eksterne leverandører eller kunder.

I den årsagsanalyse som HerbertNathan & Co var med til at gennemføre, blev det vurderet i hvilken fase fejlen blev fundet. Samtidig blev angivet en kode for årsag til fejl. Eksempler på dette er:

  • Specifikationen er uklar eller fejlbehæftet
  • Standarder for programmering er ikke fulgt
  • Forkert opsætning af parametre
  • Dårlig planlægning af test, mangler i testmiljøer, uerfarne testressourcer etc.

Endvidere blev det for hver fejl vurderet, hvilke forbedringstiltag der kunne have været gjort, som havde forhindret, at fejlen opstod. Eksempler på dette er:

  • Projektet bemandes med erfarne ressourcer
  • Kvalitetssikring af designbeslutninger
  • Planlægning og prioritering af test
  • Etablering af testdata og testmiljøer m.v.

Ingen systemer er fejlfrie, og det kan ikke svare sig at teste 100%, med mindre man skal sende en rumraket til månen, og selv i de tilfælde har der jo som bekendt været fejl. Men man kan godt lære af egne og andres erfaringer, så antallet af fejl minimeres.