B2B w IT: jak bezpiecznie opisać odpowiedzialność za awarie i przestoje

Dlaczego w umowach B2B w IT kluczowe jest opisanie odpowiedzialności za awarie i przestoje

Relacje B2B w IT są oparte na zaufaniu, ale w chwili awarii najgłośniej mówi nie zaufanie, tylko umowa. Brak precyzyjnego opisu odpowiedzialności za awarie i przestoje kończy się zwykle dwiema skrajnościami: albo klient próbuje przerzucić na dostawcę pełne skutki biznesowe każdego przestoju, albo dostawca „chowa się” za ogólnymi wyłączeniami odpowiedzialności. Jedno i drugie prowadzi do konfliktów, sporów i paraliżu współpracy.

Odpowiedzialność za awarie i przestoje w B2B w IT to nie tylko paragrafy o karach umownych. To cały system wzajemnych zobowiązań: od definicji, przez SLA, procedury zgłoszeń, aż po limity odpowiedzialności. Dobrze ułożone postanowienia zabezpieczają obie strony: klient wie, czego może się domagać i kiedy przysługują mu roszczenia, a dostawca rozumie, w jakim zakresie ryzyko biznesowe jest po jego stronie, a gdzie kończy się jego rola techniczna.

W praktyce spory nie wybuchają dlatego, że „coś padło”, tylko gdy strony mają zupełnie inne wyobrażenie: co jest awarią, jak długo wolno ją usuwać, co jest „normalnym ryzykiem”, a co jest niedopuszczalnym naruszeniem umowy. Dlatego opis odpowiedzialności musi łączyć trzy poziomy: techniczny (jak działają systemy), organizacyjny (kto co robi i kiedy) i prawny (jakie są konsekwencje i limity).

Dodatkowo w IT coraz częściej nakładają się regulacje prawne (np. bezpieczeństwo danych, ciągłość usług, odpowiedzialność dostawcy chmury wobec swoich klientów biznesowych). Umowa B2B, która ignoruje ten kontekst, działa dobrze tylko do pierwszego poważniejszego incydentu. Dopiero przy realnej awarii okazuje się, czy kontrakt faktycznie chroni strony, czy raczej staje się listą wzajemnych rozczarowań.

Fundamenty: definicje awarii, przestoju i usług w umowie IT B2B

Precyzyjne definicje techniczne jako podstawa odpowiedzialności

Bez definicji nie ma odpowiedzialności. Jeśli w umowie B2B w IT nie ma jasnych definicji awarii, incydentu, przerwy serwisowej czy dostępności, każda strona będzie interpretowała je pod siebie. Klient nazwie awarią każdą niedogodność, a dostawca będzie twierdził, że „system działał poprawnie z jego perspektywy”.

Przydatne jest wprowadzenie oddzielnych pojęć dla różnych typów problemów:

• Awarie krytyczne – pełna niedostępność usługi lub kluczowej funkcji, uniemożliwiająca korzystanie z systemu przez większą część użytkowników.
• Usterki istotne – poważne obniżenie funkcjonalności, ale z możliwością pracy w ograniczonym zakresie lub z obejściem.
• Usterki drobne – błędy nie wpływające istotnie na możliwość korzystania z systemu (np. kosmetyczne błędy w interfejsie).
• Przestój planowany – przerwa w dostępności usługi spowodowana pracami serwisowymi, komunikowana z wyprzedzeniem.

Same definicje powinny być maksymalnie techniczne i mierzalne, a nie emocjonalne. Zamiast „poważne zakłócenie”, lepiej opisać „niedostępność kluczowej funkcji X dla więcej niż Y% użytkowników przez co najmniej Z minut”. Dzięki temu ocena, czy doszło do awarii, nie zależy od nastroju zarządów, ale od porównania faktów ze zdefiniowanym progiem.

Zakres usługi i granice odpowiedzialności technicznej

Rozdzielenie zakresu usługi od odpowiedzialności jest jednym z najczęstszych miejsc, w których pojawia się konflikt. Jeśli w umowie nie ma jasno określonego, co obejmuje usługa, klienci oczekują, że dostawca odpowiada za „całość działania rozwiązania IT”. Dostawca tymczasem zwykle myśli wyłącznie w kategoriach wąskiego zakresu: konkretnej aplikacji, środowiska lub komponentu.

W kontraktach B2B w IT warto jednoznacznie opisać:

• czy usługa obejmuje tylko software, czy także infrastrukturę (serwery, sieć, bazę danych),
• czy w ramach usługi dostawca odpowiada za integracje z systemami zewnętrznymi,
• czy dostępność usługi obejmuje także usługi dostawców trzecich (np. chmura, operator płatności),
• gdzie przebiega punkt podziału odpowiedzialności – np. do warstwy hypervisora, do systemu operacyjnego, do kodu aplikacji.

Bez tego łatwo o sytuację, w której klient ma przestój z powodu problemu w chmurze lub łączu internetowym, a oczekuje od dostawcy aplikacji pełnej odpowiedzialności finansowej za skutki. Uporządkowanie zakresu pozwala przypisać ryzyka do właściwych podmiotów i odpowiednio je wycenić.

Definicja dostępności i sposobu jej mierzenia

W B2B w IT odpowiedzialność za awarie i przestoje zwykle wiąże się z parametrem dostępności (SLA). Sam procent SLA (np. 99,5%) bez definicji sposobu liczenia jest w praktyce niewiele wart. Trzeba odpowiedzieć na kilka kluczowych pytań:

• jaki jest okres rozliczeniowy (miesiąc, kwartał, rok),
• jak liczy się czas niedostępności (od zgłoszenia, od wykrycia przez monitoring, czy od momentu faktycznego pojawienia się problemu),
• czy z liczenia SLA wyłącza się przerwy planowe, zdarzenia siły wyższej, problemy u dostawców trzecich,
• czy dostępność liczona jest dla całego systemu, czy osobno dla poszczególnych komponentów / funkcji.

