Mikä on oppimisen hallintajärjestelmä (LMS) ja milloin sitä tarvitaan

LMS ei ole kansio esityksiä ja lista taulukossa. Kun ilmoittautuminen, suoritus ja voimassaolo on todistettava, järjestelmä alkaa maksaa itsensä takaisin — kun ei, se on kallis ylimääräinen osa.

Kuvittele yhteinen verkkolevy, jolla on seitsemän esitystä, kaksi videota ja yksi ohje nimeltä ”lopullinen_versio_2_korjattu.pdf”, ja sen vieressä taulukko, johon henkilöstöasiantuntija merkitsee käsin, kuka on minkäkin katsonut. Niin kauan kuin työntekijöitä on kaksikymmentä ja koulutuksia yksi, järjestely toimii aivan hyvin eikä maksa mitään, joten kukaan ei kiirehdi vaihtamaan sitä. Se hajoaa toisena hetkenä — kun joku kysyy, saiko tietty ihminen viime vuonna todella sen kertauksen, ja ainoa vastaus, joka sinulla on, on taulukon rivi, jota kukaan ei voi vahvistaa ja jonka kuka tahansa on voinut kirjoittaa yli. Oppimisen hallintajärjestelmä eli LMS on ohjelmisto, jonka ainoa vakava tehtävä on muuttaa tuo rivi merkinnäksi, jolla on alkuperä, päivämäärä ja tekijä.

Mikä LMS on ja mihin se useimmin sekoitetaan

Oppimisen hallintajärjestelmä tekee neljä asiaa: se ilmoittaa ihmiset kursseille, jakaa sisällön, tarkistaa oppimisen ja säilyttää merkinnän siitä, mitä tapahtui. Ensimmäinen ja neljäs ovat ne, joiden takia järjestelmä oikeasti ostetaan, mutta toisesta ja kolmannesta puhutaan esittelyissä, koska ne on helpompi näyttää ruudulla. Jos tästä listasta poistaa merkinnän, jäljelle jää tiedostovarasto paremmalla käyttöliittymällä, ja sellaisia organisaatiossasi on mitä todennäköisimmin jo ainakin kaksi.

Juuri siksi LMS ei ole videopalvelu, ei webinaarityökalu eikä kurssikauppa, vaikka kaikki kolme osaavat näyttää oppimateriaalia yhtä hyvin tai paremmin. Videopalvelu tietää, että tiedosto toistettiin; se ei tiedä, että sen toisti ihminen, jonka piti suorittaa tietty kurssi tiettyyn päivään mennessä, että hän teki sen toisella yrittämällä ja että vuoden kuluttua kaikki on aloitettava alusta. Ero ei ole ominaisuuslistassa, jota vertaillaan hankintataulukossa, vaan siinä kysymyksessä, johon järjestelmä pystyy vastaamaan kahden vuoden kuluttua, kun kukaan alun perin mukana olleista ei enää työskentele organisaatiossa.

Sana ”alusta” harhauttaa tässä enemmän kuin auttaa, koska sillä nimetään sekä järjestelmät, jotka kirjaavat velvoitteita, että ne, jotka tarjoavat vapaasti valittavaa sisältöä, ja molempia myyvät samat ihmiset. Käytännön jako on silti yksinkertainen ja pitää kaikissa tapauksissa: jos joku muu määrää, mitä sinun on opittava, ja joku tarkistaa, teitkö sen, kyseessä on oppimisen hallintajärjestelmä. Jos valitset itse eikä kukaan seuraa, kyseessä on kirjasto, ja molemmat voivat olla hyödyllisiä yhtä aikaa, mutta vain ensimmäinen vastaa tarkastajan kysymykseen — ja juuri se kysymys on tavallisesti se, joka johtaa projektiin asti.

