Chaos subskrypcyjny: audyt narzędzi SaaS krok po kroku

Zamiast czystego rachunku — plątanina nazw, z których połowę pierwszy raz widzisz na oczy. Slack, Notion, Calendly, oczywiście, ale też coś jak „ProWorkflow Premium roczny”, „AcmeAnalytics Pro Team”, „DataSync Enterprise 3 seats” — i tu zaczyna boleć głowa, bo nikt w zespole nie pamięta, kto to wdrożył, po co i ilu z nas w ogóle tego używa. Brzmi znajomo? Jeśli macie w firmie więcej niż trzydzieści osób, ten widok jest bardziej regułą niż wyjątkiem.

I tak właśnie zaczyna się to, co w branży nazywamy chaosem subskrypcyjnym — stanem, w którym liczba narzędzi rośnie szybciej niż zdolność zespołu, żeby nimi zarządzać. Zanim się obejrzymy, jesteśmy w sytuacji, którą znam z rozmów z dziesiątkami founderów: płacimy za oprogramowanie, którego nikt nie dotyka, równocześnie nie mamy pojęcia, co dokładnie dzieje się w naszym własnym stosie technologicznym. I co najgorsze — nie jesteśmy w tym odosobnieni. Przeciętne przedsiębiorstwo zarządza średnio 291 aplikacjami SaaS, a od 51% do 53% opłacanych licencji pozostaje całkowicie niewykorzystanych. To nie jest margines błędu. To jest dziura w budżecie, którą możemy spokojnie nazwać po imieniu.

Ponad połowa tego, co opłacamy jako firmy w modelu subskrypcji, po prostu się marnuje — a my zwykle nie mamy czasu się nad tym zastanowić, bo właśnie wdrażamy kolejne narzędzie.

Skala problemu: dlaczego 291 aplikacji to za dużo dla Twojego biznesu

Zacznijmy od liczby, która zwykle robi wrażenie: 291. To średnia liczba aplikacji SaaS, którymi zarządza pojedyncze przedsiębiorstwo. Nie mówimy tu o korporacji z Wall Street — mówimy o przeciętnej firmie, która ma dział sprzedaży, marketing, księgowość i zespół produktowy. Sama ta cyfra wyjaśnia, dlaczego audyt oprogramowania SaaS w firmie nie może być fanaberią administratora, tylko musi stać się jedną z podstawowych kompetencji operacyjnych, na równi z fakturowaniem czy raportowaniem przychodów.

Ale 291 aplikacji to nie jest problem wynikający z nadmiaru pieniędzy. To problem wynikający z tego, jak bardzo nasza praca rozproszyła się w ciągu ostatnich lat. Każdy z nas codziennie loguje się do kilkunastu narzędzi — komunikacja, dokumenty, projekty, analityka, faktury, kampanie, rekrutacja, obsługa klienta, baza wiedzy, planowanie, automatyzacje marketingowe, integracje bez kodu, kalendarze, ankiety, narzędzia do projektowania, prototypowania, listy mailingowe i zdalne burze mózgów.

Każde z tych narzędzi pojawiło się w odpowiedzi na konkretną potrzebę konkretnej osoby w konkretnym tygodniu. Problem polega na tym, że nikt nie zrobił porządku wtedy, kiedy ta potrzeba wygasła. Narzędzie zostało, konto zostało, karta została podpięta, a faktura zaczęła przychodzić automatycznie. Po kilku miesiącach nikt już nie pamięta, czy dana usługa jest elementem ważnego procesu, czy tylko pozostałością po jednym projekcie, który zakończył się dawno temu.

Właśnie dlatego liczba aplikacji sama w sobie nie jest jeszcze najważniejszym wskaźnikiem. Firma może mieć ich dużo i działać sprawnie. Może też mieć ich znacznie mniej, ale kompletnie nie wiedzieć, kto ma do nich dostęp, gdzie są przechowywane dane i kiedy przypada najbliższe odnowienie. Prawdziwy problem zaczyna się wtedy, gdy nie potrafimy odpowiedzieć na podstawowe pytania:

• kto jest właścicielem biznesowym danego narzędzia;
• za jaki proces firma faktycznie płaci;
• ilu użytkowników loguje się do usługi i jak często;
• jaki plan jest aktywny oraz czy odpowiada rzeczywistemu wykorzystaniu;
• gdzie trafiają dane i jakie inne systemy mają z nimi połączenie;
• co wydarzy się po wyłączeniu aplikacji.

I tu dochodzimy do zjawiska, które specjaliści od optymalizacji procesów biznesowych nazywają żartobliwie „aplikacyjną lodówką”. Otwierasz szafkę, a tam pięć różnych serów, z których dwa są przeterminowane, jeden należy do kolegi, który odszedł pół roku temu, a pozostałe wyglądają, jakby nikt ich nie dotykał od miesięcy. Kazus w skali makro wygląda dokładnie tak samo: od 51% do 53% licencji SaaS w firmach to martwe wydatki, czyli pieniądze, które można było przeznaczyć na trakcję, wydłużenie runwayu albo pierwszego seniora, którego brakuje w zespole. Tyle że zamiast tego odprowadzamy je co miesiąc do dostawców, których nazwy z trudem wymawiamy.

W audycie warto więc rozdzielić trzy rzeczy: liczbę kupionych subskrypcji, liczbę aktywnych kont oraz faktyczne wykorzystanie funkcji. To nie są synonimy. Aktywne konto może oznaczać jedno logowanie w ciągu ostatniego roku. Licencja przypisana do pracownika nie musi być licencją potrzebną temu pracownikowi. Z kolei aplikacja używana przez niewielką grupę może być krytyczna dla procesu, którego nie da się łatwo zastąpić.

Shadow IT w praktyce: jak 80% pracowników omija dział IT

Prawdziwy potwór chaotycznego stosu SaaS czai się jednak tam, gdzie go nie widać. Shadow IT — czyli oprogramowanie, którego nikt formalnie nie zatwierdził, a z którego korzystają nasi ludzie — to zjawisko, które dotyka niemal każdej organizacji, niezależnie od jej wielkości. Szacunki są tu dość przygnębiające: aż 80% pracowników sięga po aplikacje SaaS bez pytania działu IT o zgodę.

Brzmi to trochę jak historia o niegrzecznych dzieciach, które robią, co chcą, kiedy rodzic zajęty jest telefonem. Ale prawda jest mniej dramatyczna i bardziej ludzka: ludzie po prostu chcą wykonywać swoją pracę sprawniej, a ścieżka formalnego zamówienia w wielu firmach bywa tak długa, że równie dobrze mogłaby wymagać zgody zarządu.

Weźmy typową historię. Analityczka w zespole marketingu potrzebuje narzędzia do wizualizacji danych, które połączy się z ich CRM-em. Zgłasza potrzebę, czeka tydzień na ocenę, kolejny tydzień na przetarg, dwa tygodnie na wdrożenie. W tym czasie klient prosi o raport, którego nie da się zrobić w dotychczasowym arkuszu. Analityczka zakłada więc konto z własnej karty, podpina kartę firmową i po dwóch godzinach raport jest gotowy.

Czy postąpiła źle? Biorąc pod uwagę kontekst — raczej nie. Czy właśnie stworzyła kolejną pozycję, której nikt w firmie nie kontroluje? Zdecydowanie tak. I co istotne — wcale nie jest w tym jedyna.

Shadow IT rzadko zaczyna się od złej intencji. Najczęściej jest skutkiem tarcia organizacyjnego. Pracownik nie może szybko dostać dostępu do potrzebnej funkcji, więc szuka rozwiązania na własną rękę. Dostawcy SaaS doskonale to rozumieją: darmowy okres próbny, rejestracja bez rozmowy z handlowcem, płatność kartą i gotowe. Z punktu widzenia użytkownika to kilka minut. Z punktu widzenia firmy — nowy dostawca, nowe miejsce przetwarzania danych, nowe uprawnienia i potencjalne odnowienie, o którym nikt nie pamięta.

