Tak, da się. System LMS można zbudować na gotowym otwartym rdzeniu i dołożyć do niego tylko to, czego brakuje Twojej organizacji. Systemy o otwartym kodzie są projektowane pod rozszerzanie, nie pod przepisywanie od nowa, a sam Moodle udostępnia 58 typów wtyczek i nazywa je najlepiej utrzymywalną drogą dodawania nowych funkcji.

Pytanie nie brzmi więc, czy da się. Brzmi, gdzie przebiega granica. Gotowa platforma w subskrypcji kończy się tam, gdzie kończy się jej konfiguracja. Budowa całego systemu od zera to większy budżet, dłuższy czas i większe ryzyko projektu. Między tymi skrajnościami są dwie różne drogi pośrednie, nie jedna, i właśnie ich pomieszanie jest najczęstszym błędem na tym etapie decyzji. Poniżej znajdziesz cztery warianty budowy, granicę między bezpiecznym rozszerzeniem a długiem technologicznym, składniki kosztu w horyzoncie trzech lat i siedem reguł, po których poznasz, który wariant jest Twój.

5 kluczowych wniosków
  • Gotowy rdzeń LMS pozwala uniknąć budowy całego systemu od zera.

  • Funkcje custom najlepiej dodawać przez wtyczki lub API.

  • Open source eliminuje licencję, ale nie koszty utrzymania.

  • Model hybrydowy sprawdza się, gdy rdzeń spełnia większość wymagań.

  • Wybór rozwiązania zależy od potrzeb firmy i jej kompetencji technicznych.

Co to jest system LMS i czym różni się od platformy szkoleniowej?

System LMS to oprogramowanie do tworzenia, organizowania, dostarczania i rozliczania szkoleń oraz materiałów edukacyjnych dla wskazanej grupy odbiorców, wraz z rejestrowaniem postępów i wyników. Po polsku funkcjonuje jako system zarządzania nauczaniem. W kontekście firmowym ten sam typ narzędzia opisuje się jako system zarządzania szkoleniami, bo w organizacji liczy się nie tyle nauczanie, ile udokumentowany efekt.

Platformy LMS działają jako jeden punkt dostępu dla prowadzących i uczestników. Pracownik ma jedno miejsce, w którym widzi przypisane kursy online, zestaw materiałów szkoleniowych i terminy. Administrator ma jedno miejsce, w którym widzi, kto ukończył, kto nie ukończył i czyj certyfikat wygasa. To samo oprogramowanie LMS obsługuje na całym świecie instytucje edukacyjne, w tym szkoły i uczelnie wyższe, a także agencje rządowe i firmy, tylko z inną logiką w środku.

Czym learning management system różni się od LCMS, LXP i narzędzi klasowych?

LMS dostarcza i rozlicza szkolenia. LCMS służy przede wszystkim do tworzenia i wersjonowania treści. LXP stawia na odkrywanie materiałów przez samego pracownika i na jego własne doświadczenia edukacyjne, bez sztywnej ścieżki. Narzędzia klasowe w rodzaju Google Classroom oraz współdzielony dysk Google obsługują pracę z grupą, ale nie obsługują ról, ważności certyfikatów, audytowalności ani raportowania dla organizacji.

W firmie zatrudniającej ponad pięćset osób ta różnica przestaje być akademicka. Bez ról nie przypiszesz szkolenia obowiązkowego do stanowiska. Bez daty ważności certyfikatu nie odtworzysz przed audytem stanu z konkretnego dnia. Kursów edukacyjnych rozliczanych ocenami nikt w firmie nie potrzebuje. Potrzebuje dowodu, że dana osoba ma aktualne uprawnienie. Platformy edukacyjne i platformy szkoleniowe stają się w takiej organizacji dwoma różnymi produktami, bo pierwsze mierzą naukę, a drugie mierzą gotowość ludzi do pracy.

Jest jeszcze jedna rzecz, która zaskakuje na pierwszym spotkaniu z dostawcą. Najpopularniejsze otwarte rdzenie powstały na uczelniach. Widać to w ich domyślnych pojęciach, zbudowanych wokół ocen i semestrów, gdzie raporty pokazują postępy uczniów oraz wyniki uczniów, a nie gotowość pracownika do zadania. Canvas LMS obejmuje około połowy rynku uczelnianego w Stanach Zjednoczonych i Kanadzie, a Moodle około jednej dziesiątej, przy czym te udziały dotyczą szkolnictwa wyższego, nie firm. Dla Twojej organizacji oznacza to jedno, część pojęć w takim systemie trzeba przetłumaczyć na język stanowisk, ról i szkoleń obowiązkowych, i to jest pierwsza porcja pracy, której nie uniknie nikt.

