Hvordan implementere et LMS? Sjekkliste og 90-dagersplan

Spør fem LMS-leverandører hvor lang tid implementeringen tar, og du får det samme svaret: tre til ni måneder. Det spennet gjør mye jobb. Det beskytter trege leverandører, det senker forventningene dine, og det gjør i stillhet et oversiktlig prosjekt om til et maraton.

Her er et annet utgangspunkt: for de fleste organisasjoner er 90 dager fra signert kontrakt til live plattform realistisk. Ikke forhastet, ikke heroisk. Realistisk. Moderne skyplattformer er teknisk klare på dager. Det som tar tid, er alt rundt teknologien: beslutninger, innhold, mennesker og kommunikasjon. Det er nettopp det denne sjekklisten er bygget rundt.

Ett ærlig forbehold før vi starter. Skal du rulle ut til titusenvis av deltakere i mange land, med spesialbygde integrasjoner og compliance-krav i flere lag, vil tidslinjen strekke seg forbi 90 dager. Vi flagger underveis hvor den typen kompleksitet legger til tid. For alle andre er planen under laget for å få deg live i løpet av et kvartal.

Hva bør en sjekkliste for LMS-implementering faktisk dekke?

En sjekkliste for LMS-implementering er den komplette listen over beslutninger, oppgaver og milepæler mellom signert kontrakt og live opplæring på plattformen. En nyttig sjekkliste dekker fem områder: forberedelse (mål, budsjett og omfang), mennesker (teamet ditt og leverandørens), plattform (teknisk oppsett og integrasjoner), innhold (hva du migrerer og hva du bygger nytt) og bevis (pilot, lansering og måling).

De fleste sjekklister du finner på nettet, feiler på den siste delen. De er lister over oppgaver: konfigurer SSO, last opp kurs, send invitasjoner. Hver boks blir krysset av, og tre måneder senere bruker ingen plattformen. Problemet er ikke oppgavene. Det er at oppgaver ikke er resultater. "Konfigurer SSO" forteller deg hva du skal gjøre. Det forteller deg ikke at ferdig betyr at en ny deltaker logger inn på første forsøk uten en supporthenvendelse.

Derfor avslutter hver fase i denne guiden med et resultat du kan verifisere, ikke bare en boks du kan krysse av. Det er forskjellen på en implementering som er ferdig og en som fungerte.

Start implementeringsplanen før dag én: mål, budsjett og omfang

Implementeringsplanen din starter før du rører plattformen. Tre beslutninger du tar nå, former alt som kommer etterpå.

Definer hvordan suksess ser ut. "Lansere LMS-et" er ikke et mål, det er en oppgave. Et ekte mål høres slik ut: hver nyansatt fullfører onboarding-opplæringen innen to uker etter oppstart, eller all compliance training er sporet og rapporterbar innen utgangen av kvartalet. Skriv ned to eller tre slike, hver med et tall og en dato. De blir målene dine for dag 30, 60 og 90 senere, og de avgjør overraskende mange diskusjoner underveis.

Budsjetter utover lisensen. Lisensavgiften er den synlige kostnaden. De mindre synlige kostnadene er teamets timer, produksjon eller konvertering av innhold, eventuelt integrasjonsarbeid, og tid til å lære opp administratorer og ledere. Ingen av dem trenger å være store, men ubudsjettert arbeid er den vanligste kilden til forsinkelser. Sett et grovt tall på hver av dem nå.

Avgrens første leveranse nådeløst. Du trenger ikke alle målgrupper, alle kurs og alle integrasjoner på dag én. Velg bruksområdet med den tydeligste verdien, ofte onboarding eller compliance training, lanser det skikkelig, og bygg videre derfra. En liten lansering som fungerer, bygger langt mer momentum enn en stor lansering som halter.

Og hvis du leser dette før du faktisk har signert med en leverandør: start med guiden vår om hvordan du velger riktig LMS, og bruk en strukturert kravprosess som den i vår kravspesifikasjonsmal for LMS, slik at plattformen du velger, kan bære planen du er i ferd med å legge.

Hvem bør være med i implementeringsteamet?

Et implementeringsteam er ikke en avdeling. I de fleste organisasjoner er det en håndfull mennesker som gir deler av uken sin i ett kvartal. Det som betyr noe, er at hver rolle har et navn knyttet til seg.

