Szablon danych do zarządzania problemami
Szablon danych do zarządzania problemami
- Zalecane atrybuty do analizy przyczyn źródłowych
- Najważniejsze etapy i działania w procesie
- Instrukcja ekstrakcji danych z ServiceNow krok po kroku
Atrybuty zarządzania problemami
| 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
|
|||
Działania w procesie zarządzania problemami
| 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
|
|||
Instrukcje ekstrakcji danych
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
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.