Jakich funkcji lms nie musisz pisać od zera, jeśli startujesz z gotowego rdzenia?

Dojrzały rdzeń systemu LMS ma już zarządzanie użytkownikami i rolami, tworzenie kursów, testy i ocenianie, śledzenie postępów w czasie rzeczywistym, raportowanie, automatyczne powiadomienia, komunikację i dostęp z dowolnego urządzenia. Tego nie pisze się od nowa, a lista wymagań, którą dział HR przynosi na pierwsze spotkanie, w większości pokrywa się właśnie z tym zestawem. Kluczowe cechy takiego rdzenia są policzalne, a nie deklaratywne. Zanim ktokolwiek zacznie liczyć, ile kosztuje dedykowany system LMS, warto zobaczyć, jak długa jest ta lista.

Oto co dostajesz standardowo, bez ani jednej linii nowego kodu.

  • Zarządzanie użytkownikami i rolami, czyli struktura firmy odwzorowana w systemie zamiast ręcznego przypisywania każdej osoby do każdego kursu.
  • Tworzenie kursów online z materiałów, które już masz, czyli prezentacje, pliki PDF i nagrania wideo.
  • Testy i ocenianie z progiem zaliczenia oraz limitem prób.
  • Śledzenie postępów w czasie rzeczywistym, czyli odpowiedź na pytanie, kto jest w połowie, a kto nie zaczął.
  • Raportowanie i dostarczanie gotowych zestawień dla zarządu oraz dla audytu.
  • Automatyczne powiadomienia, które przypominają o terminie zamiast Ciebie.
  • Fora dyskusyjne i czaty, czyli rozmowa o szkoleniu w tym samym miejscu, w którym leży treść.
  • Dostęp w dowolnym miejscu i w dowolnym czasie, na dowolnym urządzeniu, z materiałami dostępnymi także w trybie offline, gdy połączenie internetowe jest słabe.
  • Certyfikaty z datą ważności, czyli fundament compliance szkoleniowego.
  • Elementy gamifikacji, czyli punkty, odznaki i rankingi podnoszące ukończenia.
  • Narzędzia do nauki online dla nowych pracowników, czyli gotowe ścieżki wdrożenia zamiast serii pojedynczych spotkań.
  • Rozszerzone szkolenia dla wybranych ról, czyli ścieżki dodatkowe ponad program obowiązkowy.

To brzmi banalnie, ale ta lista rozstrzyga większość rozmów o budżecie. Skala tego, co da się dołożyć bez ingerencji w system, jest większa, niż widać z zewnątrz. Moodle udostępnia 58 typów wtyczek, czyli 58 rodzajów miejsc, w których wolno go rozszerzać. Katalog publicznie dostępnych wtyczek przekroczył dwa tysiące pozycji już w 2022 roku, przy ponad tysiącu stu współtwórcach. Sama liczba jest mniej istotna niż to, co z niej wynika, bo typowe potrzeby działu szkoleń ktoś już rozwiązał i opublikował.

Zaawansowane funkcje nie są tu wyjątkiem. Zarejestrowanych instalacji tego jednego systemu jest ponad sto czterdzieści pięć tysięcy, a rejestracja jest dobrowolna, więc realna liczba jest wyższa. Taki rdzeń zmniejsza obciążenia administracyjne działu HR od pierwszego dnia, bo zapisy, powiadomienia i raporty powstają bez udziału człowieka. Oszczędność czasu bierze się właśnie stąd, bo projekt zaczyna się od działającego systemu, a nie od pustego repozytorium.

Jakie masz warianty budowy systemu LMS i który z nich jest naprawdę trzecią drogą?

Warianty są cztery, nie trzy. Gotowy system w subskrypcji, otwarty rdzeń rozszerzany wtyczkami, gotowy produkt dostawcy rozwijany na zamówienie w modelu white label oraz budowa od zera. Dwa środkowe to dwie różne trzecie drogi. Inaczej rozkładają odpowiedzialność za aktualizacje i za bezpieczeństwo instancji. A to właśnie ta odpowiedzialność decyduje o koszcie w drugim i trzecim roku.

