Mis on õpihaldussüsteem (LMS) ja millal seda tegelikult vaja on

LMS ei ole esitluste kaust ja rida arvutustabelis. Kui registreerumist, läbimist ja kehtivusaega tuleb tõendada, hakkab süsteem end ära tasuma — kui ei tule, on see kallis lisaosa.

Kujutage ette jagatud kausta, kus on seitse esitlust, kaks videot ja üks juhend nimega „lõplik_versioon_2_parandatud.pdf“, ja selle kõrval arvutustabelit, kuhu personalispetsialist märgib käsitsi, kes mida vaadanud on. Kuni töötajaid on kakskümmend ja kursus üks, toimib see kord täiesti hästi ega maksa midagi, mistõttu keegi ei kiirusta seda muutma. Kokku kukub see mujal — hetkel, mil keegi küsib, kas konkreetne inimene sai mullu tõesti juhendamise, ja ainus vastus, mis teil on, on tabelirida, mida keegi kinnitada ei saa ja mida igaüks võis üle kirjutada. Õpihaldussüsteem ehk LMS on tarkvara, mille ainus tõsine ülesanne on muuta see rida kirjeks, millel on päritolu, kuupäev ja autor.

Mis on õpihaldussüsteem ja millega seda kõige sagedamini segi aetakse

Õpihaldussüsteem teeb nelja asja: registreerib inimesi kursustele, toimetab sisu kohale, kontrollib omandamist ja hoiab kirjet sellest, mis juhtus. Ostetakse esimese ja neljanda pärast, aga demol räägitakse teisest ja kolmandast, sest neid on ekraanil hõlpsam näidata. Kui sellest loendist kirje välja võtta, jääb järele parema liidesega failihoidla, ja neid on teie organisatsioonis tõenäoliselt juba vähemalt kaks.

Just seepärast ei ole LMS videoplatvorm, veebiseminaride tööriist ega kursuste müügikoht, kuigi kõik kolm oskavad õppematerjali näidata sama hästi või paremini. Videoplatvorm teab, et fail mängiti maha. Ta ei tea, et selle mängis maha inimene, kes pidi kursuse läbima kindlaks kuupäevaks, et ta tegi seda teisel katsel ja et aasta pärast tuleb kõik otsast peale võtta. Vahe ei ole funktsioonide loendis, mida hanketabelis kõrvutatakse, vaid küsimuses, millele süsteem oskab vastata kahe aasta pärast, kui ükski algselt asjaga seotud inimene majas enam ei tööta.

Sõna „platvorm“ eksitab siin rohkem, kui aitab, sest sellega nimetatakse ühtviisi süsteeme, mis loendavad kohustusi, ja neid, mis pakuvad vabalt valitavat sisu — müüvad neid pealegi samad inimesed. Praktiline jaotus on siiski lihtne ja peab igal juhul vastu: kui keegi teine määrab, mida te läbima peate, ja keegi kontrollib, kas te seda tegite, on tegemist õpihaldussüsteemiga. Kui valite ise ja keegi järge ei pea, on tegemist raamatukoguga. Kasu võib olla mõlemast korraga, kuid audiitori küsimusele vastab ainult esimene, ja tavaliselt just see küsimus projektini viibki.

Sellise arvepidamise vajadus ei ole Eesti eripära ja väike see samuti ei ole: Eurostati andmetel oli 2025. aasta esimeses kvartalis 16% Euroopa Liidu 16–74-aastastest elanikest kolme eelneva kuu jooksul läbinud mõne veebikursuse, nii et ekraanilt õppimine ei üllata enam kedagi. Üllatab hoopis see, kui harva oskab organisatsioon öelda, milline neist kursustest oli kohustuslik, milline sai läbitud ja kui kaua tulemus kehtib. Just need kolm küsimust süsteem ära lahendabki, ja just neid ei esita tavaliselt keegi enne esimest kontrolli.

Millal seda tõesti vaja on: tõend, mitte mugavus

