ITIL dla MŚP: Priorytet 3 - Praktyki zaawansowane (opcjonalne) - ESVS

Spis treści

W poprzednich artykułach omawialiśmy Priorytet 1 (Service Desk, Incydenty, Zmiany, Konfiguracja) – fundamenty kontroli nad IT – oraz Priorytet 2 (Problemy, SLA, Bezpieczeństwo, Ciągłe doskonalenie) – ewolucję do proaktywnego zarządzania.

Przeczytaj o Priorytecie 1 ITILa dla MŚP 

Priorytet 3 to praktyki opcjonalne, których większość organizacji MŚP może nie potrzebować. Wdrażasz je tylko, gdy pojawia się konkretna potrzeba biznesowa, nie dlatego, że „tak powinno być”.

Przeczytaj o Priorytecie 2 ITILa dla MŚP 

Trzy praktyki opcjonalne to: zarządzanie dostawcami, zarządzanie dostępnością, pomiar i raportowanie. Każda odpowiada na specyficzny problem. Jeśli tego problemu nie masz – nie wdrażaj praktyki. Można być dojrzałą organizacją IT bez Priorytetu 3.

Warto nadrobić także ogólne informacje na temat ITILa 

Kiedy w ogóle rozważać Priorytet 3?

Priorytet 3 ma sens tylko wtedy, gdy:

Priorytet 1 jest wdrożony kompletnie i działa – Service Desk funkcjonuje, incydenty są rozwiązywane, zmiany są kontrolowane, wiesz, co masz w infrastrukturze. Masz za sobą minimum 6 miesięcy stabilnej pracy.
Priorytet 2 jest przynajmniej częściowo wdrożony – problemy są analizowane, SLA zostało w większości ustalone, dbasz wstępnie o bezpieczeństwo informacji, comiesięczne retrospektywy się odbywają.
Pojawia się rzeczywista potrzeba biznesowa – nie teoretyczna („może się przyda”), ale konkretna. Szef pyta: „Ile wydajemy na dostawców IT?”, albo „Dlaczego serwer pada co miesiąc?”, albo „Uzasadnij budżet IT liczbami”.

Jeśli nie ma problemu biznesowego który praktyka rozwiązuje – nie wdrażaj. Inwestuj czas w doskonalenie Priorytetu 1 i 2.

Wolisz posłuchać?

<br />

1. Zarządzanie dostawcami

Nie potrzebujesz kontroli nad dostawcami, jeśli wszystko (lub większość) robisz wewnętrznie – własny zespół IT obsługuje całą infrastrukturę, zero outsourcingu oprócz podstawowych usług (łącze internetowe od operatora, telefonia).

Outsourcing jest minimalny i bezproblemowy – korzystacie z dostawcy hostingu, może backup w chmurze, wszystko działa, nikt się nie skarży, rozliczenia są klarowne.

Ale warto rozważyć zarządzanie dostawcami, gdy znaczna część IT jest outsourcowana – helpdesk u zewnętrznego dostawcy, hosting u providera, aplikacje w modelu SaaS od kilku vendorów, serwis sprzętu od kilku firm. Suma wydatków na zewnętrznych dostawców IT przekracza 30–40% budżetu IT. Zastanów się czy:

Mieliście problemy z jakością usług – dostawca nie dotrzymuje SLA, zgłoszenia giną, responsywność jest słaba, a eskalacje są nieskuteczne.
Trudno określić, kto za co odpowiada (lub wyznaczyć jasne granice odpowiedzialności) – jest awaria, ale trudno określić, czy to problem dostawcy A czy B. Potrzebujesz zmian w środowisku, ale nie wiesz, z którym dostawcą rozmawiać. Użytkownik pyta „kiedy to będzie naprawione” i nie masz pojęcia, co odpowiedzieć, bo to zależy od nieprzewidywalnego dostawcy.
W jakimś stopniu występuje vendor lock-in – uzależnienie od jednego dostawcy, którego usługi trudno migrować gdzie indziej. Koszty rosną, jakość spada, ale zmiana dostawcy wydaje się niemożliwa.

Czym jest zarządzanie dostawcami?

Systematyczne zarządzanie relacjami z dostawcami usług IT ma swój określony cel: zagwarantować wartość biznesową z outsourcingu, kontrolować jakość i koszty usług zewnętrznych, wiedzieć, z kim rozmawiać i czego wymagać.

Kluczowe elementy

Katalog dostawców – prosty rejestr (może być arkusz) zawierający: nazwa dostawcy, zakres usług, kluczowe osoby kontaktowe (helpdesk, menedżer, eskalacja), umowa (numer, data wygaśnięcia), SLA (czasy reakcji/rozwiązania, które dostawca zagwarantował), koszty miesięczne/roczne.

