ITIL 4 w praktyce: co to jest, co zmienia ITIL 5 i kiedy framework ma sens dla CTO?

Piątek, 18:40. System płatności w średniej firmie fintech przestaje przyjmować transakcje. Alert trafia do trzech zespołów, każdy zakłada, że problem jest u pozostałych. Klienci dowiadują się o awarii z komunikatu na portalu społecznościowym, dział obsługi klienta — od klientów. Po dwóch godzinach okazuje się, że przyczyną była zmiana konfiguracji wdrożona po południu przez zespół infrastruktury. Nikt jej nie odnotował, bo „to była drobna poprawka”.

W poniedziałek CTO dostaje dwa pytania. Zarząd pyta, dlaczego nikt nie wiedział, kto odpowiada za awarię. Dział zgodności pyta, czy incydent spełniał kryteria poważnego incydentu ICT w rozumieniu rozporządzenia DORA — bo jeśli tak, pierwsze zgłoszenie do nadzorcy powinno było trafić w ciągu 4 godzin od jego sklasyfikowania. Audytor dopisuje trzecie: „Czy stosujecie ITIL?”.

CTO pamięta ITIL z poprzedniej pracy: komitet zmian zbierający się we wtorki, formularz na każdą zmianę, tygodnie czekania na zatwierdzenie drobnej poprawki. Zespół, który teraz prowadzi, wdraża kilkanaście razy dziennie i nie wyobraża sobie powrotu do tego modelu. Pytanie brzmi więc: czy ITIL to lekarstwo na piątkowy chaos, czy powrót biurokracji?

Odpowiedź zależy od tego, który ITIL masz na myśli. Poniżej wyjaśniamy, czym jest ITIL 4, co zmienia wydany w 2026 roku ITIL (Version 5), które praktyki warto wdrożyć najpierw, jak pogodzić framework z DevOps i SRE oraz kiedy ITIL ma sens, a kiedy jest przerostem formy.

Czym jest ITIL i czym ITIL 4 różni się od wcześniejszych wersji?

ITIL to zbiór dobrych praktyk zarządzania usługami IT (IT Service Management, ITSM). Powstał w latach 80. na zlecenie brytyjskiej agencji rządowej CCTA, która chciała uporządkować sposób, w jaki administracja korzysta z informatyki. Pierwsze publikacje ukazały się w 1989 roku i rozrosły się do ok. 30 tomów. Wersja 2 pojawiła się w 2001 roku, wersja 3 — w maju 2007 roku, z aktualizacją w 2011 roku.

ITIL v3 zbudowano wokół cyklu życia usługi: strategia, projektowanie, przejście, eksploatacja i ciągłe doskonalenie, z 26 procesami i funkcjami. To ta wersja ukształtowała skojarzenia wielu CTO — bo wiele organizacji wdrażało ją dosłownie, jako zestaw obowiązkowych procesów, formularzy i komitetów. Szerzej opisaliśmy ten problem w artykule o strategicznym ITSM i budowaniu autorytetu działu IT.

ITIL 4, opublikowany w lutym 2019 roku, był pierwszą dużą zmianą od 2007 roku. Trzy różnice są najważniejsze:

• Praktyki zamiast procesów. ITIL 4 porzuca cykl życia usługi i 26 procesów na rzecz 34 praktyk. Praktyka to zestaw zasobów organizacji — ludzi, informacji, technologii, dostawców — służący określonemu celowi. Nie narzuca kolejności kroków ani struktury organizacyjnej.
• Wartość zamiast zgodności. Punktem wyjścia jest pytanie, jaką wartość usługa tworzy dla klienta, a nie czy proces przebiega zgodnie z opisem.
• Otwartość na Agile, Lean i DevOps. ITIL 4 wprost uwzględnia nowoczesne sposoby pracy, a jeden z modułów zaawansowanych, High Velocity IT, dotyczy organizacji dostarczających zmiany szybko i często.

Właściciel praw do ITIL też się zmienił. W 2013 roku rząd brytyjski i firma Capita powołały spółkę AXELOS, która zarządzała ITIL i PRINCE2. W lipcu 2021 roku AXELOS przejęła firma PeopleCert, obecnie odpowiedzialna za rozwój frameworku i system certyfikacji.

Co zmienia ITIL (Version 5) wydany w 2026 roku i czy ITIL 4 nadal ma sens?

Na początku 2026 roku PeopleCert rozpoczął wprowadzanie ITIL (Version 5). Pierwszy był egzamin Foundation w nowej wersji, udostępniony w lutym 2026 roku. Kolejne moduły zaawansowane pojawiają się etapami w dalszej części roku.

