Szablon danych do zarządzania problemami

Zarządzanie problemami w ServiceNow
Szablon danych do zarządzania problemami

Szablon danych do zarządzania problemami

Szablon zawiera plan analizy cyklu zarządzania problemami ITIL w ServiceNow. Znajdą w nim Państwo listę potrzebnych atrybutów, działań do śledzenia oraz instrukcje krok po kroku dotyczące ekstrakcji danych. Taka struktura ułatwia sprawdzenie, jak skrócić średni czas rozwiązania problemu i ograniczyć powtarzające się incydenty.
  • Zalecane atrybuty do analizy przyczyn źródłowych
  • Najważniejsze etapy i działania w procesie
  • Instrukcja ekstrakcji danych z ServiceNow krok po kroku
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zarządzania problemami

Poniżej przedstawiono zalecane pola danych do uwzględnienia w dzienniku zdarzeń, aby dokładnie analizować proces zarządzania problemami ITIL.
5 Wymagane 7 Zalecane 9 Opcjonalne
Nazwa Opis
Działanie
Activity
Zdarzenie lub czynność wykonana w ramach rekordu problemu.
Opis

Oznacza poszczególne kroki lub zmiany statusu w cyklu życia rekordu problemu. Przykłady: „Utworzono rekord problemu”, „Ustalono przyczynę źródłową” lub „Przypisano do grupy wsparcia”. Ten atrybut służy do budowy mapy procesu i wizualizacji kolejności zdarzeń.

Dlaczego to ważne

Określa węzły na mapie procesu, dzięki czemu można wizualizować przebieg workflow i warianty procesu.

Skąd pobrać

Dane pochodzą z tabel „sys_audit”, „sys_history_line” lub ze zmian stanu w tabeli „problem”

Przykłady
Utworzenie rekordu problemuZakończono analizęZmieniono stan na zamknięty
Rekord problemu
ProblemNumber
Unikalny identyfikator rekordu problemu.
Opis

Unikalny klucz alfanumeryczny przypisany do konkretnego rekordu problemu w ServiceNow (np. PRB000123). Identyfikator ten łączy wszystkie działania w procesie: od zarejestrowania problemu, przez analizę przyczyny źródłowej, aż po jego zamknięcie. W analizie process mining pełni funkcję Case ID, dzięki czemu można odtworzyć cały przebieg obsługi problemu.

Dlaczego to ważne

To podstawowy klucz, który pozwala rozróżniać poszczególne sprawy i grupować powiązane zdarzenia na grafie procesu.

Skąd pobrać

Tabela ServiceNow „problem”, pole „number”

Przykłady
PRB004512PRB009823PRB001122
Znacznik czasu zdarzenia
EventTime
Dokładna data i godzina wystąpienia działania.
Opis

Zapisuje dokładny znacznik czasu zarejestrowania zmiany lub działania w systemie. Dane te pozwalają uporządkować działania chronologicznie i obliczać czas trwania, na przykład czas cyklu oraz czas realizacji między etapami procesu.

Dlaczego to ważne

Niezbędny do uporządkowania zdarzeń i obliczania wszystkich KPI opartych na czasie.

Skąd pobrać

Pole ServiceNow „sys_created_on” w tabelach audytu i historii

Przykłady
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu ekstrakcji danych lub ich ostatniego odświeżenia.
Opis

Informuje, jak aktualny jest zbiór danych używany w analizie. Pomaga ustalić, czy analizowane są dane bieżące, czy historyczna migawka, co ma znaczenie przy interpretacji statusów otwartych spraw.

Dlaczego to ważne

Pozwala użytkownikom sprawdzić aktualność danych i rzetelnie raportować wyniki operacyjne.

Skąd pobrać

Czas systemowy w chwili wykonania ETL

Przykłady
2023-11-01T12:00:00Z
System źródłowy
SourceSystem
Nazwa systemu, z którego pochodzą dane.
Opis