Cel: w 30 sekund odpowiedzieć na pytanie „kto nam świadczy hosting?”, „kiedy kończy się umowa z dostawcą backupu?”, „Ile płacimy za helpdesk?”

Monitoring wydajności dostawców – czy dostawca dotrzymuje SLA? Proste metryki: procent zgłoszeń rozwiązanych w SLA, liczba eskalacji (ile razy musieliście eskalować, bo dostawca nie zareagował), zadowolenie użytkowników.

Regularne przeglądy – kwartalne spotkanie wewnętrzne – zespół IT przegląda rejestr dostawców: czy umowy są aktualne, czy SLA jest dotrzymywane, czy koszty mieszczą się w budżecie, czy jakość usług satysfakcjonuje biznes.

Zarządzanie relacjami – cykliczne spotkania z kluczowymi dostawcami, identyfikacja potrzeb i problemów (co można poprawić po obu stronach) oraz przygotowanie planu działań naprawczych, jeśli coś nie działa zgodnie z założeniami.

Praktyczne wdrożenie dla MŚP – poglądowy harmonogram:

Tydzień 1: Stwórz prosty arkusz z listą dostawców. Kolumny: dostawca, usługa, nr umowy, kontakt, umowa do, SLA, koszt miesięczny i roczny. Wypełnij to, co wiesz.
Tydzień 2: Zbierz umowy i SLA w jeden folder (repozytorium na dysku lub fizyczny segregator). Dodaj przypomnienia kalendarzowe 60 dni przed wygaśnięciem każdej umowy.
Kwartał 1: Pierwsze wewnętrzne spotkanie przeglądu dostawców (1 godzina). Dla każdego dostawcy: SLA, koszty, problemy, planowane działania. Zapisz wnioski! Przygotuj podsumowanie – notatkę powiązaną z dostawcą.
Co 3 miesiące: spotkanie z największym/najważniejszym dostawcą. Omówienie statystyk, problemów, planów.
Raz w roku: pełny przegląd wszystkich dostawców. Podejmij decyzję: czy kontynuować współpracę, czy renegocjować warunki, czy może szukać alternatywy?

2. Zarządzanie dostępnością

Nie potrzebujesz zarządzania dostępnością, jeśli przestoje w IT nie powodują przestoju w biznesie. Użytkownicy mogą poczekać kilka godzin na przywrócenie usługi bez poważnych konsekwencji. Praca offline jest możliwa – ludzie mogą wykonywać operacje biznesowe, nawet gdy usługi IT są chwilowo niedostępne.

Natomiast potrzebujesz tej praktyki, gdy organizacja jest uzależniona od IT — bez działających systemów firma stoi. Przykładem może być e-commerce, gdzie każda minuta przestoju to utracone transakcje, lub firma produkcyjna, w której linia produkcyjna sterowana jest przez system IT. Logistyka natomiast może mieć problem z funkcjonowaniem, jeśli wystąpi awaria systemu WMS. Spróbuj ocenić, czy:

Koszty przestoju IT dla biznesu są wysokie – godzina przestoju to dziesiątki tysięcy złotych strat (utracona sprzedaż, przestój produkcji, kary umowne za opóźnienia w realizacji zleceń klientów).

Istnieją istotne wymagania regulacyjne lub biznesowe – klienci/partnerzy wymagają określonej dostępności (99.5%, 99.9%). Istnieją regulacje branżowe, które nakładają określone wymagania odnośnie do ciągłości działania.

Czym jest zarządzanie dostępnością?

Najprościej mówiąc jest to zapewnienie, że usługi IT będą dostępne, w czasie, kiedy biznes ich potrzebuje. Ta praktyka polega na planowaniu i utrzymaniu wymaganej dostępności systemów i usług IT. Celem będzie zatem minimalizacja przestojów planowanych (okien serwisowych) i przestojów nieplanowanych (awarii).

Kluczowe metryki dostępności

Availability (Dostępność) – to procent czasu działającej prawidłowo usług.

Co znaczą procenty dostępności w praktyce:

99% = około 7.3 godziny przestoju miesięcznie
99.5% = około 3.6 godziny przestoju miesięcznie
99.9% = około 43 minuty przestoju miesięcznie
99.99% = około 4.3 minuty przestoju miesięcznie

MTBF (Mean Time Between Failures) – średni czas między awariami. Im wyższy, tym lepiej – oznacza, że system rzadko pada.

