Incydent (ang. incident) to nieplanowane przerwanie działania usługi albo obniżenie jej jakości. Pojedyncze zdarzenie, z datą i godziną: portal rejestracji nie odpowiada od 9:12, logowanie trwa minutę zamiast dwóch sekund. Zgłasza je użytkownik albo łapie monitoring, zanim ktokolwiek zadzwoni. Celem obsługi incydentu jest przywrócenie działania, a szukanie przyczyny to osobna praca, prowadzona pod innym numerem.
W jednym zdaniu, żeby nie mylić czterech słów: defekt siedzi w produkcie i żyje, dopóki ktoś go nie naprawi; incydent jest zdarzeniem w usłudze i kończy się, gdy usługa znów działa; awaria to zwykle klasa dotkliwości zapisana w umowie i rozliczana według SLA; problem to dochodzenie w sprawie przyczyny jednego albo wielu incydentów.
Trzy ścieżki dla trzech zgłoszeń w MediFlow, naszym case'ie rejestracji online dla sieci przychodni (incydent, problem i wniosek o zmianę), rozpisujemy przy haśle ITIL. Tu zajmujemy się pierwszą z nich.
Częsta pomyłka: uznanie, że incydent zamknięty równa się sprawa załatwiona. Wsparcie odpisuje „proszę odświeżyć stronę", zgłoszenie dostaje status zamknięte, a jutro to samo zdarzenie wraca u dwudziestu innych osób. Druga: nazywanie incydentem każdego maila do IT, także prośby o nowe uprawnienie. To wniosek o usługę i ma własną kolejkę.
Incydent, zgłoszenie, ticket, awaria - jak to nazywać po polsku?
| Forma | Gdzie ją spotkasz | Co realnie znaczy |
|---|---|---|
| incydent | narzędzie do zgłoszeń, umowa serwisowa, raport miesięczny | zdarzenie w usłudze, z rejestrem i priorytetem |
| zgłoszenie | rozmowa z użytkownikiem, service desk | to, co użytkownik wysłał; dopiero po kategoryzacji wiadomo, czy to incydent, wniosek czy pytanie |
| ticket | żargon zespołu | rekord w narzędziu; jeden ticket może zawierać incydent, może wniosek o usługę |
| awaria | umowa, rozmowa z dostawcą, komunikat dla klientów | klasa dotkliwości zapisana w umowie, zwykle po stronie niedostępności, z konsekwencją finansową |
Kłopot sprawia przede wszystkim „zgłoszenie". W rozmowie znaczy tyle co incydent, w statystyce miesza trzy różne rzeczy. Jeżeli w raporcie stoi „zamknęliśmy 340 zgłoszeń", a nikt nie rozdzielił incydentów od wniosków o usługę, liczba nie mówi nic o jakości systemu. W narzędziu decyduje kategoria nadana przy rejestracji, w rozmowie mów tak, jak mówi zespół.
Czym incydent różni się od defektu, problemu i awarii?
| Incydent | Defekt | Problem | Awaria | |
|---|---|---|---|---|
| Co to jest | zdarzenie: usługa nie działa albo działa gorzej | niezgodność w produkcie z wymaganiem | dochodzenie w sprawie przyczyny | klasa dotkliwości incydentu z umowy |
| Gdzie żyje | rejestr incydentów, service desk | backlog, narzędzie do zgłoszeń defektów | rejestr problemów | umowa, raport SLA |
| Kiedy jest zamknięte | usługa działa, choćby obejściem | naprawa przeszła retest | przyczyna znana i usunięta albo świadomie zaakceptowana | jak incydent, plus rozliczenie według SLA |
| Kto zamyka | wsparcie, po potwierdzeniu użytkownika | zespół wytwórczy | właściciel problemu | wsparcie, a rozliczenie strony umowy |
Z tej tabeli wynika, że zamknięcie incydentu nie zamyka defektu, o czym piszemy przy haśle defekt. Wynika też, że defekt bywa przyczyną incydentu, ale bywa nią również błędna konfiguracja, przeciążenie albo zmiana po stronie systemu, z którym się integrujemy. Incydent bez defektu jest więc zupełnie normalny.
Jak wygląda cykl życia incydentu?
Kolejność jest ważniejsza niż nazwy etapów, bo w każdym narzędziu nazywają się inaczej.
- Wykrycie. Użytkownik dzwoni, pisze albo alert z monitoringu trafia do kolejki. Im więcej incydentów łapie monitoring, tym rzadziej firma dowiaduje się o awarii od klienta.
- Rejestracja i kategoryzacja. Numer, czas, zgłaszający, usługa. Tu zapada decyzja, czy to incydent, wniosek o usługę czy pytanie.
- Priorytet. Z wpływu i pilności, według zasad spisanych przed pierwszym incydentem.
- Diagnoza i obejście. Celem jest przywrócenie pracy użytkownikowi, choćby okrężną drogą. Obejście idzie do wsparcia natychmiast, zanim zacznie się naprawa.
- Przywrócenie i zamknięcie. Po potwierdzeniu, że użytkownik znów pracuje. Zamknięcie po „u mnie działa" to najkrótsza droga do incydentu, który wraca.
- Przegląd. Dla incydentów o dużym wpływie osobne spotkanie po fakcie, z pytaniem „dlaczego" zadanym kilka razy z rzędu. Technikę opisujemy przy haśle 5 why, a szerzej w tekście o analizie przyczyn źródłowych.
Na tym cyklu wiszą trzy zegary: czas reakcji, czas obejścia i czas rozwiązania. Mierzą co innego i umowa z samym czasem reakcji gwarantuje wyłącznie to, że ktoś odpisze. Rozbieramy je przy haśle SLA, tu zapamiętaj jedno: etap 4 zatrzymuje zegar obejścia. Czy biegnie jeszcze zegar rozwiązania, zależy od priorytetu: w tabeli przy haśle SLA P1 ma osobno reakcję i obejście, a termin rozwiązania pojawia się od P2. Usunięcie przyczyny po zamknięciu incydentu prowadzi się jako problem i termin z umowy jest wtedy terminem dla problemu.
Skąd się bierze priorytet incydentu?
Z dwóch pytań zadanych osobno. Wpływ: ilu użytkowników, które procesy, czy powstają błędne dane. Pilność: czy da się poczekać bez szkody, czy szkoda rośnie z każdą godziną.
W SLA wynegocjowanym dla e-rejestracji MediFlow incydent krytyczny ma definicję zdarzenia, nie tylko nazwę: „nie można rezerwować w żadnej placówce", reakcja 30 minut, obejście 4 godziny, pomiar sondą zewnętrzną co 60 sekund. Bez takiego zapisu każdy incydent zaczyna się od sporu, czy to już jedynka. Dla porównania załóżmy, że ten sam portal działa wolno w jednej przychodni: to inny priorytet, bo obejście istnieje, rejestracja przez telefon.
Skalę priorytetów z definicjami zdarzeń i zegarami dla P1, P2 i P3 masz w tabeli przy haśle SLA. Uzgadnia się ją przed pierwszym incydentem, bo nazwa priorytetu bez definicji zdarzenia nie znaczy nic.
Co robi analityk biznesowy przy incydencie?
Nie siedzi na dyżurze i nie restartuje serwera. Robi cztery rzeczy, które bez niego nie powstają.
Pisze wymagania wsparcia, zanim system ruszy. Przy haśle ITIL piszemy, że analityk spotyka tę bibliotekę najczęściej zaraz po budowie systemu, bo ktoś musi zdefiniować, jak będzie wspierany: czasy reakcji, ścieżka zgłoszeń, proces wprowadzania zmian. Do tej listy dopisz od siebie jedno pytanie: kto przyjmuje incydent o 22:00. Bez tego w specyfikacji stoi „system ma działać niezawodnie" i każdy rozumie to inaczej. Miejsce na te zapisy to wymagania niefunkcjonalne; szerzej piszemy o nich we wpisie o wymaganiach niefunkcjonalnych.
Tłumaczy skutek techniczny na skutek biznesowy. „Nie zapisuje się status wizyty" jest dla decydenta pustą informacją. „Rejestracja w dwunastu przychodniach prowadzi grafik na papierze i wieczorem trzeba go przepisać ręcznie" to zdanie, po którym zapada decyzja o poprawce poza cyklem. Ten przykład rozbieramy w haśle defekt, przy defekcie znalezionym na produkcji.
Patrzy na incydent od strony procesu. W tekście o analizie przyczyn źródłowych piszemy wprost: przy incydencie produkcyjnym analityk bywa jedyną osobą, która patrzy na zdarzenie od strony procesu, nie tylko kodu. Kto zgłosił, ile czasu minęło, kto wiedział i nie przekazał dalej, dlaczego obejście nie było znane na pierwszej linii.
Pilnuje, żeby każdy alert miał właściciela. Na prelekcji o zarządzaniu i ciągłym doskonaleniu procesów (Magdalena Stras, 23 marca 2026, nagranie przy kursie o architekturze procesów, dostępne dla kont płatnych) padło zdanie do powieszenia nad pulpitem monitoringu: każdy alert musi mieć przypisanego konkretnego właściciela, inaczej następuje rozproszenie odpowiedzialności. Alert bez właściciela to incydent, który wszyscy widzieli i nikt nie przyjął.
Kiedy incydent staje się problemem?
Wtedy, gdy ktoś zakłada osobną sprawę, żeby ustalić przyczynę. Powtarzalność nie jest warunkiem: jedna dotkliwa awaria wystarczy, żeby otworzyć problem. Zwykle jednak wyzwalaczem jest seria. W MediFlow nocne zrywanie sesji powtarzało się i przed ustaleniem modelu wsparcia wpadało do jednego wora „IT, naprawcie". Rozpisane jako problem, doprowadziło do przyczyny: backup systemu medycznego o 2:00 blokował bazę.
Na tej samej prelekcji ścieżki eskalacji opisano na trzech poziomach i to jest dobra mapa dla incydentów. Operacyjny to rozwiązanie „tu i teraz", na przykład pomoc klientowi, który nie może wysłać formularza; brak tej ścieżki zmusza pracowników do ukrywania błędów. Taktyczny adresuje problemy powtarzalne i tu decyduje komunikacja: ludzie muszą wiedzieć, że problem jest znany i trwają prace nad rozwiązaniem systemowym. Strategiczny to zmiana samej struktury procesu albo technologii. Incydent żyje na pierwszym poziomie, problem zaczyna się na drugim. Jeżeli ten sam incydent wraca trzeci raz i nadal nikt nie założył problemu, brakuje drugiego poziomu.
Co robić, gdy zgłoszenie mimo umowy nie rusza z miejsca, opisujemy przy haśle eskalacja.
Czy incydent to tylko sprawa IT?
Nie, i to jest pułapka dla analityka, który słowo zna wyłącznie z service desku.
Incydent bezpieczeństwa. Przy haśle testowanie bezpieczeństwa opisujemy pentest MediFlow, który przed startem wykrył podatność pozwalającą podejrzeć wizytę innego pacjenta po zmianie identyfikatora w adresie. Dla sieci przychodni to nie jest błąd średniej wagi, tylko potencjalny incydent zgłaszany do UODO. Jeśli naruszenie niesie ryzyko dla pacjentów, RODO daje na zgłoszenie organowi nadzorczemu co do zasady 72 godziny od jego stwierdzenia. Procedura na taki incydent musi istnieć przed startem systemu, bo 72 godziny to za mało, żeby ją wtedy pisać.
Incydent w komunikacji kryzysowej. W kursie wprowadzającym do analizy biznesowej, w lekcji o zarządzaniu współpracą, jest ćwiczenie z planem komunikacji kryzysowej dla zakładu produkcyjnego: jeden zatwierdzony głos na zewnątrz, pierwszy komunikat do pracowników w dwie godziny, różne treści dla różnych grup. Lekcja zawiera polecenie, żeby wybrać scenariusz incydentu możliwy we własnej organizacji i wypełnić pierwszy wiersz takiego planu. To samo słowo, inny zespół i inne zegary. W innej lekcji tego kursu, o współpracy z interesariuszami, plan zaangażowania właścicieli obiektów zawiera „SLA jakości obsługi, raport incydentów dostępu", czyli raport incydentów jako zobowiązanie wobec konkretnej grupy.
Co mówi nasz job board?
Odczyt z 4 września 2026: 292 aktywne oferty dla analityków. Słowo „incydent" nie pada w żadnej, po angielsku „incident" też nie, ITIL raz, „service desk" i „SLA" zero. „Wsparcie" albo „support" pojawia się w 25 ofertach, między innymi w tytułach typu Support Analyst. Dla porównania Jira stoi w 24 ofertach, SQL w 23, BPMN w 36. Agregator przechowuje zajawki ofert, nie pełną treść.
Wniosek ostrożny: obsługa incydentów nie jest kompetencją, po którą rekruterzy sięgają w nagłówku oferty dla analityka. Żywe liczby z rynku masz w Barometrze rynku BA.
Najczęstsze pytania
Czy każdy incydent to błąd w systemie?
Nie. Przerwa w prądzie w serwerowni, wygasły certyfikat, przeciążenie po kampanii marketingowej, użytkownik z wygasłym hasłem: wszystko to są incydenty bez defektu w kodzie. Odwrotnie też bywa: defekt siedzi w systemie miesiącami i nie wywołuje żadnego incydentu, bo nikt nie używa tej ścieżki.
Kto może zgłosić incydent?
Każdy, kto zauważył, że usługa nie działa: użytkownik, pracownik wsparcia, monitoring, partner, którego integracja przestała odpowiadać. Rejestr prowadzi wsparcie, nawet jeśli zgłoszenie założył użytkownik przez portal samoobsługowy.
Co to jest major incident?
Incydent o najwyższym wpływie, dla którego uruchamia się osobna procedura: dedykowany koordynator, komunikacja do interesariuszy w ustalonych odstępach, przegląd po zamknięciu. W polskich umowach ten poziom nazywa się zwykle incydentem krytycznym, a bywa też definiowany jako awaria; jego definicję zdarzenia trzeba mieć zapisaną słowo w słowo.
Sprawdź, czy umiesz to zastosować
Najbliższy test, jaki mamy, dotyczy ryzyka, czyli tego, co incydentem jeszcze nie jest: test wiedzy o zarządzaniu ryzykiem: piętnaście pytań o prawdopodobieństwo, wpływ i strategie reakcji. Rozwiążesz go bez zakładania konta. Rejestr ryzyk krok po kroku opisujemy we wpisie o analizie ryzyka projektu.
Ćwiczenie z planem komunikacji kryzysowej i plan zaangażowania interesariuszy są w kursie wprowadzającym do analizy biznesowej. Program zobaczysz bez logowania; darmowe konto otwiera pierwszą lekcję kursu, a te dwie lekcje siedzą w płatnej części. Ten sam test masz też na platformie po założeniu darmowego konta: wynik zostaje w historii podejść, a konto bez subskrypcji ma trzy podejścia do testów w miesiącu.
Gdzie iść dalej
- Defekt - to, co bywa przyczyną incydentu i żyje dłużej niż on
- SLA - zegary, priorytety i kary, według których incydent jest rozliczany
- ITIL - biblioteka praktyk, z której pochodzi rozróżnienie incydent, problem, zmiana
- Eskalacja - co zrobić, gdy incydent stoi mimo umowy
- 5 why i diagram Ishikawy - techniki przeglądu po incydencie
- Wymaganie niefunkcjonalne - miejsce na czasy reakcji i dostępność w specyfikacji
- Business continuity i disaster recovery - co firma robi, gdy incydent trwa dłużej, niż obiecano
Trzy ścieżki zgłoszeń w MediFlow pochodzą z naszego hasła ITIL, definicja incydentu krytycznego z hasła SLA, rozgraniczenie czterech pojęć z hasła defekt. Poziomy eskalacji i zdanie o właścicielu alertu padły na prelekcji „Zarządzanie i ciągłe doskonalenie myślenia procesowego w praktyce" (Magdalena Stras, 23 marca 2026). Ćwiczenie z komunikacją kryzysową i plan zaangażowania interesariuszy pochodzą z dwóch lekcji naszego kursu wprowadzającego. Liczby z job boardu policzone 4 września 2026 na 292 aktywnych ofertach.