Dobrą praktyką jest wprowadzenie w umowie konkretnego wzoru na liczenie dostępności oraz sposobu dokumentowania incydentów. Przykładowo: „Dostępność w danym miesiącu jest liczona jako (całkowity czas w miesiącu – suma czasów niedostępności usługi) / (całkowity czas w miesiącu) × 100%, z wyłączeniem przerw planowanych zgłoszonych co najmniej 48 godzin wcześniej.”

SLA w IT B2B: jak rozsądnie zapisać poziomy usług a ryzyko awarii

Struktura SLA: od czasów reakcji do czasów przywrócenia

W relacjach B2B w IT kluczowym narzędziem do opisania odpowiedzialności jest SLA (Service Level Agreement). Prawidłowo zbudowane SLA nie opiera się wyłącznie na jednym parametrze dostępności. Obejmuje zwykle kilka typów zobowiązań:

• czas reakcji – ile maksymalnie czasu może minąć od zgłoszenia awarii do podjęcia przez dostawcę pierwszych działań,
• czas przywrócenia (RTO) – docelowy maksymalny czas przywrócenia działania usługi po awarii określonego typu,
• okresy serwisowe – dozwolone okna na prace planowe, w których usługa może być niedostępna lub ograniczona,
• priorytety incydentów – różne parametry czasowe w zależności od wagi problemu.

Sama deklaracja czasu reakcji bez jasnego określenia godzin świadczenia wsparcia (np. 24/7, 8/5) rodzi ogromne pole do nieporozumień. Zamawiający potrafią oczekiwać reakcji w ciągu 1 godziny, także w soboty o 3:00 w nocy, mimo że umowa tego wprost nie przewiduje. Stąd w SLA trzeba opisać zarówno czasy, jak i kalendarz świadczenia usług.

Przykładowa macierz priorytetów i czasów reakcji

Doświadczeni dostawcy IT stosują czytelną macierz priorytetów, w której odpowiadające im czasy reakcji i przywrócenia są jasne dla obu stron. Tabela pozwala szybko odnieść konkretną awarię do ustalonych parametrów.

Taką tabelę warto osadzić w umowie lub załączniku SLA, a nie tylko w dokumentacji operacyjnej, ponieważ to od niej zależą konsekwencje finansowe. Trzeba również dodać procedurę zmiany priorytetu (kto decyduje, jak rozstrzygane są spory co do klasyfikacji incydentu).

Powiązanie SLA z odpowiedzialnością i sankcjami

SLA oderwane od odpowiedzialności prawnej staje się dokumentem marketingowym. Żeby w B2B w IT rzeczywiście zabezpieczyć obie strony, parametry SLA powinny być logicznie powiązane z mechanizmem odpowiedzialności za awarie i przestoje:

• przekroczenie gwarantowanych czasów reakcji / przywrócenia powinno skutkować z góry określonym skutkiem (np. bonifikata, kara umowna, dodatkowe godziny pracy),
• brak możliwości dotrzymania SLA z przyczyn leżących po stronie klienta (brak dostępu, brak akceptacji zmian, opóźnienia w testach) musi wyłączać lub ograniczać odpowiedzialność dostawcy,
• powtarzające się, istotne naruszenia SLA mogą stanowić podstawę do rozwiązania umowy i/lub wypłaty dodatkowego odszkodowania – ale na rozsądnie zdefiniowanych zasadach.

W praktyce stosuje się dwa główne modele powiązania SLA z konsekwencjami finansowymi: kary umowne oraz kredyty serwisowe (service credits). W polskich realiach częściej pojawiają się kary umowne, jednak w usługach SaaS i chmurze popularniejsze są kredyty serwisowe. Prawidłowo opisany mechanizm musi określać, od jakiego poziomu naruszeń naliczana jest rekompensata, jaka jest jej forma oraz czy wyczerpuje ona roszczenia klienta.

Kary umowne, kredyty serwisowe i limity odpowiedzialności za przestoje

Kary umowne za awarie i naruszenia SLA – jak je zbalansować

Kary umowne są kuszącym narzędziem dla zamawiających, bo pozwalają „wycenić” awarie i przestoje. Z drugiej strony zbyt agresywne stawki kar zniechęcają dostawców do zawierania umów lub sprawiają, że znacząco windują ceny, by skompensować ryzyko. Rozsądne podejście do kar umownych w B2B w IT powinno łączyć trzy elementy:

• progi uruchomienia kar – nie każde minimalne przekroczenie SLA powinno automatycznie generować karę,
• limity kar – maksymalna suma kar w danym okresie (np. miesiąc, rok) ogranicza ryzyko po stronie dostawcy,
• jasne powiązanie z parametrami SLA – kary naliczane są za konkretne, mierzalne naruszenia.

Przykład: można ustalić, że jeśli dostępność miesięczna spada poniżej 99,5%, ale jest wyższa niż 99%, klient otrzymuje karę w wysokości 5% miesięcznego wynagrodzenia za daną usługę; przy dostępności poniżej 99% – 10%; przy poważniejszych naruszeniach – dodatkowe prawo do rozwiązania umowy. Wysokość kar musi mieć racjonalne uzasadnienie ekonomiczne, inaczej w razie sporu sąd ma prawo je miarkować.

Kredyty serwisowe jako elastyczna rekompensata za przestoje

Alternatywą lub uzupełnieniem kar umownych są kredyty serwisowe. Polegają one na tym, że za niedotrzymanie SLA dostawca przyznaje klientowi zniżkę na kolejne okresy rozliczeniowe lub dodatkowe godziny usług bez dodatkowego wynagrodzenia. Ten model ma kilka zalet:

• jest mniej konfrontacyjny – nie wymaga od klienta dochodzenia kary w drodze wezwań i ewentualnych pozwów,
• łatwo go zautomatyzować w modelach abonamentowych (np. usługi SaaS),
• wspiera utrzymanie relacji – celem jest poprawa jakości, a nie wyłącznie kara finansowa.

Umowa powinna określać, czy kredyty serwisowe:

• są przyznawane automatycznie po przekroczeniu określonych progów SLA, czy na wniosek klienta,
• czy wyczerpują roszczenia klienta z tytułu naruszenia SLA w danym okresie, czy też możliwe jest dochodzenie dodatkowego odszkodowania,

Limity odpowiedzialności i wyłączenia szkód pośrednich

Przy precyzyjnie opisanym SLA i mechanizmach rekompensaty kolejnym elementem układanki są limity odpowiedzialności. Bez nich dostawca ryzykuje nieproporcjonalne roszczenia za skutki biznesowe, których realnie nie był w stanie przewidzieć ani skontrolować. Z perspektywy klienta również lepiej mieć jasny, liczbowy punkt odniesienia niż niejasne „pełne odszkodowanie na zasadach ogólnych”.

Typowe rozwiązanie to limit odpowiedzialności dostawcy do określonej wielokrotności wynagrodzenia – np. do wysokości opłat zapłaconych za 3, 6 lub 12 miesięcy poprzedzających zdarzenie. Ważne, by limit:

• był powiązany z konkretną usługą – inaczej przy incydencie w jednym module klient może próbować liczyć limit od całości współpracy,
• rozróżniał limity per zdarzenie i per okres (np. maksymalna odpowiedzialność za pojedynczą awarię oraz łączna odpowiedzialność roczna),
• jasno określał, czy kary umowne i kredyty serwisowe wliczają się do limitu, czy też są od niego niezależne.

Drugi element to wyłączenie odpowiedzialności za szkody pośrednie i utracone korzyści. W kontraktach IT przyjęło się wyłączać:

• utracone zyski, utracone dane (o ile nie wynika to z naruszenia odrębnych zobowiązań, np. kopii bezpieczeństwa),
• koszty utraconej reputacji, kary nałożone przez kontrahentów klienta (chyba że strony inaczej umówią się wprost),
• inne szkody, które nie są bezpośrednim, typowym następstwem zawinionego działania dostawcy.

Przykład praktyczny: sklep internetowy ma awarię systemu zamówień przez 3 godziny. Klient zamawiający usługę może twierdzić, że stracił kilkaset zamówień i żądać odszkodowania za wszystkie niewykonane transakcje. Jeżeli jednak w umowie jest klarowny limit odpowiedzialności oraz wyłączenie utraconych zysków, spór sprowadza się do naliczenia kary/kredytu i ewentualnego odszkodowania bezpośredniego w granicach ustalonego pułapu.

Relacja między karami, kredytami a dalszym odszkodowaniem

Kontrowersyjną, ale bardzo ważną kwestią jest odpowiedź na pytanie: czy kara umowna lub kredyt serwisowy wyczerpuje roszczenia klienta za dane naruszenie SLA, czy też oprócz tego klient może żądać dodatkowego odszkodowania na zasadach ogólnych. W praktyce funkcjonują trzy modele:

• model wyczerpujący – przyznanie kary/kredytu zamyka temat odpowiedzialności za konkretną awarię, z wyjątkiem szkód spowodowanych rażącym niedbalstwem lub umyślnie,
• model mieszany – kary/kredyty liczą się „na poczet” odszkodowania, ale jeśli szkoda jest wyższa niż kara, można dochodzić nadwyżki (zwykle w ramach kontraktowego limitu),
• model kumulatywny – kary/kredyty funkcjonują obok odszkodowania, bez zaliczania na jego poczet; ten wariant jest dla dostawcy najbardziej ryzykowny.

Z punktu widzenia bezpieczeństwa prawnego w kontraktach B2B w IT najczęściej stosuje się model wyczerpujący lub mieszany, przy czym wyjątek pozostawia się dla rażącego niedbalstwa i działań umyślnych. Warto też doprecyzować, że brak zgłoszenia roszczenia w określonym terminie (np. 30 lub 60 dni od naruszenia SLA) powoduje wygaśnięcie prawa do kary czy kredytu. To wymusza sprawną komunikację po obu stronach.

Kiedy dostawca nie odpowiada za przestoje – typowe klauzule wyłączające

Żadna umowa nie zniweluje faktu, że część ryzyk leży poza kontrolą dostawcy. Dlatego w modelu B2B trzeba jasno wymienić sytuacje wyłączające odpowiedzialność za awarie i przestoje. Zwykle są to:

• siła wyższa – zdarzenia nadzwyczajne, zewnętrzne i niemożliwe do zapobieżenia (np. poważne katastrofy),
• problemy po stronie klienta – brak dostępu do środowiska, niewykonanie wymaganych działań (aktualizacja przeglądarek, sprzętu), nieautoryzowane modyfikacje,
• awarie dostawców trzecich, na których dostawca nie ma realnego wpływu (np. przerwa w działaniu publicznej sieci operatora, zewnętrzny system płatności),
• przerwy planowe – wcześniej zakomunikowane okna serwisowe w ramach ustalonego harmonogramu.

Krytyczna jest precyzja. Ogólny zapis o „siłach wyższych i okolicznościach niezależnych” nie wystarczy, bo w sporze każda strona będzie interpretować go na swoją korzyść. Dobrym zabiegiem jest dołączenie przykładowego katalogu zdarzeń (przy czym lista powinna mieć charakter otwarty, ale wskazywać typowe kategorie ryzyk).

