Szablon danych dotyczących zarządzania incydentami

BMC Helix ITSM
Szablon danych dotyczących zarządzania incydentami

Szablon danych dotyczących zarządzania incydentami

Ten szablon zawiera wskazówki dotyczące gromadzenia danych potrzebnych do optymalizacji procesu zarządzania incydentami. Wskazuje atrybuty i działania, które warto śledzić, oraz opisuje, jak wyodrębnić te dane. Ułatwia przygotowanie danych i przyspiesza analizę procesu.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia w procesie
  • Wskazówki dotyczące wyodrębniania danych z systemu
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zarządzania incydentami

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie przeanalizować proces zarządzania incydentami.
3 Wymagane 8 Zalecane 10 Opcjonalne
Nazwa Opis
Identyfikator incydentu
IncidentId
Unikalny identyfikator rekordu incydentu.
Opis

Incident ID jest głównym identyfikatorem każdego incydentu. Pozwala odróżnić go od momentu utworzenia do zamknięcia i łączy wszystkie powiązane czynności, dzienniki oraz zmiany, zapewniając pełny obraz cyklu życia incydentu.

W process mining ten atrybut ma podstawowe znaczenie, ponieważ określa case. Wszystkie zdarzenia z tym samym Incident ID należą do tej samej instancji procesu. Dzięki temu można odtworzyć i przeanalizować sposób obsługi poszczególnych incydentów.

Dlaczego to ważne

To podstawowy identyfikator case, który łączy wszystkie zdarzenia w cyklu życia incydentu i umożliwia analizę procesu od początku do końca.

Skąd pobrać

To pole 'Incident Number' (Field ID: 1000000161) w formularzu 'HPD:Help Desk'.

Przykłady
INC000001234567INC000002345678INC000003456789
Nazwa czynności
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w cyklu życia incydentu.
Opis

Ten atrybut opisuje czynność wykonaną w określonym momencie obsługi incydentu, na przykład „Zgłoszenie incydentu”, „Przypisanie do grupy” lub „Rozwiązanie incydentu”. Czynności te tworzą mapę procesu.

Analiza ich kolejności i częstotliwości pokazuje rzeczywisty przebieg procesu, najczęstsze ścieżki i odstępstwa od standardowej procedury. Pozwala zrozumieć, jakie działania podejmuje się w celu rozwiązania incydentu.

Dlaczego to ważne

Czynności określają kroki na mapie procesu, umożliwiając wizualizację i analizę workflow zarządzania incydentami.

Skąd pobrać

Zwykle ustalane na podstawie zmian pól 'Status' (Field ID: 7) i 'Status_Reason' w formularzu 'HPD:Help Desk' lub danych z formularza 'HPD:Help Desk Audit Log'.

Przykłady
Zgłoszenie incydentuPrzypisanie do grupyWdrożenie rozwiązaniaZamknięcie incydentu
Znacznik czasu zdarzenia
EventTimestamp
Dokładna data i godzina wystąpienia czynności.
Opis

Ten znacznik czasu określa, kiedy wystąpiło konkretne zdarzenie w cyklu życia incydentu. Pozwala ustalić kolejność zdarzeń i odtworzyć przebieg procesu na podstawie surowych danych.

Znacznik czasu zdarzenia jest niezbędny do analiz opartych na czasie, w tym obliczania czasu między czynnościami, wykrywania wąskich gardeł, w których incydenty długo czekają, oraz mierzenia całkowitego czasu rozwiązania. Stanowi podstawę chronologiczną analizy procesu.

Dlaczego to ważne

Znacznik czasu określa chronologiczną kolejność zdarzeń. Jest niezbędny do obliczania czasu trwania, wykrywania wąskich gardeł i analizy przebiegu procesu.

Skąd pobrać

Pole 'Last Modified Date' (Field ID: 6) lub konkretne pola daty z formularza 'HPD:Help Desk'. W przypadku zdarzeń historycznych dane pochodzą z pola znacznika czasu w dzienniku audytu.

Przykłady
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
Czy ponownie otwarto
IsReopened
Flaga wskazująca, czy incydent ponownie otwarto po zmianie jego statusu na „Resolved”.
Opis

Ten atrybut logiczny ma wartość true, jeśli po oznaczeniu incydentu jako „Resolved” jego status zmienił się z powrotem na aktywny, na przykład „In Progress”. Oznacza to, że początkowe rozwiązanie było nieskuteczne lub niekompletne.

Jest to bezpośrednia miara ponownej pracy, wykorzystywana do obliczania KPI wskaźnika ponownej pracy przy obsłudze incydentów. Analiza ponownie otwartych incydentów pomaga wykrywać poprawki niskiej jakości, niewystarczające testy i powracające problemy, które nie zostały właściwie rozwiązane. Wspiera też dashboard ścieżek ponownej pracy i eskalacji.