Tällaisen kirjanpidon tarve ei ole suomalainen erikoisuus eikä se ole pieni: Eurostatin mukaan 16 % EU:n 16–74-vuotiaasta väestöstä oli vuonna 2025 suorittanut verkkokurssin edeltäneiden kolmen kuukauden aikana, ja Suomen osuus, 29 %, oli unionin toiseksi korkein heti Irlannin jälkeen, joten ruudulta oppiminen ei täällä yllätä enää ketään. Yllättää sen sijaan se, miten harvoin organisaatio pystyy sanomaan, mikä näistä kursseista oli pakollinen, mikä niistä suoritettiin loppuun ja kuinka kauan tulos on voimassa, sillä juuri nämä kolme kysymystä järjestelmä ratkaisee ja juuri niitä ei yleensä esitä kukaan ennen ensimmäistä tarkastusta.

Milloin sitä todella tarvitaan: todiste, ei mukavuus

Useimmat organisaatiot eivät päädy hankkimaan järjestelmää siksi, että kouluttaminen olisi muuttunut vaikeammaksi, vaan siksi, että todistamisesta on tullut kallista. Työturvallisuuslain (738/2002) 14 § vaatii perehdyttämään työntekijän työhön, työpaikan olosuhteisiin ja työvälineisiin ennen uuden työn aloittamista, työtehtävien muuttuessa ja ennen uusien laitteiden tai menetelmien käyttöönottoa sekä täydentämään opetusta tarpeen mukaan, mutta se ei aseta yhtään kertausväliä eikä säilytysaikaa. Päivämäärät tulevat muualta: Työturvallisuuskeskuksen työturvallisuuskortti on voimassa viisi vuotta kerrallaan, ja samalla logiikalla toimivat alakohtaiset kortit, joita yhteisillä työpaikoilla vaaditaan. Kun ihmisiä on kaksikymmentä ja määräaikoja yksi, tätä seurataan päässä tai kalenterissa; kahdellasadalla työntekijällä, joiden aloituspäivät ovat eri, siitä tulee tehtävä, jossa virhe ei ole enää mahdollinen vaan väistämätön.

EU:n työsuojelun puitedirektiivi 89/391/ETY vaatii koulutusta paitsi työhön otettaessa myös silloin, kun ihminen siirretään toisiin tehtäviin, kun otetaan käyttöön uusia työvälineitä ja kun tekniikka muuttuu. Jokainen näistä tapahtumista synnyttää uuden määräajan uudelle ihmisjoukolle, ja juuri tämä yhdistelmä, ei koulutuksen sisältö, alkaa vaatia järjestelmää, sillä määräajat eivät osu yhteen, ryhmät menevät päällekkäin eikä yksikään niistä ala tammikuun ensimmäisenä. Säännellyillä aloilla kynnys on vielä matalampi: Suomessa laillistus on voimassa toistaiseksi eikä sitä uusita, mutta laki terveydenhuollon ammattihenkilöistä (559/1994) velvoittaa ammattihenkilön ylläpitämään ammattitaitoaan ja työnantajan luomaan siihen edellytykset, ja sosiaali- ja terveysministeriön täydennyskoulutusasetus (1194/2003) edellyttää, että toimintayksikkö seuraa koulutuksen toteutumista, siihen osallistumista ja sen kustannuksia — jonkun on siis laskettava ne ja pystyttävä näyttämään ne.

Mittakaavan hahmottamisessa auttaa sekin, miten yleinen tämä tarve ylipäätään on: Eurostatin mukaan vuonna 2020 jo 67,4 % vähintään kymmenen hengen EU-yrityksistä tarjosi henkilöstölleen täydennyskoulutusta, joten kyse ei ole harvinaisuudesta vaan enemmistöstä, ja kysymys on vain siitä, miten kukin sen kirjaa. Siksi rehellinen syy ottaa LMS käyttöön kuulostaa epäromanttiselta: sinun on tiedettävä, kuka on koulutettu, milloin se tapahtui, kuinka kauan se on voimassa ja mitä ensi neljänneksellä erääntyy, ja sinun on tiedettävä se soittamatta kollegalle, joka on juuri silloin lomalla. Jos tällaista kysymystä ei ole eikä kukaan sitä lähiaikoina esitä, järjestelmä ratkaisee ongelman, jota sinulla ei ole, ja tämä on ainoa projektityyppi, jota hyväkään käyttöönotto ei pelasta.

