5 fejl før go-live i GMP-produktion

Et digitaliseringsprojekt er næsten klar til go-live: Systemet er valgt. Integrationerne er bygget. Produktion er klar til at tage løsningen i brug.

Så kommer spørgsmålene.

• Er kravene dokumenteret godt nok? 
• Er dataflowet beskrevet? 
• Hvem ejer egentlig de data, systemet genererer? 
• Og er valideringen tænkt rigtigt ind?

Pludselig bliver det tydeligt, at det, der lignede de sidste detaljer før implementering, i virkeligheden handler om beslutninger, der burde være truffet langt tidligere.

Det er en klassisk udfordring i digitalisering af GMP-reguleret produktion. For selv om projekterne ofte handler om teknologi, bliver de sjældent udfordret af teknologien alene.

Problemerne opstår typisk i samspillet mellem systemer, processer, kvalitet, data og ansvar.

Her er fem fejl, der er værd at være opmærksom på, længe før projektet nærmer sig go-live.

1. GMP-impact bliver ikke afklaret tidligt nok

Et digitaliseringsprojekt kan se enkelt ud på overfladen: en ny integration, et dashboard eller en automatiseret arbejdsgang. Men hvis løsningen påvirker en GMP-kritisk proces, data eller beslutning, ændrer det kravene til projektet.

Derfor bør et af de første spørgsmål være: Hvilken GMP-impact har løsningen?

Hvis det først bliver afklaret sent, kan projektet have truffet en række valg om system, design og dokumentation på et forkert grundlag.

En tidlig vurdering gør det lettere at afgøre, hvilke krav der skal med videre – og hvor grundigt løsningen skal dokumenteres og valideres.

2. Use case og GMP-krav er ikke koblet sammen

De fleste digitaliseringsprojekter starter med et reelt behov.

Måske vil man reducere manuelt arbejde, få bedre overblik over produktionen eller bruge data mere aktivt til at træffe beslutninger. Det er et godt udgangspunkt.

Men i en GMP-reguleret produktion er der et ekstra spørgsmål, som skal med fra start:

Hvad betyder løsningen for de processer, data og kvalitetskrav, vi allerede er underlagt?

En stærk use case er ikke nok, hvis den regulatoriske konsekvens er uklar.

Jo tidligere forretningsbehov og GMP-krav bliver tænkt sammen, desto mindre er risikoen for, at en ellers god løsning senere viser sig at være vanskelig at implementere.

3. Valideringsstrategien er ikke på plads

Før projektet kommer langt i design og implementering, bør det være klart, hvordan løsningen skal valideres.

• Hvad skal dokumenteres? 
• Hvilke funktioner eller processer er kritiske? 
• Hvad skal testes – og hvilke kriterier skal være opfyldt, før løsningen kan accepteres?

Hvis de spørgsmål først bliver besvaret tæt på go-live, risikerer projektet at opdage, at krav, design og test ikke hænger ordentligt sammen.

En tydelig valideringsstrategi tidligt i forløbet gør det lettere at bygge dokumentation og test ind i projektet i stedet for at forsøge at rekonstruere dem bagefter.

4. Ingen har helt styr på dataflowet

Et system kan fungere teknisk korrekt og stadig skabe problemer, hvis organisationen ikke har et klart billede af, hvad der sker med data.

• Hvor bliver data skabt?
• Hvordan bevæger de sig mellem systemer?
• Hvem kan se, ændre eller godkende dem?
• Hvor bliver de gemt?
• Og hvilke data bruges som grundlag for beslutninger eller dokumentation?

Jo flere systemer, integrationer og automatiserede processer der kommer i spil, desto vigtigere bliver de spørgsmål.

Hvis dataflowet er uklart, bliver det også svært at vurdere dataintegriteten.

Før go-live bør det derfor være tydeligt, hvor kritiske data kommer fra, hvordan de bevæger sig mellem systemer, hvem der kan ændre dem, og hvordan deres integritet bliver sikret.

5. Hvornår er løsningen faktisk klar til go-live?

Projektplanen har en go-live-dato. Men er der også en fælles og dokumenteret forståelse af, hvad der skal være på plads, før løsningen kan frigives?

Det bør være tydeligt, hvilke test der skal være gennemført, hvilken dokumentation der skal være godkendt, hvilke afvigelser der kan accepteres, og hvem der træffer den endelige beslutning.

Ellers risikerer go-live at blive styret mere af kalenderen end af løsningens faktiske parathed.

Klare acceptkriterier gør det lettere at afgøre, om løsningen er klar – og at dokumentere, hvorfor organisationen vurderede, at den var klar.

Problemerne opstår sjældent dagen før go-live

Når et projekt bliver forsinket tæt på implementering, er det let at fokusere på det problem, der lige nu står i vejen.

Det kan være en manglende test. En dokumentation, der ikke er færdig. Måske er det et spørgsmål om data. Men tit er det kun symptomet.

Den egentlige årsag ligger ofte tidligere: GMP-impact blev ikke afklaret, use case og krav blev ikke koblet tæt nok sammen, valideringsstrategien var uklar, dataflowet var ikke kortlagt, eller kriterierne for go-live var aldrig defineret tydeligt.

Derfor handler god digitalisering i GMP-produktion ikke kun om at vælge den rigtige teknologi.

Det handler om at stille de rigtige spørgsmål, mens der stadig er tid til at handle på svarene.