Accepttesten er den sidste prøve før et nyt system tages i brug. Her prøver forretningens egne folk, om systemet kan klare det arbejde, de skal udføre i det. Leverandøren har allerede testet, at løsningen virker, som den er bygget. Accepttesten skal vise, om den er bygget rigtigt til jeres hverdag. I et program med flere afdelinger eller selskaber er det samtidig en ledelsesopgave, for testerne er jeres dygtigste medarbejdere, de sidder et andet sted end IT, og underskriften har betydning for kontrakten. Tre ting skal afgøres. Hvem frigiver folkene, hvilke scenarier skal testes, og hvad betyder det, når en procesejer skriver under?
Softwarehuse, der laver deres eget produkt, har en anden problemstilling, og den står på hvornår en leverance er færdig. Her er I kunden, og systemet er købt.
Hvem tester?
Testerne skal være dem, der kender arbejdet. Det er bogholderen, der lukker måneden, indkøberen, der håndterer rykkere, og lagerlederen, der ved, hvad der sker, når en palle er forkert. IT-folk og konsulenter kan hjælpe med at planlægge, men de kan ikke afgøre, om løsningen er brugbar. Hvis partnerens folk gennemfører testen for jer, ender I med at godkende deres egen løsning.
Procesejerne står for testen på deres område. De udpeger testerne, prioriterer fejlene og beslutter, om området er klart. En testleder, gerne jeres egen, holder sammen på planen, fejllisten og afhængighederne på tværs. Hvis I har flere selskaber, skal hvert selskab teste det, der er særligt for det. Den fælles løsning kan sagtens virke i det selskab, der var med i designet, og alligevel fejle i det, der blev tilføjet sent.
Hvem frigiver folkene?
Accepttesten bliver ofte planlagt, som om testerne var ledige. De er det ikke, og især ikke hvis testen falder oven i regnskabsafslutning eller højsæson. Det er linjelederne, der skal afgive folkene, og derfor skal beslutningen ligge over dem.
Lad programejeren aftale frigivelsen med de berørte direktører tidligt, med navne og uger. Afgør også, hvem der dækker det daglige arbejde, sådan som det er beskrevet under forretningens folk i programmet. Bliver testen forsinket, vil kalenderen ofte være det, der knækker først. Spørg derfor, hvad der sker med testerne, hvis leverancen kommer tre uger for sent.
Scenarier fra den virkelige hverdag
En god test følger arbejdet fra start til slut på tværs af afdelingerne, i stedet for at prøve enkelte skærmbilleder. En ordre skal gå fra modtagelse over plukning og forsendelse til faktura og betaling. Reklamationen, kreditnotaen og den delvise levering hører med, for det er ofte dér, løsningen først bliver prøvet.
Lad procesejerne skrive scenarierne med udgangspunkt i det, der faktisk sker. Tag månedsafslutning med, intern handel mellem selskaberne og de fejl, folk retter i dag uden at tænke over det. Brug data, der ligner de rigtige, så en kunde med særlige aftaler bliver prøvet med dem. Find også frem til årets sjældne opgaver, for de bliver let glemt.
Tag de systemer med, der hænger sammen med det nye. Accepttest af et ERP-system giver ikke meget, hvis forbindelserne til bank, webshop eller lagerstyring er erstattet af en attrap. Kan de ikke være med, skal listen sige det, så styregruppen ved, hvad der ikke er bevist.
Fejl, klasser og beslutninger
Aftal, inden testen begynder, hvordan fejl bliver klassificeret. En enkel skala er nok, fx kritisk, alvorlig og mindre. Kritisk betyder, at arbejdet ikke kan udføres, og at der ikke er en vej udenom. Skriv det ned, for partneren og forretningen vil sjældent være enige om, hvad der er en fejl, og hvad der er et nyt ønske. Grænsen mellem fejl og ændring afgør, hvem der betaler, og det er en af de hyppigste kilder til strid. Hvad der skal stå i aftalen om det, er beskrevet under fastpris eller regning.
Aftal også, hvem der afgør tvivlstilfælde. Her kan den samme gruppe bruges, som afgør afvigelser fra standarden. Fejl, der ikke rettes før go-live, skal stå på en liste med ansvarlig, dato og en foreløbig nødløsning.
Hvad underskriften betyder
En kontrakt kan knytte accepten til noget konkret. Accepten kan udløse betaling, starte en garantiperiode eller afslutte leverandørens pligt til at rette fejl uden beregning. Hvad underskriften betyder hos jer, står i jeres aftale, og spørgsmålet skal afklares med advokaten, før testen begynder. En procesejer, der skriver under af venlighed for at holde tidsplanen, kan have flyttet en risiko fra leverandøren til jer.
Skeln derfor mellem to underskrifter. Den ene er intern. Her bekræfter procesejeren over for programejeren, at området er klar, med de åbne punkter, der er. Den anden er kontraktuel, og den gives til leverandøren af den, der har fuldmagt til det. Sæt navne på begge. Så bliver det tydeligt, at bogholderen, der har testet, ikke har godkendt noget på virksomhedens vegne.
Procesejernes bekræftelse er et af kriterierne i go-live-beslutningen.
Det gør I nu
Bed programlederen om en plan, der viser testerne med navn, deres uger og hvem der dækker deres arbejde. Lad procesejerne udarbejde listen over scenarier. Læs kontraktens bestemmelser om accept, og afklar med advokaten, hvem der må underskrive og hvad det udløser.
Det skal I lade være med
- At lade partneren teste for jer · så har ingen fra forretningen set løsningen.
- At planlægge testen oven i månedsafslutningen · de rigtige folk har ikke tid.
- At underskrive for at redde datoen · underskriften kan flytte risiko fra leverandør til jer.
Det skal I kræve af dem, der leder IT
- ☐ En testplan med navngivne testere og dækning af deres daglige arbejde.
- ☐ Scenarier skrevet af procesejerne, der går på tværs af afdelinger.
- ☐ En aftalt skala for fejl og en person, der afgør tvivlstilfælde.
- ☐ Tydelig besked om, hvad der ikke kunne testes.
- ☐ En oversigt over, hvem der underskriver hvad, og hvad det betyder.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Procesejere · ERP-program på tværs af selskaber
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