Milloin sitä ei tarvita, ja miksi sitä sanotaan harvoin

Työturvallisuuslaki vaatii opetuksen ja ohjauksen, ei niiden dokumentointia, ja tämä ero on tärkeämpi kuin miltä näyttää. Työterveyslaitoksen oma soveltamisopas suosittelee kirjallista perehdytyssuunnitelmaa ja allekirjoitusta perehdytyksen päätteeksi nimenomaan hyvänä käytäntönä eikä lain vaatimuksena, ja päivätty, allekirjoitettu osallistujalista on täysipainoinen merkintä, joka kestää tarkastuksessa täsmälleen yhtä hyvin kuin ruutukaappaus järjestelmästä. Viidelletoista ihmiselle, yhdelle kurssille ja yhdelle vuosittaiselle määräajalle oppimisen hallintajärjestelmä lisää ylläpitoa, versiopäivityksiä ja yhden paikan lisää, johon on kirjauduttava, mutta ei yhtään vastausta, jota sinulta olisi aiemmin puuttunut.

Emme suosittele järjestelmää myöskään silloin, kun organisaatiolla ei vielä ole sisältöä, ja tämä on yleisin tapaus, jossa projekti kannattaa siirtää tuonnemmaksi. Tyhjä järjestelmä ei ole investointi tulevaisuuteen vaan kuluerä, joka odottaa, että joku löytää aikaa kirjoittaa kurssit — eikä sitä aikaa käyttöönoton jälkeen yleensä löydy sen paremmin kuin sitä ennenkään. Halvempaa ja nopeampaa on kirjoittaa ensin kolme kurssia tekstinä ja videona, jakaa ne niin kuin tänään osaat, katsoa, mitä ihmiset niistä oikeasti käyttävät, ja vasta sen jälkeen ostaa paikka, johon ne pannaan. Toisin päin tehty projekti päätyy useammin ympäristöön, jossa on kaksi kurssia eikä yhtään säännöllistä käyttäjää.

Kolmas tapaus, jossa vastaus on ”ei”, on se, jossa todellinen tarve ei ole oppiminen vaan vastaukset. Jos työntekijät etsivät kurssin sijasta tiettyä kohtaa sisäisestä ohjeesta — miten tietyssä asiakastilanteessa toimitaan, mikä on menettely tietyssä poikkeustapauksessa —, oppimisen hallintajärjestelmä ei sitä ratkaise, koska se on rakennettu järjestyksessä etenevään opiskeluun ja lopussa olevaan kokeeseen eikä nopeaan tarkistukseen kesken työn. Näissä tapauksissa auttaa enemmän haku yrityksen omista dokumenteista, josta kirjoitimme erikseen artikkelissa RAG-ratkaisusta yrityksen dokumenteille — esittelyssä nämä kaksi näyttävät hämmentävän samanlaisilta, koska molemmissa on haku ja molemmissa yrityksen omaa sisältöä, mutta ne ratkaisevat aivan eri ongelmia ja korvaavat siksi harvoin toisensa.

Mitä järjestelmä oikeasti kirjaa

Kirjaaminen on se kohta, jossa järjestelmät eroavat toisistaan eniten, ja samalla se kohta, jota esittelyissä katsotaan vähiten, koska se näyttää tylsältä. Ilmoittautuminen vastaa kysymykseen, kenen kurssi oli suoritettava; edistyminen vastaa siihen, kuinka pitkälle ihminen pääsi; suoritusmerkintä todistaa, että ehdot täyttyivät; voimassaolo kertoo, kuinka kauan tämä kaikki pätee. Neljäs puuttuu useimmin halvoista järjestelmistä, ja juuri sitä tarvitset joka päivä, koska sen varassa ovat sekä muistutukset, uudelleensertifiointi että johdolle menevä raportti.

