Problem

Problem (ang. problem) to przyczyna albo potencjalna przyczyna jednego lub wielu incydentów. W narzędziu wsparcia prowadzi się go jako osobny rekord dochodzenia do tej przyczyny: ma własny numer i własnego właściciela, a praca nad nim idzie pod osobnym terminem. Incydent kończy się, gdy usługa znów działa; problem zostaje otwarty tak długo, aż przyczyna zostanie usunięta albo świadomie przyjęta. Można go założyć równolegle z incydentem, także zanim ten zostanie zamknięty.

To samo słowo znaczy coś zupełnie innego dwa piętra wyżej. Kiedy sponsor mówi „mamy problem z rejestracją", opisuje ból biznesowy, od którego zaczyna się projekt. Żadnego rekordu w narzędziu wsparcia przy tym nie ma. Oba znaczenia mają swoje procedury, a kłopot zaczyna się wtedy, gdy na jednym spotkaniu ktoś używa ich naprzemiennie.

Tabela czterech mylonych pojęć (defekt, incydent, awaria, problem) stoi przy haśle incydent, a awaria jako kategoria z umowy przy haśle awaria; progi i zegary z kontraktu przy haśle SLA. Tu ich nie powtarzamy. Częsta pomyłka: problem zakładany po to, żeby wyczyścić statystykę wsparcia. Zgłoszenie znika z kolejki incydentów, rekord problemu stoi kwartał w statusie „w analizie" i nikt do niego nie wraca. Druga: mylenie problemu z planem prac. Problem odpowiada na pytanie „dlaczego", a usunięcie przyczyny bywa dopiero osobnym wnioskiem o zmianę.

Czy „problem" znaczy to samo w service desku i w analizie biznesowej?

Nie. Pod jedną nazwą kryją się dwa byty, które biorą się z czego innego i kończą w innym momencie.

	Problem w utrzymaniu	Problem w analizie biznesowej
Skąd się bierze	z incydentu, serii incydentów albo z przeglądu wzorców w rejestrze	z bólu zgłoszonego przez biznes i z danych o stanie obecnym
Co to jest	przyczyna incydentów, prowadzona jako rekord dochodzenia	opisany ból i jego skutek, akapit otwierający projekt
Kto prowadzi	właściciel problemu po stronie utrzymania	analityk biznesowy razem ze sponsorem
Kiedy się kończy	przyczyna usunięta albo przyjęta jako ryzyko	decyzją: rozwiązujemy, przeramowujemy albo odpuszczamy
Typowy dokument	rejestr problemów, zapis znanego błędu	opis problemu, karta odkrycia, wsad do wymagań

Praktyczny skutek jest jeden: zanim odpowiesz na zdanie „to jest problem", sprawdź, w której z tych dwóch sal padło. W narzędziu wsparcia ktoś czeka na przyczynę zeszłotygodniowej przerwy w działaniu, a na spotkaniu z zarządem ktoś otwiera projekt i za chwilę powie, jakie ma rozwiązanie. Z zespołem wsparcia mów więc „problem" i miej na myśli rekord. Ze sponsorem używaj sformułowania „opis problemu", bo w jego słowniku „problem" oznacza po prostu kłopot.

Kiedy założyć problem, a kiedy zostać przy incydencie?

Trzy sytuacje, w których osobna sprawa się opłaca:

1. To samo zdarzenie wraca. Wsparcie zamyka trzecie zgłoszenie tym samym obejściem i nikt nie umie powiedzieć, co je wywołuje.
2. Jedno zdarzenie było dotkliwe. Nie musi się powtórzyć. Wystarczy jedna przerwa, po której ktoś zażądał odpowiedzi „dlaczego".
3. Obejście działa, przyczyna jest nieznana. Najbardziej podstępny przypadek, bo nic się nie pali: użytkownik pracuje, wsparcie ma gotową instrukcję, a mechanizm, który to wyprodukował, dalej tkwi w systemie.

