Jak mądrze wybierać rozwiązania e-learningowe – przewodnik dla HR i L&D

Wiele zapytań o platformę szkoleniową wygląda podobnie. Zamawiający wpisuje, że potrzebuje LMS do obsługi e-learningu, raportowania, testów, certyfikatów i integracji. Brzmi sensownie. Problem w tym, że na tak opisane zapytanie można odpowiedzieć niemal wszystkim. A skoro niemal każda oferta "spełnia wymagania", to jak później odróżnić rozwiązanie dojrzałe od takiego, które dobrze wygląda tylko w prezentacji?

W projektach e-learningowych widzimy ten problem regularnie. Ktoś po stronie HR lub szkoleń naprawdę chce dobrze przygotować postępowanie, ale dostaje od organizacji bardzo ogólne oczekiwanie: "kupmy platformę, która ogarnie szkolenia online". Tyle że platforma LMS ma zwykle ogarnąć znacznie więcej: obowiązkowe szkolenia compliance, onboarding, webinary, dokumenty, testy, certyfikację, raporty dla audytu, a czasem jeszcze integrację z katalogiem użytkowników i eksport danych do innych systemów. Jeśli to nie zostanie dobrze nazwane na starcie, porównanie ofert będzie pozorne.

Może pomyślisz: przecież dostawcy i tak dopytają. Czasem tak. Czasem jednak odpowiedzą dokładnie tyle, ile wynika z zapytania. A wtedy wygrywa nie najlepsze rozwiązanie, tylko najlepsza interpretacja niedopowiedzianych wymagań i oczywiście najniższa cena.

Zanim napiszesz wymagania, nazwij problem biznesowy

To jest pierwszy krok, który oszczędza najwięcej czasu. Nie zaczynaj od listy funkcji. Zacznij od odpowiedzi na pytanie: po co organizacji ta platforma właśnie teraz?

W praktyce najczęściej widzimy trzy sytuacje.

Pierwsza: organizacja musi raportować wykonanie szkoleń obowiązkowych i potrzebuje twardych danych o przypisaniu, postępie, zaliczeniu i terminach. W takim przypadku kluczowe stają się automatyzacja przypisań, role, raportowanie, historia aktywności, certyfikacja i eksport danych. Są platformy, które została zaprojektowana właśnie do obsługi takich procesów, w tym raportowania postępów, wyników testów, logowań, pobranych dokumentów i obszaru compliance. Obsługują też ścieżki szkoleniowe, terminy dostępności, obowiązkowość szkoleń i automatyczne procesy szkoleniowe.

Druga: firma ma rozproszoną strukturę i problem z administracją użytkownikami. Wtedy samo "mamy LMS" niczego jeszcze nie rozwiązuje. Trzeba opisać sposób zasilania kont, grup i struktury organizacyjnej, role lokalnych administratorów, integrację z Azure AD, SSO czy SAML 2.0 oraz synchronizację danych organizacyjnych. To są rzeczy, które później decydują o nakładzie pracy po stronie HR i IT.

Trzecia: organizacja chce mieć jedno środowisko nie tylko do kursów SCORM, ale też webinarów, wydarzeń stacjonarnych, testów, ankiet, dokumentów i bazy wiedzy. Wtedy zapytanie powinno obejmować cały proces uczenia, a nie wyłącznie "odtwarzanie kursów".

Dopiero gdy nazwiesz główny problem, możesz sensownie ułożyć wymagania.

Co powinno znaleźć się w zapytaniu ofertowym na platformę szkoleniową

1. Opis kontekstu użycia, a nie tylko listy funkcji

To częsty błąd. Zamawiający wpisuje 40 funkcjonalności, ale nie pisze, w jakim modelu organizacja będzie z nich korzystać. A przecież inaczej wygląda wdrożenie platformy dla 800 pracowników w jednej lokalizacji, a inaczej dla kilkunastu tysięcy użytkowników w rozproszonej strukturze, z kilkoma poziomami administracji i obowiązkowymi szkoleniami cyklicznymi.

W zapytaniu warto więc podać:

• liczbę użytkowników
• strukturę organizacyjną
• typy odbiorców, np. pracownicy, menedżerowie, partnerzy, klienci
• typy treści, np. SCORM, PDF, wideo, webinary, testy
• główne procesy, np. onboarding, compliance, rozwój kompetencji
• przewidywany model administracji, centralny lub rozproszony

Bez tego dostawca może zadeklarować zgodność, ale każdy będzie rozumiał ją inaczej.

2. Wymagania funkcjonalne opisane operacyjnie

Zamiast pisać: "platforma ma mieć raporty", lepiej napisać:
administrator centralny musi móc wygenerować raport ukończenia obowiązkowego szkolenia według spółki, działu, przełożonego, terminu i statusu, z możliwością eksportu do Excel.

To zmienia wszystko. Nagle nie pytasz o ogólną funkcję. Pytasz o konkretny scenariusz pracy.

