Umowa outsourcing IT nie powinna być jedynie załącznikiem do faktury ani krótkim opisem w rodzaju „stała opieka informatyczna”. Dobrze przygotowany dokument określa, kto i za co odpowiada, jakie czasy reakcji obowiązują, jak obsługiwane są awarie oraz co dzieje się z danymi i dostępami po zakończeniu współpracy. W małej lub średniej firmie ma to szczególne znaczenie, ponieważ dostawca zewnętrzny często zastępuje wewnętrzny dział IT. Jeżeli zapisy są nieprecyzyjne, każda poważniejsza awaria może prowadzić do sporu o to, czy dana czynność była objęta usługą, czy wymaga dodatkowego rozliczenia.
W tym poradniku wyjaśniam, co powinna zawierać umowa serwisowa IT, jak czytać zapisy SLA w umowie IT i które postanowienia warto doprecyzować przed podpisaniem dokumentu. Omawiam również praktyczne sytuacje spotykane w firmach: awarię serwera, pracę hybrydową, wdrożenie nowego pracownika, incydent bezpieczeństwa oraz zakończenie współpracy z dostawcą. Celem nie jest stworzenie jednego uniwersalnego wzoru, ale pokazanie, jakie pytania należy zadać i jak przełożyć oczekiwania biznesowe na konkretne zapisy.
Rola umowy outsourcing IT w firmie
Umowa jako opis odpowiedzialności, a nie formalność
Umowa outsourcing IT powinna przede wszystkim rozdzielać odpowiedzialność między klienta a dostawcę. W dokumencie należy opisać, za jakie elementy infrastruktury odpowiada firma zewnętrzna, a które pozostają po stronie klienta. Może chodzić o serwery, komputery użytkowników, sieć lokalną, kopie zapasowe, pocztę, Microsoft 365, systemy branżowe, urządzenia drukujące, telefony IP oraz dostęp zdalny. Samo stwierdzenie „opieka nad infrastrukturą” nie wystarcza, ponieważ każda ze stron może rozumieć je inaczej.
W praktyce spór często pojawia się przy systemach dostarczanych przez zewnętrznych producentów. Firma oczekuje, że administrator naprawi program księgowy, natomiast dostawca IT może odpowiadać wyłącznie za system operacyjny, sieć i dostępność serwera. Umowa powinna wskazywać, czy obsługa obejmuje kontakt z producentem aplikacji, analizę logów, instalowanie aktualizacji, konfigurację integracji oraz udział w testach po zmianach. Jeżeli określony system jest wyłączony z usługi, warto zapisać to wprost razem z informacją, jaki rodzaj pomocy może zostać udzielony dodatkowo.
Dobrym punktem wyjścia jest lista zasobów objętych obsługą. Powinna zawierać przynajmniej lokalizacje, liczbę użytkowników, serwery, urządzenia sieciowe, usługi chmurowe i najważniejsze aplikacje. Warto dodać zasadę aktualizacji tej listy po zakupie sprzętu, przejęciu nowej lokalizacji lub wdrożeniu kolejnej usługi. Przydatna jest także lista elementów sprawdzanych podczas audytu IT, ponieważ audyt przed podpisaniem kontraktu ogranicza ryzyko przejęcia nieudokumentowanego i przestarzałego środowiska.
Umowa ramowa i załączniki operacyjne
Wygodnym rozwiązaniem jest podzielenie dokumentacji na umowę główną oraz załączniki. Umowa główna opisuje zasady współpracy, poufność, płatności, odpowiedzialność i zakończenie kontraktu. Załącznik techniczny może zawierać listę urządzeń i usług, a osobny dokument może opisywać SLA, procedurę zgłoszeń, zasady bezpieczeństwa i plan reakcji na incydenty. Taki układ pozwala aktualizować zakres techniczny bez przepisywania całej umowy, ale trzeba określić, w jaki sposób zmiana załącznika staje się wiążąca.
W małej firmie dokument nie musi mieć kilkudziesięciu stron, jednak powinien być precyzyjny. Krótka umowa może działać dobrze, jeśli zawiera definicje, zakres, czasy reakcji, wyłączenia, zasady eskalacji i odpowiedzialność za dane. Długi dokument nie gwarantuje bezpieczeństwa, jeśli posługuje się ogólnikami. Z perspektywy administratora najważniejsze jest, aby po przeczytaniu umowy można było odpowiedzieć na pytania: co zgłaszamy, komu zgłaszamy, w jakim czasie nastąpi reakcja, kto podejmuje decyzję i jak dokumentujemy wykonanie prac.
Przed podpisaniem warto przeprowadzić spotkanie robocze z osobą odpowiedzialną za IT po stronie klienta. Należy przejść przez typowy tydzień pracy: reset hasła, nowy laptop, problem z Wi-Fi, niedostępność aplikacji, podejrzaną wiadomość, awarię serwera i odejście pracownika. Jeżeli strony nie potrafią jednoznacznie ustalić, jak obsłużone zostanie każde z tych zdarzeń, umowa wymaga dopracowania. Taki warsztat jest bardziej użyteczny niż samo porównywanie ogólnych nazw pakietów usług.
Definicje, które eliminują nieporozumienia
W umowie warto zdefiniować najważniejsze pojęcia. „Czas reakcji” powinien oznaczać moment potwierdzenia przyjęcia zgłoszenia i rozpoczęcia analizy, a nie czas usunięcia problemu. „Czas rozwiązania” albo „czas przywrócenia usługi” wymaga osobnego opisu, ponieważ nie każdą awarię da się usunąć w jednakowym terminie. Należy także zdefiniować godziny świadczenia usługi, dni robocze, awarię krytyczną, incydent bezpieczeństwa, zgłoszenie standardowe i prace planowane.
Przykładowo niedostępność całego systemu sprzedażowego może być incydentem krytycznym, natomiast problem z jednym stanowiskiem powinien mieć niższy priorytet. Nie oznacza to, że użytkownik pojedynczego komputera może czekać bez końca. Umowa powinna wskazywać priorytety, ich kryteria oraz możliwość zmiany priorytetu po analizie technicznej. Bez takich zasad pracownicy często oznaczają każde zgłoszenie jako pilne, a dostawca nie ma obiektywnej metody ustalenia kolejności.
Wskazówka praktyczna jest prosta: każdą definicję testuj na przykładzie. Jeżeli zapis mówi o „niezwłocznej reakcji”, zapytaj, ile dokładnie wynosi ten czas w godzinach i czy dotyczy także weekendu. Jeżeli umowa mówi o „stałym monitoringu”, ustal, czy chodzi o automatyczne alarmy, analizę człowieka, monitoring dostępności, kontrolę miejsca na dysku czy również przegląd bezpieczeństwa. Precyzja na etapie kontraktu jest tańsza niż negocjowanie odpowiedzialności podczas awarii.
Zakres obsługi informatycznej
Co powinno znaleźć się w zakresie podstawowym
Zakres obsługi informatycznej powinien odpowiadać rzeczywistym potrzebom firmy, a nie katalogowi przypadkowych czynności. Najczęściej obejmuje przyjmowanie zgłoszeń, zdalną pomoc użytkownikom, administrację stacjami roboczymi, serwerami, siecią, kontami i usługami chmurowymi. Jeżeli dostawca wykonuje monitoring, umowa powinna opisać monitorowane elementy oraz sposób przekazywania alarmów. Warto również wskazać, czy w ramach stałej obsługi realizowane są przeglądy okresowe, rekomendacje modernizacyjne i raportowanie stanu infrastruktury.
Zakres powinien uwzględniać cykl życia użytkownika. Onboarding może obejmować utworzenie konta, nadanie uprawnień, przygotowanie komputera, konfigurację MFA i przekazanie zasad bezpieczeństwa. Offboarding powinien określać blokadę kont, odebranie sprzętu, przekazanie danych, archiwizację skrzynki oraz zmianę haseł do współdzielonych usług. Pomocny jest opis zadań przy onboardingu pracownika od strony IT, ponieważ pokazuje, jak wiele czynności może kryć się za pozornie prostym „przygotowaniem stanowiska”.
Jeżeli firma pracuje hybrydowo, zakres powinien obejmować również urządzenia poza biurem. Trzeba ustalić, czy wsparcie dotyczy domowego połączenia internetowego pracownika, konfiguracji VPN, drukarki używanej w domu, prywatnego routera lub telefonu. Dostawca może odpowiadać za firmowy laptop i aplikacje, ale nie za jakość domowego Wi-Fi. Taki podział należy zapisać, aby użytkownik wiedział, gdzie zgłosić problem i jakie działania są możliwe po stronie serwisu.
Usługi dodatkowe i prace projektowe
Umowa powinna rozróżniać bieżącą obsługę od prac projektowych. Migracja poczty, wymiana serwera, przeprowadzka biura, wdrożenie VLAN-ów, instalacja nowego systemu ERP i konfiguracja centralnego zarządzania laptopami zwykle wymagają osobnego planu, harmonogramu i akceptacji. Jeżeli wszystko zostanie wrzucone do jednej kategorii „wsparcie IT”, po kilku miesiącach może pojawić się spór o to, czy duży projekt mieści się w abonamencie.
Warto opisać proces zamawiania prac dodatkowych. Powinien on wskazywać, kto po stronie klienta może zlecić projekt, jak przedstawiany jest zakres, jak zatwierdzane są założenia oraz jak dokumentuje się odbiór. Dobrą praktyką jest przygotowanie krótkiego opisu zawierającego cel, zakres, zależności, ryzyka, termin i kryteria zakończenia. Nie należy zaczynać znaczącej zmiany tylko na podstawie rozmowy telefonicznej, jeśli może ona wpłynąć na dostępność systemu lub bezpieczeństwo danych.
Przykład z praktyki: firma przenosi dokumenty z lokalnego serwera do Microsoft 365. Samo utworzenie bibliotek SharePoint nie oznacza zakończenia projektu. Trzeba zaplanować uprawnienia, strukturę folderów, synchronizację, migrację starych danych, szkolenie oraz wyłączenie poprzedniego dostępu. W umowie należy wskazać, czy dostawca odpowiada za całość migracji, czy tylko za konfigurację techniczną. Przydatne może być wcześniejsze przeanalizowanie różnic opisanych w artykule SharePoint czy OneDrive w firmie.
Wyłączenia i granice usługi
Wyłączenia z zakresu nie są problemem, jeśli są jasno opisane. Mogą dotyczyć sprzętu prywatnego, nielegalnego oprogramowania, systemów bez wsparcia producenta, urządzeń kupionych bez konsultacji, awarii wynikających z naruszenia procedur lub aplikacji, do których dostawca nie ma dostępu administracyjnego. Należy jednak wskazać, czy wyłączenie oznacza całkowity brak pomocy, czy tylko rozliczenie dodatkowych prac. Pracownik klienta powinien wiedzieć, czego może oczekiwać w sytuacji awaryjnej.
Trzeba także zapisać zasady dostępu do środowiska. Dostawca nie powinien ponosić odpowiedzialności za system, do którego nie otrzymał wymaganych uprawnień, dokumentacji lub możliwości zdalnej administracji. Z drugiej strony klient nie powinien udostępniać nieograniczonego dostępu bez kontroli. Umowa może wymagać kont imiennych, MFA, rejestrowania działań i okresowego przeglądu uprawnień. Dzięki temu granica między wygodą administracji a ryzykiem nadmiernych uprawnień jest jasno ustalona.
Wskazówka dla właściciela firmy: poproś dostawcę o pokazanie przykładowego zgłoszenia, które zostanie przyjęte w ramach obsługi, oraz takiego, które będzie wyceniane osobno. Zapytaj też, kto kupuje licencje, kto odpowiada za gwarancję sprzętu i kto kontaktuje się z producentem. Takie pytania ujawniają różnice między ofertami, których nie widać w samym opisie abonamentu. Dobrze opisany zakres ułatwia również zmianę opiekuna, ponieważ nowy administrator może szybko ustalić, jakie zadania powinien wykonywać.
SLA, zgłoszenia i odpowiedzialność
Jak zapisać SLA w umowie IT
SLA, czyli Service Level Agreement, to uzgodniony poziom świadczenia usługi. SLA w umowie IT powinno określać między innymi czas reakcji, godziny obsługi, priorytety, kanały kontaktu, sposób eskalacji i ewentualny czas przywrócenia działania. Najważniejsze jest odróżnienie reakcji od rozwiązania. Dostawca może potwierdzić zgłoszenie w krótkim czasie, ale usunięcie awarii zależy od dostępu do części, producenta oprogramowania, dostawcy internetu lub odtworzenia danych.
Priorytet powinien wynikać ze skutku biznesowego. Awaria systemu obsługującego całą sprzedaż, ransomware lub niedostępność centralnego uwierzytelniania mają inny ciężar niż problem z pojedynczą drukarką. Warto opisać kilka poziomów i przypisać im konkretne czasy. Trzeba też ustalić, kto nadaje priorytet i kto może go zmienić. Jeżeli priorytet wynika wyłącznie z deklaracji osoby zgłaszającej, wszystkie sprawy szybko stają się krytyczne.
W umowie należy zdefiniować, kiedy zegar SLA jest zatrzymywany. Może to nastąpić, gdy dostawca czeka na dostęp klienta, akceptację zmiany, odpowiedź użytkownika, dostawę sprzętu lub działanie producenta. Nie powinno to jednak służyć do ukrywania opóźnień. Każde wstrzymanie powinno być opisane w systemie zgłoszeń, z podaniem powodu i osoby odpowiedzialnej za kolejny krok. Więcej o pomiarze jakości obsługi opisuje materiał dotyczący KPI i SLA w helpdesku IT.
System zgłoszeń i komunikacja
Umowa serwisowa IT powinna wskazywać podstawowy kanał przyjmowania zgłoszeń. Najlepiej, gdy jest nim portal lub dedykowany adres poczty, ponieważ pozwala to zachować historię, priorytet, osobę zgłaszającą i czas obsługi. Telefon jest potrzebny przy awarii krytycznej, ale ustalenia telefoniczne powinny być później zapisane w systemie. Komunikatory mogą wspierać szybką wymianę informacji, lecz nie powinny być jedynym miejscem dokumentowania zgłoszeń.
Warto określić, kto może zgłaszać awarie i kto zatwierdza prace wpływające na całą organizację. W większej firmie można wyznaczyć lokalnych koordynatorów, którzy filtrują proste pytania i zbierają informacje. W małej firmie zgłoszenia mogą pochodzić bezpośrednio od pracowników, ale nadal potrzebne są zasady dotyczące haseł, danych osobowych i kontaktu poza godzinami pracy. Instrukcja zgłaszania powinna być krótka: opis problemu, moment wystąpienia, zakres wpływu, komunikat błędu i wykonane działania.
Przykładowo zgłoszenie „nie działa internet” jest zbyt ogólne, aby szybko ustalić przyczynę. Lepszy opis zawiera informację, czy problem dotyczy całego biura, jednej sieci Wi-Fi, wszystkich usług czy tylko jednej strony. Jeżeli firma ma powtarzające się problemy z wydajnością, umowa może przewidywać analizę trendów i raport miesięczny. Warto także ustalić, czy zgłoszenia użytkowników są mierzone od momentu wysłania wiadomości, czy od poprawnego zarejestrowania sprawy przez system.
Odpowiedzialność, błędy i raportowanie
Postanowienia o odpowiedzialności powinny być proporcjonalne do wpływu usługi na biznes. Dostawca może odpowiadać za należyte wykonanie uzgodnionych czynności, ale nie powinien gwarantować absolutnego braku awarii, jeżeli zależy ona od operatora telekomunikacyjnego, producenta systemu lub decyzji klienta. Jednocześnie ogólne wyłączenie odpowiedzialności za wszystko jest dla firmy niebezpieczne. Warto rozróżnić szkody wynikające z umyślnego działania, rażącego zaniedbania, naruszenia poufności i zwykłej pomyłki operacyjnej.
Umowa może przewidywać mechanizm rekompensaty za niedotrzymanie SLA, ale samą karę finansową należy traktować jako element dodatkowy. Najważniejsze jest ustalenie procesu naprawczego: analiza przyczyny, plan działań, osoba odpowiedzialna i termin weryfikacji. Jeżeli dostawca wielokrotnie przekracza czas reakcji, klient powinien mieć prawo do eskalacji do kierownika usługi, przeglądu współpracy i rozwiązania umowy na określonych zasadach. Warto również zapisać, jak raportowane są incydenty oraz jakie dane raport powinien zawierać.
Praktyczna rekomendacja jest taka, aby co najmniej raz na kwartał analizować raport obsługi. Należy sprawdzić liczbę zgłoszeń, powtarzające się przyczyny, średni czas reakcji, awarie krytyczne, działania zapobiegawcze i zaległe rekomendacje. Sam fakt zamknięcia zgłoszenia nie świadczy o jakości usługi, jeśli problem wraca co tydzień. Dobrze działająca umowa pozwala przejść od gaszenia awarii do planowania zmian, aktualizacji i inwestycji w infrastrukturę.
Bezpieczeństwo, dane i ciągłość działania
Dostępy administracyjne i poufność
Umowa outsourcing IT musi regulować dostęp dostawcy do systemów i danych. Należy opisać, jakie konta są używane, kto je zatwierdza, jak chronione są dane uwierzytelniające i w jaki sposób rejestrowane są działania administracyjne. Dostępy powinny być imienne, ograniczone do niezbędnego zakresu i zabezpieczone uwierzytelnianiem wieloskładnikowym, jeśli technologia na to pozwala. Wspólne konto administratora utrudnia ustalenie, kto wykonał zmianę i zwiększa ryzyko po odejściu pracownika dostawcy.
Klauzula poufności powinna obejmować dokumentację, dane pracowników, dane klientów, konfiguracje, hasła, informacje handlowe i kopie zapasowe. Trzeba określić, czy dostawca może korzystać z podwykonawców, gdzie przechowywane są dane oraz kto ma do nich dostęp. Jeżeli administracja odbywa się zdalnie, warto ustalić wymagania dotyczące szyfrowania połączeń, stacji administratorów i rejestrowania sesji. Umowa nie zastąpi polityki bezpieczeństwa, ale powinna wymagać przestrzegania uzgodnionych zasad.
W przypadku danych osobowych należy przeanalizować role stron i potrzebę zawarcia umowy powierzenia przetwarzania danych. Nie każdy dostawca IT przetwarza dane w taki sam sposób. Administrator może mieć dostęp do skrzynek, folderów i profili użytkowników tylko przy okazji wykonywania usługi, ale taki dostęp nadal trzeba odpowiednio uregulować. Warto oprzeć wymagania na wytycznych Urzędu Ochrony Danych Osobowych oraz przeprowadzić ocenę, jakie dane faktycznie są dostępne dla firmy serwisowej.
Backup, odtwarzanie i incydenty
Jeżeli dostawca odpowiada za backup, umowa musi wskazywać chronione systemy, częstotliwość kopii, retencję, lokalizację, szyfrowanie i sposób monitorowania. Sam komunikat „backup jest wykonywany” nie mówi, czy kopia obejmuje bazy danych, konfiguracje urządzeń, pocztę, dokumenty i stacje robocze. Należy także wskazać, kto sprawdza wynik zadania oraz jak długo przechowywane są logi. W praktyce kopia, której nigdy nie testowano, nie powinna być traktowana jako pewny plan odzyskania danych.
W umowie warto zapisać obowiązek okresowych testów odtwarzania. Test powinien odpowiadać na pytanie, czy da się przywrócić konkretną usługę, w jakim czasie i z jaką utratą danych. Pomocne jest rozdzielenie celu RPO, czyli dopuszczalnej utraty danych, od celu RTO, czyli oczekiwanego czasu przywrócenia działania. Zasada 3-2-1 w backupie firmowym jest dobrym punktem odniesienia, ale umowa powinna przełożyć ją na konkretne urządzenia i procedury klienta.
Procedura incydentu bezpieczeństwa powinna określać, kiedy dostawca informuje klienta, kto podejmuje decyzję o odłączeniu urządzenia, jak zabezpieczane są logi i jak prowadzona jest komunikacja. W przypadku ransomware liczy się szybkość, ale pochopne wyłączenie systemów może utrudnić analizę. Umowa powinna wskazywać całodobowy kontakt dla incydentów krytycznych albo jasno powiedzieć, że reakcja poza godzinami pracy wymaga osobnego trybu. Ważne jest też ustalenie, kto kontaktuje się z ubezpieczycielem, prawnikiem, organem nadzorczym lub producentem.
Ciągłość działania i zależności
Outsourcing IT powinien wspierać plan ciągłości działania, ale nie może go zastąpić. Umowa powinna wskazywać najważniejsze procesy biznesowe, minimalne zasoby potrzebne do pracy i kolejność odtwarzania usług. Dla firmy handlowej priorytetem może być system sprzedaży i dostęp do magazynu, dla biura projektowego pliki oraz poczta, a dla zakładu produkcyjnego system sterowania i komunikacja z urządzeniami. Takie różnice wpływają na backup, sprzęt zastępczy, procedury awaryjne i wymagane czasy przywrócenia.
Trzeba również uwzględnić zależności od innych podmiotów. Dostawca IT może zarządzać routerem, ale nie kontroluje awarii operatora. Może administrować Microsoft 365, lecz nie jest właścicielem platformy. Może przygotować komputer zastępczy, ale nie zagwarantuje natychmiastowej dostępności konkretnego modelu. Umowa powinna zawierać procedurę eskalacji do tych podmiotów, wymagane dane kontaktowe oraz zasady informowania klienta o stanie sprawy.
Wskazówka praktyczna: raz w roku wykonaj ćwiczenie odtworzeniowe na podstawie scenariusza. Przykładem może być utrata serwera plików, kompromitacja konta administratora albo zalanie pomieszczenia z urządzeniami. Sprawdź, czy dostępne są kopie, hasła awaryjne, dokumentacja, kontakty i sprzęt zastępczy. Wynik ćwiczenia powinien trafić do protokołu oraz stać się podstawą aktualizacji umowy, procedur i zakresu usług.
Koszty, zmiany i zakończenie współpracy
Model rozliczeń i przejrzystość kosztów
Umowa powinna wyjaśniać, co jest objęte stałą opłatą, a co rozliczane oddzielnie. Nie chodzi o wpisanie konkretnych stawek do poradnika, lecz o zrozumienie mechanizmu. Koszt outsourcingu zależy między innymi od liczby użytkowników, liczby lokalizacji, stanu infrastruktury, wymaganych godzin wsparcia, zakresu monitoringu, poziomu SLA, liczby serwerów i systemów oraz odpowiedzialności za backup. Znaczenie ma także to, czy dostawca ma świadczyć pomoc na miejscu, czy głównie zdalnie.
W umowie trzeba opisać rozliczanie prac dodatkowych, dojazdów, zakupów, licencji, części zamiennych, usług chmurowych i interwencji poza standardowymi godzinami. Jeżeli dostawca kupuje sprzęt w imieniu klienta, warto określić zasady akceptacji oferty, gwarancji i marży. Przydatna jest także informacja, czy niewykorzystane godziny przechodzą na kolejny okres i czy prace projektowe są planowane z wyprzedzeniem. Brak tych zapisów utrudnia kontrolę budżetu i może powodować zaskoczenia przy fakturze.
Dobry model rozliczeń powinien być zrozumiały dla osoby zarządzającej firmą, która nie jest administratorem. Właściciel powinien wiedzieć, jakie ryzyko i jaki zakres pracy pokrywa stała opłata, a które decyzje wymagają dodatkowej zgody. Warto oczekiwać cyklicznego podsumowania wykonanych działań, zaplanowanych zmian i rekomendowanych inwestycji. Takie informacje pozwalają traktować IT jako zarządzany obszar działalności, a nie wyłącznie koszt reagowania na awarie.
Zmiany w środowisku i przegląd umowy
Infrastruktura firmy zmienia się szybciej niż wiele umów. Dochodzą nowe konta, laptopy, lokalizacje, aplikacje SaaS i wymagania bezpieczeństwa. Dlatego umowa powinna opisywać proces zmiany zakresu. Wystarczy ustalić, że aktualizacja listy zasobów, dodanie lokalizacji lub zmiana poziomu SLA wymaga potwierdzenia przez wskazane osoby i jest odnotowywana w aneksie albo zatwierdzonym załączniku. Nie powinno być sytuacji, w której dostawca dowiaduje się o nowym serwerze dopiero po awarii.
Przegląd umowy warto przeprowadzać po większym projekcie, zmianie modelu pracy, przejęciu innej firmy, wdrożeniu nowego systemu lub incydencie bezpieczeństwa. Należy wtedy sprawdzić, czy nadal aktualne są kontakty, zakres, priorytety, uprawnienia, lokalizacje backupu i procedura eskalacji. Mała firma może robić taki przegląd raz w roku, natomiast organizacja szybko rosnąca powinna reagować częściej. Dokument nie może pozostawać niezmienny, gdy środowisko techniczne ewoluuje.
Przykład: firma zwiększa liczbę pracowników z kilkunastu do kilkudziesięciu i wprowadza pracę zdalną. Dotychczasowa umowa obejmowała lokalną sieć i jeden serwer, ale nie mówiła o VPN, zarządzaniu laptopami, MFA, urządzeniach prywatnych i wsparciu poza biurem. Formalnie dostawca może nadal realizować dawny zakres, choć ryzyko biznesowe jest już zupełnie inne. Aktualizacja kontraktu powinna poprzedzać zmianę organizacyjną, a nie następować dopiero po pierwszym incydencie.
Wypowiedzenie, przekazanie danych i exit plan
Jednym z najczęściej pomijanych elementów jest plan zakończenia współpracy. Umowa powinna określać okres wypowiedzenia, formę wypowiedzenia, obowiązki stron w okresie przejściowym oraz sposób przekazania dokumentacji. Exit plan powinien obejmować listę urządzeń, konfiguracje, schematy sieci, konta, licencje, kopie zapasowe, umowy z operatorami, historię zgłoszeń i informacje o otwartych problemach. Bez tego zmiana dostawcy może trwać długo i powodować przerwy w pracy.
Należy zapisać, w jakim terminie zwracane są dane klienta i w jakim formacie. Dotyczy to również danych przechowywanych w systemie helpdesk, dokumentacji haseł awaryjnych oraz kopii zapasowych. Po potwierdzeniu migracji dostawca powinien usunąć swoje kopie danych, konta i dostępy zgodnie z uzgodnioną procedurą. Jeżeli korzystał z podwykonawców lub zewnętrznego hostingu, klient powinien otrzymać informację o zamknięciu tych dostępów.
Praktyczna wskazówka: nie czekaj z przygotowaniem dokumentacji do dnia wypowiedzenia. Aktualny opis infrastruktury, lista administratorów i procedura odzyskania dostępu powinny istnieć przez cały okres współpracy. W Serwis24.org zakres obsługi informatycznej może obejmować między innymi administrację infrastrukturą, wsparcie użytkowników i działania związane z bezpieczeństwem; przy wyborze dostawcy warto jednak zawsze ustalić, które elementy są objęte konkretną umową i jak wygląda przekazanie środowiska. To samo dotyczy usług lokalnych, takich jak obsługa firm w Kielcach, Radomiu, Starachowicach czy Skarżysku-Kamiennej.
FAQ
Co powinna zawierać umowa outsourcing IT?
Umowa outsourcing IT powinna zawierać dane stron, definicje, zakres obsługi, listę objętych systemów, zasady zgłaszania problemów, SLA, godziny świadczenia usług, zasady eskalacji, odpowiedzialność, poufność, ochronę danych, bezpieczeństwo dostępów, backup, raportowanie, rozliczenia, zmiany zakresu i zakończenie współpracy. Warto dodać załącznik techniczny z listą urządzeń, użytkowników i lokalizacji. Największą wartość ma precyzja. Zapis „opieka nad serwerem” powinien zostać rozwinięty o monitoring, aktualizacje, backup, reakcję na alarmy, dokumentację i zakres odpowiedzialności za aplikacje działające na serwerze.
Czym różni się czas reakcji od czasu usunięcia awarii?
Czas reakcji oznacza okres od prawidłowego zgłoszenia do potwierdzenia sprawy i rozpoczęcia analizy przez dostawcę. Czas usunięcia awarii albo przywrócenia usługi określa, kiedy problem ma zostać rozwiązany lub kiedy klient otrzyma działanie zastępcze. Te wartości mogą być różne, ponieważ usunięcie awarii zależy od przyczyny, części zamiennych, producentów i dostępu do danych. Umowa powinna wyraźnie rozdzielić oba pojęcia oraz wskazać, kiedy SLA jest wstrzymywane, na przykład w oczekiwaniu na decyzję klienta lub działanie operatora.
Czy SLA powinno obowiązywać przez całą dobę?
Całodobowe SLA jest potrzebne tylko wtedy, gdy działalność firmy wymaga reakcji poza standardowymi godzinami pracy. Dla biura pracującego od poniedziałku do piątku wystarczający może być tryb dzienny z osobną procedurą awarii krytycznych. Jeżeli firma prowadzi sklep internetowy, produkcję albo obsługuje klientów przez całą dobę, należy rozważyć dyżur, monitoring i eskalację 24/7. W umowie trzeba wskazać, które zdarzenia są obsługiwane poza godzinami, jak nawiązać kontakt i czy reakcja obejmuje tylko przyjęcie zgłoszenia, czy także realne działania techniczne.
Czy dostawca IT powinien odpowiadać za backup?
Dostawca może odpowiadać za wykonanie, monitoring i testowanie backupu, ale umowa musi jasno wskazywać zakres tej odpowiedzialności. Należy określić chronione dane, częstotliwość kopii, retencję, lokalizację, szyfrowanie, ochronę przed usunięciem i procedurę odtwarzania. Klient powinien wiedzieć, jakie dane nie są objęte kopią oraz jaki jest oczekiwany czas przywrócenia. Warto też zapisać obowiązek raportowania błędów i okresowych testów. Backup bez weryfikacji odtworzenia nie daje pewności, że firma wróci do pracy po awarii.
Jak zabezpieczyć się przed uzależnieniem od dostawcy?
Należy wymagać aktualnej dokumentacji, imiennych kont, dostępu do danych klienta, opisanej procedury przekazania środowiska i jasnych zasad zakończenia współpracy. Dostawca nie powinien być jedynym posiadaczem haseł do domeny, backupu, usług chmurowych ani urządzeń sieciowych. Konta powinny należeć do firmy, a dostawca powinien otrzymywać uprawnienia potrzebne do pracy. Warto regularnie sprawdzać, czy dokumentacja jest aktualna i czy inna osoba mogłaby przejąć podstawową administrację w sytuacji awaryjnej.
Czy mała firma potrzebuje osobnej umowy SLA?
Mała firma również potrzebuje zapisów SLA, ale ich forma może być prostsza. Nie zawsze konieczny jest rozbudowany dokument z wieloma poziomami usług. Wystarczy jasno określić godziny obsługi, sposób zgłaszania, priorytety, czas reakcji dla awarii krytycznej i standardowych spraw oraz procedurę kontaktu poza godzinami pracy. Ważne jest dopasowanie SLA do realnego ryzyka. Jeżeli firma nie może działać bez systemu sprzedaży, ten system powinien mieć wyższy priorytet niż problem z pojedynczym stanowiskiem, niezależnie od liczby pracowników.
Podsumowanie
Dobra umowa outsourcing IT jest narzędziem zarządzania ryzykiem, a nie wyłącznie dokumentem handlowym. Powinna odpowiadać na praktyczne pytania: jakie systemy są objęte obsługą, kto może zgłaszać problemy, jak szybko nastąpi reakcja, co dzieje się podczas awarii, kto odpowiada za backup i jak przekazywane są dane po zakończeniu współpracy. Największym błędem jest pozostawienie tych kwestii w sferze ustnych ustaleń. Pamięć uczestników spotkania nie zastąpi dokumentacji, zwłaszcza gdy po kilku miesiącach zmienią się pracownicy, sprzęt i zakres usług.
Przed podpisaniem umowy warto przygotować listę zasobów, scenariusze typowych awarii i opis procesów biznesowych, które muszą działać bez przerwy. Następnie należy przełożyć je na zakres usług, priorytety SLA, procedury zgłoszeń i wymagania bezpieczeństwa. Trzeba również oddzielić obsługę bieżącą od projektów, jasno opisać dodatkowe prace i ustalić zasady aktualizacji zakresu. W małej firmie takie przygotowanie nie musi wymagać wielomiesięcznego projektu, ale powinno obejmować rozmowę techniczną z osobą, która zna środowisko i realne problemy użytkowników.
Na końcu należy zweryfikować plan zakończenia współpracy. Firma powinna zachować kontrolę nad własnymi kontami, danymi, licencjami i dokumentacją, niezależnie od tego, czy korzysta z jednego administratora, czy z zewnętrznego zespołu. Dostawca powinien być partnerem, który pomaga utrzymać infrastrukturę i ograniczać ryzyko, ale umowa musi tworzyć przejrzyste zasady działania po obu stronach. Jeżeli zapisy są konkretne, łatwiej mierzyć jakość usługi, planować budżet i podejmować decyzje o rozwoju IT.
Jak wdrożyć system zgłoszeń IT w małej firmie?
[…] wymagają akceptacji klienta. Przydatne wskazówki dotyczące zapisów można znaleźć w materiale umowa outsourcing IT — najważniejsze zapisy. Serwis24.org oferuje obsługę informatyczną firm, w której uporządkowany kanał zgłoszeń […]