W MediFlow, naszym case'ie rejestracji online dla sieci przychodni, problem powstał dokładnie z pierwszego powodu: zrywanie sesji w portalu powtarzało się nocami, a winowajcą okazał się backup systemu HIS uruchamiany o 2:00. Bez osobnego dochodzenia zostałaby seria zgłoszeń zamykanych obejściem.

Przy samym incydencie zostajesz wtedy, gdy przyczyna jest znana od pierwszej minuty i mieści się w rutynie: wygasły certyfikat, zapełniony dysk, zaplanowane okno serwisowe, o którym nie uprzedzono użytkowników. Zakładanie problemu do każdego zgłoszenia kończy się rejestrem, którego nikt nie przegląda. Sam wyzwalacz spisuje się zawczasu, w procedurze wsparcia albo w umowie utrzymaniowej; podział na incydenty, problemy i zmiany, z którego ten wyzwalacz wynika, opisujemy przy haśle ITIL.

Co powinno być w rekordzie problemu?

• Opis zjawiska. Co się dzieje, komu i jak często, bez nazwiska w roli przyczyny.
• Powiązane incydenty. Wpisz numery zgłoszeń. Bez nich nikt nie oceni skali.
• Hipotezy ze statusem. Sprawdzona, obalona, czeka na dane. Hipoteza bez statusu wraca na każdym spotkaniu.
• Znany błąd i obejście, gdy już je znacie.
• Właściciel. Jedna osoba z imieniem i nazwiskiem.
• Decyzja z datą. Usuwamy przyczynę, przyjmujemy ryzyko, czekamy na wersję dostawcy.

Na prelekcji o zarządzaniu i ciągłym doskonaleniu procesów (Magdalena Stras, 23 marca 2026, materiał kursu o architekturze procesów biznesowych) padło zdanie o ryzykach: każde ryzyko musi dostać konkretnego właściciela, nierzadko innego niż właściciel procesu, żeby uniknąć rozproszenia odpowiedzialności i „sprzedawania problemu". Rekord problemu bez nazwiska zachowuje się identycznie: krąży między zespołami i nikt nie odpowiada za jego termin.

Czym jest znany błąd i po co dokumentować obejście?

Znany błąd to problem z ustaloną przyczyną, do którego nie ma jeszcze naprawy. Brzmi jak porażka, a jest jednym z najbardziej użytecznych zapisów w utrzymaniu: kiedy zdarzenie wraca, wsparcie sięga po opisane obejście i skraca przestój, zamiast prowadzić dochodzenie od początku.

Obejście to sposób na przywrócenie działania bez usuwania przyczyny. Skraca przestój i zdejmuje presję z zespołu, ale zdejmuje ją też z decyzji o naprawie. Dobrze udokumentowane obejście potrafi żyć latami: skoro ludzie pracują, naprawa spada na koniec listy. Dlatego przy jego zapisie od razu ustaw datę przeglądu. Zegary z umowy bywają przy tym mylące. Uruchomione obejście zatrzymuje zegar obejścia. Zegar rozwiązania biegnie dalej, do przywrócenia docelowego działania usługi, a jego długość zależy od priorytetu z tabeli przy haśle SLA. Samo usunięcie przyczyny nie ma już zegara incydentu: w praktyce pilnuje go termin rekordu problemu.

Czym różni się reaktywne zarządzanie problemami od proaktywnego?

Reaktywne zaczyna się od zdarzenia: coś przestało działać, otwieramy dochodzenie. Proaktywne zaczyna się od przeglądu rejestru incydentów, w którym ktoś raz w miesiącu szuka powtarzających się układów zgłoszeń. Wystarczą do niego trzy pytania: które usługi generują najwięcej zgłoszeń, które zgłoszenia wracają mimo zamknięcia i gdzie obejście stało się stałym elementem pracy. Techniki dochodzenia są te same, które analityk już zna: 5 why na jednym łańcuchu i diagram Ishikawy, gdy hipotez jest kilka naraz. Obie opisujemy krok po kroku we wpisie o analizie przyczyn źródłowych, razem z agendą warsztatu.

