Slik lykkes du med implementering av nytt system

Slik lykkes du med implementering av nytt system

Vi har skrevet tidligere om fallgruvene ved å bytte PMS eller eventsystem — timing, datamigrering, glemte integrasjoner. Dette innlegget handler om noe litt annet: hva som faktisk gjør at en implementering lykkes, ikke bare unngår de verste fellene. Og det gjelder ikke bare PMS og eventsystem. Vi har sett akkurat de samme mønstrene i alt fra nye kassasystemer til nye HR-verktøy — den underliggende dynamikken er overraskende lik uansett hva slags system det er snakk om.

Den korte versjonen, før vi går i detalj: et systembytte lykkes sjelden fordi programvaren er god. Det lykkes fordi noen internt faktisk eier prosessen, fordi innføringen følger en plan i stedet for å skje litt av gangen når det passer, og fordi de ansatte som skal bruke systemet daglig, får reell tid til å lære det — ikke bare en times gjennomgang rett før det går live.

Eierskap: noen må faktisk ville dette

Det aller vanligste vi ser gå galt, skjer allerede før implementeringen starter: prosjektet får ingen tydelig eier internt. Det blir en oppgave som "IT tar seg av", eller noe som ledelsen har bestilt og som ansatte forventes å bare begynne å bruke en dag. Ingen av delene fungerer særlig godt i praksis.

Et systembytte som lykkes, har som regel én navngitt person internt som faktisk eier det — ikke som en tittel på et organisasjonskart, men som noen som har fått satt av reell tid til det, som kjenner både det gamle og det nye systemet godt nok til å stille kritiske spørsmål til leverandøren, og som har mandat til å ta beslutninger underveis uten å måtte eskalere alt oppover. Denne personen trenger ikke være IT-ansvarlig. På et konferansehotell er det ofte driftssjefen, en resepsjonssjef med interesse for systemer, eller en salgsansvarlig — noen som forstår hverdagen systemet skal fungere i.

Det som ofte glemmer seg bort, er at denne rollen koster noe reelt: tid vekk fra andre oppgaver, i en periode der vedkommende sannsynligvis allerede har nok å gjøre. Hvis implementeringen blir en ekstra oppgave oppå en full stilling, uten at noe annet letter samtidig, blir den sjelden gjort grundig, uansett hvor motivert personen er i utgangspunktet.

En plan, ikke en følelse av at det "bare skal skje"

Den nest vanligste fellen er at implementeringen ikke egentlig følger noen plan — den skjer litt her og litt der, etter hvert som noen har tid. Det høres ufarlig ut, men uten en tydelig struktur er det lett å oppdage, tre uker inn i prosjektet, at ingen egentlig vet hva som er gjort og hva som gjenstår.

En strukturert tilnærming trenger ikke være tung eller byråkratisk. Det holder ofte med noe så enkelt som:

Kartlegging — hva gjør vi i dag, konkret, og hva av det må systemet faktisk løse? Konfigurasjon — sette opp systemet med egne rom, priser, roller og rutiner, ikke bare akseptere standardoppsettet. Test med ekte data — kjør reelle scenarioer, ikke bare eksempeldata leverandøren har forberedt. Opplæring — se eget punkt under. Go-live med en definert dato — ikke en flytende overgang uten noe klart startpunkt. Oppfølging — en periode etter oppstart der avvik samles opp og rettes systematisk, i stedet for å bli glemt fordi alle er glade for at systemet endelig er i drift.

Poenget med en slik struktur er ikke å følge en mal for malens skyld. Det er at hver fase har et tydelig "dette er ferdig når"-punkt, slik at ingen antar noe er på plass som faktisk ikke er det.

Superbrukere: den mest undervurderte investeringen i hele prosjektet

Vi nevnte dette kort i forrige innlegg, men det fortjener mer plass, fordi det er trolig det enkelttiltaket som gir mest igjen for pengene. Identifiser 2–4 ansatte tidlig i prosjektet — gjerne folk fra ulike roller, ikke bare fra ledelsen — og gi dem vesentlig mer opplæringstid enn resten av staben.

Disse superbrukerne blir det første stoppestedet når en kollega står fast, i stedet for at alt går til leverandørens support eller til den ene personen som "kan systemet" og fort blir en flaskehals. De fanger opp reelle spørsmål fra egen drift, ikke bare fra en generisk demo, og de er ofte de som først oppdager om noe i konfigurasjonen faktisk ikke stemmer med hvordan dere jobber.

Det som gjør superbrukere effektive, er ikke bare at de kan systemet — det er at de er noen kollegene allerede stoler på og spør uansett. Velg derfor ikke nødvendigvis den mest tekniske personen i teamet, men den som andre naturlig går til når noe er uklart. Og gi dem noe konkret igjen for innsatsen — det er en ekstra byrde i en periode, og det bør anerkjennes som det, enten gjennom avlastning andre steder, en tydelig rolle videre, eller rett og slett at ledelsen sier høyt at dette er verdsatt.

Opplæring er ikke én økt. Det er en kontinuerlig investering.

En vanlig antakelse er at opplæring er noe som skjer én gang, gjerne rett før systemet går live — en dag med gjennomgang, kanskje en video å se på egen hånd. Det fungerer for å forstå hvor knappene er. Det fungerer sjelden for å faktisk kunne håndtere en travel fredag tre uker senere, når det er noe helt annet enn det som ble vist i opplæringen.

Det som fungerer bedre, er å tenke på opplæring som en periode, ikke en hendelse: en innledende gjennomgang av grunnfunksjonene, etterfulgt av noen uker der ansatte bruker systemet på ekte oppgaver med en superbruker eller erfaren kollega lett tilgjengelig, og gjerne en kort oppfriskningsøkt noen uker inn i driften når de første reelle spørsmålene har dukket opp — spørsmål ingen kunne forutse før systemet faktisk ble brukt i praksis.

Dette er spesielt viktig for virksomheter med mange vikarer og sesongansatte, som ikke har samme mulighet til å bygge opp erfaring over måneder som en fast ansatt ville hatt. Vurder om det finnes en enkel, skriftlig rutinebeskrivelse superbrukerne kan vise til, i stedet for at alt må forklares muntlig hver gang en ny vikar starter.

Det som faktisk avgjør.

Hvis vi skal koke det ned: et systembytte som lykkes har som regel noen som faktisk eier det internt, en plan med tydelige faser i stedet for en løs følelse av fremdrift, noen få superbrukere som får reell tid og anerkjennelse, og en opplæringsperiode i stedet for en opplæringsdag. Ingen av disse tingene koster noe å bestemme seg for. De koster tid — og det er nettopp derfor de så ofte blir nedprioritert til fordel for det som haster mer i øyeblikket, selv om det er akkurat disse tingene som avgjør om implementeringen faktisk lander godt.