Skalowalne przepływy pracy

01Konfigurowalne etapy lejka rekrutacyjnego dla każdej oferty

Domyślny lejek rekrutacyjny obejmuje siedem etapów — nowa aplikacja, selekcja, lista kandydatów, rozmowa kwalifikacyjna, oferta, zatrudniony, odrzucony — ale nie jest to stały układ globalny. Każda oferta pracy może definiować własną sekwencję etapów, więc rekrutacja masowa w handlu detalicznym może zawierać dodatkowe etapy selekcji, podczas gdy rekrutacja na stanowisko kierownicze może zostać ograniczona tylko do etapów: aplikacja, rozmowa i oferta. Konfiguracja znajduje się bezpośrednio w ofercie pracy, a nie na oddzielnej stronie ustawień niezwiązanej z konkretną rolą.

02Role-based permissions

Cztery role — właściciel, administrator, rekruter i menedżer ds. rekrutacji — mają celowo zróżnicowany zakres widoczności i uprawnień w systemie. Menedżer ds. rekrutacji może przesuwać kandydatów i dodawać opinie dotyczące prowadzonych przez siebie rekrutacji bez konieczności posiadania dostępu administracyjnego do rozliczeń czy zarządzania zespołem; rekruterzy zarządzają swoimi procesami bez możliwości zmiany ustawień całej organizacji. Zyskuje to na znaczeniu wraz z rozwojem zespołu, gdy pełny dostęp dla wszystkich przestaje być uzasadniony.

03Operacje masowe na dużą skalę

Indywidualna ocena każdego kandydata w procesie rekrutacyjnym nie sprawdza się przy liczbie większej niż kilku aplikujących. Pojedyncza akcja ponownie ocenia wszystkie nieocenione aplikacje na dane stanowisko w jednym przebiegu, z uwzględnieniem miesięcznego limitu kredytów inteligentnego oceniania organizacji oraz z możliwością bezproblemowego wznowienia w razie przerwania — przydatne w przypadku stanowiska, na które przez weekend wpłynęło dwieście aplikacji i które wymaga uszeregowanej listy kandydatów na poniedziałek rano.

Masowe tworzenie kandydatów i ofert pracy opiera się na tej samej filozofii: z pojedynczego pliku CSV można utworzyć do 100 ofert pracy, a kandydatów można dodawać masowo za pomocą pliku CSV, wklejonej tablicy JSON lub przeciągając pakiet plików CV, z których każdy jest automatycznie parsowany i dodawany do bazy talentów. Żadna z tych masowych ścieżek nie omija reguł walidacji i deduplikacji stosowanych w pojedynczych formularzach — zduplikowany adres e-mail w masowym imporcie CSV jest pomijany dokładnie tak samo, jak przy ręcznym wpisie.

04Co pozostaje bez zmian wraz ze wzrostem wolumenu

Podstawowa metodologia oceny, ścieżka audytu przy każdej aplikacji oraz model uprawnień działają dokładnie tak samo przy 10 aplikacjach, jak i przy 10 000 — nie ma osobnego „trybu korporacyjnego” z odmiennymi gwarancjami. Skalowaniu podlega liczba stanowisk w danym planie, limit aktywnych ogłoszeń oraz miesięczny pakiet kredytów na inteligentną ocenę, a nie wewnętrzne mechanizmy punktacji czy uprawnień.

05Co zazwyczaj zawodzi w pierwszej kolejności w miarę rozwoju zespołu rekrutacyjnego

Zespoły przechodzące od kilku rekruterów do większego działu pozyskiwania talentów zwykle napotykają te same punkty tarcia, niezależnie od używanych narzędzi. Widoczność procesu jest pierwszym z nich: gdy więcej niż dwie lub trzy osoby przesuwają kandydatów w procesie tej samej oferty, ktoś nieuchronnie pyta: „chwila, kto przeniósł tego kandydata i kiedy” — dlatego każda zmiana etapu jest domyślnie oznaczana znacznikiem czasu i przypisywana do użytkownika, a nie dodawana jako opcjonalna funkcja audytu na późniejszym etapie.

Niespójna ocena dokonywana przez różnych rekruterów to druga kwestia, ściśle powiązana z problemem rozbieżności opisanym na stronie dotyczącej rekrutacji ustrukturyzowanej — dwóch rekruterów weryfikujących kandydatów na to samo stanowisko według nieco innych kryteriów tworzy proces, który pozornie wygląda spójnie (te same etapy, ta sama tablica), lecz w rzeczywistości stosuje odmienne standardy. Trzecim wyzwaniem jest niekontrolowane rozszerzanie uprawnień: wraz z rozwojem zespołu przejście od podejścia „wszyscy mają pełny dostęp, bo tak było prościej, gdy pracowaliśmy w trzy osoby” do „potrzebujemy uprawnień opartych na rolach” następuje zazwyczaj nagle — najczęściej tuż po incydencie związanym z dostępem, a nie z wyprzedzeniem. Dlatego model uprawnień oparty na rolach jest dostępny od samego początku, a nie jako opcja rozbudowy, o której skonfigurowaniu rosnący zespół musi pamiętać w późniejszym czasie.