Szablon danych do zarządzania problemami

BMC Helix ITSM
Szablon danych do zarządzania problemami

Szablon danych do zarządzania problemami

Szablon zawiera strukturę do analizy workflow badania przyczyn źródłowych w BMC Helix ITSM. Opisuje niezbędne atrybuty i działania w procesie, które pozwalają zbudować szczegółowy dziennik zdarzeń, a także praktyczne wskazówki dotyczące eksportu danych. Korzystając z tego przewodnika, można wykryć ukryte wąskie gardła i usprawnić proces trwałego rozwiązywania incydentów.
  • Podstawowe pola danych do analizy przyczyn źródłowych
  • Standardowe etapy procesu do monitorowania
  • Wskazówki dotyczące eksportu danych z BMC Helix ITSM
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zarządzania problemami

Tabela zawiera zalecane pola danych potrzebne do utworzenia dziennika zdarzeń i szczegółowej analizy cyklu zarządzania problemami.
5 Wymagane 9 Zalecane 5 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Znacznik czasu wskazujący, kiedy wystąpiła dana czynność.
Opis

Ten atrybut zapisuje dokładną datę i godzinę wykonania czynności. W BMC Helix ITSM odpowiada polom takim jak „Submit Date” i „Last Modified Date” lub znacznikom czasu zmian statusu zapisanym w tabelach historii.

W analizie służy do ustalania chronologicznej kolejności zdarzeń i obliczania czasu ich trwania. Umożliwia pomiar czasu między dowolnymi punktami procesu, na przykład „Investigation Cycle Time” lub „Workaround Publication Lead Time”.

Dokładne znaczniki czasu są niezbędne do wykrywania wąskich gardeł. Obliczenie różnicy czasu między kolejnymi zdarzeniami pozwala wskazać, gdzie dokładnie występują opóźnienia, na przykład podczas wstępnego przypisania lub końcowego przeglądu.

Dlaczego to ważne

Umożliwia obliczanie wszystkich KPI opartych na czasie trwania oraz ustalanie kolejności zdarzeń.

Skąd pobrać

Tabele historii lub dzienniki audytu powiązane z PBM:Problem Investigation

Przykłady
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
Czynność
Activity
Konkretne zadanie lub zdarzenie polegające na zmianie statusu.
Opis

Ten atrybut opisuje konkretny krok w cyklu zarządzania problemem, na przykład „Zarejestrowanie rekordu problemu”, „Ustalenie przyczyny źródłowej” lub „Aktualizacja bazy rozwiązań”. W BMC Helix dane te są często wyprowadzane z historii statusów, dzienników audytu lub znaczników czasu transakcji w module Problem Investigation.

Ten atrybut stanowi podstawę odkrywania procesu. Analizując kolejność czynności, narzędzie process mining tworzy mapę procesu i pokazuje rzeczywisty przebieg pracy w porównaniu z zaprojektowanym procesem. Ujawnia pętle, poprawki i odstępstwa od standardowej procedury.

Dokładne nazwy czynności są niezbędne, aby zrozumieć, co faktycznie wydarzyło się w trakcie procesu. Dane te pozwalają mierzyć czas między poszczególnymi krokami, na przykład od ustalenia przyczyny źródłowej do rozpoczęcia wniosku o zmianę.

Dlaczego to ważne

Określa węzły na mapie procesu i umożliwia wizualizację workflow.

Skąd pobrać

Dane pochodzą z historii statusów PBM:Problem Investigation lub PBM:AuditLogSystem

Przykłady
Zarejestrowanie rekordu problemuPrzypisanie do grupy wsparciaRozpoczęcie analizyUstalenie przyczyny źródłowej
Rekord problemu
ProblemRecord
Unikalny identyfikator sprawy dotyczącej analizy problemu.
Opis

Ten atrybut pełni funkcję głównego identyfikatora sprawy w procesie zarządzania problemami. W BMC Helix ITSM jest to zazwyczaj pole „Problem ID” w formularzu PBM:Problem Investigation, na przykład PBI00000012345. Łączy wszystkie powiązane działania, od pierwszego zarejestrowania problemu po jego zamknięcie i przegląd po wdrożeniu.

