LMS-integrasjoner og åpent API: en kjøpsguide

En læringsplattform blir aldri bedre enn systemene den henger sammen med. Tenk deg at synkroniseringen med HR-systemet stopper opp. Noen i teamet lager et regneark for å holde oversikt over hvem som har fullført hva, og uka etter er det to personer som holder det à jour. Den egentlige prisen for en plattform som står alene, er ikke en funksjon som mangler, men at det manuelle arbeidet du kjøpte plattformen for å bli kvitt, kommer snikende tilbake.

Kanskje er det du som skal koble plattformen inn i systemlandskapet. Eller kanskje er det du som må svare når revisor spør hvem som har tilgang til hva. Uansett hjelper det lite å spørre «Har den et API?», for nesten alle leverandører svarer ja. Disse tre spørsmålene gir deg mer å gå på: Er det et ekte, åpent API, eller bare en kort liste med ferdige koblinger? Kan teamet ditt lese dokumentasjonen uten å måtte avtale et salgsmøte først? Og når noe ryker klokka fire en fredag ettermiddag, finnes det da et menneske som kan hjelpe deg?

Vi går gjennom hva åpent API og god utviklerstøtte betyr i praksis, og ser på de fire integrasjonslagene du bør vurdere hver for seg. Du får også spørsmålene som skiller en plattform du kan bygge videre på, fra en du kommer til å slite med i årevis, og til slutt ser du hvordan vi løser dette i Learnifier.

Hva betyr «åpent API» og «god utviklerstøtte» egentlig?

Et åpent API er et dokumentert og offentlig tilgjengelig grensesnitt som lar systemene dine lese og skrive data i læringsplattformen gjennom vanlige webkall. «Åpent» betyr at kundene og utviklerne deres får tilgang, med dokumentasjon som faktisk er til å lese. Åpen kildekode har det ingenting med å gjøre. Et godt API er RESTful, altså bygget rundt forutsigbare URL-er som peker på ressurser. Det bruker standard HTTP-metoder, sender strukturerte data som JSON og krever sikker autentisering.

Utviklerstøtte er alt rundt API-et som avgjør om teamet ditt blir ferdig på noen dager eller trenger flere uker. Det gjelder tydelig dokumentasjon, et trygt sted å teste, en fornuftig autentiseringsmodell, forutsigbar versjonering og folk som hjelper deg når dokumentasjonen ikke strekker til.

Integrasjon og API blir ofte brukt om hverandre, men det er to forskjellige ting. En integrasjon er en ferdig kobling som leverandøren bygger og vedlikeholder, for eksempel en ferdig synkronisering mot et bestemt HR-system. API-et er verktøykassen utviklerne dine bruker til å lage koblinger leverandøren aldri så for seg. De sterkeste plattformene har begge deler. En liste med ferdige koblinger er praktisk helt til du trenger den som ikke står på lista. Da er det bare et åpent API som hjelper.

Hvilke fire integrasjonslag bør du vurdere?

«Integrasjoner» dekker fire ganske ulike ting, og en plattform kan godt være sterk på ett område og svak på et annet. Vurder derfor hvert lag for seg.

1. Identitet: single sign-on og provisjonering

Det er her de fleste innføringer enten går på skinner eller stopper opp. Med single sign-on (SSO) logger deltakerne inn med identitetsleverandøren organisasjonen din har, og slipper enda et passord å huske. Se etter standardene IT-avdelingen din allerede bruker: SAML, OpenID Connect og katalogtjenesten, enten det er Active Directory eller Microsoft Entra.

Like viktig, og langt oftere oversett, er provisjonering: hvordan kontoer blir opprettet, oppdatert og deaktivert. SCIM (System for Cross-domain Identity Management) automatiserer denne jobben. Uten SCIM kan en som har sluttet, beholde en aktiv konto helt til noen husker å slette den manuelt. Med SCIM skjer deaktiveringen av seg selv. Gir du opplæring til mer enn noen hundre personer, bør du behandle SCIM som et skal-krav. Det er også et av punktene som skiller plattformene fra hverandre når du gjør en grundig vurdering av LMS for store bedrifter.

2. Data og selve API-et

Dette er det egentlige API-laget. Sjekk først at API-et er RESTful, dokumentert og har en tydelig autentiseringsmodell. Deretter gjenstår tre spørsmål som tynn dokumentasjon sjelden svarer rett ut på:

• Webhooks: Kan plattformen sende hendelser til deg i det øyeblikket de skjer, for eksempel når et kurs er fullført eller en bruker er registrert? Eller må du spørre API-et med jevne mellomrom (polling)? Polling er tregere, krever mer ressurser og henger alltid litt etter. Med webhooks kan du automatisere i sanntid.
• Grenser for antall API-kall (rate limits): Hvor mange kall kan du gjøre før leverandøren struper deg? Svaret avgjør om en engangssynkronisering av hele brukerbasen blir en helt vanlig jobb eller en ødelagt helg.
• Dekning: Hvilke ressurser når du faktisk via API-et? «Vi har et API» kan bety full lese- og skrivetilgang, eller en håndfull endepunkter som bare kan leses. Sjekk at dataene du trenger til rapportering og beslutningsgrunnlag er med, og ikke bare brukerpostene.

3. Innholdsstandarder

Bygger du kurs i eksterne verktøy, eller kan det tenkes at du bytter plattform en dag? Da er det standardene som beskytter investeringen din. SCORM er den etablerte standarden: et kurs laget i ett verktøy kan kjøres i hvilken som helst kompatibel plattform. xAPI (Experience API, tidligere Tin Can API) fanger opp flere typer læring og sender dataene videre til en Learning Record Store. cmi5 er en nyere spesifikasjon som kombinerer kursstrukturen fra SCORM med den fleksible sporingen i xAPI. ADL, som står bak begge, omtaler den som etterfølgeren til SCORM. LTI 1.3 er standarden for å koble eksterne læringsverktøy rett inn i plattformen.

Still to spørsmål, for leverandørene svarer ofte bare på det første. Hvilke standarder kan plattformen kjøre? Og får du innholdet ditt ut igjen hvis du bytter leverandør? Den praktiske testen på portabilitet er om du kan laste ned det du har lastet opp. Vær også klar over at støtte for en standard ikke er det samme som å konvertere til den. De fleste plattformer kjører innhold i SCORM, xAPI eller cmi5, men svært få gjør om det eksisterende materialet ditt til disse formatene for deg.

4. Ferdige koblinger

Dette er bekvemmelighetslaget: ferdige koblinger til verktøy du allerede bruker, som HR-system (HRIS), lønn, rekruttering, CRM, samarbeidsverktøy og kalender- og videoverktøy for liveøkter. Koblingene sparer deg for mye tid, men de dekker bare det leverandøren har valgt å bygge. Når du trenger noe koblingslista ikke tok høyde for, er det åpne API-et reserveløsningen.

Hvordan kobler du læringsplattformen til systemene du allerede bruker?

Tre integrasjoner går igjen i nesten alle evalueringer: HR-system, CRM og samarbeidsverktøy. De har hvert sitt formål og reiser ulike spørsmål, så de får hver sin del.

Koble LMS-et til HR-systemet (HRIS)

Koblingen til HR-systemet sørger for at deltakeropplysningene stemmer. Når systemene snakker sammen, blir nyansatte opprettet automatisk, rolle- og avdelingsbytter blir oppdatert automatisk, og de som slutter, blir deaktivert uten at noen trenger å huske på det. Du slipper manuell registrering, risikoen for feil går ned, og opplæringsdataene viser hvem som faktisk jobber hvor. Dette er også ryggraden i automatisert onboarding: den nyansatte dukker opp i HR-systemet, og riktig opplæring ligger klar allerede første dag.

Det kjedeligste spørsmålet er det du bør stille først. Glem et øyeblikk hvilke felt som skal mappes mot hverandre, og spør heller: hvem deaktiverer kontoen når noen slutter? Er svaret navnet på en person, har du ingen integrasjon ennå. Du har en påminnelse.

Koble LMS-et til CRM-systemet

Gir du opplæring til folk utenfor organisasjonen, som kunder, partnere eller forhandlere, ligger relasjonene i CRM-systemet og opplæringen i læringsplattformen. Kobler du dem sammen, havner opplærings- og sertifiseringsdata på riktig kontakt eller kundekonto. Salg og customer success ser da hvem som har tatt opplæringen, hvem som er sertifisert og hvor langt kunden har kommet. For kunde- og partneropplæring er det slik du viser hva opplæringen betyr for fornyelser og mersalg. Vi går nærmere inn på dette i guiden om hvordan du kobler LMS-et til CRM-systemet.

Microsoft Teams og samarbeidsverktøy