W przypadku platformy szkoleniowej szczególnie warto opisać takie obszary:

• Zarządzanie szkoleniami
  Import SCORM, przypisywanie do użytkowników i grup, terminy dostępności, zależności między szkoleniami, ścieżki szkoleniowe, materiały dodatkowe.
• Testy, ankiety i certyfikacja
  Różne typy pytań, limity czasu, losowanie pytań, progi zaliczeniowe, wielokrotne podejścia, ankiety satysfakcji, automatyczne generowanie certyfikatów PDF z własnych szablonów i unikalnymi numerami.
• Raportowanie
  Raporty dynamiczne, eksport do Excel, monitoring postępów, wyniki testów, logowania, aktywność użytkowników, obszar compliance. Tu naprawdę warto być szczegółowym, bo "raportowanie" jest jednym z najczęściej nadużywanych słów w ofertach.
• Zarządzanie użytkownikami
  Import z arkuszy, grupy, struktura organizacyjna, przypisywanie przełożonych, role, poziomy administracyjne, automatyczne przypisania do grup.

3. Wymagania wdrożeniowe

To obszar, który bywa niedoszacowany. A potem okazuje się, że platforma jest dobra "co do zasady", tylko nikt nie policzył kosztu i czasu dojścia do stanu używalności.

W zapytaniu warto zawrzeć pytania o:

• konfigurację środowiska i brandingu
• import użytkowników
• import treści szkoleniowych
• konfigurację ról i uprawnień
• konfigurację grup i struktury organizacyjnej
• migrację historii szkoleń z obecnego rozwiązania
• szkolenie dla administratorów
• uruchomienie środowiska produkcyjnego
• orientacyjny harmonogram wdrożenia oraz zależności po stronie klienta

4. Bezpieczeństwo, RODO i dostępność

To nie powinien być osobny załącznik "dla formalności". To jeden z głównych elementów porównania ofert.

W zapytaniu warto poprosić o odpowiedzi na konkretne pytania:

• gdzie są przechowywane dane użytkowników
• czy dane pozostają w EOG
• jakie są mechanizmy kontroli dostępu
• jakie są procedury retencji, anonimizacji, eksportu i usuwania danych
• jakie standardy bezpieczeństwa dostawca stosuje
• jak wyglądają backup i disaster recovery

To nie są detale. RODO wymaga, aby przetwarzanie danych było odpowiednio zabezpieczone, z uwzględnieniem ryzyka. Z kolei OWASP ASVS bywa wykorzystywany jako punkt odniesienia do definiowania i weryfikacji wymagań bezpieczeństwa aplikacji webowych. Inne zabezpieczenia to m.in. szyfrowanie SSL/TLS, wielopoziomowe role i uprawnienia, zgodność z wytycznymi OWASP ASVS, firewall oraz IDS/IPS, polityka retencji danych i przechowywanie danych wyłącznie w EOG.

5. Integracje i wyjście z systemu

Dobre zapytanie sprawdza nie tylko wejście do systemu, ale też wyjście z niego. To wbrew pozorom ważny test dojrzałości dostawcy.

Warto zapytać:

• z jakimi systemami platforma integruje się standardowo
• jakie są dostępne metody uwierzytelniania
• czy istnieje API REST
• jakie dane można synchronizować automatycznie
• w jakich formatach można eksportować dane i materiały

Specyfikacje niektórych platform wprost wskazują, że dane, materiały i raporty pozostają własnością klienta oraz mogą być eksportowane w standardowych formatach umożliwiających migrację do innych systemów. To jest dobry przykład wymagania, które warto mieć również w swoim zapytaniu, niezależnie od tego, którego dostawcę wybierzesz.

Jak pisać wymagania, żeby oferty były porównywalne

Najprostsza rada brzmi: oddziel wymagania obowiązkowe od punktowanych.

Jeśli wszystko jest obowiązkowe, to nic nie jest naprawdę ważne. A jeśli wszystko jest punktowane, dostawcy będą rozgrywać interpretacje.

Dobrze działa taki podział:

• wymagania obowiązkowe - bez nich oferta odpada
• wymagania punktowane - zwiększają użyteczność, skalowalność albo bezpieczeństwo
• pytania opisowe - pokazują dojrzałość dostawcy i sposób pracy we wdrożeniu

Przykład?

• Wymaganie obowiązkowe:
  Platforma musi umożliwiać obsługę procesów szkoleniowych w organizacji, w tym: zarządzanie użytkownikami i grupami, przypisywanie szkoleń obowiązkowych i rozwojowych, realizację kursów SCORM, testów i ankiet, generowanie certyfikatów oraz raportowanie postępów, wyników i statusów ukończenia.
• Wymaganie punktowane:
  Dodatkowe punkty za rozbudowane funkcje wspierające administrację i raportowanie, w szczególności: automatyczne procesy szkoleniowe, ścieżki szkoleniowe, eksport danych do Excel, raportowanie compliance, integrację z SSO, Azure AD, Active Directory, API REST oraz możliwość obsługi webinarów, wydarzeń stacjonarnych i dokumentów w jednym środowisku.