• Prosjekteier. Driver tidslinjen, tar beslutninger i hverdagen og eskalerer det som står fast. Den mest involverte rollen: regn med flere timer i uken gjennom hele 90-dagersperioden.
• Sponsor i ledelsen. Fjerner hindringer og signaliserer at plattformen betyr noe. En time eller to ved viktige milepæler holder, men den timen er ikke valgfri.
• LMS-administrator. Lærer plattformen i dybden, eier konfigurasjonen og blir personen alle går til etter lansering. Tyngst arbeidsmengde i uke én til fire.
• Innholdseier. Bestemmer hva som migreres, hva som bygges på nytt og hva som pensjoneres. Har det travlest midt i prosjektet.
• IT-kontakt. Trengs for SSO og eventuell integrasjon mot HR-systemet. På en moderne skyplattform er dette vanligvis dager med arbeid totalt, ikke uker, men book kalenderen tidlig.
• Kommunikasjonsansvarlig. Eier lanseringskampanjen og lederengasjementet. Lett arbeidsmengde tidlig, tung den siste måneden.

I en liten organisasjon kan én person dekke tre av rollene, og det er helt greit. Sjekklisten krymper ikke, men møtene gjør det.

Så finnes det en sjuende rolle, og det er den de fleste implementeringsguider hopper helt over: personen på leverandørens side. Still hver eneste leverandør ett spørsmål: hvem, med navn, skal vi jobbe med under implementeringen? Er svaret en ticketkø eller en lenke til et hjelpesenter, har prosjekteieren din nettopp arvet en jobb til. En navngitt kontakt som kjenner kontoen din, målene dine og tidslinjen din, endrer formen på hele prosjektet. Vi innrømmer gjerne at vi er partiske her: hos Learnifier jobber kundene med ekte mennesker gjennom oppsett og lansering, for vi har aldri sett programvare implementere seg selv. Uansett hvilken leverandør du velger: gjør den navngitte kontakten til et krav, ikke noe som bare er kjekt å ha.

Hvordan ser en 90-dagers prosjektplan for LMS-implementering ut?

Her er tidslinjen i korte trekk, fase for fase. Hver fase avsluttes med et resultat du kan sjekke.

Og nei, et kvartal er ingen fantasi. Mange organisasjoner klarer det, og forskjellen mellom den raske gruppen og den trege er sjelden programvaren. Det er planen.

Dag 1 til 7: fundamentet

Få det tekniske grunnlaget live. Plattformen er satt opp med profilen din, SSO er koblet til (eller testkontoer er klare), administratorene dine har tilgang, og du har holdt kickoff med leverandørkontakten din for å låse milepælskalenderen. Resultat: administratoren din kan logge inn og bygge et testkurs uten hjelp.

Uke 2 til 4: bygg og forbered piloten

Sett opp roller og tilganger, koble til eventuelle integrasjoner, legg inn det første ekte innholdet, og rekrutter pilotgruppen. Det er her LMS-administratoren og innholdseieren gjør seg fortjent til lønnen. Resultat: en pilotklar plattform med ekte innhold i, ikke plassholdertekst.

Dag 30: piloten er live

En representativ gruppe bruker plattformen til reell opplæring. Jobben din nå er å observere, lytte og samle tilbakemeldinger raskt. Resultat: en rangert liste over ting som må fikses, sortert i "før lansering" og "senere".

Dag 60: full lansering

Fiksene er på plass, lanseringskampanjen ruller, og alle deltakerne i målgruppen er invitert. Resultat: alle i omfanget har fått invitasjon, og den første bølgen av aktivitet er i gang.

Dag 90: mål og juster

Hold resultatene opp mot målene du skrev før dag én. Bestem hva som skal fikses og hva som skal utvides. Resultat: en kort skriftlig gjennomgang som sammenligner virkeligheten med planen.

Er du på enterprise-nivå, endres ikke fasene, men kalenderen gjør det. Kanskje kjører du pilot per region i stedet for én gang, sikkerhetsgjennomganger parallelt med byggingen, og lanseringer land for land. Rekkefølgen over gjelder fortsatt. Det er den ærlige versjonen av forbeholdet: kompleksitet strekker tidslinjen, den skriver ikke om planen.

Teknisk oppsett: SSO, roller, profil og integrasjoner

På et moderne sky-LMS er den tekniske sjekklisten kortere enn du frykter. Fire områder trenger beslutninger, ikke måneder.

Single sign-on. Koble plattformen til identitetsleverandøren din, slik at deltakerne aldri trenger å håndtere et eget passord. Friksjon ved innlogging er den stilleste adopsjonsdreperen som finnes, og SSO fjerner det meste av den i ett grep.