Rynek opisuje ten wybór dwiema parami przeciwieństw. Darmowe kontra komercyjne oraz chmura kontra serwer własny, jakby typ LMS sprowadzał się do ceny i do miejsca instalacji. Żadna z tych par nie odpowiada na pytanie, które zadaje dyrektor HR. W wyborze LMS liczy się jedno, ile z listy wymagań mieści się w czymś, co już istnieje, i kto zajmie się resztą. Odpowiedź zależy od skali organizacji, od jej potrzeb biznesowych i od tego, czy w firmie jest zespół techniczny.

Kiedy wystarczy gotowy system w modelu subskrypcyjnym?

Gotowy system w subskrypcji wystarcza wtedy, gdy Twoje procesy szkoleniowe da się opisać jako konfiguracja pojęć, które system już zna. Role, ścieżki, certyfikaty, powiadomienia, raporty. Dostawca LMS bierze na siebie hosting, aktualizacje i bezpieczeństwo, a Ty płacisz subskrypcję i konfigurujesz to, co udostępnia panel administratora.

W architekturze w pełni współdzielonej koszt jednostkowy jest najniższy w całym zestawieniu, bo tę samą instancję obsługuje wielu klientów. Cena tej oszczędności to ograniczony zakres konfiguracji. Granica konfiguracji jest w takim systemie sztywna i właśnie tu zaczynają się typowe wady gotowych systemów LMS, czyli sytuacje, w których firma dostosowuje proces do narzędzia, a nie odwrotnie.

Co daje otwarty rdzeń rozszerzany wtyczkami?

LMS oparty na otwartym rdzeniu daje prawo do modyfikacji kodu, brak opłaty licencyjnej za sam system i architekturę zaprojektowaną pod rozszerzanie. Przenosi jednocześnie na Twoją organizację albo na jej partnera technicznego odpowiedzialność za hosting, aktualizacje, kopie zapasowe, bezpieczeństwo danych oraz przechowywanie danych pracowników.

I tu robi się ciekawie, bo licencja nie jest detalem prawnym, tylko warunkiem biznesowym. Moodle jest wydawany na licencji GNU GPL. Canvas LMS oraz rdzeń Open edX na AGPLv3, a Chamilo na GPLv3 i późniejszych. Przy GPL własne modyfikacje utrzymywane wewnątrz firmy nie muszą być publikowane. Przy AGPL samo udostępnienie zmodyfikowanej wersji użytkownikom przez sieć rodzi obowiązek zaoferowania im kodu źródłowego tej wersji.

Praca z systemem opartym na otwartym kodzie ma jeszcze jedno zastrzeżenie. Otwarty projekt nie oznacza, że wszystko w nim jest otwarte. Moodle Workplace, czyli wariant przygotowany pod organizacje, nie jest open source i jest dostępny wyłącznie przez certyfikowanych partnerów. Rdzenie różnią się między sobą licencją, cyklem wydań i tym, jak głęboko wolno je rozszerzać, co widać w porównaniu platform szkoleniowych dostępnych dziś na rynku.

Czym jest system w modelu white label rozwijany na zamówienie?

W modelu white label Twoja organizacja dostaje działający produkt dostawcy pod własną marką. Dopasowania do jej procesów powstają jako warstwa na tym produkcie. Aktualizacje i bezpieczeństwo rdzenia zostają po stronie dostawcy, a Ty rozwijasz to, co wyróżnia Twoją firmę, bez utrzymywania całej podstawy systemu.

Architektonicznie odpowiada temu instancja dedykowana albo pionowo podzielone środowisko, w którym klienci standardowi korzystają ze wspólnego rdzenia, a wybrani mają osobną instancję. Taki układ daje pełną konfigurowalność i izolację danych. Jego koszt rośnie razem z liczbą instancji. Przykładem takiego układu jest Mentingo, system LMS w modelu white label, który jednocześnie da się dowolnie customizować, bo jest produktem należącym do software house'u. Do działającego rdzenia można w nim dodać dokładnie to, czego potrzebuje konkretna organizacja.

Rdzeń rozwija się tu razem z nową technologią po stronie dostawcy. Ten wariant przenosi natomiast dwie rzeczy do umowy, nie do kodu. Pierwsza to własność warstwy własnej, czyli kto ma prawa do tego, co powstało na Twoje zlecenie. Druga to warunki wyjścia, czyli co dostajesz, gdy współpraca się kończy. Kiedy warstwa własna jest osobną aplikacją rozmawiającą z rdzeniem przez API, powstaje w nowoczesnej technologii frontendowej, a tworzenie aplikacji w React jest tu jednym z częstszych wyborów.

