Kravspesifikasjon for LMS: mal og evalueringsmatrise

Når en LMS-anskaffelse går galt, er det sjelden fordi teamet stilte for få spørsmål til leverandørene. Som regel stilte det altfor mange. Noen maler inneholder flere hundre spørsmål, og resultatet er forutsigbart: leverandørene svarer med klipp og lim, teamet drukner i svar ingen klarer å sammenligne, og til slutt tas beslutningen på magefølelse likevel.

Denne siden er laget som et verktøy du kan ta i bruk med en gang. Du får en kravspesifikasjon til nedlasting med rundt 50 spørsmål som faktisk skiller leverandørene fra hverandre, og en vektet evalueringsmatrise som lar deg poengsette svarene på like vilkår. Har du ikke kommet så langt ennå, og lurer fortsatt på hva du egentlig trenger, bør du begynne med hvordan du velger riktig LMS for bedriften eller, for større organisasjoner, hvordan du velger et enterprise-LMS. Kom tilbake hit når spørsmålene skal ut til leverandørene.

Last ned malen for kravspesifikasjon

Last ned kravspesifikasjonsmalen (docx). Den inneholder alt du trenger for en strukturert LMS-anskaffelse:

• en forside med instruksjoner som du tilpasser på noen minutter
• to avsnitt du fyller ut selv: bakgrunn om organisasjonen, og mål og bruksområder
• åtte spørsmålsavsnitt: funksjonalitet, teknologi, sikkerhet, implementering, support, pris, exit-vilkår og leverandørens bakgrunn
• en vektet evalueringsmatrise med foreslåtte standardvekter, klar til å poengsette tre leverandører side om side

At malen kommer som docx, er et bevisst valg. Stryk spørsmålene som ikke gjelder deg, legg til dem som mangler, og gjør den til din egen. En kortere og skarpere kravspesifikasjon gir bedre svar enn en lang. Hvert spørsmål du fjerner, er lesetid du får tilbake, ganget med antall leverandører du sender den til.

Hva er forskjellen på kravspesifikasjon, RFI og RFP?

Kravlisten er det interne dokumentet ditt. Der står hva plattformen må kunne, for hvem og hvorfor. En RFI (request for information) er en tidlig og uformell henvendelse til en bredere liste med leverandører, som du bruker til å forstå markedet og sette sammen en shortlist. Kravspesifikasjonen, det som på engelsk kalles RFP (request for proposal), er det formelle dokumentet du sender til leverandørene på shortlisten. Den inneholder konkrete spørsmål, en svarfrist og en strukturert måte å sammenligne svarene på.

Du trenger ikke alltid alle tre. Ved et mindre kjøp holder det ofte med en gjennomarbeidet kravliste og et par godt forberedte demoer. Den formelle kravspesifikasjonen gjør nytte for seg når flere interessenter skal bli enige, når anskaffelsesregler gjelder, eller når avtalen er stor nok til at et feilvalg svir i flere år. Er du fortsatt usikker på hva et LMS i det hele tatt skal gjøre for deg, bør du få grunnlaget på plass før du skriver et eneste krav.

Start med kravene, ikke med spørsmålslisten

Definer dine egne krav før du skriver ett eneste spørsmål til en leverandør. De fleste team hopper over dette trinnet, og det er nettopp der det avgjøres om kravspesifikasjonen kommer til å fungere.

Sett opp kravene i to kolonner. Et skal-krav slår ut plattformen hvis det mangler. Et bør-krav gir poeng i matrisen, men slår ingen ut. Vær ærlig om hva som hører hjemme hvor. Når alt er skal-krav, er ingenting det, og da ender du med å sammenligne leverandører på funksjoner ingen bruker etter et par måneder.

Tre ting som hjelper:

• Knytt hvert krav til et reelt bruksområde. «SSO via identitetsleverandøren vår, fordi IT krever det» er et krav. «AI-funksjoner» blir først et krav når du kan si hvilket problem de skal løse.
• Spør dem som skal jobbe i plattformen hver dag, altså administratorene som bygger kurs og deltakerne som gjennomfører dem. Det som skaper friksjon i arbeidshverdagen deres, sier mer enn en funksjonstabell.
• Sett et tak for skal-kravene. Blir det flere enn rundt ti, er noen av dem bør-krav i forkledning.