Enamik organisatsioone jõuab õppesüsteemini mitte sellepärast, et õpe oleks keerulisemaks läinud, vaid sellepärast, et tõendamine on läinud kalliks. Töötervishoiu ja tööohutuse seadus paneb tööandjale kohustuse registreerida juhendamise ja väljaõppe kuupäev ja sisu kirjalikult või kirjalikku taasesitamist võimaldavas vormis, ning töötaja kinnitab läbitu samas vormis. Ühtset riiklikku sagedust seadus 2019. aastast enam ette ei kirjuta: millal juhendamist korrata, otsustab tööandja ise riskianalüüsist lähtudes. See teeb tähtaegade jälgimise raskemaks, mitte lihtsamaks — ühe üleriigilise kuupäeva asemel on igal ametikohal oma tingimus, ja kahesaja töötaja juures on neid tingimusi kakssada.

Euroopa Liidu töökeskkonna raamdirektiiv 89/391/EMÜ nõuab väljaõppe tagamist mitte ainult tööle võtmisel, vaid ka inimese teisele tööle üleviimisel, uue töövahendi kasutuselevõtul ja tehnoloogia muutumisel. Iga selline sündmus tekitab uue tähtaja uuele inimeste rühmale, ja just see kombinatoorika, mitte õppesisu, hakkab süsteemi nõudma: tähtajad ei lange kokku, rühmad kattuvad ja ükski neist ei alga esimesel jaanuaril. Reguleeritud valdkondades on lävi veel madalam. Veoauto- ja bussijuhi ametipädevus kehtib viis aastat ja selle säilitamiseks tuleb igas tsüklis läbida 35 tundi ametialast täienduskoolitust, mille peab keegi kokku lugema ja nõudmisel ette näitama.

Mastaabi aitab mõista seegi, kui levinud niisugune vajadus üldse on: Eurostati andmetel pakkus 2020. aastal 67,4% vähemalt kümne töötajaga Euroopa Liidu ettevõtetest oma inimestele täiendusõpet, nii et jutt ei käi harvast erandist, vaid enamusest, ja küsimus on ainult selles, kuidas igaüks neist seda loendab. Seepärast kõlab aus põhjus LMS-i kasutusele võtta tavaliselt üsna proosaliselt: te peate teadma, kes on välja õpetatud, millal see toimus, kui kaua see kehtib ja mis juhtub järgmises kvartalis — ja te peate seda teadma ilma helistamata kolleegile, kes on parasjagu puhkusel. Kui sellist küsimust ei ole ega tule, lahendab süsteem probleemi, mida teil ei ole, ja see on ainus projektiliik, mida hea juurutamine ei päästa.

Millal seda vaja ei ole ja miks seda harva öeldakse

Seadus nõuab kirjet, mitte tarkvara, ja see vahe on tähtsam, kui paistab. Töötervishoiu ja tööohutuse seadus nimetab vormi — kirjalik või kirjalikku taasesitamist võimaldav — ega nimeta ühtegi toodet, nii et kuupäevaga juhendamiskaart on täisväärtuslik kirje, mis peab kontrollis vastu sama hästi kui ekraanipilt süsteemist. Sotsiaalministeeriumi juhis ütleb sedasama teistpidi: sobib ka andmebaas, kus töötaja juhendamisega tutvumist kinnitab. Viieteistkümnele inimesele, ühele kursusele ja ühele tähtajale aastas lisab õppesüsteem ülalpidamise, versiooniuuendused ja veel ühe koha, kuhu sisse logida, kuid mitte ühtegi vastust, mida teil seni puudu oli.