Kiedy budowa od zera jest jedyną sensowną opcją?

Budowa od zera broni się w dwóch sytuacjach. Pierwsza to wymagania, których nie spełnia żaden dostępny rdzeń. Druga to sytuacja, w której sam system jest przewagą konkurencyjną firmy, a nie narzędziem wewnętrznym. Skala organizacji nie jest tym warunkiem, bo tysiąc kont obsługuje spokojnie każdy dojrzały rdzeń.

Cena tej drogi jest policzona. Duże projekty informatyczne przekraczają budżet średnio o 45 procent i dowożą o 56 procent mniej wartości, niż zakładano. Każdy dodatkowy rok trwania projektu podnosi przekroczenie kosztów o kolejne 15 procent. Dopiero po odrzuceniu trzech pozostałych wariantów dedykowane oprogramowanie na zamówienie przestaje być najdroższą drogą do tego samego celu i staje się jedyną drogą do celu, którego inaczej nie osiągniesz.

KryteriumGotowy system w subskrypcjiOtwarty rdzeń plus wtyczkiProdukt dostawcy rozwijany na zamówienieBudowa od zera
Zakres dopasowaniakonfiguracja w granicach ustawieńrozszerzenia w przewidzianych punktach, w jednym z rdzeni 58 typów wtyczekprocesy, raporty, integracje i interfejs w granicach architektury produktudowolny
Kto aktualizuje systemdostawcaTwoja organizacja albo jej partner, duże wydania co pół rokudostawca produktuTwoja organizacja
Kto odpowiada za bezpieczeństwo instancjidostawcaTwoja organizacja albo partnerdostawcaTwoja organizacja
Własność warstwy własnejbrakTwoja organizacja, przy GPL bez obowiązku publikacjizależna od umowyTwoja organizacja
Ryzyko przy aktualizacjibrak po Twojej stronieniskie dla wtyczek, wysokie dla zmian w kodzie bazowympo stronie dostawcypo Twojej stronie
Czas do pierwszej działającej wersjinajkrótszyśrednikrótki, rdzeń działa od pierwszego dnianajdłuższy
Ryzyko projektowenajniżsześrednieniskie do średniegonajwyższe
Główne ryzyko strategiczneuwiązanie do dostawcy i jego modelu cenowegobrak kompetencji utrzymaniowych w organizacjizależność od jednego partnera, do zaadresowania umowąkoszt utrzymania własnego produktu przez lata

Co da się dopasować bez ruszania kodu bazowego, a co wymaga jego zmiany?

Wtyczka rozszerza system w miejscach przewidzianych przez jego twórców i przechodzi aktualizacje bez konfliktów. Zmiana samego kodu bazowego wymaga ręcznego scalania przy każdym nowym wydaniu. Pierwsze jest kosztem jednorazowym, drugie kosztem powtarzalnym, i to jest cała różnica, którą trzeba rozumieć przed podpisaniem czegokolwiek.

Elastyczność systemu nie jest jedną wartością, bo dopasowanie ma cztery poziomy, ułożone od najtańszego do najdroższego. Konfiguracja, czyli ustawienia dostępne administratorowi. Wtyczka, czyli nowy typ aktywności, raportu, uwierzytelniania albo integracji, wpięty w przewidziane miejsce. Warstwa własna, czyli osobna aplikacja korzystająca z rdzenia przez API. Zmiana kodu bazowego, czyli ingerencja w sam system. Dokumentacja rdzenia nazywa wtyczkę najłatwiejszą i najlepiej utrzymywalną drogą dodawania funkcji, a instrukcja aktualizacji wprost ostrzega przed nadpisywaniem kodu nowej wersji plikami ze starej.

Infografika przedstawiająca cztery poziomy ingerencji w LMS: konfigurację, wtyczkę, warstwę własną i modyfikację kodu bazowego.
Cztery poziomy dostosowania LMS – od ustawień administracyjnych po modyfikację kodu bazowego.