Kiedy problem jest zamknięty?

W jednym z dwóch momentów. Pierwszy: przyczyna została usunięta i widać to w danych, bo zdarzenie przestało wracać. Drugi, rzadziej wypowiadany na głos: przyczyna jest znana i świadomie zostaje, bo koszt naprawy przewyższa szkodę, dostawca planuje zmianę w kolejnej wersji albo moduł idzie do wygaszenia.

Drugie zakończenie jest w porządku pod jednym warunkiem: decyzja ma datę, ma właściciela i ma wpis w rejestrze ryzyk, który opisujemy we wpisie o analizie ryzyka projektu. Bez tego wpisu przyjęte ryzyko wypada z pola widzenia i przy kolejnym incydencie zespół zaczyna dochodzenie od zera. Skuteczność całej tej pracy widać w jednej liczbie: odsetek nawrotów, czyli ile incydentów wraca po zamknięciu problemu.

Jak napisać opis problemu, od którego zaczyna się projekt?

Tu przechodzimy do drugiego znaczenia. Opis problemu (ang. problem statement) to krótki akapit mówiący, kogo boli, co się dzieje, w jakim kontekście i jakim kosztem. Czyta się go w trzydzieści sekund, a przeczyta go każdy, kto wejdzie do projektu za pół roku.

W lekcji o tym w naszym minikursie o odkrywaniu jest scena, którą zna każdy analityk. Anna, analityczka w MediFlow, wraca do sali z notatkami po sesji „pięć razy dlaczego", a na tablicy ktoś zdążył już napisać dużymi literami: „PROBLEM: nie mamy aplikacji do rezerwacji online". To, co wisi na tablicy, jest brakiem konkretnego rozwiązania przebranym za problem. Test jest prosty: jeśli zdanie da się „rozwiązać", kupując albo budując rzecz z tego zdania, to nie był problem. Tak samo działa „potrzebujemy chatbota" i „rejestratorki nie mają systemu kolejkowego".

Szablon z lekcji ma pięć elementów:

1. Kto jest dotknięty, czyli która grupa cierpi.
2. Co się dzieje, opisane neutralnie.
3. Gdzie i kiedy, czyli w jakim kontekście boli najbardziej.
4. Jaki jest wpływ albo koszt, najlepiej z liczbą.
5. Bez rozwiązania: w całym akapicie nie pada nazwa systemu, kanału ani technologii.

Test neutralności robi się po napisaniu. Podkreśl każdy rzeczownik, który jest nazwą rzeczy do zbudowania albo kupienia, wytnij go i napisz, czemu ta rzecz miała służyć. Drugie sprawdzenie: czy istnieje więcej niż jeden sposób rozwiązania tego problemu. Jeśli tylko jeden, odpowiedź już siedzi w zdaniu. W wersji MediFlow po poprawce zostaje sam ból: pacjenci 12 przychodni i rejestratorki nie mają sprawnego sposobu, żeby umówić, potwierdzić albo odwołać wizytę inaczej niż telefonicznie, najdotkliwiej w poniedziałkowe poranki, a skutkiem są puste gabinety, przeciążone rejestratorki i pacjenci rezygnujący z umówienia.

Skąd wiesz, że problem jest wart rozwiązywania?

Z trzech pytań zadanych w tej kolejności: czy problem jest realny (widać go w danych, nie tylko w głowie zarządu), czy jest dość dotkliwy (ludzie próbują sobie z nim radzić po swojemu) i czy jest wart rozwiązania przez nas i teraz. Ból, wobec którego nikt nie wymyślił żadnego obejścia, jest zwykle bólem słabym. Sprawdza się to tanio: rozmową o przeszłym zachowaniu, danymi z systemu i małym eksperymentem. Pytania hipotetyczne w rodzaju „czy użyłby pan aplikacji" są bezużyteczne, bo wszyscy odpowiadają „tak", a potem nikt nie używa.

