Wybór systemu HRM zacząłbym od trzech rzeczy: problemów do rozwiązania, procesów do obsłużenia i warunków, których firma nie może pominąć. Dopiero z taką listą warto porównywać dostawców.
Bo pytanie „jaki HRM jest najlepszy?” szybko prowadzi do kolejnego: najlepszy do czego?
Do uporządkowania danych? Urlopów? Rekrutacji? Ocen? A może do tego, żeby HR przestał przypominać wszystkim o wszystkim?
Każda z tych odpowiedzi może zmienić wybór.
1. Co ma działać lepiej po wdrożeniu?
„Chcemy zdigitalizować HR” to kierunek. Do porównania ofert potrzebujesz konkretu.
Na przykład: menedżer ma widzieć, które zadania związane z przyjęciem nowej osoby są wykonane. HR ma sprawdzić status bez pisania do trzech działów. Pracownik ma wiedzieć, gdzie znaleźć potrzebną informację.
Zapisz trzy najważniejsze rezultaty. Jeżeli wszystko jest równie pilne, trudno będzie ustalić, co uruchomić najpierw.
2. Które procesy mają wejść do systemu na start?
Oddziel pierwszy etap od pomysłów na przyszłość.
Możesz potrzebować bazy pracowników i obiegu wniosków teraz, a ocen dopiero po ustaleniu zasad ich prowadzenia. Sprawdź możliwość późniejszej rozbudowy, ale wyceń też wariant obejmujący wyłącznie obecne potrzeby.
Sama dostępność modułu nie oznacza, że firma jest gotowa go używać.
3. Jakie sytuacje system musi obsłużyć?
Weź jeden proces i opisz go od początku do końca. Dodaj wyjątek.
Przykładowo: nowa osoba zaczyna pracę, menedżer dostaje zadania, IT przygotowuje dostęp. Co się stanie, jeśli termin rozpoczęcia pracy się przesunie? Kto poprawi zadania? Czy informacja dotrze do właściwych osób?
Tak przygotowany scenariusz daje więcej niż pytanie „czy macie onboarding?”.
4. Kto będzie z tego korzystać?
System powinien pasować do pracy HR, menedżera i pracownika. Każda z tych osób potrzebuje czegoś innego.
Poproś o pokazanie tego samego procesu z różnych kont. Sprawdź też sposób dostępu osób, które nie pracują przy komputerze. Wygodny panel administratora nie mówi jeszcze wiele o codziennym korzystaniu z narzędzia przez resztę firmy.
5. Co już działa i warto to zachować?
Masz sprawny ATS? Dobrze działające urlopy? Program kadrowo-płacowy, którego nie planujesz zmieniać?
Zapisz, co ma zostać. Przy każdej planowanej zmianie sprawdź, czy nowy system obsłuży ważne funkcje obecnego narzędzia. Nie tylko te widoczne na pierwszym ekranie. Również raporty, wyjątki i eksport danych.
6. Jak będą przepływać dane?
„Mamy integrację” wymaga doprecyzowania.
Jakie dane są przekazywane? W którą stronę? Jak często? Co się dzieje po poprawieniu błędu? Kto odpowiada za utrzymanie połączenia?
Gdybym miał wybrać jeden test integracji, wybrałbym korektę już przekazanej informacji. Chciałbym zobaczyć, gdzie pojawi się poprawna wersja i kto zauważy ewentualny błąd. Gotowe połączenie, wymiana plików i możliwość zbudowania integracji przez API oznaczają różny zakres prac. Poproś o opis rozwiązania dla Twojej konfiguracji i uwzględnij jego koszt.
7. Kto zobaczy poszczególne informacje?
Sprawdź dostęp na przykładach. Czy menedżer widzi tylko potrzebne dane swojego zespołu? Co zobaczy po zmianie działu? Jak odbierany jest dostęp osobie kończącej współpracę?
Do oceny rozwiązania włącz osoby odpowiedzialne za IT i ochronę danych. Ogólna deklaracja dostawcy nie zastępuje sprawdzenia uprawnień i sposobu pracy w Twojej firmie.
8. Kto wykona prace wdrożeniowe?
Ustal, kto przygotuje dane, skonfiguruje procesy, sprawdzi ich działanie i przeszkoli użytkowników.
„Wdrożenie w cenie” może oznaczać różny zakres wsparcia. Poproś o konkretne zadania po stronie dostawcy i po stronie firmy. Dodaj osobę, która podejmie decyzję, gdy pojawi się sporna kwestia.
9. Jaki będzie koszt całego rozwiązania?
Porównaj ten sam zakres: liczbę użytkowników, moduły, okres umowy, wdrożenie, integracje i wsparcie. Uwzględnij pracę własnego zespołu.
Osobno policz pierwszy rok i dalsze korzystanie. Do szczegółów wracam w artykule Ile kosztuje system HRM?.
10. Po czym poznasz, że system pasuje?
Przed demo ustal, co musi zostać pokazane. Zamiast „onboarding działa”, zapisz: można przydzielić zadania HR, menedżerowi i IT, zobaczyć ich status oraz obsłużyć zmianę terminu.
Na testach korzystaj z danych przykładowych. Zapisuj, co widziałeś, co wymaga konfiguracji, a co pozostaje deklaracją dostawcy. Funkcję dopiero planowaną oceniaj oddzielnie od dostępnej.
Jak porównać odpowiedzi?
Przygotuj prostą tabelę:
| Wymaganie | Jak je sprawdzimy? | Wynik testu | Koszt lub ograniczenie |
|---|---|---|---|
| Zastępstwo przy akceptacji wniosku | Test nieobecności menedżera | Do uzupełnienia | Do uzupełnienia |
| Przekazanie danych do kadr | Próbny eksport i odbiór danych | Do uzupełnienia | Do uzupełnienia |
| Zmiana terminu onboardingu | Zmiana daty w scenariuszu testowym | Do uzupełnienia | Do uzupełnienia |
Najpierw sprawdź wymagania konieczne. System z dużą liczbą dodatków może nadal nie obsługiwać procesu, bez którego firma nie ruszy.
Przed pierwszym spotkaniem możesz skorzystać z checklisty przed wyborem systemu HRM. Uzupełnij ją razem z osobami, które później będą pracować w systemie. Ich pytania warto poznać przed podpisaniem umowy.
Zanim zaprosisz dostawców: przygotuj kartę decyzji
Największą różnicę między przypadkowym demo a użytecznym porównaniem robi przygotowanie jednej strony z wymaganiami. Nie musi to być rozbudowane RFP. Wystarczy dokument, który mówi, co próbujecie poprawić, które procesy są najważniejsze i jak sprawdzicie odpowiedź dostawcy.
Przy każdym wymaganiu zapisałbym cztery rzeczy: obecny problem, oczekiwany rezultat, scenariusz testowy oraz poziom ważności. Dzięki temu zespół nie ocenia prezentacji na podstawie wrażenia, tylko na podstawie tego, co zobaczył.
| Problem dziś | Oczekiwany rezultat | Jak sprawdzimy? | Ważność |
|---|---|---|---|
| HR ręcznie sprawdza status onboardingu | Status zadań jest widoczny bez dopytywania | Zmiana terminu startu i sprawdzenie zadań HR, IT i menedżera | Konieczne |
| Wnioski trafiają do niewłaściwej osoby podczas nieobecności menedżera | Proces ma obsługę zastępstwa | Nieobecny przełożony i nowy wniosek pracownika | Konieczne |
| Raport powstaje z kilku plików | Potrzebne dane można uzyskać w jednym zestawieniu | Przygotowanie konkretnego raportu na danych testowych | Ważne |
Taka karta ma jeszcze jedną zaletę: pozwala odróżnić wymagania konieczne od rzeczy atrakcyjnych na prezentacji. Jeżeli dostawca pokaże świetny moduł, którego nie planowaliście używać przez najbliższy rok, nie powinien on przykrywać braku funkcji kluczowej dla codziennego procesu.
Nie porównuj systemów jedną oceną
Jedna liczba typu „8,4/10” wygląda obiektywnie, ale potrafi ukryć najważniejszy problem. System może dostać wysoką średnią dzięki wielu dodatkom, a jednocześnie nie obsługiwać procesu, bez którego organizacja nie chce ruszyć.
Rozdzieliłbym ocenę na trzy grupy:
Po każdym demo zaznacz, co zostało faktycznie pokazane, co wymaga konfiguracji, co jest dostępne dopiero w innym planie, a co pozostało deklaracją. Te cztery odpowiedzi nie są równoważne.
Jak poprowadzić demo, żeby coś z niego wynikało?
Nie wysyłałbym dostawcy wyłącznie listy funkcji. Wysłałbym dwa lub trzy scenariusze i poprosił o pokazanie ich od początku do końca. Jeżeli możliwe, niech przez część procesu przejdzie osoba, która później będzie z systemu korzystać.
Prosty układ 60-minutowego demo
- 10 minut: kontekst firmy, użytkownicy i trzy najważniejsze problemy.
- 35 minut: przejście przez ustalone scenariusze, razem z wyjątkiem lub korektą.
- 10 minut: integracje, zakres wdrożenia i prace po stronie klienta.
- 5 minut: lista tematów niepokazanych i sposób ich potwierdzenia.
Jeżeli prezentacja zaczyna zmieniać się w wycieczkę po menu, wróć do scenariusza. Celem nie jest poznanie całego produktu. Celem jest sprawdzenie, czy rozwiązanie obsłuży Waszą pracę i czy zespół będzie potrafił później tę konfigurację utrzymać.
Co zrobić po ostatnim demo?
Nie podejmowałbym decyzji od razu po spotkaniu. Najpierw zamknij otwarte pytania i doprowadź wszystkie oferty do porównywalnego zakresu. Jeżeli jeden dostawca wycenił trzy moduły, a drugi sześć, porównywanie samej kwoty nie odpowiada na pytanie, która oferta jest korzystniejsza.
Na koniec przygotuj krótką rekomendację: czego potrzebujemy, które rozwiązania spełniają warunki konieczne, jakie ograniczenia akceptujemy i jakie prace zostają po naszej stronie. Taki dokument jest dużo bardziej użyteczny dla osoby zatwierdzającej budżet niż kilkadziesiąt notatek z prezentacji.