Wskazuje konkretną instancję lub środowisko ServiceNow, z którego pobrano dane dotyczące zarządzania problemami. Jest to szczególnie przydatne w środowiskach z wieloma systemami, ponieważ pozwala śledzić pochodzenie danych i uwzględniać różnice między systemami w analizie.

Dlaczego to ważne

Pozwala ustalić pochodzenie danych, zwłaszcza gdy łączone są dane z kilku narzędzi ITSM.

Skąd pobrać

Wartość ustawiana na etapie ekstrakcji (np. „ServiceNow Production”)

Przykłady
ServiceNow ProdServiceNow EMEA
Grupa wsparcia
AssignmentGroup
Zespół techniczny odpowiedzialny za rozwiązanie problemu.
Opis

Wskazuje grupę wsparcia lub zespół przypisany obecnie do problemu. Atrybut ten jest niezbędny w dashboardzie „Analiza przekazywania między grupami wsparcia”, który pozwala śledzić przekazywanie spraw między zespołami i wykrywać silosy organizacyjne.

Dlaczego to ważne

Pomaga wykrywać wąskie gardła między działami i analizować sprawność przekazywania spraw.

Skąd pobrać

Tabela ServiceNow „problem”, pole „assignment_group”

Przykłady
Operacje siecioweAdministratorzy baz danychService desk
Kategoria przyczyny źródłowej
RootCauseCategory
Klasyfikacja ustalonej przyczyny źródłowej.
Opis

Klasyfikuje przyczynę problemu, na przykład jako błąd oprogramowania, błąd człowieka lub awarię sprzętu. Atrybut ten zasila dashboard „Dokładność klasyfikacji przyczyn źródłowych” i pomaga wykrywać powtarzające się wzorce awarii.

Dlaczego to ważne

Pozwala analizować wzorce awarii i planować usprawnienia.

Skąd pobrać

Tabela ServiceNow „problem”, pole „rca_category” lub „u_root_cause_category”

Przykłady
Wada oprogramowaniaBłąd konfiguracjiProblem po stronie dostawcy
Liczba ponownych przypisań
ReassignmentCount
Liczba zmian grupy przypisanej do problemu.
Opis

Licznik zmian grupy przypisania. Jest źródłem danych dla KPI „Liczba ponownych przypisań rekordu problemu” i pomaga wykrywać efekt „ping-ponga”, gdy zgłoszenia krążą między zespołami.

Dlaczego to ważne

Bezpośredni wskaźnik tarć w procesie i niejasnego podziału odpowiedzialności.

Skąd pobrać

Tabela ServiceNow „problem”, pole „reassignment_count”

Przykłady
0312
Liczba powiązanych incydentów
RelatedIncidentCount
Liczba incydentów powiązanych z tym rekordem problemu.
Opis

Określa wpływ problemu, zliczając powiązane z nim incydenty. Wysokie wartości, zwłaszcza w przypadku znanych błędów, są uwzględniane w dashboardzie „Znane błędy i nawroty incydentów”.

Dlaczego to ważne

Mierzy skalę wpływu problemu na użytkowników.

Skąd pobrać

Tabela ServiceNow „problem”, pole „related_incidents” (nazwa pola może się różnić) lub liczba powiązanych rekordów

Przykłady
1501200
Priorytet
Priority
Poziom priorytetu przypisany do rekordu problemu.
Opis

Określa wagę i pilność problemu, zwykle na podstawie jego wpływu i pilności. Atrybut pozwala podzielić wyniki analizy według krytyczności i wspiera dashboard „Monitorowanie naruszeń SLA i priorytetów”.

Dlaczego to ważne

Pozwala analizować wyniki procesu z uwzględnieniem znaczenia problemu dla działalności.

Skąd pobrać

Tabela ServiceNow „problem”, pole „priority”

Przykłady
1 - Krytyczny2 - Wysoki3 - Umiarkowany
Przypisany użytkownik
AssignedTo
Osoba przypisana do obsługi problemu.
Opis

Wskazuje użytkownika odpowiedzialnego obecnie za rekord problemu. Analiza tego atrybutu pomaga ocenić rozkład obciążenia pracą, wyniki poszczególnych osób i potencjalne wąskie gardła związane z zasobami.

