Software house z Warszawy może przygotować układ, jeżeli najpierw wykaże, że po opłaceniu bieżącego zespołu, podwykonawców B2B, chmury, licencji, podatków, ZUS i kosztów realizacji projektów zostaje powtarzalna gotówka dla wierzycieli. W praktyce restrukturyzacja przedsiębiorstwa w Warszawie nie powinna zaczynać się od deklaracji wysokiej raty, lecz od oddzielenia podpisanego backlogu, czyli zakontraktowanego portfela prac, od niepewnego pipeline'u, czyli szans sprzedażowych. Równie ważne jest odróżnienie przychodu od wpływu oraz rentownego projektu od projektu, który tylko zajmuje zespół.
Najważniejsze są cztery dane: które umowy rzeczywiście obowiązują, kiedy klient zaakceptuje pracę, ile kosztuje jej dokończenie oraz kiedy pieniądze znajdą się na rachunku. Abonament miesięczny może być stabilnym źródłem wpływów, ale nie wtedy, gdy klient może szybko ograniczyć zakres albo zespół wykonuje w tej samej cenie coraz więcej pracy. Projekt fixed price, czyli rozliczany ryczałtowo, może mieć wysoką wartość umowną, lecz pogarszać płynność, jeżeli poprawki i opóźnione odbiory pochłaniają marżę. T&M, czyli rozliczenie według czasu i zaangażowanych zasobów, może być przewidywalne tylko przy potwierdzonym zapotrzebowaniu na godziny i rzeczywistym obłożeniu specjalistów.
Układ nie zastąpi rentownej realizacji projektów. Może zmienić sposób spłaty zadłużenia historycznego, ale nowe faktury B2B, wynagrodzenia, daniny i usługi potrzebne do wykonania kontraktów muszą mieć bieżące finansowanie. Jeżeli pierwsza rata ma zostać zapłacona kosztem nowych zaległości wobec programistów, dostawcy chmury albo urzędu, plan nie rozwiązuje problemu — przenosi go na kolejną grupę wierzycieli.
Poniższe uwagi odnoszą się do stanu prawnego na 28 października 2026 r., w szczególności do Prawa restrukturyzacyjnego według tekstu jednolitego Dz.U. 2026 poz. 533, uwzględniającego także zmiany obowiązujące od 23 sierpnia 2025 r. Tekst nie zastępuje analizy konkretnej spółki, umów, praw do kodu, wierzytelności spornych, dnia układowego ani wyboru postępowania. Porządkuje dane operacyjne i finansowe, które zarząd powinien przygotować przed rozmową o układzie.
Punktem wyjścia nie jest suma wystawionych faktur ani wartość całego portfela umów. Software house powinien policzyć gotówkę możliwą do uzyskania po wykonaniu konkretnych prac i po spełnieniu warunków odbioru. Dopiero od tej kwoty odejmuje się bieżące koszty realizacji projektów, koszty stałe, podatki, ZUS i bufor na odchylenia. To, co zostaje, wyznacza maksymalną przestrzeń na raty układowe.
Najprostszy model decyzyjny wygląda tak:
realne wpływy po odbiorach – bieżący koszt zespołu i infrastruktury – daniny – bufor płynności = środki potencjalnie dostępne na układ
Każdy element tego równania wymaga korekty o czas. Jeżeli podwykonawca B2B wystawia fakturę co miesiąc, a klient płaci dopiero po odbiorze etapu, firma finansuje projekt przed otrzymaniem wynagrodzenia. Jeżeli duża przedpłata od klienta wpłynęła wcześniej, nie można ponownie traktować jej jako przyszłego źródła rat. Jeżeli faktura została wystawiona, lecz klient kwestionuje zakres prac, nie powinna być wpisana jako pewny wpływ do podstawowego wariantu przepływów pieniężnych (cash flow).
| Pytanie kontrolne | Odpowiedź pozwalająca pracować nad układem | Sygnał do korekty |
|---|---|---|
| Czy źródło wpływu jest podpisane? | istnieje umowa lub potwierdzone zamówienie z określonym zakresem | wpływ wynika głównie z oferty, rozmowy albo szansy w CRM |
| Czy prace da się wykonać? | zespół i podwykonawcy są dostępni, a koszt został policzony | plan zakłada pełne obłożenie lub pracę osób, które mogą odejść |
| Czy klient odbierze etap? | kryteria odbioru są znane, a sporne elementy wyjaśnione | brak protokołu, zaległe poprawki albo otwarty spór o zakres |
| Czy termin wpływu jest realistyczny? | wynika z umowy i historii płatniczej klienta | plan utożsamia datę faktury z datą przelewu |
| Czy po kosztach zostaje bufor? | firma utrzymuje działalność także przy opóźnieniu części wpływów | pierwsze odchylenie tworzy nowe zaległości bieżące |
Czerwona flaga: raty mają być finansowane przede wszystkim z niepodpisanego pipeline'u, przyszłego projektu bez uzgodnionego startu albo faktur zależnych od spornego odbioru. To nie jest zakontraktowana gotówka, tylko wariant sprzedażowy.
Wniosek praktyczny: układ warto dalej projektować dopiero wtedy, gdy można prześledzić drogę od podpisanej umowy, przez wykonanie i odbiór, aż do konkretnego wpływu na rachunek. Jeżeli któregokolwiek etapu brakuje, prognozę trzeba obniżyć albo przesunąć w czasie.
W software house'ach kilka modeli rozliczeń może działać równolegle. Każdy inaczej wpływa na płynność, marżę i wiarygodność propozycji dla wierzycieli. Dlatego przychodów nie należy wpisywać do jednego wiersza „sprzedaż”. Trzeba rozdzielić je co najmniej na abonamenty lub stałe opłaty za gotowość i zakres usług (retainery), T&M oraz projekty fixed price.
Abonament za utrzymanie, rozwój, obsługę serwisową albo określoną pulę godzin może stabilizować wpływy, jeśli umowa trwa, zakres jest kontrolowany, a klient płaci zgodnie z historią współpracy. Trzeba jednak sprawdzić okres i podstawy wypowiedzenia, możliwość ograniczenia zamówienia, niewykorzystane pule godzin, gwarantowane parametry obsługi (SLA), koszt dyżurów oraz to, czy zakres usługi nie urósł bez zmiany ceny.
Przychód powtarzalny nie powinien obejmować jednorazowej przedpłaty tylko dlatego, że dotyczy dłuższego okresu. Przedpłata może poprawić gotówkę w miesiącu wpływu, ale część środków nadal finansuje przyszłe świadczenia. Jeśli firma wyda ją na stare zadłużenie, może później nie mieć pieniędzy na wykonanie usługi już opłaconej przez klienta.
W modelu time and materials przychód zależy zwykle od liczby zaakceptowanych godzin i uzgodnionej stawki. Sama dostępność programistów nie tworzy sprzedaży. Do backlogu powinny wejść godziny wynikające z aktualnego zapotrzebowania klienta, zleconego zakresu albo wiarygodnego planu sprintów, a nie maksymalna pojemność całego zespołu.
Trzeba również uwzględnić urlopy, pracę wewnętrzną, działania przedsprzedażowe (presales), zarządzanie, przestoje między projektami oraz limit godzin, który klient rzeczywiście zaakceptuje. Jeżeli prognoza zakłada, że każda dostępna godzina będzie fakturowalna, przeszacowuje zarówno przychód, jak i gotówkę.
W projekcie ryczałtowym wartość umowy jest tylko początkiem analizy. Należy zestawić pozostałe wynagrodzenie z kosztem dokończenia, zakresem poprawek, zmianami wymagań, kryteriami odbioru, karami, terminami oraz pracą niewyfakturowaną. Szczególnie ryzykowny jest projekt, w którym część ceny już wpłynęła i została wydana, natomiast największy koszt zespołu oraz odbiór końcowy są jeszcze przed firmą.
| Model | Co może potwierdzać przychód | Kiedy powstaje gotówka | Koszt, którego nie wolno pominąć | Główna czerwona flaga |
|---|---|---|---|---|
| Abonament lub retainer | aktywna umowa, zakres, historia odnowień i płatności | zgodnie z cyklem fakturowania i terminem przelewu | stała gotowość, SLA, dyżury, rosnący zakres prac | klient łatwo ogranicza usługę albo koszt obsługi przekracza cenę |
| T&M | potwierdzone zapotrzebowanie, plan sprintów, zamówiona pula godzin | po wykonaniu, raportowaniu i akceptacji godzin | czas bez projektu (bench), praca niefakturowalna, urlopy, zarządzanie | pełna dostępność zespołu jest traktowana jak sprzedane godziny |
| Fixed price | podpisany zakres, kamienie milowe, protokoły i harmonogram | po spełnieniu warunku fakturowania i zapłacie klienta | poprawki, zmiany zakresu bez aneksu, opóźnienia i koszt dokończenia | pozostałe wynagrodzenie jest niższe niż koszt ukończenia projektu |
| Utrzymanie po wdrożeniu | umowa serwisowa, baza aktywnych klientów, rzeczywisty zakres | cyklicznie albo po zgłoszeniach, zależnie od umowy | infrastruktura, obsługa serwisowa, bezpieczeństwo i usuwanie błędów | firma finansuje dawny błąd projektowy w ramach stałej opłaty |
Po zbudowaniu tabeli każdy kontrakt powinien dostać jedną z czterech decyzji: utrzymać bez zmian, renegocjować cenę lub zakres, domknąć w kontrolowany sposób albo wyłączyć z podstawowej prognozy. Nie chodzi o rezygnację z każdego trudnego projektu. Chodzi o to, aby wierzyciele nie otrzymali harmonogramu opartego na kontraktach, które konsumują gotówkę zamiast ją tworzyć.
Decyzja: abonament warto liczyć jako stabilny rdzeń dopiero po sprawdzeniu zakresu i możliwości jego utrzymania. T&M warto przyjmować według realnie zamówionych godzin. Fixed price powinien wejść do prognozy po aktualizacji kosztu dokończenia, a nie według pierwotnego budżetu projektu.
Budżet sprzedażowy pokazuje, ile firma chce osiągnąć. Prognoza na potrzeby układu ma pokazać, ile prawdopodobnie wykona, zafakturuje i otrzyma w gotówce. To dwa różne dokumenty. Wierzyciel potrzebuje drugiego, ponieważ rat nie spłaca się celem handlowym ani wartością szans w CRM.
Dobra prognoza software house'u składa się z czterech warstw:
Backlog ma zwykle wyższą wiarygodność niż pipeline, ale również wymaga korekty. Umowa ramowa bez zamówionej puli prac nie jest tym samym co potwierdzony projekt. Kontrakt może przewidywać wypowiedzenie, ograniczenie zespołu albo odbiory zależne od decyzji klienta. Dlatego przy każdym wierszu backlogu trzeba wskazać nie tylko wartość, lecz także warunek utrzymania przychodu.
Pipeline może pokazać potencjał odbudowy sprzedaży, ale nie powinien finansować najbliższych rat w wariancie podstawowym. Wartościowanie szans powinno wynikać z danych firmy: etapu rozmów, dotychczasowej konwersji, czasu od oferty do startu i dostępności zespołu. Jeżeli software house nie ma takich danych, bezpieczniej pokazać pipeline osobno niż ukrywać go w jednej kwocie z podpisanym backlogiem.
| Warstwa prognozy | Dane wejściowe | Korekta ostrożna | Decyzja dla układu |
|---|---|---|---|
| Podpisane abonamenty | aktywne umowy, terminy, zakres, historia płatności | możliwe ograniczenie, wypowiedzenie lub wzrost kosztu obsługi | rdzeń prognozy, jeżeli marża i ciągłość są potwierdzone |
| Backlog projektowy | zamówiony zakres, etapy, budżet, plan zasobów | opóźniony start, poprawki, odbiór i koszt dokończenia | baza prognozy po rozpisaniu na wykonanie i wpływy |
| Pipeline | CRM, oferty, etap rozmów, własna konwersja | późniejszy start, przegrana części szans, brak dostępnego zespołu | scenariusz dodatkowy, nie jedyne źródło rat |
| Pojemność zespołu | dostępne osoby, kompetencje, kalendarz, stawki | urlopy, czas bez projektu, praca wewnętrzna, odejścia | górna granica możliwej sprzedaży, nie sam przychód |
| Należności | faktury, odbiory, terminy, historia klienta | opóźnienie, potrącenie, reklamacja lub spór | wpływ dopiero po ocenie ściągalności i czasu |
Wariant bazowy powinien obejmować zdarzenia najbardziej prawdopodobne, a nie wszystkie korzystne naraz. Wariant słabszy ma sprawdzić, czy firma nadal zapłaci bieżące zobowiązania oraz ratę, gdy wystąpi jedno lub kilka realistycznych odchyleń:
Test nie powinien kończyć się na wyniku rocznym. Software house może być rentowny w skali roku, a jednocześnie nie mieć gotówki w miesiącu wypłat i raty układowej. Potrzebny jest co najmniej miesięczny cash flow, a w okresie napiętej płynności także krótszy widok operacyjny, który pokazuje terminy wynagrodzeń, B2B, podatków, ZUS, infrastruktury, wpływów i rat.
Po policzeniu nadwyżki trzeba osobno sprawdzić, czy firma udźwignie raty układu także w słabszym okresie. Jeżeli rata mieści się tylko w wariancie bazowym, harmonogram jest zbyt kruchy. Jeżeli po racie nie zostaje bufor na opóźniony odbiór albo utratę części obłożenia, firma może wrócić do zaległości już przy pierwszym odchyleniu.
Czerwona flaga: prognoza przychodów równa się celowi sprzedaży, wszystkie osoby mają pełne obłożenie, każdy projekt jest odbierany terminowo, a wszystkie faktury wpływają zgodnie z terminem. Taki model nie pokazuje ryzyka wykonania układu.
Wniosek praktyczny: wierzycielom należy pokazać osobno przychód podpisany, potencjalny i warunkowy oraz przejście od pracy do gotówki. Raty powinny wytrzymać wariant słabszy bez opóźniania nowych zobowiązań.
W software house'ach podwykonawca B2B może być jednocześnie wierzycielem i osobą niezbędną do dokończenia kontraktu. Sama lista zaległych faktur nie pokazuje więc pełnego ryzyka. Trzeba ustalić, przy którym projekcie dana osoba pracuje, czy można ją zastąpić, jaki ma dostęp do repozytorium i infrastruktury, jakie obowiązują zasady wypowiedzenia oraz kiedy i pod jakim warunkiem przechodzą prawa do rezultatów pracy.
Pierwszy podział dotyczy zaległości historycznych i nowych świadczeń. Ich prawne traktowanie zależy między innymi od daty powstania wierzytelności, dnia układowego, treści umowy i wybranego postępowania. Nie wolno zakładać, że firma może dowolnie spłacać wybrane stare faktury tylko dlatego, że dotyczą ważnego programisty. Jednocześnie plan, który nie przewiduje pieniędzy na nowe, bieżące prace konieczne do wykonania kontraktu, nie ma operacyjnego źródła spłaty.
| Pole w mapie B2B | Co ustalić | Dlaczego wpływa na układ |
|---|---|---|
| Saldo historyczne | faktury, terminy, odsetki, spory i uzgodnienia | pokazuje pozycję podwykonawcy jako wierzyciela |
| Prace bieżące | zakres, stawka, harmonogram i nowe faktury | określa gotówkę potrzebną do dalszej realizacji projektów |
| Projekt i etap | klient, kamień milowy, zaległe zadania i odbiór | pozwala ocenić, czy odejście zatrzyma fakturowanie |
| Zastępowalność | dokumentacja, dostępność kompetencji i czas wdrożenia | pokazuje koszt oraz ryzyko przerwy |
| Wypowiedzenie i wstrzymanie prac | uprawnienia stron wynikające z umowy i aktualny status współpracy | pozwala ocenić, czy prognoza zakłada niepewną ciągłość |
| Prawa do kodu | zasady przeniesienia praw, pola eksploatacji, warunki płatności | brak praw może zablokować odbiór lub przekazanie rezultatu klientowi |
| Dostępy i wiedza | repozytoria, chmura, klucze, dokumentacja, proces przekazania | odejście jednej osoby nie może odciąć firmy od projektu |
Szczególnej kontroli wymaga sytuacja, w której przeniesienie autorskich praw majątkowych jest powiązane z zapłatą wynagrodzenia. Zaległa faktura może wtedy mieć znaczenie nie tylko płynnościowe. Jeżeli software house nie uzyskał praw potrzebnych do przekazania rozwiązania klientowi, może nie spełnić warunków odbioru, a planowany wpływ nie pojawi się w terminie. To wymaga analizy konkretnych umów z podwykonawcą i klientem, a nie ogólnego założenia, że kod znajdujący się w firmowym repozytorium należy do spółki.
Niebezpieczne jest również utrzymywanie dwóch różnych wersji planu. W prognozie dla wierzycieli podwykonawcy pozostają i kończą projekty, natomiast w rozmowach z nimi firma nie potrafi wyjaśnić zasad płatności bieżących, dalszego zakresu ani statusu zaległości. Bez operacyjnego planu współpracy prognoza może stracić zespół, na którym została zbudowana.
Czerwona flaga: przychód z kluczowego projektu jest wpisany jako pewny, ale specjalista odpowiedzialny za jego ukończenie ma zaległe faktury, może zakończyć współpracę, nie przekazał dokumentacji albo umowa uzależnia przejście praw od zapłaty.
Decyzja: każdego kluczowego podwykonawcę trzeba ująć jednocześnie w mapie wierzycieli i planie realizacji projektów. Jeżeli firma nie potrafi sfinansować nowych prac albo zabezpieczyć praw, dokumentacji i dostępu, wpływ z danego projektu powinien zostać obniżony lub przesunięty w prognozie.
Software house często finansuje pracę przed otrzymaniem pieniędzy od klienta. Wynagrodzenia i faktury podwykonawców mają stałe terminy, podczas gdy rozliczenie z klientem zależy od raportu godzin, odbioru sprintu, kamienia milowego, wdrożenia albo usunięcia błędów. Dlatego należności od klientów trzeba analizować według jakości i czasu, a nie tylko sumy.
Najpierw należy przygotować wiekowanie: faktury przed terminem, krótko po terminie, istotnie opóźnione oraz sporne. Sam wiek nie wystarczy. Przy każdej pozycji trzeba wskazać, czy klient odebrał pracę, czy zgłosił reklamację, czy istnieje ryzyko potrącenia, kary lub korekty, kto po jego stronie zatwierdza płatność i jak wyglądała dotychczasowa historia przelewów.
| Status należności | Co sprawdzić | Jak traktować w prognozie |
|---|---|---|
| Faktura przed terminem | odbiór, brak zastrzeżeń, historia płatności | według realistycznego dnia wpływu, nie daty wystawienia |
| Faktura po terminie, niesporna | potwierdzenie salda i deklarowaną datę przelewu | ostrożnie, z wariantem dalszego opóźnienia |
| Należność zależna od odbioru | kryteria akceptacji, listę poprawek i osobę decyzyjną | dopiero po oszacowaniu czasu i kosztu domknięcia |
| Należność sporna | podstawę sporu, potrącenia, kary, reklamację i dokumentację | poza pewnym źródłem najbliższych rat |
| Przyszły etap | zakres pozostałych prac, koszt, termin i warunek faktury | jako przyszły wpływ po uwzględnieniu wykonania |
Kolejnym testem jest koncentracja. Jeżeli duża część wpływów pochodzi od jednego klienta, nie wystarczy stwierdzić, że umowa nadal obowiązuje. Trzeba sprawdzić możliwość ograniczenia zespołu, zakończenia projektu, zmianę budżetu po stronie klienta, osoby odpowiedzialne za odbiór oraz to, czy firma ma alternatywę w razie opóźnienia. Koncentracja może dotyczyć nie tylko przychodu, lecz także gotówki: kilku klientów może generować sprzedaż, ale jeden przelew może decydować o wypłatach i racie.
Przed układem warto również przejrzeć mechanikę umów. Zaliczka, krótszy etap, częstsze rozliczenia T&M, jasny protokół odbioru albo osobna wycena zmiany zakresu mogą ograniczyć lukę między kosztem pracy a wpływem. Nie każda zmiana będzie możliwa, ale bez tej analizy firma może bronić harmonogramu projektu, który systemowo pogarsza jej płynność.
Czerwona flaga: należności są wykazane jako aktywo i źródło spłaty, ale firma nie ma potwierdzonych odbiorów, aktualnego statusu reklamacji ani dat uzgodnionych z osobami odpowiedzialnymi za płatność po stronie klientów.
Wniosek praktyczny: do podstawy rat powinny wejść tylko wpływy, dla których da się obronić wykonanie, odbiór i termin płatności. Należność sporna albo zależna od niezamkniętego zakresu może być scenariuszem dodatkowym, ale nie powinna finansować pierwszych rat.
Po uporządkowaniu przychodów, projektów, B2B i należności można przejść do propozycji układowych. Ich konstrukcja wymaga analizy prawnej i finansowej, ale logika ekonomiczna pozostaje czytelna: harmonogram powinien odpowiadać nadwyżce gotówkowej, a nie maksymalnej kwocie, którą zarząd chce obiecać w negocjacjach.
Równa miesięczna rata nie zawsze pasuje do software house'u. Wpływy mogą zależeć od większych odbiorów etapowych, odnowień abonamentów albo cyklu budżetowego klientów. Nie oznacza to, że każdą nieregularność trzeba przenieść do propozycji. Oznacza, że harmonogram powinien być sprawdzony względem rzeczywistych dat wpływów i kosztów, a firma musi posiadać bufor na okres pomiędzy wykonaniem pracy a zapłatą.
Przed ustaleniem rat trzeba rozdzielić co najmniej cztery koszyki gotówki:
Jeżeli środki z pierwszych trzech koszyków zostaną wpisane do rat, software house może wykonać płatność wierzycielom, ale utracić możliwość dokończenia projektów generujących kolejne wpływy. Taki harmonogram wygląda atrakcyjnie tylko na początku.
Wierzyciel nie potrzebuje pełnego dostępu do repozytoriów ani danych klientów. Powinien jednak otrzymać spójne wyjaśnienie, z czego układ będzie wykonywany. Pakiet powinien odpowiadać na to, co wierzyciel chce zobaczyć w planie firmy:
Postępowanie o zatwierdzenie układu może być jednym z analizowanych trybów, lecz nie powinno być wybierane automatycznie tylko dlatego, że firma chce szybko zatrzymać presję wierzycieli. Trzeba ocenić między innymi skalę wierzytelności spornych, egzekucje, zabezpieczenia, umowy krytyczne, potrzebę głębszych działań naprawczych i zdolność do regulowania nowych zobowiązań. Skutki obwieszczenia, zakres ochrony i kwalifikację poszczególnych wierzytelności należy ustalić dla konkretnej sprawy.
Podobnie nie można z góry przesądzić, czy poszczególni podwykonawcy, dostawcy infrastruktury, banki, wierzyciele publicznoprawni i pozostali kontrahenci powinni otrzymać identyczne propozycje. Ewentualne grupy i różnice wymagają obiektywnego uzasadnienia prawnego i ekonomicznego. Operacyjna ważność wierzyciela jest istotną informacją, ale sama nie daje prawa do dowolnego uprzywilejowania.
Wniosek praktyczny: propozycje układowe powinny pokazywać nie tylko kwoty i terminy, lecz cały mechanizm dojścia do gotówki. Jeżeli wierzyciel nie może prześledzić drogi od backlogu przez realizację projektu i odbiór do nadwyżki, harmonogram wymaga dalszej pracy.
Nie każdy software house z zadłużeniem ma gotową podstawę do układu. Czasem przed formalnym krokiem trzeba najpierw ograniczyć straty na projektach, renegocjować umowy, ustabilizować zespół lub odzyskać kontrolę nad należnościami. Samo rozłożenie historycznego długu nie pomoże, jeśli firma nadal traci na każdej kolejnej iteracji.
Za szczególnie niebezpieczne należy uznać następujące sytuacje:
Formalny układ nie naprawi automatycznie tych problemów. Jeśli projekt jest nierentowny, trzeba zmienić zakres, cenę, harmonogram albo sposób jego zakończenia. Jeśli przychód zależy od jednej osoby, trzeba zabezpieczyć wiedzę, dostęp i zastępowalność. Jeśli pipeline jest niepewny, należy obniżyć ratę lub odsunąć założenie sprzedażowe od podstawowego źródła spłaty.
Sytuacja, w której nie warto składać wysokiej obietnicy: firma nie ma dodatniej nadwyżki nawet w wariancie bazowym, ale zakłada, że po rozpoczęciu restrukturyzacji szybko podpisze nowe projekty i w ten sposób sfinansuje bieżące koszty oraz raty. Bez potwierdzonego źródła gotówki taka propozycja może tylko zwiększyć nowe zadłużenie.
Decyzja: jeżeli czerwone flagi dotyczą pojedynczych kontraktów, należy je skorygować i ponownie policzyć cash flow. Jeżeli dotyczą całego modelu — braku marży, braku bieżącej płynności i odpływu kluczowego zespołu — trzeba zatrzymać projektowanie rat i przeanalizować głębszą zmianę działalności albo inną ścieżkę prawną.
Zarząd software house'u powinien przejść przez poniższą sekwencję przed przedstawieniem wierzycielom propozycji. Kolejność ma znaczenie: wysokość rat jest wynikiem analizy, a nie jej pierwszym założeniem.
Po przejściu tej listy możliwe są trzy wnioski.
Działać: podpisane abonamenty i rentowny backlog tworzą nadwyżkę także w wariancie słabszym, firma reguluje nowe zobowiązania i potrafi utrzymać zespół potrzebny do realizacji projektów.
Skorygować: podstawowa działalność może zarabiać, ale część projektów ma złą marżę, terminy wpływów nie pasują do rat, pipeline jest przeszacowany albo zaległości B2B zagrażają ciągłości. Najpierw trzeba zmienić założenia, a potem ponownie policzyć propozycje.
Zatrzymać plan i przeanalizować inną ścieżkę: firma tworzy nowe zaległości, traci kluczowych klientów lub specjalistów, nie ma dodatniej nadwyżki nawet przed ratami albo nie jest w stanie dokończyć projektów, na których oparto prognozę.
Wniosek praktyczny: gotowość do układu nie wynika z samej wysokości zadłużenia. Wynika z jakości podpisanych przychodów, kontroli kosztu realizacji projektów, zdolności utrzymania zespołu i dodatniej gotówki po bieżących zobowiązaniach.
Software house z Warszawy powinien przygotować układ od strony operacyjnej jeszcze przed ustaleniem rat. Najpierw trzeba rozdzielić abonamenty, T&M i fixed price, zaktualizować koszt dokończenia projektów, zbudować backlog i pipeline jako osobne warstwy, a następnie przełożyć odbiory oraz terminy płatności na cash flow.
Drugim filarem jest ciągłość. Podwykonawcy B2B, prawa do kodu, dokumentacja, chmura i kluczowe kompetencje nie są dodatkiem do planu finansowego. To warunki wystawienia kolejnych faktur. Jeżeli nie mają finansowania albo są objęte nierozwiązanym sporem, prognoza przychodów musi pokazać to ryzyko.
Układ ma ekonomiczny sens wtedy, gdy po bieżących kosztach i buforze zostaje powtarzalna nadwyżka także w wariancie słabszym. Jeżeli raty wymagają pełnego obłożenia, bezbłędnych odbiorów, terminowej zapłaty wszystkich klientów i dalszej pracy nieopłaconych podwykonawców, plan jest zbyt optymistyczny. Wtedy właściwą decyzją nie jest mocniejsza obietnica dla wierzycieli, lecz korekta projektów, kosztów, terminów albo wybór innej ścieżki.
Nasi licencjonowani doradcy restrukturyzacyjni działają na terenie Warszawy i całego Mazowsza. Skontaktuj się z nami — opisz swoją sytuację.
Przejdź do kontaktuWięcej wiedzy o restrukturyzacji firm i układzie z wierzycielami