Według PeopleCert nowa wersja odpowiada na trzy zmiany w otoczeniu:

• Organizacje zarządzają produktami cyfrowymi, a nie tylko usługami. ITIL 5 łączy zarządzanie produktami i usługami cyfrowymi w jeden cykl życia — od projektowania, przez budowę i eksploatację, po doskonalenie.
• AI zmienia sposób wykonywania pracy. Nowa wersja jest opisywana jako „AI-native” — zawiera wskazówki dotyczące pracy w środowisku, w którym część zadań wykonują systemy AI, oraz zarządzania ryzykiem związanym z ich użyciem.
• Schemat kwalifikacji był zbyt złożony. ITIL 5 upraszcza ścieżkę certyfikacji: Foundation pozostaje punktem wejścia, a moduły zaawansowane są powiązane z rolami.

Dla CTO najważniejsze jest to, co się nie zmienia. Siedem zasad przewodnich pozostaje takich samych, a struktura 34 praktyk jest zachowana, choć część z nich zgrupowano inaczej — na przykład jako praktyki zarządzania produktami i usługami. PeopleCert deklaruje, że ITIL 5 jest zgodny wstecz: wiedza i certyfikaty ITIL 4 zachowują wartość, a ITIL 4 pozostaje dostępny dla osób kontynuujących ścieżkę certyfikacji.

Czy więc ITIL 4 nadal ma sens w 2026 roku? Tak, z jednym zastrzeżeniem. Praktyki, które wdrożysz według ITIL 4, nie zdezaktualizują się — incydenty, zmiany i problemy obsługuje się w obu wersjach według tych samych zasad. Jeśli natomiast planujesz dopiero certyfikację zespołu, warto sprawdzić, które moduły ITIL 5 są już dostępne w języku i formie, której potrzebujesz. W dalszej części artykułu opisujemy ITIL 4, bo to w nim jest dziś opisana większość wdrożeń, narzędzi i materiałów, i zaznaczamy, gdzie ITIL 5 wprowadza różnice.

Z czego składa się ITIL 4: system wartości usług, łańcuch wartości i cztery wymiary?

ITIL 4 ma dwa główne komponenty: model czterech wymiarów i system wartości usług. Oba brzmią abstrakcyjnie, ale w praktyce działają jak lista kontrolna, która chroni przed najczęstszymi błędami przy zmianach w IT.

Cztery wymiary zarządzania usługami to obszary, które trzeba uwzględnić przy każdej usłudze i każdej zmianie:

1. Organizacje i ludzie — struktura, role, kompetencje, kultura.
2. Informacje i technologia — dane, wiedza, narzędzia i systemy.
3. Partnerzy i dostawcy — relacje z firmami zewnętrznymi, od dostawcy chmury po zespół staff augmentation.
4. Strumienie wartości i procesy — sposób, w jaki praca przepływa przez organizację.

Wartość tego modelu widać na przykładzie z wprowadzenia. Firma fintech miała dobrą technologię (wymiar 2), ale nie miała jasno przypisanych ról przy incydencie (wymiar 1) ani uzgodnionego przepływu informacji o zmianach (wymiar 4). Kupno nowego narzędzia do monitorowania nie rozwiązałoby problemu — co jest jednym z najczęstszych błędów przy porządkowaniu IT.

System wartości usług (SVS) opisuje, jak wszystkie elementy organizacji współpracują przy tworzeniu wartości. Składa się z pięciu części: zasad przewodnich, ładu organizacyjnego (governance), łańcucha wartości usług, praktyk i ciągłego doskonalenia.

Centralnym elementem SVS jest łańcuch wartości usług — sześć działań, z których składa się każda praca IT: planowanie, doskonalenie, angażowanie (kontakt z interesariuszami), projektowanie i przejście, pozyskiwanie lub budowanie oraz dostarczanie i wsparcie. To nie jest sekwencja kroków. Różne scenariusze — obsługa incydentu, wdrożenie nowej funkcji, przyjęcie nowego pracownika — łączą te działania w różnej kolejności, tworząc strumienie wartości.

W praktyce oznacza to, że zamiast pytać „jaki proces mamy dla zmian?”, pytasz „jak wygląda strumień wartości od zgłoszenia potrzeby przez biznes do działającej funkcji na produkcji i gdzie tracimy czas?”. To pytanie znacznie bliższe myśleniu DevOps niż ITIL v3.

Jakie są zasady przewodnie ITIL 4 i jak stosować je na co dzień?

