Umowa SLA
Umowa SLA - Service Level Agreement to coś więcej niż obietnica, że system „będzie działał” po zakończeniu wdrożenia. To twarde reguły gry, które decydują o tym, jak wygląda życie biznesowe i technologiczne obu stron w fazie utrzymania projektu. Z mojego doświadczenia wynika, że źle skonstruowany lub zbyt ogólny kontrakt serwisowy to dla zamawiającego ryzyko ciągłych przestojów i nieprzewidywalnych kosztów, a dla dostawcy (software house'u) – widmo nieuzasadnionych roszczeń finansowych i presja darmowej pracy „po godzinach”. Dobrze wynegocjowana umowa SLA ma działać operacyjnie: musi wyznaczać jasne granice odpowiedzialności, standaryzować proces zgłaszania błędów i chronić budżety obu stron przed niespodziewanymi awariami.
Service Level Agreement
Czym zajmuję się w ramach obsługi umów SLA?
W praktyce widzę, że większość sporów na etapie utrzymania oprogramowania (maintenance) wynika z braku precyzji w definiowaniu pojęć technicznych na gruncie prawnym. Dlatego gdy na stół trafia nowa umowa SLA, definicja jej przedmiotu nie może ograniczać się do ogólników. Buduję kontrakty tak, aby parametry dostępności (np. mityczne 99,9%) i czasy reakcji były nie tylko ładnie wyglądającymi liczbami, ale realnym, wykonalnym planem zarządzania kryzysem, gdy system napotka problemy.
Kluczowe jest dla mnie rozróżnienie: czy mówimy o systemie e-commerce zarabiającym w trybie 24/7, który wymaga natychmiastowej reakcji na każdy błąd krytyczny, czy o wewnętrznym narzędziu CRM, gdzie wsparcie w dni robocze jest całkowicie wystarczające. Te dwa światy wymagają innych akcentów w umowie, zupełnie innej kategoryzacji incydentów i mechanizmów naliczania kar umownych lub rekompensat typu service credits.
„Znajomość specyfiki branży IT, zrozumienie jej problemów i doświadczenie przy prawnej obsłudze firm działających w obszarze IT umożliwiają mi świadczenie specjalistycznych i kompleksowych usług z korzyścią dla moich Klientów.”
Radca Prawny Piotr Stawowski
Co powinny zawierać
UMOWA SLA W PRAKTYCE IT
W umowach serwisowych SLA nie chodzi o to, by obciążyć dostawcę odpowiedzialnością za każdą nieprzewidzianą usterkę, ani o to, by zamawiający musiał czekać tygodniami na usunięcie błędu krytycznego, który blokuje jego sprzedaż. Jeżeli zastanawiasz się, co powinna zawierać umowa SLA, aby była użytecznym narzędziem zarządzania ryzykiem, musisz skupić się na precyzyjnych procedurach obsługi incydentów. Na stronach branżowych często podkreśla się znaczenie kategoryzacji błędów i wskaźników dostępności, jako elementów, które realnie porządkują współpracę na etapie utrzymania systemu.
Poniżej elementy, które na bazie mojego doświadczenia traktuję jako absolutny standard w profesjonalnej umowie serwisowej (SLA):
- Precyzyjna kategoryzacja incydentów: Definiuję w umowie jasny podział na błędy krytyczne, poważne (istotne) oraz zwykłe usterki, opisując przy tym rzeczywisty wpływ danego problemu na użyteczność lub wydajność systemu IT.
- Wskaźniki SLI i raportowanie: Uregulowanie mechanizmów mierzenia dostępności usługi (np. 99,9%). Klient musi wiedzieć, w jakich cyklach miesięcznych lub rocznych dostawca przedstawia raporty i statystyki ze zrealizowanych zgłoszeń.
- Procedury i kanały zgłoszeń: Opisuję, w jaki sposób incydenty mają być zgłaszane (np. poprzez dedykowany system klasy ITSM, e-mail czy kanał telefoniczny), aby liczenie czasu reakcji było transparentne dla obu stron.
- Czas reakcji (Response Time): Ustalenie maksymalnego czasu, w którym dostawca ma obowiązek odpowiedzieć na zgłoszenie incydentu i przypisać mu odpowiedni priorytet naprawczy, liczony od momentu powiadomienia.
- Czas naprawy i workarounds: Czas przewidziany na trwałe usunięcie przyczyny incydentu. Zawsze dbam o dodanie zapisów o obejściach (workarounds) – gdy techniczna naprawa błędu krytycznego wymaga czasu, dostawca musi zapewnić czasowe rozwiązanie zastępcze.
- Okna serwisowe (Maintenance Windows): Ustalenie planowanych przerw na aktualizacje lub konserwację systemu, które nie są wliczane do czasu niedostępności (downtime) i nie skutkują nałożeniem kar.
- Service Credits i kary umowne: Wypracowanie mechanizmu finansowej rekompensaty za niedotrzymanie gwarantowanych poziomów SLA (np. zniżki na kolejny miesiąc wsparcia w miejsce rygorystycznych kar).
- Katalog wyłączeń (Exclusions): Wskazanie sytuacji, za które dostawca oprogramowania nie ponosi odpowiedzialności (np. awarie infrastruktury zamawiającego, ataki hakerskie typu DDoS czy błędy w integracjach z zewnętrznym API treciej strony).
Jeżeli obsługa serwisowa dotyczy infrastruktury zewnętrznej lub modelu chmurowego, niezbędna staje się również umowa SLA na outsourcing środowiska, która musi dodatkowo regulować kwestie polityki bezpieczeństwa, zarządzania kopiami zapasowymi (backup) oraz dostępności serwerów.
Jeżeli w dalszym ciągu masz wątpliwości, skontaktuj się ze mną.
Gwarancja, Utrzymanie czy Rozwój?
Umowa SLA a modele współpracy
W projektach IT najczęściej spotykam się z poważnym błędem pojęciowym: mieszaniem darmowej gwarancji na wykonany kod z płatną usługą utrzymania (SLA) oraz zadaniami polegającymi na dalszym rozwoju systemu. Dobrze skonstruowana SLA umowa musi jednoznacznie oddzielać te obszary, aby uniknąć konfliktów o to, za co zamawiający płaci abonament, a co powinno być usunięte w ramach rękojmi.
Gdy doradzam klientom, zawsze dbam o to, aby umowa serwisowa była dopasowana do rzeczywistego trybu pracy zespołu. Z tego względu wyraźnie rozdzielam SLA na dwa główne nurt: utrzymanie aplikacji przez jej twórców oraz zewnętrzny outsourcing.
Utrzymanie autorskie i rozwój systemu (Maintenance & Development)
Jeżeli kontrakt na wdrożenie przechodzi w fazę utrzymania realizowanego przez ten sam software house, SLA musi godzić naprawę błędów z bieżącym rozwojem oprogramowania. W takiej sytuacji nie wystarczy wpisać suchych czasów reakcji z dokumentów publicznych czy tabel priorytetów.
W tym modelu kluczowe staje się ustalenie hybrydowych form rozliczeń. Z reguły wprowadzam stały miesięczny ryczałt za gotowość zespołu, monitorowanie infrastruktury i usuwanie błędów krytycznych, który chroni interesy zamawiającego. Równocześnie, dla prac wykraczających poza utrzymanie (tzw. change requests czy dodawanie nowych modułów do aplikacji), stosuję transparentne stawki godzinowe Time & Material, co pozwala software house’owi zachować rentowność i elastycznie przydzielać programistów do poszczególnych zadań bez obaw o naruszenie wskaźników dostępności.
Umowa SLA – outsourcing infrastruktury i usług chmurowych
Kiedy utrzymanie systemu nie spoczywa na barkach twórców kodu, lecz zewnętrznego operatora IT (np. administratorów serwerów czy dostawców usług chmurowych), zasady gry całkowicie się zmieniają. Gdy przedmiotem negocjacji jest umowa SLA outsourcing wymaga szczególnego podejścia do bezpieczeństwa, ponieważ zewnętrzny podmiot uzyskuje dostęp do środowisk produkcyjnych i wrażliwych danych.
W tym przypadku nie oceniamy już czasu napisania poprawki do kodu (bugfix), ale gwarancję nieprzerwanego działania serwerów (Uptime), czasy przywrócenia danych z kopii zapasowej w ramach procedur Disaster Recovery oraz odporność na ataki DDoS. Taki dokument musi również uwzględniać zasady współpracy z innymi dostawcami (np. software house’em) – tak aby w razie awarii administratorzy infrastruktury wiedzieli, w którym momencie przekazać zgłoszenie programistom, zamiast odbijać przysłowiową „piłeczkę”.
Na co zwracam uwagę?
WŁASNOŚĆ INTELEKTUALNA A UMOWA SLA
W projektach IT utrzymanie systemu i prawa autorskie to naczynia połączone. W praktyce najwięcej problemów w fazie maintenance pojawia się wtedy, gdy zamawiający płaci za usunięcie błędu krytycznego lub stworzenie obejścia awarii, a po zakończeniu prac okazuje się, że nie posiada praw do nowo napisanego kodu. Dlatego dbam o to, by SLA umowa precyzyjnie regulowała kwestie własności intelektualnej do wszelkich łatek (bugfixów), skryptów naprawczych czy aktualizacji wdrażanych w ramach prac serwisowych.
Porządkuję model przeniesienia praw lub udzielania licencji na efekty prac utrzymaniowych, aby uniknąć paraliżującego zjawiska vendor lock-in. Jeżeli w ramach Service Level Agreement dostawca tworzy modyfikacje przywracające systemowi pełną funkcjonalność po awarii, zamawiający musi mieć gwarancję, że nabyte prawa (lub zakres licencji) pozwalają na swobodne korzystanie z tych rozwiązań, modyfikowanie ich w przyszłości oraz udzielanie sublicencji – np. w przypadku zmiany wykonawcy, który przejmie obsługę systemu.
Zwracam również szczególną uwagę na powiązanie dostępu do kodu źródłowego z procedurami eskalacji. Uregulowanie zasad przekazywania repozytorium czy mechanizmów escrow staje się dla klienta swoistym „wyjściem awaryjnym”. Gdy dostawca rażąco narusza gwarantowane wskaźniki dostępności, nie usuwa na czas błędów krytycznych lub grozi mu utrata płynności finansowej, odpowiednio skonstruowana umowa SLA pozwala zamawiającemu przejąć kontrolę nad procesem naprawczym bez ryzyka roszczeń o naruszenie majątkowych praw autorskich.
Nasz zespół
Nasz zespół to prawnicy z doświadczeniem w pracy z firmami z sektora IT, gamedev i startupami. Współpracowaliśmy m.in. z Imnite, Nice Guys, InviNets i innymi wiodącymi firmami działającymi w obszarze IP/IT.
Rekomendacje
Opinie moich klientów
Mecenas Stawowski wspierał Spółkę już na etapie jej zakładania – kompleksowo przeprowadził nas przez formalności i przygotował wzory umów, które zabezpieczają nasz biznes.
Doceniamy nie tylko wysoką jakość obsługi, ale też praktyczne podejście, szybkość działania i słuchanie naszych potrzeb. Dzięki wsparciu kancelarii mogliśmy skupić się na rozwijaniu firmy, wiedząc, że kwestie prawne są w dobrych rękach.
Z pełnym przekonaniem polecamy kancelarię Piotra Stawowskiego
Wsparcie prawnika
NEGOCJOWANIE I OPINIOWANIE UMÓW SLA
W negocjacjach kontraktów serwisowych nie interesuje mnie mnożenie ryzyk czy wpisywanie nierealnych kar finansowych, które zniszczą relacje biznesowe – zależy mi na tym, żeby system miał zagwarantowaną ciągłość działania, a obydwie strony jasne reguły rozliczeń. Dlatego pracuję tak, by każdy umowa SLA przykład (od prostego wsparcia po złożone utrzymanie 24/7) był dokumentem mierzalnym technicznie i zrozumiałym dla zarządu, prawnika oraz zespołu wsparcia (helpdesk).
Najczęściej pomagam w jednym z poniższych wariantów:
- Audyt umowy od dostawcy: Wskazuję słabe punkty w zaproponowanych wskaźnikach (np. ukryte wyłączenia z czasu niedostępności) i proponuję konkretne, negocjowalne poprawki, które realnie zwiększą bezpieczeństwo.
- Przygotowanie SLA od zera: Dobieram odpowiedni model kontraktu serwisowego, ustalam precyzyjne tabele priorytetów (kategoryzację błędów), czasy reakcji i naprawy oraz mechanizmy service credits (rekompensat).
- Wsparcie w negocjacjach: Biorę udział w rozmowach, tłumacząc zawiłości prawne na język technologii i biznesu; dbam o wypracowanie kompromisu, który pozwala bezpiecznie rozpocząć fazę utrzymania.
- Wsparcie w trakcie trwania umowy: Gdy pojawia się spór dotyczący tego, czy dane zgłoszenie to błąd objęty gwarancją czy nowa funkcjonalność (change request), pomagam rozstrzygnąć problem i uregulować zasady płatności.
Jeżeli na Twoim biurku leży do podpisu nowa SLA umowa, podeślij mi dokument. Przeanalizuję proponowane poziomy świadczenia usług i podpowiem, które zapisy należy doprecyzować, by chroniły Twój budżet i spokój.
