Go-live utan kaos – så planerar du systembytet
Go-live vid ett systembyte är ett eget delprojekt, inte en knapptryckning. De avgörande valen är strategin – big bang eller parallelldrift – en rollbackplan med tydliga beslutskriterier för att backa i tid, och en förstärkt support de första veckorna. En genomtänkt driftsättning med generalrepetition minskar risken för att bytet blir det kaos många fruktar.
Att byta ett verksamhetssystem liknas ofta vid att byta motor på ett flygplan i luften – verksamheten kan inte pausas medan bytet sker. Själva driftsättningen, det som kallas go-live, är ett projekt i sig och den fas där mest kan gå fel. Många lägger all kraft på att bygga det nya systemet och nästan ingen på hur bytet ska genomföras. Här är hur du planerar driftsättningen så att den blir en kontrollerad övergång i stället för en helg i kaos.
Big bang eller parallelldrift?
Det första och viktigaste vägvalet är strategin. Två grundmodeller finns, och de innebär olika balans mellan risk och kostnad.
- Big bang. Alla byter samtidigt vid en bestämd tidpunkt, och det gamla systemet stängs av. Det är snabbast och billigast, men också mest riskabelt – går något fel står hela verksamheten på det nya systemet utan reträttväg.
- Parallelldrift. Båda systemen körs samtidigt en period medan användarna gradvis flyttar över. Tryggare, eftersom det gamla finns kvar som skyddsnät, men dyrare och mer krävande – någon måste hålla båda systemen i gång och hantera data på två ställen.
Valet styrs av hur affärskritiskt systemet är. Ett internt verktyg tål ofta en big bang. Ett system som hanterar order och betalningar mitt i verksamheten motiverar den försiktigare vägen, trots kostnaden.
Generalrepetition före skarp start
Oavsett strategi är generalrepetitionen det billigaste sättet att köpa trygghet. Innan den skarpa driftsättningen övar du hela förloppet i en testmiljö, med riktig data och riktiga steg. Poängen är att hitta felen medan de är gratis att hitta.
En repetition avslöjar det som annars dyker upp mitt i skarp start: att ett migreringssteg tar tre timmar i stället för trettio minuter, att vissa data inte flyttar rent, att en behörighet saknas för en nyckelroll. Att upptäcka detta på en planerad övning är oändligt mycket billigare än att göra det klockan tre på natten under skarp go-live, med hela verksamheten väntande.
Rollbackplan med tydliga beslutskriterier
Hoppet är ingen strategi. Innan driftsättningen börjar måste du veta exakt vad som får dig att avbryta och backa till det gamla systemet – och vem som fattar det beslutet.
| Beslutspunkt | Vad som ska vara bestämt i förväg |
|---|---|
| Rollback-kriterier | Vilka konkreta fel eller förseningar som utlöser ett återgångsbeslut |
| Beslutsfattare | En utpekad person med mandat att avbryta – ingen kommitté i stunden |
| Tidsgräns | Senaste tidpunkt då rollback fortfarande är möjlig utan dataförlust |
| Återgångssteg | Hur man faktiskt tar sig tillbaka till gamla systemet, testat i förväg |
Poängen med att bestämma allt detta i förväg är att rollbackbeslut annars fattas i panik eller för sent. När kriterierna är satta vågar någon dra i handbromsen i tid, innan ett halvt genomfört byte gjort ordentligt ont.
De första veckorna i drift
Go-live är inte slutet, det är början på den mest känsliga perioden. Det är nu de verkliga användningsmönstren möter systemet och problem som inga tester fångade kommer fram. Planera för det i stället för att andas ut för tidigt.
- Förstärkt support. Ha utvecklare tillgängliga för snabba rättningar de första dagarna, då trycket är som högst.
- En tydlig kanal för användarna. Frågor och fel ska ha en självklar väg in, annars sprids frustrationen i korridoren i stället för att lösas.
- Daglig avstämning. Följ upp läget varje dag den första tiden och prioritera det som stör flest.
Räkna med förhöjd beredskap i minst ett par veckor. Det är då småfel avgör om användarna får förtroende för det nya systemet eller börjar längta tillbaka till det gamla.
Ett scenario: bytet som höll ihop
Ett bolag bytte sitt centrala verksamhetssystem och valde parallelldrift eftersom en stunds stillestånd skulle stoppa hela leveranskedjan. De körde en full generalrepetition helgen innan, satte en tydlig gräns för när de skulle backa och bemannade upp supporten den första veckan.
Under skarp start dök ett datafel upp – men eftersom det låg långt under rollback-gränsen och supporten fanns på plats rättades det på en timme utan att någon behövde backa. Bytet upplevdes som odramatiskt, just för att dramatiken hade planerats bort i förväg.
En genomtänkt driftsättning är billig försäkring mot en dyr helg. Ska ni byta ett verksamhetskritiskt system hjälper vi på Weapp gärna till att planera go-liven – hör av dig med en beskrivning av vad ni ska byta.
Vanliga frågor
Vad är skillnaden mellan big bang och parallelldrift?
Big bang betyder att alla byter till det nya systemet vid en bestämd tidpunkt och det gamla stängs av. Parallelldrift innebär att båda systemen körs samtidigt en period medan användarna gradvis flyttar över. Big bang är snabbare och billigare men mer riskabelt, parallelldrift är tryggare men dyrare och mer krävande att hålla i gång. Valet beror på hur affärskritiskt systemet är.
Behöver vi verkligen en generalrepetition?
Ja, för ett verksamhetskritiskt system är det svårt att motivera att hoppa över. En repetition av hela driftsättningen i en testmiljö avslöjar de fel som annars dyker upp mitt i skarp start – att ett steg tar längre tid än väntat, att data inte flyttar rent, att en behörighet saknas. Det är billigare att hitta det på en generalrepetition än klockan tre på natten under skarp go-live.
När ska vi bestämma att backa till gamla systemet?
Besluta det före, inte under, driftsättningen. Sätt konkreta kriterier i förväg – vilka fel eller förseningar som utlöser en rollback – och utse vem som fattar beslutet. Utan förutbestämda gränser fattas rollbackbeslut i panik eller för sent, när det redan gjort ont. En tydlig gräns gör att någon vågar dra i handbromsen i tid.
Hur länge behöver vi förstärkt support efter go-live?
De första dagarna är mest intensiva, men räkna med förhöjd beredskap i minst ett par veckor. Det är då de verkliga användningsmönstren möter systemet och problem som inga tester fångade dyker upp. Ha utvecklare tillgängliga för snabba rättningar och en tydlig kanal för användarnas frågor, så att småfel inte hinner bli förtroendekriser.