Me ei soovita õppesüsteemi ka siis, kui organisatsioonil ei ole veel sisu, ja see on kõige sagedasem juhtum, mil projekt tasub edasi lükata. Tühi süsteem ei ole investeering tulevikku, vaid kulu, mis ootab, kuni keegi leiab aega kursused kirjutada — ja pärast käivitamist ei leidu seda aega tavaliselt samamoodi, nagu seda ei leidunud enne. Odavam on kirjutada kõigepealt kolm kursust tekstina ja videona, levitada neid nii, nagu täna oskate, vaadata, milliseid inimesed tegelikult kasutavad, ja alles siis osta koht, kuhu need panna. Vastupidi tehtud projekt lõpeb sagedamini platvormiga, kus on kaks kursust ja mitte ühtegi püsivat kasutajat.

Kolmas juhtum, mil vastus on „ei“, on see, kui tegelik vajadus ei ole õpe, vaid vastused. Kui töötajad ei otsi kursust, vaid kindlat punkti sisedokumendist — kuidas käituda konkreetse kliendijuhtumiga, milline on kord konkreetses olukorras —, siis õppesüsteem seda ei lahenda: see on ehitatud järjestikuseks läbimiseks koos kontrolliga lõpus, mitte kiireks järelevaatamiseks töö keskel. Siin aitab rohkem otsing ettevõtte dokumentides, millest kirjutasime eraldi artiklis ettevõtte dokumentidel põhinevast RAG-lahendusest. Esitlusel näevad need kaks petlikult sarnased välja, sest mõlemas on otsing ja mõlemas ettevõtte sisu, kuid nad lahendavad eri probleeme ega asenda teineteist.

Mida süsteem tegelikult loendab

Arvepidamine on koht, kus õppesüsteemid omavahel kõige rohkem erinevad, ja ühtlasi koht, mida demol kõige vähem vaadatakse, sest see näeb igav välja. Kursusele registreerumine vastab küsimusele, kes pidi kursuse läbima; edenemine ütleb, kui kaugele inimene jõudis; kursuse läbimise kirje tõendab, et tingimused said täidetud; kehtivusaeg ütleb, kui kaua see kõik kehtib. Neljas puudub odavates süsteemides kõige sagedamini, ja just seda te vajate iga päev, sest sellel püsivad ühtviisi meeldetuletused, resertifitseerimine ja aruanne juhtkonnale.

Praktikas tähendab see, et süsteem peab oskama eristada „vaatas video ära“, „sooritas kontrolli“ ja „kehtib kuni“ ning tegema seda ühes vaates, mitte kolmes aruandes. Kui süsteem hoiab ainult esimest, on tegemist tegevuslogiga, mitte pädevusregistriga, ja kontrollis ei tõenda see midagi peale selle, et fail avati. Paluge demol näidata konkreetset inimest, kellel üks kursus on sooritatud, teine hilinenud ja kolmanda kehtivus lõppenud, ning vaadake, kui hõlpsalt on neid kolme seisundit ilma selgituseta eristada.

Teine sageli valesti mõistetud osa on see, et õppesüsteem ei ole personalisüsteem ega saa selleks kunagi. Ta teab kursustest ja tulemustest, aga ametikoha, struktuuriüksuse ja töösuhte alguskuupäeva saab ta mujalt, ning just see liidestus otsustab, kas kursusele registreerumine käib automaatselt või käsitsi. Kui uus töötaja tuleb kursustele käsitsi kirja panna, ei ole süsteem lõpuni juurutatud: ta on sama töö arvutustabelist uude liidesesse tõstnud, ja aasta pärast küsib keegi jälle, miks nimekirjad ei klapi.

Arvepidamisel on ka teine pool, millele mõeldakse harvemini: andmed tekivad tihti väljaspool süsteemi ennast. Kui osa õppest toimub välises tööriistas — simulaatoris, keeleplatvormil, seadmetootja õppekeskkonnas —, on küsimus selles, kas tulemus jõuab sealt teie kirjesse automaatselt või kirjutab keegi selle käsitsi ümber. Just selleks on olemas LTI (Learning Tools Interoperability), mis lubab välise tööriista eraldi sisselogimiseta külge panna ja hinde tagasi tuua, ja just seepärast tasub hankes küsida mitte ainult standardi nime, vaid ka seda, millised selle osad on pakkuja ellu viinud ja kuidas seda kontrollitud on.