Odpowiedzialność przy integracjach i środowiskach wielodostawczych

Coraz więcej systemów działa w środowisku, gdzie odpowiedzialność rozmywa się między kilku dostawców. Przykład: aplikacja SaaS hostowana w chmurze publicznej, zintegrowana z zewnętrznym systemem ERP i bramką płatniczą. Wystarczy incydent po stronie jednego z elementów, by klienci końcowi widzieli „awarię całości”.

W takich przypadkach umowa powinna odpowiedzieć na kilka pytań:

• jaki jest zakres odpowiedzialności głównego dostawcy – czy odpowiada wyłącznie za własny moduł, czy także za całość łańcucha usług,
• kto zarządza incydentem – czy klient kontaktuje się z jednym punktem („single point of contact”), który koordynuje dalsze działania,
• jak liczy się dostępność – czy uwzględnia się przestoje systemów zewnętrznych, czy liczy się tylko status elementów utrzymywanych bezpośrednio przez dostawcę.

Dla porządku często stosuje się zapis, że dostawca nie ponosi odpowiedzialności za niedostępność lub nieprawidłowe działanie usług podmiotów trzecich, chyba że działają one jako jego podwykonawcy wybrani i kontrolowani przez niego. Inaczej grozi sytuacja, w której dostawca „przejmuje” na siebie ryzyko kontraktów, których nawet nie widział.

Obowiązki klienta jako warunek odpowiedzialności dostawcy

Odpowiedzialność w IT nie działa w próżni. W modelu B2B kluczowe jest opisanie obowiązków klienta, od których zależy możliwość wywiązania się przez dostawcę z gwarantowanych parametrów. Chodzi m.in. o:

• zapewnienie kontaktu i dostępów – imienne osoby kontaktowe, uprawnienia administracyjne, dostęp do logów i środowisk testowych/produkcyjnych,
• przestrzeganie procedur zgłaszania incydentów – określony kanał (system zgłoszeń, infolinia), zakres informacji wymaganych do przyjęcia zgłoszenia,
• terminowe testy i akceptacja zmian – szczególnie przy wdrożeniach i większych release’ach,
• minimalne wymagania sprzętowe i programowe po stronie użytkowników końcowych.

Brak tych elementów często prowadzi do sporów, w których każda ze stron powołuje się na „zawinienie” drugiej. Dlatego w umowie dobrze dodać zasadę, że niewykonanie lub nienależyte wykonanie obowiązków przez klienta skutkuje zawieszeniem SLA lub odpowiedzialności dostawcy w zakresie, w jakim miało to wpływ na awarię lub czas jej usunięcia. Można też przewidzieć uproszczony mechanizm dowodowy: domniemanie, że jeśli dostawca nie miał dostępu lub wymaganych informacji, czasy SLA ulegają odpowiedniemu wydłużeniu.

Raportowanie incydentów i audyt rozliczeń SLA

Aby spory o odpowiedzialność za przestoje nie opierały się na „słowo przeciwko słowu”, trzeba zadbać o transparentne raportowanie. Poza samym wzorem na obliczanie SLA i definicją incydentu przydają się:

• cykliczne raporty SLA – np. miesięczne lub kwartalne, wskazujące liczbę i czas trwania incydentów, ich priorytety oraz przyczyny,
• wspólna akceptacja raportów – możliwość zgłoszenia zastrzeżeń przez klienta w określonym terminie, po którym raport uznaje się za przyjęty,
• prawo audytu – w rozsądnym zakresie, by klient mógł zweryfikować dane źródłowe (logi, wpisy w systemie zgłoszeń), z jednoczesną ochroną poufności i bezpieczeństwa.

W praktyce wiele firm stosuje prosty model: jeśli klient w określonym czasie nie zgłosi zastrzeżeń do raportu SLA, staje się on podstawą ostatecznego rozliczenia ewentualnych kar i kredytów serwisowych za dany okres. Ogranicza to ryzyko „otwierania” tych samych tematów po wielu miesiącach.

Bezpieczeństwo danych a odpowiedzialność za skutki incydentów

W usługach IT przestoje często wiążą się z ryzykiem naruszenia poufności i integralności danych. Odpowiedzialność za takie incydenty powinna być opisana spójnie z przepisami o ochronie danych (np. RODO) oraz wewnętrznymi politykami bezpieczeństwa klienta. W szczególności przydają się postanowienia, które:

• określają standardy bezpieczeństwa technicznego (szyfrowanie, backupy, segmentacja środowisk, procedury odzyskiwania),
• regulują czasy i sposób zgłaszania naruszeń bezpieczeństwa klientowi i – w razie potrzeby – organom nadzorczym,
• wskazują, w jakim zakresie dostawca odpowiada za utratę lub uszkodzenie danych (zwykle w ramach odrębnego limitu odpowiedzialności, powiązanego z usługą backupu).

W niektórych modelach rozsądne jest rozdzielenie odpowiedzialności: inny limit dla „zwykłych” awarii funkcjonalnych, a inny – często wyższy – dla incydentów bezpieczeństwa danych osobowych. Można też uzależnić ten drugi limit od posiadania przez dostawcę odpowiedniego ubezpieczenia OC zawodowego lub cyber.

Mechanizmy eskalacji i rozwiązywania sporów o przestoje

Nawet najlepiej napisana umowa nie wyeliminuje wszystkich konfliktów. Dlatego przy opisywaniu odpowiedzialności za awarie i przestoje dobrze zdefiniować mechanizmy eskalacji i rozwiązywania sporów. W praktyce sprawdzają się m.in.:

• wewnętrzna ścieżka eskalacji – od zespołu helpdesku, przez kierownika kontraktu, po zarząd lub komitet sterujący,
• terminy na reakcję w sporach – np. obowiązek udzielenia pisemnego stanowiska w kwestii odpowiedzialności za incydent w ciągu określonej liczby dni,
• procedura ustalania przyczyn źródłowych (post-mortem) – wspólny raport powypadkowy, który wskazuje przyczynę, zakres odpowiedzialności oraz plan działań naprawczych.

W umowach przy bardziej krytycznych usługach pojawia się też często zapis o obowiązkowej mediacji lub negocjacjach przed skierowaniem sporu do sądu lub arbitrażu. To pozwala szybciej dojść do porozumienia co do rekompensaty i środków naprawczych, bez paraliżu współpracy.

Dobre praktyki przy negocjowaniu odpowiedzialności za awarie w B2B

Na zakończenie kilka prostych zasad, które pomagają utrzymać rozsądny balans między interesami stron. Przy negocjowaniu umowy:

• traktuj parametry SLA, kary, kredyty i limity odpowiedzialności jako spójny system naczyń połączonych, a nie zestaw oderwanych zapisów,
• odróżniaj cele jakościowe (ambitne, „targetowe” SLA) od twardych zobowiązań kontraktowych, za których naruszenie faktycznie płaci się pieniądze,
• sprawdzaj, czy przewidziane kary i limity są realnie skorelowane z wynagrodzeniem – inaczej jedna poważniejsza awaria może „zjeść” kilka lat marży,
• dla kluczowych procesów biznesowych klienta ustal osobne, wyższe poziomy ochrony (np. krótsze RTO, wyższe kary, odrębne limity), a dla mniej krytycznych – prostsze i tańsze parametry,
• doprecyzuj tryb aktualizacji SLA w trakcie trwania umowy – wzrost obciążenia, zmiana architektury czy migracja do chmury często wymagają korekty parametrów i odpowiedzialności.

Ostatecznie celem kontraktu B2B w IT nie jest przerzucenie całego ryzyka na jedną stronę, ale stworzenie takiej konstrukcji, w której awarie i przestoje są:

• jak najszybciej wykrywane i usuwane,
• sprawiedliwie rozliczane, zgodnie z ustalonym z góry algorytmem,
• punktem wyjścia do poprawy jakości usług, a nie wyłącznie do sporów o odszkodowanie.

Klauzule siły wyższej i zdarzeń nadzwyczajnych w kontekście SLA

Coraz więcej awarii i przestojów ma źródło poza bezpośrednią kontrolą którejkolwiek ze stron: globalne awarie chmury, przerwy w działaniu operatorów telekomunikacyjnych, ataki DDoS na infrastrukturę krytyczną. Standardowa klauzula siły wyższej z ogólnych warunków współpracy zwykle nie wystarcza, jeśli umowa szczegółowo reguluje SLA i odpowiedzialność finansową.

Przy usługach IT opłaca się doprecyzować mechanizm „wyłączeń SLA” w przypadku zdarzeń nadzwyczajnych, w tym m.in.:

• katalog zdarzeń siły wyższej – nie tylko klęski żywiołowe czy wojna, ale też długotrwałe przerwy w dostawie energii, zakłócenia w działaniu łączy telekomunikacyjnych, globalne awarie centrów danych,
• warunek należytej staranności – brak odpowiedzialności tylko wtedy, gdy dostawca faktycznie nie miał realnego wpływu na zdarzenie i podejmował rozsądne działania prewencyjne,
• obowiązek minimalizacji skutków – wymóg uruchomienia planów ciągłości działania (BCP/DRP), przełączenia na zapasowe środowiska lub tryb „degraded mode”, jeśli to możliwe,
• obowiązki informacyjne – maksymalny czas na przekazanie klientowi komunikatu o zaistnieniu zdarzenia, szacowanym czasie trwania i możliwych konsekwencjach.

W dobrych umowach pojawia się też rozróżnienie między zawieszeniem kar SLA a zawieszeniem całej odpowiedzialności odszkodowawczej. To nie to samo. Czasem strony godzą się na wyłączenie naliczania kar za okres trwania siły wyższej, ale pozostawiają odpowiedzialność za brak wdrożenia uzgodnionych procedur awaryjnych.

Usługi chmurowe i model „shared responsibility”

Przy kontraktach B2B opartych na chmurze publicznej lub hybrydowej odpowiedzialność za awarie i przestoje jest wielowarstwowa. Dostawca rozwiązań (software house, integrator) najczęściej bazuje na infrastrukturze IaaS/PaaS globalnego providera, a klient używa aplikacji w modelu SaaS lub dedykowanym.

Umowa powinna odzwierciedlać model współdzielonej odpowiedzialności. W praktyce pomocne są dwie tabele: pierwsza opisuje kto za co odpowiada operacyjnie, druga – kto ponosi odpowiedzialność kontraktową wobec klienta. Warto jednoznacznie wskazać m.in.:

• kto odpowiada za dostępność warstwy infrastruktury (serwery, sieć, storage),
• kto odpowiada za aktualizacje i konfigurację platformy (bazy danych, middleware, kontenery),
• kto odpowiada za kod aplikacyjny i integracje z systemami zewnętrznymi,
• kto odpowiada za zarządzanie kontami użytkowników, politykami haseł i dostępów.

Jeżeli dostawca rozlicza się z klientem z dostępności całego rozwiązania, a sam korzysta z usług chmurowych, dobrze jest:

• powiązać własne SLA z SLA dostawcy chmury (np. „dostawca zapewnia dostępność nie niższą niż deklarowana przez… plus określona nadwyżka”),
• opisać zasady przekazywania benefitów – np. kredyty SLA otrzymane od providera infrastruktury mogą być w całości lub częściowo przenoszone na klienta końcowego,
• wskazać, kiedy awaria chmury stanowi wyłączenie odpowiedzialności, a kiedy nie – np. jeśli dotyczy tylko jednego regionu, a dostawca nie wdrożył wieloregionowego scenariusza wysokiej dostępności, choć był on przewidziany w architekturze.

