Wdrożenie aplikacji czy systemu to moment, w którym większość firm odetchnie z ulgą – projekt działa, użytkownicy z niego korzystają, cel wydaje się osiągnięty. W praktyce to dopiero początek najdłuższego etapu życia produktu cyfrowego. Aplikacja, która nie jest monitorowana, aktualizowana i wspierana technicznie, zaczyna się psuć – czasem gwałtownie, częściej po cichu, aż do momentu, w którym awaria kosztuje więcej niż roczne wsparcie by kosztowało.
W tym artykule wyjaśniamy, czym jest wsparcie IT po wdrożeniu, jak wygląda dobrze skonstruowana umowa SLA (Service Level Agreement) i o co warto zapytać software house, zanim się na taką umowę zdecydujesz.
Czy każda aplikacja potrzebuje SLA?
Nie. Sformalizowana umowa SLA ma sens tam, gdzie przestój realnie kosztuje – gdy aplikacja obsługuje sprzedaż, płatności, logistykę albo krytyczne procesy dla klientów. W takich przypadkach kilka godzin niedostępności to bezpośrednia strata finansowa lub wizerunkowa.
Inaczej wygląda sytuacja w przypadku MVP czy produktów walidujących pomysł na wczesnym etapie. Jeśli aplikacja ma kilkudziesięciu testowych użytkowników, a jej celem jest sprawdzenie hipotezy biznesowej, kilkugodzinna przerwa w działaniu zwykle nie ma żadnych realnych konsekwencji. W takim momencie sztywne SLA z gwarantowanymi czasami reakcji jest niepotrzebnym kosztem – ważniejsze jest szybkie iterowanie nad produktem niż formalne gwarancje dostępności.
Dobra praktyka to dopasowanie poziomu wsparcia do etapu, na którym znajduje się produkt: na starcie wystarczy elastyczne wsparcie „na żądanie”, a formalną umowę SLA warto wprowadzić w momencie, gdy aplikacja zaczyna generować realny biznes i przestój przestaje być czymś, co można po prostu przeczekać.
Czym jest wsparcie IT po wdrożeniu
Wsparcie po wdrożeniu to coś więcej niż „naprawianie błędów, jeśli się pojawią”. W praktyce obejmuje zwykle trzy obszary:
Utrzymanie (maintenance) – monitorowanie działania aplikacji, aktualizacje zależności i bibliotek, poprawki bezpieczeństwa, dostosowywanie do nowych wersji systemów operacyjnych (np. iOS, Android) czy przeglądarek.
Reagowanie na awarie (support/reaktywne) – szybka reakcja, gdy coś przestaje działać: od drobnych błędów po krytyczne przestoje wpływające na klientów.
Rozwój (proaktywne wsparcie) – drobne usprawnienia, nowe funkcje, optymalizacja wydajności – czyli praca, która sprawia, że aplikacja nie stoi w miejscu, tylko rośnie razem z biznesem.
Firmy często kupują tylko pierwszy element (utrzymanie) i traktują resztę jako „coś, czym zajmiemy się, jak będzie problem”. To błąd, bo koszt reagowania po fakcie jest zwykle wielokrotnie wyższy niż koszt zapobiegania.
Co powinna zawierać dobra umowa SLA
SLA to dokument, który określa, na jakim poziomie usługi możesz polegać – i co się dzieje, jeśli ten poziom nie zostanie dotrzymany. Dobra umowa SLA w kontekście wsparcia IT powinna precyzyjnie definiować kilka rzeczy.
Czas reakcji i czas naprawy. To dwie różne wartości i warto je rozróżniać. Czas reakcji to moment, w którym ktoś z zespołu potwierdza przyjęcie zgłoszenia. Czas naprawy to moment, w którym problem faktycznie zostaje rozwiązany. Oba powinny być powiązane z priorytetem zgłoszenia (np. Krytyczny błąd blokujący działanie systemu vs. drobna niedogodność kosmetyczna).
W przypadku aplikacji mobilnych czas naprawy musi dodatkowo uwzględniać proces review w Google Play i App Store. Poprawka po stronie zespołu może być gotowa w kilka godzin, ale zanim trafi do użytkowników, musi przejść weryfikację sklepu – w Google Play to zwykle kilka godzin do jednego dnia, w App Store nierzadko 24-48 godzin, a w przypadku odrzucenia zgłoszenia proces się wydłuża. Dobra umowa SLA powinna rozróżniać „czas do gotowości poprawki” od „czas do jej realnego wdrożenia u użytkowników” i jasno mówić, że ten drugi zależy również od czynników niezależnych od software house’u.
Priorytety zgłoszeń. Standardowo stosuje się podział na kilka poziomów – np. Krytyczny (system nie działa, wpływ na wszystkich użytkowników), wysoki (poważny błąd, ale są obejścia), średni i niski. Każdy poziom powinien mieć własny czas reakcji.
Dostępność (uptime). Jeśli aplikacja obsługuje procesy biznesowe (np. Sprzedaż, logistykę, płatności), warto określić oczekiwaną dostępność systemu, np. 99,5%, oraz sposób jej mierzenia.
Kanały i godziny kontaktu. Czy wsparcie działa w godzinach 9-17 w dni robocze, czy 24/7? Czy zgłoszenia idą przez e-mail, dedykowany system ticketowy, czy komunikator? To szczegół, który w praktyce decyduje o tym, jak szybko realnie dostaniesz pomoc.
Zakres wsparcia. Umowa powinna jasno mówić, co jest w niej zawarte (np. Liczba godzin miesięcznie, rodzaj prac), a co jest dodatkowo płatne – żeby uniknąć sytuacji, w której „drobna poprawka” okazuje się dużym projektem rozliczanym osobno.
Modele współpracy przy wsparciu IT
W zależności od wielkości firmy i stopnia zaangażowania własnego zespołu, wsparcie IT można zorganizować na kilka sposobów.
Pełna obsługa techniczna – software house przejmuje cały zakres utrzymania i rozwoju aplikacji. Sprawdza się, gdy firma nie ma własnego zespołu technicznego i chce mieć jednego partnera odpowiedzialnego za cały produkt.
Obsługa wybranego obszaru – firma ma już część kompetencji wewnątrz (np. Własny backend), a zleca na zewnątrz konkretny fragment, np. Frontend, UX/UI albo aplikację mobilną.
Body-leasing / wsparcie zespołowe – firma zatrudnia konkretnych specjalistów do swojego zespołu i sama zarządza ich pracą, korzystając z kompetencji zewnętrznego dostawcy bez oddawania mu pełnej kontroli nad projektem.
Żaden z tych modeli nie jest uniwersalnie „lepszy” – wybór zależy od tego, ile kontroli chcesz zachować i ile kompetencji masz już wewnątrz organizacji.
Sygnały, że potrzebujesz wsparcia IT
Kilka sytuacji, które w praktyce najczęściej skłaniają firmy do podpisania umowy SLA:
Aplikacja przestała być rozwijana przez pierwotnego wykonawcę, a nikt nie monitoruje jej działania. Pojawiają się zgłoszenia od użytkowników, ale nie ma jasnej ścieżki, kto i w jakim czasie je obsłuży. Zbliża się aktualizacja systemu operacyjnego lub biblioteki, od której zależy działanie aplikacji. Firma rośnie, a aplikacja musi obsłużyć więcej użytkowników lub nowe funkcje biznesowe.
O co zapytać software house przed podpisaniem umowy SLA
Zanim podpiszesz umowę, warto zadać kilka konkretnych pytań: jaki jest gwarantowany czas reakcji dla zgłoszeń krytycznych, czy w cenie jest limit godzin i co się dzieje po jego przekroczeniu, kto dokładnie będzie się zajmował projektem (dedykowany zespół czy rotacyjna obsługa), jak wygląda proces eskalacji, jeśli standardowe wsparcie nie rozwiąże problemu, oraz czy umowę można elastycznie skalować w górę lub w dół wraz ze zmieniającymi się potrzebami.
Odpowiedzi na te pytania mówią więcej o jakości współpracy niż sama stawka godzinowa.
Podsumowanie
Wsparcie IT po wdrożeniu to nie koszt dodatkowy, tylko naturalny element cyklu życia każdego produktu cyfrowego. Dobrze skonstruowana umowa SLA – z jasnymi czasami reakcji, priorytetami zgłoszeń i przejrzystym raportowaniem – pozwala uniknąć sytuacji, w której awaria systemu staje się kryzysem, zamiast rutynowego zgłoszenia.
Jeśli zastanawiasz się, jak zorganizować wsparcie dla swojej aplikacji lub systemu, chętnie doradzimy, który model współpracy najlepiej pasuje do Twojej sytuacji.
Napisz do nas: https://thecodebrothers.pl/kontakt/