Käytännössä tämä tarkoittaa, että järjestelmän on osattava erottaa ”katsoi videon” siitä, että ”läpäisi kokeen”, ja molemmat siitä, että suoritus ”on voimassa tiettyyn päivään saakka”, ja sen on osattava tehdä se yhdessä näkymässä eikä kolmessa raportissa. Jos järjestelmä säilyttää vain ensimmäisen, se on tapahtumaloki eikä osaamisrekisteri, eikä se tarkastuksessa todista muuta kuin että tiedosto avattiin. Pyydä esittelyssä näyttämään yksi tietty ihminen, jolla yksi kurssi on suoritettu, toinen myöhässä ja kolmannen voimassaolo päättynyt, ja katso, kuinka helposti nämä kolme tilaa erottaa toisistaan ilman erillistä selitystä.

Toinen usein väärin ymmärretty asia on se, ettei oppimisen hallintajärjestelmä ole henkilöstöhallinnon järjestelmä eikä siitä sellaista tule. Se tietää kursseista ja tuloksista, mutta tehtävänimikkeen, yksikön ja työsuhteen alkamispäivän se saa muualta, ja juuri tämä integraatio ratkaisee, tapahtuuko ilmoittautuminen kursseille automaattisesti vai käsin. Jos uusi työntekijä on ilmoitettava kursseille käsin, käyttöönottoa ei ole viety loppuun asti — silloin on vain siirretty sama työ taulukosta uuteen käyttöliittymään, ja vuoden kuluttua joku kysyy taas, miksi listat eivät täsmää.

Kirjaamisella on toinenkin puoli, jota ajatellaan harvemmin: dataa syntyy myös järjestelmän ulkopuolella. Jos osa koulutuksesta tapahtuu ulkoisessa työkalussa — simulaattorissa, kielipalvelussa, laitevalmistajan omassa oppimisympäristössä —, kysymys kuuluu, palaako tulos sieltä merkintääsi automaattisesti vai kirjoittaako joku sen käsin. Juuri tätä varten on olemassa LTI (Learning Tools Interoperability), jonka avulla ulkoisen työkalun saa liitettyä ilman erillistä kirjautumista ja arvioinnin takaisin, ja juuri siksi hankinnassa kannattaa kysyä standardin nimen lisäksi se, mitkä sen osat toimittaja on toteuttanut ja miten se on todennettu.

Standardit, jotka ratkaisevat, pääsetkö pois

Kysymys, joka projektin alussa näyttää tekniseltä ja kolmen vuoden kuluttua osoittautuu kaupalliseksi, on tämä: kenelle sisältö ja merkinnät kuuluvat, jos päätät vaihtaa järjestelmää. Siihen ei vastaa sopimuskohta datan palauttamisesta vaan ne muodot, joissa sisältö ja merkinnät tosiasiassa säilytetään. SCORM on niistä vanhin ja edelleen yleisin tapa paketoida kurssi niin, että sen voi viedä toiseen järjestelmään; xAPI on uudempi kerros, joka ei kuvaa pakettia vaan tapahtumia — kuka teki mitä ja millä tuloksella — ja säilyttää ne erillisessä varastossa, jonka nimi on LRS (learning record store).

Tässä on vivahde, jota myyntiesityksistä ei löydy ja joka on viime vuosina muuttanut koko kysymyksenasettelun: ADL Initiative, Yhdysvaltain puolustusministeriön ohjelma, joka loi SCORMin ja julkaisi xAPI:n, on lakkautettu, ja sen GitHub-organisaatio, jonka GitHub on vahvistanut adlnet.gov:n omistamaksi, ilmoittaa: ”The ADL Initiative has been shut down.” Se ei tarkoita, että SCORM lakkaisi yhtäkkiä toimimasta, sillä muoto on julkaistu ja järjestelmät lukevat sitä jatkossakin, mutta se tarkoittaa, ettei nimen takana ole enää aktiivista ylläpitäjää, joka kehittäisi sitä eteenpäin. Tietomalli, johon SCORMin ajonaikainen toiminta perustuu, on ja pysyy IEEE-standardina: IEEE 1484.11.1-2022 on voimassa ja julkaistiin 15. huhtikuuta 2022.