W praktyce spory pojawiają się szczególnie przy złożonych incydentach: z perspektywy klienta „chmura nie działa”, natomiast globalny provider twierdzi, że jego usługa była dostępna, a problem leżał w konfiguracji po stronie integratora. Czytelny opis odpowiedzialności na styku tych warstw oszczędza długich ustaleń techniczno-prawnych post factum.

Change management a odpowiedzialność za skutki wdrożeń

Znaczna część poważnych awarii nie wynika z nagłej usterki sprzętu, lecz z nieudanego wdrożenia zmiany: nowej wersji aplikacji, poprawki bezpieczeństwa, migracji danych. Sama procedura zarządzania zmianą (change management) zwykle trafia do załącznika operacyjnego, ale jej kluczowe elementy mocno wpływają na rozkład odpowiedzialności.

W kontrakcie warto usystematyzować przede wszystkim:

• klasy zmian – drobne, standardowe, większe, wysokiego ryzyka, z przypisanymi procedurami testów i akceptacji,
• kto podejmuje decyzję o wdrożeniu – czy wystarczy zgoda Product Ownera po stronie klienta, czy wymagany jest formalny CAB (Change Advisory Board),
• okna serwisowe i okna zmian – jasno określone przedziały czasowe, w których dopuszcza się utrudnienia lub krótkie przerwy,
• plan wycofania (rollback) – wymagany zakres dokumentacji i testów, które muszą poprzedzić wdrożenie zmiany.

Od strony odpowiedzialności praktyczne są zapisy, że:

• jeżeli klient wymusza wdrożenie zmiany z pominięciem standardowej procedury (np. bez pełnych testów, w okresie zakazu wdrożeń), odpowiada za ewentualne skutki w uzgodnionym zakresie,
• jeżeli dostawca zignoruje uzgodnioną procedurę change management lub wdroży zmianę bez wymaganej zgody, ponosi zwiększoną odpowiedzialność za spowodowane tym przestoje,
• w określonych scenariuszach przestoje w oknie serwisowym nie wliczają się do SLA, o ile mieszczą się w z góry zdefiniowanych granicach (np. liczba i długość planowanych przerw miesięcznie).

Dobrym kompromisem jest model, w którym ewidentne błędy wdrożeniowe po stronie dostawcy (np. brak możliwości przywrócenia poprzedniej wersji) skutkują nie tylko standardowymi karami SLA, lecz także obowiązkiem wykonania na własny koszt dodatkowych działań naprawczych lub refaktoryzacji problematycznego modułu.

Poziomy wsparcia i przypisanie odpowiedzialności do linii serwisowych

W organizacjach korzystających z rozbudowanych systemów IT awarie obsługuje się często w modelu kilku linii wsparcia (L1, L2, L3). Przypisanie odpowiedzialności kontraktowej do tych ról bywa pomijane, a to właśnie na tym etapie tracone są godziny, które później „psują” wskaźniki SLA.

W części serwisowej umowy można precyzyjnie zmapować:

• jakie incydenty obsługuje wsparcie L1 po stronie klienta (np. podstawowa diagnostyka, restart usług, weryfikacja konfiguracji użytkownika),
• co trafia na L2/L3 po stronie dostawcy i od którego momentu liczy się czas reakcji i usunięcia incydentu,
• jak wygląda przekazanie zgłoszenia między liniami – wymagane informacje, maksymalny czas na eskalację, odpowiedzialność za błędną kwalifikację.

Często stosuje się zasadę, że czas poświęcony na czynności L1 po stronie klienta nie wlicza się do czasu obsługi SLA po stronie dostawcy, o ile dostawca nie ma wpływu na sposób realizacji tych czynności. Wymaga to jednak:

• precyzyjnych definicji, jakie zadania wchodzą w zakres L1,
• szkolenia zespołów klienta w obsłudze standardowych scenariuszy,
• udostępnienia checklist i playbooków diagnostycznych, które klient powinien zrealizować przed eskalacją do L2/L3.

Jeżeli klient zleca także L1 dostawcy (np. w modelu pełnego outsourcingu IT), w zamian za wyższą opłatę serwisową można oczekiwać szerszej odpowiedzialności za czasy reakcji oraz usunięcia incydentów, bez rozbijania ich na „wewnętrzne” etapy.

Odpowiedzialność za dostępność a model rozliczeń (time & material vs. fixed price)

To, jak skonstruowany jest model finansowy umowy, ma bezpośredni wpływ na to, jak rozsądnie da się opisać odpowiedzialność za awarie. Inaczej negocjuje się kontrakt typu time & material, inaczej utrzymanie w modelu stałej opłaty (managed services), a jeszcze inaczej duże wdrożenie w rozliczeniu fixed price.

Przykładowo:

• w modelu time & material dostawca co do zasady rozlicza czas pracy, a nie rezultat. Można wprowadzić SLA dla czasu reakcji i podstawowych parametrów jakości, ale odpowiedzialność finansowa za niedostępność bywa ograniczona. Zamiast wysokich kar częściej stosuje się prawo do bezkosztowego poprawienia wad w określonym terminie,
• w modelu managed services/abonamentowym sensowne są mierzalne SLA z karami lub kredytami, bo dostawca ma większą kontrolę nad zasobami (np. stały zespół, rezerwowe moce),
• w projektach fixed price ważna jest granica między czasem budowy (kiedy zwykle SLA nie obowiązują, a odpowiedzialność wynika z rękojmi/gwarancji jakości) a faza produkcyjna, w której zaczynają działać wskaźniki dostępności i związane z nimi kary.