MTTR (Mean Time To Repair) – średni czas naprawy. Im niższy, tym lepiej – oznacza, że szybko przywracasz działanie IT po awarii.

Posłuchaj także:

Trzy filary wysokiej dostępności

FILAR 1: Redundancja (nadmiarowość)

Zasilanie – UPS (zasilanie awaryjne na 15-30 minut), agregat prądotwórczy (dla dłuższych przestojów energii), redundantne zasilacze w serwerach (jeden pada, drugi działa).
Sieć – dwa lub więcej łączy internetowych (różni operatorzy, różne technologie), redundantne przełączniki sieciowe, router / firewall w konfiguracji HA (jeden pada, drugi działa).
Storage – RAID (dyski w macierzy w układach nadmiarowych – jeden pada, dane są bezpieczne), alternatywnie replikacja między urządzeniami lub lokalizacjami, backup + disaster recovery.
Serwery – stosuj układy klastrowe (failover automatyczny – serwer pada, VM automatycznie statuuje lub przenosi się na inny serwer), load balancing (automatyczne równoważenie obciążenia między serwerami), itd.

FILAR 2: Monitoring i proaktywne działania

Monitoring 24/7 – dostępność usług (czy serwer odpowiada?), wydajność (CPU, RAM, dyski – czy coś się zapycha?), alerty przy anomaliach (mail/SMS gdy coś przekracza określony próg alarmowy).
Proaktywne działania – regularne łatanie dziur (aktualizacje bezpieczeństwa, zanim się pojawią exploity), wymiana starzejących się komponentów (dysk ma 50 000 godzin pracy, wymień go, zanim padnie), regularne aktualizacje firmware’u.

FILAR 3: Planowanie i testowanie

Planowanie pojemności – przewidywanie przyszłych potrzeb (rośniemy o 20% rocznie, kiedy zabraknie miejsca na storage?), skalowanie przed osiągnięciem limitów (oczywiście łatwiej jest z chmurą i usługami SaaS – dodajesz zasoby, gdy potrzeba).
Disaster Recovery Plan – procedury przywracania IT do działania po poważnej awarii (pożar, ransomware, itd.). Regularne testy DR minimum raz w roku – symulowanie awarii i próba przywracania z pomiarem czasu.
Okna serwisowe – kontrolowane przestoje planuj w najmniej krytycznych godzinach (np. w tygodniu po 16:00 lub w weekend), zadbaj o komunikację z użytkownikami – daj znać z wyprzedzeniem o planowanej niedostępności IT, minimalizuj czas przestoju (zadbaj o przygotowanie, testuj zmiany przed wdrożeniem na produkcji, przygotuj plan rollback i zabezpiecz aktualną kopię bezpieczeństwa danych).

Praktyczne wdrożenie dla MŚP

Krok 1: Analiza krytyczności

Porozmawiaj z biznesem i oceńcie, które systemy są absolutnie kluczowe? Dla każdego systemu określcie: jaki jest akceptowalny czas przestoju (RTO – Recovery Time Objective), ile danych możemy stracić (RPO – Recovery Point Objective), ile kosztuje godzina przestoju?

Przeczytaj także: Skyteczny backup dancyh w firmie

Krok 2: Podejście stopniowe

Zacznij od podstawy – backupu dla wszystkich systemów. Następnie Wdrażaj kolejne rozwiązania podnoszące poziom dostępności (w zależności od priorytetów):

Backup wszystkich krytycznych systemów – podstawa, najtańsze zabezpieczenie
Redundancja dla najbardziej krytycznych – ERP na klastrze, bazy danych z replikacją
Monitoring i alerty – wiesz o problemie zanim użytkownicy zaczną dzwonić
Testy disaster recovery – sprawdzasz czy backup faktycznie działa
Rozbudowa redundancji – kolejne systemy z failover

Krok 3: Koszt vs korzyść

99% dostępności – jest zwykle tanie w implementacji i utrzymaniu (podstawowy backup, restart serwera po awarii, kilka godzin przestoju akceptowalne).
99.5% dostępności – generuje umiarkowany koszt (redundancja krytycznych komponentów, monitoring, testy backup i DR wykonywane regularnie).
99.9% dostępności – to już droższa przygoda (pełna redundancja, układy klastrowe, monitoring 24/7).
99.99% dostępności – to bardzo wysokie i bardzo drogie SLA (pełna redundancja IT, klastry active-active, dwie niezależne lokalizacje, zespół on-call 24/7).

Dla większości MŚP: 99–99,5% dla krytycznych systemów jest wystarczające. To oznacza kilka godzin przestoju rocznie. Jest to akceptowalne podejście, gdy koszty wyższej dostępności przekraczają możliwe koszty przestoju.