Skala tego zjawiska jest poważniejsza, niż zwykliśmy przyznawać. Typowa firma oficjalnie monitoruje jedynie około 10% faktycznie używanych usług chmurowych — średnio 108 zidentyfikowanych wobec 975 działających w ukryciu. W dużych organizacjach niezatwierdzone oprogramowanie może pochłaniać od 30% do 40% całkowitego budżetu IT. To ważne rozróżnienie: ten przedział dotyczy całego budżetu IT dużych organizacji, a nie wydatków na oprogramowanie w dowolnej firmie. Nie oznacza więc, że co trzecia złotówka przeznaczona na wszystkie firmowe subskrypcje znika bez kontroli. Oznacza natomiast, że skala niezatwierdzonych zakupów może być dla dużych organizacji bardzo poważna.

W startupie, gdzie każdy etat rozpatrujemy trzy razy, zanim go zaakceptujemy, taka strata i tak brzmi absurdalnie — nawet jeśli nie da się jej sprowadzić do jednej uniwersalnej proporcji. Koszt nie kończy się zresztą na samej fakturze. Dochodzi czas pracowników, którzy utrzymują niepotrzebne konta, ryzyko wycieku danych, problemy z dostępem po odejściu członka zespołu i kłopoty podczas kontroli bezpieczeństwa. Czasem największym kosztem nie jest to, że płacimy za aplikację. Największym kosztem jest to, że nie wiemy, co ta aplikacja robi w naszym środowisku.

Dlatego reakcją nie powinien być zakaz wszystkiego. Jeśli firma zablokuje każdą możliwość szybkiego przetestowania narzędzia, pracownicy znajdą obejście. Rozsądniejszy model to jasna ścieżka zgłoszenia, szybka ocena ryzyka i określona zasada odpowiedzialności. Pracownik powinien wiedzieć, że może zgłosić potrzebę bez obawy, że zostanie ukarany za sam fakt poszukiwania rozwiązania. Firma powinna natomiast wiedzieć, kto zatwierdził usługę, do jakich danych ma ona dostęp i kiedy należy wrócić do tej decyzji.

Trzy poziomy integracji: techniczne fundamenty skutecznego audytu

Audyt SaaS to nie jest kwestia dobrej woli ani jednego arkusza w Excelu. Żeby naprawdę zobaczyć, co siedzi w naszej firmie, musimy podejść do tego jak do projektu inżynieryjnego, który wymaga kilku źródeł sygnału. To dlatego poważne podejścia do zarządzania subskrypcjami SaaS w firmie opierają się na integracji danych z trzech warstw — każda widzi coś innego i dopiero ich suma daje pełny obraz.

Każda z tych warstw ma swoje mocne strony i swoje martwe pole. Wtyczki przeglądarkowe widzą zachowanie, ale widzą je tylko na zainstalowanych przeglądarkach i zgodnych urządzeniach. Konektory tożsamości wiedzą, kto ma dostęp, ale nie wiedzą, czy ten ktoś w ogóle dane narzędzie otwiera. Interfejs rozliczeniowy zna stan finansowy konta, ale nie powie nam, czyja praca naprawdę z tego konta korzysta.

Dopiero połączenie tych trzech strumieni daje szansę na realne odpowiedzi: czy narzędzie jest aktywne, czy ktoś z niego korzysta, czy nadal spełnia swoją funkcję, czy dane konto powinno mieć szerokie uprawnienia i czy warto zostawić obecny plan. W praktyce oznacza to, że dane finansowe trzeba zestawić z informacją o logowaniach i z perspektywą właściciela procesu. Sama faktura nie wystarczy. Sam raport z logowań również nie.

Dobry audyt zaczyna się od zebrania danych, ale nie kończy się na ich zebraniu. Najpierw trzeba ujednolicić nazwy. Ten sam dostawca może pojawiać się na wyciągu pod kilkoma nazwami, a różne zespoły mogą opisywać jedno narzędzie innymi określeniami. Potem należy połączyć konta, użytkowników i płatności. Dopiero wtedy da się sprawdzić, czy firma nie płaci równocześnie za kilka planów tej samej usługi albo czy jedna licencja nie została przypisana osobie, która od dawna nie pracuje w organizacji.

Następny krok to ustalenie minimalnego zestawu informacji dla każdej aplikacji:

• nazwa usługi i dostawcy;
• właściciel biznesowy oraz osoba odpowiedzialna technicznie;
• dział korzystający z narzędzia;
• liczba kupionych i faktycznie używanych licencji;
• wysokość opłaty oraz cykl rozliczeniowy;
• data odnowienia i warunki rezygnacji;
• typ danych przechowywanych w usłudze;
• integracje z innymi systemami;
• decyzja: utrzymać, zmienić plan, przenieść licencje albo wyłączyć.

I jeszcze jedna uwaga, zanim ktoś zapyta, czy to wszystko wymaga budżetu rzędu wdrożenia dla dużej korporacji. Nie, nie musi. Na początek wystarczy świadoma decyzja, że łączymy te trzy sygnały, choćby w arkuszu: dane z przeglądarek dla najbardziej niezdyscyplinowanych zespołów, Okta albo Entra ID w warstwie tożsamości oraz ręcznie pobierane dane rozliczeniowe od głównych dostawców. To nie jest technologia kosmiczna, tylko konsekwencja.

A kiedy okaże się, że skala nas przerasta, wtedy dopiero rozmawiamy o dedykowanej platformie do zarządzania SaaS, która te trzy warstwy sklei w jeden panel. Narzędzia do zarządzania licencjami SaaS są dziś dojrzałym segmentem rynku, ale warto do nich dojść, kiedy już wiemy, czego konkretnie szukamy. Zakup platformy przed uporządkowaniem procesu często kończy się tym, że firma ma nowy system do zarządzania starym chaosem.

Strategia konsolidacji: jak wyeliminować 50% martwych licencji

W 2025 roku 33% organizacji zdecydowało się na konsolidację nadmiarowych aplikacji SaaS w celu optymalizacji kosztów. To nie jest chwilowa moda — to odpowiedź na dojrzewający rynek, który wreszcie zaczął liczyć pieniądze, równocześnie wiedząc, że do końca tego samego roku oprogramowanie w modelu SaaS stanowiło aż 85% całego oprogramowania biznesowego wykorzystywanego przez firmy.

Konsolidacja, w odróżnieniu od chaotycznego wycinania, wymaga jednak metody. Wycinanie na oślep, zwłaszcza w pośpiechu i bez konsultacji z zespołami, kończy się tym, że za trzy miesiące kupujemy to samo narzędzie drugi raz, tylko pod inną nazwą, bo lider zespołu nie wytrzymał pracy w jego zastępstwie.

Konsolidacja SaaS nie jest terapią szokową. To rozmowa z zespołami, zrozumienie, po co naprawdę używają danego narzędzia, i dopiero potem decyzja: zostaje, odchodzi, zmienia rolę albo rotuje licencję.

Realna ścieżka wygląda tak. Najpierw klasyfikacja — do każdej aplikacji przypisujemy właściciela biznesowego, czyli osobę, która faktycznie za nią odpowiada. Bez tego każde narzędzie staje się sierotą, a sieroty nikt nie odważa się wyłączyć, bo „może komuś się przyda”. Właściciel nie musi być osobą, która zamawia usługę. Powinien jednak umieć odpowiedzieć, jaki problem rozwiązuje aplikacja, kto z niej korzysta i co się stanie po jej wyłączeniu.

Potem kategoryzacja: narzędzia krytyczne dla produktu, narzędzia wspierające operacje, narzędzia eksperymentalne oraz narzędzia pozostające poza kontrolą. Te ostatnie nie powinny automatycznie trafić do kosza. Powinny jednak dostać najwyższy priorytet w wyjaśnieniu, kto je kupił, jakie dane przetwarzają i dlaczego nie ma ich w oficjalnym katalogu.

Następnie przychodzi przegląd aktywności — tu właśnie przydają się dane z trzech warstw integracji. Warto patrzeć nie tylko na to, czy ktoś się zalogował, lecz także na częstotliwość korzystania, liczbę aktywnych użytkowników i funkcje, które faktycznie są używane. Aplikacja otwierana raz w miesiącu może być potrzebna, jeśli obsługuje zamknięcie okresu rozliczeniowego. Z drugiej strony codzienne logowanie nie zawsze oznacza, że firma potrzebuje najwyższego planu. Czasem użytkownik korzysta z jednej funkcji, którą można znaleźć w tańszym pakiecie albo w innym już opłacanym narzędziu.