W analizie process mining ten atrybut służy do grupowania poszczególnych zdarzeń w jedną instancję procesu. Dzięki niemu analitycy mogą prześledzić cały przebieg konkretnej analizy problemu. Bez tego identyfikatora nie dałoby się powiązać kolejnych działań różnych grup wsparcia i koordynatorów.

Pole to jest kluczem głównym dziennika zdarzeń i jest niezbędne do agregacji danych na poziomie sprawy, na przykład obliczania całkowitego czasu realizacji dla każdego problemu lub zliczania problemów według priorytetu.

Dlaczego to ważne

To podstawowy klucz potrzebny do utworzenia widoku procesu i śledzenia cyklu życia konkretnych problemów.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Problem ID”

Przykłady
PBI00000004512PBI00000004513PBI00000004514
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane zostały pobrane lub ostatnio odświeżone.
Opis

Ten atrybut wskazuje, kiedy dane zostały ostatnio załadowane do aplikacji process mining. Dzięki niemu analitycy wiedzą, jak aktualne są przeglądane dane. Wartość jest zwykle generowana przez skrypt ekstrakcji lub narzędzie do obsługi przepływu danych.

Pomaga uniknąć podejmowania decyzji na podstawie nieaktualnych danych. Jeśli na przykład kierownik analizuje otwarte rekordy problemów, informacja, że dane zaktualizowano godzinę temu, a nie tydzień temu, znacząco wpływa na ocenę bieżącego obciążenia pracą.

Atrybut ten służy również do przyrostowego ładowania danych. Śledząc czas ostatniej aktualizacji, proces ETL może pobierać tylko rekordy zmienione od poprzedniej ekstrakcji, co poprawia wydajność i zmniejsza obciążenie systemu.

Dlaczego to ważne

Pozwala ocenić aktualność danych i wspiera strategie ich przyrostowego ładowania.

Skąd pobrać

Czas systemowy w chwili ekstrakcji

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

Ten atrybut wskazuje system, z którego pobrano dane o procesie, w tym przypadku „BMC Helix ITSM”. Jest szczególnie ważny w środowiskach korzystających z wielu systemów, gdy process mining łączy dane z różnych narzędzi ITSM, programistycznych lub dostarczanych przez zewnętrznych dostawców.

W analizie pole to pełni funkcję metadanych potwierdzających pochodzenie rekordu. Jeśli widok procesu łączy dane z BMC Helix dotyczące zarządzania problemami z danymi z osobnego systemu programistycznego, na przykład Jira, atrybut ten pozwala podzielić analizę według systemu źródłowego.

Pomaga również w diagnozowaniu problemów technicznych. W razie wykrycia problemów z jakością danych znajomość systemu źródłowego pozwala inżynierom prześledzić ich przyczynę do konkretnego procesu ekstrakcji lub źródłowej bazy danych.

Dlaczego to ważne

Zapewnia możliwość śledzenia pochodzenia danych i kontekst, szczególnie w widokach procesów obejmujących wiele systemów.

Skąd pobrać

Wartość ustawiana na stałe podczas ekstrakcji danych

Przykłady
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
Czy przekroczono SLA
IsSLABreached
Flaga informująca, czy rozwiązanie problemu zajęło więcej czasu, niż dopuszcza SLA.
Opis

Ten atrybut logiczny informuje, czy dla rekordu problemu przekroczono termin SLA. Jest obliczany przez porównanie znacznika czasu „Resolution Verified” z terminem „SLA Due Date” albo pobierany bezpośrednio ze statusu SLM.

Atrybut ten zasila dashboard „SLA Compliance and Breach Trends”. Umożliwia prosty podział procesów na zgodne i niezgodne z SLA. Dzięki temu można łatwo wyodrębnić cechy nieudanych spraw, na przykład sprawdzić, czy przekroczenia terminu zawsze dotyczą grupy wsparcia X.

