Go-live uden kaos: sådan planlægger du systemskiftet
Go-live ved et systemskifte er et selvstændigt delprojekt, ikke et tryk på en knap. De afgørende valg er strategien (big bang eller paralleldrift), en rollbackplan med tydelige beslutningskriterier så man kan trække sig i tide, og forstærket support de første uger. En gennemtænkt idriftsættelse med generalprøve mindsker risikoen for at skiftet ender i det kaos mange frygter.
At skifte et forretningssystem bliver ofte sammenlignet med at skifte motor på et fly i luften: Forretningen kan ikke sættes på pause mens skiftet sker. Selve idriftsættelsen, det der kaldes go-live, er et projekt i sig selv og den fase hvor mest kan gå galt. Mange lægger alle kræfter i at bygge det nye system og næsten ingen i hvordan skiftet skal gennemføres. Sådan planlægger du idriftsættelsen så den bliver en kontrolleret overgang i stedet for en weekend i kaos.
Big bang eller paralleldrift?
Det første og vigtigste vejvalg er strategien. Der findes to grundmodeller, og de indebærer en forskellig balance mellem risiko og omkostning.
- Big bang. Alle skifter samtidig på et fastlagt tidspunkt, og det gamle system bliver lukket. Det er hurtigst og billigst, men også mest risikabelt: Går noget galt, står hele forretningen på det nye system uden en vej tilbage.
- Paralleldrift. Begge systemer kører samtidig i en periode mens brugerne gradvist flytter over. Tryggere fordi det gamle stadig findes som sikkerhedsnet, men dyrere og mere krævende: Nogen skal holde begge systemer kørende og håndtere data to steder.
Valget styres af hvor forretningskritisk systemet er. Et internt værktøj kan ofte tåle en big bang. Et system der håndterer ordrer og betalinger midt i forretningen, retfærdiggør den mere forsigtige vej trods omkostningen.
Generalprøve før den rigtige go-live
Uanset strategi er generalprøven den billigste måde at købe tryghed på. Før den rigtige idriftsættelse øver du hele forløbet i et testmiljø med rigtige data og rigtige trin. Pointen er at finde fejlene mens de er gratis at finde.
En generalprøve afslører det der ellers dukker op midt i den rigtige go-live: at et migreringstrin tager tre timer i stedet for tredive minutter, at visse data ikke flytter rent, at en adgangsrettighed mangler for en nøglerolle. At opdage det ved en planlagt øvelse er uendelig meget billigere end at gøre det klokken tre om natten under den rigtige go-live mens hele forretningen venter.
Rollbackplan med tydelige beslutningskriterier
Håb er ingen strategi. Før idriftsættelsen begynder, skal du vide præcis hvad der får dig til at afbryde og gå tilbage til det gamle system, og hvem der træffer den beslutning.
| Beslutningspunkt | Hvad der skal være besluttet på forhånd |
|---|---|
| Rollback-kriterier | Hvilke konkrete fejl eller forsinkelser der udløser en beslutning om at gå tilbage |
| Beslutningstager | En udpeget person med mandat til at afbryde, ikke et ad hoc-udvalg |
| Tidsfrist | Seneste tidspunkt hvor rollback stadig er mulig uden datatab |
| Trin til at gå tilbage | Hvordan man faktisk kommer tilbage til det gamle system, testet på forhånd |
Pointen med at beslutte alt dette på forhånd er at rollbackbeslutninger ellers bliver truffet i panik eller for sent. Når kriterierne er sat, tør nogen trække i nødbremsen i tide før et halvt gennemført skifte har gjort ordentlig skade.
De første uger i drift
Go-live er ikke slutningen, men begyndelsen på den mest følsomme periode. Det er nu de reelle brugsmønstre møder systemet, og problemer som ingen test fangede, kommer frem. Tag højde for det i planen i stedet for at ånde lettet op for tidligt.
- Forstærket support. Hav udviklere til rådighed til hurtige rettelser de første dage, hvor presset er størst.
- En tydelig kanal til brugerne. Spørgsmål og fejl skal have en selvfølgelig vej ind. Ellers spredes frustrationen på gangene i stedet for at blive løst.
- Dagligt statusmøde. Følg op på situationen hver dag i den første tid, og prioritér det der generer flest.
Regn med skærpet beredskab i mindst et par uger. Det er i den periode små fejl afgør om brugerne får tillid til det nye system eller begynder at længes tilbage til det gamle.
Et scenarie: skiftet der holdt
En virksomhed skiftede sit centrale forretningssystem og valgte paralleldrift fordi selv en kort nedetid ville stoppe hele leverancekæden. De gennemførte en fuld generalprøve weekenden før, satte en tydelig grænse for hvornår de ville gå tilbage og styrkede bemandingen i supporten den første uge.
Under den rigtige go-live dukkede en datafejl op, men fordi den lå langt under rollbackgrænsen og supporten var på plads, blev den rettet på en time uden at nogen behøvede at gå tilbage. Skiftet blev oplevet som udramatisk netop fordi dramatikken var planlagt væk på forhånd.
En gennemtænkt idriftsættelse er en billig forsikring mod en dyr weekend. Skal I skifte et forretningskritisk system, hjælper vi hos Weapp gerne med at planlægge go-live. Kontakt os med en beskrivelse af hvad I skal skifte.
Ofte stillede spørgsmål
Hvad er forskellen på big bang og paralleldrift?
Big bang betyder at alle skifter til det nye system på et fastlagt tidspunkt, og at det gamle bliver lukket. Paralleldrift betyder at begge systemer kører samtidig i en periode mens brugerne gradvist flytter over. Big bang er hurtigere og billigere, men mere risikabelt. Paralleldrift er tryggere, men dyrere og mere krævende at holde kørende. Valget afhænger af hvor forretningskritisk systemet er.
Har vi virkelig brug for en generalprøve?
Ja, for et forretningskritisk system er det svært at begrunde at springe den over. En prøvekørsel af hele idriftsættelsen i et testmiljø afslører de fejl der ellers dukker op midt i den rigtige go-live: at et trin tager længere tid end ventet, at data ikke flytter rent, at en adgangsrettighed mangler. Det er billigere at finde det ved en generalprøve end klokken tre om natten under den rigtige go-live.
Hvornår skal vi beslutte at gå tilbage til det gamle system?
Beslut det før idriftsættelsen, ikke undervejs. Fastlæg konkrete kriterier på forhånd (hvilke fejl eller forsinkelser der udløser en rollback), og udpeg hvem der træffer beslutningen. Uden fastlagte grænser bliver rollbackbeslutninger truffet i panik eller for sent når skaden allerede er sket. En tydelig grænse gør at nogen tør trække i nødbremsen i tide.
Hvor længe har vi brug for forstærket support efter go-live?
De første dage er de mest intensive, men regn med skærpet beredskab i mindst et par uger. Det er i den periode de reelle brugsmønstre møder systemet, og problemer som ingen test fangede, dukker op. Hav udviklere til rådighed til hurtige rettelser og en tydelig kanal til brugernes spørgsmål så små fejl ikke når at blive til tillidskriser.