Jak napisać zadanie dotyczące wyboru systemu LMS

Wybór systemu zarządzania nauczaniem (LMS) zazwyczaj nie zawodzi pod względem technologii, ale niejasno zdefiniowanych oczekiwań. Starannie przygotowane zadanie ujednolici język między zespołem a dostawcami, zapewni porównywalne oferty i znacznie skróci późniejsze wdrożenie. 

W tym artykule omówiono wybrane obszary postępowania przetargowego: od definicji celów i użytkowników, poprzez treść i funkcje, integrację i bezpieczeństwo, aż po kryteria oceny.

Wskazówka: Jeśli rozważają Państwo już konkretne platformy, zalecamy najpierw sformułować wewnętrznie wymagania „must-have”, a dopiero potem rozpocząć negocjacje z dostawcami. W ten sposób unikną Państwo rozpraszania uwagi dyskusjami na temat funkcji, które nie są istotne dla Państwa potrzeb.

Kiedy rozpocząć tworzenie specyfikacji i dlaczego ma to znaczenie

Specyfikację warto tworzyć w momencie, gdy znasz już przynajmniej ogólny zarys projektu i masz podstawową wiedzę na temat rynku. Jest to absolutnie kluczowe w przypadku tworzenia zamówień publicznych.  Prawidłowo sporządzona dokumentacja przetargowa stanowi punkt odniesienia dla wszystkich zainteresowanych stron: zarówno dla Państwa zespołu wewnętrznego, jak i potencjalnych dostawców. Im dokładniej opiszą Państwo kontekst i oczekiwania, tym bardziej realistyczne i porównywalne oferty otrzymają Państwo. 

Kontekst i cele: określ mierzalne wyniki

Wprowadzenie do dokumentacji przetargowej powinno w kilku akapitach wyjaśniać, kim jesteś, dlaczego wdrażasz lub modyfikujesz system LMS i jakich wyników oczekujesz. Unikaj ogólnych sformułowań i preferuj mierzalne wskaźniki: na przykład „skrócenie czasu potrzebnego na ukończenie obowiązkowych szkoleń dla nowych pracowników z 30 do 21 dni w ciągu sześciu miesięcy od wdrożenia systemu LMS” lub „zwiększenie rocznego wskaźnika ukończenia szkoleń ustawowych z 85% do 95%”. Tak sformułowane cele następnie przełożysz na kryteria oceny, scenariusze i testy akceptacyjne.

Wskazówka: W zadaniu należy uwzględnić również cele negatywne, czyli to, czego system nie musi robić, nie ma lub jest bezpośrednio niepożądane. Pozwoli to uniknąć niepożądanych dostosowań lub rozszerzenia zakresu przez potencjalnych dostawców.

Użytkownicy, role i wzrost: wpływ na licencjonowanie i wydajność

Wiele rozwiązań chmurowych lub pudełkowych ma model cenowy oparty na liczbie licencji (czyli użytkowników w systemie). Dostawcy muszą wiedzieć, ilu użytkowników będzie aktywnych w systemie, jakie będą pełnić role (student, wykładowca, administrator, menedżer, audytor) oraz jak według Państwa będzie kształtować się liczba użytkowników w perspektywie 12–24 miesięcy. Nie chodzi tylko o liczbę użytkowników (a co za tym idzie liczbę licencji), ale także o obciążenie serwera, a tym samym koszty jego działania. Jeśli przewidujesz sezonowe szczyty – na przykład w przypadku obowiązkowych szkoleń lub szkoleń produktowych – podaj to również w dokumentacji przetargowej, aby dostawca mógł uwzględnić rzeczywiste koszty eksploatacji infrastruktury.

Przykład z praktyki: Sieć detaliczna planowała rozpoczęcie obowiązkowych szkoleń BHP dla 7000 pracowników w ciągu dwóch tygodni. Dzięki temu, że wyraźnie opisała szczytowe obciążenie w dokumentacji przetargowej, dostawca zaproponował tymczasowe zwiększenie wydajności i zapobiegł awariom i kolejkom w systemie. W rezultacie obciążenie serwerów było mniejsze, a koszty eksploatacji mogły zostać jasno określone z wyprzedzeniem.

Treść i standardy: pamiętaj o analityce

Opisz, jaką treść będziesz udostępniać w LMS: czy będą to kursy zgodne ze standardami SCORM 1.2/2004, xAPI/cmi5, ewentualnie filmy, pliki PDF lub webinaria. Podaj, jakich narzędzi autorskich używasz i jak będzie wyglądał proces publikacji. Jeśli planujesz bardziej szczegółową analitykę (np. śledzenie działań edukacyjnych również poza LMS), rozważ wymaganie dotyczące LRS (Learning Record Store). 