Jest też podstawowym filtrem przy analizie przyczyn źródłowych niepowodzeń procesu. Analitycy mogą wybrać „IsSLABreached = True”, a następnie sprawdzić na mapie procesu, gdzie stracono czas, na przykład podczas długiego oczekiwania na zgodę dostawcy.

Dlaczego to ważne

Ułatwia raportowanie zgodności z SLA i analizę niepowodzeń.

Skąd pobrać

Formularz SLM:Measurement lub wartość obliczana

Przykłady
truefalse
Grupa wsparcia
SupportGroup
Zespół techniczny aktualnie przypisany do analizy problemu.
Opis

Ten atrybut wskazuje grupę wsparcia, na przykład „Server Admin” lub „Database Support”, odpowiedzialną za rekord problemu w chwili wystąpienia zdarzenia. W BMC Helix odpowiada mu pole „Assigned Group”.

Atrybut ten jest niezbędny na dashboardach „Support Group Workload Distribution” i „Support Group Reassignment Analysis”. Analitycy mogą filtrować mapę procesu według zespołu, aby sprawdzić, które grupy obsługują najwięcej spraw i gdzie występują wąskie gardła w analizie problemów.

Analiza przekazań między grupami wsparcia pomaga wykryć efekt „ping-pong”, gdy zgłoszenie krąży między zespołami bez rozwiązania. Często wskazuje to na niejasny podział odpowiedzialności lub niewystarczające zarządzanie wiedzą w organizacji.

Dlaczego to ważne

Umożliwia analizę organizacyjną i wykrywanie wąskich gardeł na poziomie zespołów.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Assigned Group”

Przykłady
Pierwsza linia Service DeskWsparcie zapleczaAdministracja siecią
Kategoria przyczyny źródłowej
RootCauseCategory
Klasyfikacja przyczyny źródłowej problemu.
Opis

Ten atrybut zawiera kategorię wybraną po ustaleniu przyczyny źródłowej, na przykład „Błąd oprogramowania”, „Awaria sprzętu” lub „Luka w procesie”. W BMC Helix kategorię wybiera się zwykle z menu „Root Cause” lub „Generic Categorization”.

Atrybut ten jest niezbędny w widoku „Fix Effectiveness and Quality”. Pozwala powiązać konkretne typy przyczyn źródłowych z odsetkiem poprawek lub długim czasem analizy. Może na przykład ujawnić, że rozwiązywanie problemów związanych z błędami oprogramowania trwa regularnie dwa razy dłużej niż problemów spowodowanych awarią sprzętu.

Służy również do obliczania wskaźnika „Root Cause Categorization Rate”. Wysoki odsetek wartości „Unknown” lub „Other” może wskazywać na potrzebę lepszego szkolenia technicznego lub bardziej szczegółowych kategorii.

Dlaczego to ważne

Umożliwia analizę trendów dotyczących problemów systemowych i wspiera proaktywne zarządzanie problemami.

Skąd pobrać

Formularz PBM:Problem Investigation, pola na karcie „Root Cause” lub kategoryzacji

Przykłady
Moduł oprogramowaniaInfrastruktura sieciowaBłąd ludzki
Koordynator ds. problemów
ProblemCoordinator
Osoba wyznaczona do koordynowania analizy problemu.
Opis

Ten atrybut wskazuje osobę odpowiedzialną za rekord problemu. W BMC Helix ITSM odpowiada mu pole „Problem Coordinator”. Osoba ta odpowiada za cały cykl życia problemu, nawet jeśli poszczególne zadania są delegowane innym.

Atrybut ten wspiera dashboard „Support Group Workload Distribution”. Pomaga kierownikom sprawdzić, czy konkretne osoby nie są przeciążone analizą problemów, podczas gdy inni mają wolne moce przerobowe. Umożliwia również analizę wyników pracy poszczególnych osób i pomaga określić potrzeby szkoleniowe oraz wskazać osoby osiągające dobre wyniki.

W process mining pole to pełni funkcję atrybutu zasobu. Pozwala zobaczyć, jak praca przepływa między poszczególnymi osobami, i wykryć pojedyncze punkty awarii, gdy proces w zbyt dużym stopniu zależy od jednego eksperta.

Dlaczego to ważne