xAPI:n tie on kulkenut päinvastaiseen suuntaan: se on standardoitu nimellä IEEE 9274.1.1-2023 ja julkaistiin 6. lokakuuta 2023, joten sillä on ylläpitäjä ja tässä muodossa syntyneet merkinnät pysyvät luettavina silloinkin, kun tuote vaihtuu. Kolmas standardi, joka kannattaa pyytää nimeltä, on LTI, jolla ulkoisen työkalun saa liitettyä ilman erillistä kirjautumista, ja 1EdTechin tuki kaikille LTI 1.3:a edeltäville versioille päättyi 30. kesäkuuta 2021, joten vastaus ”tuemme LTI:tä” ilman versionumeroa ei ole enää vastaus. Koko kurssin siirtämiseen on Common Cartridge, ja juuri sitä kannattaa vaatia näytettäväksi eikä keskusteltavaksi.

Miksi ”tukee standardia” ei ole sama kuin ”toimii”

Standardin nimi määrittelyssä ja standardin käyttäytyminen tietyssä järjestelmässä ovat kaksi eri asiaa, ja paras esimerkki on julkisesti Moodlen dokumentaatiossa, siis tarkistettavissa ilman yhdenkään toimittajan apua. Siellä lukee, että Moodle tukee SCORM 1.2:ta ja läpäisee ADL:n vaatimustenmukaisuustestit, mutta ettei Moodle tue SCORM 2004:ää. Uudempi versionumero ei siis tarkoita tässä parempaa tukea — se ei tarkoita mitään, ennen kuin se on kokeiltu —, ja toimittaja, joka ei sitä kerro, joko ei tiedä sitä tai laskee sen varaan, ettet tarkista.

Tästä seuraa käytännön koe, joka ei maksa mitään, vie noin tunnin ja kertoo enemmän kuin yksikään suositus: ota yksi todellinen kurssi siinä muodossa, jossa sisältösi tänään on, ja pyydä lataamaan se testiympäristöön esittelyn aikana eikä sopimuksen allekirjoittamisen jälkeen. Jos vastaus on, että se tehdään käyttöönoton kuluessa, olet jo saanut vastauksesi, ja se on halvin tieto, jonka tästä projektista saat. Sama koskee vientiä: pyydä ottamaan kurssi ulos ja viemään se toiseen järjestelmään, sillä juuri tuota toimenpidettä tarvitaan aikanaan kiireessä.

Toimittajan väitteet yhteensopivuudesta voi tarkistaa myös täysin hänestä riippumatta. 1EdTech ylläpitää julkista TrustEd Apps -luetteloa tuotteista, jotka ovat läpäisseet sertifioinnin, ja toteaa suoraan, että luettelosta puuttuva tuote joko ei ole läpäissyt sertifiointia tai sen sertifiointi on vanhentunut. Viisi minuuttia tässä luettelossa kertoo enemmän kuin viidenkymmenen kalvon esitys, ja se on käytännössä ainoa tämän alan lähde, jota myyjä ei ole itse julkaissut. Jos tuotetta ei sieltä löydy, se ei vielä ole ostokielto, mutta se on kysymys, johon kannattaa saada vastaus kirjallisena.

Sama varovaisuus koskee versionumeroita, jotka luetaan turhan helposti laadun mittarina. LTI 2.0 näyttää numeroltaan uudemmalta kuin 1.3, mutta 1EdTech luettelee sen nimenomaan niiden aiempien versioiden joukkoon, joiden tuki lopetettiin, joten tarjous, jossa tämä numero mainitaan etuna, lupaa käytännössä vanhentunutta ja vaille ylläpitoa jäänyttä liitäntätapaa. Jos tarjouksessa ei ole versionumeroa lainkaan, se kannattaa pyytää kirjallisena, sillä se on yksi rivi, joka myöhemmin ratkaisee, viekö integraatio seuraavaan työkaluun tunnin vai vaatiiko se oman projektin.

LMS ja LXP: mikä niiden ero on