Mange vil at læringen skal skje der arbeidet allerede foregår. Med koblinger til Microsoft Teams eller Slack kommer kursvarsler, påminnelser og lenker i kanalene folk faktisk følger med i. Da blir påminnelsen sett, i stedet for å bli liggende uåpnet i innboksen. Kjører du liveøkter eller kombinert opplæring, bør du sjekke hvordan plattformen kobles mot video- og kalenderverktøyene, slik at øktene blir booket og synkronisert uten knot. Alt dette er nyttig, men identitet og data er viktigere.

Hvordan vurderer du utviklerstøtten (delen leverandørene hopper over)?

Selv et kraftig API koster deg uker hvis støtten rundt er dårlig. Gå gjennom denne sjekklisten før du signerer:

• Offentlig dokumentasjon: Kan utviklerne lese dokumentasjonen og teste API-et før du binder deg? Interaktiv dokumentasjon, for eksempel et Swagger- eller OpenAPI-grensesnitt, er et godt tegn. Må du gjennom et salgsmøte bare for å få se dokumentasjonen, sier også det noe.
• Et trygt sted å teste: Finnes det en sandbox eller et testmiljø der teamet kan bygge uten å røre ekte deltakerdata?
• En fornuftig autentiseringsmodell: API-nøkler eller tokens som er enkle å utstede og administrere.
• Forutsigbar versjonering: Når leverandøren endrer API-et, får endringen et nytt versjonsnummer, og blir du varslet på forhånd? Eller slutter integrasjonene dine å virke uten forvarsel? Be om retningslinjene for utfasing og endringsloggen.
• Ekte mennesker: Dette er punktet kjøpere undervurderer og senere angrer på. Dokumentasjonen svarer på de fleste rutinespørsmål. Det er de rare unntakene under oppstarten som krever noen som kjenner plattformen og svarer raskt. Et godt API uten noen bak er et godt API du feilsøker alene.

Utviklerstøtte handler like mye om mennesker som om dokumentasjon. Teamene som integrerer raskest, er de som får tak i noen som faktisk kjenner systemet. Det er lett å overse i en funksjonssammenligning, og vanskelig å klare seg uten når lanseringen står for døra.

Hvilke spørsmål bør du stille som kjøper?

Ta med disse spørsmålene til leverandørdemoen. Svarene, og hvor lett de kommer, forteller deg det meste.

1. Kartlegg systemlandskapet først. Hvilke systemer må plattformen snakke med fra første dag, og hvilke kan vente? Bestem det før demoen, så du vurderer leverandøren opp mot din egen hverdag.
2. Skill mellom skal-krav og bør-krav. Har du mer enn noen hundre brukere, er SSO og automatisk provisjonering som regel skal-krav. En bestemt kobling kan godt være et bør-krav hvis det åpne API-et dekker det samme.
3. Spør hvem som vedlikeholder hver integrasjon. En ferdig kobling vedlikeholdes av leverandøren. Bygger du selv på API-et, blir det som oftest din jobb. Avklar hvem som er ansvarlig for vedlikeholdet før du bestemmer deg.
4. Velg mellom å bygge selv og å bruke en ferdig kobling. Finnes det en ferdig kobling for hver integrasjon, eller må du bygge på API-et? Begge deler fungerer, så lenge ingen blir overrasket underveis.
5. Test at innholdet kan flyttes. Får du ut kursene som SCORM eller xAPI? Kan du ta med deg materialet hvis du bytter plattform neste år?
6. Sjekk sikkerheten rundt API-tilgangen. Hvordan autentiserer og avgrenser leverandøren tilgangen, og hvor blir dataene dine lagret? For europeiske organisasjoner, og for alle med opplæring som må holde ved en revisjon, er dette et krav i anskaffelsen, ikke et ønske.

Hvilke feil er vanligst?

De samme mønstrene går igjen når integrasjonsprosjekter sporer av:

• Å tro at «har et API» betyr «har et brukbart API»: Ordet står på hver eneste nettside. Det som skiller, er dokumentasjonen, sandboxen og støtten bak.
• Å glemme deaktiveringen: Teamet spesifiserer flyten for nyansatte og glemmer flyten for dem som slutter. Uten automatisk provisjonering blir deaktivering en manuell oppgave og et sikkerhetshull ingen ser.
• Å overse innholdsportabilitet: Det virker uviktig første dag og blir avgjørende den dagen du vil bytte.
• Å undervurdere vedlikeholdet: En integrasjon er ikke ferdig når den er levert. API-er endres og systemer oppdateres, og noen må holde den i gang.
• Å velge etter logoer: En lang rekke integrasjonslogoer virker betryggende. Men dybde teller mer enn antall: én grundig, godt dokumentert integrasjon er bedre enn ti overfladiske som du ikke kan konfigurere.

