Czym różni się firma usługowa od produkcyjnej w oczach ERP
W klasycznym ERP dla produkcji głównym „bohaterem” jest materiał, technologia i magazyn. W firmie usługowej centrum wszechświata to czas pracy ludzi, ich kompetencje i projekty. Ten sam system ERP może wyglądać zupełnie inaczej, jeśli w jednym przypadku zarządza produkcją mebli, a w drugim – pracą konsultantów czy programistów.
Firma usługowa ma kilka cech, które mocno wpływają na wymagania wobec ERP:
Brak fizycznego produktu – nie ma czego „policzyć na palecie”, jest za to mnóstwo godzin, zadań i spotkań.
Elastyczny zakres prac – zakres projektu często zmienia się w trakcie, klient dodaje zadania, przesuwa priorytety.
Wysoka rola kompetencji – stawka godzinowa i czas realizacji zależą od konkretnych ludzi i ich doświadczenia.
Silne powiązanie pracy z rozliczeniami – sposób raportowania czasu bezpośrednio wpływa na faktury i rentowność.
Jeśli ERP ma wspierać taką organizację, sam moduł sprzedaży i księgowości jest po prostu za krótki. Potrzebny jest spójny model projektów, zleceń, zadań i czasu pracy, który odzwierciedli to, jak faktycznie pracuje zespół. System musi „rozumieć”, że jeden pracownik może tego samego dnia:
pracować 3 godziny nad projektem A dla klienta X,
2 godziny nad wewnętrznym projektem rozwojowym,
1 godzinę na spotkaniu sprzedażowym z potencjalnym klientem,
i jeszcze obsłużyć kilka krótkich ticketów serwisowych.
Jeżeli ERP potrafi taką mozaikę poprawnie zarejestrować i połączyć z rozliczeniami, staje się realnym narzędziem zarządzania. Jeśli nie – pozostaje drogą księgowo-fakturową „skorupą”, a reszta życia firmy toczy się w arkuszach Excel, JIRA, Asanie, notatnikach i mailach.
Procesy kluczowe: od pozyskania zlecenia do rozliczenia
Trzon każdej firmy usługowej to kilka powtarzalnych procesów. ERP musi je objąć w całości, a nie tylko „przeciąć” w miejscu fakturowania. Typowa ścieżka wygląda tak:
Pozyskanie zlecenia – lead pojawia się w CRM, handlowiec rozmawia z klientem, powstaje koncepcja projektu.
Oferta i wycena – definiowany jest szacowany zakres, model rozliczeń (fixed price, time&material, retainer) i budżet.
Akceptacja i start projektu – pojawia się formalne zlecenie, umowa, projekt w ERP (i często w narzędziu do zadań).
Planowanie i realizacja – rozbicie na etapy, zadania, przydzielenie ludzi, raportowanie czasu i postępu.
Kontrola budżetu i zmian zakresu – porównywanie planu do wykonania, akceptacja dodatkowych prac.
Rozliczenie i fakturowanie – na koniec miesiąca albo etapu projektowego powstają faktury w oparciu o dane z ERP.
Analiza rentowności – po projekcie patrzymy, co wyszło dobrze, a gdzie „uciekły” godziny i marża.
Każdy z tych kroków generuje dane, które można albo wykorzystać, albo zgubić po drodze. W dobrze wdrożonym ERP obieg wygląda następująco:
dane z CRM i ofertowania automatycznie zasilają kartotekę projektu,
harmonogram i budżet zamieniają się w zadania, etapy i limity godzin,
timesheety pracowników wpadają na odpowiednie projekty i zadania,
fakturowanie korzysta z tych samych danych, które widzi kierownik projektu i controlling.
Gdy ERP tego nie spina, zaczynają się ręczne przepisywania, niespójne dane, a na końcu – dyskusje, dlaczego klient dostał inną fakturę niż się spodziewał.
Modele działalności usługowej i ich wpływ na ERP
Pod pojęciem „firma usługowa” kryje się wiele różnych działalności. Procesowo wyglądają one podobnie, ale szczegóły są kluczowe dla konfiguracji ERP:
Software house / IT – projekty długoterminowe, częste zmiany zakresu, praca zespołowa, narzędzia typu JIRA, GitLab. Tu ERP musi dobrze „dogadać się” z systemem do zadań i kodu, inaczej timesheety będą oderwane od rzeczywistości.
Agencja marketingowa – miks projektów kampanijnych i stałych obsług (retainer). Istotne są kalendarze publikacji, akceptacje materiałów, praca kreatywna trudna do wyceny godzinowej.
Kancelaria prawna, biuro rachunkowe – dużo drobnych spraw/klientów, powtarzalne czynności, abonamenty i ryczałty. Kluczowa jest ewidencja czasu per klient i per sprawa oraz rozliczanie w ramach abonamentu.
Doradztwo biznesowe – projekty konsultingowe, warsztaty, analizy. Często fixed price z limitem dni, duża rola kosztów delegacji, podróży, materiałów.
Serwis techniczny, utrzymanie – zlecenia wyjazdowe, zgłoszenia serwisowe, SLA, priorytety. W centrum stoą ticket, zgłoszenie i czas reakcji, nie tylko sam projekt.
W każdym z tych modeli inaczej zdefiniujesz pojęcia projektu, zlecenia, zadania i ticketu. To pierwsza decyzja, którą trzeba świadomie podjąć na etapie wdrożenia ERP, bo późniejsza zmiana jest bardzo bolesna (przenoszenie danych historycznych, raportów, integracji).
Wspólny mianownik jest taki: ERP dla firmy usługowej musi „czuć” projekty i czas pracy tak samo, jak zarząd i liderzy zespołów. Bez tego system będzie przeciągał firmę w kierunku swojego modelu, zamiast wspierać istniejące (i często sensowne) praktyki.
Źródło: Pexels | Autor: Vlada Karpovich
Analiza przedwdrożeniowa pod kątem projektów i czasu pracy
Zbieranie wymagań: nie od modułów, tylko od procesów
Najczęstsza pułapka analizy przedwdrożeniowej w usługach to rozmowa w stylu: „Co chcecie w module sprzedaży? A co w module projektów? A co w księgowości?”. Efekt bywa taki, że każdy dział przedstawia swoją listę życzeń, a nikt nie spina tego w jeden ciągły proces. Potem okazuje się, że oferta, projekt i faktura „nie widzą się” nawzajem.
Dużo lepsze podejście to warsztaty procesowe typu „dzień z życia projektu”. Zamiast pytać o funkcje, przechodzi się krok po kroku:
Jak pojawia się lead i kto go wprowadza?
Jak powstaje oferta i gdzie jest przechowywana?
Co się dzieje po akceptacji oferty – kto zakłada projekt, gdzie, na podstawie jakich danych?
Jak są planowane zadania i przydzielani ludzie?
Gdzie i jak pracownicy raportują czas?
Jak kierownik projektu sprawdza budżet i decyduje o dodatkowych pracach?
W jaki sposób rozliczacie projekt – etapami, co miesiąc, na koniec?
Podczas takiego warsztatu bardzo szybko wychodzą na jaw niespójności, na przykład:
handlowiec wycenia projekt w Excelu,
kierownik projektu zakłada go samodzielnie w narzędziu do zadań, bez powiązania z ofertą,
czas pracy jest raportowany w trzech różnych aplikacjach,
a księgowość dostaje jedynie „sumę godzin na fakturę” mailem.
Dopiero gdy taki obraz jest na stole, można zacząć przekładać go na ERP: co będzie w module projektów, co w CRM, co w integracji z JIRA, a co pozostanie poza systemem (świadomie, a nie z przyzwyczajenia).
Zespoły i role w analizie (biznes, finanse, operacje, HR)
W firmie usługowej wdrożenie ERP, które dotyka projektów, czasu pracy i rozliczeń, nie może być „projektem IT”. To zmiana sposobu pracy całej organizacji. W analizie muszą uczestniczyć różne perspektywy:
Biznes / sprzedaż – jak sprzedajemy projekty, jak je wyceniamy, jakie obietnice składamy klientom.
Operacje / delivery – jak naprawdę prowadzimy projekty, jakie są niewygodne skróty, gdzie brakuje informacji.
Finanse / controlling – jak mierzymy rentowność, jakie raporty są potrzebne, jak wygląda budżetowanie.
HR / kadry – jak rozliczamy czas pracy, nadgodziny, urlopy, premie powiązane z projektami.
IT / administratorzy systemu – co da się zintegrować, jak, z jakimi ograniczeniami.
Jeśli zabraknie któregoś z tych głosów, system będzie kulał. Klasyczny przykład: ERP skonfigurowany „pod controlling”, w którym rejestracja czasu jest bardzo szczegółowa, ale tak uciążliwa, że pracownicy jej nie przestrzegają. Na papierze – perfekcyjna analityka, w praktyce – dane fikcyjne.
Dobrze działającym modelem jest komitet sterujący (zarząd + liderzy kluczowych obszarów) oraz zespół roboczy złożony z przedstawicieli działów. Komitet podejmuje decyzje o zasadach (np. jaki model ewidencji czasu przyjmujemy), zespół roboczy dopracowuje szczegóły (np. listę typów aktywności w timesheetach).
Identyfikacja miejsc, gdzie powstaje i ginie informacja o czasie pracy
W usługach czas pracy to „paliwo” firmy. Problem w tym, że informacja o nim często jest rozproszona po wielu narzędziach i przyzwyczajeniach ludzi. Przed wdrożeniem ERP warto dosłownie narysować mapę: gdzie dziś powstaje informacja o czasie pracy, a gdzie się gubi.
Źródła danych zwykle obejmują:
kalendarze (Outlook, Google Calendar) – spotkania z klientami, warsztaty, szkolenia,
narzędzia do zadań (JIRA, Asana, Trello, Monday) – czas przy zadaniach, ticketach, sprintach,
systemy RCP / kadrowe – wejścia/wyjścia, urlopy, nieobecności,
arkusze Excel – ręczne zestawienia czasu pracy, ewidencje projektowe,
maile i komunikatory – ustalenia „na szybko”, które nigdzie nie są wpisywane.
Trzeba zadać kilka prostych, ale bardzo konkretnych pytań:
Które z tych danych naprawdę są potrzebne do rozliczeń z klientem?
Które dane są potrzebne do analiz wewnętrznych (rentowność, obciążenie zespołu)?
Gdzie dziś czas pracy jest dublowany (np. wpisywany i w JIRA, i w Excelu)?
Gdzie jest luka – czyli czas, który nigdzie nie jest rejestrowany, a powinien?
Na tej podstawie można podjąć decyzję, które źródła zostają źródłem prawdy (np. JIRA dla IT), które będą zasilane z ERP, a które odchodzą w przeszłość. To moment, kiedy okazuje się, że część narzędzi jest używana tylko dlatego, że ERP „tego nie umiał” – po wdrożeniu nowej wersji te narzędzia mogę zostać uproszczone lub wycofane.
Spisanie wymagań: priorytety i zdrowy minimalizm
Z warsztatów procesowych i analizy źródeł czasu pracy powstaje długa lista oczekiwań. Żeby ERP dało się wdrożyć w rozsądnym czasie, trzeba te oczekiwania uporządkować. Najpraktyczniejszy podział to:
MVP (minimum viable product) – absolutne minimum, żeby projekty, czas pracy i rozliczenia mogły działać w jednym systemie.
Wymagania ważne, ale nie krytyczne – mogą wejść w drugim etapie, jeśli nie zdążą na start.
„Fajnie by było” – pomysły na później, po zdobyciu doświadczeń z pierwszych miesięcy pracy w ERP.
Przy projektach i czasie pracy MVP zwykle obejmuje:
rejestrację i podstawową klasyfikację projektów,
powiązanie projektów z umowami/ofertami i klientami,
prosty model budżetu czasowego i kosztowego,
ewidencję czasu pracy per projekt i pracownik,
zasady akceptacji i korekt czasu,
generowanie faktur na podstawie danych projektowych (przynajmniej dla wybranych modeli rozliczeń).
Resztę – zaawansowane analizy BI, rozbudowane workflow zmian zakresu, automatyczne generowanie aneksów do umów – lepiej zostawić na później. Pierwszy etap ma pozwolić firmie normalnie pracować, zdobyć dane i doświadczenia. Dopiero potem warto „doszlifowywać” szczegóły.
Przykład z praktyki: każdy dział inaczej liczy czas
W jednej z firm IT na etapie analizy okazało się, że:
programiści liczą czas w JIRA, ale wpisują tylko szacowane godziny na zadanie,
Przykład z praktyki: każdy dział inaczej liczy czas (ciąg dalszy historii)
W tej samej firmie IT sytuacja wyglądała jeszcze ciekawiej:
konsultanci wdrożeniowi mieli własne arkusze Excel, bo „w JIRA jest za mało kolumn na opis wyjazdu i diet”,
dział wsparcia wpisywał czas w system ticketowy, ale tylko na zgłoszenia płatne – resztę traktowano jako „koszt ogólny”,
menedżerowie średniego szczebla w ogóle nie raportowali czasu – ich praca „była w pensji”.
Dopiero wspólna mapa procesów i czasu pracy pokazała, że:
ci sami ludzie jednego dnia raportują w trzech systemach,
część pracy dla klientów ląduje w kosztach ogólnych, bo „nie ma gdzie tego przypiąć”,
księgowość nie ma szans zweryfikować, czy faktura „za 80 godzin” faktycznie ma pokrycie w timesheetach.
Wnioskiem nie było: „wrzućmy wszystko do ERP i zakażmy innych narzędzi”. Uzgodniono raczej, że ERP będzie centralnym rejestrem czasu na potrzeby rozliczeń i controllingu, a JIRA i system ticketowy pozostaną narzędziami operacyjnymi – z integracją, która przenosi podsumowania czasu na poziomie zadania/ticketu. Dzięki temu zespół nie musiał zmieniać nawyków, a finanse dostały spójny obraz projektów.
Model projektów w ERP – jak ustawić strukturę, żeby nie zwariować
Projekt, zlecenie, zadanie, ticket – słowniczek robiony „na własny użytek”
Pierwszy krok do sensownego modelu projektowego w ERP to uporządkowanie słownictwa dla tej konkretnej firmy. Nie ma jednego, uniwersalnego schematu. W jednej organizacji „projekt” będzie rocznym kontraktem ramowym, w innej – dwudniowym warsztatem.
Pomaga proste ćwiczenie: na tablicy wypisać najczęściej używane pojęcia (projekt, kontrakt, zlecenie, sprint, ticket, zadanie, podprojekt…) i obok każdego dopisać:
kto tego pojęcia używa (sprzedaż, delivery, finanse, wsparcie),
jak długo to „żyje” (dzień, tydzień, rok),
czy jest rozliczane z klientem, czy tylko wewnętrznie,
jakie decyzje na tym poziomie się podejmuje (budżet, ceny, priorytety).
Z tego rodzi się wspólna definicja: co w ERP nazwiemy projektem, co zleceniem, a co zadaniem. Często wychodzi, że:
„kontrakt” = projekt nadrzędny (ramowy),
„zlecenia” lub „epiki” = podprojekty / fazy,
„zadania” = szczegółowa praca operacyjna, która żyje w JIRA, Asanie itp., a w ERP widoczna jest tylko zagregowana (suma godzin).
Najważniejsze, żeby te definicje były spisane i zaakceptowane przez komitet sterujący. Bez tego po pół roku nikt nie będzie pewien, czy „projekt” w ERP to to samo, o czym mówi handlowiec z klientem.
Poziomy analityki: ile szczegółu naprawdę jest potrzebne
Drugie kluczowe pytanie: na jakim poziomie chcemy liczyć pieniądze i czas? Im głębsza struktura (projekty → podprojekty → zadania → aktywności), tym więcej kliknięć po stronie użytkowników i większe ryzyko błędów.
Dobrą praktyką jest wyjście od decyzji biznesowych i raportów, które mają być możliwe:
jeśli zarząd patrzy na rentowność na poziomie klienta i dużych kontraktów – projekty mogą być dość „grube”,
jeśli rozliczacie premie zespołów na poziomie linii biznesowych (np. wdrożenia vs utrzymanie) – wystarczy, że projekty będą tagowane linią,
jeśli rozliczacie konsultantów z realizacji targetu godzinowego na konkretnych typach prac – trzeba mieć rozbicie na kategorie czasu (np. development, analiza, wsparcie).
Praktycznie sprawdza się schemat:
Poziom 1: Projekt – to, co odpowiada umowie/kontraktowi,
Poziom 3: Typ aktywności – kategoria czasu (analiza, development, szkolenia, wsparcie, podróż).
Czas pracy raportowany jest do konkretnego projektu/etapu z wyborem typu aktywności. Szczegółowe zadania pozostają w narzędziach zespołowych. ERP widzi tyle, ile trzeba, by policzyć pieniądze i obciążenie zespołu – nie więcej.
Jak odwzorować różne modele usług w jednym modelu projektowym
Większe firmy usługowe rzadko działają w jednym modelu. Zwykle obok siebie są:
duże projekty fixed price,
małe zlecenia „Task Force” rozliczane godzinowo,
abonamentowe pakiety wsparcia,
projekty wewnętrzne (R&D, marketing, rozwój produktu).
Trzymanie dla każdego z tych obszarów osobnej logiki w ERP kończy się chaosem. Lepiej potraktować je jako warianty tego samego modelu projektowego i zróżnicować głównie:
typ projektu (wdrożeniowy, serwisowy, wewnętrzny),
model rozliczenia (fixed price, time & material, abonament, mieszany),
zasady budżetowania (budżet kwotowy, budżet godzinowy, limit dni/zgłoszeń).
W praktyce może to wyglądać tak:
projekt Wdrożenie ERP dla Klienta X – 3 etapy (analiza, wdrożenie, szkolenia), fixed price per etap, z kontrolą czasu do wewnętrznej rentowności,
projekt Serwis aplikacji Y – projekt typu serwis, budżetowana liczba godzin miesięcznie, rozliczany cyklicznie na podstawie faktycznego czasu,
projekt Rozwój produktu Z – projekt wewnętrzny, bez faktur, ale z pełną ewidencją czasu i kosztów, żeby wiedzieć, ile naprawdę kosztuje rozwój produktu.
ERP nie musi „znać” wszystkich niuansów umów. Powinien natomiast pozwolić ustawić dla projektu taki schemat, który da się konsekwentnie powtarzać, a nie wymaga każdorazowo „ręcznej gimnastyki” księgowości.
Minimalny zestaw pól w kartotece projektu
Karta projektu w ERP często jest przeciążona – każda komórka dodaje po 2–3 pola „bo mogą się kiedyś przydać”. Po kilku miesiącach połowa z nich jest pusta, a ludzie boją się wchodzić w zakładkę „Szczegóły”.
Dobrym punktem startu jest zdefiniowanie zestawu pól, które są konieczne do:
podpięcia projektu pod właściwego klienta i umowę,
przypisania odpowiedzialnych osób (kierownik, właściciel biznesowy),
podstawowej analizy (linia biznesowa, produkt, region).
Reszta – tagi marketingowe, szczegółowe informacje techniczne, długie opisy zakresu – lepiej trzymać w załącznikach lub w systemie do zarządzania zadaniami, a w ERP jedynie odwołać się referencją (np. numerem epika w JIRA). Im mniej obowiązkowych pól, tym większa szansa, że projekty będą zakładane szybko i poprawnie.
Źródło: Pexels | Autor: Yan Krukau
Ewidencja i kontrola czasu pracy w ERP (lub obok ERP)
Centralny rejestr czasu vs. narzędzia zespołowe
Spór „czy czas raportujemy w ERP, czy w JIRA/innym narzędziu” pojawia się niemal zawsze. Zamiast wybierać jedną stronę, lepiej zdefiniować system wiodący i zasady integracji.
Dwa najczęstsze modele:
ERP jako główne miejsce raportowania czasu
Wszyscy wpisują czas bezpośrednio do ERP, zwykle na poziomie projektu/etapu i typu aktywności. Narzędzia zespołowe służą do zarządzania zadaniami, ale nie do ewidencji godzin.
Plusy: jedno źródło prawdy, spójne dane dla finansów, mniej integracji.
Minusy: zespół musi codziennie zaglądać do ERP, co przy „ciężkim” interfejsie bywa bolesne.
Narzędzia zespołowe jako miejsce operacyjne, ERP jako hurtownia
Czas jest raportowany tam, gdzie ludzie i tak pracują (JIRA, system ticketowy, aplikacja mobilna konsultanta). ERP dostaje zagregowane dane z integracji.
Plusy: mniejsza zmiana nawyków, lepsza akceptacja użytkowników.
Minusy: konieczność sensownej integracji, ryzyko rozjazdów, jeśli ktoś zmieni dane „po fakcie”.
Często najlepiej działa model mieszany: konsultanci projektowi raportują czas w narzędziu projektowym, a działy wsparcia i administracja – bezpośrednio w ERP lub systemie kadrowym, który z ERP jest zintegrowany.
Jak uprościć raportowanie czasu, żeby ludzie faktycznie to robili
Technicznie większość ERP potrafi ewidencjonować czas. Problemem nie są funkcje, tylko psychologia i ergonomia. Jeśli raportowanie zajmuje więcej niż kilka minut dziennie, prędzej czy później ludzie zaczną „wymyślać” godziny z pamięci.
Kilka prostych trików, które robią dużą różnicę:
lista projektów i etapów powinna być krótka – nie zmuszaj konsultanta do wybierania z listy 200 pozycji,
używaj domyślnych filtrów (np. pokazuj tylko projekty, na które dana osoba jest przypisana),
umożliwiaj kopiowanie wpisów z poprzedniego dnia/tygodnia i szybkie korekty,
zapewnij prosty widok „dzisiaj” (lista aktywności w jednym oknie) zamiast skakania po wielu ekranach,
umożliwiaj raportowanie z telefonu – zwłaszcza dla ludzi w terenie.
Przydatny jest też jasny standard: do jakiej dokładności liczymy czas (15 minut, 30 minut, godzina) i jakie typy aktywności są dostępne. Im mniej wariantów, tym lepiej. Jeśli każdy projekt dodaje swoje własne kategorie czasu, po kilku miesiącach analityka staje się nieporównywalna.
Akceptacja czasu pracy: kto zatwierdza i po co
Sam wpis pracownika to dopiero połowa historii. Druga to akceptacja – czyli moment, kiedy dane stają się „oficjalne” i mogą iść dalej, na faktury i do controllingu.
W usługach sprawdza się dwuetapowe podejście:
Akceptacja merytoryczna – kierownik projektu sprawdza, czy godziny są przypisane do właściwych projektów/etapów, czy nie ma oczywistych błędów (np. 12 godzin szkolenia w dzień wolny bez delegacji),
Akceptacja formalna – dział HR/finanse weryfikuje zgodność z kalendarzem pracy, urlopami, nadgodzinami.
Nie trzeba robić z tego skomplikowanego workflow. Wystarczy, że system pozwoli:
odfiltrować i zatwierdzić czas dla projektu za dany okres,
zablokować edycję po akceptacji (z możliwością korekty przez uprawnioną osobę),
oznaczyć, które godziny są fakturowalne, a które nie.
Przy projektach time & material bardzo pomaga możliwość dodawania komentarzy do pozycji czasu. Klient często pyta: „Skąd te 5 godzin w środę?”. Jeśli konsultant wpisał krótki opis, kierownik projektu ma gotową odpowiedź, a faktura nie budzi tyle emocji.
Czas fakturowalny, niefakturowalny i „szara strefa”
Nie każda godzina konsultanta zamienia się w przychód. Część czasu to presales, wewnętrzne spotkania, rozwój kompetencji, urlopy. Jeśli ERP ma pomóc zarządzać firmą, musi umieć odróżnić:
czas fakturowalny (billable) – wprost powiązany z projektem klienta,
czas niefakturowalny produktowy – rozwój oferty, R&D, szkolenia wewnętrzne,
czas „kosztowy” – administracja, spotkania firmowe, rekrutacja.
W praktyce wystarczy dodać do wpisu czasu dwa wymiary:
projekt (kliencki, wewnętrzny, ogólnofirmowy),
znacznik fakturowalności (tak/nie) lub typ aktywności (billable / non-billable).
„Szara strefa” pojawia się tam, gdzie konsultanci nie mają jasności, czy dany czas jest fakturowalny. Typowy przykład: dodatkowe konsultacje po wdrożeniu, drobne poprawki „z uprzejmości”, przedsprzedaż. Rozwiązaniem jest jasna polityka (spisana!) i możliwość łatwego oznaczenia takich godzin jako „do decyzji”. Kierownik projektu w procesie akceptacji decyduje wtedy, które z nich trafią na fakturę, a które zostaną w kosztach.
Integracja z RCP i kadrami – dwa światy, które muszą się dogadać
RCP, kadry i projekty: jak zgrać trzy różne perspektywy
System rejestracji czasu pracy (RCP), moduł kadrowo-płacowy i ewidencja projektowa w ERP to często trzy osobne światy, każdy z własną logiką. RCP myśli w kategoriach wejść/wyjść i norm czasu, kadry – w kategoriach etatów, urlopów i list płac, a projekty – w kategoriach zadań i budżetów. Bez wspólnego mianownika robi się z tego „telefon głuchy”.
Punktem wyjścia jest rozdzielenie dwóch pytań:
Ile czasu pracownik był w pracy? – na to odpowiada RCP/kadry,
Na co ten czas został zużyty? – na to odpowiada moduł projektowy/hours tracking.
Technicznie nie trzeba mieć jednego systemu, który zrobi wszystko. Zdecydowanie ważniejsze jest, żeby:
oba źródła miały wspólny identyfikator pracownika,
istniała możliwość porównania „godzin w kalendarzu” z „godzinami na projektach”,
proces zamknięcia miesiąca jasno określał, kiedy dane z obu światów są „zamrożone”.
Prosta, ale skuteczna praktyka: co miesiąc raport „godziny z RCP minus godziny zaraportowane na projekty / kody wewnętrzne”. Odchylenia powyżej pewnego progu (np. 5%) trafiają do weryfikacji kierownika. Po kilku cyklach ludzie zaczynają pilnować raportowania czasu bez dodatkowych apeli na firmowym czacie.
Mapowanie kodów kadrowych na projekty i aktywności
Kolejny zgrzyt pojawia się przy urlopach, zwolnieniach, delegacjach. Dla kadr to „kody nieobecności”, dla controllingu – realny brak dostępności do realizacji projektów. Jeśli ERP ma dawać sensowny obraz obciążenia i rentowności, te dwa światy muszą się spotkać.
W praktyce dobrze działa prosta macierz:
po stronie kadr – kody nieobecności (urlop wypoczynkowy, L4, opieka, szkolenie zewnętrzne),
po stronie projektowej – projekty wewnętrzne / kody globalne (np. „URL”, „SZKOL”, „ADMIN”).
Integracja zamienia wtedy nieobecność „UR” na automatyczny wpis czasu na projekt „Urlopy i nieobecności”, a szkolenie zewnętrzne na „Szkolenia obowiązkowe”. Zespół nie musi niczego dopisywać ręcznie, a raporty obciążenia pokazują realistyczną dostępność zespołu. Proste? Proste – o ile ktoś na starcie usiądzie razem z kadrami i controllingiem i tę macierz po prostu narysuje.
Godziny nominalne, rozliczeniowe i „roboczogodziny projektowe”
W firmach usługowych często miesza się kilka pojęć „godzin”, co kończy się nieporozumieniami w rozmowach o efektywności. ERP może w tym pomóc, ale najpierw trzeba rozróżnić trzy poziomy:
godziny nominalne – wynikające z kalendarza pracy (etat, święta, urlopy),
godziny rozliczeniowe – faktycznie przepracowane według RCP lub timesheetów,
roboczogodziny projektowe – przypisane do projektów lub aktywności wewnętrznych.
Dopiero zestawienie tych trzech perspektyw daje sensowny obraz: ktoś może mieć 100% obecności, ale tylko 40% czasu projektowego (reszta to administracja, spotkania, wewnętrzne „gaszenie pożarów”). Jeśli ERP pozwoli powiązać te dane w jednym raporcie, rozmowy o „produktywności” przestają być oparte na intuicji.
Dobrym zwyczajem jest uzgodnienie na poziomie firmy, które wskaźniki są liczone na bazie jakich godzin. Przykład: „utilization” liczony tylko z godzin rozliczeniowych vs. „project utilization” liczony z roboczogodzin projektowych. To drobna różnica, ale oszczędza wiele sporów przy przeglądzie kwartalnym.
Rozliczenia projektów: modele, algorytmy, konfiguracja w ERP
Dlaczego model rozliczenia trzeba ustalić przed startem projektu
W usługach kłopoty z rentownością rzadko wynikają z „kosmosu w kosztach”. Częściej z tego, że nikt nie przemyślał modelu rozliczenia, a fakturowanie „robi się jakoś” na końcu miesiąca. ERP niczego tu nie załatwi, jeśli zespół sprzedaży i delivery nie dojdą do ładu co do tego, za co i jak klient ma płacić.
Przy zakładaniu projektu w ERP dobrze jest wymusić wybór jednego z kilku jasno zdefiniowanych modeli, zamiast pozwalać na dowolne kombinacje na poziomie pojedynczej umowy. Dzięki temu:
schematy fakturowania i kalkulacji marży można przygotować raz i powielać,
controlling porównuje jabłka z jabłkami (projekty o podobnej logice),
nowi handlowcy szybciej uczą się „jak się u nas sprzedaje usługi”.
Fixed price: jak okiełznać ryzyko w ERP
Projekty ryczałtowe są dla wielu usługodawców źródłem zarówno marży, jak i siwych włosów. ERP nie usunie ryzyka zakresu, ale może sprawić, że alarm zacznie migać wcześniej niż tydzień przed końcem budżetu.
W modelu fixed price przydatne są trzy elementy konfiguracyjne:
Budżet godzinowy dla etapu/projektu
Każdy etap (analiza, konfiguracja, testy) dostaje limit godzin, powiązany z kalkulacją oferty. ERP powinien pozwolić na:
porównanie przepracowanych godzin do budżetu w czasie rzeczywistym,
konfigurację progów ostrzegawczych (np. 80%, 100%, 120% budżetu),
podział budżetu na role (konsultant, developer, PM), jeśli stawki istotnie się różnią.
Odseparowanie wyceny dla klienta od stawek wewnętrznych
Cena sprzedaży etapu jest stała, ale stawki wewnętrzne osób mogą się zmieniać. Dlatego:
na projekcie przechowujemy osobno wartość kontraktu,
w ewidencji czasu stosujemy aktualne koszty osobowe,
marżę liczymy jako różnicę między kontraktem a sumą kosztów rzeczywistych.
Rejestrowanie zmian zakresu
Zakres projektu fixed price nigdy nie jest w 100% „zamrożony”. ERP nie musi być systemem do zarządzania zmianą, ale:
warto mieć możliwość oznaczania godzin jako „poza zakresem bazowym”,
dobrze, jeśli da się tworzyć subprojekty change requestowe z osobnym budżetem i fakturami,
raporty powinny pokazywać oddzielnie rentowność bazowego kontraktu i zmian.
Wiele firm, które miały serię „stratnych” projektów fixed price, po wdrożeniu takiej logiki odkrywa nagle, że problemem nie są stawki, tylko niekontrolowane dokładanie zakresu. ERP staje się wtedy lustrem, a nie kolejnym „systemem do księgowania strat”.
Time & material: diabeł tkwi w szczegółach stawek
Model T&M brzmi prosto: klient płaci za przepracowane godziny według uzgodnionych stawek. Schody zaczynają się, gdy okazuje się, że:
stawki różnią się między rolami (junior/senior/architect),
część klientów ma specjalne cenniki,
stawki walutowe zmieniają się w czasie,
są osobne zasady dla nadgodzin, weekendów, pracy zdalnej/onsite.
Żeby nie skończyć z arkuszem Excela jako głównym narzędziem rozliczeń, dobrze jest uporządkować w ERP kilka rzeczy:
Cenniki standardowe i indywidualne
Trzonem jest cennik domyślny na poziomie roli lub stanowiska. Klient może mieć:
cennik indywidualny (np. rabat procentowy),
stawkę per konkretną osobę (rzadziej, bo trudne w utrzymaniu).
Najważniejsze, aby ERP jednoznacznie wskazywał, skąd wzięła się dana stawka na fakturze.
Reguły stawek „specjalnych”
Nadgodziny i praca w weekendy często mają mnożniki (np. 150%, 200%). Można to załatwić:
osobnymi typami czasu („Weekend billable”, „Night shift billable”),
lub automatycznymi regułami, które patrzą na kalendarz i przekształcają stawkę.
Druga opcja jest wygodniejsza dla konsultantów, ale wymaga porządnej konfiguracji i testów.
Mechanizm zamykania okresów rozliczeniowych
Przy T&M kluczowe jest zdefiniowanie granicy, po której czas „wchodzi” na fakturę:
termin zamknięcia raportowania (np. 3. dzień roboczy nowego miesiąca),
blokada edycji po wystawieniu faktury,
procedura korekt (np. noty korygujące, faktury korygujące).
ERP powinien wspierać te zasady technicznie, a nie polegać na dobrej woli ludzi.
Abonament i retainer: stała kwota, zmienna praca
Coraz więcej firm usługowych przechodzi na modele subskrypcyjne: miesięczny retainer za określoną dostępność zespołu lub pulę godzin. Dla księgowości to „stała faktura cykliczna”, ale dla operacji i controllingu sprawa jest bardziej złożona.
W takim modelu przydają się w ERP trzy równoległe wymiary:
kontrakt abonamentowy – definiuje kwotę miesięczną, okres obowiązywania, zasady indeksacji,
budżet godzinowy / zakres usług – ile godzin/zgłoszeń jest „w pakiecie”,
ewidencja faktycznego zużycia – godziny, SLA, liczba ticketów.
Dobrą praktyką jest prowadzenie w ERP „wirtualnego salda godzin” dla każdego retaineru:
na początku miesiąca saldo powiększa się o pulę godzin z umowy,
każdy wpis czasu na projekt retainerowy to „konsumpcja” godzin,
system pokazuje na bieżąco stan salda (np. 70% wykorzystania puli).
Jeśli umowa przewiduje dopłaty za przekroczenie, ERP może automatycznie generować propozycje pozycji faktury „ponad pakiet”. W przeciwnym razie saldo służy choćby do rozmów z klientem: „w tym kwartale regularnie zużywamy 130% puli, czas porozmawiać o nowym poziomie abonamentu”.
Modele mieszane: jak nie utonąć w wyjątkach
Rzeczywistość rzadko mieści się w jednym modelu. Typowa umowa wdrożeniowa łączy elementy fixed price (analiza, podstawowa konfiguracja), T&M (zmiany, dodatkowe konsultacje) i abonament (support powdrożeniowy). Najgorsze, co można wtedy zrobić, to próbować zmieścić wszystko w jednym projekcie z jednym schematem rozliczeń.
Bardziej przejrzyste podejście to podział na projekty/segmenty o różnych logikach finansowych:
projekt A – wdrożenie core, fixed price per etap,
projekt B – prace dodatkowe, T&M (podpięty pod tę samą umowę i klienta),
projekt C – utrzymanie, rozliczenie abonamentowe.
Od strony ERP kluczowe jest, aby:
projekty były powiązane jedną umową / kontraktem nadrzędnym,
dało się raportować zarówno na poziomie pojedynczego projektu, jak i całej relacji z klientem,
schematy fakturowania były różne, ale spójne zdefiniowane na poziomie typu projektu.
Dzięki temu z poziomu controllingu można np. zobaczyć: „na wdrożeniu zarobiliśmy mniej, ale na zmianach i utrzymaniu projekt odrobił koszty i jest zyskowny w horyzoncie dwóch lat”. Bez podziału logicznego w ERP takie wnioski opierają się bardziej na przeczuciu niż na danych.
Algorytmy naliczania przychodu i marży w czasie
Sam moment wystawienia faktury nie musi pokrywać się z momentem „zarobienia” przychodu z perspektywy rachunkowości zarządczej. W dłuższych projektach przydają się proste, ale spójne algorytmy rozpoznawania przychodu w czasie.
Najczęściej stosowane warianty, które ERP może obsłużyć:
proporcjonalnie do postępu prac (cost-to-cost) – przychód rozpoznawany jest wg udziału kosztów poniesionych w kosztach całkowitych projektu,
proporcjonalnie do czasu – gdy prace są równomierne, a kontrakt zryczałtowany na dłuższy okres (np. roczny retainer),
kamieniami milowymi – przychód przypisany do zakończenia konkretnych etapów.
Nie trzeba zaczynać od skomplikowanych rozwiązań IFRS w ERP. Wystarczy, że system:
pozwala przypisać do projektu wybrany algorytm,
Najczęściej zadawane pytania (FAQ)
Jakie moduły ERP są kluczowe w firmie usługowej: projekty, czas pracy, rozliczenia?
W firmie usługowej nie wystarczy sprzedaż + księgowość. Sercem wdrożenia są moduły, które ogarną cały „życiorys” projektu: od leada w CRM, przez ofertę i budżet, aż po raportowanie czasu i fakturowanie. System powinien mieć spójny model: projekt → zadania/etapy → czas pracy → faktury i raporty rentowności.
W praktyce najważniejsze są: CRM/ofertowanie, projekty i zlecenia, ewidencja czasu pracy (timesheety), rozliczanie projektów (fixed price, T&M, abonamenty) oraz integracje z narzędziami operacyjnymi (np. JIRA, Asana). Dopiero ich połączenie daje pełen obraz, zamiast kilku osobnych „wysp” danych.
Jak dobrze zaprojektować rejestrowanie czasu pracy w ERP dla firmy usługowej?
Rejestracja czasu musi być jednocześnie na tyle dokładna, aby dało się policzyć rentowność projektu, i na tyle prosta, żeby ludzie faktycznie ją wypełniali. Punktem wyjścia jest zdefiniowanie, co to jest „jednostka pracy”: projekt, zadanie, ticket, sprawa, typ aktywności (np. billable / niebillable).
Najlepsze efekty daje połączenie: jasnej struktury (projekty, etapy, zadania), sensownej granulacji (nie co 15 minut, jeśli nikt tego nie wytrzyma) oraz wygodnego narzędzia – np. rejestrowania czasu bezpośrednio z narzędzia do zadań lub kalendarza. Pracownik powinien w prosty sposób „przypiąć” swoje godziny do konkretnego projektu i typu pracy, a ERP ma na tej bazie zasilić fakturowanie i controlling.
Jak podejść do analizy przedwdrożeniowej ERP w firmie usługowej?
Zamiast zaczynać od listy funkcji w modułach, lepiej przejść ścieżkę „dzień z życia projektu”. Czyli krok po kroku: jak pojawia się lead, jak powstaje oferta, kto zakłada projekt, gdzie planowane są zadania, jak raportowany jest czas, jak rozliczane są zmiany zakresu, w jaki sposób powstaje faktura. Dopiero na takim obrazie można sensownie rozłożyć role między ERP, CRM, narzędziem do zadań i innymi systemami.
W warsztatach analitycznych powinni wziąć udział przedstawiciele sprzedaży, delivery/operacji, finansów/controllingu, HR oraz IT. Jeśli zabraknie któregoś z tych głosów, powstaje system wygodny tylko dla jednej grupy – np. dla controllingu, ale kompletnie nieużywalny dla konsultantów, którzy mają codziennie raportować czas.
Jak zintegrować ERP z narzędziami do zadań typu JIRA, Asana w firmie usługowej?
Najpierw trzeba ustalić „prawdę nadrzędną”: czy projekty i klienci są zakładani w ERP i synchronizowani do JIRA/Asany, czy odwrotnie. Zazwyczaj to ERP jest miejscem, gdzie powstaje projekt biznesowy (z budżetem, modelem rozliczeń), a narzędzie typu JIRA służy jako robocza „deska warsztatowa” dla zespołu.
Dobra integracja oznacza, że zadania lub tickety z narzędzia operacyjnego można łatwo przypisać do projektów w ERP, a zarejestrowany czas automatycznie trafia do odpowiednich zleceń i etapów. Dzięki temu kierownik projektu widzi budżet i wykonanie w jednym miejscu, a pracownicy nie muszą podwójnie raportować godzin.
Jak ERP wspiera różne modele rozliczeń: fixed price, time & material, abonament?
Dla rozliczeń fixed price kluczowe jest porównanie zużytych godzin (i kosztów) do zafakturowanej wartości – ERP powinien umożliwić ustawienie budżetu godzinowego/kwotowego na projekt lub etap oraz sygnalizować jego przekroczenia. W T&M najważniejsze jest precyzyjne powiązanie zarejestrowanego czasu z klientem, projektem i stawką (osobową lub zadaniową), tak aby faktura mogła powstać niemal „z automatu”.
Przy abonamentach i retainerach potrzebny jest model, w którym klient ma określony pakiet (np. liczba godzin lub zakres prac), a system śledzi jego wykorzystanie. ERP powinien pozwalać na ewidencję czasu per klient/sprawa i jednocześnie kontrolę, które aktywności mieszczą się w abonamencie, a które są pracami dodatkowymi do osobnego rozliczenia.
Czym różni się wdrożenie ERP w firmie usługowej od wdrożenia w firmie produkcyjnej?
W produkcji głównym bohaterem są materiały, technologie, magazyny i BOM-y. W usługach na pierwszy plan wychodzi czas ludzi, ich kompetencje, projekty i zadania. W efekcie inaczej definiuje się „jednostkę rozliczeniową”: nie jest to paleta czy partia produkcyjna, lecz godzina pracy przypisana do konkretnego projektu lub klienta.
Wdrożenie w firmie usługowej wymaga więc większego nacisku na: model projektów i zleceń, strukturę zadań, integrację z narzędziami do pracy zespołowej oraz ergonomię raportowania czasu. Jeśli te elementy zostaną potraktowane po macoszemu, ERP stanie się tylko księgową „skorupą”, a faktyczne życie firmy i tak wróci do Excela i osobnych aplikacji.
Jak uniknąć sytuacji, w której ERP nie odzwierciedla realnej pracy zespołu?
Podstawą jest świadome zdefiniowanie pojęć: co u nas jest projektem, co zleceniem, co zadaniem, czym różni się ticket od etapu. Trzeba też odtworzyć realne scenariusze pracy – łącznie z „brzydkimi skrótami”, np. raportowaniem czasu na koniec miesiąca z pamięci czy wyceną projektów w prywatnych Excelach handlowców. Tylko wtedy da się zaprojektować procesy w ERP, które nie będą fikcją.
Dobrym testem jest pytanie do liderów i konsultantów: „Czy na podstawie tego, jak ustawiliśmy projekty i zadania w ERP, jesteście w stanie normalnie prowadzić dzień pracy – bez dodatkowych, ukrytych arkuszy?”. Jeśli odpowiedź brzmi „nie”, to nie ludzie są problemem, tylko model w systemie, który trzeba skorygować zanim zacznie się masowa migracja danych.