Umożliwia analizę zasobów i równoważenie obciążenia pracą poszczególnych osób.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Problem Coordinator”

Przykłady
Jan KowalskiAnna NowakAdministrator systemu
Liczba powiązanych incydentów
RelatedIncidentCount
Liczba incydentów powiązanych z tym rekordem problemu.
Opis

Ten atrybut określa skalę wpływu problemu, zliczając powiązane z nim incydenty. W BMC Helix jest to zwykle liczba rekordów w formularzu HPD:Help Desk powiązanych z rekordem PBM.

Atrybut ten zasila KPI „Incident Linkage Density”. Wysoka wartość oznacza, że problem ma duży wpływ i generuje wiele zgłoszeń dla service desku. Zestawienie tej wartości z polem „Priority” pozwala sprawdzić, czy problemy powodujące wiele incydentów są traktowane jako krytyczne.

Pomaga też ustalać priorytety zaległych spraw. Rekord problemu powiązany z 500 incydentami prawdopodobnie powinien mieć wyższy priorytet niż problem oznaczony jako „Critical”, z którym powiązano tylko 1 incydent. Rozwiązanie pierwszego problemu odciąży service desk w większym stopniu.

Dlaczego to ważne

Określa wpływ problemu na operacje i uciążliwość dla użytkowników.

Skąd pobrać

Obliczana przez zliczenie powiązanych wierszy w HPD:Associations lub HPD:Help Desk

Przykłady
15120
Priorytet
Priority
Priorytet problemu obliczony na podstawie jego wpływu i pilności.
Opis

Ten atrybut wskazuje priorytet rekordu problemu, na przykład krytyczny, wysoki, średni lub niski. W BMC Helix jest to zwykle pole obliczane na podstawie wybranych wartości Impact i Urgency.

W analizie służy do dashboardu „Throughput and Priority Volume”. Organizacja może sprawdzić, czy zasoby są właściwie dopasowane do potrzeb firmy. Problemy o priorytecie krytycznym powinny na przykład mieć krótszy czas do pierwszego przypisania i krótszy całkowity czas realizacji niż problemy o niskim priorytecie.

Filtrowanie według priorytetu pomaga ukierunkować działania usprawniające. Wąskie gardło w procesie obsługi problemów o niskim priorytecie może być akceptowalne, ale takie samo opóźnienie w przypadku problemu krytycznego stanowi poważne zagrożenie dla ciągłości działania firmy i zgodności z SLA.

Dlaczego to ważne

Pozwala podzielić analizę według znaczenia problemu dla firmy i wspiera analizę SLA.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Priority”

Przykłady
KrytycznyWysokiŚredniNiski
Przyczyna rozpoczęcia analizy
InvestigationDriver
Powód rozpoczęcia analizy problemu.
Opis

Ten atrybut określa przyczynę utworzenia rekordu problemu, na przykład „Liczba incydentów”, „Poważny incydent”, „Powiadomienie od dostawcy” lub „Proaktywna analiza trendów”. W BMC Helix odpowiada mu pole „Investigation Driver”.

Atrybut ten wspiera dashboard „Proactive Identification Trends”. Pozwala mierzyć przejście od reaktywnego gaszenia pożarów, czyli reagowania na incydenty, do proaktywnego zarządzania problemami, czyli wykrywania zagrożeń, zanim się zmaterializują.

Analiza przebiegu procesu według pola „Investigation Driver” może ujawnić różnice w sposobie obsługi. Problemy wykryte proaktywnie mogą na przykład dłużej czekać w kolejce, ponieważ nie powodują bezpośrednich awarii. Problemy związane z poważnym incydentem są natomiast obsługiwane szybciej.

Dlaczego to ważne

Pozwala odróżnić pracę reaktywną od proaktywnej, co jest ważnym wskaźnikiem dojrzałości.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Investigation Driver”

Przykłady
ReaktywnyProaktywnyPowtarzające się incydenty
Termin rozwiązania problemu według SLA
SLADueDate
Docelowa data i godzina rozwiązania problemu.
Opis

