Vendor lock-in u LMS: jak se mu vyhnout už při výběru

Když firma vybírá LMS, většinou se soustředí hlavně na to, co systém umí dnes. Jak vypadá katalog kurzů, jak fungují testy, jaké jsou reporty, jestli se dá napojit na firemní systémy. Mnohem méně pozornosti se věnuje tomu, co se stane později, pokud bude potřeba systém rozšířit, změnit dodavatele nebo se z nějakého důvodu přesunout jinam. A právě tady začíná téma vendor lock-inu.

Vendor lock-in neznamená nutně, že jste „uvězněni“ v systému, ze kterého není úniku. Častěji jde o  situaci, kdy technicky odejít můžete, ale je to tak složité, drahé nebo nepříjemné, že raději zůstáváte. Systém sice funguje, ale každý větší rozvoj stojí víc, než jste čekali. Export dat je omezený. Integrace jsou závislé na jednom partnerovi. Obsah je uložený v podobě, která se špatně přenáší jinam. A změna dodavatele by znamenala téměř novou implementaci od začátku.

Dobrá zpráva je, že většině těchto problémů se dá předejít už při výběru. Ne až při odchodu, ale právě na začátku, kdy ještě máte prostor si podmínky nastavit.

Co vlastně vendor lock-in znamená v praxi

V běžné řeči se tím myslí situace, kdy je zákazník příliš závislý na jednom dodavateli, jednom systému nebo jednom způsobu provozu. U LMS to může mít několik podob.

Někdy je problém v datech. Výsledky studia, certifikáty, historie průchodů, uživatelé nebo metadata kurzů sice v systému jsou, ale dostat je ven v rozumné a použitelné podobě je složité. Jindy je problém v obsahu. Kurzy jsou vytvořené způsobem, který funguje dobře jen v jednom konkrétním prostředí a při přesunu jinam se musí složitě upravovat. A velmi častý je lock-in i v samotném dodavatelském modelu: vše důležité zná jen jeden partner, integrace spravuje pouze on a každá změna vede zpátky k němu.

Na papíře tak firma systém vlastní nebo si ho alespoň předplácí, ale v reálu má jen omezenou kontrolu nad tím, co s ním může dělat.

Proč je lock-in u LMS tak častý

LMS není jen jedna aplikace. Obvykle je to kombinace uživatelských účtů, rolí, katalogu, obsahových standardů, reportů, notifikací, napojení na identity, HR systémy a někdy i na platební nebo obchodní procesy. Čím déle LMS používáte, tím víc se propojí s interním fungováním firmy. A právě tím roste i citlivost na změnu.

Dodavatelé navíc často přirozeně staví řešení tak, aby fungovalo co nejlépe právě v jejich vlastním ekosystému. To samo o sobě není nic špatného. Problém nastává tehdy, když se tato výhoda časem změní ve skrytou závislost. Typicky ve chvíli, kdy zjistíte, že export je jen částečný, API má omezení, dokumentace je nedostatečná nebo že historická data nejdou převést bez drahé zakázky navíc.

První obrana: ptejte se na odchod už při vstupu

Možná to zní zvláštně, ale jeden z nejlepších způsobů, jak si ověřit kvalitu LMS dodavatele, je zeptat se ho hned na začátku, jak by vypadal odchod. Kvalitní partner se takové otázky nebojí. Chápe, že zákazník chce vědět, jak budou vypadat exporty dat, jaká je podoba reverzní migrace a co se stane s obsahem a historií, pokud jednou spolupráce skončí.

Naopak pokud dodavatel reaguje podrážděně, odpovědi jsou nejasné nebo se vše odkládá na „pozdější řešení“, je to důležitý signál. Ne proto, že byste snad plánovali odchod, ale proto, že právě tady se ukazuje, jak otevřeně a férově je systém postavený.

Data musí být Vaše, ne jen „někde v systému“

Jedním z nejdůležitějších témat je, jak pracovat s daty. Nemělo by vám od dodavatele stačit, že „export samozřejmě máme“. Důležité je, co přesně export obsahuje, v jakém formátu, jak často jej lze udělat a zda je opravdu použitelný.

Mělo by být jasné, zda si můžete vyexportovat uživatele, skupiny, role, výsledky, certifikáty, historii studia, metadata kurzů i obsah reportů. Stejně důležité je vědět, zda k exportům dostanete i popis struktury dat, aby s nimi šlo rozumně pracovat v jiném systému.

Pokud dodavatel nabízí export jen ve formě několika základních CSV souborů bez návazností, není to totéž jako otevřený a dobře přenositelný datový model. U LMS je to podobné jako u účetnictví: nejde jen o to „něco vytáhnout“, ale dostat data ven v takové podobě, aby dávala smysl i mimo původní systém.

Pozor na přenos vzdělávacího obsahu