Dlaczego to ważne

Przydatny do analizy efektywności zasobów i obciążenia poszczególnych osób.

Skąd pobrać

Tabela ServiceNow „problem”, pole „assigned_to”

Przykłady
Alice SmithBob JonesAdministrator systemu
Stan problemu
ProblemState
Status cyklu życia rekordu problemu.
Opis

Określa bieżący etap obsługi problemu, na przykład: otwarty, analiza przyczyny źródłowej, wdrażanie poprawki lub zamknięty. Atrybut ten służy do filtrowania i analizy struktury zaległości w dashboardzie „Analiza wieku zaległych rekordów problemów”.

Dlaczego to ważne

Podstawowy wskaźnik statusu, który pozwala filtrować sprawy otwarte i zamknięte.

Skąd pobrać

Tabela ServiceNow „problem”, pole „state”

Przykłady
NowyOcenaAnaliza przyczyn źródłowychRozwiązany
Czas oczekiwania
PendingDuration
Łączny czas, przez który problem pozostawał zawieszony lub oczekiwał na dalsze działania.
Opis

Sumuje czas spędzony w statusach takich jak „Oczekiwanie na dostawcę” lub „Wstrzymany”. Wskaźnik ten służy do analizy „Czas w statusie oczekiwania”, która pozwala oddzielić czas pracy zespołu od opóźnień zewnętrznych.

Dlaczego to ważne

Pozwala odróżnić niską efektywność zespołu od opóźnień wynikających z zależności zewnętrznych.

Skąd pobrać

Obliczenie: suma czasu trwania przedziałów, w których stan = oczekujący/wstrzymany

Przykłady
5 dni0 minut
Czas opracowania rozwiązania
SolutionDraftingTime
Czas od ustalenia przyczyny źródłowej do zaproponowania rozwiązania.
Opis

Mierzy czas opracowywania poprawki po ustaleniu przyczyny problemu. Wskaźnik ten wspiera dashboard „Opracowanie rozwiązania i wdrożenie poprawki”.

Dlaczego to ważne

Pozwala osobno ocenić czas projektowania poprawki.

Skąd pobrać

Obliczenie: znacznik czasu zdarzenia „Opracowano propozycję rozwiązania” minus „Ustalono przyczynę źródłową”

Przykłady
2 dni4 godziny
Element konfiguracji
ConfigurationItem
Zasób lub usługa, których dotyczy problem.
Opis

Wskazuje element konfiguracji (CI) powiązany z rekordem problemu. Analiza tego atrybutu pozwala powiązać problemy z konkretnym sprzętem, oprogramowaniem lub usługami i wspiera dashboard „Dokładność klasyfikacji przyczyn źródłowych”.

Dlaczego to ważne

Łączy problemy w procesie z konkretnymi zasobami fizycznymi lub logicznymi.

Skąd pobrać

Tabela ServiceNow „problem”, pole „cmdb_ci”

Przykłady
Serwer SAP ERP 01Usługa poczty ExchangeOracle DB Prod
Numer wniosku o zmianę
ChangeRequestNumber
Identyfikator wniosku o zmianę złożonego w celu rozwiązania problemu.
Opis

Łączy rekord problemu z rekordem zarządzania zmianą (RFC). To powiązanie jest niezbędne w dashboardzie „Sprawność przejścia do realizacji wniosku o zmianę”, który pozwala mierzyć czas przekazania sprawy od diagnozy problemu do wdrożenia zmiany w infrastrukturze.

Dlaczego to ważne

Pozwala śledzić przejście od zarządzania problemem do zarządzania zmianą.

Skąd pobrać

Tabela ServiceNow „problem”, pole „rfc”

Przykłady
CHG003001CHG004552
Opublikowanie obejścia problemu
WorkaroundPublished
Informuje, czy opisano i udostępniono obejście problemu.
Opis

