Jak napsat zadání pro výběr LMS

Výběr systému pro řízení vzdělávání (LMS) obvykle neselhává na technologiích, ale na nejasně definovaných očekáváních. Pečlivě připravené zadání sjednotí jazyk mezi vaším týmem a dodavateli, přinese porovnatelné nabídky a výrazně zkrátí následnou implementaci. 

Tento článek Vás provede celým procesem: od definice cílů a uživatelů přes obsah a funkce, integrace a bezpečnost až po hodnoticí kritéria.

Tip: Pokud už zvažujete konkrétní platformy, doporučujeme nejprve vnitřně zformulovat „must-have“ požadavky, a teprve poté začít jednat s dodavateli. Vyhnete se tak rozptylování debatou o funkcích, které pro vaše potřeby nejsou zásadní.

Kdy se zadáním začít a proč na něm záleží

Zadání má smysl vytvářet ve chvíli, kdy znáte alespoň rámcový záměr projektu a máte základní přehled o trhu. Naprosto klíčové je pak v případě tvorby Veřejné zakázky. Správně napsaná zadávací dokumentace funguje jako referenční bod pro všechny zúčastněné: pro váš interní tým i pro potenciální dodavatele. Čím přesněji popíšete kontext a očekávání, tím realističtější a srovnatelnější nabídky obdržíte. 

Kontext a cíle: stanovte měřitelné výsledky

Úvod zadávací dokumentace by měl v několika odstavcích vysvětlit, kdo jste, proč LMS zavádíte nebo obměňujete a jaké výsledky očekáváte. Vyhněte se obecným formulacím a preferujte měřitelné ukazatele: například „zkrátit čas do dokončení povinných školení u nováčků z 30 na 21 dní do šesti měsíců od zavedení LMS“ nebo „zvýšit roční míru dokončení zákonných školení z 85 % na 95 %“. Takto formulované cíle následně promítnete do hodnotících kritérií, do scénářů i do akceptačních testů.

Tip: Vložte do zadání i negativní cíle – tedy to, co systém dělat nemusí, nemá či je to přímo nežádoucí. Zabráníte tak nechtěným customizacím nebo rozšiřování rozsahu ze strany potenciálních dodavatelů.

Uživatelé, role a růst: dopady na licencování i výkon

Mnoho z cloudových či krabicových řešení má svůj cenový model postaven na počtech licencí (rozumějte uživatelů v systému). Dodavatelé potřebují vědět, kolik uživatelů bude v systému aktivních, jaké budou mít role (student, lektor, administrátor, manažer, auditor) a jak očekáváte, že se budou počty uživatelů vyvíjet v horizontu 12–24 měsíců. Nejde pak pouze o počty uživatelů (a od toho počty licencí), ale také o zatížení serveru a tedy nákladech za  jeho výkon. Pokud tak předpokládáte sezónní špičky – například u povinných či produktových školení – uveďte to i v rámci zadávací dokumentace, aby dodavatel dokázal zahrnout i reálné náklady na provoz infrastruktury.

Příklad z praxe: Retailový řetězec plánoval start povinných BOZP školení pro 7 000 zaměstnanců během dvou týdnů. Díky tomu, že špičku jasně popsal již v rámci zadávací dokumentace, dodavatel navrhl dočasné navýšení výkonu a vyhnulo se výpadkům i frontám v systému. Následně už byl provoz na serverech mírnější a tak i náklady na provoz mohli byt dopředu jasně definovány.

Obsah a standardy: myslete i na analytiku

Popište, jaký obsah budete v LMS provozovat: zda půjde o kurzy ve standardech SCORM 1.2/2004, xAPI/cmi5, případně o videa, PDF či webináře. Uveďte, jaké autorské nástroje používáte a jak bude vypadat publikační workflow. Pokud plánujete podrobnější analytiku (např. sledování vzdělávacích aktivit i mimo LMS), zvažte požadavek na LRS (Learning Record Store). 

Tip: Zamyslete se nad tím, zda vyžadujete exportní a importní nástroje, vzorové migrace a přehled datových polí. Pokud ano, nezapomeňte tuto informaci zmínit v rámci Zadání, abyste předešli ručnímu „překlápění“ dat či vendor-locku v budoucnu.

Funkční požadavky: scénáře jsou cennější než seznamy

Namísto dlouhých tabulek „ano/ne“ doporučujeme popsat několik reprezentativních scénářů, které vystihují Vaše reálné potřeby. Například: „Nový zaměstnanec v pobočce Brno je automaticky zařazen do onboardingové cesty podle pracovní pozice a jazyka; jeho manažer dostává týdenní přehled plnění, HR pak měsíční agregovaný report.“ Teprve na tyto scénáře navážete strukturou funkcí (testy, certifikáty, learning paths, doporučování obsahu, gamifikace, notifikace, katalog kurzů, knihovna, dovednosti a kompetence, dashboardy, obsah reportů). Na příkladech popište  jací uživatelé a jak budou se systémem pracovat. Dodavatel tak lépe pochopí proces, priority i plánované používání systému a může navrhnout relevantní konfiguraci.

Příklad z praxe: Ve službách sdílených center stačilo vydefinovat tři dobře popsané scénáře, aby jeden z původních favoritů vypadl – neuměl splnit pravidelný a přehledný reporting studia manažerům bez dodatečného vývoje.

Integrace: popište datové toky a odpovědnosti

