Projekt zamknął się w marcu. Aplikacja działa, użytkownicy z niej korzystają, a zespół, który ją budował, przeszedł do innych zadań. We wrześniu dyrektor finansowy prosi CTO o budżet na przyszły rok i zadaje pytanie, na które nikt nie przygotował odpowiedzi: ile kosztuje utrzymanie tego systemu? Na biurku leżą dwie oferty. Pierwszy dostawca proponuje stały abonament miesięczny z SLA, drugi pulę godzin rozliczaną według zużycia. Różnią się kwotą o połowę, a z treści nie da się wyczytać, za co dokładnie się płaci.
To typowa sytuacja, bo utrzymanie jest najmniej widoczną częścią życia aplikacji. Budowę planuje się miesiącami, a utrzymanie często dopisuje się do umowy w ostatnim tygodniu przed wdrożeniem. Tymczasem to właśnie utrzymanie odpowiada za większość kosztów oprogramowania w całym jego cyklu życia, a źle skrojona umowa potrafi kosztować więcej niż samo wsparcie: w przestojach, w eskalacjach i w funkcjach, których nikt nie ma czasu dowieźć.
Ten tekst jest dla CTO, który ma przed sobą decyzję o modelu i budżecie utrzymania. Pokazujemy, z czego składa się koszt, czym różnią się poziomy wsparcia L1–L3, jak policzyć roczny budżet od dołu zamiast zgadywać procent i co musi być w SLA, żeby miało praktyczne znaczenie. Ogólne uzasadnienie, dlaczego utrzymanie jest równie ważne jak budowa, opisaliśmy we wcześniejszym tekście o strategiach wsparcia po wdrożeniu. Tutaj zajmujemy się pieniędzmi i umową.
Z czego składa się koszt utrzymania aplikacji po wdrożeniu?
Słowo „utrzymanie” obejmuje kilka różnych rodzajów pracy, a oferty dostawców często mieszają je w jednej pozycji. Norma ISO/IEC/IEEE 14764, opisująca proces utrzymania oprogramowania, wyróżnia cztery rodzaje utrzymania (zestawienie znajdziesz w rozdziale o utrzymaniu w przewodniku SWEBOK): korygujące, czyli naprawę zgłoszonych błędów; prewencyjne, czyli usuwanie ukrytych usterek, zanim się ujawnią; adaptacyjne, czyli dostosowanie do zmian otoczenia, takich jak nowe wersje systemu operacyjnego, przeglądarek, bibliotek czy API partnerów; oraz doskonalące, czyli ulepszenia i drobne zmiany funkcjonalne.
To rozróżnienie ma bezpośrednie przełożenie na budżet. Utrzymanie korygujące zależy od jakości systemu i jest trudne do przewidzenia. Adaptacyjne jest nieuniknione i rośnie wraz z liczbą zależności: każda biblioteka i każda integracja kiedyś wymaga aktualizacji. Doskonalące jest w praktyce dalszym rozwojem produktu i to ono najczęściej „zjada” budżet utrzymania, bo biznes zawsze ma kolejne prośby.
Robert L. Glass w książce „Facts and Fallacies of Software Engineering” (2002) zebrał wyniki badań w dwóch twierdzeniach: utrzymanie pochłania zwykle od 40 do 80 procent kosztów oprogramowania, a około 60 procent kosztów utrzymania to ulepszenia, a nie naprawa błędów. To dane sprzed ponad dwóch dekad i nie należy ich traktować jak cennika, ale ich wymowa jest aktualna: większość pieniędzy wydanych na utrzymanie idzie na zmiany, których chce biznes, a nie na łatanie.
Do tego dochodzą koszty, które nie są pracą ludzi: hosting i chmura, licencje na oprogramowanie i narzędzia, monitoring, kopie zapasowe, certyfikaty, usługi zewnętrzne. W ofertach utrzymania zwykle ich nie ma, bo opłaca je właściciel systemu, ale w budżecie rocznym muszą się znaleźć.
Pierwszy praktyczny wniosek: zanim porównasz oferty, rozdziel w nich cztery pozycje. Gotowość i reakcję na incydenty, naprawę błędów, aktualizacje techniczne i zmiany funkcjonalne. Dwie oferty, które w jednej kwocie mieszają te pozycje w różnych proporcjach, są nieporównywalne.
Ile kosztuje utrzymanie rocznie i dlaczego procent od kosztu wytworzenia to tylko punkt startu?
Najczęstsza odpowiedź na pytanie o budżet utrzymania brzmi: „przyjmij pewien procent kosztu wytworzenia rocznie”. Podawane w branżowych tekstach wartości mocno się różnią. Nie znaleźliśmy wiarygodnego, aktualnego badania, które potwierdzałoby jakąkolwiek konkretną wartość jako normę rynkową, dlatego traktuj taki procent wyłącznie jako szacunek do pierwszej rozmowy z zarządem, a nie jako podstawę budżetu.
Procent od kosztu wytworzenia ma trzy wady. Po pierwsze, koszt budowy słabo przewiduje koszt utrzymania: dwie aplikacje za tę samą kwotę mogą mieć zupełnie inną liczbę integracji, użytkowników i wymagań dostępności. Po drugie, ignoruje jakość: system bez testów i z dużym długiem technologicznym generuje więcej utrzymania korygującego niż dobrze zbudowany system o tej samej cenie. Po trzecie, nie mówi nic o tym, ile zmian funkcjonalnych chce biznes, a to one zwykle przesądzają o kwocie.
Co realnie przesuwa koszt w górę i w dół? Liczba i stabilność integracji z systemami zewnętrznymi, wymagane godziny wsparcia (dni robocze czy całą dobę), krytyczność systemu dla biznesu, liczba użytkowników i środowisk, wiek technologii i tempo aktualizacji zależności, jakość testów automatycznych i monitoringu oraz to, czy dostawca utrzymania jest tym samym zespołem, który system zbudował. Szczegółowe zestawienie tych czynników znajdziesz w tabeli w dalszej części tekstu.
Dlatego lepszą metodą jest budżet liczony od dołu, z godzin i ról, który pokazujemy w osobnej sekcji. Procent warto policzyć dopiero na końcu, jako test zdrowego rozsądku: jeśli wychodzi Ci kilka procent kosztu budowy przy systemie krytycznym z wieloma integracjami, prawdopodobnie czegoś nie uwzględniłeś.
Czym różnią się poziomy wsparcia L1, L2 i L3?
Podział na poziomy wsparcia pochodzi z praktyki zarządzania usługami IT i służy temu, żeby drogie godziny programistów nie były zużywane na sprawy, które może rozwiązać ktoś inny. Każdy poziom ma inny koszt i inne kompetencje.
L1, pierwsza linia. Przyjmuje zgłoszenia, rejestruje je, ustala priorytet i rozwiązuje proste sprawy według instrukcji: reset hasła, problem z uprawnieniami, pytanie o działanie funkcji. Resztę przekazuje dalej z kompletem informacji. L1 często prowadzi firma we własnym zakresie, bo zna użytkowników i ich procesy, albo zleca ją wyspecjalizowanemu helpdeskowi.
L2, wsparcie aplikacyjne. Diagnozuje problemy w działającym systemie: analizuje logi, dane i konfigurację, odtwarza błędy, obsługuje znane problemy i ich obejścia, wykonuje poprawki danych i czynności administracyjne. L2 musi dobrze znać aplikację, ale nie zawsze zmienia kod.
L3, wsparcie inżynierskie. Programiści, którzy znają kod i architekturę, naprawiają błędy w oprogramowaniu, przygotowują poprawki, wdrażają je i analizują przyczyny źródłowe incydentów. To najdroższy poziom i ten, którego jakość najbardziej wpływa na to, czy te same problemy wracają.
W umowie najważniejsze jest nie samo nazewnictwo, tylko granice między poziomami. Zapisz, kto prowadzi każdy z nich (Twoja firma, dostawca, helpdesk zewnętrzny), jakie informacje musi zawierać zgłoszenie przekazywane wyżej (kroki do odtworzenia, zrzut ekranu, identyfikator użytkownika, czas wystąpienia) i jak szybko poziom wyższy przejmuje sprawę. Niekompletne zgłoszenia odbijane między poziomami potrafią zużyć więcej czasu niż sama naprawa, a w raporcie SLA zwykle tego nie widać, bo zegar zaczyna liczyć się dopiero po przyjęciu zgłoszenia przez dostawcę.
Rozsądny model utrzymania dba o to, żeby do L3 trafiało jak najmniej zgłoszeń, które mogło rozwiązać L1 albo L2. Jeśli w ofercie dostawcy cała obsługa idzie przez programistów, płacisz stawkę L3 za zgłoszenia typu „nie mogę się zalogować”. Jeśli z kolei nie ma w niej L3, to przy pierwszym prawdziwym błędzie w kodzie okaże się, że nikt nie może go naprawić bez osobnego zlecenia. Więcej o procesie obsługi zgłoszeń i eskalacji opisuje hasło zarządzanie incydentami.
Jakie modele rozliczenia utrzymania spotkasz na rynku?
W ofertach utrzymania pojawiają się w praktyce cztery modele i każdy z nich inaczej rozkłada ryzyko między Ciebie a dostawcę.
Abonament ryczałtowy. Stała opłata miesięczna za określony zakres: gotowość, SLA, obsługę zgłoszeń i zwykle limit prac. Daje przewidywalny budżet i zarezerwowaną dostępność. Ryzyko: płacisz także w spokojnych miesiącach, a jeśli zakres jest opisany ogólnie, każda większa sprawa okazuje się „poza abonamentem”.
Pula godzin. Kupujesz z góry określoną liczbę godzin miesięcznie albo kwartalnie, zużywanych na zgłoszenia i zmiany. Ważne są zasady: czy niewykorzystane godziny przechodzą na kolejny okres, jaka jest stawka za godziny ponad pulę i czy pula gwarantuje dostępność w określonym czasie.
Czas i materiały. Płacisz za faktycznie przepracowane godziny, bez stałej opłaty. Najtańszy przy małej liczbie zgłoszeń, ale nie daje żadnej gwarancji, że ktoś będzie dostępny, gdy system przestanie działać w piątek wieczorem.
Model mieszany. Stała, niższa opłata za gotowość i SLA na incydenty plus pula godzin albo rozliczenie godzinowe na zmiany i ulepszenia. W praktyce to najczęściej najzdrowszy układ, bo oddziela dwie rzeczy, które mają różną naturę: ubezpieczenie od awarii i dalszy rozwój produktu.
Podział ryzyka w tych modelach jest analogiczny do tego, który opisaliśmy przy wyborze modelu współpracy w projekcie, w tekście T&M, fixed price czy abonament zespołu. Zasada jest ta sama: im więcej ryzyka bierze na siebie dostawca, tym więcej za to policzy.
Jak policzyć budżet utrzymania od dołu, zamiast zgadywać procent?
Budżet od dołu składa się z trzech warstw: gotowości (kto jest dostępny i w jakich godzinach), pracy (ile godzin miesięcznie zużywają zgłoszenia, aktualizacje i zmiany) oraz kosztów infrastruktury i narzędzi. Poniższe przykłady pokazują metodę, nie są cennikiem żadnego dostawcy. Jako podstawę przyjmujemy stawki z naszego benchmarku na 2026 rok: senior backend developer 180–260 zł netto za godzinę, senior DevOps 200–280 zł netto za godzinę.
Przykład 1: aplikacja wewnętrzna, wsparcie w dni robocze. System dla kilkudziesięciu użytkowników, kilka integracji, wsparcie w godzinach pracy. L1 prowadzi firma, a dostawca zapewnia L2/L3 w puli 40 godzin miesięcznie. Przy stawce seniora to 7 200–10 400 PLN miesięcznie, czyli 86 400–124 800 PLN rocznie, do tego hosting i licencje.
Przykład 2: aplikacja dla klientów, większy ruch. System sprzedażowy lub obsługowy z kilkunastoma integracjami, częstymi aktualizacjami zależności i regularnymi zmianami. Dostawca zapewnia 80 godzin programisty i 40 godzin DevOps miesięcznie. To 14 400–20 800 PLN plus 8 000–11 200 PLN, razem 22 400–32 000 PLN miesięcznie, czyli 268 800–384 000 PLN rocznie, bez infrastruktury i bez dyżuru poza godzinami pracy.
Skąd wziąć liczbę godzin? Najlepiej z historii. Jeśli system działa już kilka miesięcy, policz zgłoszenia według priorytetów i średni czas ich obsługi, dodaj czas na aktualizacje zależności i na zmiany, które biznes już zgłosił. Jeśli historii nie ma, przyjmij wyższą pulę na pierwsze pół roku i skoryguj ją po kwartale. Pierwsze miesiące po wdrożeniu prawie zawsze generują więcej zgłoszeń niż kolejne.
Osobno zaplanuj okres tuż po wdrożeniu, często nazywany hypercare. Przez pierwsze tygodnie użytkownicy odkrywają przypadki, których nie przewidziały testy, dane z migracji ujawniają niespójności, a integracje po raz pierwszy pracują pod prawdziwym obciążeniem. W tym okresie potrzebujesz większej dostępności zespołu, który system budował, niż w docelowym rytmie utrzymania. Jeśli umowa przechodzi z projektu prosto na minimalną pulę godzin, pierwsze tygodnie zjedzą budżet kwartału, a reszta zgłoszeń będzie czekać w kolejce.
Nie zapominaj też o warstwie gotowości. Pula godzin mówi, ile pracy kupujesz, ale nie mówi, jak szybko ktoś usiądzie do zgłoszenia. Jeśli potrzebujesz gwarantowanego czasu reakcji, dostawca musi trzymać kogoś w rezerwie także wtedy, gdy zgłoszeń nie ma, i zapłacisz za to w opłacie stałej albo w wyższej stawce. To uczciwy koszt, pod warunkiem że jest jawnie nazwany w ofercie, a nie ukryty w ogólnej kwocie abonamentu.
Na koniec policz procent od kosztu wytworzenia jako test. Jeśli budowa w przykładzie 1 kosztowała 600 000 PLN, roczny budżet utrzymania wychodzi na około 14–21 procent. To nie jest norma rynkowa, tylko wynik tego konkretnego wyliczenia, ale pozwala sprawdzić, czy oferta dostawcy nie odbiega rażąco od tego, czego realnie potrzebujesz.
Co powinno być w SLA, żeby miało praktyczne znaczenie?
SLA w wielu ofertach utrzymania wygląda imponująco i nie znaczy prawie nic. Najczęstszy problem: dokument określa czas reakcji, czyli czas, w którym dostawca potwierdzi przyjęcie zgłoszenia, ale nie mówi nic o tym, kiedy problem zostanie rozwiązany albo obejściem ograniczony. „Reakcja w 30 minut” może oznaczać automatyczną odpowiedź z systemu zgłoszeń.
Dobre SLA zawiera definicje priorytetów z przykładami, a nie ogólnikami. Priorytet krytyczny to na przykład „system niedostępny dla wszystkich użytkowników albo błąd uniemożliwiający przyjmowanie płatności”, a nie „poważny wpływ na biznes”. Dla każdego priorytetu określa czas reakcji, czas przywrócenia działania lub obejścia i czas trwałego rozwiązania, bo to trzy różne rzeczy.
SLA musi też określać godziny świadczenia usługi. Czas rozwiązania „4 godziny” w trybie dni roboczych od 9 do 17 oznacza, że błąd zgłoszony o 16:30 w piątek może zostać naprawiony w poniedziałek przed południem. Jeśli system musi działać w weekendy, potrzebujesz wprost zapisanego trybu całodobowego albo dyżuru dla priorytetów krytycznych.
Kolejne elementy to sposób pomiaru i raportowania (kto mierzy, w jakim narzędziu, jak często dostajesz raport), konsekwencje niedotrzymania (najczęściej obniżenie opłaty za dany okres, rzadziej kary umowne) i lista wyłączeń. Wyłączenia są ważne, bo tam ukrywa się większość sporów: awarie infrastruktury klienta, zmiany wprowadzone przez osoby trzecie, problemy z usługami zewnętrznymi. Sprawdź, czy lista jest rozsądna, czy wyłącza wszystko, co mogłoby się zdarzyć.
Przykładowa struktura, od której warto zacząć negocjacje, wygląda tak. Priorytet krytyczny: system niedostępny albo zatrzymany kluczowy proces biznesowy, z krótkim czasem reakcji, określonym czasem przywrócenia działania lub obejścia i obsługą także poza godzinami pracy, jeśli biznes tego wymaga. Priorytet wysoki: ważna funkcja nie działa, ale istnieje obejście, z obsługą w godzinach pracy. Priorytet normalny: błąd o ograniczonym wpływie, naprawiany w ramach kolejnego planowego wydania. Priorytet niski: kosmetyka i pytania. Konkretne czasy zależą od krytyczności systemu i budżetu, ale sama struktura powinna być w każdej umowie.
Zwróć też uwagę na to, kto ustala priorytet. Najlepiej, gdy zgłaszający proponuje priorytet według definicji z umowy, a dostawca może go zmienić tylko z uzasadnieniem i za zgodą wskazanej osoby po Twojej stronie. Bez tej zasady łatwo o sytuację, w której zgłoszenia krytyczne są po cichu obniżane, a raport SLA wygląda wzorowo.
Wreszcie dopasuj SLA do tego, co naprawdę jest Ci potrzebne. Najdroższe SLA na wszystkie zgłoszenia jest marnotrawstwem, jeśli krytyczna jest tylko jedna ścieżka, na przykład płatności. Często lepiej kupić ścisłe SLA dla wąsko zdefiniowanych incydentów krytycznych i luźniejsze dla reszty.
Ile kosztuje dyżur całodobowy i kiedy naprawdę go potrzebujesz?
Wsparcie całodobowe to pozycja, która najbardziej podnosi koszt utrzymania, i ta, którą najczęściej kupuje się na wyrost. Pokrycie wszystkich godzin tygodnia wymaga rotacji kilku osób, które znają system, tak żeby żadna z nich nie dyżurowała bez przerwy. Dostawca musi więc utrzymywać w gotowości większy zespół niż ten, który faktycznie pracuje nad zgłoszeniami, a za samą gotowość, niezależnie od tego, czy coś się wydarzy, trzeba zapłacić.
Zanim kupisz dyżur 24/7, odpowiedz na trzy pytania. Ile kosztuje Cię godzina niedostępności systemu w nocy albo w weekend: utracona sprzedaż, kary wobec klientów, ryzyko regulacyjne? Czy awarie poza godzinami pracy w ogóle się zdarzają i z jakich przyczyn? Czy krytyczna jest cała aplikacja, czy tylko jedna jej funkcja?
Dla wielu systemów wewnętrznych odpowiedzi prowadzą do wniosku, że wystarczy wsparcie w dni robocze plus dobry monitoring i automatyczne alerty. Dla systemów sprzedażowych, płatniczych albo obsługujących klientów w różnych strefach czasowych dyżur jest uzasadniony, ale można go zawęzić do incydentów krytycznych zdefiniowanych w SLA, zamiast obejmować nim wszystkie zgłoszenia.
Dwie rzeczy obniżają koszt dyżuru bardziej niż negocjacje stawki. Pierwsza to monitoring i ciągłe monitorowanie środowisk, które wykrywa problemy, zanim zgłosi je klient, i daje dyżurnemu informację, gdzie szukać. Druga to automatyzacja: system, który sam restartuje usługę po awarii albo przełącza ruch, wymaga interwencji człowieka znacznie rzadziej.
Co podnosi koszt utrzymania, a co go obniża?
Poniższa tabela zbiera czynniki, które w największym stopniu wpływają na roczny koszt utrzymania, i pokazuje, jak je sprawdzić, zanim podpiszesz umowę.
| Czynnik | Co podnosi koszt | Co obniża koszt | Jak sprawdzić przed podpisaniem |
|---|---|---|---|
| Godziny wsparcia | Dyżur 24/7 dla wszystkich zgłoszeń | Dni robocze plus dyżur tylko dla incydentów krytycznych | Policz koszt godziny przestoju poza godzinami pracy |
| Jakość kodu i testów | Brak testów automatycznych, duży dług technologiczny | Testy regresji krytycznych ścieżek, czysta architektura | Audyt kodu albo raport pokrycia testami |
| Integracje | Wiele systemów zewnętrznych, częste zmiany API partnerów | Mało integracji, stabilne, udokumentowane interfejsy | Lista integracji z historią zmian po stronie partnerów |
| Zależności i technologia | Przestarzały framework, biblioteki bez wsparcia | Aktualny stos, automatyczne aktualizacje zależności | Przegląd wersji i dat końca wsparcia |
| Monitoring i automatyzacja | Awarie zgłaszane przez użytkowników | Alerty, automatyczne restarty, przełączanie ruchu | Sprawdź, skąd dowiadujecie się o ostatnich incydentach |
| Ciągłość zespołu | Utrzymanie przejmuje zespół, który nie budował systemu | Ci sami ludzie budują i utrzymują | Zapytaj, kto konkretnie będzie w zespole utrzymania |
| Dokumentacja | Wiedza w głowach dwóch osób | Aktualna dokumentacja, procedury, runbooki | Poproś o procedurę wdrożenia i przywracania kopii |
| Zmiany funkcjonalne | Brak limitu, wszystko „w abonamencie” | Osobna pula i priorytety ustalane co miesiąc | Rozdziel w ofercie utrzymanie od rozwoju |
Tabela przydaje się też po podpisaniu umowy. Raz w roku, przy planowaniu budżetu, warto przejść przez nią ponownie: jeśli liczba zgłoszeń krytycznych nie spada, testów nie przybywa, a monitoring wciąż nie wykrywa awarii przed użytkownikami, koszt utrzymania będzie rósł niezależnie od tego, jak dobrze wynegocjowano stawkę.
Najwięcej oszczędności zwykle nie leży w stawce godzinowej, tylko w trzech pierwszych wierszach. System z dobrymi testami i monitoringiem, utrzymywany w trybie dostosowanym do realnej krytyczności, kosztuje w utrzymaniu wyraźnie mniej niż system bez testów z kupionym na wszelki wypadek dyżurem całodobowym.
Jakie obowiązki bezpieczeństwa i regulacyjne zmieniają zakres utrzymania?
Utrzymanie to dziś nie tylko naprawa błędów, ale też obowiązek reagowania na podatności. Nowe luki w popularnych bibliotekach ujawniane są stale, a aplikacja, której zależności nikt nie aktualizuje, z każdym miesiącem staje się łatwiejszym celem. Dlatego w budżecie utrzymania musi być stała pozycja na aktualizacje bezpieczeństwa, niezależna od zgłoszeń użytkowników.
Jeśli Twoja aplikacja jest produktem, który sprzedajesz na rynku UE, warto znać rozporządzenie o cyberodporności (Cyber Resilience Act, UE 2024/2847). Od 11 września 2026 roku producenci produktów z elementami cyfrowymi objętych rozporządzeniem muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty, a od 11 grudnia 2027 roku stosuje się większość pozostałych obowiązków, w tym obsługę podatności przez okres wsparcia, który co do zasady ma wynosić co najmniej pięć lat, chyba że produkt ma być używany krócej. To zmienia rachunek: utrzymanie produktu nie jest już decyzją biznesową, którą można odłożyć, tylko obowiązkiem na lata. Czy rozporządzenie dotyczy Twojej aplikacji, zależy od jej charakteru; systemy budowane wyłącznie na własny użytek wewnętrzny są w innej sytuacji niż produkty wprowadzane do obrotu, więc tę kwestię warto sprawdzić z prawnikiem.
W sektorze finansowym dochodzą wymogi DORA dotyczące zarządzania ryzykiem ICT i umów z dostawcami usług ICT, w tym strategii wyjścia. W praktyce oznacza to, że umowa utrzymaniowa musi przewidywać, jak przekazać system innemu dostawcy, i że ten scenariusz warto mieć przemyślany wcześniej. Jak wygląda zmiana dostawcy w praktyce, opisaliśmy w tekście o przejęciu projektu w 30 dni.
Niezależnie od regulacji warto zapisać w umowie trzy rzeczy: czas na wdrożenie poprawki krytycznej podatności, odpowiedzialność za monitorowanie podatności w zależnościach oraz regularny, na przykład kwartalny, przegląd i aktualizację bibliotek.
Jakie pytania zadać dostawcy utrzymania przed podpisaniem umowy?
Oferty utrzymania łatwo porównać po cenie i trudno po treści. Poniższe pytania pomagają zobaczyć, co faktycznie kupujesz.
Co dokładnie obejmuje opłata stała, a co jest rozliczane osobno? Poproś o listę przykładowych zgłoszeń z przypisaniem: w abonamencie czy poza nim. Odpowiedź ogólna typu „bieżące utrzymanie” to zaproszenie do sporów.
Jak mierzycie i raportujecie SLA? Dostawca powinien pokazać przykładowy raport miesięczny: liczba zgłoszeń według priorytetów, czasy reakcji i rozwiązania, naruszenia SLA i ich przyczyny.
Kto konkretnie będzie utrzymywał system i czy zna jego kod? Zespół, który system budował, utrzymuje go taniej niż zespół, który dopiero się go uczy. Jeśli to nowy zespół, zapytaj, ile potrwa i ile kosztuje wdrożenie w system.
Jak wygląda zastępstwo, gdy kluczowa osoba odejdzie albo zachoruje? Utrzymanie oparte na jednej osobie to ryzyko, którego SLA nie pokryje. Zapytaj o dokumentację, procedury i o to, ile osób w zespole dostawcy zna system.
Jak przekażecie system, jeśli zakończymy współpracę? Odpowiedź powinna obejmować kod i konta po Twojej stronie, aktualną dokumentację, okres przejściowy i stawki za transfer wiedzy. Dostawca, który nie chce o tym rozmawiać przed podpisaniem umowy, nie będzie chciał też po jej wypowiedzeniu.
Jak dbacie o to, żeby te same błędy nie wracały? Dobry dostawca prowadzi analizę przyczyn źródłowych dla incydentów krytycznych i proponuje zmiany, które zmniejszają liczbę zgłoszeń. Utrzymanie, które z miesiąca na miesiąc obsługuje te same problemy, jest wygodne dla dostawcy rozliczanego godzinowo, ale nie dla Ciebie.
Jak wygląda Wasze wejście w system, jeśli go nie budowaliście? Zespół, który przejmuje utrzymanie cudzej aplikacji, potrzebuje czasu na poznanie kodu, środowisk i historii incydentów. Dobra odpowiedź opisuje ten okres: przegląd kodu, sesje z dotychczasowym zespołem, pierwsze wdrożenie pod nadzorem, a dopiero potem pełne SLA. Dostawca, który obiecuje pełne SLA od pierwszego dnia w systemie, którego nie zna, albo nie rozumie ryzyka, albo zamierza je przerzucić na Ciebie przez wyłączenia w umowie.
Jakie są czerwone flagi w ofertach utrzymania?
Kilka sygnałów w ofercie albo w rozmowie powinno skłonić do dodatkowych pytań, zanim przejdziesz do negocjacji ceny.
SLA tylko z czasem reakcji. Jak pisaliśmy wyżej, reakcja to nie rozwiązanie. Oferta bez czasu przywrócenia działania dla incydentów krytycznych nie daje realnej ochrony.
Brak definicji priorytetów albo definicje, które dostawca ustala sam. Jeśli to dostawca decyduje o priorytecie zgłoszenia bez jasnych kryteriów, SLA zawsze będzie dotrzymane, bo każde trudne zgłoszenie dostanie niski priorytet.
Abonament bez limitu prac i bez listy wyłączeń. Wygląda atrakcyjnie, ale w praktyce oznacza, że granica zostanie wyznaczona w sporze, a nie w umowie.
Utrzymanie, w którym kod i konta są po stronie dostawcy. Repozytorium, chmura, domeny i narzędzia muszą być na kontach Twojej firmy. Inaczej zmiana dostawcy utrzymania stanie się operacją ratunkową.
Wycena bez obejrzenia systemu. Dostawca, który nie zna kodu, nie może uczciwie wycenić utrzymania. Albo dolicza wysoką marżę na niepewność, albo zamierza odbić ją sobie w zgłoszeniach „poza zakresem”. Rozsądny dostawca chce najpierw zobaczyć kod, dokumentację i historię incydentów.
Jak ARDURA Consulting podchodzi do utrzymania aplikacji?
Mówimy to wprost, bo od tego zależy, czy w ogóle warto z nami rozmawiać o utrzymaniu: nie świadczymy utrzymania jako samodzielnej usługi zarządzanej. Utrzymanie z umową SLA przejmujemy po projekcie, który zrealizowaliśmy w ramach Software development albo uratowaliśmy w ramach Software Rescue. Wtedy zespół, który zna kod, odpowiada też za jego utrzymanie, co jest najtańszym i najbezpieczniejszym układem z opisanych wyżej.
Jeśli Twoja aplikacja powstała u innego dostawcy i potrzebujesz zmiany zespołu utrzymującego, ścieżką jest Software Rescue: zaczynamy od audytu kondycji kodu (od 18 000 PLN, 1–2 tygodnie), stabilizujemy system, redukujemy dług techniczny, a długoterminowe utrzymanie z SLA jest czwartą fazą tego procesu. Audyt pokazuje też, ile utrzymanie będzie realnie kosztować, bo bez wiedzy o stanie kodu każda wycena jest zgadywaniem.
Jeśli wolisz utrzymywać system własnym zespołem i brakuje Ci w nim ludzi, możesz go wzmocnić specjalistami w modelu body leasingu, o którym więcej na stronie outsourcingu IT. Stawki seniorów według naszego benchmarku na 2026 rok to 180–260 zł netto za godzinę, a każda współpraca zaczyna się od dwutygodniowej gwarancji satysfakcji z bezpłatną wymianą specjalisty. Szczegółowe stawki dla poszczególnych ról znajdziesz w cenniku.
Co zapamiętać, zanim podpiszesz umowę na utrzymanie?
Koszt utrzymania aplikacji to nie jedna liczba, tylko suma kilku decyzji: jakie godziny wsparcia są naprawdę potrzebne, ile zmian funkcjonalnych chce biznes, jak dobrze system jest przetestowany i monitorowany oraz kto go utrzymuje.
Zapamiętaj pięć rzeczy. Po pierwsze, rozdziel w ofertach gotowość, naprawę błędów, aktualizacje i zmiany funkcjonalne, bo inaczej oferty są nieporównywalne. Po drugie, licz budżet od dołu z godzin i ról, a procent od kosztu wytworzenia traktuj tylko jako test. Po trzecie, zadbaj, żeby do L3 trafiały tylko sprawy wymagające programisty. Po czwarte, wymagaj SLA z definicjami priorytetów, czasem przywrócenia działania i godzinami świadczenia usługi, a nie tylko czasem reakcji. Po piąte, kupuj dyżur całodobowy tylko tam, gdzie godzina przestoju naprawdę kosztuje, i inwestuj w monitoring, który skraca każdą interwencję.
Jeśli Twój system potrzebuje nowego zespołu utrzymującego albo nie wiesz, w jakim jest stanie, zobacz, jak działa Software Rescue albo umów rozmowę. Powiemy, czy zacząć od audytu, jak mogłoby wyglądać przejęcie utrzymania i ile realnie może ono kosztować.