Keskusteluissa tulee ennemmin tai myöhemmin vastaan lyhenne LXP, ja se ansaitsee selityksen, koska sen paino on pienempi kuin miltä kuulostaa. LMS olettaa, että organisaatio määrää, kenen on opittava mitä, ja kirjaa suorituksen; LXP (learning experience platform) taas nimeää lähestymistavan, jossa sisällön valitsee oppija itse ja järjestelmä suosittelee, jolloin paino siirtyy velvollisuudesta kiinnostukseen. Painotuserona se on todellinen ja toisinaan hyödyllinen — vapaaehtoisessa osaamisen kehittämisessä velvoitteiden kirjaaminen ei todellakaan ole pääasia, ja pakollisten kurssien lista pikemminkin haittaa siellä.

Mitä tällä erolla ei ole, on standardointiorganisaatio tai jokin tekninen raja, jonka voisi tarkistaa. Termin esitteli julkisesti syyskuussa 2018 henkilöstöteknologian analyytikko Josh Bersin omana keksintönään, ja siitä lähtien sitä on käytetty pääasiassa markkinoiden jaotteluun. Käytännössä tämä tarkoittaa, että kaksi samalla nimikkeellä varustettua tuotetta voivat olla yhtä erilaisia kuin mitkä tahansa kaksi tuotetta ilman sitä, ja ettei kategorian nimeen perustuva vertailu kerro mitään siitä, mitä tulet saamaan, joten hankintataulukossa tämä sarake jää tyhjäksi kohdaksi, jolla on otsikko: se luo turvallisuuden tunteen mutta ei ilmaise yhtäkään tarkistettavaa vaatimusta.

Vertailla kannattaa sen perusteella, mitä tietokantaan jää, kun esittely on ohi. Merkintäkerros, johon molemmat kategoriat viittaavat, on standardoitu — xAPI on IEEE 9274.1.1-2023 —, ja juuri se ratkaisee, pystytkö kolmen vuoden kuluttua sanomaan, mitä ihmiset oppivat, myös silloin kun tuote on siihen mennessä toinen. Jos toimittaja mainitsee kategorian nimen useammin kuin sen muodon, jossa merkinnät säilytetään ja josta ne haetaan ulos, keskustelu koskee markkinointia, ja sen voi sanoa ääneen jo palaverissa.

Käytännössä tämän tarkistaa kahdella kysymyksellä, jotka voi esittää missä tahansa esittelyssä. Ensimmäinen: mikä määrää, että tietyn ihmisen on suoritettava tietty kurssi tiettyyn päivään mennessä, ja missä tämä päätös järjestelmässä näkyy. Toinen: missä muodossa velvoitteen täyttyminen säilytetään ja miten se saadaan ulos, jos tuote vaihdetaan. Jos vastaus ensimmäiseen on, että järjestelmä suosittelee muttei velvoita, sinulla on kategorian nimestä riippumatta käsissäsi kirjasto, ja velvoitteiden kirjaaminen on ratkaistava jossain muualla.

Mihin oppimisen hallintajärjestelmä loppuu ja toinen alkaa

Raja, joka projekteissa ylitetään useimmin, kulkee oppimisen hallintajärjestelmän ja opintotieto- tai henkilöstöjärjestelmän välillä. Ensimmäinen hallitsee kursseja, toinen ihmisiä: valintoja, sopimuksia, ryhmiä, tehtävänimikkeitä ja työsuhteen tilaa. Oppimisen hallintajärjestelmään voi syöttää ihmisluettelon, mistä syntyy houkutus käyttää sitä myös rekisterinä, ja juuri tämä houkutus tuottaa tilanteen, jossa kahdessa paikassa on yhtä aikaa kaksi eri totuutta siitä, kuka on vielä työntekijä ja missä yksikössä.

Käytännön periaate on yksi ja se on yksinkertainen: ihminen luodaan siellä, missä hänet organisaatiossa luodaan, ja oppimisen hallintajärjestelmään hän vain tulee. Jos työntekijärekisteri on henkilöstöjärjestelmässä, sieltä tulee myös ilmoittautuminen kursseille, ja LMS antaa takaisin tuloksen ja voimassaolon. Jos tätä virtaa ei ole määritelty jo vaatimuksissa, se ratkaistaan lähes aina kuukausittaisella taulukolla, jonka joku kokoaa käsin — ja se on täsmälleen sama taulukko, josta koko projekti alkoi.