Lock-in se velmi často schovává v obsahu. Firma má pocit, že vlastní své kurzy, ale až při změně systému zjistí, že to není tak jednoduché. Obsah bývá rozdělený na dvě části: na soubory, které lze přenést relativně snadno, a na vše, co je navázáno na konkrétní šablony, pluginy nebo specifický editor.

Proto má smysl už při výběru řešit, v jakých formátech bude obsah vznikat a jak přenositelný do budoucna bude. Pokud používáte standardy jako SCORM nebo xAPI, situace bývá snazší. Pokud se ale velká část obsahu tvoří přímo „nativně“ v konkrétním LMS, vyplatí se dopředu vědět, co z toho půjde vyexportovat a jak složité bude to znovu použít jinde.

Nejde o to nativní obsah apriori odmítat. Spíš o to mít jasno, jaká je cena pohodlí dnes a jaká může být cena přenosu zítra.

Otevřené API je dobrý signál, ale ne samospásné řešení

Mnoho dodavatelů dnes správně říká, že mají API. To je určitě plus, ale samo o sobě to ještě neznamená, že se lock-inu vyhnete. Důležité je, jak dobře je API zdokumentované, co skutečně umí a zda k němu má zákazník nebo jeho partner rozumný přístup.

Některá API jsou otevřená jen částečně. Některá mají výrazná omezení, která se projeví až v provozu. A někdy je sice API technicky dostupné, ale prakticky použitelné jen pro původního implementačního partnera, protože nikdo jiný nezná kontext a logiku propojení.

Integrace by neměly být černou skříňkou

Dalším častým zdrojem závislosti jsou integrace. Na začátku vše vypadá dobře: systém je napojený na SSO, HR nebo CRM, data tečou a projekt se zdá hotový. Jenže o rok později přijde změna v organizační struktuře, nový export nebo potřeba přidat další roli – a ukáže se, že celé řešení drží pohromadě hlavně proto, že jeden konkrétní dodavatel ví, jak bylo postavené.

Kvalitní LMS partner by měl být schopen dodat přehlednou dokumentaci datových toků, popsat logiku integrací a zajistit, aby nebyly závislé jen na znalostech (a paměti) jednoho člověka ve firmě. Právě v této oblasti se lock-in často nepozná při výběru, ale až při první větší změně.

Smlouva je stejně důležitá jako technika

Lock-in není jen technický problém. Často je to problém smluvní. Pokud ve smlouvě nemáte jasně popsané exporty dat, součinnost při ukončení spolupráce, SLA, vlastnictví obsahu a podmínky reverzní migrace, může být Váš vyjednávací prostor později velmi malý.

Dobře nastavená smlouva by měla říkat, že data i obsah zůstávají Vaše, že při ukončení spolupráce dostanete export v dohodnuté podobě a že dodavatel poskytne přiměřenou součinnost při přechodu jinam. 

Je překvapivé, kolik firem věnuje velkou pozornost ceně licencí, ale exportům, ukončení spolupráce nebo popisu datových struktur věnují jen minimum energie. Přitom právě tam se v budoucnu "láme chleba".

Open-source není automatická záruka svobody

Někdy se říká, že open-source řešení lock-in řeší samo od sebe. To ale není úplně pravda. Open-source sice často snižuje závislost na jednom výrobci a bývá otevřenější z hlediska kódu i dat, ale lock-in se může přesunout jinam – třeba k jednomu implementačnímu partnerovi, který jako jediný zná konkrétní úpravy, integrace a provozní logiku.

Stejně jako u komerčního LMS tedy i tady záleží na dokumentaci, kvalitě architektury, otevřenosti dat a tom, zda lze systém rozvíjet nebo převzít i s jiným partnerem.

Jak si lock-in prověřit ještě před podpisem

Nejlepší je udělat si z toho normální součást výběru. Ptejte se například:

• Jak vypadá kompletní export dat a obsahu?
• Jaké formáty exportu podporujete?
• Co dostaneme při ukončení spolupráce?
• Může s API pracovat i jiný dodavatel?
• Máme k dispozici dokumentaci integrací a datových struktur?
• Je možné převzít správu systému jiným partnerem?
• Co zůstává přenositelné a co je navázané na Vaše vlastní moduly nebo editor?

Tyto otázky nejsou projevem nedůvěry. Jsou znakem toho, že přemýšlíte zodpovědně.

Vendor lock-in u LMS není něco, co se objeví až po letech. Ve skutečnosti se často „rodí“ už při výběru systému a nastavování prvních smluvních a technických pravidel. Čím dřív si ohlídáte exporty, otevřenost API, přenositelnost obsahu, dokumentaci integrací a smluvní součinnost při případném odchodu, tím větší svobodu si necháte do budoucna.

Nejde o to vybírat systém s představou, že z něj budete za dva roky utíkat. Jde o to vybrat si takové řešení a takového partnera, u kterých budete vědět, že zůstáváte proto, že chcete, ne proto, že nemáte jinou rozumnou možnost.