Gdy zatrudnianie podnosi rachunek za software: nowe spojrzenie na licencje per użytkownik

TL;DR (Quick Summary)

Przy planie zatrudnienia koszt licencji per użytkownik potrafi rosnąć szybciej niż wartość z narzędzia. Trzeba policzyć nie tylko seaty, ale też pokrycie procesu, realne użycie i koszt pracy poza systemem.

• Zacznij od pytania biznesowego → headcount nie równa się opłacalność
• Policz pełną krzywą kosztu → cena seata zaniża obraz
• Podziel pracowników na kategorie dostępu → nie każdy etat potrzebuje full seat
• Oceń koszt pozornych oszczędności → brak licencji tworzy obejścia
• Interpretuj metryki łącznie → wzorce są ważniejsze niż pojedyncze KPI
• Wskaż, które kategorie narzędzi → per-seat ma sens tylko czasem
• Zamień analizę w decyzję zakupową → wybierz model na następne 12 miesięcy

Takeaway: Jeśli licencje rosną razem z headcountem, trzeba sprawdzić, czy kupujesz dostęp tam, gdzie powstaje wartość, czy tylko dopłacasz za strukturę zatrudnienia. Dobra decyzja łączy koszt stacku z widocznością procesu.

---

Problem zwykle wychodzi przy planie wzrostu. Firma zatrudnia kolejne osoby, procesy obejmują nowe zespoły, a rachunek za software rośnie niemal automatycznie. W modelu per użytkownik nie każda nowa osoba podnosi wartość systemu w takim samym tempie jak koszt licencji. Trzeba więc rozstrzygnąć, czy obecny model nadal wspiera operacje, czy stał się dodatkowym kosztem od każdego etatu.

Sama liczba użytkowników niczego nie rozstrzyga. Opłacalność trzeba ocenić przez trzy filtry naraz: intensywność użycia, krytyczność roli oraz ryzyko pracy poza systemem. Dopiero taki zestaw pokazuje, czy seat wnosi wartość, czy tylko zwiększa koszt stacku.

Zacznij od pytania biznesowego: czy plan zatrudnienia skaluje wartość narzędzi szybciej niż koszt licencji?

Przy budżetowaniu software łatwo pomylić dwa cele. Pierwszy to kontrola całkowitego kosztu stacku. Drugi to zapewnienie dostępu pracownikom, którzy tworzą dane, przesuwają proces do przodu albo odpowiadają za zgodność. Te cele nie zawsze idą razem.

Jeśli firma patrzy wyłącznie na sumę abonamentów, naturalną reakcją jest ograniczanie dostępu. Gdy priorytetem jest pełne objęcie procesu systemem, koszt może rosnąć szybciej, niż zakładano. Dlatego pytanie nie powinno brzmieć: „ilu użytkowników mamy?”, tylko: „czy każda kolejna licencja powiększa wartość operacyjną proporcjonalnie do kosztu?”

To rozróżnienie ma znaczenie przy planie zatrudnienia. Dodanie handlowca pracującego codziennie w CRM to co innego niż dodanie brygadzisty, który raz dziennie potwierdza wykonanie zadania, albo pracownika sezonowego, który tylko odbiera przydzielone zlecenia. Vendor może policzyć kolejnego użytkownika tak samo, ale biznesowo to inne sytuacje.

Liczy się nie liczba etatów, tylko relacja między trzema elementami:

• użyciem – jak często dana rola pracuje w systemie,
• wpływem – czy bez tej osoby proces traci ciągłość, jakość danych lub terminowość,
• alternatywą – co dzieje się, gdy tej osoby w systemie nie ma.

Ten trzeci punkt bywa pomijany. Firma może uznać seat za zbędny, bo ktoś loguje się rzadko. Po chwili informacje z terenu wracają mailem, kierownik przepisuje je ręcznie do CRM, a statusy zadań są widoczne z opóźnieniem. Oszczędność na licencji zostaje, ale widoczność procesu znika.