Ten atrybut zawiera termin rozwiązania problemu określony w umowie o poziomie usług. W BMC Helix jest to zwykle pole „Target Resolution Date” lub obliczony znacznik czasu kamienia milowego SLA.

Atrybut ten stanowi punkt odniesienia dla dashboardu „SLA Compliance and Breach Trends”. Porównując ten znacznik czasu ze znacznikiem czasu aktywności „Resolution Verified”, system ustala, czy dotrzymano SLA.

Wizualizacja tej daty pozwala analitykom sprawdzić, jak blisko terminu zespół kończy pracę. Czy problemy są rozwiązywane z kilkudniowym wyprzedzeniem, czy regularnie na kilka minut przed przekroczeniem terminu? Taka wiedza pomaga planować zasoby.

Dlaczego to ważne

To punkt odniesienia przy obliczaniu wskaźników zgodności z SLA i terminowości.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Target Resolution Date”

Przykłady
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
Usługa CI
ServiceCI
Główna usługa biznesowa lub element konfiguracji, którego dotyczy problem.
Opis

Ten atrybut wskazuje element konfiguracji usługi (CI) powiązany z problemem, na przykład „Usługa poczty e-mail”, „SAP ERP” lub „Sieć Wi-Fi”. W BMC Helix odpowiada mu często pole „Service+” lub główne powiązanie z CI.

W analizie pozwala podzielić rekordy problemów według produktu lub usługi. Pomaga kierownictwu IT ustalić, które usługi są najbardziej podatne na awarie i generują najwięcej analiz problemów. Dodaje wymiar produktu do dashboardu „Throughput and Priority Volume”.

Powiązanie tego atrybutu z „Investigation Cycle Time” może pokazać, czy analiza złożonych usług, takich jak podstawowy system bankowy, z natury trwa dłużej niż analiza usług standardowych, takich jak drukowanie.

Dlaczego to ważne

Łączy wyniki procesu z konkretnymi produktami lub usługami firmy.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „ServiceCI” lub „CI Name”

Przykłady
Usługa poczty e-mailSystem płacowyFirmowa sieć VPN
Czas analizy problemu
InvestigationCycleTime
Czas od rozpoczęcia analizy do ustalenia przyczyny źródłowej.
Opis

Ten obliczany atrybut mierzy czas między aktywnością „Investigation Commenced” a aktywnością „Root Cause Identified”. Pokazuje czas poświęcony na zasadniczą pracę w procesie zarządzania problemami.

Wskaźnik zasila dashboard „Root Cause Investigation Cycle Time”. Pomaga menedżerom ocenić złożoność techniczną problemów i sprawność zespołów analitycznych. Nietypowe wartości, na przykład bardzo krótki czas, mogą wskazywać na zgadywanie, a bardzo długi czas na zatrzymanie analizy.

Porównanie tego wskaźnika między grupami wsparcia („Support Groups”) i priorytetami („Priorities”) pozwala ustalić, które zespoły potrzebują lepszych narzędzi, szkoleń lub wsparcia dostawcy, aby szybciej diagnozować problemy.

Dlaczego to ważne

To podstawowy wskaźnik sprawności technicznej fazy analizy.

Skąd pobrać

Obliczany na podstawie znaczników czasu aktywności

Przykłady
4500000120000
Identyfikator powiązanego wniosku o zmianę
RelatedChangeRequestId
Identyfikator wniosku o zmianę utworzonego w celu rozwiązania problemu.
Opis

Ten atrybut zawiera identyfikator wniosku o zmianę (np. CRQ0000...) powiązanego z rekordem problemu. Oznacza przejście od analizy do wdrożenia trwałego rozwiązania.

Atrybut ten jest potrzebny do obliczenia KPI „Root Cause to Change Lead Time”. Narzędzie process mining może dzięki niemu zmierzyć czas od ustalenia przyczyny źródłowej do rozpoczęcia procesu zarządzania zmianą. Na tym etapie przekazania często dochodzi do opóźnień.

