W firmie doradczej pieniądze robią się na poziomie pojedynczego zlecenia, a nie rocznego sprawozdania. Partner zwykle intuicyjnie wie, które projekty ciągną wynik, a które go zjadają, tylko że ta wiedza siedzi w głowach i w arkuszach, a nie w jednym, spójnym widoku. Dlatego analityka w firmie doradczej zaczyna się nie od wykresów, lecz od pytania: czy w ogóle wiemy, ile naprawdę kosztuje i ile zarabia konkretne zaangażowanie.
Z naszego doświadczenia najtrudniejsze nie jest narysowanie dashboardu, tylko doprowadzenie danych o projektach, ludziach i kontraktach do stanu, w którym liczby się zgadzają. Nie mamy w tej sprawie gotowego case study do pokazania, ale mamy to, co w takim projekcie liczy się najbardziej: inżynierów danych, architektów BI i specjalistów ML, których wstawiamy do zespołu klienta, żeby ten fundament powstał i był utrzymywany.
Dlaczego firmie doradczej potrzebna jest własna analityka projektów?
Bo model biznesowy consultingu jest wrażliwy na kilka zmiennych naraz: stawkę, wykorzystanie konsultantów (utilisation), realizację budżetu godzin i rozpoznanie przychodu w czasie. Wystarczy, że jedna z nich zjedzie, a marża na projekcie znika, często zanim ktokolwiek to zauważy w comiesięcznym zamknięciu.
Standardowe systemy tego nie pokazują w całości. ERP zna faktury, time tracking zna godziny, CRM zna pipeline, a HR zna koszty ludzi, tylko że żaden z nich nie łączy tego w obraz rentowności jednego zaangażowania. Własna warstwa analityczna to miejsce, w którym te światy się spotykają, a partner zarządzający przestaje rządzić na wyczucie.
Jak zaprojektować hurtownię danych o projektach doradczych?
Fundamentem jest model danych, który opisuje, jak firma doradcza faktycznie pracuje, a nie jak wygląda w teorii. Zwykle budujemy go wokół kilku kluczowych encji:
- projekt / zaangażowanie jako centralna jednostka z typem kontraktu (fixed price, time & material, retainer),
- konsultant i rola z kosztem, stawką sprzedażową i dostępnością,
- rejestr czasu (timesheet) spięty z projektem i zadaniem,
- kontrakt i budżet z planowanym przychodem i kosztem,
- klient i branża dla analiz portfelowych i benchmarkingu.
Na tym stawiamy klasyczny model wymiarowy (fakty i wymiary), bo pozwala liczyć te same miary w różnych przekrojach, od pojedynczego konsultanta po całą linię biznesową, bez przepisywania logiki przy każdym nowym pytaniu.
Jak zbudować dashboardy marży i wykorzystania?
To serce rozwiązania, bo tu codziennie patrzą COO i partnerzy. Dashboard rentowności i wykorzystania powinien odpowiadać na pytania operacyjne szybciej, niż zajęłoby zebranie tego ręcznie:
- marża na projekcie i na kliencie, z podziałem na planowaną i zrealizowaną,
- utilisation per konsultant, zespół i praktyka, z rozróżnieniem godzin billable i non-billable,
- spalanie budżetu godzin i kosztu względem harmonogramu (podobne do metryki burn/EAC),
- realizacja stawki (effective rate) kontra stawka z cennika,
- rozpoznanie przychodu i praca w toku (WIP) na projektach rozliczanych etapami.
Kluczowe jest, żeby te miary były policzone raz, w jednym miejscu, z jedną definicją. Inaczej dwa działy przyniosą na spotkanie dwie różne marże i dyskusja zejdzie na to, czyj Excel jest prawdziwy.
Jak stworzyć biblioteki benchmarków i estymat?
Benchmarking to moment, w którym dane z przeszłości zaczynają zarabiać w przyszłych ofertach. Z historii projektów budujemy biblioteki benchmarków i estymat, czyli uporządkowaną wiedzę o tym, ile faktycznie zajmują i kosztują powtarzalne typy prac.
W praktyce oznacza to parametryzację projektów po typie, branży, wielkości i składzie zespołu, a potem liczenie rozkładów rzeczywistych nakładów względem pierwotnych estymat. Zespół sprzedaży przestaje wyceniać „na czucie”, a nowy manager dostaje punkt odniesienia zamiast czystej kartki. To także najuczciwszy sposób, żeby nazwać projekty, które systematycznie się nie domykają, i zrozumieć, dlaczego.
Jak prognozować pipeline i moce przerobowe?
Firma doradcza sprzedaje czas ludzi, więc prognozowanie pipeline i mocy przerobowych to w istocie dopasowywanie dwóch krzywych: popytu z pipeline’u i podaży z grafików zespołu. Jeśli patrzy się na nie osobno, zawsze jest albo przegrzanie, albo ławka.
Łączymy więc ważony pipeline z CRM z planowaną alokacją i dostępnością konsultantów, żeby pokazać przyszłe luki i nadwyżki mocy z wyprzedzeniem tygodni czy miesięcy. Taki widok zmienia rozmowy zarządu z reaktywnych na planujące: zamiast gasić pożar braku ludzi w przyszłym kwartale, można wcześniej uruchomić rekrutację, przesunąć zespół albo świadomie wyhamować sprzedaż w przeciążonym obszarze.
Jak zadbać o jakość i spójność danych źródłowych?
Najpiękniejszy dashboard przegrywa z jednym źle przypisanym timesheetem, dlatego jakość i spójność danych źródłowych traktujemy jako osobny element projektu, a nie dodatek. Typowe problemy są przewidywalne:
- godziny księgowane z opóźnieniem albo na zły projekt,
- różne definicje tego samego pojęcia (co liczymy jako billable) w działach,
- rozjazd między kontraktem w CRM a rzeczywistym zakresem prac,
- braki w danych kosztowych konsultantów i podwykonawców.
Dlatego budujemy walidacje i testy danych w pipeline’ach ładowania, alerty o brakach oraz jasny słownik miar. Nie chodzi o idealne dane od pierwszego dnia, tylko o to, żeby błędy były widoczne i naprawiane u źródła, zanim trafią na ekran partnera.
Kiedy warto sięgnąć po prognozy z ML?
Wtedy, gdy klasyczne reguły i średnie przestają wystarczać, a danych historycznych jest już na tyle dużo, że widać w nich wzorce. Prognozy z ML nie zastępują dashboardów, tylko dokładają warstwę przewidywania tam, gdzie człowiek nie przeliczy wszystkich zależności.
W consultingu najczęściej ma to sens przy prognozie prawdopodobieństwa domknięcia szansy w pipeline, predykcji przekroczenia budżetu projektu na podstawie wczesnych sygnałów oraz prognozie wykorzystania zespołów w kolejnych okresach. To realna kompetencja, którą dostarczamy, choć uczciwie zaznaczamy: ML ma sens dopiero na uporządkowanych danych, więc zwykle jest kolejnym etapem, a nie pierwszym.
Jakie kompetencje dostarczamy do takiego projektu?
Skład dobieramy pod konkretny zakres pracy, a nie „na zapas”. W projektach analityki dla firm profesjonalnych zwykle są to:
- inżynier danych budujący pipeline’y i hurtownię (ELT/ETL, modelowanie),
- architekt BI / analityk odpowiadający za model miar i warstwę dashboardów,
- inżynier analityczny (analytics engineer) pilnujący definicji i transformacji,
- specjalista ML tam, gdzie wchodzą prognozy,
- DevOps / platforma danych dla wdrożeń, bezpieczeństwa i utrzymania.
Taki układ pozwala przejąć realną odpowiedzialność za warstwę danych, a nie tylko dostarczyć pojedynczy raport i zniknąć.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, który wstawia do projektu kompetencje data, BI i ML, nawet jeśli to Twój zespół nadaje kierunek:
- wzmacniamy zespół konkretnymi specjalistami, których umiejętności weryfikujemy przed startem,
- projektujemy model danych firmy doradczej, zanim powstanie pierwszy wykres,
- spinamy źródła (ERP, time tracking, CRM, HR) w jedną, utrzymywalną hurtownię,
- warstwę ML dokładamy dopiero tam, gdzie dane są na to gotowe, bez obietnic bez pokrycia.
Nie udajemy, że mamy w tym obszarze gotowe wdrożenie do pokazania; dajemy ludzi i podejście, dzięki którym takie wdrożenie u Ciebie powstaje i zostaje utrzymane.
Od czego zacząć budowę analityki projektów doradczych?
Zacznij od jednej decyzji, którą chcesz podejmować lepiej, na przykład „czy przyjąć ten projekt przy tym składzie”, i od pytania, jakie dane są do tego potrzebne. To wyznacza zakres pierwszej iteracji hurtowni, zestaw miar i role, których potrzebujesz. Lepiej mieć jeden wiarygodny dashboard marży niż dziesięć, którym nikt nie ufa. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Budujesz analitykę i benchmarking projektów doradczych? Porozmawiajmy, dobierzemy zespół data/BI/ML i architekturę pod Twoją firmę.