Samoin on todistusten ja asiakirjahallinnan laita: oppimisen hallintajärjestelmä osaa myöntää todistuksen kurssin suorittamisesta, mutta se ei ole asiakirjahallintajärjestelmä, ja oikeudellisesti merkittävä pitkäaikaissäilytys kuuluu yleensä sinne, missä sopimukset ja päätökset jo ovat, joten raja näiden kahden välille vedetään projektin alussa eikä sinä päivänä, jona joku sitä ensimmäisen kerran vaatii. Kun se tehdään ajoissa, integraatioiden lista lyhenee ja halpenee; kun ei tehdä, vuoden kuluttua ilmestyy vaatimus, jota kukaan ei ole suunnitellut ja jonka budjetti on jo käytetty.

Tästä seuraa myös se, miten raportteja kannattaa arvioida — ne kun hankinnassa yleensä pyydetään aivan viimeisenä. Raportti on hyödyllinen vain, jos se vastaa kysymykseen, jonka joku todella esittää — kuinka moni tässä yksikössä on myöhässä pakollisesta perehdytyksestä ja milloin kunkin voimassaolo päättyy —, eikä siihen, kuinka monta kurssia tässä kuussa avattiin. Jos järjestelmä saa ihmisten rakenteen henkilöstörekisteristä, tällainen raportti on yksi kysely; jos ei saa, se on taulukko, jonka joku kokoaa joka kuukausi käsin kahdesta viennistä.

Moodle esimerkkinä, ei suosituksena

Kun keskustelu etenee yksittäisiin tuotteisiin, Suomessa esiin tulee lähes aina Moodle, joten kannattaa sanoa, mikä se tosiasiassa on, ennen kuin mielipiteet alkavat. Moodle on oppimisen hallintajärjestelmä, jota kehittää ja ylläpitää Moodle Pty Ltd, ja se on vapaasti saatavilla GPL-lisenssillä. Se tarkoittaa, että lähdekoodi on avointa eikä itse ohjelmistosta tarvitse maksaa, mutta ei tarkoita, että kaikki sen ympärillä olisi vapaasti käytettävissä: GPL koskee koodia, kun taas sana Moodle ja logot ovat Moodle Pty Ltd:n tavaramerkkejä, joiden kaupalliseen käyttöön tarvitaan omistajan ennalta antama kirjallinen lupa.

Käytännön päätöksen kannalta lisenssiä tärkeämpi on ylläpidon rytmi, koska juuri se määrää seuraavien vuosien budjetin. Moodle julkaisee julkaisukalenterin, jossa on kaksi isoa versiota vuodessa, huhtikuussa ja lokakuussa, sekä ylläpitojulkaisuja kahden kuukauden välein; jokainen iso versio saa kahdentoista kuukauden yleisen tuen, tavallinen julkaisu tietoturvakorjauksia kahdeksaantoista kuukauteen ja LTS-julkaisu kolmeenkymmeneenkuuteen. Tämän kalenterin mukaan suunnitellaan raha ja ihmiset, sillä versio, jonka tuki on päättynyt, ei ole enää makuasia vaan tietoturva-asia, ja se osuu yleensä huonoon hetkeen.

On myös vaatimuksia, jotka koskevat infrastruktuuria ja jotka kannattaa tarkistaa ennen lupauksia: Moodle 5.2 vaatii vähintään PHP 8.3.0:n ja jonkin näistä: PostgreSQL 16, MySQL 8.4, MariaDB 10.11.0 tai Microsoft SQL Server 2019. Ja vielä yksi asia, joka on hyvä tietää ennen kuin luet vaikuttavia levinneisyyslukuja: moodle.org:n julkaisema tilasto tulee sivustoilta, jotka ovat itse vapaaehtoisesti rekisteröityneet, joten se kertoo yhteisön koosta eikä mitatusta markkinaosuudesta. Erikseen on olemassa Moodle Workplace, joka on saatavilla vain sertifioitujen kumppanien kautta, ja se on eri tuote eri hankintapolulla.