Najczęstszy błąd? Zmiana w kodzie bazowym tam, gdzie wystarczyłaby wtyczka. Dlatego każde wymaganie z listy przechodzi przez pięć pytań w tej kolejności.

  1. Czy da się to ustawić w panelu administratora bez udziału programisty? Jeśli tak, to koniec rozmowy.
  2. Czy istnieje już publiczna wtyczka, która to robi, i czy jest utrzymywana pod aktualną wersję rdzenia?
  3. Czy da się to napisać jako własną wtyczkę w jednym z przewidzianych typów rozszerzeń?
  4. Czy da się to wynieść poza rdzeń, do osobnej aplikacji korzystającej z API, żeby rdzeń pozostał nietknięty?
  5. Czy naprawdę trzeba zmienić kod bazowy, a jeśli tak, kto i za ile będzie scalał tę zmianę przy każdym wydaniu przez najbliższe trzy lata?

Realne potrzeby szkoleniowe najczęściej nie dotyczą logiki systemu, tylko tego, co widzi pracownik. Zaprojektowanie interfejsu aplikacji pod realne ścieżki w firmie daje szybciej odczuwalny efekt niż przebudowa rdzenia, bo pracownik nie ocenia architektury, tylko liczbę kliknięć do swojego kursu.

Są też wymagania, których rdzeń nie spełni. Trzeba to wiedzieć przed wyborem, nie po. Moodle obsługuje standard SCORM w wersji 1.2 i przechodzi pełny zestaw testów zgodności dla tej wersji. Nie obsługuje SCORM 2004, prace nad tym wsparciem zostały zatrzymane, a zgłoszenia zamykane bez realizacji. Jeśli Twoja biblioteka treści stoi na SCORM 2004, ten jeden fakt przestawia całą decyzję o wyborze rdzenia.

Osobna rzecz dotyczy danych osobowych. Wtyczki w dojrzałym rdzeniu mają obowiązek raportować, jakie dane osobowe przechowują, oraz obsługiwać ich eksport i usunięcie. Rozszerzenie napisane zgodnie ze standardem projektu nie zmienia zakresu zgodności Twojej organizacji z przepisami o ochronie danych, a rozszerzenie napisane obok standardu zmienia go po cichu.

Co się dzieje z Twoimi dopasowaniami przy aktualizacji systemu?

Zespół analizuje działanie systemu przy szafie serwerowej po zakończeniu wdrożenia.
Utrzymanie i rozwój wdrożonego systemu wymagają jasno określonego właściciela.

Duże wydania dojrzałego rdzenia wychodzą regularnie, w Moodle co pół roku, w kwietniu i październiku. Wydania punktowe co około dwa miesiące. Wersje z długim wsparciem dostają dwanaście miesięcy poprawek błędów i trzydzieści sześć miesięcy poprawek bezpieczeństwa, więc utrzymanie systemu jest cyklem, nie jednorazowym zadaniem.

Ten kalendarz da się przeliczyć na własny plan. Wersja 4.5 z długim wsparciem wyszła w październiku 2024 i dostaje poprawki bezpieczeństwa do października 2027. Kolejna wersja z długim wsparciem, oznaczona 5.3, wychodzi w październiku 2026 i ma wsparcie bezpieczeństwa do października 2029. Horyzont planowania odczytujesz więc z kalendarza wydań, a nie z obietnicy handlowca.

Alternatywny rdzeń działa w podobnym rytmie. Open edX wydaje nazwane wersje co pół roku, a każda ma wsparcie przez około osiemnaście miesięcy. Krótszy okres wsparcia oznacza po prostu częstsze okna aktualizacyjne w Twoim rocznym planie pracy.

Poprawki bezpieczeństwa mają własną mechanikę i to ona decyduje o obsadzie. Szczegóły luki trafiają do zarejestrowanych administratorów razem z wydaniem. Publiczne ujawnienie następuje tydzień później, żeby administratorzy mieli czas zaktualizować systemy. Ktoś musi w tym oknie zadziałać. Dlatego przy samodzielnie utrzymywanym rdzeniu organizacje domykają ten obszar własnym zespołem infrastruktury albo kupują usługi DevOps i konsultingu IT.

Jak wpiąć system LMS w HRIS, SSO i standardy treści szkoleniowych?

Wpięcie systemu w środowisko HR opiera się na trzech grupach standardów. Logowanie obsługują SAML 2.0 oraz OpenID Connect. Automatyczne zakładanie i wyłączanie kont obsługuje SCIM 2.0, a treści szkoleniowe i wyniki przenoszą SCORM, xAPI oraz cmi5. Wszystkie trzy grupy są otwartymi standardami, więc żaden dostawca nie jest ich właścicielem i żaden nie uzależni od siebie Twojego wyjścia.