Wskazówka: Zastanów się, czy potrzebujesz narzędzi do eksportu i importu, przykładowych migracji i przeglądu pól danych. Jeśli tak, nie zapomnij wspomnieć o tym w specyfikacji, aby uniknąć ręcznego „przenoszenia” danych lub uzależnienia od dostawcy w przyszłości.

Wymagania funkcjonalne: scenariusze są cenniejsze niż listy

Zamiast długich tabel „tak/nie” zalecamy opisanie kilku reprezentatywnych scenariuszy, które odzwierciedlają rzeczywiste potrzeby. Na przykład: „Nowy pracownik w oddziale w Brnie jest automatycznie przypisywany do ścieżki onboardingowej zgodnie ze stanowiskiem i językiem; jego kierownik otrzymuje cotygodniowy przegląd realizacji, a dział HR miesięczny raport zbiorczy”. Dopiero na podstawie tych scenariuszy można opracować strukturę funkcji (testy, certyfikaty, ścieżki edukacyjne, rekomendacje treści, grywalizacja, powiadomienia, katalog kursów, biblioteka, umiejętności i kompetencje, pulpity nawigacyjne, treść raportów). Na przykładach opisz, jacy użytkownicy będą korzystać z systemu i w jaki sposób. Dzięki temu dostawca lepiej zrozumie proces, priorytety i planowane wykorzystanie systemu i będzie mógł zaproponować odpowiednią konfigurację.

Przykład z praktyki: W usługach centrów współdzielonych wystarczyło zdefiniować trzy dobrze opisane scenariusze, aby jeden z pierwotnych faworytów odpadł – nie był w stanie zapewnić regularnych i przejrzystych raportów dla menedżerów studiów bez dodatkowego rozwoju.

Integracja: opisz przepływy danych i obowiązki

Integracja nie powinna być jedynie wyliczeniem logo. Podaj, jakich systemów używasz (HRIS/ERP, Microsoft 365 lub Google Workspace, narzędzie do webinarów itp.) i jaki system będzie „źródłem prawdy” dla danych użytkowników (czy będzie to Twój CRM lub przyszły LMS?), jasno opisz strukturę organizacyjną, role i uprawnienia w systemie. Opisane procesy przetwarzania danych – kto zakłada użytkowników, kto zarządza i przypisuje role, kto planuje webinaria i gdzie są zapisywane wyniki – zapobiegną nieporozumieniom podczas wdrażania. 

Bezpieczeństwo i zgodność z przepisami: określ minimalne wymagania bez kompromisów

Sformułuj konkretne wymagania dotyczące bezpieczeństwa: jakie certyfikaty są wymagane (np. ISO 27001), w jaki sposób będzie realizowane szyfrowanie danych „w spoczynku” i „podczas przesyłania”, jak długo mają być przechowywane zapisy audytowe i jak będzie wyglądać umowna regulacja przetwarzania danych osobowych. W przypadku projektów międzynarodowych należy podać, gdzie mają być przechowywane dane (np. w UE). Jasno określone minimum znacznie przyspieszy ocenę prawną i bezpieczeństwa po wyborze dostawcy.

Przykład z praktyki: W sektorze usług finansowych wybór dostawcy LMS opóźnił się o kilka tygodni z powodu wymagań dotyczących dzienników audytowych. Częścią zadania było „rejestrowanie wpisów na wypadek przyszłych potrzeb”, ale nie określono jasno, co ma być rejestrowane, dlaczego, w jakiej formie, gdzie i jak długo. 

Dostępność i lokalizacja

Dostępność nie jest dodatkiem, ale koniecznością. Należy zaznaczyć, że interfejs użytkownika musi być zgodny z WCAG 2.2. Należy określić wersje językowe i wymagania dotyczące lokalizacji lub brandingu systemu – czy będą potrzebne własne kolory, logo lub typografia? Jak często będzie się zmieniać wygląd systemu? Czy będzie to w ogóle możliwe? Takie informacje pomagają w odpowiednim czasie oszacować zakres prac i zapobiec późniejszym „szybkim” interwencjom.

Wskazówka: Poproś dostawcę, aby w wersji demonstracyjnej/przykładowej zaprezentował również pracę z systemem. Wiele niedociągnięć ujawni się natychmiast.

Model operacyjny i SLA: chmura vs. lokalizacja i oczekiwania dotyczące wsparcia