Pozwala też sprawdzić kompletność procesu. Zamknięcie rekordu problemu ze statusem „Completed” bez powiązanego wniosku o zmianę ani obejścia może oznaczać naruszenie procedury: przyczyna źródłowa została ustalona, ale problemu faktycznie nie rozwiązano.

Dlaczego to ważne

Łączy proces zarządzania problemami z procesem zarządzania zmianami.

Skąd pobrać

Karta PBM:Investigation Associations lub Relationship

Przykłady
CRQ00000021345CRQ00000021346
Liczba zmian przypisania
ReassignmentCount
Łączna liczba zmian grupy wsparcia.
Opis

Ten atrybut zlicza wystąpienia aktywności „Assigned to Support Group” w ramach jednej sprawy. Bezpośrednio mierzy utrudnienia w procesie i sprawność kierowania zgłoszeń.

Atrybut ten zasila wykres „Support Group Reassignment Analysis”. Wysokie wartości, oznaczające przekazywanie sprawy między grupami, wskazują, że wstępna kwalifikacja nie działa prawidłowo albo nie ustalono, kto odpowiada za złożone problemy. To sygnał, że czas realizacji może się wydłużyć.

Menedżerowie wykorzystują ten wskaźnik do wskazywania potrzeb szkoleniowych. Jeśli service desk regularnie przekazuje problemy „Database” najpierw do grupy „Network”, a ta odsyła je do „Database”, liczba zmian przypisania rośnie. Wskazuje to na potrzebę poprawy skryptów wstępnej diagnozy.

Dlaczego to ważne

Pomaga wykrywać zbędne działania, utrudnienia i brak odpowiedzialności w procesie.

Skąd pobrać

Obliczana na podstawie historii aktywności

Przykłady
015
Region
Region
Region geograficzny związany z problemem.
Opis

Ten atrybut określa lokalizację geograficzną (np. „Ameryka Północna”, „EMEA”), w której problem powstał lub jest obsługiwany. W BMC Helix informacje te znajdują się zwykle w polach „Region” lub „Site” przypisanych do osoby zgłaszającej albo zasobu, którego dotyczy problem.

W analizie atrybut ten umożliwia podział danych według regionów. Pomaga ustalić, czy w niektórych regionach występuje więcej problemów lub czy ich rozwiązywanie trwa dłużej. Może to wskazywać na różnice w obsadzie zespołów wsparcia lub jakości infrastruktury w poszczególnych lokalizacjach.

Jest przydatny w organizacjach globalnych, które chcą zapewnić spójny poziom usług. Jeśli „Investigation Cycle Time” w regionie „APAC” jest dwukrotnie dłuższy niż w „NAM”, warto sprawdzić, czy przyczyną jest alokacja zasobów lub przestrzeganie procedur w tym regionie.

Dlaczego to ważne

Umożliwia porównywanie wyników procesu w różnych regionach.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Region”

Przykłady
AmerykiEMEAAPAC
Status obejścia problemu
WorkaroundStatus
Informuje, czy znaleziono i opublikowano działające obejście problemu.
Opis

Ten atrybut śledzi stan rozwiązania tymczasowego (Workaround). Może przyjmować wartość logiczną (Has Workaround) lub status tekstowy. W BMC Helix jego wartość wynika często z tego, czy pole „Workaround” zawiera tekst, albo z określonej flagi statusu.

Atrybut ten zasila dashboard „Workaround Publication Performance”. Pokazuje, jak skutecznie zespół ogranicza wpływ problemu podczas ustalania jego przyczyny źródłowej. Widok procesu przefiltrowany według wartości „No Workaround” wskazuje sprawy, w których firma odczuwa pełne skutki problemu w trakcie analizy.

Pomaga również w audytach jakości. Zamknięcie rekordu problemu bez trwałego rozwiązania (wniosku o zmianę) i bez obejścia zwykle oznacza błąd w procesie, który wymaga sprawdzenia.

Dlaczego to ważne

Mierzy skuteczność ograniczania wpływu problemu podczas analizy.

Skąd pobrać

Formularz PBM:Problem Investigation, sprawdzenie zawartości pola „Workaround”

Przykłady
AktywnyBrakWycofany
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania problemami