Wartość logiczna lub status wskazujący, czy znaleziono tymczasowe rozwiązanie i opublikowano je w bazie wiedzy lub bazie znanych błędów. Atrybut ten wspiera dashboard „Skuteczność publikowania obejść problemów”.

Dlaczego to ważne

Pozwala mierzyć, jak szybko ograniczany jest wpływ problemu na działalność przed wdrożeniem ostatecznej poprawki.

Skąd pobrać

Tabela ServiceNow „problem”, pole „work_around” (jeśli zawiera tekst) lub określony status

Przykłady
truefalse
Termin SLA
SlaDueDate
Docelowa data i godzina rozwiązania problemu zgodnie z SLA.
Opis

Znacznik czasu określający, do kiedy problem należy rozwiązać, aby dotrzymać warunków SLA. Stanowi punkt odniesienia dla dashboardu „Monitorowanie naruszeń SLA i priorytetów” oraz obliczania wskaźników zgodności.

Dlaczego to ważne

Punkt odniesienia przy ustalaniu, czy doszło do naruszenia SLA.

Skąd pobrać

Tabela ServiceNow „task_sla” powiązana z problemem

Przykłady
2023-12-31T17:00:00Z
Usługa biznesowa
BusinessService
Usługa biznesowa, na którą problem ma bezpośredni wpływ.
Opis

Oznacza usługę widoczną z perspektywy biznesu (np. „Obsługa płac”, „Portal klienta”), a nie jej komponent techniczny. Dzięki temu raporty przedstawiają problem w kontekście działalności firmy.

Dlaczego to ważne

Łączy problemy techniczne ze strumieniami wartości biznesowej.

Skąd pobrać

Tabela ServiceNow „problem”, pole „business_service”

Przykłady
Bankowość internetowaPoczta wewnętrzna
Wynik PIR
PostImplementationReviewResult
Wynik lub status przeglądu po wdrożeniu.
Opis

Zapisuje wynik lub status PIR (np. zakończony, niewymagany, oczekujący). Atrybut ten jest potrzebny w dashboardzie „Zgodność z wymogami przeglądu po wdrożeniu”, który pozwala sprawdzić, czy poważne problemy zostały poddane przeglądowi.

Dlaczego to ważne

Wskaźnik kontroli jakości, który pozwala sprawdzić, czy wyciągnięto wnioski z poważnych incydentów.

Skąd pobrać

Tabela ServiceNow „problem”, pole „pir_state” lub podobne pole niestandardowe

Przykłady
ZakończonyOdstąpionoOczekujący
Znany błąd
IsKnownError
Wskaźnik informujący, czy problem sklasyfikowano jako znany błąd.
Opis

Informuje, czy rekord problemu został przekształcony w znany błąd lub oznaczony jako znany błąd. Jest to niezbędne w analizie „Znane błędy i nawroty incydentów”, która pozwala ocenić skuteczność zarządzania wiedzą.

Dlaczego to ważne

Pozwala odróżnić trwające analizy od zaakceptowanych wad, dla których istnieją obejścia.

Skąd pobrać

Tabela ServiceNow „problem”, pole „known_error”

Przykłady
truefalse
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania problemami

To najważniejsze kroki i etapy cyklu życia, które warto zapisać w dzienniku zdarzeń, aby prawidłowo odkryć przebieg obsługi problemów.
8 Zalecane 6 Opcjonalne
Działanie Opis
Przypisanie do grupy wsparcia
Skierowanie rekordu problemu do konkretnego zespołu technicznego w celu przeprowadzenia analizy. To działanie pokazuje, jak zmienia się odpowiedzialność za sprawę, i ma zasadnicze znaczenie przy analizie przekazań.
Dlaczego to ważne

Niezbędne do analizy zmian przypisania do grup wsparcia w dashboardzie, który pomaga wykrywać przerzucanie spraw i wąskie gardła między zespołami.

Skąd pobrać

Tabela ServiceNow 'sys_audit' lub 'sys_history_line', rejestrująca zmiany pola 'assignment_group'.

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Rozpoczęcie analizy
Zmiana stanu rekordu problemu z 'New' na 'Assess' lub 'Root Cause Analysis'. Oznacza, że analityk rozpoczął pracę nad problemem.
Dlaczego to ważne