Siedem zasad przewodnich to najbardziej praktyczna część ITIL 4 — i ta, którą ITIL 5 przejął bez zmian. Dają się zastosować niezależnie od tego, czy wdrażasz jakąkolwiek praktykę.

1. Skup się na wartości. Każda aktywność powinna prowadzić do wartości dla klienta lub organizacji. Przykład: raport z SLA, którego nikt nie czyta, nie tworzy wartości — lepiej zastąpić go jednym wskaźnikiem, na który ktoś reaguje.
2. Zacznij tam, gdzie jesteś. Zanim zbudujesz coś nowego, sprawdź, co już działa. Większość firm ma nieformalną obsługę incydentów — kanał na komunikatorze, dyżury. Punktem wyjścia jest jej uporządkowanie, a nie zastąpienie.
3. Postępuj iteracyjnie, z informacją zwrotną. Wdrażaj praktyki małymi krokami i mierz efekt. Nie projektuj całego ITSM przez pół roku przed pierwszym wdrożeniem.
4. Współpracuj i zapewniaj widoczność. Praca, której nie widać, nie może być usprawniona. Wspólna tablica zmian i incydentów często daje więcej niż nowy proces.
5. Myśl i działaj całościowo. Usługa to suma wszystkich czterech wymiarów. Optymalizacja jednego zespołu kosztem innych nie poprawia usługi.
6. Zachowaj prostotę i praktyczność. Jeśli krok procesu nie tworzy wartości, usuń go. To zasada, która najmocniej odcina ITIL 4 od biurokratycznych wdrożeń v3.
7. Optymalizuj i automatyzuj. Najpierw uprość, potem automatyzuj. Automatyzacja złego procesu tylko przyspiesza powstawanie błędów.

Dla CTO najbardziej użyteczne są zasady 2, 6 i 7. Razem tworzą prostą regułę wdrażania: zacznij od tego, co zespół już robi, usuń zbędne kroki i dopiero wtedy automatyzuj. Wiele nieudanych wdrożeń ITIL zrobiło dokładnie odwrotnie — kupiło narzędzie ITSM, skonfigurowało w nim procesy z podręcznika i kazało zespołom się dostosować.

Które z 34 praktyk ITIL 4 naprawdę warto wdrożyć na początek?

ITIL 4 opisuje 34 praktyki w trzech grupach: 14 praktyk zarządzania ogólnego (m.in. zarządzanie strategią, ryzykiem, dostawcami, bezpieczeństwem informacji i ciągłe doskonalenie), 17 praktyk zarządzania usługami (m.in. zarządzanie incydentami, problemami, umożliwianie zmian, service desk, zarządzanie poziomem usług) i 3 praktyki zarządzania technicznego (zarządzanie wdrożeniami, zarządzanie infrastrukturą i platformami oraz wytwarzanie i zarządzanie oprogramowaniem).

Nikt nie wdraża wszystkich 34 jednocześnie. ITIL 4 zresztą tego nie oczekuje. Z naszego doświadczenia w pracy z działami IT wynika, że pięć praktyk rozwiązuje większość problemów widocznych dla zarządu i klientów. Poniżej każda z nich w wersji minimalnej, która działa w zespole kilkudziesięciu inżynierów:

Praktyka	Problem, który rozwiązuje	Wersja minimalna
Zarządzanie incydentami	Nikt nie wie, kto prowadzi awarię	Klasyfikacja ważności (np. 4 poziomy), rola lidera incydentu, jeden kanał komunikacji, szablon komunikatu dla klientów
Umożliwianie zmian (dawniej zarządzanie zmianami)	Zmiany wdrażane bez wiedzy innych	Rejestr zmian zasilany automatycznie z pipeline’u, kategorie: standardowa, normalna, awaryjna; komitet tylko dla zmian wysokiego ryzyka
Zarządzanie problemami	Te same awarie wracają	Przegląd poincydentowy bez szukania winnych dla każdego poważnego incydentu, lista działań naprawczych z właścicielem i terminem
Monitorowanie i zarządzanie zdarzeniami	O awarii informują klienci	Alerty powiązane z usługami, a nie serwerami; progi uzgodnione z właścicielami usług
Zarządzanie poziomem usług	Brak wspólnej definicji „działa”	2–3 wskaźniki na kluczową usługę (dostępność, czas odpowiedzi), uzgodnione z biznesem i widoczne dla wszystkich