3. Pomiar i raportowanie

To zbędna praktyka, jeśli kierownictwo ufa IT i nie wymaga szczegółowych raportów – wszyscy wiedzą co się dzieje, nikt nic nie kwestionuje. Budżet IT jest stabilny, przyjmowany bez dyskusji, a inwestycje zatwierdzane są na słowo.

Pomiary i raporty stają się jednak niezbędne, gdy:

Kierownictwo pyta: „co robi IT?” – biznes nie dostrzega wartości i zwrotu z inwestycji w IT.
Trudno uzasadnić budżet – każda propozycja zakupu/inwestycji spotyka się z pytaniem „po co nam to i dlaczego to takie drogie?”.
Planowane są duże inwestycje – nowa infrastruktura, migracja do chmury, wdrożenie systemu – wówczas potrzebujesz danych, żeby pokazać przyszły zwrot z inwestycji.

Czym jest ta praktyka?

Pomiar i raportowanie, to systematyczne zbieranie i analizowanie danych o usługach IT. Odpowiednio realizowana, umożliwia prezentację wartości IT dla biznesu w języku zrozumiałym dla kierownictwa. Raporty będą stanowić podstawę do podejmowania decyzji i uzasadniania inwestycji.

Możemy wyróżnić dwa poziomy raportowania:

Metryki operacyjne (dla IT) – szczegółowe, techniczne.
Metryki biznesowe (dla kierownictwa) – wartość, koszty, ryzyko.

Jak raportować do kierownictwa?

Oto zasady dla dobrego i wartościowego raportu:

Struktura – zacznij raport od podsumowania – czasami to wystarczy do podjęcia decyzji. Jeśli nie lub są wątpliwości, można przeczytać cały raport.
Długość – 1–2 strony – kierownictwo może nie mieć czasu, żeby analizować dane na 20 stronach.
Wizualizacje – wykresy są lepsze niż tabele, a tabele lepsze niż tekst. Trend na wykresie widać w 5 sekund, nie trzeba czytać i interpretować danych.
Akcent na wartość biznesową – zamiast pisać o „instalacji 50 poprawek”, napisz „zabezpieczyliśmy systemy przed 15 znanymi najgroźniejszymi atakami”. Nie pisz „uptime systemu wyniósł 99.2%”, ale „odnotowano przestój 6 godzin w miesiącu, co przekłada się na utraconą produktywność w koszcie ~20 000 zł”.
Trendy – jak sytuacja zmienia się w czasie? Czy zgłoszeń przybywa czy ubywa? Czy przestoje maleją? Czy koszty rosną szybciej niż organizacja?
Jasne wnioski i rekomendacje – nie tylko dane, ale „co z tego wynika”. 2–3 najważniejsze działania na następny miesiąc/kwartał z uzasadnieniem opartym na danych – możesz umieścić te wnioski w podsumowaniu na początku dokumentu.
Częstotliwość: raport miesięczny lub kwartalny dla bezpośredniego przełożonego IT. Raport roczny dla zarządu – podsumowanie roku, osiągnięcia, wyzwania, plany na kolejny rok.

Podsumowanie

ITIL opisuje 34 praktyki zarządzania usługami IT. To nie oznacza, że musisz wdrożyć wszystkie. ITIL to framework, nie przepis – bierzesz tylko to co ma sens dla Twojej organizacji i odpowiednio dostosowujesz. Nasze zalecenia dla MŚP:

Priorytet 1 (Service Desk, Incydenty, Zmiany, Konfiguracja) – konieczny dla każdej organizacji. Bez tego rodzi się chaos.

Priorytet 2 (Problemy, SLA, Bezpieczeństwo, Ciągłe doskonalenie) – zalecany dla organizacji, które chcą działać proaktywnie i dojrzale.

Priorytet 3 (Dostawcy, Dostępność, Pomiar i raportowanie) – opcjonalny, wdrażany wybiórczo w odpowiedzi na konkretne potrzeby biznesowe:

Zarządzanie dostawcami – tylko jeśli pojawia się znaczący outsourcing IT
Zarządzanie dostępnością – tylko jeśli przestoje IT wpływają na biznes
Pomiar i raportowanie – tylko jeśli trzeba uzasadniać wartość IT dla biznesu

Pamiętaj! Można być dojrzałą, profesjonalną organizacją IT bez wdrażania Priorytetu 3. Jeśli nie masz problemów które te praktyki rozwiązują – nie wdrażaj ich. Lepiej zainwestować czas w doskonalenie tego, co już masz.