[BANNER type="lead_banner_1" title="Arkusz do prognozowania kosztów oprogramowania przy zatrudnianiu" description="Wprowadź swój adres e-mail, aby otrzymać kompleksowy, szczegółowy przewodnik krok po kroku" picture-src="/upload/medialibrary/c0f/04zrwoo0jpzvirn15czqu595pynw0yl9.webp" file-path="/upload/medialibrary/af1/vxotsqpsb3h6kx0hokvmyp1pbcm8nds2.pdf"]

Policz pełną krzywą kosztu, a nie tylko cenę za seat

Analiza oparta na prostym mnożeniu „liczba osób x cena licencji” zwykle zaniża przyszły koszt. Potrzebny jest model 12-miesięczny, który łączy plan zatrudnienia z konkretnymi aplikacjami i typami dostępu.

Najprostszy układ obejmuje trzy warstwy: stan obecny, czyli liczbę użytkowników, typy licencji i realny koszt po uwzględnieniu pakietów; plan zatrudnienia rozpisany miesięcznie albo kwartalnie; oraz mapowanie ról do aplikacji, czyli odpowiedź, które nowe role rzeczywiście potrzebują dostępu do jakiego narzędzia.

Taki model powinien pokazać krzywą kosztu w czasie. Dzięki temu widać momenty, w których przekroczysz próg cenowy, wejdziesz w wyższy pakiet albo będziesz musiał dokupić licencje administracyjne, specjalistyczne lub integracyjne.

W prostych kalkulacjach najczęściej znikają:

• minimalne pakiety – płacisz za blok użytkowników, nawet jeśli nie wykorzystujesz całości,
• progi cenowe – zmiana liczby seatów uruchamia inną taryfę,
• droższe licencje – admini, analitycy, supervisorzy,
• wdrożenie i konfiguracja – nowe role to dodatkowe workflow, pola, uprawnienia i szkolenia,
• konta po rotacji – opłacane mimo odejścia pracownika lub długiej nieaktywności.

Dobra prezentacja dla zarządu albo finansów powinna mieć trzy widoki:

Różnica między drugim i trzecim widokiem pokazuje, czy problem leży w cenie narzędzia, czy w tym, że firma kupuje dostęp szerzej, niż realnie potrafi go wykorzystać. To kwestia nie tylko procurementu, ale też jakości przypisania licencji do ról.

Podziel pracowników na kategorie dostępu zamiast traktować każdy etat jak pełnego użytkownika

W wielu organizacjach każdy nowy etat uruchamia domyślny zestaw kont. To wygodne administracyjnie, ale kosztowo i operacyjnie bywa błędne. Lepsze podejście to segmentacja ról według sposobu pracy z systemem.

Podział może wyglądać tak:

• codzienni użytkownicy systemu – stale tworzą i aktualizują dane,
• użytkownicy zadaniowi – wchodzą do systemu przy konkretnych czynnościach,
• odbiorcy – sprawdzają status, raport albo harmonogram,
• pracownicy terenowi – wykonują proste akcje, często mobilnie,
• niepełny etat – mają ograniczony czas pracy, ale nie zawsze ograniczoną odpowiedzialność.

Taka segmentacja porządkuje dyskusję o tym, kto uzasadnia pełny seat. Nie wystarczy patrzeć na częstotliwość logowania. Ważne są też kluczowe akcje, odpowiedzialność za dane, wymogi audytowe i wpływ braku dostępu na przekazanie pracy dalej.

Niska liczba logowań nie musi oznaczać niskiej wartości. Dyrektor operacyjny może logować się rzadko, ale zatwierdzać wyjątki wpływające na zgodność lub przychód. Pracownik terenowy może wykonać niewiele akcji, ale jeśli od jego potwierdzenia zależy fakturowanie albo serwis, jego obecność w systemie ma dużą wagę.

Kategorie dostępu powinny więc wynikać z roli w przepływie pracy, a nie z samej formy zatrudnienia. Part-time nie oznacza automatycznie „lekki użytkownik”, a pracownik biurowy nie zawsze potrzebuje pełnego pakietu funkcji.