Te pięć praktyk tworzy spójny obieg: monitorowanie wykrywa zdarzenie, zarządzanie incydentami przywraca usługę, zarządzanie problemami usuwa przyczynę, umożliwianie zmian bezpiecznie wprowadza poprawkę, a zarządzanie poziomem usług mówi, czy efekt jest wystarczający. Szczegóły pierwszej z nich opisaliśmy w haśle o zarządzaniu incydentami i w artykule o reagowaniu na incydenty w 2026 roku.

Warto zwrócić uwagę na zmianę nazwy: ITIL 4 mówi o umożliwianiu zmian (change enablement), a nie o zarządzaniu nimi. To nie kosmetyka. Celem praktyki jest maksymalizacja liczby udanych zmian, a nie ich kontrolowanie. Więcej o tym w haśle zarządzanie zmianą.

Kolejne praktyki dodaje się, gdy pojawia się konkretna potrzeba. Zarządzanie wiedzą — gdy rośnie liczba zespołów i rotacja. Zarządzanie dostawcami — gdy znacząca część pracy trafia do partnerów zewnętrznych. Zarządzanie aktywami IT — gdy koszty licencji i chmury wymykają się spod kontroli. Ta ostatnia praktyka łączy się bezpośrednio z Software Asset Management, w którym ARDURA Consulting wspiera klientów od lat.

Jak pogodzić ITIL 4 z DevOps, agile i SRE?

Konflikt między ITIL a DevOps był realny w czasach ITIL v3 wdrażanego dosłownie. W ITIL 4 jest w dużej mierze pozorny, bo oba podejścia odpowiadają na inne pytania.

ITIL odpowiada na pytanie „co” — jakie praktyki organizacja musi mieć, żeby usługi działały niezawodnie: obsługę incydentów, zmian, problemów, poziomów usług. DevOps i SRE odpowiadają na pytanie „jak” — jak wykonywać te praktyki szybko, automatycznie i przy małej liczbie przekazań między zespołami.

W praktyce połączenie wygląda tak:

• Umożliwianie zmian przez pipeline. Zmiana, która przechodzi automatyczne testy, skanowanie bezpieczeństwa i jest wdrażana przez powtarzalny pipeline z możliwością szybkiego wycofania, spełnia definicję zmiany standardowej w ITIL 4 — zatwierdzonej z góry, bez komitetu. Rejestr zmian zasila się automatycznie z systemu CI/CD. Komitet zajmuje się tylko zmianami niestandardowymi o wysokim ryzyku.
• Budżet błędów zamiast arbitralnego SLA. Site Reliability Engineering proponuje definiowanie celów niezawodności (SLO) i budżetu błędów. To konkretna implementacja praktyki zarządzania poziomem usług: gdy budżet się wyczerpuje, zespół przesuwa priorytety z nowych funkcji na stabilność.
• Przeglądy poincydentowe bez szukania winnych. To praktyka zarządzania problemami w wersji, którą promuje kultura DevOps — nastawiona na naukę, a nie na karanie.
• Metryki DORA jako miara praktyk. Cztery kluczowe metryki badań DevOps Research and Assessment — częstotliwość wdrożeń, czas realizacji zmian, odsetek nieudanych zmian i czas przywrócenia usługi — mierzą skuteczność dokładnie tych praktyk, które ITIL opisuje. Pisaliśmy o tym w artykule o biznesowej wartości DevOps i metrykach DORA. Uwaga na zbieżność nazw: metryki DORA nie mają nic wspólnego z unijnym rozporządzeniem DORA, o którym piszemy niżej.

Warunkiem działania tego połączenia jest kultura. Praktyki ITIL wdrożone w organizacji, w której zespoły boją się zgłaszać problemy, zamieniają się w teatr zgodności. Rolę lidera w tej zmianie opisaliśmy w artykule o budowaniu kultury DevOps.

Kiedy ITIL ma sens, a kiedy jest przerostem formy?

ITIL nie jest ani obowiązkowy, ani uniwersalny. Opłaca się, gdy koszt chaosu przewyższa koszt porządku. Z naszego doświadczenia wynika kilka sygnałów, że firma przekroczyła ten próg:

• IT obsługuje wielu użytkowników lub klientów zewnętrznych, a przestoje mają mierzalny koszt — utracone transakcje, kary umowne, odpływ klientów.
• Kilka zespołów współdzieli infrastrukturę, a zmiany jednego wpływają na usługi innych.
• Te same awarie powtarzają się, bo nikt nie jest odpowiedzialny za usunięcie przyczyny.
• Znacząca część pracy jest realizowana przez partnerów zewnętrznych i trzeba jasno ustalić, kto odpowiada za co.
• Firma podlega regulacjom wymagającym udokumentowanego zarządzania incydentami, zmianami i ryzykiem ICT.
• Klienci korporacyjni wymagają certyfikacji ISO/IEC 20000-1 lub pytają w ankietach bezpieczeństwa o procesy ITSM.