Dlaczego to ważne

Bezpośrednio mierzy ponowną pracę i jakość rozwiązań. Wysoki odsetek ponownie otwartych incydentów wskazuje na nieskuteczne poprawki i słabości procesu.

Skąd pobrać

Wartość jest obliczana na podstawie kolejności działań dotyczących incydentu. Jeśli po działaniu „Incident Reopened” lub podobnym wystąpi działanie „Resolution Implemented”, flaga ma wartość true.

Przykłady
truefalse
Czy przekroczono SLA
IsSlaBreached
Flaga wskazująca, czy incydent rozwiązano po upływie terminu SLA.
Opis

Ten atrybut logiczny ma wartość true, jeśli czas rozwiązania incydentu przekroczył termin określony w SLA. Jednoznacznie wskazuje, czy dla danego incydentu dotrzymano ustalonego poziomu usług.

Flaga ta jest niezbędna do tworzenia dashboardu przeglądu realizacji SLA dla incydentów oraz obliczania KPI wskaźnika zgodności incydentów z SLA. Ułatwia analizę, ponieważ pozwala filtrować i agregować incydenty, dla których nie dotrzymano ustalonego poziomu usług, a następnie badać przyczyny przekroczeń.

Dlaczego to ważne

Flaga ułatwia analizę zgodności z SLA. Można szybko odfiltrować incydenty z przekroczonym terminem i zbadać ich przyczyny źródłowe.

Skąd pobrać

Wartość jest obliczana przez porównanie znacznika czasu zdarzenia „Incident Resolved” z wartością „SlaTargetDate”. Jeśli rozwiązanie nastąpiło po terminie, flaga ma wartość true.

Przykłady
truefalse
Kategoria incydentu
IncidentCategory
Klasyfikacja incydentu, często oparta na hierarchii wielopoziomowej.
Opis

Kategoryzacja incydentów zapewnia uporządkowany sposób ich klasyfikowania, zwykle z użyciem hierarchii wielopoziomowej, na przykład: poziom 1: sprzęt, poziom 2: laptop, poziom 3: bateria. Dane te są niezbędne do kierowania zgłoszeń, raportowania i analizy trendów.

W process mining kategoryzacja pozwala analizować osobno różne rodzaje incydentów. Dashboard dokładności kategoryzacji incydentów porównuje kategorie początkowe i końcowe. Dane te pomagają też wykrywać trendy na potrzeby dashboardu trendów przyczyn źródłowych.

Dlaczego to ważne

Kategoryzacja ułatwia prawidłowe kierowanie zgłoszeń, analizę trendów i porównywanie wyników dla różnych rodzajów incydentów.

Skąd pobrać

Są to pola „Operational Categorization Tier 1/2/3” w formularzu „HPD:Help Desk”.

Przykłady
Sprzęt > Laptop > BateriaOprogramowanie > Aplikacja firmowa > Błąd logowaniaSieć > Łączność > Wi-Fi
Osoba przypisana
Assignee
Użytkownik przypisany do obsługi incydentu.
Opis

Osoba przypisana to konkretny agent wsparcia lub technik odpowiedzialny za incydent w danym momencie. Atrybut ten zapewnia dokładniejsze informacje niż przypisana grupa.

Analiza wyników pracy poszczególnych osób pomaga wskazać najlepszych pracowników, osoby wymagające dodatkowego szkolenia oraz nierównomierny podział obciążenia. Umożliwia też odtworzenie dokładnej kolejności działań podjętych przez poszczególne osoby przy obsłudze złożonego incydentu.

Dlaczego to ważne

Pozwala szczegółowo analizować podział obciążenia i wyniki pracy poszczególnych osób, a także wskazać najlepszych pracowników i osoby potrzebujące wsparcia.

Skąd pobrać

To pole „Assignee” (identyfikator pola: 1000000218) w formularzu „HPD:Help Desk”.

Przykłady
Bob SmithAlice JohnsonCharlie Brown
Priorytet
Priority
Poziom priorytetu przypisany do incydentu, który określa pilność jego obsługi.
Opis

Priorytet jest zwykle ustalany na podstawie wpływu i pilności incydentu. Określa kolejność i tempo jego rozwiązywania. Typowe wartości obejmują zakres od „Krytyczny” do „Niski”.

W process mining analiza incydentów według priorytetu ma zasadnicze znaczenie dla oceny wyników. Pomaga odpowiedzieć na pytania: „Czy dotrzymujemy SLA dla incydentów o wysokim priorytecie?” i „Czy incydenty o niskim priorytecie czekają dłużej?”. Filtrowanie według priorytetu pozwala skupić analizę na najważniejszych problemach biznesowych.

Dlaczego to ważne

Ten atrybut pozwala dzielić analizę na segmenty, aby incydenty o wysokim priorytecie były obsługiwane szybciej i zgodnie z przypisanymi im celami SLA.

