Restrukturyzacja firmy informatycznej Toruń – plan naprawczy dla software house i usług IT

Restrukturyzacja firmy informatycznej w Toruniu nie zaczyna się od zwolnień ani od nerwowych maili do klientów. Zaczyna się od policzenia prawdy o projektach: ile naprawdę zarabiasz na godzinie, gdzie utknęła gotówka i które umowy przenoszą ryzyko wyłącznie na Ciebie. W usługach IT można mieć pełne kalendarze i jednocześnie tracić płynność, bo wynik księgowy, backlog i gotówka to trzy różne światy.

W tym artykule dostajesz praktyczny plan restrukturyzacji software house oraz firmy IT B2B w Toruniu: co sprawdzić w pierwsze 72 godziny, jak ustawić 13-tygodniowy cashflow, jak uporządkować portfel projektów i w jaki sposób rozmawiać z wierzycielami oraz klientami, żeby odzyskać sterowność. Oparłem go o realia pracy projektowej i wnioski z badań o niepowodzeniach projektów IT (m.in. raporty PMI i Standish Group), a także o powtarzalne obserwacje z analiz płynności w gospodarce (NBP) i zatorów płatniczych w sektorze MŚP.

Jeśli rozważasz też formalną ścieżkę (układ, ochrona przed egzekucją), zobacz, jak wyglądają procedury restrukturyzacyjne w Toruniu — szczególnie gdy presja wierzycieli rośnie.

Dlaczego firma IT wpada w kryzys, mimo że "pracy jest dużo"

W branży informatycznej kryzys rzadko wygląda jak nagły spadek popytu. Częściej jest to seria drobnych pęknięć, które sumują się w jeden problem: firma dowozi coraz więcej, a zarabia coraz mniej i finansuje klientów własną gotówką.

Najczęstsze mechanizmy kryzysu w software house i usługach IT:

• Projekty fixed price z niedoszacowaniem: raporty o zarządzaniu projektami (PMI) od lat wskazują, że niejasny zakres i słabe zarządzanie zmianą są w czołówce przyczyn przekroczeń budżetu. W IT "doklejanie" funkcji bez change request to prosty sposób na ujemną marżę.
• Wysoki koszt stały ludzi: wynagrodzenia i koszty pracodawcy płacisz co miesiąc, a wpływy klienta zależą od akceptacji, protokołów i terminów płatności. Gdy rośnie rotacja albo spada obłożenie, koszt stały zaczyna "zjadać" bufor.
• WIP (Work In Progress) zamiast cash: wiele firm ma "wypracowane" godziny, których nie da się szybko zafakturować (bo brakuje akceptacji, dokumentów, sprint review, podpisu). To typowy powód, dla którego bilans wygląda lepiej niż konto.
• DSO rośnie bez alarmu: faktury B2B w IT potrafią mieć 14, 30, 45 dni, a realnie spływają później, bo "po stronie klienta" trwa akceptacja lub brakuje jednego załącznika. Analizy NBP i raporty o zatorach płatniczych konsekwentnie pokazują, że opóźnienia w płatnościach są jednym z najważniejszych źródeł problemów płynności.
• Sprzedaż bez progów rentowności: gdy nie masz minimalnej stawki godzinowej (z narzutem na koszty pośrednie), handlowiec lub CEO może podpisywać "cokolwiek, byle były projekty". W IT to szybko prowadzi do przepracowania i spadku jakości.

Jeśli wpisujesz w wyszukiwarkę frazy typu "restrukturyzacja software house Toruń" albo "jak uratować firmę IT w Toruniu z problemami płynności", to niemal zawsze chodzi o odzyskanie kontroli nad trzema rzeczami: gotówką, marżą i ryzykiem kontraktowym.

Jeśli potrzebujesz szerszego kontekstu (nie tylko branża IT), zacznij od artykułu o restrukturyzacji firmy w Toruniu.

Sygnały ostrzegawcze w firmie informatycznej (zwykle 4–10 tygodni wcześniej)