Standardid, mis otsustavad, kas te saate lahkuda

Küsimus, mis projekti alguses näib tehniline ja kolme aasta pärast osutub äriliseks, on see: kellele kuuluvad sisu ja kirjed, kui te otsustate platvormi vahetada. Sellele ei vasta lepingupunkt andmete tagastamisest, vaid vormingud, milles sisu ja kirjed tegelikult seisavad. SCORM on neist vanim ja endiselt levinuim viis pakkida kursus nii, et selle saaks teise süsteemi panna. xAPI on uuem kiht, mis ei kirjelda paketti, vaid sündmusi — kes, mida ja millise tulemusega tegi — ja hoiab neid eraldi hoidlas, mille nimi on LRS (learning record store).

Siin on nüanss, mida müügiesitlustelt ei leia ja mis on viimastel aastatel kogu küsimuseasetuse ümber pööranud: ADL Initiative, Ameerika Ühendriikide kaitseministeeriumi programm, mis SCORM-i lõi ja xAPI avaldas, on suletud, ning tema GitHubi organisatsioon, mille kuuluvust adlnet.gov-ile on GitHub kinnitanud, teatab: „The ADL Initiative has been shut down.“ See ei tähenda, et SCORM äkki töötamast lakkaks, sest vorming on avaldatud ja süsteemid loevad seda edasi, kuid tähendab, et kaubamärgi taga ei ole enam aktiivset hooldajat, kes seda arendaks. Andmemudel, millel SCORM-i käitusaeg püsib, on ja jääb IEEE standardiks: IEEE 1484.11.1-2022 kehtib ja avaldati 15. aprillil 2022.

xAPI tee on kulgenud vastupidises suunas. See on standarditud kui IEEE 9274.1.1-2023 ja avaldatud 6. oktoobril 2023, seega on hooldaja olemas ja selles vormingus tehtud kirjed jäävad loetavaks ka siis, kui toode vahetub. Kolmas standard, mida tasub nimepidi küsida, on LTI, mis lubab välise tööriista eraldi sisselogimiseta külge panna, ja 1EdTech lõpetas kõigi LTI 1.3-st varasemate versioonide toe 30. juunil 2021 — nii et vastus „me toetame LTI-d“ ilma versiooninumbrita ei ole enam vastus. Terve kursuse ülekandmiseks on Common Cartridge, ja just seda tasub lasta ette näidata, mitte arutada.

Miks „toetab standardit“ ei ole sama mis „töötab“

Standardi nimi spetsifikatsioonis ja standardi käitumine konkreetses süsteemis on kaks eri asja, ja parim näide on avalikult loetav Moodle'i dokumentatsioonis, seega kontrollitav ilma pakkuja abita. Seal on kirjas, et Moodle toetab SCORM 1.2 ja läbib ADL-i vastavustestid, kuid SCORM 2004 tuge Moodle'il ei ole. Suurem versiooninumber ei tähenda siin paremat tuge — see ei tähenda midagi, kuni pole kontrollitud —, ja pakkuja, kes seda välja ei ütle, kas ei tea või arvestab sellega, et te ei kontrolli.

Sellest tuleneb praktiline katse, mis ei maksa midagi, võtab umbes tunni ja ütleb rohkem kui ükski soovitus: võtke üks päris kursus selles vormingus, milles teie sisu juba täna olemas on, ja paluge see demo ajal testkeskkonda üles laadida, mitte pärast lepingu allkirjastamist. Kui vastus on, et seda tehakse juurutuse käigus, olete vastuse juba kätte saanud, ja see on kõige odavam teave, mille selles projektis üldse saate. Sama kehtib ekspordi kohta: paluge kursus välja võtta ja teise süsteemi panna, sest just seda toimingut läheb kunagi kiirustades vaja.