To podstawowe etapy procesu i zmiany statusu, które warto monitorować, aby uzyskać pełny obraz przebiegu analizy i rozwiązywania problemów.
9 Zalecane 4 Opcjonalne
Działanie Opis
Anulowanie rekordu problemu
Zakończenie obsługi rekordu problemu przed jego rozwiązaniem. Zdarzenie jest rejestrowane, gdy status zmienia się na „Cancelled” lub „Rejected”.
Dlaczego to ważne

Pomaga wykryć niepotrzebną pracę lub uzasadnione duplikaty. Stanowi alternatywny punkt końcowy procesu.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Status” = „Cancelled” lub „Rejected”.

Rejestrowanie

Porównanie pola Status w celu wykrycia zmiany na „Cancelled”

Typ zdarzenia inferred
Opisanie obejścia
Wprowadzenie lub aktualizacja tekstu w polu Workaround rekordu problemu. Zdarzenie oznacza udokumentowanie tymczasowego rozwiązania.
Dlaczego to ważne

Obsługuje KPI „Workaround Publication Lead Time” i wskazuje, że podjęto działania ograniczające wpływ incydentu.

Skąd pobrać

Formularz PBM:Problem Investigation, zmiany w polu tekstowym „Workaround”.

Rejestrowanie

Porównanie zawartości pola „Workaround” w celu wykrycia aktualizacji z niepustą wartością

Typ zdarzenia inferred
Przypisanie do grupy wsparcia
Przypisanie rekordu problemu do konkretnego zespołu technicznego. Zdarzenie można wykryć, monitorując zmiany pola „Assigned Group”.
Dlaczego to ważne

Niezbędne do mierzenia przekazań między zespołami, efektu „ping-pong” oraz KPI „Mean Time to Initial Assignment”.

Skąd pobrać

Formularz PBM:Problem Investigation, historia pola „Assigned Group” lub dziennik audytu.

Rejestrowanie

Porównanie wartości pola „Assigned Group” przed aktualizacją i po niej

Typ zdarzenia inferred
Rozpoczęcie analizy
Przejście rekordu problemu do aktywnej fazy analizy. Zdarzenie jest wnioskowane na podstawie zmiany pola Status na „Under Investigation”.
Dlaczego to ważne

Oznacza początek właściwej pracy nad problemem i umożliwia pomiar KPI „Investigation Cycle Time”.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Status” = „Under Investigation”.

Rejestrowanie

Porównanie pola Status w celu wykrycia zmiany na „Under Investigation”

Typ zdarzenia inferred
Rozpoczęcie wniosku o zmianę
Powiązanie wniosku Infrastructure Change Request z analizą problemu. Oznacza początek etapu wdrożenia.
Dlaczego to ważne

Niezbędne do pomiaru KPI „Root Cause to Change Lead Time” i wykrywania silosów między procesami Problem Management i Change Management.

Skąd pobrać

Tabela PBM:Investigation_Associations lub wypełnienie pola „Infrastructure Change ID”.

Rejestrowanie

Rejestrowane po utworzeniu powiązania w PBM:Investigation_Associations

Typ zdarzenia explicit
Ustalenie przyczyny źródłowej
Moment, w którym stan rekordu problemu wskazuje, że przyczyna jest znana. Zdarzenie jest wnioskowane na podstawie zmiany pola Status na „Root Cause Identified”.
Dlaczego to ważne

Ważny etap na dashboardzie „Root Cause Investigation Cycle Time”. Oznacza przejście od analizy do opracowywania rozwiązania.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Status” = „Root Cause Identified”.

Rejestrowanie

Porównanie pola Status w celu wykrycia zmiany na „Root Cause Identified”

Typ zdarzenia inferred
Weryfikacja rozwiązania
Moment potwierdzenia, że trwałe rozwiązanie działa. Zdarzenie jest wnioskowane na podstawie zmiany pola Status na „Solution Implemented” lub „Completed”.
Dlaczego to ważne

Służy do obliczania wskaźnika „Problem SLA Adherence Rate”. Potwierdza zakończenie prac technicznych.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Status” = „Solution Implemented” lub „Completed”.

