W firmie doradczej produktem jest czas ludzi, więc obsadzanie projektów to nie administracja, tylko serce biznesu. Każda godzina niewłaściwie przypisanego konsultanta to albo przepalona marża, albo projekt po terminie. Gdy zespół rośnie powyżej kilkudziesięciu osób, arkusz i pamięć resourcing managera przestają nadążać, a decyzje o obsadzie zapadają zbyt wolno i po omacku.
Z naszego doświadczenia to moment na własny system obsadzania projektów i zarządzania dostępnością, a nie kolejne pudełkowe narzędzie, które nie zna pojęć firmy professional services: harmonogram zadań to nie to samo co obsadzanie ludzi na role, a kalendarz urlopów nie mówi nic o marży. Nie mamy case study dokładnie w tym obszarze, ale mamy inżynierów, którzy budowali narzędzia planistyczne, rejestry zasobów i integracje z HR i sprzedażą. W modelu wzmocnienia zespołu lub zespołu dedykowanego wstawiamy te kompetencje tam, gdzie ich brakuje, i traktujemy system jako oprogramowanie dedykowane utrzymywane latami, bo tylko szyte na miarę uwzględni wasze modele rozliczeń (time & materials, fixed price, retainer), poziomy senioralności i stawki.
Czym jest rejestr kompetencji i dostępności konsultantów?
To fundament systemu, czyli jedno źródło prawdy o tym, kim dysponujecie i kiedy. Bez wiarygodnego rejestru każda prognoza i alokacja stoi na piasku. Budujemy go tak, żeby trzymał kilka warstw danych naraz:
- profil kompetencji (technologie, certyfikaty, branże, języki, role projektowe),
- poziom biegłości i potwierdzone doświadczenie, nie tylko deklaracje,
- dostępność w czasie z alokacjami, urlopami i rezerwacjami wstępnymi,
- ograniczenia takie jak lokalizacja, gotowość do podróży czy klauzule konkurencji.
Kluczowe jest to, żeby dane były żywe, a nie archiwalne. Dlatego spinamy rejestr z systemami, w których te informacje już powstają, zamiast kazać ludziom wypełniać kolejny arkusz.
Jak zbudować narzędzie do obsadzania i alokacji zespołów?
Obsadzanie to problem dopasowania: po jednej stronie zapotrzebowanie projektu, po drugiej dostępni ludzie z odpowiednimi kompetencjami, a dobre narzędzie skraca drogę od pytania „kto może wejść na ten projekt” do decyzji z godzin do minut. Projektujemy przede wszystkim przejrzysty widok alokacji na osi czasu, gdzie widać, kto jest wolny, kto kończy projekt w przyszłym tygodniu, a kto jest przebukowany. Dokładamy miękkie i twarde rezerwacje, żeby odróżnić obsadę potwierdzoną od planowanej pod ofertę, która nie jest jeszcze podpisana. Automatyzujemy też podpowiedzi dopasowania: system proponuje kandydatów na rolę po kompetencjach, dostępności i stawce, a człowiek decyduje. Nie udajemy, że obsada jest w pełni algorytmiczna, bo liczy się też relacja z klientem i ścieżka rozwoju konsultanta, dlatego budujemy je jako wsparcie decyzji, a nie automat.
Jak zaplanować wykorzystanie (utilisation) konsultantów?
Wykorzystanie to miara, na którą patrzy zarząd, bo pokazuje, jaka część opłacanego czasu zespołu generuje przychód. Problem w tym, że utilisation liczony po fakcie jest spóźniony o cały kwartał, a decyzje trzeba podejmować wcześniej. Budujemy planowanie tak, żeby patrzyło do przodu:
- utilisation planowany wynikający z obecnych alokacji i rezerwacji,
- utilisation docelowy per rola, linia biznesowa albo poziom senioralności,
- wczesne alerty o ludziach schodzących poniżej lub wchodzących powyżej progu,
- rozróżnienie czasu rozliczalnego od inwestycyjnego (rozwój, przedsprzedaż, inicjatywy wewnętrzne).
Dbamy przy tym, żeby dashboard tłumaczył metrykę, a nie tylko ją pokazywał, bo 85 procent utilisation znaczy co innego dla architekta, a co innego dla juniora na ławce przed dużym kontraktem.
Jak zintegrować system obsadzania z pipeline’em rekrutacyjnym?
Obsadzanie i rekrutacja to dwie strony tej samej luki kompetencyjnej. Jeśli system widzi, że za sześć tygodni zabraknie dwóch seniorów w danej technologii, ta informacja powinna trafiać do rekrutacji automatycznie, a nie po fakcie na statusie. Dlatego spinamy narzędzie z pipeline’em rekrutacyjnym, żeby:
- braki kompetencyjne z planowania stawały się zapotrzebowaniem rekrutacyjnym,
- kandydaci w procesie byli widoczni jako przyszła, warunkowa dostępność,
- data gotowości nowej osoby zasilała prognozy obłożenia,
- decyzja build vs buy (rekrutować, przesunąć wewnętrznie czy sięgnąć po body leasing) opierała się na tych samych danych.
Integrację robimy przez API istniejącego ATS, bez przepisywania go od nowa, żeby jedna luka nie była liczona w trzech miejscach inaczej.
Jak prognozować obłożenie względem pipeline’u sprzedaży?
Sprzedaż obiecuje klientom terminy, a delivery musi je obsadzić ludźmi. Bez wspólnego widoku sprzedaż sprzedaje zespół, którego nie ma, albo firma trzyma ludzi na ławce, bo nie wie, co nadchodzi. Budujemy prognozę, która nakłada pipeline sprzedaży na dostępność zespołu: szanse wnosimy do planowania wraz z prawdopodobieństwem i zapotrzebowaniem na role, więc system pokazuje nie jeden scenariusz, tylko widełki, co stanie się z obłożeniem przy domknięciu 30, 50 albo 80 procent pipeline’u. Nie obiecujemy magicznej dokładności, bo dane sprzedażowe bywają optymistyczne, dlatego narzędzie pokazuje założenia, a nie ukrywa je w jednej liczbie.
Jak rozwiązywać konflikty alokacji i testować scenariusze?
Konflikt alokacji to codzienność: ta sama osoba jest potrzebna na dwóch projektach, klient przesuwa start, kluczowy konsultant idzie na dłuższy urlop. Dobry system nie udaje, że konfliktów nie ma, tylko pokazuje je wcześnie i podpowiada wyjścia:
- wykrywanie nakładających się rezerwacji i przekroczeń dostępności w czasie rzeczywistym,
- scenariusze „co jeśli”, czyli skutki przesunięcia osoby bez naruszania danych produkcyjnych,
- widok wpływu, który projekt ucierpi, jeśli zdejmiecie z niego konkretną osobę,
- ślad decyzji, kto i dlaczego zmienił obsadę.
Scenariusze są tu najważniejsze: resourcing manager rozgrywa warianty na piaskownicy i dopiero najlepszy przenosi do planu, zamiast testować zmiany na żywych projektach.
Jakie kompetencje dostarczamy do takiego projektu?
Dobieramy skład pod konkretny system, a nie „na zapas”. Budowa narzędzia resourcingowego to projekt na styku logiki biznesowej, danych i integracji, więc zespół łączy kilka kompetencji:
- architekt i backend developer projektujący model danych dostępności, kompetencji i alokacji,
- frontend developer odpowiadający za czytelne osie czasu i dashboardy wykorzystania,
- specjalista od integracji spinający system z HR, ATS i CRM przez API,
- analityk lub product owner przekładający reguły obsady i rozliczeń na wymagania.
Tam, gdzie wchodzi warstwa prognoz i podpowiedzi dopasowania, dokładamy kompetencje z obszaru danych i AI (modele predykcyjne, scoring kandydatów na rolę). To realna kompetencja naszej grupy, którą wpinamy tam, gdzie daje wartość, a nie dla samego hasła.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, w modelu, który pasuje do waszej sytuacji. Budujemy system jako oprogramowanie dedykowane rozwijane przez nasz zespół, kiedy startujecie od zera, albo wzmacniamy wasz zespół o brakujące role, kiedy narzędzie powstaje wewnętrznie. Kompetencje weryfikujemy przed startem, skład dobieramy pod specyfikę systemu, a dzięki zbliżonej strefie czasowej wchodzimy w wasze przeglądy kodu i spotkania bez długiego rozruchu. Nawet bez case study dokładnie z tego obszaru dostarczamy ludzi, którzy budowali narzędzia planistyczne i integracje danych. To sedno naszej oferty: kompetencja, którą realnie obsadzacie, a nie obietnica.
Od czego zacząć budowę systemu obsadzania?
Zacznij od jednego, najboleśniejszego pytania, na które dziś nie umiecie szybko odpowiedzieć, na przykład „kto jest wolny za trzy tygodnie i ma kompetencje pod ten projekt”. Ono wyznaczy, jaki rejestr danych zbudować najpierw i jakie integracje są naprawdę konieczne na start. Lepiej dowieźć jeden działający przepływ (rejestr plus widok alokacji) i rozbudowywać go o prognozy i scenariusze, niż projektować wszystko naraz. Różnice między budową dedykowaną, wzmocnieniem zespołu a usługą zarządzaną opisaliśmy w artykule o modelach współpracy IT.
Budujesz system obsadzania projektów albo zarządzania dostępnością konsultantów? Porozmawiajmy, dobierzemy zespół i architekturę pod wasz model delivery.