Mitään edellä sanotusta ei pidä lukea suosituksena valita juuri tämä järjestelmä, sillä oikea vastaus riippuu siitä, kuinka monta ihmistä, kuinka monta kurssia ja kuinka monta määräaikaa sinulla todella on. Moodle on tässä esimerkkinä siksi, että se on avoin ja sen dokumentaatio on julkista, jolloin jokaisen sitä koskevan väitteen voi tarkistaa ilman yhdenkään toimittajan välikättä — ja juuri tällä ominaisuudella mitataan mitä tahansa ehdokasta, myös suljettua tuotetta, jonka dokumentaatio on piilotettu kirjautumislomakkeen taakse.

Mikä maksaa enemmän kuin lisenssi

Jos lisenssi on ilmainen, budjetti menee muualle, ja se on paljon parempi nähdä ennen projektia kuin sen puolivälissä. Suurin erä on lähes aina sisältö: kurssien valmistelu, videoiden tekeminen, kokeiden laatiminen ja saman sisällön ylläpito myöhemmin, kun menettelyt tai säädökset muuttuvat. Toinen on migraatio, jos jotain on jo olemassa — vanhoja Moodle-versioita, kursseja toisessa järjestelmässä, osallistujahistoriaa, joka on säilytettävä siksi, että voimassaoloajat eivät ole vielä päättyneet ja todiste niistä tarvitaan edelleen.

Kolmas erä on integraatiot ja tunnistautuminen, ja juuri tässä suomalaiset vaatimukset poikkeavat yleisistä listoista: korkeakouluissa ja tutkimuslaitoksissa kirjaudutaan CSC:n operoiman Haka-luottamusverkoston kautta SAML 2.0:lla, perusopetuksessa ja toisella asteella Opetushallituksen MPASSid-ratkaisulla, julkisen sektorin asioinnissa Suomi.fi-tunnistuksella ja yrityksissä koko organisaation kertakirjautumisella. Neljäs, joka suunnitelmissa näkyy harvimmin, on ylläpito käyttöönoton jälkeen: versiopäivitykset edellä mainitun kalenterin mukaan, varmuuskopiot, käyttäjätuki ja pieni mutta katkeamaton muutosvirta. Siitä, miten tällaiset projektit hinnoittelemme ja missä järjestyksessä ne teemme, olemme kirjoittaneet erikseen Moodle-järjestelmien kehityksen ja ylläpidon sivulle.

Ennen keskustelua kenenkään toimittajan kanssa kannattaa lukea myös se, minkä olemme koonneet artikkeliin kymmenestä tyypillisimmästä virheestä kehitystä tilattaessa, sillä näissä projekteissa ne toistuvat lähes muuttumattomina: määrittelemätön laajuus, testaamaton vienti ja oletus, että sisältö syntyy itsestään. Jos haluat, että joku lukee nykytilanteesi läpi ja sanoo, onko järjestelmä tässä ylipäätään oikea vastaus, kirjoita meille — joskus rehellisin vastaus on, että se mitä sinulla jo on riittää, ja että raha kannattaa käyttää sisältöön eikä alustaan.

Viides erä, joka suomenkielisessä ympäristössä kannattaa tarkistaa erikseen, on lokalisointi. Moodle-yhteisö on kääntänyt järjestelmän yli 120 kielelle, mutta käännöksen kattavuus vaihtelee kielten välillä, ja se näkyy julkisesti Moodlen käännösympäristössä, joten sen voi tarkistaa ennen päätöstä. Käytännössä tämä tarkoittaa, että osa harvemmin käytetyistä näkymistä voi olla englanniksi silloinkin, kun käyttöliittymä on muuten suomeksi, ja että valinta täydellisen käännöksen ja sen puutteen välillä on sinun eikä sattuman — mutta vain, jos tarkistat sen ajoissa.