Brukerprovisjonering. Bestem hvordan folk får kontoer: synkronisert fra HR-systemet, lagt til manuelt eller selvregistrert. Du kan blande tilnærminger per målgruppe. Automatiser den største gruppen først.

Roller og tilganger. Hvem lager innhold, hvem administrerer, hvem tar ut rapporter? Start enkelt. Å legge til flere nivåer senere er lett; å nøste opp en overkonstruert tilgangsstruktur er det ikke.

Profil og språk. Sørg for at plattformen ser ut og høres ut som dere fra første innlogging. Og jobber deltakerne dine på flere språk, sjekk språkstøtten i grensesnittet tidlig i stedet for ved lansering. Det er en detalj det gjør vondt å oppdage sent. (Til referanse: Learnifier støtter 26+ språk, og alle data lagres på EU-servere i Sverige. Uansett hvor du lander, still leverandøren begge spørsmålene: hvilke språk, og hvor lagres dataene våre.)

Book IT-kontakten din til SSO- og provisjoneringsarbeidet i uke én, selv om selve arbeidet skjer i uke tre. Å vente på ledig kalendertid er den mest unngåelige forsinkelsen i hele denne planen.

Innholdsmigrering: hva flyttes, hva bygges på nytt, hva pensjoneres

Migrering er stedet der tidslinjer drar for å dø. Ikke fordi det er teknisk vanskelig å flytte innhold, men fordi "flytt alt" er standardvalget ingen stiller spørsmål ved. Spør hvem som helst som har gjort det, så kommer den samme angeren igjen: de skulle ønske de hadde satt av mer tid til selve migreringen, og mer tid til å lære opp folk da den først var på plass.

Start med en gjennomgang av det eksisterende innholdet ditt og sorter det i tre bunker:

• Flytt som det er. Obligatorisk compliance training, gjeldende onboarding-materiell og de mest brukte kursene dine. Dette er lanseringskatalogen din.
• Bygg på nytt. Innhold som betyr noe, men som har eldes dårlig. Gamle timelange kurs fortjener ofte å bli korte, mobilvennlige moduler i stedet for å kopieres over som de er. Migreringen er den beste unnskyldningen du noen gang får til å forbedre dem.
• Pensjoner. Alt ingen har rørt på et år. Vær modig her. En liten, skarp katalog ved lansering slår hundrevis av kurs av varierende kvalitet, for førsteinntrykket av plattformen er innholdet folk finner i den.

Gjør den samme sorteringen med historiske opplæringsdata. Fullførte compliance-kurs må bli med. Hver eneste quizpoengsum fra fem år tilbake trenger sannsynligvis ikke det. Bestem hva du faktisk trenger å rapportere på fremover, og migrer det.

Flytter du fra et eksisterende LMS i stedet for å starte fra null, kommer et lag av eksportformater, SCORM-pakker og håndtering av historikk på toppen av dette. Det har vi dekket i detalj i vår guide til å bytte LMS.

Hvorfor kjøre en pilot før du lanserer til alle?

Fordi en pilot finner problemene dine mens publikummet fortsatt er lite og tilgivende.

Kjør den i to til fire uker med en representativ gruppe. Ikke bare L&D-entusiastene som ville elsket enhver plattform, men en reell blanding: noen skeptikere, et par ledere, folk på mobil, folk i ulike roller. Hvis skeptikerne snur, har du lært noe. Hvis de ikke gjør det, har du lært noe enda nyttigere.

Test øyeblikkene som avgjør adopsjonen: fungerer innloggingen på første forsøk, finner folk opplæringen sin uten instruksjoner, fungerer innholdet på mobil, lander varslene der folk faktisk ser? Samle deretter tilbakemeldinger raskt, og enda viktigere: vis synlig at du handler på dem. Ingenting bygger goodwill som at noen ser klagen sin fikset i løpet av en uke.

Piloten har en jobb nummer to som er lett å overse: den produserer lanseringshistorien din. Pilotdeltakerne blir ambassadører som svarer på kollegenes spørsmål, og de ærlige sitatene deres ("det tok meg to minutter å finne kurset mitt") er verdt mer i lanseringsbudskapet enn noe prosjektteamet kunne skrevet selv.

Lanseringsdagen: kommunikasjon slår konfigurasjon

På lanseringsdagen er plattformarbeidet gjort, og menneskearbeidet begynner. Dette er fasen der teknisk perfekte implementeringer feiler i stillhet, fordi teamet behandler lanseringen som en e-post i stedet for en kampanje. Å hoppe over en skikkelig plan for endringsledelse er angeren som dukker opp oftest i etterkant.