Skąd pobrać

To pole „Priority” (identyfikator pola: 1000000164) w formularzu „HPD:Help Desk”.

Przykłady
KrytycznyWysokiŚredniNiski
Przypisana grupa
AssignedGroup
Grupa wsparcia odpowiedzialna za obsługę incydentu.
Opis

Ten atrybut wskazuje zespół lub dział przypisany do incydentu, na przykład „Service Desk”, „Zespół sieciowy” lub „Administratorzy baz danych”. Śledzenie przypisań pozwala zrozumieć przepływ pracy między zespołami.

Atrybut ten służy do analizy przekazywania spraw między zespołami, wykrywania wąskich gardeł powodowanych przez konkretne grupy oraz pomiaru wskaźnika ponownych przypisań incydentów. Pokazuje, jak incydent przechodzi przez organizację, i wskazuje problemy z kierowaniem spraw lub braki w wiedzy.

Dlaczego to ważne

Informacja o przypisanej grupie pozwala analizować przekazywanie spraw, wykrywać pętle ponownych przypisań i wskazywać wąskie gardła w poszczególnych zespołach.

Skąd pobrać

To pole „Assigned Group” (identyfikator pola: 1000000217) w formularzu „HPD:Help Desk”.

Przykłady
Service DeskOperacje siecioweWsparcie aplikacji, poziom 2Usługi infrastrukturalne
Status incydentu
IncidentStatus
Bieżący lub historyczny status incydentu w chwili wystąpienia zdarzenia.
Opis

Ten atrybut określa stan incydentu, na przykład 'New', 'In Progress', 'Pending', 'Resolved' lub 'Closed'. Pokazuje, na jakim etapie cyklu życia znajduje się incydent.

Analiza zmian statusu ma podstawowe znaczenie dla zrozumienia procesu zarządzania incydentami. Pozwala definiować czynności, mierzyć czas spędzony w poszczególnych stanach, na przykład 'Pending', oraz wykrywać incydenty, które utknęły lub pozostają nieaktywne.

Dlaczego to ważne

Śledzenie zmian statusu pozwala zrozumieć przebieg obsługi incydentu i zmierzyć czas spędzony w określonych stanach, takich jak 'Pending' lub 'In Progress'.

Skąd pobrać

To pole 'Status' (Field ID: 7) w formularzu 'HPD:Help Desk'.

Przykłady
NowyPrzypisanyW tokuOczekujeRozwiązanyZamknięty
Usługa
Service
Usługa biznesowa lub techniczna, której dotyczy incydent.
Opis

Ten atrybut łączy incydent z konkretną usługą zdefiniowaną w bazie danych zarządzania konfiguracją (CMDB), na przykład „Poczta firmowa”, „Dostęp VPN” lub „SAP Financials”.

Powiązanie to pozwala określić wpływ incydentów na działalność firmy. Analiza incydentów według usług pomaga wykrywać usługi generujące dużą liczbę zgłoszeń, wskazywać powtarzające się problemy związane z konkretnymi technologiami oraz analizować trendy na potrzeby zarządzania problemami.

Dlaczego to ważne

Powiązanie incydentów z usługami biznesowymi ułatwia analizę ich wpływu i wskazanie usług najczęściej dotkniętych problemami.

Skąd pobrać

To pole „ServiceCI” lub podobne, wskazujące element konfiguracji (CI), którego dotyczy problem, w formularzu „HPD:Help Desk”.

Przykłady
Poczta firmowaSAP ERPZdalny dostęp VPNPortal kadr i płac
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio odświeżone z systemu źródłowego.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego wyodrębnienia danych. Informuje, jak aktualne są analizowane dane, co pozwala ocenić, na ile bieżące są wnioski dotyczące procesu.

Znajomość czasu ostatniej aktualizacji jest ważna przy raportowaniu i korzystaniu z dashboardów. Użytkownicy wiedzą dzięki niej, jak aktualne są dane i czy obejmują najnowsze czynności związane z incydentami.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak bieżąca jest analiza procesu i wynikające z niej wnioski.

Skąd pobrać

Ta wartość jest zwykle generowana i zapisywana w zbiorze danych podczas procesu ich wyodrębniania (ETL).

Przykłady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
Kanał zgłoszenia
Channel
Sposób zgłoszenia incydentu.
Opis

Ten atrybut określa, w jaki sposób zgłoszono incydent, na przykład telefonicznie, e-mailem, przez portal samoobsługowy lub osobiście. Wskazuje, jak incydent trafił do procesu wsparcia.

Analiza incydentów według kanału może pokazać, które sposoby zgłaszania są najskuteczniejsze oraz które prowadzą do zgłoszeń łatwiejszych lub trudniejszych do rozwiązania. Może też pomóc w podjęciu decyzji o inwestycjach w automatyzację lub szkolenia użytkowników, na przykład w promowaniu portalu samoobsługowego, który pozwala zebrać więcej informacji już na początku.