Jeżeli jeden kontrakt obejmuje zarówno wdrożenie, jak i późniejsze utrzymanie, warto wyraźnie zaznaczyć moment „przełączenia” odpowiedzialności – np. datę podpisania protokołu odbioru produkcyjnego, od której zaczyna się bieg SLA i liczonych jest RTO/RPO.

Współodpowiedzialność kilku dostawców i koordynator usług

W większych organizacjach IT rzadko odpowiada jeden podmiot. Typowy pejzaż to: integrator, kilka firm utrzymujących poszczególne moduły, operator centrum danych, dostawca łączy, wewnętrzny zespół klienta. W tej układance rozmyta odpowiedzialność jest łatwiejsza niż realne rozliczenie za przestoje.

Jeden z modeli kontraktowych zakłada powołanie service integratora lub koordynatora usług, który:

• pełni rolę single point of contact dla klienta w sprawach incydentów i zmian,
• koordynuje działania wszystkich zaangażowanych dostawców,
• utrzymuje wspólny rejestr usług i zależności (service map),
• odpowiada za przygotowanie zintegrowanych raportów SLA.

Umowa z takim podmiotem musi jednak odpowiedzieć na trudne pytanie: czy koordynator odpowiada finansowo za całość dostępności (łącznie z usługami, których sam nie świadczy), czy tylko za „obsługę” i raportowanie? Pierwszy model daje klientowi prostszy punkt rozliczeń, ale wiąże się z istotnie wyższą ceną i koniecznością mocnego reasekuracyjnego „rozsmarowania” ryzyka w łańcuchu podwykonawców.

W drugim wariancie odpowiedzialność merytoryczna i finansowa za konkretne elementy systemu pozostaje po stronie poszczególnych dostawców, natomiast koordynator odpowiada przede wszystkim za:

• prawidłową klasyfikację i eskalację incydentów,
• dotrzymanie terminów reakcji w ramach swojego zakresu,
• integrację danych do raportów SLA i poprawność wniosków z analiz powypadkowych.

Szare strefy odpowiedzialności: performance, degradacja usług i „soft downtime”

Nie każda sytuacja, w której użytkownik narzeka na system, to formalna niedostępność. Coraz częściej kluczowe są parametry wydajnościowe – czas odpowiedzi, przepustowość, liczba obsługiwanych transakcji na sekundę. Bez ich opisania łatwo o spór, czy mieliśmy do czynienia z awarią, czy „jedynie” obniżeniem komfortu pracy.

Przy projektowaniu odpowiedzialności kontraktowej warto więc zdefiniować także:

• metryki wydajności (np. średni i maksymalny czas odpowiedzi dla kluczowych operacji, czas generowania raportów),
• progi degradacji – kiedy obniżona wydajność traktowana jest jak incydent SLA (np. gdy określony próg przekraczany jest dłużej niż przez określony czas),
• różnicę między incydentem „twardym” (całkowity brak dostępności) a „soft downtime” (dostępność z poważnie obniżonymi parametrami).

Dla degradacji wydajności można przewidzieć odrębny, zwykle łagodniejszy, schemat rozliczania odpowiedzialności, np. mniejsze kredyty serwisowe lub mechanizm „progressive penalties” – tym wyższe, im dłużej trwa spadek wydajności.

Z perspektywy technicznej kluczowe jest także ustalenie, czyje narzędzia pomiarowe są „źródłem prawdy”. Spór o to, czy system działał za wolno, często wynika z różnic między pomiarami po stronie klienta (np. w oddziałach z wolniejszym łączem) a danymi z monitoringu dostawcy w centrum danych lub chmurze.

Dokumentacja i procedury jako „warstwa ochronna” dla obu stron

Najczęściej zadawane pytania (FAQ)

Jak opisać odpowiedzialność za awarie i przestoje w umowie B2B w IT?

Odpowiedzialność za awarie i przestoje warto opisać nie tylko jednym paragrafem o karach umownych, ale całym systemem postanowień. Powinien on obejmować: precyzyjne definicje awarii i przestoju, zakres usługi (za jakie elementy rozwiązania dostawca faktycznie odpowiada), parametry SLA (dostępność, czasy reakcji i przywrócenia), procedury zgłoszeń oraz limity odpowiedzialności.

Kluczowe jest, aby definicje były mierzalne (np. procent użytkowników, czas trwania, konkretne funkcje), a nie ogólne („poważne zakłócenie”). Dzięki temu obie strony mogą obiektywnie stwierdzić, czy doszło do incydentu dającego podstawę do roszczeń.

Co powinna zawierać dobra definicja awarii w umowie IT B2B?

Dobra definicja awarii powinna rozróżniać co najmniej kilka poziomów problemów, np. awarie krytyczne, usterki istotne i usterki drobne. Każda kategoria powinna mieć opis techniczny, odnoszący się do:

• zakresu wpływu (np. większość użytkowników, konkretna funkcja),
• skutku biznesowego (całkowita niedostępność vs. obniżenie funkcjonalności),
• minimalnego czasu trwania zdarzenia.

Zamiast ogólnych sformułowań warto posługiwać się warunkami w stylu: „niedostępność funkcji X dla więcej niż Y% użytkowników przez co najmniej Z minut”. Takie techniczne progi minimalizują pole do sporów interpretacyjnych.

Czym różni się przestój planowany od awarii i dlaczego trzeba to rozdzielić w umowie?

Przestój planowany to z góry zaplanowana i zakomunikowana przerwa w działaniu systemu, wynikająca np. z aktualizacji, prac serwisowych lub migracji. Awarie i usterki to zdarzenia nieplanowane, które występują wbrew założeniom SLA i umowy.

