Kontrola PIP w software house: mix B2B i UoP

W software house kontrola zwykle nie zaczyna się od pytania, ilu wykonawców pracuje na B2B. Znacznie ważniejsze jest to, jak ta współpraca wygląda w praktyce i co potwierdzają umowy, regulaminy, harmonogramy oraz codzienna komunikacja. Fraza „kontrola PIP software house mix B2B i UoP” opisuje więc nie problem samego modelu zatrudnienia, lecz ryzyko, że część kontraktów B2B będzie nosiła cechy stosunku pracy.

Mix umów B2B i umów o pracę jest w IT dopuszczalny i powszechny. Problem pojawia się wtedy, gdy kontraktor formalnie prowadzi działalność, ale faktycznie wykonuje pracę w warunkach charakterystycznych dla etatu: pod kierownictwem firmy, w miejscu i czasie przez nią wyznaczonym, za stałym wynagrodzeniem oraz w ramach jej bieżącej organizacji. To właśnie taki układ może zostać oceniony przez pryzmat art. 22 §1 Kodeksu pracy.

Kontrola PIP w software house z miksem B2B i UoP

Inspektor nie ocenia współpracy na podstawie samej nazwy dokumentu. Umowa „B2B”, faktura wystawiana co miesiąc czy wpis do CEIDG nie przesądzają o charakterze relacji. Znaczenie ma jej rzeczywista treść. Jeżeli praktyka i dokumenty wskazują na wykonywanie pracy jak przez pracownika, ryzyko reklasyfikacji rośnie.

W software house szczególnie łatwo o niejednoznaczność. Zespoły projektowe działają w sprintach, mają wspólne spotkania, deadline’y, dostęp do repozytoriów i narzędzi klienta. Same te elementy nie tworzą jeszcze stosunku pracy. Są często normalną konsekwencją realizacji projektu IT. Kluczowe jest jednak, czy służą koordynacji niezależnej usługi, czy stałemu zarządzaniu osobą podobnie jak pracownikiem.

Przykładowo, obowiązek udziału w jednym statusie projektowym nie ma takiego samego ciężaru jak codzienne rozliczanie obecności od 9:00 do 17:00, wymóg uzyskiwania zgody na każdą nieobecność i podporządkowanie poleceniom przełożonego dotyczącym bieżącego sposobu pracy. Podobnie dostęp do firmowego Slacka może być technicznie konieczny, ale nie powinien automatycznie oznaczać włączenia kontraktora do pełnej struktury pracowniczej.

Co PIP może analizować podczas kontroli

Punkt wyjścia stanowi art. 22 §1 Kodeksu pracy. Przepis wskazuje na wykonywanie pracy określonego rodzaju na rzecz pracodawcy, pod jego kierownictwem oraz w miejscu i czasie przez niego wyznaczonym, za wynagrodzeniem. W realiach software house’u te elementy trzeba przełożyć na konkretne zapisy i fakty, a nie na ogólne deklaracje o „partnerskiej współpracy”.

Podporządkowanie i bieżące polecenia

Największe znaczenie ma zwykle stopień samodzielności. Kontraktor może otrzymać wymagania projektowe, zakres rezultatu, priorytety biznesowe i termin realizacji. To naturalne w umowie usługowej. Ryzykowne staje się natomiast stałe wydawanie wiążących poleceń dotyczących sposobu, kolejności i czasu wykonywania każdego zadania, zwłaszcza gdy osoba po stronie firmy pełni wobec B2B funkcję przełożonego.

Warto odróżnić odbiór rezultatu od zarządzania pracą. Product owner może zaakceptować funkcję, zgłosić błąd lub zmienić priorytet produktu. Nie musi to oznaczać kierownictwa pracowniczego. Jeżeli jednak kontraktor jest rozliczany jak członek zespołu etatowego, podlega codziennym dyspozycjom i nie ma realnej przestrzeni do samodzielnej organizacji usługi, argument o niezależności słabnie.

Czas i miejsce wykonywania usług

Wiele firm IT wprowadza stałe godziny dostępności, aby zapewnić współpracę zespołu. Taki zapis wymaga ostrożności. Okno komunikacyjne lub konieczność dostępności na zaplanowane warsztaty mogą mieć uzasadnienie projektowe. Sztywne godziny świadczenia pracy, ewidencja obecności czy obowiązek pozostawania online przez pełny dzień roboczy przypominają natomiast organizację etatu.

Podobnie jest z miejscem. Wymóg pracy z biura każdego dnia może być uzasadniony wyjątkowo, na przykład bezpieczeństwem projektu lub koniecznością pracy na infrastrukturze klienta. Powinien jednak wynikać z realnej potrzeby usługi, a nie być automatycznie kopiowany z zasad obowiązujących pracowników. Im mniej firma potrafi wyjaśnić biznesowy sens ograniczenia, tym trudniej obronić jego proporcjonalność.

Osobiste świadczenie i zastępstwo

B2B nie musi zawsze oznaczać faktycznego korzystania z podwykonawcy. Ważne jest jednak, czy kontraktor ma choćby realną, rozsądnie uregulowaną możliwość zapewnienia zastępstwa lub wsparcia innej osoby. Całkowity zakaz zastępstwa, połączony z wymaganiem osobistego wykonywania wszystkich zadań, może wzmacniać obraz relacji pracowniczej.