Wyznacza koniec początkowego oczekiwania w kolejce i początek aktywnej analizy. Umożliwia analizę okresów oczekiwania.

Skąd pobrać

Tabela ServiceNow 'sys_audit' rejestrująca zmiany pola 'state' (np. zmianę wartości na 102 lub 103, zależnie od konfiguracji).

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Rozpoczęcie wniosku o zmianę
Powiązanie wniosku o zmianę (RFC) z rekordem problemu. Oznacza przekazanie sprawy z zarządzania problemami do zarządzania zmianą w celu wdrożenia poprawki.
Dlaczego to ważne

Niezbędne do dashboardu efektywności przekazywania wniosków o zmianę. Pozwala wykryć opóźnienia między ustaleniem poprawki a rozpoczęciem procesu zmiany.

Skąd pobrać

Tabela ServiceNow 'sys_audit' rejestrująca uzupełnienie pola referencyjnego 'rfc' w tabeli 'problem'.

Rejestrowanie

Rejestrowane po wykonaniu transakcji Create Normal Change

Typ zdarzenia explicit
Ustalenie obejścia problemu
Wprowadzenie tekstu w polu 'Workaround' rekordu problemu. Rejestruje moment udokumentowania rozwiązania tymczasowego przez analityka.
Dlaczego to ważne

Umożliwia pomiar skuteczności publikowania obejść w dashboardzie, wskazując, kiedy po raz pierwszy znane było rozwiązanie techniczne.

Skąd pobrać

Tabela ServiceNow 'sys_audit', w której wartość 'fieldname' to 'workaround'.

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Ustalenie przyczyny źródłowej
Moment uzupełnienia kodów 'Root Cause' lub zmiany stanu na 'Fix in Progress'. Oznacza pomyślne zdiagnozowanie problemu.
Dlaczego to ważne

Pozwala obliczyć średni czas ustalenia przyczyny źródłowej i zasila dashboard czasu analizy przyczyny źródłowej. To ważny etap procesu.

Skąd pobrać

Tabela ServiceNow 'sys_audit' rejestrująca zmiany pola kategorii 'root_cause' lub przejście do stanu 'Fix in Progress'.

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Utworzenie rekordu problemu
Utworzenie rekordu problemu w systemie ServiceNow. To początek cyklu zarządzania problemem i punkt odniesienia dla pomiaru wieku rekordu.
Dlaczego to ważne

Wyznacza początek pomiaru czasu cyklu i SLA. Jest podstawą do określenia liczby nowych analiz problemów.

Skąd pobrać

Tabela ServiceNow 'problem', pole 'sys_created_on'.

Rejestrowanie

Rejestrowane po wykonaniu transakcji New Record

Typ zdarzenia explicit
Wdrożenie trwałej poprawki
Moment oznaczenia problemu jako Resolved, często po zamknięciu powiązanego wniosku o zmianę. Oznacza zakończenie prac technicznych.
Dlaczego to ważne

Wyznacza koniec aktywnego cyklu wdrażania poprawki. Służy do obliczenia całkowitego czasu rozwiązania w odniesieniu do SLA.

Skąd pobrać

Tabela ServiceNow 'sys_audit', zmiana pola 'state' na 'Resolved' (zwykle wartość 106).

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Zamknięcie rekordu problemu
Końcowe zdarzenie cyklu życia, po którym rekord staje się nieaktywny. Nie przewiduje się dalszych działań.
Dlaczego to ważne

Ostateczny koniec instancji procesu. Niezbędny do obliczenia całkowitego czasu cyklu.

Skąd pobrać

Tabela ServiceNow 'problem', pole 'closed_at' lub zmiana pola 'state' na 'Closed'.

Rejestrowanie

Rejestrowane po wykonaniu transakcji Close Problem