Pakkuja väiteid ühilduvuse kohta saab kontrollida ka temast sõltumatult. 1EdTech peab avalikku TrustEd Appsi loendit toodetest, mis on sertifitseerimise läbinud, ja ütleb otse, et toode, mida loendis ei ole, kas ei ole sertifitseerimist läbinud või on selle kehtivus lõppenud. Viis minutit selles loendis ütleb rohkem kui viiekümne slaidi pikkune esitlus, ja see on siin praktiliselt ainus allikas, mida ei ole avaldanud müüja ise. Kui toodet seal ei ole, ei ole see veel ostukeeld, aga on küsimus, millele tasub saada kirjalik vastus.

Sama ettevaatlikkus käib versiooninumbrite kohta, mida kiputakse lugema kvaliteedinäitajana. LTI 2.0 näib numbri poolest uuem kui 1.3, kuid 1EdTech loeb selle just nende varasemate versioonide hulka, mille toe ta lõpetas, mistõttu pakkumine, kus see number on esitatud eelisena, lubab tegelikkuses vananenud ja hooldamata ühendusviisi. Kui pakkumises versiooninumbrit üldse ei ole, tasub see kirjalikult välja nõuda, sest see on üks rida, mis otsustab hiljem, kas järgmise tööriista liidestus võtab tunni või eraldi projekti.

LMS ja LXP: milles on vahe

Vestlustes õppesüsteemidest kerkib varem või hiljem esile lühend LXP, ja see väärib selgitust, sest selle kaal on väiksem, kui kõlab. LMS eeldab, et organisatsioon määrab, kes mida läbima peab, ja loendab täitmist; LXP (learning experience platform) tähistab lähenemist, kus sisu valib õppija ise, süsteem aga soovitab, ning rõhk nihkub kohustuselt huvile. Rõhuasetuse vahena on see päris ja kohati kasulik: vabatahtlikul enesetäiendamisel ei olegi kohustuste arvepidamine peamine ja sunnitud kursuste nimekiri pigem segab.

Mida sel vahel ei ole, on standardiorganisatsioon või mõni tehniline piir, mida saaks kontrollida. Termini esitles 2018. aasta septembris avalikult oma sõnaloominguna personalitehnoloogia analüütik Josh Bersin, ja sellest ajast kasutatakse seda peamiselt turu jagamiseks. Praktikas tähendab see, et kaks sama nimetusega toodet võivad olla sama erinevad kui ükskõik millised kaks toodet ilma selle nimetuseta, ja et võrdlus kategooria nime järgi ei ütle midagi selle kohta, mida te saate — nii jääb hanketabelisse tühi lahter pealkirjaga, mis loob turvatunnet, kuid ei väljenda ühtegi kontrollitavat nõuet.

Võrrelda tasub selle järgi, mis jääb andmebaasi siis, kui demo on läbi. Kirjekiht, millele mõlemad kategooriad viitavad, on standarditud — xAPI on IEEE 9274.1.1-2023 —, ja just see otsustab, kas te oskate kolme aasta pärast öelda, mida inimesed omandasid, ka siis, kui toode on selleks ajaks teine. Kui pakkuja mainib kategooria nime sagedamini kui vormingut, milles kirjeid hoitakse ja millest neid kätte saab, käib jutt turundusest, ja seda tasub juba koosolekul valjusti välja öelda.

Praktikas kontrollib seda kaks küsimust, mida võib esitada igal demol. Esimene: mis määrab, et konkreetne inimene peab konkreetse kursuse läbima konkreetseks kuupäevaks, ja kus see otsus süsteemis näha on. Teine: millises vormingus nende kohustuste täitmist hoitakse ja kuidas see kätte saadakse, kui toode välja vahetatakse. Kui vastus esimesele on, et süsteem soovitab, aga ei kohusta, siis on teil kategooria nimest hoolimata käes raamatukogu, ja kohustuste arvepidamine tuleb lahendada mujal.

Kus lõpeb õppesüsteem ja algab teine

