LMS-vaatimusten tarkistuslista compliance-koulutukseen
Useimmat liikkeellä olevat LMS-vaatimusmallit on kirjoitettu yritysten oppimiseen ja kehittämiseen. Ne kysyvät kurssiluetteloista, pelillistämisestä, sosiaalisista ominaisuuksista ja mobiilioppimisesta. Ne eivät ole vääriä, ne vain vastaavat eri toimeksiantoon, ja compliance-ostaja, joka käyttää sellaista, päätyy pisteyttämään toimittajia asioista, joilla ei koskaan ole merkitystä, ja ohittamaan ne kaksi tai kolme, joilla on.
Tämä on vaatimusluettelo, joka on rakennettu toisin päin, lähtien siitä, mitä compliance-ohjelman on pystyttävä todistamaan. Käytä sitä tarjouspyynnön selkärankana tai lyhyen listan pisteytyskorttina. Osiot on järjestetty sen mukaan, kuinka usein niistä tulee se, mikä hajoaa.
Määrittele populaatio ennen vaatimusten kirjoittamista
Lähes jokainen epäonnistunut LMS-valinta, jonka olen nähnyt, alkoi vaatimusluettelolla ja ohitti tämän vaiheen. Vaatimusluettelo on yhden kysymyksen alavirrassa: kenet on koulutettava mihin, ja mikä sen ratkaisee?
Kirjaa ylös ennen kuin puhut toimittajan kanssa:
- Kuinka monta ihmistä, kuinka monessa juridisessa yksikössä, kuinka monessa maassa
- Kuinka monta erillistä opetussuunnitelmaa, ja mikä määrää, kuka saa minkäkin
- Kuinka monella kielellä tarvitsette sisältöä, ja mitkä niistä ovat lain edellyttämiä eivätkä vain toivottuja
- Mitkä populaatiot eivät ole HR-järjestelmässänne lainkaan: alihankkijat, vuokratyöntekijät, hallituksen jäsenet, kausityöntekijät
- Tarvitsevatko ulkoiset osapuolet, kuten toimittajat tai franchise-yrittäjät, koulutusta
Kaksi viimeistä riviä koituvat useamman organisaation kohtaloksi kuin mikään tekninen vaatimus. Hallituksen jäsenet ja alihankkijat kuuluvat usein koulutusvelvoitteiden piiriin eivätkä lähes koskaan ole HR-syötteessä, joten heistä tulee manuaalinen prosessi, jota kukaan ei suunnitellut. Artikkeli 47 käsittelee, miten rakennetaan matriisi, joka vastaa toiseen kohtaan kunnolla.
Osoitus ja ilmoittautuminen
Tässä compliance-alusta ansaitsee tai menettää paikkansa. Manuaalinen ilmoittautuminen ei skaalaudu eikä pysy oikeana.
- Sääntöpohjainen automaattinen osoitus HR-järjestelmän attribuuttien perusteella: rooli, yksikkö, maa, osasto, työsuhteen tyyppi
- Uudelleenarviointi muutoksen yhteydessä, jolloin roolin tai maan vaihtuminen päivittää opetussuunnitelman ilman manuaalista puuttumista
- Tuki maa-akselille rooliakselin lisäksi, jolloin suomalainen ja ruotsalainen controller voivat saada eri kurssiversiot
- Uuden työntekijän säännöt määritellyllä aloituspäivän siirtymällä
- Lähtijän käsittely: mikä pysähtyy, mikä säilytetään, mikä anonymisoidaan
- Manuaalinen ohitus kirjatulla perusteella, koska poikkeus on aina olemassa
- Massaosoitus HR-syötteen ulkopuolisille populaatioille
Demotesti: siirrä työntekijä yksiköstä toiseen ja katso, mitä tapahtuu ilman, että kukaan koskee tietueeseen.
Määräajat, muistutukset ja eskalointi
- Kurssikohtainen määräaikalogiikka, konfiguroitavissa populaatioittain eikä globaalisti
- Muistutusrytmi, jonka te asetatte, mukaan lukien kuinka monta, kuinka kaukana toisistaan ja millä kielellä
- Eskalointi esihenkilölle määritellyllä laukaisukohdalla
- Esihenkilön näkymä oman tiiminsä tilanteeseen ilman ylläpitäjän oikeuksia
- Raportointi myöhässä olevista yksiköittäin ja esihenkilöittäin
Toistuvuus ja versiointi
- Tuki vähintään kolmelle toistuvuusmallille: kiinteä aikaväli, tapahtuman kuten roolin vaihtumisen laukaisema, ja kertaluonteinen
- Kurssiversiointi, joka erottaa sisällölliset muutokset kosmeettisista
- Sääntö sille, mitä olemassa oleville suorituksille tapahtuu kurssiversion muuttuessa: pysyvätkö ne voimassa, vanhenevatko vai laukaisevatko uudelleenosoituksen
- Kyky raportoida suoritukset tiettyä versiota vastaan, ei vain kurssin nimeä vastaan
Versiointivaatimus on se, jonka ostajat useimmiten huomaavat myöhässä. Jos lahjonnanvastaisen kurssinne sisällöllistä muutosta ei voi erottaa kirjoitusvirheen korjauksesta, ette voi vastata kysymykseen siitä, koulutettiinko henkilö nykyiseen aineistoon.
Kieli ja sisältö
- Saman kurssin itsenäiset kieliversiot, erikseen versioituina ja erikseen julkaistavina
- Määritelty varakäyttäytyminen, kun oppijalle ei ole kieliversiota
- Käyttöliittymän kieli riippumaton sisällön kielestä, koska suomenkieliselle voidaan osoittaa englanninkielinen kurssi
- Tuki käyttämienne kielten merkistöille ja lajittelusäännöille
- Kyky suorittaa kurssi kielellä, joka ei ole sidottu oppijan maahan, rajojen yli työskenteleville
Standardit ja sisällön siirrettävyys
- Mitä standardeja alusta tuo: SCORM 1.2, SCORM 2004, xAPI, cmi5
- Voidaanko ulkoinen oppimistietovarasto (LRS) liittää, jos teillä on sellainen
- Oman ladatun sisältönne vienti alkuperäisessä paketoidussa muodossa
- Voivatko toimittajalta lisensoidut kurssit toimia toisella alustalla, jos lähdette
Artikkeli 53 selittää, mitä nämä standardit tekevät ja mitä niistä todella tarvitsette. Kaupallinen pointti on yksinkertaisempi: jos sisältönne ei voi lähteä, hintaneuvottelunne uusimisen yhteydessä ei ole todellinen neuvottelu.
Raportointi ja todisteet
Pyytäkää nämä tuotoksina, ei kojelaudan kuvakaappauksina.
- Henkilökohtainen suoritustieto kurssin nimellä, versiolla, päivämäärällä ja pistemäärällä, kun sovellettavissa
- Yksikkö- ja vuosikohtainen todistevienti muodossa, jonka tarkastaja hyväksyy
- Historiallinen raportointi populaatioista sellaisina kuin ne olivat tuolloin, ei sellaisina kuin ne ovat nyt
- Itsepalveluraporttien rakentaminen ilman toimittajan osallistumista tai asiantuntijapalvelumaksuja
- Ajastetut raportit nimetyille vastaanottajille
- API-pääsy suoritustietoihin
Tämän luettelon yksittäinen hyödyllisin vaatimus: pyytäkää toimittajaa tuottamaan täysi todistevienti arvioinnin aikana demodatalla, ja katsokaa tiedostoa. Artikkeli 49 käsittelee, mitä paketin tulisi sisältää.
Integraatio
- Kertakirjautuminen: SAML 2.0 tai OpenID Connect
- Automaattinen käyttäjien provisiointi ja poisto, mieluiten SCIM
- Nimetyt liittimet tai dokumentoitu API-tuki nimenomaan teidän HR-järjestelmällenne
- Käyttäjäsynkronoinnin tiheys ja mitä tapahtuu, kun se epäonnistuu
- Veloittaako toimittaja integraatiotyöstä erikseen
Artikkeli 54 käsittelee, mitä kysyä HR-puolelta, mukaan lukien pohjoismaiset HR-järjestelmät, jotka harvoin näkyvät toimittajan liitinluettelossa.
Tietosuoja ja isännöinti
- Isännöinnin sijainti ja voidaanko se rajata EU:hun tai ETA:aan
- Alihankkijaluettelo ja muutosten ilmoitusehdot
- Säilytyksen konfigurointi: voitteko asettaa säilytyssäännöt itse, tietoluokittain
- Poisto- ja anonymisointirutiinit, ja mitä ne jättävät jälkeensä
- Allekirjoittaako toimittaja teidän tietojenkäsittelysopimuksenne vai tarjoaako se vain omaansa
- Ylläpitäjien toimien tarkastusloki
Artikkeli 55 käsittelee, mitä saatte säilyttää ja millä perusteella.
Saavutettavuus
- Väitetty vaatimustenmukaisuustaso ja mitä WCAG-versiota vasten
- Onko olemassa vaatimustenmukaisuusraportti, ja sen päivämäärä
- Kattaako väite sisällöntuotantotyökalulla tuotetun kurssisisällön alustan käyttöliittymän lisäksi
- Kurssisoittimen ja arviointimoottorin näppäimistökäytettävyys
- Tekstitys- ja transkriptiotuki videosisällölle
Ero alustan vaatimustenmukaisuuden ja sisällön vaatimustenmukaisuuden välillä on se, missä useimmat toimittajien väitteet hiljaa epäonnistuvat. Artikkeli 56 käsittelee sitä.
Hallinto ja omistamisen kustannukset
- Kuinka monta ylläpitäjää lisenssi sisältää ja mitä he maksavat
- Sisältyvätkö raportointi, integraatio ja lisäkielet hintaan vai hinnoitellaanko ne erikseen
- Hiekkalaatikko- tai testiympäristön saatavuus
- Tukiajat, kieli ja vasteaikasitoumukset
- Irtisanomisaika, uusimisehdot ja hinnankorotuslausekkeet
- Tietojen vienti sopimuksen päättyessä: muoto, kustannus ja kuinka kauan aikaa teillä on
Artikkeli 62 käsittelee, mikä todella määrää kokonaiskustannuksen, joka on harvoin tarjouksen ensimmäisen sivun käyttäjäkohtainen hinta.
Muuntaminen pisteytysmalliksi
Älkää painottako jokaista riviä yhtä paljon. Jakakaa luettelo kolmeen tasoon ennen lähettämistä.
Pakollinen. Ei tässä pudottaa toimittajan. Pitäkää tämä luettelo lyhyenä, mieluiten alle viisitoista kohtaa. Pohjoismaiselle compliance-ostajalle se sisältää yleensä monikielisen sisällön versioinnin, maatietoisen osoituksen, henkilökohtaisen todisteviennin, EU-isännöinnin ja kertakirjautumisen.
Toivottava. Pisteytetty, painotettu, ja siellä, missä suurin osa erottelusta tapahtuu.
Mukava lisä. Kirjattu, painottamaton tai kevyesti painotettu, jotta ette maksa lisähintaa ominaisuuksista, joita kukaan ei ole pyytänyt.
Vaatikaa sitten, että vastaukset pakollisiin kohtiin osoitetaan eikä vain vakuuteta. Kirjalliset vastaukset ominaisuuskysymyksiin laativat ihmiset, joiden työ on voittaa tarjouskilpailu. Viiden minuutin demonstraatio siirtoskenaariosta, todisteviennistä ja kieliversion muutoksesta kertoo enemmän kuin neljäkymmentä sivua sitä.
Usein kysytyt kysymykset
Kuinka pitkä LMS-tarjouspyynnön tulisi olla?
Lyhyempi kuin useimmat. Tiivis 60–80 kohdan vaatimusluettelo, jaettuna pakollisiin, toivottaviin ja mukaviin lisiin, tuottaa paremman vertailtavuuden kuin kolmensadan rivin matriisi, koska toimittajat vastaavat lyhyeen luetteloon huolellisesti ja pitkään kopioimalla ja liittämällä.
Pitäisikö meidän toteuttaa pilotti ennen allekirjoitusta?
Kyllä, jos toimittaja sallii sen. Pilotti yhdellä todellisella kurssilla, yhdellä todellisella populaatiolla ja yhdellä todellisella raportointivaatimuksella tuo esiin integraatio- ja tietolaatuongelmia, joita mikään demo ei tuo. Rajatkaa se yhteen yksikköön ja kiinteään neljän–kuuden viikon ikkunaan, jotta siitä ei tule pysyvää tilaa.
Keiden tulisi kuulua arviointitiimiin?
Vähintään compliance, HR, IT ja tietosuoja. Compliance omistaa velvoitteen, HR omistaa osoitusta syöttävän tiedon, IT omistaa integraation ja turvallisuuden, ja tietosuojatoiminto omistaa säilytys- ja käsittelykysymykset. Viimeisen puuttuminen on tapa, jolla organisaatiot päätyvät neuvottelemaan tietojenkäsittelysopimuksen uudelleen allekirjoituksen jälkeen.
Mikä on yleisin vaatimus, jonka ihmiset unohtavat?
Lähtijän käsittely. Kaikki määrittelevät, mitä tapahtuu, kun henkilö tulee taloon ja vaihtaa roolia. Paljon harvemmat määrittelevät, mitä alusta tekee tietueelle, kun henkilö lähtee, mikä on juuri se tietue, jota teiltä myöhemmin pyydetään.
Lähteet ja lisälukemista
- SAML V2.0 Core – OASIS-standardi
- OpenID Connect Core 1.0 – OpenID Foundation
- RFC 7644: SCIM Protocol – IETF
- cmi5-spesifikaatio: SCORM vs cmi5 – AICC / ADL
- xAPI SCORM Profile – ADL Initiative
- Web accessibility laws and policies: European Union – W3C WAI
- Yleinen tietosuoja-asetus (EU) 2016/679 – EUR-Lex