Dopiero na końcu podejmujemy decyzje:

1. Zostaje — gdy narzędzie jest krytyczne, ma jasno określonego właściciela i jest używane adekwatnie do kosztu.

2. Zmienia plan — gdy funkcje są potrzebne, ale firma kupuje więcej miejsc lub możliwości, niż faktycznie wykorzystuje.

3. Rotuje licencję — gdy dostęp nie musi być stały i można przekazywać go między użytkownikami zgodnie z zasadami dostawcy.

4. Zostaje zastąpione — gdy podobną funkcję zapewnia już inne narzędzie, a migracja nie niesie nieakceptowalnego ryzyka.

5. Odchodzi — gdy nie ma właściciela, aktywności, krytycznych danych ani procesu, który zależałby od aplikacji.

Najczęstszym błędem w tym procesie jest próba zrobienia wszystkiego naraz. Uczciwie — nie da się. Dlatego warto priorytetyzować według prostego rachunku: roczna wartość licencji pomnożona przez prawdopodobieństwo, że nikt z niej nie korzysta, daje nam listę najszybszych oszczędności przy najmniejszym ryzyku.

Zwykle zaczyna się od śmietnika, bo tam nikt się nie obrazi, gdy wyrzucimy nieużywaną subskrypcję. Z czasem można podejść do bardziej delikatnych pozycji, tych, które wymagają rozmowy z właścicielami produktu czy szefami sprzedaży. Czasem takie narzędzie nie zasługuje na cięcie, ale na zmianę kierunku — inny sposób użycia albo przeniesienie do mniejszego, tańszego planu.

Warto również sprawdzić, czy kilka działów nie kupuje osobno podobnych usług. Marketing może mieć własne narzędzie do formularzy, sprzedaż drugie do automatyzacji, a obsługa klienta trzecie do zbierania odpowiedzi. Każdy zakup z osobna wygląda rozsądnie. Razem tworzą koszt, który rośnie bez wspólnej decyzji i bez negocjacyjnej siły. Konsolidacja może więc oznaczać nie tylko wyłączenie aplikacji, lecz także połączenie kilku umów, ujednolicenie planu i wynegocjowanie lepszych warunków.

Na koniec warto zostawić sobie bufor. Nie tniemy 100% tego, co wygląda podejrzanie. Zostawiamy 5–10% budżetu na szybkie eksperymenty, bo za dwanaście miesięcy lista niezbędnych narzędzi może wyglądać zupełnie inaczej. Elastyczność kosztowa to też kompetencja operacyjna, nie luksus. Firma, która oszczędza na każdej próbie, może po prostu spowolnić zespoły i wrócić do tych samych zakupów inną drogą.

Budowanie kultury zarządzania: SaaS to proces, a nie jednorazowy projekt

Audyt, w którym ktoś siada, wycina, co się da, i ogłasza zwycięstwo, to pierwszy krok do powtórki chaosu za pół roku. Prawdziwa zmiana zaczyna się wtedy, gdy rozumiemy, że zarządzanie subskrypcjami SaaS w firmie to nie jest jednorazowy projekt ani zadanie dla IT, tylko ciągły proces — nawyk organizacyjny, który trzeba wbudować w codzienność zespołów.

Około 47% firm deklaruje, że brakuje im zasobów, ludzkich i technologicznych, do efektywnego zarządzania posiadanymi subskrypcjami. To liczba, która przeraża, dopóki nie uświadomimy sobie, że w większości organizacji odpowiedzialność za ten obszar nie jest w ogóle przypisana. Nikt nie „jest za to”. Więc nikt nie „robi” — aż do momentu, kiedy księgowa zaczyna zadawać niewygodne pytania przy okazji zamknięcia roku.

Pierwsza praktyka, która robi różnicę, to onboarding i offboarding traktowane jako para, nie jako dwie osobne procedury. Kiedy ktoś dołącza, dostaje jasną listę aktywnych narzędzi i jasne zasady, że każde nowe wymaga zgłoszenia. Kiedy ktoś odchodzi, robimy automatyczny przegląd jego dostępów i faktycznie je wycofujemy, zamiast zostawiać na „później”, które nigdy nie nadchodzi.