[BANNER type="lead_banner_2" blockquote="\"Przekonała nas przejrzysta i logiczna struktura Bitrix24, a także wiele opcji integracji z innymi oprogramowaniami.\"" user-picture-src='/upload/optimizer/converted/upload/iblock/076/ojv5hyzs9tyd2rkovjq2zlcngu7sg8d4.png.webp?1747117529883' user-name="Dyrektor generalny, Peter Krummenacher" user-description="k-webs GmbH - Internet Consulting"]

Oceń koszt pozornych oszczędności, gdy część zespołu zostaje poza systemem

Najczęstsza reakcja na rosnące koszty licencji jest prosta: nie dawajmy seatów osobom pracującym dorywczo, terenowo albo sezonowo. Na papierze wygląda to rozsądnie. Problem zaczyna się wtedy, gdy ich pracę trzeba mimo wszystko odnotować.

Pojawiają się shadow processes: e-maile ze statusami, arkusze z wykonaniem, wiadomości w komunikatorach, telefoniczne potwierdzenia i współdzielone loginy. Firma formalnie oszczędza na licencjach, ale buduje drugi, nieoficjalny obieg danych.

Tego kosztu nie da się wiarygodnie uchwycić jedną kwotą, ale można go mierzyć przez wskaźniki operacyjne:

• liczba ręcznych przekazań danych – ile razy informacja przechodzi przez pośrednika, zanim trafi do systemu,
• czas opóźnienia między wykonaniem pracy a rejestracją – jak długo system pokazuje stan nieaktualny,
• odsetek rekordów uzupełnianych przez pośrednika – jak często ktoś wpisuje dane za osobę wykonującą pracę,
• liczba błędów i wyjątków – ile razy trzeba poprawiać statusy, daty, przypisania lub kompletność danych.

Każdy z tych wskaźników odsłania inny koszt: obciążenie koordynatorów, opóźnione raportowanie, niższą identyfikowalność albo więcej interwencji. Jeśli firma oszczędza na seatcie, ale rośnie liczba obejść, rośnie też koszt koordynacji i spada jakość danych.

Decyzja powinna opierać się na porównaniu dwóch kosztów: kosztu pełnego objęcia roli systemem oraz kosztu utrzymywania tej roli poza systemem. Gdy drugi zaczyna rosnąć szybciej, oszczędność na licencji staje się pozorna.

Formuła wyceny opóźnień i błędów wygląda następująco:

Koszty ukryte (Shadow IT) = (Czas poświęcony na obejścia i przepisywanie × Stawka godzinowa operatora/koordynatora) + (Koszt ryzyka / ewentualnych kar z tytułu niedotrzymania SLA)

Aby wyliczenia były wiarygodne, nie opieraj ich na deklaracjach zespołu. Skorzystaj z trzech twardych źródeł danych operacyjnych:

1. Logi e-mail i komunikatorów (IM): zlicz, ile wiadomości zawiera słowa „status”, „załączam potwierdzenie”, „czy to zrobione?”, które krążą jako zamiennik działań w systemie.
2. Timesheety (czasówki): sprawdź kategorie takie jak „administracja”, „aktualizacja danych”, „synchronizacja zespołu”.
3. Rejestr SLA (Service Level Agreement): wyciągnij logi kar umownych, utraconych upustów lub opóźnień fakturowania wynikających z braku przepływu informacji z terenu/produkcji do biura.

Badania i rynkowe stawki wynagrodzeń

Zjawisko "pracy nad pracą" (ang. work about work) kosztuje firmy ogromne pieniądze. Według najnowszego, obszernego raportu Anatomy of Work Index (Asana) pracownicy biurowi spędzają aż 60% swojego czasu na czynnościach okołopracowych – szukaniu informacji, przełączaniu się między aplikacjami czy ręcznym przepisywaniu statusów, zamiast na właściwej pracy eksperckiej. Z kolei analizy Gartnera wskazują, że 47% cyfrowych pracowników regularnie ma problem ze znalezieniem danych potrzebnych do wykonania swoich zadań z powodu ich rozproszenia.

