Siedzisz przed ekranem, wpisujesz „ITSM” w Google i dostajesz lawiny skrótów, które brzmią jakby R2-D2 miał firmę konsultingową. Incident management, problem management, ITIL, CMDB… już wiesz, że za chwilę ktoś napisze, że bez tej wiedzy Twój dział IT będzie gorzej zarządzany niż stołówka szkolna. Tylko co z tego wszystkiego faktycznie znaczy i dlaczego menedżer IT, który używa tych pojęć na co dzień, wciąż często ma problem z wyjaśnieniem ich swojej mamie?
Zarządzanie usługami IT (ITSM) to w gruncie rzeczy całość tego, co robisz, żeby dział IT działał – od momentu, gdy ktoś zgłasza, że nie działa mu drukarka, aż po zmianę infrastruktury, która ma zapewnić, że za trzy lata będziecie mogli obsłużyć dwukrotnie więcej użytkowników. To nie jest jedna aplikacja. To nie jest Jira, ServiceNow ani żaden inny system z ładnymi dashboardami. To sposób myślenia o tym, co robisz. A że w tej przestrzeni powstało mnóstwo frameworków i standardów, które mają pomóc w tym myśleniu – no cóż, to już inna historia.
Kiedy ktoś woła „awaria”, a ty się zastanawiasz, czy to incident, czy może już problem
W latach 80. w Wielkiej Brytanii rząd uznał, że usługi IT w administracji publicznej działają jakoś tak sobie i trzeba by to uporządkować. Powstało wtedy ITIL – Information Technology Infrastructure Library. Nie był to system, tylko zbiór najlepszych praktyk, które ktoś spisał, zebrawszy doświadczenia z organizacji, które radziły sobie lepiej niż inne. W 2001 wydano drugą wersję, w 2007 trzecią, a w 2019 czwartą – każda próbowała odpowiedzieć na pytanie: jak zarządzać IT tak, żeby nie było koszmaru, gdy coś się sypie?
Podstawowa rzecz, jaką ITIL wprowadza, to rozróżnienie między incydentem a problemem. Incident to cokolwiek, co zaburza działanie usługi. Problem to przyczyna jednego lub wielu incydentów. Wydaje się proste, prawda? Ale w praktyce – gdy w piątek o 17.00 serwer pada po raz trzeci w tym tygodniu – nikt nie stoi z podręcznikiem ITIL i nie zastanawia się, czy to już problem, czy jeszcze seria niezależnych incydentów. Wszyscy po prostu chcą, żeby działało. I tu właśnie zaczyna się różnica między organizacją, która ma ITSM, a tą, która ma chaos z naklejoną karteczką „dział IT”.
W pierwszej zespół wie, że teraz trzeba szybko przywrócić usługę (incident management), a później usiąść i zastanowić się, dlaczego to w ogóle się dzieje (problem management). W drugiej wszyscy gaszą pożary, dopóki ktoś nie powie: „a może byśmy tak przestali płacić za sprzęt, który się psuje co tydzień?”
ITSM to nie to samo co ITIL, ale w praktyce wszyscy je mylą
Zarządzanie usługami IT (ITSM) to pojęcie szersze niż ITIL. ITSM to podejście do zarządzania całością tego, co IT robi dla organizacji – od projektowania usług, przez ich wdrażanie, po monitorowanie i ciągłe usprawnianie. ITIL to jeden z frameworków, który opisuje, jak to robić. Są też inne, na przykład ISO/IEC 20000, czy nawet wewnętrzne standardy firm, które wymyśliły sobie własne podejście.
Problem w tym, że w Polsce (i nie tylko) ITIL stał się synonimem ITSM. Mówisz „zarządzanie usługami IT” i ktoś od razu myśli o kursach ITIL Foundation, egzaminach i certyfikatach, które wiszą w ramkach obok dyplomów z podstawówki. A przecież ITIL to tylko jeden sposób patrzenia na ITSM – może popularny, może sprawdzony, ale nie jedyny. W małej firmie, gdzie masz trzech ludzi w IT, wdrożenie pełnego ITIL byłoby jak zakup kombajnu do ogródka na balkonie. A jednak ktoś, kto się raz zetknął z ITIL, będzie ci tłumaczył, że bez CMDB (Configuration Management Database) nie przeżyjesz. Otóż przeżyjesz.
Service desk, czyli miejsce, gdzie kończą się marzenia, a zaczynają tickety
Jeśli pracowałeś kiedykolwiek w IT, to wiesz, że service desk to pierwsza linia kontaktu między użytkownikami a działem IT. To tam spływają zgłoszenia: „nie działa mi Excel”, „zapomniałem hasła” albo ulubione „coś mi nie działa, nie wiem co, ale pilne”. Service desk w ITSM pełni rolę centrali, która rejestruje incydenty, klasyfikuje je i kieruje do odpowiednich osób. W teorii brzmi to logicznie. W praktyce często wygląda to tak, że ktoś siedzi przy telefonie, notuje zgłoszenia w Excelu i przekazuje je mailem do kolegi, który akurat nie jest na urlopie.
A jednak organizacje, które poważnie traktują ITSM, mają service desk zintegrowany z systemem ticketowym, który automatycznie eskaluje sprawy według priorytetów, łączy incydenty w problemy i generuje raporty dla zarządu. Nie oznacza to, że nagle wszystko działa idealnie – ale przynajmniej wiesz, ile spraw jest otwartych, kto nad czym pracuje i czy przypadkiem nie powtarzają się te same problemy co miesiąc.
Change management, czyli dlaczego ktoś musi powiedzieć „nie”
Jednym z bardziej niedocenianych elementów ITSM jest zarządzanie zmianami (change management). Brzmi biurokratycznie i jest – ale ma sens. Chodzi o to, żeby każda zmiana w środowisku IT (nowy serwer, aktualizacja systemu, zmiana konfiguracji) przechodziła przez proces zatwierdzania i dokumentacji. Bo inaczej masz sytuację, w której ktoś w poniedziałek rano „poprawił coś szybko na produkcji” i nagle połowa aplikacji nie działa.
W organizacjach bez ITSM zmiany robią wszyscy, kto ma dostęp i chwilę czasu. W organizacjach z ITSM każda zmiana ma właściciela, ocenę ryzyka i plan wycofania. Nie oznacza to, że nigdy nic się nie psuje – ale przynajmniej wiesz, kto jest odpowiedzialny i co dokładnie się stało. I nie musisz w panice szukać w logach, kto „coś kliknął” o 3 w nocy.
To nie jest droga dla każdego, ale jak już idziesz, to lepiej wiedzieć dokąd
ITSM nie jest czarną magią ani cudownym lekarstwem na wszystkie bolączki działu IT. To podejście, które wymaga czasu, zaangażowania i przede wszystkim zrozumienia, że nie chodzi o to, żeby wypełniać formularze, tylko o to, żeby lepiej zarządzać tym, co robisz. ITIL, ISO 20000, a nawet wewnętrzne procedury – wszystko to są narzędzia. Ale narzędzie bez pomysłu to tylko kartka papieru z ładnymi nagłówkami.
Jeśli jesteś menedżerem IT, który zastanawia się, czy warto zainwestować w ITSM – odpowiedź brzmi: to zależy. Jeśli masz pięć osób w zespole i jednego klienta, to może najpierw załóż normalny system ticketowy i przestań zarządzać zgłoszeniami mailem. Jeśli masz kilkadziesiąt osób, setki użytkowników i incydenty, które się powtarzają jak zły sen – to tak, warto poważnie zastanowić się nad wdrożeniem jakiegoś frameworka. Tylko pamiętaj, że ITSM to nie jest certyfikat na ścianie. To sposób myślenia. I jeśli twój zespół będzie myślał kategoriami usług, a nie tylko „naprawiania rzeczy”, to już jesteś o krok bliżej tego, co ITSM ma w sobie najlepszego.
Źródła
- ITIL History – IT Process Wiki, https://wiki.en.it-processmaps.com/index.php/History_of_ITIL (dostęp: 2026)
- Brooks F.P., \“The Mythical Man-Month\”, Addison-Wesley, 1975
- ITSM definition – Atlassian, https://www.atlassian.com/itsm (dostęp: 2026)
- Incident vs Problem Management – IBM, https://www.ibm.com/think/topics/incident-management-vs-problem-management (dostęp: 2026)
Zdjęcie: cottonbro studio / Pexels