Skal-kravene avgjør hvem som får være med videre. Hvor godt leverandørene oppfyller dem, sammen med bør-kravene dine, er det du gir poeng for i matrisen. Mer komplisert er det ikke.

Utvalgskriterier for LMS: slik fungerer den vektede evalueringsmatrisen

Utvalgskriteriene vekter du før svarene kommer inn. Gir du alt samme vekt, vinner gjerne plattformen med den lengste funksjonslisten. Den som folk faktisk kommer til å bruke, kan være en helt annen. Matrisen løser dette, forutsatt at du og teamet blir enige om vektene før leverandørene svarer. Setter du dem i etterkant, blir de fort justert slik at favoritten til noen vinner.

Slik fungerer det:

1. Bli enige i teamet om kriteriene, og gi hvert av dem en prosentvekt. Summen skal bli 100 %.
2. Når svarene kommer inn, gir du hver leverandør en poengsum fra 1 til 5 per kriterium.
3. Gang poengsummen med vekten, og summer kolonnen. Høyeste mulige vektede totalpoeng er 5,0.

Matrisen har foreslåtte standardvekter. Brukervennlighet og funksjonell dekning veier tyngst, deretter integrasjoner og sikkerhet, så support, pris, implementering og exit-vilkår. Bruk dem som et utgangspunkt. En strengt regulert organisasjon vekter sikkerheten opp. Et L&D-team på én person vekter brukervennligheten enda tyngre. De nøyaktige tallene betyr mindre enn at du og teamet kranglet om dem åpent, én gang, før svarene fra leverandørene kunne farge diskusjonen.

Hva inneholder malen?

Malen har ti avsnitt, pluss evalueringsmatrisen. De to første fyller du ut selv, resten er spørsmål til leverandøren.

1. Om organisasjonen din og omfanget. Hvem du er, hvor mange deltakere og administratorer, og tidsplanen din. Leverandører svarer bedre når de vet hvem som spør.
2. Mål og bruksområder. Hva du vil oppnå: onboarding, compliance-opplæring, kundeopplæring, kompetanseutvikling.
3. Funksjonelle krav. Hvordan du bygger, leverer, automatiserer og følger opp kurs.
4. Tekniske krav og integrasjoner. API, SSO, synkronisering med HR-systemet og e-læringsstandarder som SCORM, xAPI og cmi5.
5. Sikkerhet og datalagring. Hvor dataene lagres, og hvem som har tilgang til dem (mer om det nedenfor).
6. Implementering og onboarding. Hvordan veien fra signert avtale til det første kurset er ute hos deltakerne, faktisk ser ut.
7. Support og partnerskap. Hvem som svarer når noe slutter å virke, og hvor raskt.
8. Pris og totalkostnad. Hele bildet, inkludert kostnadene som ikke står på prissiden.
9. Exit og dataportabilitet. Vilkårene dine for å si opp avtalen, forhandlet mens du fortsatt har noe å forhandle med.
10. Leverandørens bakgrunn og referanser. Eierforhold, stabilitet og referansekunder du kan ringe, helst noen som ligner organisasjonen din.

Sikkerhet og datalagring: spørsmål du bør stille hver leverandør

Du trenger ikke være sikkerhetsekspert for å komme gjennom dette avsnittet. Du trenger en håndfull direkte spørsmål og tålmodighet nok til å kreve direkte svar.

Spør hvor dataene lagres fysisk, og under hvilken jurisdiksjon hostingleverandøren opererer. For europeiske organisasjoner er EU/EØS-hosting et standardspørsmål til alle på listen, siden lagringsstedet avgjør hvilke lover som gjelder for dataene. Spør hvem som eier dataene (og svaret skal være deg, uten forbehold), hvilke underdatabehandlere som er involvert og hvor de behandler data, og hvordan leverandøren håndterer GDPR i praksis: databehandleravtale, de registrertes rettigheter og sletting.

Be deretter om dokumentasjon i stedet for adjektiver. Hvilke sikkerhetsrammeverk følger leverandøren, og hva kan de legge frem? For eksempel revisjonsrapporter, sammendrag av penetrasjonstester og en prosess for hendelseshåndtering med forpliktende frister for å varsle deg. En leverandør som svarer klart og skriftlig på dette, forteller deg mye om hva slags partner de kommer til å bli.