Kończy się to decyzją o samym problemie: kontynuuj, przeramuj (problem realny, ale nie ten, który zakładaliśmy) albo odpuść. Trzecia możliwość bywa najcenniejsza, bo zaoszczędzony budżet też jest wynikiem pracy analityka.

Co robi analityk biznesowy przy problemie w utrzymaniu?

Rolę analityka przy samym zdarzeniu opisujemy przy haśle incydent. W dochodzeniu dochodzą do tego dwie rzeczy, których zwykle nie robi nikt inny.

Pilnuje, żeby łańcuch przyczyn nie kończył się na człowieku. Jeśli odpowiedź na „dlaczego" zawiera imię albo stanowisko, to nie jest przyczyna, tylko kolejny objaw. Wymiana jednej osoby na drugą niczego nie zmieni, bo nowa wpadnie w ten sam proces.

Przekuwa przyczynę w pozycję backlogu. Ścieżka wygląda tak: przyczyna źródłowa, potrzeba biznesowa, wymaganie z kryteriami akceptacji, miara sukcesu. Samą przyczynę wpisz do opisu historyjki. Za pół roku ktoś zapyta, po co nam ta reguła, i odpowiedź ma czekać w zgłoszeniu.

Gdy dochodzenie stoi mimo zapisów w umowie, procedurę opisujemy przy haśle eskalacja. Gdy usunięcie przyczyny wymaga zmiany w systemie, naprawa idzie jako wniosek o zmianę, a rekord problemu zostaje w rejestrze ze statusem „czeka na zmianę", aż dane potwierdzą, że zdarzenie przestało wracać. Zarządzanie zmianą opisujemy przy haśle ITIL.

Gdzie sprawdzić, czy umiesz to zastosować?

Najbliższy temu tematowi test dotyczy tego, co problemem jeszcze nie jest: test wiedzy o zarządzaniu ryzykiem. Szablon opisu problemu przechodzimy krok po kroku w naszym minikursie o odkrywaniu i ramowaniu problemu.

Jeśli chcesz przejść pierwszą lekcję tego minikursu i mieć plan nauki na trzydzieści dni, załóż darmowe konto: daje też trzy podejścia do testów w miesiącu. Jak dziś wygląda rynek pracy dla analityków, sprawdzisz w Barometrze rynku BA.

Gdzie iść dalej

• Incydent - zdarzenie, od którego zaczyna się problem, i tabela czterech mylonych pojęć
• Awaria - kategoria z umowy i to, co kontrakt musi o niej powiedzieć
• Defekt - niezgodność w produkcie, która bywa przyczyną, ale nie musi nią być
• SLA - trzy zegary i tabela priorytetów z definicjami zdarzeń
• ITIL - biblioteka praktyk, z której pochodzi rozróżnienie incydent, problem, zmiana
• Wniosek o zmianę - droga naprawy, gdy przyczyna wymaga zmiany w systemie
• 5 why i diagram Ishikawy - techniki dochodzenia do przyczyny
• Rejestr ryzyk - miejsce na przyczynę, którą świadomie zostawiacie
• Eskalacja - co zrobić, gdy sprawa stoi mimo zapisów w umowie

Rozgraniczenie czterech pojęć pochodzi z naszego hasła incydent, zegary umowy z hasła SLA, a przykład nocnego zrywania sesji w MediFlow z hasła ITIL. Scena z tablicą, szablon opisu problemu, test neutralności oraz trzy pytania walidacyjne pochodzą z lekcji 4 i 9 naszego minikursu „Odkrywanie i ramowanie problemu". Ścieżka od przyczyny do pozycji backlogu i reguła o łańcuchu kończącym się na człowieku pochodzą z wpisu o analizie przyczyn źródłowych. Zdanie o właścicielu ryzyka padło na prelekcji „Zarządzanie i ciągłe doskonalenie myślenia procesowego w praktyce" (Magdalena Stras, 23 marca 2026). Podział na reaktywne i proaktywne zarządzanie problemami oraz pojęcia znanego błędu i obejścia pochodzą z praktyki opisanej w ITIL.