Dlaczego to ważne

Informacja o kanale zgłoszenia ułatwia ocenę skuteczności różnych sposobów przyjmowania zgłoszeń i może pomóc w planowaniu inwestycji w samoobsługę lub automatyzację.

Skąd pobrać

To pole „Reported Source” (identyfikator pola: 1000000215) w formularzu „HPD:Help Desk”.

Przykłady
E-mailTelefonSamoobsługaZgłoszenie bezpośrednie
Kod zamknięcia
CloseCode
Kod wybierany przy zamykaniu incydentu, określający wynik jego rozwiązania.
Opis

Kod zamknięcia w uporządkowany sposób opisuje sposób rozwiązania incydentu. Przykłady: „Rozwiązany przez użytkownika”, „Nie znaleziono usterki”, „Duplikat incydentu” lub „Wdrożono trwałą poprawkę”.

Atrybut ten pomaga analizować skuteczność i wyniki rozwiązywania incydentów. Pozwala wykrywać zgłoszenia zamknięte bez faktycznego usunięcia problemu oraz kategorie, w których użytkownicy często sami rozwiązują swoje problemy. Może to wskazywać na potrzebę przygotowania lepszych artykułów w bazie wiedzy lub narzędzi samoobsługowych.

Dlaczego to ważne

Dostarcza uporządkowanych danych o wynikach rozwiązywania incydentów, co ułatwia ocenę skuteczności poprawek i analizę sposobów zamykania zgłoszeń.

Skąd pobrać

Zwykle jest to część informacji o rozwiązaniu lub zamknięciu w formularzu „HPD:Help Desk”.

Przykłady
Rozwiązano zdalnieDuplikat zgłoszeniaBłąd użytkownikaNie wymaga działania
Liczba ponownych przypisań
ReassignmentCount
Łączna liczba przypisań incydentu do innej grupy.
Opis

Ta miara zlicza zmiany wartości pola „AssignedGroup” w trakcie obsługi incydentu. Wysoka wartość może wskazywać na problemy z początkowym kierowaniem zgłoszeń, niski odsetek rozwiązań przy pierwszym kontakcie lub złożone problemy wymagające udziału wielu zespołów.

Atrybut ten bezpośrednio wspiera KPI wskaźnika ponownych przypisań incydentów oraz dashboard analizy cyklu ponownych przypisań. Pozwala zmierzyć efekt „przerzucania” zgłoszeń między zespołami, który powoduje znaczne opóźnienia i obniża sprawność procesu.

Dlaczego to ważne

Pozwala mierzyć problemy z kierowaniem zgłoszeń i przekazywaniem ich między zespołami, a także wykrywać incydenty krążące między grupami w pętli ponownych przypisań.

Skąd pobrać

Wartość jest obliczana przez zliczenie zmian pola „AssignedGroup” dla danego identyfikatora incydentu w dzienniku zdarzeń.

Przykłady
0135
Opis rozwiązania
Resolution
Opis kroków podjętych w celu rozwiązania incydentu, wprowadzany jako tekst dowolny.
Opis

To pole zawiera szczegółowy opis końcowego rozwiązania, napisany przez osobę obsługującą zgłoszenie. Wyjaśnia, co zrobiono, aby usunąć problem i przywrócić użytkownikowi dostęp do usługi.

Mimo że dane te nie mają ustalonej struktury, można analizować je metodami eksploracji tekstu, aby wykrywać typowe sposoby rozwiązywania problemów, wyszukiwać słowa kluczowe związane z konkretnymi problemami lub uzupełniać analizę przyczyn źródłowych. Zapewniają kontekst jakościowy, którego często brakuje w polach o ustalonej strukturze.

Dlaczego to ważne

Zawiera jakościowy opis rozwiązania, który można analizować metodami eksploracji tekstu, aby wykrywać wzorce niewidoczne w danych o ustalonej strukturze.

Skąd pobrać

To pole „Resolution” (identyfikator pola: 1000000156) w formularzu „HPD:Help Desk”.

Przykłady
Hasło użytkownika zresetowano w usłudze Active Directory.Wyczyszczono pamięć podręczną i pliki cookie w przeglądarce, co rozwiązało problem z logowaniem.Uruchomiono ponownie przełącznik sieciowy w szafie IDF 3B.
Przyczyna źródłowa
RootCause
Podstawowa lub ostateczna przyczyna incydentu.
Opis

Przyczyna źródłowa to podstawowy problem, którego usunięcie zapobiegłoby ponownemu wystąpieniu incydentu. Zwykle ustala się ją w ramach powiązanego procesu analizy problemu.