Najbardziej praktyczny z nich jest ten najmniej znany działom HR. Standard SCIM w wersji 2.0, opisany w dwóch publicznych dokumentach specyfikacji, ma gotowe rozszerzenie dla użytkownika korporacyjnego. Przenosi ono z systemu kadrowego dokładnie te pola, których potrzebuje dział szkoleń, czyli numer pracownika, dział, przełożonego, stanowisko i status zatrudnienia. Atrybut statusu zatrudnienia pozwala automatycznie wyłączyć konto w dniu odejścia pracownika, co ma kluczowe znaczenie dla audytu dostępu.

Po stronie treści standardy dzielą się na starsze i nowsze. SCORM opisuje pakowanie kursu i jego komunikację z systemem. xAPI rejestruje pojedyncze zdarzenia uczenia się i od 2023 roku jest formalną normą organizacji standaryzacyjnej, opublikowaną w październiku tego roku. cmi5 łączy oba podejścia i jest następcą SCORM. Rdzeń, który obsługuje SCORM tylko w wersji 1.2, zawęża Ci wybór biblioteki treści, więc to pytanie zadaje się dostawcy przed umową, nie po niej.

Infografika pokazująca cztery ścieżki przepływu danych do LMS: tożsamość, dane pracownika, treści i wyniki oraz zewnętrzne narzędzia.
Cztery główne ścieżki integracji danych z LMS: SAML/OIDC, SCIM, SCORM/xAPI/cmi5 oraz LTI.

Zewnętrzne narzędzia wpina się przez LTI, dziś w wersji 1.3. Bezpieczeństwo tej wersji opiera się na OpenID Connect oraz OAuth 2.0, a starsze wersje zostały wycofane z certyfikacji z powodu przestarzałych mechanizmów zabezpieczeń. Jeśli dane o strukturze i zatrudnieniu mają płynąć automatycznie, po drugiej stronie musi stać system kadrowy z otwartym interfejsem, a przy braku takiego systemu rozmowa przenosi się na dedykowane oprogramowanie HRM.

Ile realnie kosztuje system LMS i czy open source wychodzi taniej?

Brak opłaty licencyjnej za otwarty rdzeń nie oznacza darmowego systemu. Koszt przenosi się na hosting, aktualizacje, bezpieczeństwo i pracę administracyjną. Nie istnieje niezależne badanie, które rozstrzyga, czy otwarty rdzeń wychodzi taniej od subskrypcji, więc rachunek trzeba zrobić dla własnej organizacji.

Z ręką na sercu, w tej sprawie źródła mówią wprost przeciwne rzeczy. Dostawcy komercyjnych systemów twierdzą, że firma wyda na platformę open source więcej niż na produkt w subskrypcji, bo dochodzi konfiguracja serwera, hosting i regularne aktualizacje. Badanie zlecone przez instytucje europejskie wskazuje odwrotnie, że wybór otwartego oprogramowania obniża całkowity koszt posiadania i ogranicza uwiązanie do dostawcy. Obie strony mają rację przy różnych założeniach, a rozstrzyga jedna zmienna, czyli czy w Twojej organizacji jest kto ma ten system utrzymywać.

Ta zmienna wygląda w Polsce dość jednoznacznie. Dedykowany dział albo osobne stanowisko do spraw szkoleń ma 20 procent polskich pracodawców. Wydzielony budżet szkoleniowy ma 33 procent, co oznacza wzrost o 4 punkty procentowe wobec poprzedniego badania. Założenie, że ktoś w organizacji przejmie administrowanie systemem w wolnym czasie, jest w czterech firmach na pięć założeniem fałszywym.

Modele cenowe różnią się między wariantami, więc rachunek warto rozbić na te same pozycje w każdym z nich. Subskrypcja liczona za użytkownika albo roczną opłatę licencyjną, opłata instalacyjna, hosting i jego skalowanie, praca przy aktualizacjach, poprawki bezpieczeństwa, integracje, koszt tworzenia treści, wsparcie użytkowników i czas administratora. Rachunek wygląda inaczej przy dwustu, a inaczej przy pięciu tysiącach kont, bo LMS dla dużej firmy obciąża nie tylko licencję, ale też infrastrukturę i pracę administracyjną.