To samo dotyczy zmian ról. Pracownik przeniesiony z marketingu do sprzedaży nie powinien automatycznie zachować wszystkich wcześniejszych uprawnień. Jeśli dostęp jest nadawany raz i pozostaje na zawsze, firma z czasem buduje nie tylko nadmiar licencji, lecz także nadmiar uprawnień. A to już nie jest wyłącznie problem kosztowy. To problem bezpieczeństwa i odpowiedzialności za dane.

Druga praktyka to kwartalny rytuał przeglądu subskrypcji — godzinna sesja z właścicielami narzędzi, w trakcie której każdy musi powiedzieć, czy tego używa, ile osób naprawdę z tego korzysta i czy potrzebuje tego samego planu za trzy miesiące. Brzmi sztywno? Tylko do czasu, aż stanie się normą. Kwartalny rytm jest wystarczająco częsty, by wychwycić martwe licencje, i wystarczająco rzadki, by nie zamienić pracy w niekończące się spotkanie administracyjne.

Trzecia praktyka to tożsamość jako centralna warstwa zarządzania, czyli Okta, Entra ID albo ich odpowiednik, tak aby każda nowa aplikacja domyślnie przechodziła przez jednokrotne logowanie i była widoczna w panelu. Nie rozwiąże to całego problemu, bo część usług nadal będzie działała poza tym systemem. Zmienia jednak punkt wyjścia: zamiast odkrywać aplikacje dopiero na wyciągu z karty, możemy kontrolować znaczną część dostępu już na etapie tworzenia konta.

Czwarta i najtrudniejsza praktyka to kultura, w której pracownik nie boi się przyznać, że przestał używać narzędzia. Zbyt często w firmach niewykorzystana licencja to „wstydliwa porażka” — ktoś przecież za nią zapłacił, ktoś ją wybrał, przetestował i walczył o budżet. Ale jeśli nie budujemy przestrzeni, w której przyznanie się do nieużyteczności narzędzia jest w porządku, będziemy w nieskończoność opłacać decyzje, które dawno przestały mieć sens.

Właściciel narzędzia powinien być rozliczany nie z tego, czy utrzymał subskrypcję, ale z tego, czy firma świadomie podjęła decyzję o jej utrzymaniu. To subtelna, ale ważna różnica. Celem nie jest przecież zejście do zera aplikacji. Celem jest wiedzieć, dlaczego dana aplikacja jest w firmie, kto jej potrzebuje i jaki koszt uzasadnia jej obecność.

Od czego zacząć dziś, jeszcze dziś, bez wielkiego planu i wielkiego budżetu? Zróbmy jedną prostą rzecz. Spójrzmy na listę ostatnich dwudziestu pozycji na wyciągu z firmowej karty i zapytajmy na głos, przy każdej z nich: czy ktoś z nas używał tego w zeszłym tygodniu?

Jeśli przez dziesięć sekund nikt się nie odezwie — to jest nasz pierwszy kandydat do wyjaśnienia, a być może także do wycięcia. Nie zawsze trzeba od razu anulować usługę. Najpierw warto sprawdzić właściciela, dane, integracje i warunki rezygnacji. Ale sama cisza przy nazwie dostawcy jest wystarczającym powodem, żeby przestać udawać, że wszystko jest pod kontrolą.

I tak, to nie jest rewolucja. Ale rewolucja w zarządzaniu SaaS zaczyna się od tego momentu, w którym zamiast gonić kolejne wdrożenie, zatrzymujemy się i pytamy, po co w ogóle płacimy za to, co już mamy. Nie chodzi o to, żeby każdą decyzję zakupową zamienić w wieloetapową procedurę. Chodzi o to, żeby firma miała pamięć: wiedziała, co kupiła, dla kogo, na jak długo i według jakiej zasady będzie mogła z tego zrezygnować.

Chaos subskrypcyjny nie znika po jednym audycie. Można jednak sprawić, że przestanie narastać bez świadomej decyzji. A to już wystarczająco dużo, by odzyskać część budżetu, ograniczyć shadow IT w przedsiębiorstwie i zbudować stos technologiczny, który wspiera rozwój zamiast po cichu go opodatkowywać.