Nie każdy incydent ma udokumentowaną przyczynę źródłową, ale analiza tego atrybutu jest niezbędna do proaktywnego zarządzania problemami. Wspiera KPI wskaźnika identyfikacji przyczyn źródłowych i pomaga tworzyć dashboardy pokazujące trendy w powtarzających się problemach. Dzięki temu można planować wdrożenie trwałych rozwiązań.

Dlaczego to ważne

Ustalenie przyczyny źródłowej jest niezbędne do zarządzania problemami i ograniczania liczby powtarzających się incydentów.

Skąd pobrać

Informacja ta może znajdować się w osobnym polu „Root Cause” w zgłoszeniu incydentu lub, częściej, w powiązanym formularzu „PBI:Problem Investigation”.

Przykłady
Za mało miejsca na dysku serweraBłąd konfiguracji sieciBłąd oprogramowania w wersji 2.1Wygasły certyfikat bezpieczeństwa
System źródłowy
SourceSystem
System, z którego wyodrębniono dane o incydentach.
Opis

Ten atrybut wskazuje źródło danych. Jest szczególnie przydatny w środowiskach korzystających z kilku narzędzi ITSM lub zintegrowanych systemów. Potwierdza, że dane pochodzą z oczekiwanego źródła, na przykład konkretnej instancji BMC Helix ITSM.

W analizie pomaga odróżnić procesy i cechy danych, które mogą się różnić między systemami produkcyjnymi, deweloperskimi i starszymi. Ułatwia też weryfikację pochodzenia danych.

Dlaczego to ważne

Wskazuje źródło danych, co ma zasadnicze znaczenie dla ich weryfikacji i prowadzenia analiz obejmujących wiele zintegrowanych systemów.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas procesu wyodrębniania, przekształcania i ładowania danych (ETL).

Przykłady
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
Termin realizacji SLA
SlaTargetDate
Data i godzina, do której należy rozwiązać incydent zgodnie z SLA.
Opis

Ten atrybut przechowuje termin rozwiązania incydentu określony w obowiązującej umowie o gwarantowanym poziomie świadczenia usług (SLA). Termin jest obliczany na podstawie priorytetu incydentu i ustalonych godzin świadczenia usług.

Ten znacznik czasu stanowi punkt odniesienia przy pomiarze rzeczywistego czasu rozwiązania incydentu. Jest niezbędny do obliczania KPI wskaźnika zgodności incydentów z SLA oraz tworzenia dashboardów pokazujących realizację SLA. Umożliwia też monitorowanie incydentów, których termin realizacji zbliża się do końca.

Dlaczego to ważne

To punkt odniesienia przy ocenie zgodności z SLA. Pozwala ustalić, czy incydent rozwiązano w terminie, czy przekroczono ustalony czas.

Skąd pobrać

Dane te są zwykle przechowywane w formularzu „SLM:Measurement” i powiązane z incydentem. Nie są bezpośrednim polem formularza „HPD:Help Desk”.

Przykłady
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
Wpływ
Impact
Miara wpływu incydentu na procesy biznesowe.
Opis

Wpływ określa skalę negatywnych skutków incydentu dla działalności firmy. Często opisuje się go za pomocą skali, na przykład: „rozległy/powszechny”, „znaczący/duży”, „umiarkowany/ograniczony” lub „niewielki/lokalny”.

W połączeniu z pilnością wpływ określa priorytet incydentu. Analiza według wpływu pomaga ustalić, które incydenty najbardziej zakłócają działalność firmy, niezależnie od ich złożoności technicznej. Ułatwia to ustalanie priorytetów działań na rzecz ulepszania procesów.

Dlaczego to ważne

Pozwala określić skalę skutków incydentu dla firmy. Wpływ jest jednym z czynników ustalania priorytetu i pomaga skupić analizę na problemach o największych konsekwencjach.

Skąd pobrać

To pole „Impact” (identyfikator pola: 1000000163) w formularzu „HPD:Help Desk”.

Przykłady
1 - Rozległy/powszechny2 - Znaczący/duży3 - Umiarkowany/ograniczony4 - Niewielki/lokalny
Zgłaszający
Submitter
Osoba, która jako pierwsza zgłosiła incydent.
Opis

Zgłaszający to użytkownik końcowy lub klient, który napotkał problem i go zgłosił. Nie należy go mylić z osobą przypisaną do obsługi incydentu.

Analiza danych według zgłaszającego lub jego działu pomaga wskazać grupy użytkowników, które mogą potrzebować dodatkowych szkoleń, oraz grupy dotknięte konkretnym rodzajem problemu. Zapewnia to perspektywę użytkownika w analizie procesu obsługi incydentów.

Dlaczego to ważne

Wskazuje użytkownika, który zgłosił problem. Umożliwia analizę według działu, lokalizacji lub roli, aby wykrywać trendy dotyczące konkretnych grup użytkowników.

Skąd pobrać

