Derfor er standardsystemer ikke plug-and-play

”Nej, det er da ikke nødvendigt at teste – det er et standardsystem, vi implementerer”. Har du hørt den kommentar før?

Nogle af de antagelser, jeg har mødt igennem årene omkring standard løsninger, har været:

• ”Det virker jo allerede – andre bruger det jo.”
• ”Vi behøver ikke test – vi regner ikke med at lave ændringer.”
• ”Det er hurtigt og billigt at implementere.”
• ”Vi kan tilpasse vores processer til systemet.”
• ”Leverandøren tager sig af det.”
• ”Brugerne lærer det bare henad vejen.”

Alt for ofte ser vi organisationer, der kæmper med at lykkes med at implementere f.eks. nye CRM- eller ERP-systemer, fordi man har undervurderet opgaven.

I denne artikel vil vi dykke ned i, hvorfor implementering af standardsystemer ikke altid er helt så simple, som det ser ud til udefra, og med testbrillerne på vil vi komme med anbefalinger til, hvordan vi kan gribe kvalitetssikringen af disse implementeringsprojekter an.

Men lad os lige starte med en definition:

En standardløsning refererer til en softwarepakke designet til at imødekomme de generelle behov hos en bred vifte af brugere eller organisationer. Disse løsninger er færdigudviklede produkter, der kan implementeres uden væsentlige ændringer.

Her bider jeg mærke i to ting:

1. ”Disse løsninger er færdigudviklede produkter”
2. ”kan implementeres uden væsentlige ændringer”

Umiddelbart lyder det fantastisk, men for de fleste organisationer er det bare ikke den virkelighed, de står overfor, når først de kommer i gang. Lad os prøve at dykke ned i nogle af udfordringerne.

Udfordringer

Processer og arbejdsgange

Hvis vi tager udgangspunkt i Dynamics 365FO, kommer det ganske rigtigt som en færdigudviklet løsning med en hel pakke med en struktur af foruddefinerede processer og arbejdsgange – og en brugerflade, der supporterer dem. Men her er der lige en håndfuld spørgsmål, som vi skal huske at stille:

• Hvordan ser vores arbejdsgange ud i dag?
• Har vi styr på, hvor mange der er? Og er de dokumenteret?
• Passer vores arbejdsgange til de standardprocesser, der er implementeret?
• Er det praktisk muligt at ændre vores arbejdsgange, eller er det systemet, der skal ændres?
• Har vi alle de felter til rådighed i de forskellige skærmbilleder, for at vi kan gennemføre de forskellige arbejdsgange, vi har identificeret?

Testfokus kan have stor værdi i arbejdet med processer: Det kan identificere uoverensstemmelser mellem standardprocesser og virksomhedens arbejdsgange tidligt i forløbet gennem workshops med testcases baseret på rigtige arbejdsgange til at validere, om systemet fungerer i praksis.

Test af konfigurationen kan afsløre, om systemets standardfunktionalitet understøtter de eksisterende arbejdsgange, eller om der er behov for tilpasninger. Hvis strategien er at tilpasse forretningen til systemet (i stedet for at tilpasse systemet), kan test vise, om ændringerne er realistiske for medarbejderne.

I komplekse organisationer er processer ofte afhængige af flere systemer og aktører. En test med end-to-end scenarier kan afsløre, om f.eks. en ordreproces fungerer på tværs af ERP, lager- og finanssystemer.

Data

Den næste udfordring, vi kan stå overfor, er dataaspektet. Dette afhænger en del af, hvorvidt vi migrerer fra et andet system og skal have data med over, eller om vi starter på en frisk. Hvis organisationen hører til en af de første, så er det værd at stille spørgsmål som:

• Hvor ligger data i dag? Er data spredt over flere systemer, regneark og manuelle processer?
• Er alle nødvendige data tilgængelige, eller findes de slet ikke i struktureret form?
• Hvem ejer data? Hvilke afdelinger eller systemer har autoritet over hvilke data?
• Hvem har ansvaret for data efter implementeringen? Hvem opdaterer og vedligeholder?
• Har vi styr på politikker, så datakvaliteten ikke sander til over tid?
• Hvordan er den nuværende datakvalitet? Er der mange dubletter, er der fejl i data, mangler der nøgledata?
• Er data standardiseret i dag? Er der f.eks. en ensartet brug af landekoder mv.?

Når vi taler om data, kan vi heller ikke komme udenom datamigrering.

• Hvordan flytter vi data fra det gamle til det nye system? Big bang eller bulks?
• Hvordan håndterer vi historiske data? Skal alt migreres med over, eller tager vi først fra et vist tidspunkt? Hvis det sidste er tilfældet, hvad er så konsekvensen af at udelade data?
• Hvad gør vi med fejlbehæftede eller ufuldstændige data?
• Hvordan sikrer vi, at alle relevante data er overført korrekt?

