Mange ERP-implementeringer lykkes rigtigt godt, men også nogle mislykkes med store omkostninger og stort tidstab til følge. En af de store grunde til at ERP-projekter mislykkes kan henføres til testningen af den nye ERP-løsning. Mange virksomheder undervurderer betydningen af de forskellige tests, der skal gennemføres for at sikre en succesfuld igangsætning af den nye ERP-løsning. Man tror at leverandøren gennemfører en stor del af testarbejdet, og overlader endda i visse tilfælde dele af testopgaven til leverandøren.

Et normalt ERP-projekt opdeles i forskellige faser, typisk starter implementeringen med en designfase, hvor leverandøren analyserer virksomheden for at kunne udarbejde det design, som systemet skal udvikles efter. Det kaldes typisk designspecifikationen eller et business blueprint. Når designet er fastlagt begynder leverandøren at udvikle eller klargøre ERP-løsningen – også kaldet konstruktionsfasen. Når leverandøren udvikler ERP-løsningen foretager de ”interne” enhedstests (unit test) for at sikre, at opsætning og tilretninger virker efter hensigten i henhold til designet. Men leverandøren foretager ikke de efterfølgende tests, og virksomheden bør tage det fulde ansvar for al efterfølgende test af systemet. I virkeligheden burde virksomheden rette hele sin fokus på at forberede, tilrettelægge, planlægge og gennemføre de tests der er nødvendige for at sikre en succesfuld igangsætning af den nye ERP-løsning. Alt som virksomheden skal udføre under konstruktionsfasen bør faktisk pege hen mod testen. Den samlede test bør som minimum indeholde installationstest, funktionstest, integrationstest, overtagelsesprøve samt driftsprøve. Og virksomheden skal selv sørge for planlægning, forberedelse og gennemførelse af alle disse tests. Man kan dog godt benytte leverandøren som rådgiver, fx til tilrettelæggelse, valg af værktøjer til at styre testen mv.

Først og fremmest skal der udarbejdes en testplan, og det kan virksomheden faktisk godt starte med allerede i designfasen. Testplanen skal beskrive alle de tests der skal gennemføres, de værktøjer der skal bruges samt hvilke af virksomhedens og leverandørens ressourcer der skal deltage i testaktiviteterne. Ikke mindst skal den beskrive de kriterier der skal opfyldes for at en testaktivitet kan gennemføres og resultatet af denne kan godkendes.

Ved tilrettelæggelsen af de enkelte tests skal man udarbejde ”test scripts” eller et testscenarie (nogle kalder det også test case eller use case, som dog egentlig dækker over noget andet). Testscenarierne bør indeholde følgende:

  1. Forudsætningerne for testen, dvs. de forskellige ting der skal være forberedt eller klargjort samt de data der skal benyttes i testscenariet. I visse typer test er man nødt til at simulere forskellige forudsætninger, fx integrationer som endnu ikke er udviklet
  2. Aktiviteterne som udføres i testen, dvs. de forskellige arbejdsopgaver som skal udføres i forbindelse med en proces. Herunder er det også vigtigt at medtage arbejdsopgaver, som man er nødt til at udføre, hvis processen ikke følges, dvs. undtagelser fra den almindelige arbejdsproces.
  3. Resultatet af testen, dvs. det resultat som man forventer af testen eller udførelsen af en arbejdsopgave. Det er med denne del man verificerer kriterierne for et succesfuldt testforløb, som kan godkendes. Verifikation bør også omfatte de relevante dele af designdokumentet og kravspecifikationen.

Det er vigtigt at man ved tilrettelæggelsen af den specifikke test har en struktur for, hvordan man sikrer at alle nødvendige aspekter af testen, fx at man har beskrevet sine processer ned til et vist detaljeringsniveau, som regel helt ned på brugervejledningsniveau. Det forudsætter selvfølgelig at virksomheden i forløbet har mappet sine nye forretningsprocesser og afspejlet dem i brugervejledningen.

Der er selvfølgelig mange andre aktiviteter og flere detaljer til en succesfuld test, men afslutningsvist skal virksomheden sikre, at man sætter de nødvendige ressourcer af til gennemførelse af testen, og især for de forretningsrelaterede ressourcer er der behov for mange ressourcer.

Hvis man er klar over den opgave der ligger i forbindelse med testen og planlægger det grundigt, kan man fjerne en meget stor risiko for et mislykket ERP-projekt.