W IT często da się "zobaczyć" kryzys, zanim zobaczy go bank czy ZUS. Zwróć uwagę na te objawy:

1. Wzrost pracy nie-fakturowalnej: poprawki, utrzymanie, gaszenie pożarów, spotkania statusowe, support "po godzinach".
2. Zator akceptacji po stronie klienta: sprinty się kończą, ale protokoły stoją; rośnie liczba "prawie gotowe".
3. Przesuwanie płatności stałych: czynsz, podatki, raty, podwykonawcy; pojawiają się prośby o przesunięcie terminu o tydzień.
4. Nadmiar "pilnych" projektów: zespół skacze między tematami, bo każdy klient jest "najważniejszy", a nic nie domyka się do końca.
5. Spadek jakości i morale: rośnie liczba błędów na produkcji, a zespół ma poczucie, że "ciągle gonimy".

Wskazówka eksperta: w restrukturyzacji firmy IT najdroższe jest udawanie, że to "tylko przejściowy dołek". Jeśli masz 2–3 miesiące spadku marży i rosnące DSO, to nie jest problem sprzedaży, tylko problem sterowności modelu.

Audyt w 72 godziny: dane, bez których nie da się naprawić firmy IT

Nie potrzebujesz od razu wielkiego controllingu. Potrzebujesz jednego, spójnego zestawu liczb, które pozwolą podejmować decyzje w tygodniach, a nie w emocjach.

Zbierz i ułóż w jednym arkuszu:

• 13-tygodniowy cashflow (tygodniami): wpływy planowane i realne + wszystkie płatności (płace, ZUS, podatki, podwykonawcy, narzędzia, leasing, biuro).
• Aging należności: 0–14, 15–30, 31–60, 60+ dni; oddziel sporne od niespornych.
• Aging zobowiązań: co jest krytyczne (płace, ZUS, kluczowi dostawcy) i co da się negocjować.
• Rentowność projektów: plan vs wykonanie (godziny, stawka, koszty), a jeśli nie masz danych godzinowych - choćby estymacja: kto ile czasu spędził i co z tego jest fakturowalne.
• Utilization (obłożenie): ile godzin zespołu jest realnie sprzedawalne w tygodniu; oddziel delivery od "wewnętrznego" (sprzedaż, rekrutacja, QA, DevOps, PM).
• WIP i status akceptacji: co jest "gotowe do faktury", co czeka na klienta, czego brakuje (protokół, ticket, opis, raport).
• Pipeline sprzedaży i ryzyko: 5 największych szans + prawdopodobieństwo + realny termin startu (a nie życzeniowy).

Już ten audyt zwykle pokazuje, że problem nie leży w tym, że "klienci nie chcą", tylko w tym, że firma nie ma procesu domykania wartości do faktury.

Restrukturyzacja firmy IT w Toruniu – plan na 7 / 30 / 90 dni

W usługach IT restrukturyzacja działa tylko wtedy, gdy ma rytm i właściciela. Poniżej sprawdzony schemat, który daje szybko efekt na gotówce i jakości dowożenia.

Gdzie w IT "ucieka" marża: trzy dźwignie, które zwykle dają najszybszy efekt

W restrukturyzacji software house są trzy miejsca, w których nawet niewielka zmiana robi różnicę.

1) Cena i model rozliczeń (ryzyko po Twojej stronie vs po stronie klienta)

Jeśli większość pracy robisz w fixed price, potrzebujesz przynajmniej dwóch bezpieczników:

• twardego zarządzania zakresem (change request, limit liczby iteracji, jasna definicja "gotowe"),
• warunków płatności związanych z postępem (milestone, sprint, miesięczna faktura za utrzymanie).

To nie jest "trudny charakter". To standard, którego brak jest jedną z najczęstszych przyczyn porażek projektowych opisywanych w badaniach o delivery IT: klient naturalnie będzie chciał więcej, a dostawca bez procesu zmian naturalnie będzie to dowoził kosztem marży.

2) Utilization i miks kompetencji (kto robi co, i czy ta praca jest sprzedawalna)