Z drugiej strony ITIL jest przerostem formy, gdy:

• Zespół produktowy liczy kilkanaście osób i rozwija jeden system — wystarczy dyżur, kanał incydentowy i przeglądy poincydentowe.
• Firma jest we wczesnej fazie, szuka dopasowania produktu do rynku i zmienia kierunek co kwartał.
• Celem wdrożenia jest certyfikat, a nie problem. Wdrożenie ITIL „bo audytor zapyta” kończy się dokumentacją, której nikt nie używa.

Warto pamiętać, że ITIL to nie jedyna opcja. Standard ISO/IEC 20000-1 (wydanie z 2018 roku) określa wymagania dla systemu zarządzania usługami i może być certyfikowany — ITIL jest jedną z dróg do jego spełnienia. SIAM (Service Integration and Management) koncentruje się na koordynacji wielu dostawców. VeriSM proponuje podejście do zarządzania usługami w całej organizacji, nie tylko w IT. ITIL 4 czerpie z nich wszystkich, więc w praktyce często łączy się elementy kilku podejść.

Jak regulacje DORA i NIS2 zmieniają rolę ITIL w 2026 roku?

Przez lata ITIL był wyborem. Dla części firm w Polsce przestaje nim być — nie dlatego, że przepisy wymagają ITIL z nazwy, ale dlatego, że wymagają praktyk, które ITIL opisuje.

Rozporządzenie DORA (Digital Operational Resilience Act) stosuje się od 17 stycznia 2025 roku do podmiotów sektora finansowego: banków, zakładów ubezpieczeń, firm inwestycyjnych, instytucji płatniczych i ich kluczowych dostawców ICT. Wymaga m.in. ram zarządzania ryzykiem ICT, klasyfikacji incydentów i zgłaszania poważnych incydentów w trzech etapach: zgłoszenie wstępne w ciągu 4 godzin od sklasyfikowania incydentu jako poważnego, ale nie później niż 24 godziny od jego wykrycia, raport pośredni w ciągu 72 godzin i raport końcowy w ciągu miesiąca.

Dyrektywa NIS2 została wdrożona w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa, która weszła w życie na początku kwietnia 2026 roku. Obejmuje znacznie szerszy krąg podmiotów niż poprzednie przepisy — od energetyki i transportu po dostawców usług cyfrowych i producentów. Model zgłaszania poważnych incydentów jest trzystopniowy: wczesne ostrzeżenie w ciągu 24 godzin, pełne zgłoszenie w ciągu 72 godzin i sprawozdanie końcowe w ciągu miesiąca. Firmy mają okres przejściowy na dostosowanie się do nowych wymogów.

Żeby dotrzymać terminu 4 godzin, organizacja musi w ciągu kilkudziesięciu minut od wykrycia problemu wiedzieć, kto prowadzi incydent, jak ocenić jego wagę i kto podejmuje decyzję o zgłoszeniu. To dokładnie zakres praktyki zarządzania incydentami. Raport końcowy wymaga analizy przyczyn — to zarządzanie problemami. Wymóg kontroli zmian w systemach ICT — to umożliwianie zmian. Nadzór nad dostawcami ICT — to zarządzanie dostawcami.

Dla CTO w sektorze finansowym lub w podmiocie objętym NIS2 pytanie nie brzmi więc „czy wdrażać ITIL”, tylko „jak szybko udokumentować i przećwiczyć praktyki, które już teraz są obowiązkowe”. ITIL 4 daje do tego gotowy słownik i strukturę, którą rozumieją audytorzy i nadzorcy. Ten artykuł nie jest poradą prawną — zakres obowiązków zależy od kwalifikacji konkretnego podmiotu i warto go potwierdzić z działem zgodności.

Jak wdrożyć ITIL 4 krok po kroku bez biurokracji?

Wdrożenie ITIL nie jest projektem z datą zakończenia. To seria małych usprawnień, z których każde powinno dać efekt widoczny w ciągu kilku tygodni. Poniższa kolejność sprawdza się w organizacjach, które startują od nieformalnej obsługi IT.

Krok 1. Nazwij usługi. Spisz usługi, które IT dostarcza biznesowi i klientom — nie systemy, tylko usługi: „płatności online”, „obsługa zamówień”, „poczta firmowa”. Każdej przypisz właściciela i określ jej krytyczność. Bez tego nie da się ustalić priorytetów incydentów.