• Pytanie opisowe:
  Proszę opisać, jak w praktyce wygląda wdrożenie platformy w dużej organizacji, w tym: konfiguracja środowiska i brandingu, role i uprawnienia, import użytkowników i materiałów, konfiguracja grup i struktury organizacyjnej, migracja historii szkoleniowych, szkolenie administratorów, model wsparcia technicznego oraz sposób realizacji raportowania dla obszarów obowiązkowych i audytowych.

Tak skonstruowane zapytanie premiuje rozwiązania bardziej dojrzałe organizacyjnie. A to zwykle są właśnie te platformy, które później mniej obciążają HR, L&D i IT.

Cena ma znaczenie, ale nie powinna decydować sama

Cena oczywiście ma znaczenie, szczególnie wtedy, gdy projekt musi zmieścić się w sztywnym budżecie. Problem zaczyna się wtedy, gdy organizacja porównuje wyłącznie koszt dostępu do platformy, a pomija koszt wdrożenia, integracji, migracji danych, pracy administratorów, wsparcia technicznego, aktualizacji i późniejszych zmian. Wtedy najtańsze rozwiązanie bywa najdroższe w utrzymaniu. W praktyce wygląda to często tak: system jest tani na starcie, ale nie ma automatyzacji, raporty trzeba składać ręcznie, użytkowników importuje się manualnie, a każda zmiana wymaga udziału dostawcy albo działu IT. Osoba z HR lub L&D oszczędza więc w tabeli zakupowej, ale traci czas przez kolejne miesiące. Dlatego warto oceniać nie tylko cenę licencji, lecz całkowity koszt używania platformy w perspektywie np. 2 lat: wdrożenie, administrację, support, rozwój i ryzyko błędów. To zwykle daje znacznie uczciwszy obraz niż proste pytanie: kto jest najtańszy?

Czego nie wpisywać zbyt ogólnie

Z naszych doświadczeń wynika, że szczególnie niebezpieczne są cztery sformułowania.

"Platforma ma być intuicyjna"
To za mało. Lepiej poprosić o scenariusze demo dla administratora i użytkownika.

"Platforma ma mieć raportowanie"
Jakie raporty, dla kogo, w jakim układzie, z jakim eksportem?

"Platforma ma być bezpieczna"
Według jakich standardów, z jakimi procedurami, z jakim zakresem odpowiedzialności?

"Platforma ma się integrować z systemami klienta"
Z którymi dokładnie, w jakim kierunku, jak często, z jakim zakresem danych?

To trochę jak z zakupem samochodu służbowego na podstawie wymagania: "ma dobrze jeździć". Niby prawda, ale dział zakupów wiele z tego nie wyciągnie.

Co warto dać dostawcom "na tacy"

Jeżeli chcesz dostać oferty, które da się realnie porównać, wpisz do zapytania przynajmniej te informacje:

1. liczba użytkowników i przewidywana skala wzrostu
2. typy szkoleń i materiałów
3. wymagane scenariusze raportowe
4. wymagany model administracji
5. lista integracji
6. wymagania bezpieczeństwa, RODO i dostępności
7. oczekiwania wobec wdrożenia i szkoleń administratorów
8. oczekiwany model wsparcia i SLA
9. wymagania dotyczące eksportu danych i zakończenia współpracy
10. kryteria oceny ofert wraz z wagami

Podsumowanie

Dobre zapytanie ofertowe na platformę szkoleniową nie polega na zebraniu najdłuższej listy funkcji. Polega na tym, by nazwać własny kontekst, opisać kluczowe procesy i zmusić dostawców do odpowiedzi na pytanie, jak ich rozwiązanie poradzi sobie w codziennej pracy organizacji.

Jeśli zapytanie będzie zbyt ogólne, dostaniesz oferty trudne do porównania. Jeśli będzie zbyt techniczne i oderwane od praktyki HR czy L&D, możesz odsiać sensownych partnerów, a zostawić tych, którzy najlepiej piszą odpowiedzi do tabeli. Najlepsze efekty daje trzecia droga: wymagania konkretne, ale osadzone w realnych scenariuszach użycia.

W takich projektach sprawdza się rozwiązanie, które łączy dojrzałe raportowanie, obsługę szkoleń SCORM, testów, ankiet, webinarów, certyfikacji, integracji i bezpieczeństwa z przewidywalnym wdrożeniem oraz wsparciem po starcie.

Nasza rada

Przygotowując dokumentację wyboru platformy, warto skonsultować ją nie tylko z HR czy L&D, ale też z osobami z biznesu, które będą później korzystać z raportów, statusów realizacji i procesów szkoleniowych. To pozwala lepiej opisać realne potrzeby organizacji i uniknąć wyboru rozwiązania, które dobrze wygląda w tabeli, ale słabo działa w praktyce.