Den vanligaste orsaken till att en LMS-upphandling spårar ur är att teamet ställer för många frågor. Vissa mallar innehåller flera hundra, och du kan nog gissa hur det slutar. Leverantörerna klipper och klistrar ur gamla svar, teamet drunknar i dokument som inte går att ställa bredvid varandra, och till sist fattas beslutet på magkänsla ändå.
Den här sidan ska fungera som ett verktyg, inte som ännu en guide. Du får en nedladdningsbar kravspecifikation med ungefär 50 frågor som faktiskt skiljer leverantörerna åt, och en viktad utvärderingsmatris som gör att svaren kan poängsättas på samma villkor. Har du inte kommit så långt än och funderar fortfarande på vad du egentligen behöver? Börja då med hur du väljer rätt LMS för ditt företag eller, om organisationen är stor, med hur du väljer ett enterprise-LMS. Kom tillbaka hit när frågorna ska ut till leverantörerna.
Ladda ner mallen för din kravspecifikation
Ladda ner kravspecifikationsmallen (docx). Den innehåller allt du behöver för en strukturerad LMS-upphandling:
- En försättssida med instruktioner som du anpassar på några minuter.
- Två avsnitt du fyller i själv: organisationens bakgrund samt mål och användningsområden.
- Åtta frågeavsnitt: funktionalitet, teknik, säkerhet, implementering, support, pris, exitvillkor och leverantörsbakgrund.
- En viktad utvärderingsmatris med föreslagna standardvikter, där du poängsätter tre leverantörer sida vid sida.
Att mallen är en docx-fil är ett medvetet val. Stryk de frågor som inte gäller dig, lägg till dem som gör det, och gör den till din egen. En kort och vass kravspecifikation ger bättre svar än en lång. Varje fråga du stryker är lästid du får tillbaka, gånger antalet leverantörer du frågar.
Vad är skillnaden mellan kravspecifikation, RFI och RFP?
Kravlistan är ditt interna dokument. Den beskriver vad plattformen måste klara, för vem och varför. En RFI (request for information) är en tidig, informell förfrågan till en bredare lista med leverantörer, för att förstå marknaden och få fram en shortlist. Kravspecifikationen, det som på engelska kallas RFP (request for proposal), är det formella dokument du skickar till leverantörerna på shortlisten: specifika frågor, en deadline och ett strukturerat sätt att jämföra svaren.
Du behöver inte alltid alla tre. Vid ett mindre köp räcker det ofta med en genomarbetad kravlista och ett par väl förberedda demos. Den formella kravspecifikationen gör skäl för sig när flera intressenter ska enas, när upphandlingsregler gäller eller när avtalet är stort nog att ett felval svider i flera år. Vet du ännu inte vad ett LMS ska göra för dig, se då till att grunderna är på plats innan du skriver ett enda krav.
Börja med kraven, inte med frågelistan
Definiera dina egna krav innan du skriver en enda fråga till en leverantör. De flesta team hoppar över det steget, och det är just det steget som avgör om kravspecifikationen kommer att fungera över huvud taget.
Gör det i två kolumner. Ska-krav är sådant som slår ut en plattform om det saknas. Bör-krav ger poäng i matrisen men slår inte ut någon. Var ärlig om vad som hör hemma var. När allt är ska-krav är inget det, och då sitter du och jämför leverantörer på funktioner ingen använder efter ett par månader.
Tre saker som hjälper:
- Knyt varje krav till ett verkligt användningsområde. ”SSO via vår identitetsleverantör, för IT kräver det” är ett krav. ”AI-funktioner” är det först när du kan säga vilket problem de ska lösa.
- Fråga dem som ska jobba i plattformen varje dag, alltså administratörerna som bygger kurserna och deltagarna som går dem. Det som skaver i deras vardag säger mer än någon funktionstabell.
- Sätt ett tak för ska-kraven. Blir listan längre än ungefär tio är några av dem egentligen bör-krav.
Ska-kraven avgör vilka leverantörer som alls går vidare till matrisen. Hur väl de uppfyller dem, och dina bör-krav, är det du sedan poängsätter. Mer än så är det inte.
Utvärderingskriterier för LMS: så fungerar den viktade utvärderingsmatrisen
Vikta utvärderingskriterierna innan svaren kommer in. Ger du allt samma vikt glider valet mot plattformen med längst funktionslista i stället för mot den som folk faktiskt kommer att använda. Matrisen löser det, förutsatt att du och teamet enas om vikterna innan leverantörerna svarat. Sätts de i efterhand hamnar de gärna precis där någons favorit råkar vinna.
Så fungerar det:
- Enas om kriterierna och ge varje kriterium en vikt i procent. Summan ska bli 100 %.
- När svaren kommer in poängsätter du varje leverantör från 1 till 5 per kriterium.
- Multiplicera poängen med vikten och summera kolumnen. Högsta möjliga viktade totalpoäng är 5,0.
Matrisen har föreslagna standardvikter inlagda. Användarvänlighet och funktionell täckning väger tyngst, sedan integrationer och säkerhet, därefter support, pris, implementering och exitvillkor. Se dem som en utgångspunkt att justera. En hårt reglerad organisation viktar upp säkerheten. En ensam utbildningsansvarig viktar användarvänligheten ännu tyngre. De exakta siffrorna betyder mindre än att du och teamet tog diskussionen öppet, en gång, innan leverantörernas svar kunde färga någons omdöme.
Vad innehåller mallen?
Tio avsnitt, plus utvärderingsmatrisen. De två första fyller du i själv, resten är frågor till leverantören.
- Om din organisation och omfattning. Vem du är, hur många deltagare och administratörer det gäller, och din tidsplan. Leverantörer svarar bättre när de vet vem som frågar.
- Mål och användningsområden. Vad du vill uppnå: onboarding, compliance-utbildning, kundutbildning eller kompetensutveckling.
- Funktionella krav. Hur kurser byggs, levereras, automatiseras och följs upp.
- Tekniska krav och integrationer. API, SSO, synk med HR-systemet och e-learningstandarder som SCORM, xAPI och cmi5.
- Säkerhet och datalagring. Var datan lagras och vem som kommer åt den. Mer om det längre ned.
- Implementering och onboarding. Hur vägen från påskrivet avtal till första skarpa kurs ser ut i praktiken.
- Support och partnerskap. Vem som svarar när något går sönder, och hur snabbt.
- Pris och total ägandekostnad. Hela bilden, inklusive de kostnader som inte står på prissidan.
- Exit och dataportabilitet. Dina villkor för att säga upp avtalet, förhandlade medan du fortfarande sitter i ett bra läge.
- Leverantörsbakgrund och referenser. Ägarförhållanden, stabilitet, och kunder som liknar din organisation och som du kan ringa upp.
Säkerhet och datalagring: frågor du bör ställa till varje leverantör
Du behöver inte vara säkerhetsspecialist för att klara det här avsnittet. En handfull raka frågor räcker, tillsammans med tålamodet att kräva lika raka svar.
Fråga var datan lagras fysiskt och under vilken jurisdiktion hostingbolaget verkar. För en europeisk organisation är EU-hosting en standardfråga till varje leverantör på listan, eftersom platsen avgör vilka lagar som gäller för datan. Fråga vem som äger datan (svaret ska vara du, utan förbehåll), vilka underbiträden som är inblandade och var de behandlar data, och hur leverantören hanterar GDPR i praktiken: personuppgiftsbiträdesavtal, de registrerades rättigheter och radering.
Be sedan om bevis i stället för adjektiv. Vilka säkerhetsramverk följer leverantören, och vad kan de visa upp? Revisionsrapporter, sammanfattningar av penetrationstester, en incidentprocess med utlovade tider för när du får besked? En leverantör som svarar tydligt och skriftligt på det här säger samtidigt något om hur den kommer att uppträda som partner.
Frågor om integrationer och teknisk arkitektur
Ett LMS står aldrig för sig självt. Det ska fungera ihop med din identitetsleverantör, förmodligen med ditt HR-system och kanske med ditt CRM. Mallens tekniska avsnitt kretsar därför främst kring fyra saker. Finns det ett dokumenterat, öppet API, och vad klarar det? Vilka SSO-standarder stöds? Hur skapas och tas användare bort automatiskt? Och vilka e-learningstandarder (SCORM, xAPI, cmi5) kan plattformen importera och exportera?
Ett praktiskt tips är att be leverantörerna beskriva en verklig integration med ett system som ditt, i stället för att bara bekräfta att integration är ”möjlig”. Nästan allt är möjligt om någon får tid och budget. Frågan är hur mycket som fungerar direkt och hur mycket som blir ett konsultprojekt hos dig.
Frågor om support och implementering
Två plattformar med identiska funktionslistor kan ge helt olika upplevelser, och skillnaden brukar visa sig just i support och implementering. Mallen ber därför leverantörerna beskriva en typisk tidsplan från påskrivet avtal till första skarpa kurs, vad som ingår och vad som kostar extra, vem i deras team du får jobba med, och vilken utbildning dina administratörer får.
Supportfrågorna är konkreta med flit. Vilka kanaler och vilka tider? Vilka språk? Är svarstiderna avtalade? Och får du en namngiven kontaktperson eller en ärendekö? Hos oss på Learnifier har vi byggt hela vår modell kring människor du faktiskt kan nå, så vi är knappast neutrala i frågan. Vi tycker ändå att det här avsnittet förtjänar mer vikt än de flesta köpare ger det. Bedöm varje leverantör, oss inräknade, efter vad de är beredda att skriva ned.
Vad som händer efter att du skrivit på, och hur du får folk att faktiskt använda plattformen, går vi igenom i vår checklista för LMS-implementering.
Exitvillkor och dataportabilitet: skydda din nästa migrering
Förhandla exitvillkoren innan du skriver på, medan du fortfarande sitter i ett bra förhandlingsläge och har leverantörens goodwill. Ingen planerar att säga upp avtalet, och det är precis därför klausulen brukar hoppas över. Den dag du vill byta leverantör sitter du annars mot en motpart som inte har mycket att vinna på att göra bytet enkelt.
Mallen ställer frågorna åt dig. Vilka data kan du exportera, i vilka format, och kan du göra det själv utan att öppna ett ärende? Vad händer med kursinnehåll och media vid uppsägning? Vad kostar hjälp med utflytten? När och hur raderas din data, och hur bekräftas raderingen? Och står en definierad exitprocess i avtalet, eller bara i säljsamtalet?
Sitter du redan fast i en plattform som gör det svårt att byta? Vår guide till att byta LMS går igenom hur du tar dig ur på ett snyggt sätt.
Checklista för utvärdering: så skickar du kravspecifikationen och jämför svaren rättvist
Du har definierat kraven, trimmat frågelistan och satt vikterna. Det som återstår är disciplin i processen.
- Skicka till tre till fem leverantörer. Färre ger ingen riktig jämförelse. Fler ger bara mer att läsa, utan att beslutet blir bättre.
- Samma dokument, samma deadline, samma information. Får en leverantör ett förtydligande ska alla få det.
- Poängsätt var för sig först. Låt varje utvärderare fylla i matrisen på egen hand och jämför sedan. Då kommer den ärliga oenigheten fram innan alla hunnit lägga sig på linje med den som pratar högst.
- Kör dina egna scenarier i demon. Ge leverantörerna på shortlisten två eller tre av dina verkliga användningsområden och be dem visa hur det går till i plattformen.
- Använd den viktade totalpoängen för att rikta diskussionen, inte för att avsluta den. Hamnar två leverantörer nära varandra visar matrisen exakt var de skiljer sig åt, och det är precis där det sista samtalet ska börja.
Ladda ner mallen och sätt av en timme med teamet för att bråka om vikterna. Då har du gjort det svåraste innan en enda leverantör hunnit svara.
Vanliga frågor om kravspecifikation för LMS
Vad ska en kravspecifikation för LMS innehålla?
En kravspecifikation för LMS börjar med en beskrivning av din organisation och omfattningen, följt av mål och användningsområden. Därefter kommer frågorna, uppdelade i fokuserade avsnitt: funktionella krav, teknisk arkitektur och integrationer, säkerhet och datalagring, implementering, support, pris och total ägandekostnad, exitvillkor samt leverantörsreferenser. Ett femtiotal väl valda frågor räcker gott. Lägg också till en viktad utvärderingsmatris, så att alla intressenter poängsätter leverantörerna mot samma kriterier.
Vad är skillnaden mellan RFP och RFI vid upphandling av LMS?
En RFI (request for information) är en tidig och informell marknadssondering som du skickar till en bredare lista med leverantörer för att kunna bygga en shortlist. En RFP (request for proposal) är det formella dokument som sedan går till shortlisten, med specifika frågor, en deadline och strukturerad poängsättning. På svenska kallar vi det helt enkelt kravspecifikation. Tumregel: RFI:n använder du för att lära känna marknaden, kravspecifikationen för att fatta beslutet.
Hur många leverantörer ska du skicka kravspecifikationen till?
Tre till fem leverantörer fungerar bäst i praktiken. Med färre än tre får du ingen meningsfull jämförelse, och du står dessutom svagare i förhandlingen. Med fler än fem mångdubblas utvärderingsarbetet utan att beslutet blir bättre, och leverantörerna lägger mindre krut på svaren när de märker att de är många om budet. Har du en längre lista från början: använd en RFI eller en demorunda för att korta den innan kravspecifikationen går ut.
Hur viktar du kriterier i en LMS-utvärdering?
Enas om vikterna i teamet innan leverantörernas svar kommer in, så att ingen favorit hinner påverka siffrorna. Varje utvärderingskriterium får en procentvikt och summan ska bli 100 %, med tyngst vikt på användarvänlighet och funktionell täckning. När svaren sedan ligger på bordet poängsätter du varje leverantör från 1 till 5 per kriterium, multiplicerar poängen med vikten och summerar. Resultatet är en viktad totalpoäng där 5,0 är max.
Hur lång tid tar en upphandling med kravspecifikation för LMS?
Räkna med ungefär sex till tolv veckor från färdiga krav till beslut. En till två veckor går åt till att färdigställa själva kravspecifikationen, och leverantörerna behöver två till tre veckor på sig att svara. Resten av tiden lägger du på poängsättning, demos med leverantörerna på shortlisten, referenssamtal och avtalsdiskussion. Med en trimmad frågelista kortar du varje steg, eftersom både skrivandet och utvärderingen går fortare när det finns färre frågor att ta ställning till.
Räcker en kravlista vid ett mindre LMS-köp, eller behövs en formell kravspecifikation?
En formell kravspecifikation behövs inte alltid. Har du ett litet team och ett tydligt behov räcker det ofta med en skriftlig kravlista och en strukturerad demorunda med två eller tre leverantörer. Kravspecifikationen lönar sig när flera intressenter ska enas om valet, när upphandlingsregler kräver den, eller när avtalet är så stort att ett byte några år senare skulle svida ordentligt.








.webp)

.jpg)