Piir, mida projektides kõige sagedamini ületatakse, jookseb õppesüsteemi ning õppeinfosüsteemi (ÕIS) või personalisüsteemi vahel. Esimene haldab kursusi, teine inimesi: vastuvõttu, lepinguid, rühmi, ametikohti ja staatust. Õppesüsteemi saab inimeste nimekirja sisse laadida, mistõttu tekib kiusatus kasutada seda ka registrina, ja just see kiusatus loob olukorra, kus kahes kohas korraga elab kaks eri tõeversiooni sellest, kes on veel töötaja ja millises üksuses.

Praktiline põhimõte on üks ja lihtne: inimene luuakse seal, kus ta organisatsioonis luuakse, ja õppesüsteemi ta üksnes saabub. Kui töötajate register on personalisüsteemis, siis tuleb sealt ka kursusele registreerumine, õppesüsteem aga annab vastu tulemuse ja kehtivusaja. Kui see liikumine ei ole juba nõuetes kirjas, lahendatakse see peaaegu alati igakuise arvutustabeliga, mille keegi käsitsi kokku paneb — ja see on täpselt seesama arvutustabel, millest kogu projekt alguse sai.

Sarnane lugu on tunnistuste ja dokumendihaldusega: õppesüsteem oskab väljastada kinnituse kursuse läbimise kohta, kuid ta ei ole dokumendihaldussüsteem, ja õigusliku tähendusega pikaajaline säilitamine kuulub tavaliselt sinna, kus juba seisavad lepingud ja käskkirjad, mistõttu piir kahe süsteemi vahel tõmmatakse projekti alguses, mitte päeval, mil keegi seda esimest korda nõuab. Kui see tehakse õigel ajal, jääb liidestuste loend lühemaks ja odavamaks; kui ei tehta, ilmub aasta pärast nõue, mida keegi ei planeerinud ja mille jaoks eelarve on juba ära kulutatud.

Sellest tuleneb ka see, kuidas hinnata aruandeid, mida hankes küsitakse tavaliselt kõige viimasena. Aruanne on kasulik ainult siis, kui see vastab küsimusele, mida keegi tõesti esitab — mitu inimest selles üksuses on kohustusliku juhendamisega hilinenud ja millal kellelgi kehtivus lõpeb —, mitte sellele, mitu kursust sel kuul avati. Kui süsteem saab inimeste struktuuri personaliregistrist, on niisugune aruanne üks päring; kui ei saa, on see arvutustabel, mille keegi paneb igal kuul käsitsi kokku kahest ekspordist.

Moodle näitena, mitte soovitusena

Kui jutt jõuab konkreetsete toodeteni, kõlab Eestis peaaegu alati Moodle, nii et enne arvamusi tasub öelda, mis see faktiliselt on. Moodle on õpihaldussüsteem, mida arendab ja hooldab Moodle Pty Ltd, ja see on GPL-litsentsiga vabalt saadaval. Lähtekood on seega avatud ja tarkvara enda eest maksta ei ole vaja, kuid kõik selle ümber ei ole vabalt kasutatav: GPL käib koodi kohta, sõna Moodle ja logod on aga kaubamärgid, mille ärilisel kasutamisel on vaja omaniku eelnevat kirjalikku luba.

Litsentsist tähtsam on praktilise otsuse jaoks hooldusrütm, sest just see määrab järgmiste aastate eelarve. Moodle avaldab väljalasete kalendri, milles on kaks suurt versiooni aastas — aprillis ja oktoobris — ja hooldusväljalasked iga kahe kuu tagant; iga suur versioon saab kaksteist kuud üldist tuge, tavaline väljalase turvaparandusi kuni kaheksateist ja LTS-väljalase kuni kolmkümmend kuus kuud. Selle kalendri järgi planeeritakse raha ja inimesi, sest versioon, mille tugi on lõppenud, ei ole enam maitseküsimus, vaid turvaküsimus, ja see saabub tavaliselt sobimatul hetkel.