Nie należy jednak tworzyć pozornego prawa do zastępstwa. Klauzula nie pomoże, jeśli praktyka pokazuje, że firma nigdy nie dopuszcza takiej możliwości albo wymaga uprzedniej zgody bez jasnych kryteriów. W projektach wymagających poufności, dostępu do systemów klienta czy określonych kompetencji ograniczenia mogą być uzasadnione. Powinny być opisane precyzyjnie i adekwatnie do ryzyka projektu.

Wynagrodzenie, urlopy i narzędzia

Stała miesięczna faktura sama w sobie nie przesądza o etacie. W IT jest popularnym sposobem rozliczeń, zwłaszcza przy długich projektach. Ryzyko zwiększają jednak zapisy i praktyki typowe dla wynagrodzenia pracowniczego: płatne „urlopy”, formalne wnioski o wolne, rozliczanie absencji jak nieobecności pracownika czy gwarantowanie stałej wypłaty niezależnie od świadczenia usług.

Również sprzęt firmowy nie jest automatycznym problemem. Laptop, konto w narzędziu klienta czy dostęp do środowiska testowego bywają konieczne dla ochrony danych i jakości pracy. Warto jednak ustalić, czy narzędzia są udostępniane wyłącznie dla realizacji konkretnej usługi oraz czy umowa nie buduje obrazu pełnego, organizacyjnego podporządkowania.

Gdzie software house’y popełniają najczęstsze błędy

Najbardziej ryzykowne są nie zawsze pojedyncze postanowienia, lecz niespójność całego modelu. Umowa może deklarować niezależność wykonawcy, a jednocześnie przewidywać obowiązek pracy w godzinach firmy, raportowanie obecności, wniosek urlopowy i nadzór team leadera. W kontroli taka deklaracja będzie miała ograniczoną wartość, jeżeli nie odpowiada rzeczywistości.

Częstym błędem jest też stosowanie jednego wzoru B2B dla wszystkich ról. Inaczej wygląda współpraca z niezależnym ekspertem realizującym zamknięty zakres, inaczej z developerem pracującym przez wiele miesięcy wyłącznie w jednym squadzie, a jeszcze inaczej z kontraktorem pełniącym dyżury operacyjne. Jeden wzór może nie uwzględniać istotnych różnic w stopniu samodzielności, dostępności i odpowiedzialności.

Problemem jest również kopiowanie regulaminów pracowniczych na osoby B2B. Dotyczy to zwłaszcza zasad czasu pracy, procedur nieobecności, oceny okresowej, poleceń służbowych czy benefitów opisanych identycznie jak dla pracowników. Nie chodzi o to, aby kontraktor był wyłączony z zasad bezpieczeństwa lub współpracy projektowej. Chodzi o rozdzielenie reguł koniecznych do realizacji usługi od mechanizmów typowych dla zatrudnienia pracowniczego.

Jak przygotować dokumenty przed kontrolą PIP

Przygotowanie nie polega na szybkim dopisywaniu do umów klauzuli o braku stosunku pracy. Taki zapis może mieć znaczenie pomocnicze, ale nie zastąpi spójnej konstrukcji kontraktu i praktyki operacyjnej. Najpierw należy ustalić, które role B2B są najbardziej podobne do etatowych oraz jakie dokumenty regulują ich codzienną współpracę.

Warto objąć przeglądem nie tylko umowę główną, ale też aneksy, załączniki, regulaminy, polityki pracy zdalnej, procedury zgłaszania nieobecności, wzory komunikatów onboardingowych i zasady raportowania. To właśnie poza umową często znajdują się instrukcje, które przesuwają relację w stronę podporządkowania pracowniczego.

Dobrym porządkiem działania są cztery kroki:

• podziel kontrakty B2B na grupy według roli, projektu i sposobu współpracy;
• wskaż zapisy dotyczące kierownictwa, czasu, miejsca, osobistego świadczenia, nieobecności oraz rozliczeń;
• porównaj treść umowy z faktyczną organizacją pracy zespołu;
• poprawiaj nie tylko pojedyncze sformułowania, ale także procedury, które przeczą niezależności wykonawcy.

Automatyczna analiza może przyspieszyć pierwszy etap selekcji. PipCheck skanuje umowę PDF pod kątem 14 kryteriów związanych z ryzykiem reklasyfikacji, wskazuje cytaty z dokumentu i porządkuje obszary wymagające sprawdzenia. Darmowy screening pozwala ustalić, czy pełny raport jest potrzebny, zanim firma przeznaczy czas na ręczny przegląd całego portfela kontraktów.

Taki raport nie zastępuje indywidualnej porady prawnej ani nie daje gwarancji wyniku ewentualnej kontroli. Jest natomiast użytecznym narzędziem operacyjnym: pokazuje, gdzie dokładnie znajdują się zapisy wymagające decyzji i które umowy warto skierować do dalszej analizy.

Dokumenty muszą odpowiadać praktyce

Najbezpieczniejszy model nie polega na maksymalnym „odcinaniu” kontraktora od firmy. W software house byłoby to często nierealne i nieefektywne. Celem jest takie ułożenie współpracy, aby konieczna koordynacja projektu nie zamieniała się w faktyczne kierownictwo pracownicze.

Jeżeli firma potrzebuje stałych dyżurów, wyłączności, codziennej dostępności i ścisłego nadzoru nad sposobem pracy, warto uczciwie ocenić, czy B2B jest właściwą formą dla danej roli. Jeżeli natomiast współpraca ma charakter usługowy, dokumenty i praktyka powinny to konsekwentnie potwierdzać. Najlepszym momentem na wykrycie rozbieżności jest przegląd kontraktu przed problemem, a nie kompletowanie wyjaśnień dopiero po wejściu inspektora do firmy.