Spørsmål om integrasjoner og teknisk arkitektur

Et LMS står aldri alene. Det skal spille sammen med identitetsleverandøren din, sannsynligvis HR-systemet og kanskje CRM-systemet. Malens tekniske avsnitt handler først og fremst om fire ting: om det finnes et dokumentert, åpent API og hva det dekker, hvilke SSO-standarder som støttes, hvordan brukere opprettes og fjernes automatisk, og hvilke e-læringsstandarder (SCORM, xAPI, cmi5) plattformen kan importere og eksportere.

Et praktisk tips er å be leverandørene beskrive en reell integrasjon med et system som ligner ditt. Å bekrefte at integrasjon er «mulig» sier lite, for nesten alt er mulig. Det du kjøper, er hvor mye som fungerer fra start, og hvor mye som blir et konsulentprosjekt.

Spørsmål om support og implementering

To plattformer med identiske funksjonslister kan gi helt ulike opplevelser, og forskjellen viser seg som regel her. Malen ber leverandørene beskrive en typisk tidsplan for implementeringen, fra signert avtale til det første kurset er ute hos deltakerne, hva som er inkludert og hva som koster ekstra, hvem i teamet deres du får jobbe med, og hvilken opplæring administratorene dine får.

Spørsmålene om support er konkrete med hensikt. Hvilke kanaler og åpningstider, hvilke språk, er svartidene avtalefestet, og får du en navngitt kontaktperson eller en supportkø? Hos oss på Learnifier har vi bygd hele modellen rundt mennesker du kan få tak i, så vi er ikke nøytrale her. Vi mener dette avsnittet fortjener mer vekt enn de fleste kjøpere gir det. Vurder likevel hver leverandør, oss inkludert, etter det de skriver ned.

Hva som skjer etter at du har signert, og hvordan du får plattformen til å bli brukt i praksis, finner du i sjekklisten for LMS-implementering.

Exit-vilkår og dataportabilitet: beskytt din neste migrering

Forhandle exit-vilkårene før du signerer, mens du fortsatt har noe å forhandle med og leverandøren ønsker deg som kunde. Ingen planlegger å si opp avtalen, og nettopp derfor hopper de fleste over klausulen. Etterpå står du overfor en leverandør som tjener lite på å gjøre byttet enkelt for deg.

Malen spør: hvilke data kan du eksportere, i hvilke formater, og kan du gjøre det selv uten å måtte gå via support? Hva skjer med kursinnhold og media ved oppsigelse? Hva koster det å få hjelp til å flytte dataene ut? Når og hvordan slettes dataene dine, og hvordan bekreftes slettingen? Og står en definert exit-prosess i selve avtalen, eller bare i salgssamtalen?

Sitter du allerede fast i en plattform som gjør det vanskelig å bytte leverandør, går vår guide til å bytte LMS gjennom hvordan du kommer deg ut på en ryddig måte.

Sjekkliste for evaluering: slik sender du kravspesifikasjonen og sammenligner svarene rettferdig

Du har definert kravene, kuttet i spørsmålslisten og satt vektene. Det som gjenstår, er disiplin i prosessen.

1. Send til mellom tre og fem leverandører. Færre gir ingen reell sammenligning. Flere gir bare mer å lese, uten at beslutningen blir bedre.
2. Samme dokument, samme frist, samme informasjon. Får én leverandør en avklaring, skal alle få den samme.
3. Poengsett individuelt først. La hver enkelt i teamet fylle ut matrisen på egen hånd, og sammenlign etterpå. Slik får du frem ekte uenighet før alle har lagt seg på linje med den som snakker høyest.
4. La demoene handle om dine scenarier. Gi leverandørene på shortlisten to eller tre av dine reelle bruksområder, og be dem vise hvordan det løses i plattformen, ikke bare beskrive det.
5. Bruk den vektede totalpoengsummen til å styre diskusjonen, ikke til å avslutte den. Ligger to leverandører tett, viser matrisen nøyaktig hvor forskjellen ligger. Det er det den siste samtalen bør handle om.

Last ned malen, sett av en time med teamet til å krangle litt om vektene, så har du gjort det vanskeligste før en eneste leverandør har svart.