Nyt ERP‑system: hvad skal testes før og efter idriftsættelse?

Et ERP-system samler økonomi, ordrer, lager og ofte løn i én løsning, og det kobles til webshoppen, banken og andre systemer. Hvad der skal testes, hviler derfor på tre forhold: rollerne i systemet, forbindelserne til andre systemer og den adgang, der findes udefra.

Den mest brugbare test ligger før idriftsættelsen, i et miljø, der ligner den kommende drift, med roller og integrationer sat op som planlagt. En kortere kontrol efter idriftsættelsen kan bekræfte, at driften svarer til det testede, og at projektets midlertidige adgange er fjernet.

Et projekt om processer, ikke om sikkerhed

Et ERP-projekt handler om processer, data og tidsplan. Sikkerheden indgår, men den afprøver sjældent sig selv. Rettigheder sættes op ud fra organisationens behov, integrationer bygges af forskellige parter, og standardindstillinger følger med fra leverandøren. Hver part kan have gjort sit arbejde ordentligt, uden at nogen har set på helheden. Spørg leverandøren, hvilke standardkonti og standardindstillinger systemet leveres med, og hvilke af dem der er ændret i jeres opsætning.

Samtidig er data i ERP-systemet blandt de mest følsomme i virksomheden: kunders og leverandørers oplysninger, bankforbindelser, priser, marginer og måske løn. En svaghed rammer ikke kun IT, men økonomien direkte. Det gør systemet til en naturlig kandidat, når virksomheden skal vælge, hvad der testes.

Et nyt ERP-system er også en sjælden lejlighed. Systemet bliver ofte brugt i mange år, og opsætningen fra idriftsættelsen kan leve længe. Fejl, der ikke findes nu, kan blive en del af hverdagen.

Hvem kan hvad?

I et ERP-system er det afgørende, hvem der kan hvad. Kan en lagermedarbejder se løn? Kan en bruger i bogholderiet både oprette en leverandør og godkende betalingen til den? Kan en ekstern konsulent mere, end opgaven kræver? Kan en leverandør i en portal se andre leverandørers aftaler?

Det er spørgsmål, som en test kan afprøve, når den har konti i de relevante roller. OWASP’s testvejledning for webapplikationer har et særskilt område om autorisation, altså om brugere kun kan det, deres rolle tillader. Når ERP-systemet har en webbaseret brugerflade eller portal, er tankegangen relevant. → Penetrationstest af webapplikationer

For bestillingen betyder det, at testeren skal have udleveret konti, der svarer til de vigtigste roller, og at nogen i virksomheden kan forklare, hvad hver rolle skal kunne. Uden den forklaring kan testeren ikke afgøre, om en adgang er en fejl eller en bevidst beslutning. → Testkonti og testdata

Testen afprøver de tekniske rettigheder. Den erstatter ikke økonomifunktionens egne kontroller af, om funktionsadskillelsen er rigtig tænkt. Det er en anden opgave, som revisor og den interne kontrol tager sig af.

Forbindelser til resten af virksomheden

Et ERP-system står sjældent alene. Det henter ordrer fra webshoppen, sender betalinger til banken, udveksler data med lønsystemet og har måske en portal for leverandører eller forhandlere. Hver forbindelse er en mulig vej ind eller ud. → Integrationer mellem systemer

Afklar, hvilke integrationer der skal med, og hvilke der ejes af andre, som skal give tilladelse. En bankintegration kan fx ikke testes uden bankens accept, og det samme gælder systemer, der drives af en anden leverandør. Mangler en tilladelse, skal det fremgå af scope og rapport, så hullet ikke glemmes. → Leverandørens godkendelse mangler

Bruger systemet fælles login med resten af virksomheden, påvirker det både roller og adgang udefra. En medarbejder, der forlader virksomheden, skal miste adgangen alle steder på én gang. → Fælles login i testen

Placér testen i projektplanen

ERP-projekter har ofte faste milepæle: opsætning, test af processer, datakonvertering, uddannelse og idriftsættelse. Penetrationstesten passer bedst ind, når roller og integrationer er sat op som planlagt, men før data og brugere flyttes over.

Datakonverteringen er et særligt punkt. Foregår testen i et miljø med rigtige data fra det gamle system, skal adgangen til miljøet behandles lige så forsigtigt som driften. Overvej, om testen kan bruge anonymiserede eller opdigtede data i stedet.

Før idriftsættelse · roller og integrationer kan testes i et miljø, der ligner driften, og rettelser forstyrrer ikke den daglige brug.
Efter idriftsættelse · en kortere kontrol kan bekræfte, at driften svarer til det testede, og at midlertidige projektadgange er fjernet.

Forskellen mellem projektmiljø og drift skal stå tydeligt i rapporten. → Penetrationstest i produktion eller testmiljø

Undgå at lægge testen så tæt på idriftsættelsen, at der ikke er tid til at rette. En test, der finder noget kritisk kort før, efterlader kun valget mellem at udskyde og at gå i drift med en kendt fejl. → Testen ligger lige før lanceringen

Aftal på forhånd, hvem der retter

I et ERP-projekt er der flere mulige ejere af et fund: systemleverandøren, implementeringspartneren, driftsleverandøren og virksomheden selv. Aftal i projektet, hvem der retter hvad, og hvordan fejl i selve standardsoftwaren håndteres, før testen begynder. → Hvem retter? Ansvar mellem virksomhed og leverandør

Aftal også, hvordan rettelser efterprøves. Er en fejl rettet af implementeringspartneren i projektmiljøet, skal det være klart, om rettelsen også er ført over i driften. Et fund, der er lukket i ét miljø og åbent i et andet, er stadig åbent.

Skriv gerne aftalen ind i kontrakten med implementeringspartneren. Det er lettere at aftale ansvaret for sikkerhedsfejl, før projektet er i gang, end når et fund ligger på bordet, og tidsplanen er presset.

Det skal I lade være med

At teste ERP-systemet uden roller · en test uden konti ser kun det yderste lag.
At lade alle testkonti være administratorer · så afprøves rollerne ikke.
At glemme integrationerne · forbindelserne til webshop og bank er en del af systemet.
At teste lige før idriftsættelsen · der skal være tid til at rette.
At lade projektets adgange stå efter idriftsættelsen · konsulenternes brede rettigheder bør fjernes.

Hvad kan og ikke kan konkluderes

En test før idriftsættelsen kan vise, om de undersøgte roller, integrationer og adgange holdt i det testede miljø. Den kan give et grundlag for beslutningen om idriftsættelse og for krav til leverandøren.

Den kan ikke uden videre overføres til driften, hvis opsætningen ændres undervejs. Den kan heller ikke vurdere forretningsprocesser og kontroller i økonomifunktionen, som hører under revision og intern kontrol.

En test efter idriftsættelsen kan heller ikke vise, at rollerne forbliver rigtige, når organisationen ændrer sig. Nye medarbejdere, nye afdelinger og nye moduler betyder nye rettigheder, som bør gennemgås løbende.