Jeśli przymierzymy te rynkowe straty do polskich realiów wynagrodzeń (według aktualnych raportów płacowych m.in. Hays, NoFluffJobs i TapTalent), koszty stają się brutalne:

• IT Project Manager / Koordynator wyższego szczebla: Zarobki w Polsce to średnio ok. 16 500 – 22 000 PLN brutto miesięcznie, co przy uwzględnieniu kosztów pracodawcy daje stawkę w granicach 120 – 160 PLN za godzinę.
• Specjalista operacyjny / Back-office: Średnio ok. 9 000 – 12 000 PLN brutto, czyli stawka rzędu 65 – 85 PLN za godzinę.

Interpretuj metryki łącznie: które wzorce pokazują, że model per-seat przestaje pasować do organizacji

Pojedynczy wskaźnik rzadko daje dobrą odpowiedź. Niska aktywność może oznaczać złą adopcję, błędne przypisanie licencji albo to, że narzędzie jest używane do rzadkich, ale ważnych zadań. Potrzebne są kombinacje metryk.

Pierwszy wzorzec ostrzegawczy to szybki wzrost headcountu przy stabilnym budżecie software. Na początku wygląda jak dobra kontrola kosztów. Często oznacza jednak, że rośnie grupa pracowników bez dostępu albo z dostępem zastępczym. Jeśli jednocześnie zwiększa się liczba ręcznych przekazań i opóźnień raportowania, budżet nie jest efektywny — po prostu przestał pokrywać proces.

Drugi wzorzec to rosnąca liczba kont przy niskim odsetku aktywnych użytkowników. Czasem oznacza nadmiar zakupionych licencji, ale może też wskazywać na zły mix planów, zbyt szerokie domyślne nadawanie dostępu albo błędne założenie, że każda rola potrzebuje pełnego seata.

Trzeci wzorzec to wysoka liczba zadań wykonywanych poza systemem przy pozornie dobrej adopcji. Dashboard może pokazywać aktywnych managerów i koordynatorów, ale jeśli wpisują dane za zespół, system rejestruje aktywność nie tam, gdzie powstaje praca.

Sygnały, które warto traktować poważnie, to:

• managerowie działający jako operatorzy dla osób bez licencji,
• wspólne loginy, które kasują odpowiedzialność per osoba,
• opóźnione raportowanie z terenu, przez co status w systemie jest historyczny,
• duża różnica między liczbą pracowników a liczbą osób widocznych w danych.

Dopiero zestawienie relacji daje wiarygodną diagnozę: adopcja + pokrycie ról pokazują, czy system obejmuje realny przepływ pracy; koszt na zatrudnionego + koszt obejść pokazują, czy oszczędność nie przesuwa wydatku gdzie indziej; liczba kont + aktywne użycie pokazują, czy problemem jest cena, przypisanie, czy sam model produktu.

Wtedy można odróżnić trzy sytuacje: za drogie licencje, źle rozdystrybuowane seaty albo narzędzie zaprojektowane pod inny profil organizacji niż twój.

Wskaż, które kategorie narzędzi naprawdę uzasadniają licencjonowanie per użytkownik

Nie każdy typ aplikacji źle znosi wzrost headcountu. Są kategorie, w których per-seat ma wyraźne uzasadnienie biznesowe i nie warto z nim walczyć na siłę.

Pełny seat zwykle broni się tam, gdzie narzędzie jest miejscem codziennej pracy indywidualnej. Dotyczy to systemów, w których użytkownik regularnie tworzy dane, podejmuje decyzje, odpowiada za jakość wpisów albo korzysta z szerokiego zestawu funkcji. Podobnie w produktach z wysokimi wymaganiami bezpieczeństwa, ścieżką audytu i odpowiedzialnością per osoba model „jeden użytkownik, jedno konto” jest operacyjnie uzasadniony.

