Awaria systemu księgowego w dniu zamknięcia miesiąca, niedziałająca poczta przed wysyłką ofert albo podejrzane logowanie do firmowego konta – w takich sytuacjach nie wystarczy wiedzieć, że dostawca „opiekuje się IT”. Potrzebna jest jasna odpowiedź na pytanie: kiedy podejmie działanie, w jakim zakresie i kto odpowiada za kolejne kroki. Dobrze przygotowana umowa SLA zamienia ogólne deklaracje w konkretne zasady współpracy, które chronią ciągłość działania firmy.
SLA, czyli Service Level Agreement, to ustalenie poziomu usług. Najczęściej stanowi część umowy na stałą obsługę informatyczną, ale może też dotyczyć monitoringu, infrastruktury sieciowej, systemów kopii zapasowych czy wsparcia środowiska pracy zdalnej. Dla firmy nie jest to techniczny załącznik do schowania w segregatorze. To dokument operacyjny, który ma działać wtedy, gdy pracownicy nie mogą wykonywać swoich obowiązków.
Umowa SLA nie jest obietnicą, że nic się nie zepsuje
Żaden odpowiedzialny dostawca IT nie zagwarantuje, że awaria nigdy nie wystąpi. Sprzęt się starzeje, aktualizacje potrafią powodować nieprzewidziane konflikty, a cyberprzestępcy nie planują ataków według godzin pracy biura. Celem SLA jest więc nie tyle wyeliminowanie każdego problemu, ile ograniczenie jego skutków oraz uporządkowanie reakcji.
W praktyce dobra umowa określa, jakie systemy są objęte opieką, przez jakie kanały można zgłaszać incydenty i jak dostawca ustala ich priorytet. Powinna również wskazywać granice odpowiedzialności. Jeśli firma korzysta z aplikacji branżowej obsługiwanej przez zewnętrznego producenta, partner IT może koordynować zgłoszenie i diagnozować środowisko, ale nie zawsze ma wpływ na termin usunięcia błędu w kodzie tej aplikacji.
To ważne rozróżnienie. Nieprecyzyjne SLA rodzi rozczarowanie po obu stronach: klient zakłada pełną odpowiedzialność za każdy element, a dostawca traktuje część zadań jako dodatkowo płatne lub pozostające poza zakresem. Jasne zapisy pozwalają uniknąć tego sporu, zanim pojawi się problem.
Czas reakcji to nie to samo co czas usunięcia awarii
To jeden z najczęściej źle interpretowanych zapisów. Jeżeli SLA przewiduje reakcję na awarię krytyczną w ciągu jednej godziny, nie oznacza to automatycznie, że po godzinie wszystko wróci do normy. Czas reakcji określa moment, w którym zgłoszenie zostanie przyjęte, ocenione i rozpocznie się praca nad problemem.
Czas przywrócenia usługi zależy od przyczyny. Inaczej wygląda reset zablokowanego konta, inaczej odtworzenie danych po uszkodzeniu serwera, a jeszcze inaczej incydent bezpieczeństwa wymagający odizolowania urządzeń i analizy logów. W tym ostatnim przypadku pochopne „uruchomienie wszystkiego z powrotem” może utrwalić skutki ataku lub naruszyć materiał potrzebny do wyjaśnienia zdarzenia.
Warto zatem oczekiwać od umowy dwóch osobnych parametrów: czasu reakcji oraz docelowego czasu rozwiązania albo przywrócenia działania. Jeśli drugiego parametru nie da się określić sztywno, SLA powinno opisywać sposób komunikacji. Klient musi wiedzieć, kto prowadzi sprawę, kiedy otrzyma aktualizację i jakie działania są podejmowane.
Priorytet powinien wynikać z wpływu na biznes
Dobry model priorytetów nie ocenia problemu wyłącznie przez pryzmat techniczny. Awaria jednego laptopa może być drobną usterką, ale nie wtedy, gdy należy on do osoby przygotowującej przetarg z terminem za godzinę. Z kolei chwilowy błąd na ekranie recepcji może mieć niski priorytet, jeśli nie blokuje obsługi klientów.
Najczęściej wyróżnia się incydenty krytyczne, wysokie, standardowe i niskie. Krytyczny jest na przykład brak dostępu do kluczowego systemu dla wielu pracowników, awaria łącza zatrzymująca pracę oddziału albo podejrzenie przejęcia konta administratora. Priorytet wysoki może dotyczyć pojedynczego użytkownika, który nie może realizować kluczowego zadania. Zwykłe pytanie o konfigurację drukarki nie powinno konkurować z takim zgłoszeniem o uwagę zespołu wsparcia.
Warto wspólnie z dostawcą przełożyć te kategorie na realia konkretnej firmy. Inne systemy są krytyczne dla biura rachunkowego, inne dla firmy produkcyjnej, handlowej czy medycznej.
Co powinna precyzować umowa SLA
Najlepsze SLA jest konkretne, ale nie próbuje udawać encyklopedii. Zamiast wielu ogólnych sformułowań potrzebuje kilku jasno opisanych obszarów odpowiedzialności.
Pierwszym jest zakres obsługi. Dokument powinien wskazywać objęte wsparciem lokalizacje, użytkowników, urządzenia, serwery, usługi chmurowe oraz aplikacje. W firmach rozwijających się ten zakres należy aktualizować. Pięć nowych stanowisk, dodatkowy magazyn lub wdrożenie systemu CRM mogą istotnie zmienić nakład pracy i poziom ryzyka.
Drugim obszarem są godziny dostępności. Standardowe wsparcie w dni robocze może być wystarczające dla biura działającego od 8.00 do 16.00. Jeżeli jednak firma prowadzi sprzedaż internetową, obsługuje produkcję zmianową albo ma pracowników w różnych strefach czasowych, warto ustalić obsługę dyżurową dla najpoważniejszych incydentów. Model 24/7 ma sens tylko wtedy, gdy uzasadnia go charakter działalności – w przeciwnym razie podnosi koszt bez proporcjonalnej korzyści.
Trzecim elementem są kanały zgłoszeń. Telefon, e-mail i system zgłoszeniowy spełniają różne funkcje. Awaria krytyczna nie powinna czekać w zwykłej skrzynce pocztowej, a każde zgłoszenie warto później zarejestrować, aby zachować historię działań. Taka dokumentacja pomaga również wykrywać powtarzające się problemy, na przykład awarie tej samej sieci Wi-Fi czy regularne blokowanie kont przez fałszywe wiadomości.
Czwarty obszar to wyłączenia. SLA powinno uczciwie wskazywać, co nie jest objęte stałą opieką: zakup sprzętu, specjalistyczne prace programistyczne, naprawy pogwarancyjne, odzyskiwanie danych po zdarzeniu wywołanym przez zaniedbanie albo wsparcie systemów, do których dostawca nie otrzymał niezbędnego dostępu. Wyłączenia nie są próbą unikania odpowiedzialności. Pozwalają zaplanować budżet i nie zostawiają miejsca na kosztowne domysły.
Bezpieczeństwo i kopie zapasowe wymagają własnych zapisów
Dla wielu firm najpoważniejszym zdarzeniem nie jest awaria komputera, lecz utrata dostępu do danych albo ich ujawnienie. Dlatego umowa SLA dla obsługi IT powinna odnosić się do cyberbezpieczeństwa, choćby przez opis podstawowych działań: monitorowania alertów, aktualizacji, obsługi podejrzanych zdarzeń, zarządzania kontami i eskalacji incydentów.
Szczególną uwagę warto poświęcić kopiom zapasowym. Sam komunikat „backup wykonany” nie daje jeszcze pewności, że dane można odtworzyć. Umowa powinna określać, co jest kopiowane, jak długo przechowywane są kopie, jak często weryfikowane jest ich odtworzenie oraz kto podejmuje decyzję o przywróceniu danych. W przypadku zaszyfrowania plików przez ransomware liczą się godziny, ale liczy się też wybór właściwego punktu odtworzenia.
Jeżeli dostawca ma dostęp do danych osobowych lub administruje systemami, w których są przetwarzane, relację należy uzupełnić o właściwe ustalenia dotyczące RODO. SLA nie zastępuje wymaganej dokumentacji ochrony danych, lecz powinno być z nią spójne. W razie incydentu firma musi wiedzieć, kto zabezpiecza środowisko, kto zbiera informacje oraz kto po stronie klienta podejmuje decyzje formalne.
Jak sprawdzić, czy deklarowany poziom usług jest realizowany
SLA ma wartość wtedy, gdy można je mierzyć. Nie chodzi o tworzenie rozbudowanego raportowania dla samego raportowania. Wystarczą regularne, zrozumiałe informacje: liczba zgłoszeń, dotrzymanie czasu reakcji, najczęstsze przyczyny problemów, stan aktualizacji, wykonanie kopii zapasowych oraz działania rekomendowane na kolejny okres.
Takie raporty pomagają zarządowi zauważyć różnicę między gaszeniem pożarów a faktyczną prewencją. Jeśli co miesiąc wraca ten sam problem z urządzeniami, licencjami czy dostępami użytkowników, rozwiązaniem nie będzie szybsze zamykanie kolejnych zgłoszeń. Potrzebna jest zmiana procesu, sprzętu albo konfiguracji.
W Ceprobi stała opieka IT jest traktowana właśnie jako praca nad ograniczaniem ryzyka, a nie wyłącznie reagowanie na awarie. To podejście ma znaczenie szczególnie w małych i średnich firmach, gdzie brak jednego systemu lub jednego pracownika z dostępem administracyjnym potrafi zatrzymać istotną część działalności.
Pytania, które warto zadać przed podpisaniem SLA
Przed zawarciem umowy warto ustalić, czy wskazane czasy obowiązują od momentu zgłoszenia, czy od chwili jego zakwalifikowania przez dostawcę. Należy też zapytać, jak wygląda obsługa awarii poza godzinami pracy, jakie zdarzenia mają najwyższy priorytet oraz czy miesięczna opłata obejmuje działania prewencyjne, czy tylko pomoc po wystąpieniu problemu.
Równie istotne jest ustalenie obowiązków klienta. Dostawca nie zabezpieczy skutecznie środowiska, jeśli firma nie zgłasza odejść pracowników, korzysta z nieautoryzowanego oprogramowania albo przekazuje hasła między osobami. SLA powinno wspierać partnerską współpracę, a nie tworzyć wygodne alibi dla którejkolwiek ze stron.
Dobrze skonstruowana umowa nie ma brzmieć efektownie. Ma dawać spokój wtedy, gdy coś przestaje działać: wiadomo, do kogo zadzwonić, co wydarzy się dalej i jak firma odzyska kontrolę. To właśnie ten rodzaj przewidywalności najczęściej okazuje się cenniejszy niż najniższa cena miesięcznej obsługi.