W kontraktach B2B w IT warto jasno wskazać, że przestoje planowane (np. zgłoszone z 48-godzinnym wyprzedzeniem, w określonych godzinach serwisowych) są wyłączone z liczenia dostępności SLA i z odpowiedzialności odszkodowawczej. Brak tego rozróżnienia prowadzi do sytuacji, w której klient traktuje każde wyłączenie jako „awarię” i domaga się rekompensat.

Jak prawidłowo zdefiniować SLA (dostępność) w umowie B2B w IT?

Sama liczba typu „99,5% dostępności” nie wystarczy. W umowie trzeba określić:

• okres rozliczeniowy (miesięczny, kwartalny, roczny),
• sposób liczenia czasu niedostępności (od zgłoszenia, od wykrycia przez monitoring, od faktycznego wystąpienia),
• co jest wyłączone z SLA (przestoje planowane, siła wyższa, awarie usług zewnętrznych),
• czy SLA dotyczy całego systemu, czy poszczególnych komponentów lub funkcji.

Dobrą praktyką jest wpisanie konkretnego wzoru na obliczanie dostępności oraz sposobu dokumentowania incydentów, co ułatwia później rozliczanie ewentualnych naruszeń SLA.

Za co realnie odpowiada dostawca IT przy awarii – aplikacja, infrastruktura, integracje?

To zależy od tego, jak zostanie zdefiniowany zakres usługi w umowie. W interesie obu stron jest precyzyjne wskazanie, czy dostawca odpowiada:

• tylko za software (kod aplikacji),
• również za infrastrukturę (serwery, sieć, baza danych),
• za integracje z systemami zewnętrznymi,
• za dostępność usług podmiotów trzecich (np. chmura, operator płatności).

Bez takiego rozdzielenia łatwo o spór, w którym klient oczekuje pełnej odpowiedzialności finansowej za przestój spowodowany np. awarią łącza internetowego lub chmury, nad którymi dostawca aplikacji nie ma realnej kontroli.

Jakie elementy powinno zawierać SLA dotyczące czasów reakcji i przywrócenia usługi?

SLA powinno jasno wskazywać nie tylko procent dostępności, ale również:

• czas reakcji – maksymalny czas od zgłoszenia do podjęcia działań przez dostawcę,
• czas przywrócenia (RTO) – docelowy maksymalny czas usunięcia awarii określonego typu,
• priorytety incydentów – różne czasy w zależności od wagi i wpływu na biznes,
• godziny świadczenia wsparcia (np. 24/7, dni robocze 8:00–18:00).

Bez powiązania priorytetów z konkretnymi czasami i kalendarzem wsparcia klienci często oczekują szybkiej reakcji również w nocy, weekendy i święta, mimo że umowa tego nie przewiduje. Czytelna macierz priorytetów i godzin wsparcia znacząco ogranicza takie nieporozumienia.

Czy w umowie B2B w IT trzeba uwzględniać przepisy o ochronie danych i inne regulacje?

Tak, szczególnie gdy usługa dotyczy przetwarzania danych osobowych, usług w chmurze lub systemów o znaczeniu krytycznym dla ciągłości biznesu. Odpowiedzialność za awarie i przestoje coraz częściej łączy się z obowiązkami wynikającymi z RODO, przepisów o cyberbezpieczeństwie czy regulacji branżowych.

Umowa powinna uwzględniać m.in. obowiązki związane z naruszeniami ochrony danych, wymagany poziom bezpieczeństwa technicznego i organizacyjnego, a także podział odpowiedzialności między klienta, dostawcę i ewentualnych podwykonawców (np. dostawców chmury). Zignorowanie tego kontekstu może sprawić, że przy poważnej awarii kontrakt nie będzie zabezpieczał realnych ryzyk prawnych.

Kluczowe obserwacje

• Precyzyjne opisanie odpowiedzialności za awarie i przestoje w umowach B2B w IT zapobiega skrajnościom: przerzucaniu całego ryzyka biznesowego na dostawcę lub całkowitemu „schowaniu się” za wyłączeniami odpowiedzialności.
• Odpowiedzialność za awarie to system powiązanych elementów (definicje, SLA, procedury zgłoszeń, limity odpowiedzialności), który musi jasno określać zarówno uprawnienia klienta, jak i zakres ryzyka po stronie dostawcy.
• Kluczowe jest rozróżnienie typów problemów (awarie krytyczne, usterki istotne, usterki drobne, przestoje planowane) oraz opisanie ich w sposób techniczny i mierzalny, a nie ogólny czy emocjonalny.
• Umowa powinna szczegółowo definiować zakres usługi (software, infrastruktura, integracje, usługi podmiotów trzecich) i granice odpowiedzialności, aby właściwie przypisać ryzyka i uniknąć sporów.
• Parametr dostępności (SLA) ma sens tylko wtedy, gdy umowa dokładnie określa sposób jego liczenia: okres rozliczeniowy, moment startu niedostępności, wyłączenia (przerwy planowe, siła wyższa, dostawcy zewnętrzni) oraz zakres (cały system czy poszczególne komponenty).
• Brak uwzględnienia kontekstu regulacyjnego (bezpieczeństwo danych, ciągłość usług, odpowiedzialność dostawców chmury) sprawia, że kontrakt działa wyłącznie „w ładnej pogodzie” i zawodzi przy poważnym incydencie.

Warte uwagi:

• 

  Freelance IT a prawo – co powinno być w Twojej umowie?

• 

  Umowy IT – co musi zawierać każda dobra umowa wdrożeniowa?

• 

  Czy chmura może zniknąć? – co się dzieje po…

• 

  Kiedy programista odpowiada prawnie za błędy w kodzie?

• 

  Jak długo trwa deploy aplikacji w różnych chmurach?

• 

  Czy moje dane w chmurze są bezpieczne?