Krok 2. Uporządkuj incydenty. Wprowadź klasyfikację ważności, rolę lidera incydentu i jeden kanał komunikacji. Przećwicz scenariusz poważnej awarii z udziałem zarządu i działu komunikacji. Jeśli podlegasz DORA lub NIS2, dołącz do ćwiczenia ścieżkę decyzji o zgłoszeniu.

Krok 3. Uczyń zmiany widocznymi. Rejestr zmian zasilany automatycznie z pipeline’u CI/CD i kalendarz zmian widoczny dla wszystkich zespołów. Zdefiniuj, które zmiany są standardowe (zatwierdzone z góry), a które wymagają przeglądu.

Krok 4. Zamykaj pętlę problemów. Po każdym poważnym incydencie przegląd bez szukania winnych i lista działań z właścicielami. Raz w miesiącu przegląd, które działania zostały wykonane.

Krok 5. Ustal poziomy usług. Dla kluczowych usług 2–3 wskaźniki uzgodnione z biznesem. Mierz je automatycznie i pokazuj publicznie w organizacji.

Krok 6. Wybierz narzędzie. Dopiero teraz — gdy wiesz, jak chcesz pracować. Narzędzie ITSM ma wspierać przyjęty sposób pracy, a nie go definiować.

Krok 7. Doskonal cyklicznie. Co kwartał przegląd: które praktyki działają, gdzie tracimy czas, co uprościć. To praktyka ciągłego doskonalenia, która w ITIL 4 jest częścią systemu wartości usług, a nie osobnym projektem.

Dla zespołu kilkudziesięciu inżynierów kroki 1–5 zajmują zwykle od dwóch do czterech miesięcy przy zaangażowaniu części czasu jednej osoby odpowiedzialnej za koordynację. Kluczowe jest, żeby po każdym kroku zespół widział efekt — mniej chaosu przy awarii, mniej niespodzianek po wdrożeniach.

Jakie błędy najczęściej zamieniają ITIL w biurokrację?

ITIL ma złą reputację wśród inżynierów nie z powodu treści frameworku, ale z powodu sposobu wdrażania. Sześć błędów powtarza się najczęściej:

1. Wdrażanie wszystkich praktyk naraz. Projekt „wdrożenia ITIL” obejmujący kilkanaście praktyk trwa rok, a zespoły widzą tylko nowe formularze. Lepiej wdrożyć jedną praktykę w miesiąc niż dziesięć w rok.
2. Komitet zmian dla wszystkiego. Komitet, który zatwierdza każdą zmianę, spowalnia dostarczanie i nie zmniejsza ryzyka — członkowie nie są w stanie ocenić setek zmian tygodniowo. Zmiany standardowe powinny przechodzić bez komitetu.
3. Narzędzie przed praktyką. Konfiguracja narzędzia ITSM według domyślnych procesów dostawcy zamiast według potrzeb organizacji.
4. Mierzenie aktywności zamiast wyników. Liczba zamkniętych zgłoszeń czy odsetek zgłoszeń zamkniętych w SLA mówi niewiele o tym, czy usługa działa dobrze. Zespół szybko uczy się optymalizować wskaźnik, a nie usługę.
5. ITIL jako projekt działu operacji. Praktyki wdrażane przez zespół operacyjny bez udziału zespołów deweloperskich tworzą mur między „budującymi” a „utrzymującymi” — dokładnie ten, który DevOps miał zburzyć.
6. Certyfikaty zamiast zmiany. Wysłanie całego zespołu na kurs Foundation nie zmienia sposobu pracy, jeśli po kursie nic się nie zmienia w organizacji.

Każdy z tych błędów narusza którąś z zasad przewodnich ITIL 4 — najczęściej „zachowaj prostotę i praktyczność” oraz „skup się na wartości”. To dobry test dla każdej propozycji zmiany: czy tworzy wartość, czy tylko zgodność?

Jakie certyfikaty ITIL wybrać i czy warto certyfikować zespół?

Schemat certyfikacji ITIL 4 ma poziom wejściowy i dwie główne ścieżki zaawansowane:

• ITIL 4 Foundation — podstawowe pojęcia, zasady i praktyki. Punkt wejścia do wszystkich dalszych modułów.
• ITIL 4 Managing Professional (MP) — cztery moduły: Create, Deliver and Support (CDS), Drive Stakeholder Value (DSV), High Velocity IT (HVIT) oraz Direct, Plan and Improve (DPI). Dla osób odpowiedzialnych za działanie usług i zespołów.
• ITIL 4 Strategic Leader (SL) — dwa moduły: Direct, Plan and Improve (DPI) oraz Digital and IT Strategy (DITS). Dla liderów IT odpowiedzialnych za strategię.
• Moduły rozszerzające — m.in. o zrównoważonym rozwoju w IT i zarządzaniu usługami chmurowymi.

W ITIL (Version 5) Foundation pozostaje punktem wejścia, a moduły zaawansowane są pogrupowane według ról i obszarów — m.in. doświadczenia użytkownika, produktu i usługi. PeopleCert deklaruje, że posiadacze certyfikatów ITIL 4 zachowują ich wartość i mają ścieżki przejścia do nowej wersji. Cen egzaminów nie podajemy, bo zależą od akredytowanego ośrodka szkoleniowego, formy (szkolenie z egzaminem lub sam egzamin) i kraju.

Czy warto certyfikować zespół? Nasza rekomendacja jest zróżnicowana:

• Foundation dla liderów zespołów i osób prowadzących incydenty — tak. Wspólny słownik skraca dyskusje i ułatwia rozmowę z audytorami, dostawcami i klientami.
• Foundation dla wszystkich inżynierów — zwykle nie. Lepiej zainwestować w ćwiczenia z obsługi incydentów i przeglądy poincydentowe.
• Moduły zaawansowane (np. HVIT, DPI) — dla osób, które projektują sposób pracy IT, oraz w organizacjach regulowanych, gdzie kompetencje ITSM trzeba wykazać.
• Certyfikat jako wymóg przy wyborze dostawcy — ma sens, gdy partner zewnętrzny przejmuje część praktyk, np. service desk lub utrzymanie. Przy wzmacnianiu zespołu inżynierami DevOps ważniejsze jest praktyczne doświadczenie w obsłudze incydentów niż sam certyfikat.

Jak stosować ITIL 4, gdy część pracy IT wykonują partnerzy zewnętrzni?

Mało który dział IT w 2026 roku działa wyłącznie siłami własnych pracowników. Chmura publiczna, dostawcy SaaS, firmy utrzymujące systemy, zespoły wzmacniane specjalistami zewnętrznymi — każdy z tych partnerów uczestniczy w strumieniach wartości usług. Awaria u dostawcy staje się Twoim incydentem, a zmiana wdrożona przez partnera — Twoją zmianą.

ITIL 4 odpowiada na to na dwóch poziomach. Wymiar partnerów i dostawców przypomina, że każda usługa zależy od relacji zewnętrznych i trzeba je uwzględnić przy jej projektowaniu. Praktyka zarządzania dostawcami opisuje, jak te relacje prowadzić: od wyboru partnera, przez umowę i wspólne wskaźniki, po regularne przeglądy.

W praktyce najważniejsze jest, żeby praktyki ITSM obejmowały partnerów, a nie kończyły się na granicy organizacji:

• Wspólna procedura incydentowa. Dostawca wie, jak zgłosić incydent, kto jest liderem po Twojej stronie i w jakim czasie musi odpowiedzieć. Przy obowiązkach z DORA lub NIS2 ten czas musi być zgodny z Twoimi terminami zgłoszeń do nadzorcy.
• Zmiany partnerów w Twoim rejestrze. Zmiana w systemie utrzymywanym przez dostawcę pojawia się w tym samym kalendarzu co zmiany Twoich zespołów.
• Przeglądy poincydentowe z udziałem dostawcy. Przyczyna leżąca po stronie partnera wymaga działań naprawczych po jego stronie — z właścicielem i terminem.
• Wskaźniki usług, a nie dostępności komponentów. Dostawca, który dotrzymuje SLA dla swojego komponentu przy niedziałającej usłudze końcowej, formalnie wykonał umowę, ale nie dostarczył wartości.

Inaczej wygląda to przy wzmacnianiu zespołu specjalistami zewnętrznymi. W modelu staff augmentation inżynierowie partnera pracują w Twoich zespołach, w Twoich narzędziach i według Twoich praktyk. Dostawca odpowiada za dobór i ciągłość obsady, a nie za usługę. Dlatego przy takim modelu kluczowe jest, żeby nowi członkowie zespołu znali Twoją procedurę incydentową i zasady zmian od pierwszego tygodnia — to element wdrożenia, a nie osobny projekt.