Per-seat dobrze działa także tam, gdzie interakcja jest częsta i głęboka: handlowiec pracujący codziennie w CRM, specjalista obsługi rozwiązujący zgłoszenia, księgowy przetwarzający dokumenty, HR zarządzający uprawnieniami. W takich przypadkach seat jest podstawowym narzędziem pracy.

Inaczej wygląda to w kilku kategoriach:

• proste workflow dla szerokiej populacji – potwierdzenia, checklisty, odbiory,
• raportowanie dla okazjonalnych odbiorców – statusy i podgląd danych bez częstej edycji,
• procesy frontline – wiele osób wykonuje proste, krótkie akcje,
• zadania o niskiej złożoności – interakcja z systemem jest lekka, ale skala użytkowników duża.

Tam model per-seat częściej tworzy tarcie niż wartość. Nie dlatego, że system jest zły, tylko dlatego, że koszt przypisany do każdej osoby rozmija się z ciężarem jej interakcji z produktem.

Przy ocenie vendorów warto sprawdzić:

• jaki udział stanowią użytkownicy lekcy w całej populacji,
• czy potrzebna jest identyfikowalność per osoba dla każdej czynności,
• ile kosztuje wykluczenie roli z systemu w postaci obejść i opóźnień,
• czy dostępne są inne modele cenowe niż pełny seat dla wszystkich,
• czy model dostępu wytrzyma zmienne grafiki, sezonowość i pracę terenową.

To przesuwa rozmowę z poziomu „ile kosztuje licencja” na poziom „do jakiego typu pracy ten model licencyjny jest dopasowany”.

Zamień analizę w decyzję zakupową lub porządkowanie stacku na kolejne 12 miesięcy

Po zebraniu danych potrzebna jest decyzja, a nie kolejny arkusz. Firma powinna wybrać jeden z czterech kierunków:

• zostawić obecny model – jeśli seaty pokrywają role o wysokiej wartości, a koszt obejść jest niski,
• renegocjować warunki – gdy narzędzie pasuje operacyjnie, ale obecna taryfa źle skaluje wzrost,
• ograniczyć zakres pełnych seatów – jeśli tylko część ról potrzebuje rozbudowanego dostępu,
• szukać produktu z innym modelem – usage-based, role-based albo frontline, gdy obecny produkt źle pasuje do struktury użytkowników.

Business case powinien zestawić trzy koszty: koszt obecnego stacku przy dzisiejszej liczbie użytkowników, koszt docelowy po realizacji planu zatrudnienia w horyzoncie 12 miesięcy oraz koszt pełnego objęcia procesem vs. koszt pracy poza systemem.

Ten trzeci element zwykle rozstrzyga. Jeśli pełne objęcie zespołu systemem jest drogie, ale pozostawienie części pracy poza nim generuje opóźnienia, błędy i ręczne przepisywanie, oszczędność licencyjna przestaje być argumentem strategicznym. Zostaje krótkoterminowym cięciem budżetowym.

Przed kolejnym cyklem zakupowym warto uporządkować pięć obszarów:

• audyt nieaktywnych kont – oddziel konta zbędne od rzadko używanych, ale krytycznych,
• mapowanie ról do aplikacji – przypisz dostęp na podstawie rzeczywistej pracy, nie schematu onboardingowego,
• identyfikacja shared logins – to sygnał, że model licencyjny nie pokrywa procesu,
• przegląd pracowników bez dostępu – sprawdź, gdzie powstają dane poza systemem,
• test alternatywnych polityk licencyjnych – przed odnowieniem umowy sprawdź inne typy dostępu lub produkty.

Najlepszy efekt daje połączenie finansów, IT i właścicieli procesów. Finanse widzą koszt, IT administrację i bezpieczeństwo, a biznes skutki wykluczenia części pracy z systemu. Dopiero wspólny model pokazuje, czy obecny per-user jest nadal uzasadniony, czy stał się podatkiem od planu zatrudnienia.