Informacja ta jest zapisywana w polu „Submitter” lub w polach dotyczących klienta w formularzu „HPD:Help Desk”.

Przykłady
John DoeJane SmithPeter Jones
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania incydentami

To najważniejsze kroki i kamienie milowe procesu, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkryć proces i zobrazować jego przebieg.
5 Zalecane 9 Opcjonalne
Działanie Opis
Przypisanie do grupy
Ta czynność oznacza pierwsze przypisanie incydentu do konkretnej grupy wsparcia w celu jego zbadania. Jest ustalana na podstawie pierwszego wypełnienia pola 'Assigned Group' po utworzeniu incydentu.
Dlaczego to ważne

To ważny etap oznaczający rozpoczęcie aktywnej pracy nad incydentem. Czas do pierwszego przypisania ma zasadnicze znaczenie przy ocenie czasu reakcji i skuteczności wstępnego kierowania zgłoszeń.

Skąd pobrać

Ustalane na podstawie dziennika audytu ('HPD:HelpDesk_AuditLogSystem') formularza 'HPD:Help Desk', który rejestruje pierwsze wypełnienie pola 'Assigned Group'.

Rejestrowanie

Na podstawie znacznika czasu pierwszego wypełnienia pola 'Assigned Group'.

Typ zdarzenia inferred
Rozpoczęcie analizy
Oznacza, że pracownik wsparcia rozpoczął aktywną pracę nad incydentem. Zdarzenie jest zwykle ustalane na podstawie zmiany statusu z 'Assigned' na 'In Progress'.
Dlaczego to ważne

Ten etap oznacza przejście od oczekiwania w kolejce do aktywnej diagnozy. Analiza czasu oczekiwania na rozpoczęcie pracy pomaga wykrywać wąskie gardła związane z zasobami i wspiera dashboard „Wąskie gardła w diagnozie i analizie”.

Skąd pobrać

Ustalane na podstawie zmiany statusu w formularzu 'HPD:Help Desk'. Zdarzenie występuje, gdy pole 'Status' zmienia się na 'In Progress'; znacznik czasu pochodzi z dziennika audytu.

Rejestrowanie

Ustalane na podstawie zmiany statusu na 'In Progress' w HPD:HelpDesk_AuditLogSystem.

Typ zdarzenia inferred
Rozwiązanie incydentu
Ta czynność oznacza formalne rozwiązanie incydentu z perspektywy service desku, przed jego ostatecznym zamknięciem. Jest rejestrowana, gdy status incydentu zostaje ustawiony na 'Resolved'.
Dlaczego to ważne

To najważniejszy etap przy pomiarze zgodności z SLA i czasu rozwiązania incydentu. Oznacza przywrócenie użytkownikowi dostępu do usługi.

Skąd pobrać

Zdarzenie odpowiada ustawieniu pola 'Status' na 'Resolved' w formularzu 'HPD:Help Desk'. Znacznik czasu jest zapisywany w polu 'Last Resolved Date' i dzienniku audytu.

Rejestrowanie

Na podstawie znacznika czasu zmiany statusu na 'Resolved' w dzienniku audytu.

Typ zdarzenia inferred
Zamknięcie incydentu
To ostatnia czynność, która oznacza formalne zamknięcie rekordu incydentu po potwierdzeniu rozwiązania lub upływie okresu oczekiwania na potwierdzenie. Jest rejestrowana, gdy status zostaje ustawiony na 'Closed'.
Dlaczego to ważne

To końcowe zdarzenie w cyklu życia incydentu. Czas między zmianą statusu na 'Resolved' i 'Closed' obejmuje oczekiwanie na potwierdzenie użytkownika oraz czynności administracyjne.

Skąd pobrać

Zdarzenie odpowiada ustawieniu pola 'Status' na 'Closed' w formularzu 'HPD:Help Desk'. Znacznik czasu jest zapisywany w polu 'Closed Date' i dzienniku audytu.

Rejestrowanie

Na podstawie znacznika czasu z pola 'Closed Date' lub zmiany statusu na 'Closed'.

Typ zdarzenia inferred
Zgłoszenie incydentu
Ta czynność oznacza utworzenie rekordu incydentu w systemie. Jest rejestrowana na podstawie znacznika czasu utworzenia incydentu w głównym formularzu zarządzania incydentami.
Dlaczego to ważne

To główne zdarzenie rozpoczynające cykl życia incydentu. Jest niezbędne do obliczania całkowitego czasu rozwiązania i analizy liczby napływających incydentów.

Skąd pobrać

Zdarzenie odpowiada utworzeniu rekordu w formularzu 'HPD:Help Desk'. Znacznik czasu pochodzi zwykle z pola 'Submit Date' lub 'Reported Date'.

Rejestrowanie

Na podstawie znacznika czasu z pola 'Submit Date' w formularzu HPD:Help Desk.