Gdy liczba partnerów rośnie do kilku lub kilkunastu, a usługi końcowe zależą od wielu z nich jednocześnie, warto sięgnąć po podejście SIAM, które opisuje rolę integratora usług koordynującego wielu dostawców. Dla większości firm średniej wielkości wystarcza jednak dobrze prowadzona praktyka zarządzania dostawcami i włączenie ich w obieg incydentów i zmian.

Jak ocenić dojrzałość zarządzania usługami IT w Twojej firmie?

Zamiast pytać „czy mamy ITIL”, lepiej ocenić, na jakim poziomie dojrzałości są kluczowe praktyki. Poniższy model pomaga ustalić punkt wyjścia i następny krok. Poziomy są uproszczone i nie odpowiadają formalnemu modelowi oceny PeopleCert — służą do rozmowy w zespole kierowniczym.

Obszar	1. Reaktywny	2. Powtarzalny	3. Zdefiniowany	4. Mierzony	5. Optymalizowany
Incydenty	O awarii informują klienci	Dyżury i kanał incydentowy	Klasyfikacja ważności, lider incydentu, szablony komunikacji	Czas wykrycia i przywrócenia mierzony dla każdej usługi	Ćwiczenia awarii, automatyczne wykrywanie i częściowe samonaprawianie
Zmiany	Zmiany wdrażane bez śladu	Ręczny rejestr zmian	Kategorie zmian, zmiany standardowe przez pipeline	Odsetek nieudanych zmian i czas realizacji mierzone	Większość zmian standardowa, komitet tylko dla wysokiego ryzyka
Problemy	Te same awarie wracają	Analiza przyczyn po dużych awariach	Przeglądy poincydentowe bez szukania winnych dla każdego poważnego incydentu	Śledzenie wykonania działań naprawczych	Proaktywne wyszukiwanie problemów na podstawie trendów
Poziomy usług	Brak definicji „działa”	Umowne SLA bez pomiaru	Wskaźniki dla kluczowych usług	Pomiar automatyczny, widoczny dla biznesu	SLO i budżety błędów sterujące priorytetami
Regulacje (DORA/NIS2)	Brak świadomości obowiązków	Znane obowiązki, brak procedur	Procedura zgłaszania i klasyfikacji	Ćwiczenia z udziałem zarządu	Zgłoszenia generowane z danych systemu incydentowego
Dostawcy	Brak jasnego podziału odpowiedzialności	Umowy z SLA	Wspólne procedury incydentowe z dostawcami	Przeglądy wyników dostawców	Zintegrowane zarządzanie wieloma dostawcami (SIAM)

Większość firm, z którymi pracujemy, jest na poziomie 2 w większości obszarów. Dla organizacji objętych DORA lub NIS2 realnym minimum jest poziom 3 w incydentach, zmianach i regulacjach.

Najważniejsze wnioski:

1. ITIL 4 to nie ITIL v3. Praktyki zamiast procesów, wartość zamiast zgodności, otwartość na DevOps. Złe skojarzenia z ITIL pochodzą najczęściej z dosłownych wdrożeń wersji 3.
2. ITIL 5 nie unieważnia ITIL 4. Zasady przewodnie się nie zmieniły, praktyki zostały zachowane, a certyfikaty ITIL 4 według PeopleCert zachowują wartość.
3. Zacznij od pięciu praktyk. Incydenty, zmiany, problemy, monitorowanie i poziomy usług rozwiązują większość problemów widocznych dla zarządu i klientów.
4. ITIL mówi „co”, DevOps i SRE — „jak”. Zmiana przez przetestowany pipeline może być zmianą standardową bez komitetu.
5. DORA i NIS2 zmieniają ITIL z wyboru w konieczność dla części firm — nie z nazwy, ale z zakresu wymaganych praktyk.
6. Mierz wyniki, nie aktywność. Czas przywrócenia usługi i odsetek nieudanych zmian mówią więcej niż liczba zamkniętych zgłoszeń.

W ARDURA Consulting od ponad 10 lat wspieramy działy IT klientów w Polsce, Europie, na Bliskim Wschodzie i w USA — wzmacniając zespoły inżynierami DevOps i SRE, budując oprogramowanie z myślą o jego późniejszym utrzymaniu i porządkując zarządzanie aktywami IT. Widzimy, że najlepiej działają wdrożenia ITSM, które zaczynają się od jednego bolesnego problemu, a nie od podręcznika.

Jeśli chcesz ocenić dojrzałość praktyk ITSM w swojej organizacji albo potrzebujesz inżynierów, którzy wniosą doświadczenie w obsłudze incydentów i automatyzacji zmian, porozmawiaj z naszym zespołem.