Jest jeszcze pozycja, której nie widać w arkuszu, a która decyduje o wyjściu. Przy licencji GPL własne modyfikacje utrzymywane wewnątrz firmy zostają Twoje i nie wymagają publikacji. Przy licencji AGPL samo udostępnienie zmodyfikowanej wersji użytkownikom przez sieć rodzi obowiązek zaoferowania im kodu tej wersji. Uwiązanie do dostawcy nie zaczyna się od umowy, tylko od tego, czego nie da się z systemu wyjąć, więc licencję rdzenia sprawdza się na etapie koncepcji, a nie w trakcie negocjacji.

Kiedy podejście hybrydowe ma sens, a kiedy lepiej wybrać gotowy system albo budowę od zera?

Zespół omawia wymagania projektu przed przygotowaniem wyceny developmentu.
Podział wymagań na mniejsze części ułatwia rzetelną wycenę developmentu.

Podejście hybrydowe ma sens w dwóch warunkach jednocześnie. Większość wymagań mieści się w gotowym rdzeniu, a różnicę robi kilka procesów specyficznych dla Twojej organizacji. I jest kto utrzyma system po uruchomieniu. W wyborze systemu zarządzania nauczaniem gotowy produkt w subskrypcji wystarcza przy procesach standardowych. Budowa od zera broni się tylko wtedy, gdy żaden rdzeń nie spełnia wymagań albo gdy sam system jest przewagą konkurencyjną firmy.

Polskie dane pokazują, gdzie leży prawdziwy problem. Szkolenia zawodowe prowadzi 82,5 procent przedsiębiorstw powyżej 250 pracujących, a średnie firmy, czyli te od 50 do 249 osób, 59,5 procent. Jednocześnie w kursach uczestniczy 28,8 procent pracujących, przy 42,4 procent średnio w Unii Europejskiej. Problemem polskich organizacji nie jest brak systemu, tylko wykonanie, więc wariant techniczny wybiera się pod zdolność organizacji do dowiezienia programów szkoleniowych, nie pod długość listy funkcji. Szkolenie pracowników w wielu lokalizacjach wymaga systemu, który ktoś realnie obsłuży. Rozwój pracowników mierzy się ukończeniami i tym, jak rosną umiejętności pracowników, nie liczbą wdrożonych modułów.

Pierwsze dwie reguły dotyczą zakresu. Jeśli wymagania da się opisać jako konfiguracja pojęć, które system już zna, wybierasz gotowy produkt albo otwarty rdzeń, nie budowę od zera, bo 58 typów wtyczek pokrywa dokładnie ten zakres. Kiedy wymaganie da się zrealizować wtyczką, nigdy nie realizujesz go zmianą w kodzie bazowym, bo dokumentacja rdzenia nazywa wtyczkę najlepiej utrzymywalną drogą, a instrukcja aktualizacji ostrzega przed nadpisywaniem kodu nowej wersji.

Kolejne dwie dotyczą warunków po Twojej stronie. Brak kogoś, kto przejmie aktualizacje i bezpieczeństwo instancji, wyklucza samodzielnie utrzymywany otwarty rdzeń, bo duże wydania wychodzą co pół roku, a wsparcie bezpieczeństwa kończy się po trzydziestu sześciu miesiącach. Wymóg obsługi treści w standardzie SCORM 2004 rozstrzygasz przed wyborem rdzenia, bo jeden z najpopularniejszych systemów obsługuje wyłącznie wersję 1.2.

Trzy ostatnie reguły dotyczą ryzyka. Jeśli warstwa własna ma pozostać poufna, sprawdzasz, czy rdzeń jest na GPL czy na AGPL, bo przy AGPL udostępnienie zmodyfikowanej wersji przez sieć rodzi obowiązek zaoferowania kodu. Krótki termin przy specyficznych procesach przechyla wybór na produkt dostawcy rozwijany na zamówienie, bo każdy dodatkowy rok projektu podnosi przekroczenie kosztów o 15 procent. Brak planu na adopcję psuje każdy wariant techniczny. Aż 23 procent organizacji zgłosiło, że projekty w obszarze technologii HR nie spełniły oczekiwań adopcyjnych, a tylko 32 procent liderów raportuje zdrową adopcję zmiany w swojej firmie.

