Umowa SLA na system dedykowany: co ma być w środku

O czym jest ten tekst, a o czym nie

O zobowiązaniach: kto, kiedy i w jakim czasie reaguje. O kosztach utrzymania pisaliśmy osobno — tam jest struktura rachunku, tutaj są obietnice, które ten rachunek kupuje. To dwie różne rozmowy i warto ich nie mieszać.

Cztery rzeczy, które muszą być nazwane

1. Co znaczy „awaria”

Bez definicji każdy zgłasza wszystko jako pilne, a dostawca nic nie traktuje jako pilne. Minimalny podział, który się sprawdza, ma trzy poziomy: system nie działa · działa, ale coś istotnego jest zepsute · działa, a to jest usprawnienie.

Kluczowa jest nie liczba poziomów, tylko przykłady przy każdym. „Nie można złożyć zamówienia” to poziom pierwszy. „Raport eksportuje się w złej kolejności” — nie. Bez przykładów podział jest teoretyczny.

2. Czas reakcji, nie czas naprawy

To najczęstsze nieporozumienie. Reakcja to moment, w którym ktoś potwierdza, że wie o sprawie i się nią zajmuje. Naprawa to moment, w którym działa. Poważny dostawca zobowiąże się do pierwszego i opisze, jak podchodzi do drugiego — bo czasu naprawy nie da się obiecać, nie znając usterki.

Jeśli w umowie jest twardy czas naprawy dla wszystkich usterek, to znaczy, że ktoś obiecał coś, czego nie kontroluje.

3. Godziny, w których to obowiązuje

„24/7” brzmi dobrze i prawie nigdy nie jest prawdą przy małym zespole. Uczciwiej jest napisać realne okno i osobno opisać, co się dzieje poza nim. Warto dopasować je do tego, kiedy Wasz biznes naprawdę zarabia — sklep ma szczyt w niedzielę wieczorem, a nie w środę o dziesiątej.

4. Kto odpowiada za co

System dedykowany prawie nigdy nie stoi sam. Pod spodem jest hostowanie, bramka płatnicza, wysyłka maili, czasem model językowy albo dane z rejestru. Gdy pada któraś z tych rzeczy, dostawca systemu nie ma na to wpływu — ale ma wpływ na to, czy się o tym dowiecie i czy jest plan awaryjny.

Pytanie do umowy brzmi więc nie „czy gwarantujecie działanie bramki”, tylko „co robicie, kiedy bramka padnie”.

Czego SLA nie załatwia

Umowa opisuje, co się stanie po awarii. Nie zmniejsza szansy, że awaria nastąpi. Za to odpowiada coś zupełnie innego — sposób pracy dostawcy.

U nas wygląda to tak: przed każdym wypuszczeniem zmian uruchamiają się automatyczne kontrole, które sprawdzają, czy strony odpowiadają poprawnie, czy adresy się nie rozjechały i czy powiązania językowe są spójne. Jeśli któraś kontrola nie przechodzi, zmiana po prostu nie wychodzi — nie ma możliwości jej ominięcia w pośpiechu. Po każdym wdrożeniu ten sam zestaw sprawdzeń leci jeszcze raz na żywej stronie.

To nie jest sekcja o nas — to jest pytanie do zadania każdemu dostawcy: co u Was blokuje wypuszczenie zepsutej zmiany? Odpowiedź „testujemy przed wysłaniem” znaczy „nic”.

Trzy zapisy, o które warto poprosić

1. Raport po awarii. Krótki opis: co się stało, dlaczego i co zrobiono, żeby się nie powtórzyło. Bez tego te same rzeczy wracają.
2. Dostęp do kopii zapasowych po Waszej stronie. Nie „robimy kopie”, tylko „możecie je pobrać sami”.
3. Zapis o przekazaniu. Co dostajecie, gdyby współpraca się kończyła — i w jakim terminie. To ten sam wątek co przy uzależnieniu od dostawcy.

Jak wyglądają realne poziomy pilności

Zamiast abstrakcyjnych definicji — przykłady, które da się przekleić do własnej umowy i podmienić na swoje procesy.

Poziom 1: firma nie zarabia

Klient nie może kupić, złożyć zamówienia albo się zalogować. Strona nie odpowiada. Płatności nie przechodzą. Tu liczy się reakcja liczona w godzinach i kontakt inny niż mail — bo mail w sobotę wieczorem nikt nie czyta.

Poziom 2: firma zarabia, ale ktoś pracuje ręcznie

Automat przestał wysyłać potwierdzenia, więc ktoś wysyła je ręcznie. Raport się nie generuje, więc ktoś liczy w arkuszu. Nie jest to katastrofa, ale każdy dzień kosztuje czyjś czas — i po dwóch tygodniach ludzie zaczynają uważać, że tak ma być.

Poziom 3: to jest usprawnienie

Kolumna w złej kolejności, brzydki układ na telefonie, brakująca opcja filtrowania. Realny termin to najbliższa planowana zmiana, a nie „niezwłocznie”. Nazwanie tego wprost oszczędza obu stronom rozczarowania.

Czego nie ma w typowej umowie, a warto dopisać

1. Kto ma dostęp do czego. Imienna lista po obu stronach, aktualizowana przy zmianach w zespole. Brzmi biurokratycznie, dopóki ktoś nie odejdzie z firmy z aktywnym dostępem do bazy.
2. Co się dzieje przy zmianie u dostawcy zewnętrznego. Bramki płatnicze i usługi pocztowe zmieniają zasady bez pytania. Umowa powinna mówić, kto pilnuje tych zmian i w jakim trybie system się do nich dostosowuje.
3. Ile zmian miesięcznie mieści się w opłacie. Bez tego każda drobna prośba staje się negocjacją, a obie strony zaczynają liczyć, kto komu więcej.
4. Jak wygląda przekazanie. Nie tylko „co dostajemy”, ale też „w jakim stanie” — czy dokumentacja jest aktualna i czy ktoś z zewnątrz jest w stanie to uruchomić.

Dlaczego to jest rozmowa o zaufaniu, a nie o paragrafach

Żadna umowa serwisowa nie zmusi nikogo do dobrej pracy. Kary umowne robią tylko tyle, że dostawca zaczyna się zabezpieczać — ostrożniej opisuje zobowiązania, szerzej definiuje wyłączenia i wolniej podejmuje ryzyko przy naprawie.

Sensowne SLA robi coś innego: ustala wspólny język na dzień, w którym coś pójdzie nie tak. Obie strony wiedzą, co znaczy „pilne”, w jakim czasie ktoś się odezwie i czego można oczekiwać, a czego nie. To wystarczy, żeby awaria była problemem technicznym, a nie konfliktem.

Reszta zależy od tego, czy dostawca odbiera telefon. Tego nie da się zapisać.

Jak to czytać, gdy dostaniecie gotowy dokument

Zaznaczcie każde zdanie, w którym pada słowo „niezwłocznie”, „w miarę możliwości” albo „w rozsądnym czasie”. Przy każdym takim zdaniu poproście o liczbę. Jeśli liczby nie ma, ten zapis nie znaczy nic i obie strony będą go pamiętać inaczej.

Reszta dokumentu zwykle jest w porządku.