Decyzja między chmurą a lokalnym rozwiązaniem wynika z wymagań dotyczących bezpieczeństwa, integracji i działania. Chmura zazwyczaj wygrywa pod względem szybkości wdrożenia i mniejszego obciążenia wewnętrznego działu IT, natomiast rozwiązanie lokalne ma swoje zastosowanie tam, gdzie wymagana jest silna izolacja i szczegółowa kontrola środowiska. W specyfikacji należy określić oczekiwaną dostępność, czasy reakcji i naprawy wsparcia, plan tworzenia kopii zapasowych oraz testy przywracania. Jasno sformułowana umowa SLA to najlepszy sposób na uniknięcie rozczarowań. 

Migracja i wdrożenie: planuj realistycznie i krok po kroku

Migracja istniejących danych jest często najtrudniejszą częścią projektu. Czy nowe rozwiązanie ma umożliwiać migrację istniejących/archiwizowanych danych? W jakim zakresie? Gdzie są one przechowywane? W jakim formacie można dostarczyć dane historyczne? Opisz zakres i źródła danych (użytkownicy, wyniki, certyfikaty, kursy), zasady mapowania i oczekiwane czyszczenie danych.
W przypadku wdrożenia należy określić role po obu stronach, plan szkoleń administratorów i wykładowców oraz procedurę akceptacji. Należy z odpowiednim wyprzedzeniem poprosić o środowisko testowe, aby można było na bieżąco weryfikować scenariusze.

Przykład z praktyki: Organizacja z historycznym systemem LMS przeniosła do nowego systemu tylko bieżące certyfikaty i obowiązkowe zapisy, pozostawiając dane archiwalne w starym systemie LMS, który został zablokowany dla zwykłych użytkowników. Dostawa systemu LMS stała się tańsza, a wdrożenie rozwiązania skróciło się o prawie miesiąc.

Kryteria oceny i matryca: jak uczciwie porównać oferty

Aby można było porównać oferty dostawców, należy ujednolicić kryteria i ich wagi. W praktyce sprawdza się przypisanie największej wagi wymaganiom funkcjonalnym i integracjom, oddzielna ocena dostępności i bezpieczeństwa oraz przejrzysta ocena całkowitych kosztów w horyzoncie 12–36 miesięcy. Należy również pamiętać o referencjach – doświadczenie dostawcy w podobnych środowiskach jest często kluczowe dla sprawnego przebiegu wdrożenia. 

Wskazówka: W ramach zadania poproś kandydatów o tabelaryczne zestawienie spełnienia Twoich wymagań z możliwościami oferowanego LMS (spełnione / częściowo spełnione / niespełnione + komentarz) – w przypadku „gotowych rozwiązań” o kontrolowaną prezentację zgodnie z Twoimi scenariuszami. W ten sposób uzyskasz bardziej obiektywną podstawę do punktowej oceny.

Modele cenowe i koszty posiadania: spójrz poza horyzont pierwszego roku

Cena LMS nie zależy wyłącznie od liczby użytkowników. Należy rozróżnić, czy licencjonowanie opiera się na całkowitej liczbie użytkowników, czy na liczbie aktywnych użytkowników, oraz jak definiowana jest „aktywność” (miesięczna, kwartalna). Należy określić, które moduły są obowiązkowe, a które mogą być opcjonalne. W przypadku wdrożenia i modyfikacji należy jasno opisać, które pozycje są stałe, a które są pozycjami oczekiwanymi, które mogą jeszcze wzrosnąć w ramach wdrożenia lub późniejszej eksploatacji. Koszty należy oceniać w dłuższej perspektywie czasowej, ponieważ obejmują one również integrację, bieżące modyfikacje, szkolenia i rozwój.

Najczęstsze błędy i jak ich uniknąć

Do najczęstszych błędów należą brak mierzalnych celów, niejasny podział wymagań na „niezbędne” i „pożądane” oraz niedocenianie integracji i migracji. Ryzykiem jest również skupianie się na cenie zakupu bez uwzględnienia późniejszych kosztów eksploatacji. Większość tych problemów wystarczy przemyśleć już na etapie tworzenia zadania i uwzględnić je w kryteriach oceny lub umowach serwisowych.

Nie chcesz zajmować się tym samodzielnie?

Nie jest łatwo się w tym wszystkim odnaleźć? Skontaktuj się z nami. Przeanalizujemy Twoje potrzeby, wspólnie przygotujemy jasne wymagania i pomożemy wybrać system LMS, który będzie odpowiadał Twoim celom i budżetowi.