Integrace by neměla být pouze výčtem logotypů. Uveďte, které systémy používáte (HRIS/ERP, Microsoft 365 či Google Workspace, nástroj pro webináře,...) a jaký systém bude „zdrojem pravdy“ pro uživatelská data (bude to Vaše CRM nebo budoucí LMS?), jasně popište organizační strukturu, role a oprávnění v systému. Popsané datové procesy – kdo zakládá uživatele, kdo spravuje a přiřazuje role, kdo plánuje webinář a kam se ukládají výsledky – zabrání nedorozuměním v implementaci. 

Bezpečnost a compliance: definujte minimum bez kompromisů

Bezpečnostní požadavky formulujte konkrétně: jaké certifikace požadujete (např. ISO 27001), jak bude řešeno šifrování dat „v klidu“ i „při přenosu“, jak dlouho se mají uchovávat auditní záznamy a jak bude vypadat smluvní úprava zpracování osobních údajů. U mezinárodních projektů uveďte, kde mají být data uložena (např. v EU). Jasně stanovené minimum výrazně zrychlí právní a bezpečnostní posouzení po výběru dodavatele.

Příklad z praxe: Ve finančních službách zdržovalo výběrové řízení na dodavatele LMS několikatýdenní kolečko nad požadavky na auditní logy. Součástí zadání bylo "logování záznamů pro případ budoucí potřeby", nebylo ale jasně definováno co se má logovat, proč, jakou formou, kde ani jak dlouho. 

Přístupnost a lokalizace

Přístupnost není doplněk, ale nutnost. Uveďte, že uživatelské rozhraní musí splňovat WCAG 2.2. Specifikujte jazykové mutace a požadavky na lokalizaci, či branding systému – budete chtít vlastní barvy, logo či typografii? Jak často se bude vzhled systému měnit? Půjde to vůbec? Takové informace pomáhají včas odhadnout rozsah prací a předejít pozdějším „rychlým“ zásahům.

Tip: Požádejte dodavatele, aby v demu/ukázce předvedl i práci se systémem. Mnohé nedostatky se projeví okamžitě.

Provozní model a SLA: cloud vs. on-premise a očekávání podpory

Rozhodnutí mezi cloudem a on-premise vyplývá z bezpečnostních, integračních a provozních požadavků. Cloud obvykle vítězí rychlostí nasazení a nižší zátěží na interní IT, on-premise má své místo tam, kde je vyžadována silná izolace a detailní kontrola prostředí. V zadání definujte očekávanou dostupnost, reakční a opravné doby podpory, plán zálohování a testy obnovy. Jasně formulované SLA je nejlepší prevence zklamání.

Migrace a implementace: plánujte realisticky a po krocích

Migrace stávajících dat je často nejnáročnější část projektu. Má nové řešení umožňovat migraci stávacích/archivních dat? V jakém rozsahu? Kde ji máte uloženou? V jakém formátu dokážete historická data dodat? Popište rozsah a zdroje dat (uživatelé, výsledky, certifikáty, kurzy), pravidla mapování a očekávané čištění dat.
U implementace vymezte role na obou stranách, plán školení administrátorů a lektorů a akceptační postup. Včas si vyžádejte testovací prostředí, aby bylo možné scénáře ověřovat průběžně.

Příklad z praxe: Organizace s historickým LMS převedla do nového systému pouze probíhající certifikace a povinné záznamy, zatímco archivní data ponechala ve starém za LMS, které se uzamklo běžným uživatelům. Dodávka LMS se zlevnila a implementace řešení se zkrátila téměř o měsíc měsíc.

Hodnoticí kritéria a matice: jak srovnat nabídky férově

Aby šly nabídky dodavatelů srovnávat, sjednoťte kritéria a jejich váhy. V praxi se osvědčuje dát největší váhu funkčním požadavkům a integracím, samostatně posuzovat přístupnost a bezpečnost a transparentně vyhodnotit celkové náklady v horizontu 12–36 měsíců. Myslete také na reference – zkušenost dodavatele v podobných prostředích je často klíčová pro hladký průběh implementace.

Tip: V rámci zadání požádejte uchazeče o tabulkový přehled splnění vašich požadavků s možnostmi nabízeného LMS (splněno / částečně / nesplněno + komentář) - v případě "krabicových řešení" o řízenou ukázku podle Vašich scénářů. Získáte tak objektivnější podklad pro bodové hodnocení.

Cenové modely a náklady na vlastnictví: dívejte se za horizont prvního roku

Cena LMS není jen o počtu uživatelů. Rozlišujte, zda se licencování odvíjí od celkových, nebo aktivních uživatelů, a jak je „aktivita“ definována (měsíční, kvartální). Uveďte, které moduly považujete za povinné a které mohou být volitelné. U implementace a úprav si nechte jasně popsat, co jsou fixní položky a co jsou očekávané položky, které mohou v rámci implementace či následného provozu ještě narůst. Náklady posuzujte v delším období, protože do nákladů vstupují i integrace, průběžné úpravy, školení a rozvoj.

Nejčastější chyby a jak se jim vyhnout

Mezi nejběžnější chyby patří chybějící měřitelné cíle, nejasné rozdělení „must-have“ a „nice-to-have“ požadavků, podceněné integrace a migrace. Rizikem je také soustředění se na pořizovací cenu bez pohledu na následné provozní náklady. Na většinu těchto problémů stačí myslet již v rámci tvorby zadání a promítnout je do hodnotících kritérií či servisních smluv.