W firmie usługowej nie sprzedajesz "ludzi", tylko czas i efekt ich pracy. Praktycznie:

• jeżeli senior robi zadania, które może robić mid, to tracisz marżę,
• jeżeli delivery robi zbyt dużo spotkań i wsparcia, to spada fakturowalność,
• jeżeli PM/PO nie ma narzędzi do ograniczania WIP, rośnie chaos i rework.

Raporty DORA (State of DevOps) od lat pokazują, że dojrzałe praktyki inżynieryjne (automatyzacja, CI/CD, dobra obserwowalność) skracają czas dostarczania i ograniczają awarie. W restrukturyzacji to przekłada się na mniej kosztownych poprawek i bardziej przewidywalne domykanie sprintów.

3) Domykanie do faktury (od "zrobione" do "zapłacone")

W wielu firmach IT najszybsza poprawa cashflow nie pochodzi z nowej sprzedaży, tylko z tego, co już jest "prawie gotowe". Wdrożenie prostego rytuału raz w tygodniu (np. 45 minut):

• lista faktur do wystawienia,
• lista blokad po stronie klienta,
• właściciel każdej blokady i termin.

To brzmi banalnie, ale jest zaskakująco skuteczne, bo uderza w realny problem: rozmytą odpowiedzialność za pieniądze.

Narzędzia decyzyjne: krótka tabela, która porządkuje portfel projektów

Jeśli masz wiele tematów naraz, podejmuj decyzje na danych. Poniższa tabela jest prosta, ale bardzo pomaga w rozmowach z zespołem i klientami.

Case study (anonimowe): software house z Torunia, który tracił płynność na "dobrych" projektach

Przykład z praktyki (dane zmienione, mechanizm realny).

Spółka z Torunia (ok. 22 osoby: dev, QA, PM, sprzedaż) realizowała kilka projektów fixed price dla klientów z Polski i UE. W papierach firma "rosła", bo backlog wyglądał solidnie. Problem pojawił się, gdy dwa projekty weszły w fazę intensywnych zmian, a akceptacja po stronie klienta zaczęła się przeciągać. WIP rósł, faktury wystawiano z opóźnieniem, a zespół dokładał poprawki bez formalnych zmian zakresu.

Co zrobiono w 30 dni:

1. Wprowadzono 13-tygodniowy cashflow i stały rytm decyzyjny: jedna osoba zatwierdza płatności, druga pilnuje faktur i akceptacji.
2. Przejrzano portfel projektów według prostego kryterium: marża, ryzyko, blokady. Jeden projekt zatrzymano w trybie stop-loss do czasu podpisania aneksu.
3. Zmieniono zasady zmian: każda zmiana funkcji po akceptacji wymagała wyceny i potwierdzenia. Klienci zaakceptowali to szybciej, gdy zobaczyli raport godzin i konsekwencje dla harmonogramu.
4. Zamknięto "dziury" w fakturowaniu: część prac przeniesiono na cykl miesięczny (utrzymanie), a protokoły akceptacji ustandaryzowano.
5. Ustabilizowano delivery: ograniczono liczbę równoległych tematów, dodano jasne definition of done i kryteria gotowości do faktury.

Efekt: firma odzyskała przewidywalność tygodniową, a rozmowy z wierzycielami przestały dotyczyć emocji. Co ważne, nie oparto planu na masowych cięciach, tylko na przywróceniu marży i dyscypliny kontraktowej.

Podobny schemat (ale przy innej strukturze kosztów i ryzyk) opisałem w artykule o restrukturyzacji firmy transportowej w Toruniu.

Czy w IT warto iść w formalną restrukturyzację?

W branży IT większość problemów da się rozwiązać ugodami i uporządkowaniem cashflow, jeśli firma ma jeszcze sterowność operacyjną. Formalne postępowania restrukturyzacyjne (np. postępowanie o zatwierdzenie układu, przyspieszone postępowanie układowe) mają sens wtedy, gdy:

• presja egzekucyjna rośnie (grożą zajęcia, wypowiedzenia kluczowych umów),
• wierzycieli jest wielu i trudno z nimi uzgodnić spójne warunki,
• firma potrzebuje czasu, żeby dokończyć projekty i odzyskać należności,
• istnieje realny plan spłaty oparty o przyszłe przepływy (a nie o "nadzieję").

Warto pamiętać o specyfice IT: największym aktywem są ludzie i kontrakty. Każde postępowanie, nawet najlepsze, nie zastąpi działań operacyjnych. Jeśli nie domykasz do faktury, nie policzyłeś marży i nie opanowałeś WIP, to formalna procedura tylko odsunie problem.

FAQ – restrukturyzacja firmy informatycznej (Toruń i okolice)

Ile trwa restrukturyzacja software house?
Pierwsze efekty (odzyskanie kontroli nad cashflow i fakturowaniem) zwykle widać w 2–6 tygodni. Uporządkowanie portfela projektów, procesów delivery i modelu sprzedaży to najczęściej 3–6 miesięcy systematycznej pracy.

Czy restrukturyzacja firmy IT oznacza zwolnienia?
Nie zawsze. W praktyce najpierw naprawia się marżę i fakturowalność: zarządzanie zmianą, WIP, wycena, warunki płatności. Dopiero gdy model po tych zmianach nadal nie spina się na liczbach, podejmuje się decyzje personalne.

Jakie są najczęstsze błędy w restrukturyzacji firmy informatycznej?
Najczęściej: brak 13-tygodniowego cashflow, dopłacanie do fixed price bez formalnych zmian, brak time trackingu lub dane "pod klienta", zbyt wiele równoległych projektów i brak osoby odpowiedzialnej za domykanie do faktury.

Co powiedzieć klientowi, gdy chcesz podnieść stawkę albo zmienić model rozliczeń?
Najlepiej rozmawiać na danych: raport godzin, różnica między zakresem a zmianami, ryzyka dla terminu i jakości. Badania o projektach IT pokazują, że niekontrolowany zakres jest jedną z głównych przyczyn porażek. Zmiana zasad to w praktyce ochrona projektu, a nie "szukanie zysku".

Kiedy warto rozważyć formalne postępowanie zamiast ugód?
Gdy jest wielu wierzycieli, pojawia się ryzyko wypowiedzeń kluczowych umów albo egzekucji, a firma potrzebuje czasu na dokończenie projektów i odzyskanie należności. Warunkiem jest jednak realny plan spłaty i dyscyplina operacyjna.

Dane i źródła, na których warto się oprzeć (bez linków)

Jeżeli chcesz podeprzeć plan restrukturyzacji firmy IT twardymi danymi (w rozmowach z bankiem, inwestorem, wierzycielami lub klientem), warto korzystać z cyklicznych, weryfikowalnych źródeł:

• raporty NBP o kondycji sektora przedsiębiorstw (płynność, bariery, zatory)
• dane GUS i Eurostat (wynagrodzenia, zatrudnienie, dynamika kosztów)
• raporty PMI o przyczynach niepowodzeń projektów (zakres, komunikacja, ryzyko)
• badania Standish Group (CHAOS) jako punkt odniesienia do ryzyk projektowych w IT
• raporty DORA (State of DevOps) o wpływie praktyk inżynieryjnych na niezawodność i szybkość dostarczania

Podsumowanie

Restrukturyzacja firmy informatycznej w Toruniu jest do zrobienia, jeśli zaczniesz od liczb, a nie od intuicji. Ustaw 13-tygodniowy cashflow, odzyskaj kontrolę nad WIP i akceptacją, policz prawdziwą rentowność projektów i wprowadź zarządzanie zmianą w umowach. Dopiero na tej bazie negocjuj dług i zdecyduj, czy wystarczą ugody, czy potrzebujesz formalnej ochrony. W IT wygrywa nie ten, kto "ma najwięcej pracy", tylko ten, kto najszybciej domyka wartość do gotówki.