Slik jobber vi i Learnifier med åpne API-er og utviklerstøtte

Vi har bygget Learnifier for å passe inn i hverdagen din, slik at du slipper å rigge om alt annet rundt plattformen. Fleksibilitet er et av prinsippene vi bygger på, og det åpne API-et er en stor del av hvordan vi lever opp til det. Konkret ser det slik ut:

• Et RESTful, åpent API. Forutsigbare, ressursorienterte URL-er, standard HTTP-metoder (GET, POST, PUT, DELETE) og JSON over HTTPS. API-et er dokumentert med et interaktivt Swagger-grensesnitt, så utviklerne kan utforske det direkte. Autentiseringen skjer med HTTP Basic, med nøkkel og secret.
• Webhooks, så du slipper polling. Learnifier sender hendelser til systemene dine idet de skjer, som JSON over HTTPS til et endepunkt du setter opp selv. Det finnes mer enn 20 dokumenterte hendelsestyper: registrering, tilgang, fremdrift, fullførte kurs og moduler, oppmøte, sertifikater, nye kontoer, ventelister og endringer i prosjekter. Svarer ikke endepunktet ditt, prøver Learnifier på nytt med stadig lengre mellomrom over flere døgn.
• Ingen grenser for API-kall å planlegge rundt. Vi har ingen publiserte grenser for antall API-kall, bare en fair use-policy. Å synkronisere hele brukerbasen på én gang er dermed en ren teknisk oppgave, og du trenger ikke legge kabal med kalenderen for å få det til.
• Sandbox for enterprise-kunder. Enterprise-kunder får et eget sandbox-miljø der utviklerne kan bygge og teste uten å røre ekte deltakerdata.
• Identitet som fungerer. Du kan legge til og synkronisere deltakere via det offentlige API-et og provisjonere brukere automatisk med SCIM. Vi støtter SAML, OpenID Connect, Active Directory og Microsoft Entra, også i hybridoppsett der flere innloggingsmetoder går side om side med manuell innlogging.
• Innholdsstandardene som betyr noe. SCORM 1.2, xAPI og cmi5, pluss LTI 1.3 for eksterne læringsverktøy. Alt du laster opp, kan du laste ned igjen, så materialet forblir ditt. Plattformen konverterer ikke det eksisterende innholdet ditt mellom formatene, og det sier vi heller rett ut enn at du oppdager det senere.
• Et ordentlig bibliotek med koblinger. Teamtailor og Jobylon (rekruttering), Hailey HR, Simployer og FlexHRM (HR), SD Worx (lønn), Genially og WeAre (innholdsproduksjon), og flere til. Den oppdaterte lista finner du på integrasjonssiden vår.
• Hjelp til å bygge integrasjonen. I tillegg til API-et tilbyr vi Integration Services: teamet vårt hjelper deg med å kartlegge, bygge og vedlikeholde integrasjonene, så utviklerne dine ikke står med alt alene.
• Europeisk som standard. Learnifier er et svensk selskap med europeiske eiere. Dataene lagres på EU-servere, og du kan velge svensk hosting hvis dataene skal bli i Sverige. GDPR ser vi på som et minstekrav, noe du bør kunne ta for gitt.

Menneskene får ikke plass i en API-referanse. Når teamet ditt integrerer Learnifier, sitter det ikke alene med en dokumentasjonsside.

«Vårt åpne API gir kundene friheten til å integrere Learnifier med systemene og arbeidsflytene de allerede bruker. Men vi vet også at et API bare er halve ligningen. Det tekniske teamet vårt hjelper kundene med å forstå mulighetene, finne riktig tilnærming og få integrasjonen på plass, enten de bygger den selv eller trenger mer håndfast støtte fra oss.» - Simon Söderdahl, Technical Project Manager i Learnifier

Ditt neste steg

Før du snakker med en eneste leverandør, skriv ned de tre systemene plattformen må snakke med fra første dag, og hvem som er ansvarlig for hver kobling. Be deretter hver leverandør om to lenker: API-dokumentasjonen og retningslinjene for utfasing. Hvor raskt lenkene kommer, sier mer enn demoen.

Vil du prøve lista på et ekte API, kan du ta den med til oss. Book en demo og fortell hvilke systemer som skal kobles sammen, så går vi gjennom nøyaktig hvordan API-et og integrasjonene i Learnifier vil håndtere systemlandskapet ditt. Er du tidligere i prosessen og fortsatt i gang med å sammenligne plattformer, kan du starte med guiden vår om hvordan du velger riktig LMS.