Typ zdarzenia explicit
Anulowanie incydentu
Ta czynność oznacza zakończenie obsługi incydentu utworzonego przez pomyłkę lub nieaktualnego. Jest rejestrowana, gdy status incydentu zostaje ustawiony na 'Cancelled'.
Dlaczego to ważne

To końcowy stan incydentu, odrębny od jego pomyślnego rozwiązania. Analiza anulowanych incydentów może ujawnić problemy z kanałami zgłoszeń lub powielonymi zgłoszeniami.

Skąd pobrać

Ustalane na podstawie formularza 'HPD:Help Desk', gdy pole 'Status' zostaje zmienione na 'Cancelled'. Znacznik czasu jest zapisywany w dzienniku audytu.

Rejestrowanie

Ustalane na podstawie zmiany statusu na 'Cancelled' w dzienniku audytu.

Typ zdarzenia inferred
Kategoryzacja incydentu
Oznacza moment, w którym incydent otrzymuje kategorie operacyjne i produktowe oraz priorytet. Zdarzenie jest zwykle ustalane na podstawie wypełnienia lub ostatniej modyfikacji pól kategoryzacji.
Dlaczego to ważne

Prawidłowa i terminowa kategoryzacja ma zasadnicze znaczenie dla sprawnego kierowania incydentów i raportowania. Analiza tej czynności pomaga wykrywać opóźnienia i błędy na etapie wstępnej selekcji oraz wspiera dashboard „Dokładność kategoryzacji incydentów”.

Skąd pobrać

Ustalane na podstawie dziennika audytu ('HPD:HelpDesk_AuditLogSystem'), który rejestruje zmiany pól takich jak 'Operational Categorization Tier 1-3', 'Product Categorization Tier 1-3' i 'Priority' w formularzu 'HPD:Help Desk'.

Rejestrowanie

Na podstawie znacznika czasu ostatniej zmiany pól kategoryzacji lub priorytetu po utworzeniu incydentu.

Typ zdarzenia inferred
Naruszenie SLA
To zdarzenie obliczane, które występuje, gdy czas rozwiązania incydentu przekracza wyznaczony limit umowy SLA. Jest ustalane przez porównanie znacznika czasu rozwiązania z terminem SLA.
Dlaczego to ważne

Ta czynność ma zasadnicze znaczenie dla dashboardu „Przegląd realizacji SLA dla incydentów” i KPI „Wskaźnik zgodności z SLA dla incydentów”. Wskazuje incydenty, w przypadku których nie dotrzymano uzgodnionych warunków świadczenia usług.

Skąd pobrać

Obliczane przez porównanie pola 'Last Resolved Date' z polem 'Target Date' (terminem SLA) w formularzu 'HPD:Help Desk'. Jeśli incydent nie został jeszcze rozwiązany, można porównać termin z bieżącym czasem.

Rejestrowanie

Zdarzenie obliczane: występuje, gdy 'Last Resolved Date' > 'Target Date'.

Typ zdarzenia calculated
Oczekiwanie na informacje od użytkownika
Oznacza wstrzymanie obsługi incydentu w oczekiwaniu na informacje lub działanie użytkownika. Zdarzenie jest ustalane na podstawie zmiany statusu na 'Pending'.
Dlaczego to ważne

Ta czynność pozwala oddzielić czas pracy pracownika wsparcia od czasu oczekiwania na odpowiedź użytkownika. Analiza czasu w tym stanie pomaga ocenić, jak opóźnienia w odpowiedziach wpływają na całkowity czas rozwiązania incydentu.

Skąd pobrać

Ustalane na podstawie formularza 'HPD:Help Desk', gdy pole 'Status' zostaje zmienione na 'Pending'. Szczegółowa przyczyna znajduje się często w polu 'Status_Reason'.

Rejestrowanie

Ustalane na podstawie zmiany statusu na 'Pending' w HPD:HelpDesk_AuditLogSystem.

Typ zdarzenia inferred
Oczekiwanie na potwierdzenie użytkownika
Ten etap następuje po wdrożeniu rozwiązania, gdy zespół wsparcia czeka na potwierdzenie użytkownika, że problem został usunięty. Często odpowiada mu status 'Resolved', od którego rozpoczyna się odliczanie do automatycznego zamknięcia.
Dlaczego to ważne

Ta czynność ma zasadnicze znaczenie dla dashboardu „Opóźnienia w potwierdzeniu i weryfikacji przez użytkownika”. Pozwala zmierzyć czas od wdrożenia poprawki do jej zatwierdzenia przez użytkownika, który może niepotrzebnie wydłużać cykl życia incydentu.

Skąd pobrać

Ten stan rozpoczyna się, gdy pole 'Status' w formularzu 'HPD:Help Desk' zmienia się na 'Resolved'. Czas trwania mierzy się od daty 'Last Resolved Date' do zmiany statusu incydentu na 'Closed' lub 'Reopened'.