Dette kræver også test – både med fokus på datakvaliteten i forbindelse med migration i form af datavalideringstest, hvor den migrerede data sammenlignes med den originale – men også dataflow test, hvor fokus er på, at data bevæger sig korrekt både internt i systemet og mellem systemerne. Det bringer os videre til næste udfordring.

Integrationer

Og lad os også lige tale om en af de klassiske elefanter i rummet, integrationer. Som testmanager er det virkelig et af mine yndlingsord, ”integrationer”. Mest fordi det er sådan en ”sjov” testopgave, som gang på gang bliver undervurderet. Jeg tror, den bedste kommentar jeg har fået i den kontekst er, ”Vi har testet ud til snitfladen, så vi ved, at det virker”. Famous last words. Selvom det er to standardsystemer, der skal integreres, kan det være en stor udfordring, og det er essentielt, at der er fokus på integrationerne fra dag 1:

• Hvilke systemer skal vores nye ERP-løsning integrere til?
• Hvordan virker integrationen? Bulk loads? Delta overførsel? Realtids push?
• Har vi defineret klare snitflader? Har vi helt styr på feltformaterne i begge ender af integrationerne?
• Har vi fået mappet alle de data, der skal flyde mellem systemerne?
• Har vi klart overblik over, hvem der har ejerskab over data? F.eks. hvis nu vores Dynamics skal integrere til et HR-system, hvilket af systemerne ejer så løndata? Persondata?

Regulatoriske krav og governance

Og så er der selvfølgelig også det med den generelle governance såvel som regulatoriske krav:

• Hvordan styrer vi adgangsstyring og datasikkerhed?
• Hvem må se hvilke data i det nye system?
• Hvem må gennemføre hvilke processer?
• Overholder vi GDPR?
• Hvilke compliance krav skal vi overholde? F.eks. bogføringsloven, regler i forhold til told og skat, NIS2 osv. Og så er der selvfølgelig alle de domænespecifikke compliance-krav som f.eks. i forhold til Finanstilsynet, hvis man er i finanssektoren, eller GAMP5, hvis man er i pharma.

Også denne del kan være temmelig omfattende at få styr på i løbet af projektet, afhængigt af hvilket domæne man arbejder i.

Så der er en række udfordringer, der kræver, at vi, inden vi går i gang med implementeringen, har styr på:

1. overblik over hvilke processer, systemet skal supportere
2. en strategi for datamigrering
3. en plan for at sikre datakvalitet
4. klare ejerskaber og governance
5. test af integrationer, datavalidering og processer.

Hvordan tester man så et standardsystem?

Når man skal teste standardsystemer (f.eks. ERP, CRM eller HR-systemer), adskiller teststrategien sig fra en traditionel softwareteststrategi, da standardsystemer sjældent udvikles fra bunden men i stedet konfigureres, integreres og migreres. Det betyder, at vores fokus ikke ligger på de mere udviklernære testniveauer som unittest og unitintegrationstest men ofte har fokus på:

• konfigurationstest: Sikrer, at systemet er opsat korrekt i forhold til de krav og behov, vi har identificeret sammen med vores brugere
• integrationstest: Sikrer, at systemet fungerer sammen med det eksisterende IT-landskab
• datamigreringstest: Hvis organisationen har data fra andre systemer, der skal migrereres, skal vi sikre at gamle data overføres korrekt til det nye system
• forretningsproces-test: Det er helt essentielt, at vi gennemfører test af de identificerede forretningsprocesser for at bekræfte, at arbejdsgangene fungerer som forventet
• accepttest (UAT): Brugerne bekræfter, at systemet understøtter deres daglige opgaver. Accepttesten kan være en ”paraply”, der reelt samler op på resultatet af de andre testaktiviteter og evt. supplerer med noget scenariebaseret test med end-to-end fokus for at sikre, at daglige opgaver kan løses.

Principper for test af standardsystemer

Der er nogle vigtige principper for test af standardsystemer, som bør tages med i planlægningen af projektet:

• Risikobaseret test: Fokus på de mest kritiske områder (f.eks. finansielle processer i et ERP). Ofte kan der f.eks. være rigtigt mange forretningsprocesser (jeg har set eksempler på 150-200 forskellige), og her er det vigtigt at kunne prioritere testaktiviteterne, så de vigtigste processer er dem, der får den mest grundige test.
• Tidlig test af konfiguration og integration: Undgå at vente med test til slutningen af projektet. Generelt er princippet om shift-left også vældigt relevant her. Der er ingen grund til at vente med test af f.eks. feltkonfigurationer til UAT eller procesorienteret test; lav tidlig test af de enkelte konfigurationer, og gerne noget der er automatiseres, så det bliver en integreret del af regressionstesten. Det er et nærmeste, vi kommer ”unit test” i klassisk forstand, da vi jo ikke tester kodekomponenter som sådan men konfigurationer.
• Automatisering hvor det giver mening: F.eks. regressionstest af workflows eller API‘er. ERP-systemet skal give værdi i mange år fremover, og mange organisationer vil opleve, at de løbende har behov for forbedringer og tilpasninger. For ikke at forglemme de forholdsvis store releases, der kommer fra leverandøren (SAP eller Microsoft afhængigt af platform) med utallige rettelser. Her har jeg set releasenotes med flere tusinde rettelser til en af de store releases – så her bliver regressionstest essentiel, og den skal ikke være manuel, da organisationen som oftest så vil være tvunget til at trække på forretningen i stort omfang, hver gang der kommer en ny release.
• Brugerinvolvering i accepttest – Forretningsbrugerne skal godkende, at systemet virker som forventet. Hvis vi skal være sikre på, at vi ikke kun har bygget det rigtigt men også har bygget det rigtige – at det virker i brugernes hverdag – så skal brugerne involveres i testen af løsningen. Som minimum i accepttesten.

Tips til test

Rent praktisk er der en række ting, der er værd at have in mente, når vi planlægger testen. Dette for at sikre, at vi får skabt det rigtige setup for testen og får styr på det rette omfang af testen – ikke for meget, ikke for lidt – men lige tilpas.

Så brug denne tjekliste som inspiration, når I skal i gang med at planlægge testen;

1. Fokus på de mest kritiske forretningsprocesser. Brug workshops med forretningen til at identificere de kritiske områder.
2. Brug testteknikker!! Også ved standardsystemer. F.eks. er procescyklustest helt fantastisk til at skabe det mest effektive sæt af test cases med procesfokus.
3. Automatiser gentagne tests så som workflows og tests af API’er.
4. Manuel test er vigtig, hvor brugeroplevelsen er i fokus. Altså test af konfigurationer og accepttest.
5. Hvis eksterne systemer ikke er klar, så brug mocks og testdata til at simulere integrationerne – men husk at teste dem rigtigt også!
6. Hvis mange brugere skal bruge systemet samtidig, så overvej, om det er relevant at gennemføre performance test for specifikke områder.
7. Hvordan får vi et testmiljø, der afspejler produktionen? Er det nødvendigt?
8. Hvordan håndterer vi versioner og opdateringer af standardsystemer?
9. Hvordan får vi testdata? Kan vi bruge anonymiseret produktionsdata, eller skal det genereres?

Test bør ske løbende gennem projektet. En prioriteret rækkefølge kan være som vist nedenfor, dog med den tilføjelse, at regressionstesten bør udvikles så tidligt som muligt, så den kan køres løbende gennem projektet; især hvis man arbejder inkrementelt, hvor områder færdiggøres løbende og samles til en samlet idriftsættelse:

1. Tidlig test af konfigurationer (konfigurationsvalidering)
2. Integrationstest (sikre system-til-system kommunikation)
3. Datamigreringstest (test af dataoverførsel fra gamle systemer)
4. End-to-end test (validering af forretningsprocesser)
5. Brugeraccepttest (UAT) (slutbrugerne godkender systemet)
6. Regressionstest og stabilitetstest før go-live

Men vi skal selvfølgelig kigge på jeres egen kontekst og finde det setup, der passer. Det kan være, at der er behov for en separat test, der fokuserer på compliance i forhold til, hvad I nu end har af regulativer, som I skal overholde for at sikre, at I får den korrekte og tilstrækkelige dokumentation til at bevise compliance. For i den type test handler det jo i lige så høj grad om den rapport/dokumentation, I kan levere efterfølgende som bevis for compliance – så det er nødt til at være i fokus ved planlægningen af testen.

Det kan også være, at der stort set ikke sker tilpasning af processerne, da vi udelukkende bruger standardprocesserne. Så kan der skæres ned på den detaljerede test af processer og fokuseres på en overordnet end-to-end test som en del af brugeraccepttesten.

Konklusion

Selvom standardsystemer kommer som færdige løsninger, betyder det ikke, at de kan implementeres uden grundig test. Konfigurationer, integrationer og datamigreringer introducerer risici, der kan påvirke både systemets funktionalitet og forretningens daglige drift.

En veltilrettelagt teststrategi sikrer, at systemet fungerer i praksis og understøtter forretningens behov. Fokus bør være på tidlig test af konfigurationer, grundig validering af integrationer, kvalitetssikring af data og risikobaseret prioritering af kritiske forretningsprocesser.

Test er ikke en unødvendig omkostning. Det er en investering i en succesfuld implementering.