On ka taristunõudeid, mida tasub kontrollida enne lubadusi: Moodle 5.2 eeldab vähemalt PHP 8.3.0 ja üht neist — PostgreSQL 16, MySQL 8.4, MariaDB 10.11.0 või Microsoft SQL Server 2019. Ja veel üks asi, mida on hea teada, enne kui loete muljetavaldavaid levikunumbreid: moodle.org-i avaldatud statistika tuleb saitidelt, mis on end ise vabatahtlikult registreerinud, nii et see näitab kogukonna suurust, mitte mõõdetud turuosa. Eraldi on olemas Moodle Workplace, mis on saadaval üksnes sertifitseeritud partnerite kaudu — teine toode teistsuguse hanketeega.

Midagi eelnevast ei maksa lugeda soovituseks just see süsteem valida, sest õige vastus sõltub sellest, kui palju inimesi, kursusi ja tähtaegu teil tegelikult on. Moodle on siin näide seepärast, et ta on avatud ja tema dokumentatsioon on avalik, seega saab iga väidet tema kohta kontrollida ilma ühegi pakkuja vahenduseta — ja just see on omadus, mille järgi mõõdetakse iga kandidaati, ka suletud toodet, mille dokumentatsioon on peidus sisselogimisvormi taga.

Mis maksab rohkem kui litsents

Kui litsents on tasuta, läheb eelarve mujale, ja seda on parem näha enne projekti kui selle keskel. Suurim rida on peaaegu alati sisu: kursuste ettevalmistamine, videote salvestamine, kontrollide koostamine ja seesama sisu hooldamine hiljem, kui korrad või õigusaktid muutuvad. Teine on migreerimine, kui midagi juba olemas on — vanad Moodle'i versioonid, kursused teises süsteemis, osalejate ajalugu, mis tuleb alles hoida, sest tähtajad kehtivad veel ja tõendit on endiselt vaja.

Kolmas rida on liidestused ja autentimine, ja just siin erinevad Eesti nõuded üldistest loeteludest: sisselogimine ID-kaardi, Mobiil-ID või Smart-ID abil riigi autentimisteenuse (TARA) kaudu, hariduses HarID või TAAT, ettevõttes kogu organisatsiooni ühekordne sisselogimine SAML-i või OpenID Connecti kaudu, ning ühendus õppeinfosüsteemi või personaliregistriga. Neljas, mida plaanides nähakse harvemini, on hooldus pärast käivitamist: versiooniuuendused eespool nimetatud kalendri järgi, varukoopiad, kasutajatugi ja väike, kuid katkematu muudatuste vool. Sellest, kuidas me niisuguseid projekte arvestame ja millises järjekorras neid teeme, oleme kirjutanud eraldi Moodle LMS-i juurutamise ja hoolduse lehel.

Enne juttu ükskõik millise pakkujaga tasub läbi lugeda ka see, mille oleme kokku pannud artiklis kõige sagedasematest vigadest arendust tellides, sest õppesüsteemide projektides korduvad need peaaegu muutumatuna: määramata maht, kontrollimata eksport ja eeldus, et sisu tekib iseenesest. Kui soovite, et keegi loeks läbi teie olukorra ja ütleks, kas süsteem on siin üldse õige vastus, kirjutage meile — vahel on ausaim vastus see, et olemasolevast piisab ja raha tasub kulutada sisule, mitte platvormile.

Viies rida, mida eestikeelses keskkonnas tasub eraldi kontrollida, on lokaliseerimine. Moodle'i kogukond on süsteemi tõlkinud enam kui 120 keelde, kuid tõlke täielikkus keelte lõikes erineb, ja see on Moodle'i tõlkekeskkonnas avalikult näha, seega enne otsust kontrollitav. Praktikas tähendab see, et mõni harvem ekraan või üksik silt võib olla ingliskeelne ka siis, kui liides on üldiselt eestikeelne — nii on see ka Eesti ülikoolide Moodle'is. Valik täieliku tõlke ja selle puudumise vahel on teie oma, mitte juhus, aga ainult siis, kui te kontrollite seda õigel ajal.