Go-live uten kaos: Slik planlegger du systembyttet
Go-live ved et systembytte er et eget delprosjekt, ikke et knappetrykk. De avgjørende valgene er strategien (big bang eller parallelldrift), en rollback-plan med tydelige beslutningskriterier for å trekke seg tilbake i tide, og forsterket support de første ukene. En gjennomtenkt produksjonssetting med generalprøve reduserer risikoen for at byttet blir det kaoset mange frykter.
Å bytte et forretningssystem sammenlignes ofte med å bytte motor på et fly i luften: Virksomheten kan ikke settes på pause mens byttet skjer. Selve produksjonssettingen, det som kalles go-live, er et prosjekt i seg selv og den fasen der mest kan gå galt. Mange legger all kraft i å bygge det nye systemet og nesten ingen i hvordan byttet skal gjennomføres. Denne guiden viser hvordan du planlegger produksjonssettingen slik at den blir en kontrollert overgang i stedet for en helg i kaos.
Big bang eller parallelldrift?
Det første og viktigste veivalget er strategien. Det finnes to grunnmodeller, og de gir ulik balanse mellom risiko og kostnad.
- Big bang. Alle bytter samtidig på et bestemt tidspunkt, og det gamle systemet slås av. Det er raskest og billigst, men også mest risikabelt: Går noe galt, står hele virksomheten på det nye systemet uten retrettmulighet.
- Parallelldrift. Begge systemene kjøres samtidig i en periode mens brukerne gradvis flytter over. Det er tryggere fordi det gamle finnes som sikkerhetsnett, men dyrere og mer krevende: Noen må holde begge systemene i gang og håndtere data to steder.
Valget styres av hvor forretningskritisk systemet er. Et internt verktøy tåler ofte en big bang. Et system som håndterer ordrer og betalinger midt i driften, rettferdiggjør den forsiktigere veien, til tross for kostnaden.
Generalprøve før produksjonsstart
Uansett strategi er generalprøven den billigste måten å kjøpe trygghet på. Før den faktiske produksjonssettingen øver du på hele forløpet i et testmiljø, med reelle data og de samme stegene. Poenget er å finne feilene mens det er gratis å finne dem.
En generalprøve avdekker det som ellers dukker opp midt i selve oppstarten: at et migreringssteg tar tre timer i stedet for tretti minutter, at enkelte data ikke flyttes rent, at en tilgang mangler for en nøkkelrolle. Å oppdage dette på en planlagt øvelse er uendelig mye billigere enn å gjøre det klokken tre om natten når systemet skal i produksjon, mens hele virksomheten venter.
Rollback-plan med tydelige beslutningskriterier
Håp er ingen strategi. Før produksjonssettingen starter, må du vite nøyaktig hva som får deg til å avbryte og gå tilbake til det gamle systemet, og hvem som tar den beslutningen.
| Beslutningspunkt | Hva som skal være bestemt på forhånd |
|---|---|
| Kriterier for rollback | Hvilke konkrete feil eller forsinkelser som utløser en beslutning om å gå tilbake |
| Beslutningstaker | En utpekt person med mandat til å avbryte, ingen komité der og da |
| Tidsgrense | Siste tidspunkt da rollback fortsatt er mulig uten tap av data |
| Tilbakeføringssteg | Hvordan man faktisk kommer seg tilbake til det gamle systemet, testet på forhånd |
Poenget med å bestemme alt dette på forhånd er at rollback-beslutninger ellers tas i panikk eller for sent. Når kriteriene er satt, tør noen å trekke i nødbremsen tidsnok til at et halvveis gjennomført bytte ikke rekker å gjøre stor skade.
De første ukene i drift
Go-live er ikke slutten, men begynnelsen på den mest sårbare perioden. Det er nå de reelle bruksmønstrene møter systemet, og problemer som ingen tester fanget opp, kommer frem. Planlegg for det i stedet for å puste ut for tidlig.
- Forsterket support. Ha utviklere tilgjengelige for raske rettelser de første dagene, når presset er størst.
- En tydelig kanal for brukerne. Spørsmål og feil skal ha en selvsagt vei inn, ellers sprer frustrasjonen seg i korridoren i stedet for å bli løst.
- Daglig statusmøte. Følg opp situasjonen hver dag den første tiden, og prioriter det som forstyrrer flest.
Regn med økt beredskap i minst et par uker. Det er da småfeil avgjør om brukerne får tillit til det nye systemet eller begynner å lengte tilbake til det gamle.
Et scenario: byttet som holdt
Et selskap byttet sitt sentrale forretningssystem og valgte parallelldrift fordi selv en kort driftsstans ville stoppe hele leveransekjeden. De kjørte en full generalprøve helgen før og satte en tydelig grense for når de skulle gå tilbake. I tillegg styrket de supporten den første uken.
Under den faktiske oppstarten dukket det opp en datafeil, men fordi den lå langt under grensen for rollback og supporten var på plass, ble den rettet på en time uten at noen trengte å gå tilbake. Byttet ble opplevd som udramatisk nettopp fordi dramatikken var planlagt bort på forhånd.
En gjennomtenkt produksjonssetting er en billig forsikring mot en dyr helg. Skal dere bytte et virksomhetskritisk system, hjelper vi i Weapp gjerne til med å planlegge go-live. Ta kontakt med en beskrivelse av hva dere skal bytte.
Ofte stilte spørsmål
Hva er forskjellen på big bang og parallelldrift?
Big bang betyr at alle bytter til det nye systemet på et bestemt tidspunkt, og at det gamle slås av. Parallelldrift innebærer at begge systemene kjøres samtidig i en periode mens brukerne gradvis flytter over. Big bang er raskere og billigere, men mer risikabelt; parallelldrift er tryggere, men dyrere og mer krevende å holde i gang. Valget avhenger av hvor forretningskritisk systemet er.
Trenger vi virkelig en generalprøve?
Ja, for et virksomhetskritisk system er det vanskelig å forsvare å hoppe over den. En gjennomkjøring av hele produksjonssettingen i et testmiljø avdekker feilene som ellers dukker opp midt i selve overgangen: at et steg tar lengre tid enn ventet, at data ikke flyttes rent, at en tilgang mangler. Det er billigere å finne dette på en generalprøve enn klokken tre om natten når systemet skal i produksjon.
Når skal vi bestemme oss for å gå tilbake til det gamle systemet?
Bestem det før produksjonssettingen, ikke underveis. Fastsett konkrete kriterier på forhånd, altså hvilke feil eller forsinkelser som utløser en rollback, og utpek hvem som tar beslutningen. Uten forhåndsbestemte grenser tas rollback-beslutninger i panikk eller for sent, når skaden allerede har skjedd. En tydelig grense gjør at noen tør å trekke i nødbremsen i tide.
Hvor lenge trenger vi forsterket support etter go-live?
De første dagene er mest intensive, men regn med økt beredskap i minst et par uker. Det er da de reelle bruksmønstrene møter systemet, og problemer som ingen tester fanget opp, kommer frem. Ha utviklere tilgjengelige for raske rettelser og en tydelig kanal for brukernes spørsmål slik at småfeil ikke rekker å bli tillitskriser.