Przepisy prawne dodają dwa obowiązki, które nie zależą od wybranego wariantu, a zachowanie zgodności z nimi jest warunkiem uruchomienia systemu. Przy systemie utrzymywanym przez dostawcę Twoja firma pozostaje administratorem danych szkoleniowych pracowników, a dostawca jest podmiotem przetwarzającym, co wymaga umowy powierzenia o treści określonej w przepisach o ochronie danych. Jeśli system ocenia wyniki albo zachowanie pracowników z użyciem sztucznej inteligencji, przed jego uruchomieniem trzeba poinformować przedstawicieli pracowników i samych pracowników, a automatycznie generowane logi przechowywać co najmniej sześć miesięcy.

Dobra wiadomość jest taka, że najtaniej rozstrzyga się to wszystko przed pierwszą linią kodu. Na warsztatach product discovery lista wymagań rozkłada się na konfigurację, wtyczki, warstwę własną i to, co naprawdę trzeba napisać. Dopiero ta czwarta kategoria jest kosztem projektu. Kiedy wariant jest wybrany, zostaje pytanie o kolejność działań, czyli jak wdrożyć system LMS tak, żeby pierwsza grupa pracowników weszła do niego w tygodniach, a nie w kwartałach.

FAQ

LMS to skrót od learning management system, po polsku system zarządzania nauczaniem. W firmach ten sam typ oprogramowania nazywa się też systemem zarządzania szkoleniami. Ten sam skrót funkcjonuje również w zupełnie innych znaczeniach, na przykład w zarządzaniu sieciami komputerowymi, więc w rozmowie z IT warto rozwinąć go raz na początku.

To oprogramowanie do tworzenia, dostarczania i rozliczania szkoleń, dostępne przez przeglądarkę na komputerze i na telefonie. Pracownik znajduje w nim przypisane kursy i materiały, a dział HR widzi postępy, wyniki i ważność certyfikatów. Program działa jako jedno miejsce dla całej organizacji, zamiast plików rozproszonych po dyskach.

Istnieją systemy bez opłaty licencyjnej, wydawane na otwartych licencjach. Brak licencji nie oznacza jednak braku kosztów, bo pozostają hosting, aktualizacje co pół roku, poprawki bezpieczeństwa, integracje i czas administratora. Darmowy jest kod, nie system, a największą pozycją w rachunku okazuje się praca ludzi, którzy go utrzymują.

Najczęściej wymieniane otwarte rdzenie to Moodle, Open edX, Canvas LMS oraz Chamilo, wydawane odpowiednio na licencjach GNU GPL, AGPLv3, AGPLv3 i GPLv3. Obok nich działają systemy komercyjne w modelu subskrypcyjnym oraz produkty dostawców rozwijane na zamówienie w modelu white label. Wybór zależy od tego, kto ma utrzymywać system.

Przy licencji GNU GPL nie, dopóki nie rozpowszechniasz oprogramowania poza organizację, bo obowiązek udostępnienia kodu powstaje przy dystrybucji. Przy licencji AGPL sytuacja jest inna, bo samo udostępnienie zmodyfikowanej wersji użytkownikom przez sieć rodzi obowiązek zaoferowania im kodu tej wersji. Licencję rdzenia sprawdza się przed decyzją.

Otwarte standardy przenoszą treści szkoleniowe oraz rekordy aktywności uczestników, więc podstawa jest zabezpieczona. Przenoszalność całego środowiska, czyli struktury kursów, ról, uprawnień i historycznych raportów, zależy od konkretnego systemu i od umowy. To pytanie zadaje się dostawcy przed podpisaniem, razem z prośbą o przykładowy eksport.

Twoja firma pozostaje administratorem danych szkoleniowych pracowników, bo to ona ustala cele i sposoby ich przetwarzania. Dostawca utrzymujący system jest podmiotem przetwarzającym i działa na Twoje polecenie. Taki układ wymaga umowy powierzenia, która określa zakres i czas przetwarzania, zasady angażowania podwykonawców oraz zwrot lub usunięcie danych po zakończeniu usługi.

Tak. Systemy sztucznej inteligencji służące do oceny wyników i zachowania pracowników są klasyfikowane jako systemy wysokiego ryzyka. Przed uruchomieniem takiego systemu w miejscu pracy pracodawca informuje przedstawicieli pracowników oraz samych pracowników, że będą mu podlegać. Automatycznie generowane logi trzeba przechowywać co najmniej sześć miesięcy i wyznaczyć osoby odpowiedzialne za nadzór.