Rejestrowanie

Porównanie pola Status w celu wykrycia zmiany na „Solution Implemented”

Typ zdarzenia inferred
Zamknięcie rekordu problemu
Ostateczne, administracyjne zamknięcie rekordu problemu. To zdarzenie kończy instancję procesu.
Dlaczego to ważne

Standardowe zdarzenie końcowe. Jest niezbędne do pełnej analizy czasu realizacji i obliczania wskaźnika „Incident Linkage Density”.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Status” = „Closed”.

Rejestrowanie

Porównanie pola Status w celu wykrycia zmiany na „Closed”

Typ zdarzenia inferred
Zarejestrowanie rekordu problemu
Utworzenie rekordu analizy problemu w systemie. Zdarzenie jest rejestrowane w chwili zapisania nowego wpisu w formularzu PBM:Problem Investigation.
Dlaczego to ważne

Oznacza początek instancji procesu. Jest niezbędne do obliczania całkowitego czasu realizacji i wskaźników czasu pierwszej reakcji.

Skąd pobrać

Formularz PBM:Problem Investigation, znacznik czasu „Submit Date” lub wpis w dzienniku utworzenia z wartością „Status” = „Draft”.

Rejestrowanie

Rejestrowane przy utworzeniu rekordu PBM:Problem Investigation

Typ zdarzenia explicit
Aktualizacja bazy rozwiązań
Przejście rekordu do stanu „Solution Database”, oznaczające, że zaproponowano lub ustalono trwałe rozwiązanie.
Dlaczego to ważne

Śledzi postępy w opracowywaniu rozwiązania przed jego wdrożeniem.

Skąd pobrać

Formularz PBM:Problem Investigation, pole „Status” = „Solution Database”.

Rejestrowanie

Porównanie pola Status w celu wykrycia zmiany na „Solution Database”

Typ zdarzenia inferred
Przeprowadzenie przeglądu po wdrożeniu
Zakończenie etapu PIR. Zdarzenie jest rejestrowane przy zmianie statusu związanego z PIR lub zamknięciu powiązanego zadania PIR.
Dlaczego to ważne

Bezpośrednio wspiera wskaźnik „Post Implementation Review Compliance” i audyty jakości procesu.

Skąd pobrać

Formularz PBM:Problem Investigation, flaga „PIR Required” lub zakończenie powiązanego zadania typu „PIR”.

Rejestrowanie

Ustalane na podstawie zakończenia PIR lub zamknięcia zadania PIR

Typ zdarzenia inferred
Utworzenie rekordu znanego błędu
Utworzenie rekordu Known Error powiązanego z analizą problemu. Jest to zdarzenie utworzenia powiązanego rekordu.
Dlaczego to ważne

Oznacza formalne opisanie problemu na potrzeby szerszej komunikacji i długoterminowego śledzenia.

Skąd pobrać

Utworzenie rekordu w PBM:Known Error powiązanego z identyfikatorem PBM:Problem Investigation.

Rejestrowanie

Rejestrowane przy utworzeniu rekordu PBM:Known Error

Typ zdarzenia explicit
Zmiana koordynatora
Zmiana osoby pełniącej funkcję koordynatora problemu w grupie wsparcia. Można ją wykryć, monitorując pole „Problem Coordinator”.
Dlaczego to ważne

Pomaga analizować rozkład obciążenia pracą i wąskie gardła związane z poszczególnymi osobami.

Skąd pobrać

Formularz PBM:Problem Investigation, historia pola „Problem Coordinator”.

Rejestrowanie

Porównanie wartości pola „Problem Coordinator” przed aktualizacją i po niej

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje eksportu danych

Jak wyeksportować dane dotyczące zarządzania problemami z BMC Helix ITSM

Gotowi do rozpoczęcia?

Zastosuj ten szablon do danych z BMC Helix ITSM, aby poprawić stabilność usług. W razie pytań dotyczących konfiguracji można skontaktować się z naszym zespołem.

Usuń wąskie gardła w zarządzaniu problemami

Skróć czas cyklu o 30% i popraw stabilność usług.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.