En lanseringskampanje har noen få bevegelige deler, og ingen av dem er kompliserte:

• En teaser før lansering. La folk høre om plattformen før de blir bedt om å bruke den.
• Lederne brifes først. Deltakere gjør det lederen deres nevner, ikke det en systemgenerert e-post ber om. Gi lederne et manus på ett avsnitt og be dem si det på neste teammøte.
• Et lanseringsbudskap som svarer på "hva får jeg ut av det". Ikke hva plattformen er, men hva den gjør for den som leser: finn opplæringen din på ett sted, på hvilken som helst enhet, uten å spørre noen.
• En enkel første oppgave. Be alle logge inn og fullføre én kort, relevant aktivitet den første uken. Første innlogging er frøet til vanen; gjør den første helt friksjonsfri.
• En kanal for tilbakemeldinger. Ett synlig sted å melde fra om problemer, med raske svar, hindrer at små irritasjoner blir til varig rykte.

Hold det hele menneskelig og kort. Du annonserer ikke et system. Du inviterer folk til noe som gjør uken deres litt enklere.

Hva er de vanligste feilene ved LMS-implementering?

Hver eneste av disse kan unngås, og hver eneste av dem dukker opp hele tiden. Innsatsen er reell: i 2020 fant Brandon Hall Group at 42 % av selskapene aktivt lette etter en erstatning for LMS-et sitt. Mange av de plattformene feilet ikke på funksjoner. De feilet på utrullingen.

1. Å behandle det som et IT-prosjekt. Teknologien er den enkle delen. Når prosjektteamet er helteknisk og ingen eier adopsjonen, får du en perfekt konfigurert plattform ingen besøker.
2. Å migrere alt. En oppblåst, utdatert katalog ved lansering forteller deltakerne at den nye plattformen er det gamle rotet med ny logo.
3. Å hoppe over piloten. Hvert problem en pilot ville fanget opp, blir funnet uansett, bare av hele organisasjonen på en gang.
4. Å lansere uten et adopsjonsmål. Hvis suksess aldri ble definert, blir "vi har lansert" målstreken, og bruken glir stille nedover etter uke to uten at noen står ansvarlig.
5. Ingen eier etter go-live. Prosjektteamet oppløses, og seks måneder senere vet ingen hvem som legger til kurs eller svarer på spørsmål. Utnevn eieren for tiden etter lansering før lanseringen, ikke etter.
6. Å implementere seg ut av et dårlig valg. Noen implementeringsfeil var utvelgelsesfeil i forkledning. Ingen utrullingsplan redder en plattform som ikke passer med hvordan organisasjonen din faktisk jobber. Derfor fortjener valgfasen like mye grundighet som lanseringen.

Kjenner du igjen organisasjonen din i et par av disse, er det ingen dom. Det er sjekklisten din for de neste 90 dagene.

Etter dag 90: mål det som betyr noe, og utvid deretter

Lanseringen er ikke resultatet. Resultatet er det målingene dine sier etterpå, sjekket mot målene du skrev før dag én.

• Dag 30: aktivering. Hvor stor andel av de inviterte deltakerne har logget inn og fullført sin første aktivitet? Les supporthenvendelsene for mønstre, ikke volum.
• Dag 60: engasjement. Fullfører folk kjerneopplæringen, og er lederne involvert, eller toppet aktiviteten seg ved lansering og dabbet av? At det dabber av er normalt; å ignorere det er feilen.
• Dag 90: resultater. Sett deg ned med de opprinnelige målene og skriv den ærlige gjennomgangen. Hva traff, hva bommet, og hva er den ene viktigste fiksen for neste kvartal?

Bruk deretter momentumet. Organisasjonene som får mest ut av en læringsplattform, behandler go-live som første leveranse, ikke som målstreken: neste målgruppe, neste bruksområde, fra compliance til onboarding, fra obligatorisk opplæring til læring folk faktisk oppsøker.

Det neste steget ditt tar ikke 90 dager. Det tar rundt 30 minutter: skriv ned de to eller tre suksessmålene dine og sett navn på teamrollene over. Da er dag null unnagjort. Og når du sammenligner leverandører, legg 90-dagersplanen på bordet og be hver av dem gå gjennom sin side av den, uke for uke, med en navngitt kontakt knyttet til. Vil du se hvordan den første uken ser ut i praksis, er det akkurat den typen ting vi gjerne viser i en Learnifier-demo, med ditt bruksområde i stedet for et innøvd manus.