Typ zdarzenia explicit
Odrzucenie oceny
Rekord problemu wraca do poprzedniego stanu lub zostaje anulowany na etapie oceny, ponieważ sprawa nie spełnia kryteriów problemu.
Dlaczego to ważne

Wykrywa straty wynikające z błędnego kwalifikowania incydentów jako problemów.

Skąd pobrać

Tabela ServiceNow 'sys_audit', zmiana pola 'state' ze stanu 'Assess' na 'Closed/Cancelled' lub 'New'.

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Opublikowanie obejścia problemu
Wykonanie działania 'Communicate Workaround', które przekazuje obejście do powiązanych incydentów lub tworzy artykuł o znanym błędzie. To osobne działanie, niezależne od samego wpisania treści obejścia.
Dlaczego to ważne

Niezbędne do pomiaru szybkości udostępniania wiedzy. Opóźnienia na tym etapie bezpośrednio zwiększają liczbę powtarzających się incydentów.

Skąd pobrać

Tabela ServiceNow 'sys_journal_field' lub dzienniki określonych działań interfejsu. Zdarzenie można też wywnioskować z utworzenia rekordu 'kb_knowledge' typu 'Known Error'.

Rejestrowanie

Rejestrowane po wykonaniu transakcji Communicate Workaround

Typ zdarzenia explicit
Przygotowanie projektu rozwiązania
Wprowadzenie danych w polach 'Fix Notes' lub 'Resolution Code'. Oznacza, że analityk przeszedł od ustalenia przyczyny do opracowania trwałej poprawki.
Dlaczego to ważne

Umożliwia analizę czasu przygotowania projektu rozwiązania i wdrożenia poprawki w dashboardzie.

Skąd pobrać

Tabela ServiceNow 'sys_audit' rejestrująca aktualizacje pola 'fix_notes'.

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Weryfikacja rozwiązania
Etap sprawdzenia, czy rozwiązanie działa. W zależności od dojrzałości procesu może być oznaczony osobnym stanem lub polem wyboru.
Dlaczego to ważne

Zapewnia kontrolę jakości przed zamknięciem. Pominięcie tego etapu pozwala analizować odstępstwa od procesu.

Skąd pobrać

Tabela ServiceNow 'sys_audit'. Może to być zmiana stanu (Resolved -> Closed) lub zmiana skonfigurowanego pola 'u_resolution_verified'.

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Zakończenie przeglądu po wdrożeniu
Zakończenie zadania PIR lub ustawienie flagi PIR. Potwierdza przeprowadzenie analizy po zakończeniu poważnego problemu.
Dlaczego to ważne

Bezpośrednio zasila dashboard zgodności przeglądów po wdrożeniu. Brak tego działania w przypadku problemów o wysokim priorytecie wskazuje na niezgodność z wymaganiami.

Skąd pobrać

Zamknięcie rekordu w tabeli ServiceNow 'problem_task' (type=PIR) lub zmiana pola 'pir_state' w tabeli 'problem'.

Rejestrowanie

Ustalenie przez porównanie pól X i Y

Typ zdarzenia inferred
Zmiana stanu na Fix in Progress
Zmiana stanu rekordu oznacza, że trwa przygotowanie lub wdrażanie poprawki, często w oczekiwaniu na działania zespołu zarządzania zmianą.
Dlaczego to ważne

Pozwala odróżnić czas aktywnej analizy od czasu oczekiwania na zmianę i dokładniej wykrywać wąskie gardła.

Skąd pobrać

Tabela ServiceNow 'sys_audit', zmiana pola 'state' na 'Fix in Progress' (zwykle wartość 104).

Rejestrowanie

Porównanie wartości pola stanu przed zmianą i po niej

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z modułu zarządzania problemami w ServiceNow

Gotowi do rozpoczęcia?

Pobierz pełny szablon i już dziś zacznij przekształcać dane dotyczące zarządzania problemami w konkretne wnioski. Nasz zespół pomoże Państwu na każdym etapie pracy z process mining.

Usprawnij zarządzanie problemami, aby szybciej je rozwiązywać

Skróć cykl analizy o 30% dzięki process mining

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.