Rejestrowanie

Rozpoczyna się po zmianie statusu na 'Resolved', a kończy po zmianie na 'Closed' lub 'In Progress'.

Typ zdarzenia inferred
Otrzymanie potwierdzenia od użytkownika
Oznacza, że użytkownik potwierdził, iż otrzymane rozwiązanie usunęło problem. Może to być jawne zdarzenie albo zdarzenie ustalone na podstawie notatki lub powiązanej czynności w systemie przed zamknięciem incydentu.
Dlaczego to ważne

Śledzenie tego zdarzenia daje dokładniejszy obraz weryfikacji przez użytkownika niż samo oczekiwanie na automatyczne zamknięcie. Ułatwia pomiar KPI „Średni czas oczekiwania na potwierdzenie użytkownika” i wykrywanie problemów w komunikacji.

Skąd pobrać

Wiarygodne zarejestrowanie tego zdarzenia może być trudne. Można je ustalić na podstawie wpisu w dzienniku pracy lub zmiany przyczyny statusu tuż przed ustawieniem statusu incydentu na 'Closed'. Może być konieczna analiza formularza 'HPD:WorkLog'.

Rejestrowanie

Ustalane na podstawie konkretnych wpisów w dzienniku pracy lub zmian przyczyny statusu przed zamknięciem.

Typ zdarzenia inferred
Ponowne otwarcie incydentu
Oznacza incydent, który wcześniej uznano za rozwiązany, ale ponownie uruchomiono, ponieważ problem nadal występuje. Zdarzenie jest ustalane na podstawie zmiany statusu z 'Resolved' na aktywny, na przykład 'In Progress' lub 'Assigned'.
Dlaczego to ważne

Ta czynność bezpośrednio mierzy ponowną pracę i skuteczność pierwszego rozwiązania. Duża liczba ponownie otwieranych incydentów wskazuje na niską jakość poprawek i jest uwzględniana w KPI „Wskaźnik ponownej pracy przy incydentach”.

Skąd pobrać

Ustalane na podstawie dziennika audytu ('HPD:HelpDesk_AuditLogSystem') przez wykrycie zmiany pola 'Status' z 'Resolved' na 'In Progress' lub 'Assigned' dla danego Incident ID.

Rejestrowanie

Ustalane na podstawie zmiany statusu z 'Resolved' na stan aktywny.

Typ zdarzenia inferred
Przekazanie do innej grupy
Ta czynność występuje, gdy incydent zostaje przeniesiony z jednej grupy wsparcia do innej. Jest wykrywana na podstawie zmiany pola 'Assigned Group' po pierwszym przypisaniu.
Dlaczego to ważne

Częste przekazania mogą wskazywać na błędne wstępne kierowanie zgłoszeń lub braki w wiedzy. Śledzenie tej czynności jest niezbędne do analizy w dashboardzie „Analiza ponownych przypisań incydentów” oraz obliczania KPI „Wskaźnik ponownych przypisań incydentów”.

Skąd pobrać

Ustalane na podstawie dziennika audytu ('HPD:HelpDesk_AuditLogSystem') przez wykrywanie kolejnych zmian pola 'Assigned Group' w formularzu 'HPD:Help Desk' po jego pierwszym wypełnieniu.

Rejestrowanie

Wykrywanie zmian pola 'Assigned Group' po pierwszym przypisaniu.

Typ zdarzenia inferred
Wdrożenie rozwiązania
Ta czynność oznacza zastosowanie przez zespół wsparcia poprawki lub obejścia. Zdarzenie jest często ustalane na podstawie zmiany statusu incydentu na 'Resolved'.
Dlaczego to ważne

To ważny etap oznaczający dostarczenie rozwiązania. Jest istotnym punktem danych przy pomiarze czasu od zakończenia analizy do zastosowania poprawki.

Skąd pobrać

Zdarzenie jest zwykle ustalane na podstawie zmiany pola 'Status' na 'Resolved' w formularzu 'HPD:Help Desk'. Znacznik czasu jest zapisywany w polu 'Last Resolved Date' i dzienniku audytu.

Rejestrowanie

Na podstawie znacznika czasu z pola 'Last Resolved Date' lub zmiany statusu na 'Resolved'.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje wyodrębniania danych

Jak pobrać dane z BMC Helix ITSM

Gotowi, aby zacząć?

Wykorzystajcie ten szablon, aby rozpocząć process mining i odkryć przydatne informacje w danych dotyczących zarządzania incydentami. Zacznijcie usprawniać operacje już dziś.

Ogranicz powtarzające się incydenty w BMC Helix ITSM już dziś!

Skróć MTTR o 35% i wyeliminuj przekroczenia SLA, zwiększając zadowolenie użytkowników.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej. Okres próbny trwa 14 dni.