Szablon danych do zarządzania zgłoszeniami serwisowymi

Czas rozpoczęcia określa dokładną datę i godzinę rozpoczęcia danego działania. Ten znacznik czasu pozwala uporządkować zdarzenia chronologicznie oraz obliczyć czas trwania działań i całego cyklu obsługi sprawy. Każde działanie w procesie powinno mieć przypisany czas rozpoczęcia, aby można było utworzyć dokładny dziennik zdarzeń.

W analizie procesu czas rozpoczęcia służy do obliczania wskaźników KPI, takich jak czas realizacji, czas oczekiwania między działaniami i czas pracy nad działaniem. Pozwala przedstawić proces w ujęciu czasowym, wskazać opóźnienia i ustalić, które kroki zajmują najwięcej czasu. Dokładne znaczniki czasu są niezbędne do analizy wydajności.

Ten znacznik czasu pozwala prawidłowo uporządkować zdarzenia i obliczyć wskaźniki związane z czasem, takie jak czas realizacji i czas występowania wąskich gardeł.

Znajduje się w tabelach dziennika zdarzeń lub ścieżki audytu. Dla każdego działania może być zapisany jako „data utworzenia” lub „znacznik czasu zdarzenia”.

Atrybut Działanie opisuje konkretny krok lub czynność wykonaną w ramach obsługi zgłoszenia serwisowego. Działania tworzą kolejne etapy procesu, na przykład „Utworzono zgłoszenie”, „Przypisano zgłoszenie”, „Praca w toku” i „Zamknięto zgłoszenie”. Każde działanie oznacza odrębny moment w przebiegu obsługi zgłoszenia.

Analiza działań stanowi podstawę process mining. Umożliwia odkrywanie i wizualizację rzeczywistego przebiegu procesu. Analizując kolejność i częstotliwość działań, można wykryć typowe ścieżki, odstępstwa od standardowego procesu, wąskie gardła, w których zgłoszenia utknęły, oraz pętle poprawek wynikające z niepotrzebnego powtarzania kroków.

Określa kolejne kroki procesu, dzięki czemu można odkryć jego rzeczywisty przebieg, wąskie gardła i odstępstwa.

Często pochodzi z dzienników zmian statusu, tabel zdarzeń lub ścieżek audytu powiązanych ze zgłoszeniem serwisowym.

Identyfikator zgłoszenia serwisowego to klucz główny, który jednoznacznie identyfikuje każde zgłoszenie przez cały cykl jego obsługi. Pełni funkcję identyfikatora sprawy i łączy powiązane działania, zmiany statusu oraz atrybuty w jedną instancję procesu.

W analizie process mining ten identyfikator pozwala odtworzyć przebieg każdego zgłoszenia od początku do końca. Grupując wszystkie zdarzenia pod wspólnym CaseId, analitycy mogą wizualizować przebieg procesu, obliczać czas obsługi spraw i wykrywać różnice w sposobie rozpatrywania zgłoszeń. To podstawa analizy procesu obsługi zgłoszeń serwisowych.

Ten identyfikator pozwala połączyć wszystkie zdarzenia dotyczące zgłoszenia serwisowego i uzyskać pełny obraz procesu od początku do końca.

Zwykle znajduje się w nagłówku lub głównej tabeli transakcji dotyczącej zgłoszeń serwisowych.

Data ostatniej aktualizacji danych wskazuje, kiedy ostatnio pobrano lub odświeżono dane. Informuje użytkowników, jak aktualne są analizowane dane i czy analiza odzwierciedla bieżący stan, czy wcześniejszy obraz procesu.

Ten atrybut jest potrzebny do monitorowania operacji i raportowania, ponieważ pozwala ocenić aktualność uzyskanych informacji. Ułatwia ocenę wiarygodności danych i podejmowanie decyzji z uwzględnieniem tego, kiedy je zebrano. Na przykład dashboard z danymi zaktualizowanymi tydzień temu należy interpretować inaczej niż dashboard odświeżony godzinę temu.

Informuje o aktualności danych, co pozwala ocenić, czy analizy są miarodajne i oparte na bieżących informacjach.

To pole metadanych jest zwykle generowane i zapisywane podczas ekstrakcji danych (ETL).

Atrybut System źródłowy określa nazwę platformy IT Service Management (ITSM) lub innej aplikacji, z której pobrano dane. W środowiskach korzystających z wielu systemów pole to pomaga rozróżnić źródła i zachować przejrzystość pochodzenia danych.

Atrybut ten zwykle nie służy bezpośrednio do analizy przebiegu procesu, ale ma znaczenie dla zarządzania danymi, ich weryfikacji i rozwiązywania problemów. Przy łączeniu danych z różnych źródeł pozwala analizować proces osobno dla każdego systemu, co może ujawnić różnice w przebiegu procesu lub jakości danych między platformami.

Pomaga zarządzać danymi i rozwiązywać problemy, ponieważ wskazuje ich źródło, szczególnie w środowiskach z wieloma zintegrowanymi systemami.

Ta wartość jest zwykle dodawana podczas ekstrakcji danych (ETL) i nie stanowi pola wbudowanego w sam system źródłowy.

Priorytet zgłoszenia pomaga zespołom wsparcia ustalić kolejność obsługi zgłoszeń. Zwykle zależy od wpływu zgłoszenia na działalność firmy i jego pilności. Typowe poziomy priorytetu to niski, średni, wysoki i krytyczny.

Ten atrybut przydaje się do analizy wydajności i przydzielania zasobów. Analitycy mogą porównywać czas realizacji i zgodność z SLA dla różnych priorytetów, aby sprawdzić, czy zgłoszenia o wysokim priorytecie są obsługiwane zgodnie z oczekiwaniami. Można też ustalić, czy zgłoszenia o niskim priorytecie nie są pomijane i czy zespoły wsparcia prawidłowo stosują zasady ustalania priorytetów.

Pozwala sprawdzić, czy zgłoszenia są obsługiwane zgodnie z ich znaczeniem dla firmy, oraz ocenić wpływ priorytetu na czas rozwiązania.

Zwykle jest to standardowe pole w głównym rekordzie zgłoszenia serwisowego.

Przypisany konsultant to osoba odpowiedzialna za obsługę zgłoszenia serwisowego w danym momencie. W trakcie obsługi zgłoszenie może być przypisywane różnym konsultantom.

Ten atrybut pozwala analizować wydajność i obciążenie pracą. Umożliwia porównywanie wyników poszczególnych konsultantów, w tym średniego czasu rozwiązania i liczby obsługiwanych zgłoszeń. Pozwala też analizować zmiany przypisania między konsultantami, które mogą wskazywać na problemy z wstępną kwalifikacją, specjalizacją lub równomiernym rozłożeniem pracy.

Pozwala analizować wyniki pracy poszczególnych konsultantów, rozkład obciążenia i częstotliwość przekazywania zgłoszeń między nimi.

Dostępny w rekordzie zgłoszenia serwisowego. Zmiany tego pola są często zapisywane w dzienniku audytu lub tabeli historii.

Przypisany zespół to grupa wsparcia odpowiedzialna za zgłoszenie serwisowe. Zgłoszenia są często przekazywane między zespołami, na przykład do pierwszej linii wsparcia, zespołu sieciowego lub zespołu programistów, zależnie od wymaganej wiedzy.

Analiza przekazywania zgłoszeń między zespołami jest ważną częścią process mining w zarządzaniu usługami. Ten atrybut pozwala wizualizować przekazania między zespołami i wykrywać problemy z komunikacją lub opóźnienia. Umożliwia też porównywanie wyników zespołów pod względem efektywności, liczby zgłoszeń i zdolności do ich rozwiązywania bez dalszej eskalacji.

Pozwala analizować przekazywanie zgłoszeń między zespołami, wykrywać opóźnienia i porównywać wyniki pracy zespołów.

Standardowe pole w rekordzie zgłoszenia serwisowego. Zmiany tego pola są zapisywane w dzienniku audytu.

Rodzaj usługi określa charakter zgłoszenia serwisowego. Może ono dotyczyć na przykład nowego sprzętu, dostępu do oprogramowania, ogólnego zapytania lub pomocy technicznej. Taka kategoryzacja ułatwia przekazanie zgłoszenia do właściwego zespołu i pozwala ocenić zapotrzebowanie na poszczególne usługi.

W analizie procesu rodzaj usługi pozwala dzielić dane na kategorie. Filtrując mapę procesu według rodzaju usługi, można wykryć, że niektóre zgłoszenia przebiegają zupełnie inaczej, trwają dłużej lub częściej wymagają poprawek. Dzięki temu można skupić działania usprawniające na konkretnych kategoriach usług.

Pozwala filtrować i porównywać procesy dla różnych kategorii zgłoszeń oraz wykrywać wąskie gardła i nieefektywne działania charakterystyczne dla każdej z nich.

Standardowe pole w rekordzie zgłoszenia serwisowego, często powiązane z katalogiem usług.

Status zgłoszenia określa stan zgłoszenia serwisowego w danym momencie jego obsługi. Typowe statusy to „Nowe”, „W trakcie realizacji”, „Oczekujące”, „Rozwiązane” i „Zamknięte”. Atrybut ten pokazuje, na jakim etapie procesu znajduje się zgłoszenie.

Analiza statusu zgłoszenia pomaga zrozumieć przebieg procesu i zmiany jego stanów. Można filtrować sprawy, wykrywać zgłoszenia, które utknęły w danym stanie, oraz mierzyć czas spędzony w każdym statusie. Na przykład analiza czasu oczekiwania może ujawnić opóźnienia spowodowane oczekiwaniem na informacje od użytkowników lub zespołów zewnętrznych.

Pozwala sprawdzić, jak długo zgłoszenia pozostają w poszczególnych stanach, i wykryć wąskie gardła oraz opóźnienia w procesie.

Dostępny w głównej tabeli zgłoszeń serwisowych lub w dziennikach historii statusów.

Termin realizacji SLA to docelowy znacznik czasu wyznaczany na podstawie umowy SLA przypisanej do zgłoszenia. Zależy między innymi od priorytetu i rodzaju zgłoszenia oraz czasu jego utworzenia, a tym samym określa oczekiwany termin rozwiązania.

Ten atrybut stanowi podstawę analizy zgodności z SLA. Porównując rzeczywisty czas rozwiązania z terminem realizacji SLA, można ustalić, czy zgłoszenie rozwiązano na czas, czy doszło do naruszenia SLA. To ważny wskaźnik KPI jakości usług, który pomaga wykrywać powtarzające się problemy powodujące opóźnienia i naruszenia.

To punkt odniesienia przy ocenie wyników. Pozwala obliczać poziom zgodności z SLA i wskazywać zgłoszenia, w których przekroczono termin.

Często jest to pole obliczane w rekordzie zgłoszenia serwisowego na podstawie obowiązujących zasad SLA.

Czas zakończenia określa dokładną datę i godzinę zakończenia danego działania. Czas rozpoczęcia wyznacza początek, a czas zakończenia jego koniec, co pozwala określić czas trwania pojedynczego kroku procesu. Nie każde zdarzenie ma osobny czas zakończenia, ponieważ niektóre zachodzą natychmiast.

Ten atrybut pozwala obliczyć czas realizacji poszczególnych działań. Odejmując czas rozpoczęcia od czasu zakończenia, analitycy mogą ustalić, ile czasu konsultanci lub systemy aktywnie poświęcają na zadanie. Dzięki temu można wskazać działania, które zajmują najwięcej czasu i warto je usprawnić lub zautomatyzować.

Pozwala obliczyć czas realizacji poszczególnych działań i wskazać kroki procesu, które zajmują najwięcej czasu.

Znajduje się w tabelach dziennika zdarzeń lub ścieżki audytu. Jeśli nie jest dostępny bezpośrednio, można go wyznaczyć na podstawie czasu rozpoczęcia kolejnego działania.

Ten atrybut logiczny wskazuje, czy nie dotrzymano warunków określonych w umowie SLA dla zgłoszenia serwisowego. Przyjmuje wartość true, jeśli zgłoszenie rozwiązano po terminie „SlaDueDate”, a w przeciwnym razie wartość false.

Atrybut ten upraszcza raportowanie i analizę zgodności z SLA. Zamiast porównywać daty w każdym zapytaniu, można łatwo filtrować i agregować dane za pomocą tej flagi. To podstawowa miara w dashboardach dotyczących realizacji SLA, która pozwala szybko ustalić liczbę i odsetek zgłoszeń niespełniających wymaganych terminów.

Zapewnia prostą i czytelną flagę do analizy realizacji SLA, ułatwiając filtrowanie i raportowanie zgłoszeń, w których przekroczono termin.

To atrybut pochodny, obliczany podczas transformacji danych przez porównanie końcowego znacznika czasu rozwiązania z polem „SlaDueDate”.

Ten atrybut wskazuje dział lub jednostkę organizacyjną osoby, która zgłosiła potrzebę obsługi serwisowej. Dostarcza informacji o kontekście organizacyjnym zgłoszenia.

Analiza zgłoszeń według działu pomaga wykrywać potrzeby, trendy i problemy charakterystyczne dla poszczególnych działów. Na przykład duża liczba zgłoszeń określonego rodzaju z działu finansowego może wskazywać na potrzebę dodatkowych szkoleń lub usprawnienia systemu. Dane te pozwalają też rozliczać koszty usług i oceniać zapotrzebowanie na usługi IT w całej organizacji.

Dostarcza kontekstu organizacyjnego i pozwala analizować wzorce zgłoszeń oraz zapotrzebowanie na usługi w poszczególnych jednostkach.

Informacje te są zwykle pobierane z profilu użytkownika w katalogu pracowników lub systemie ITSM.

Kanał zgłoszenia wskazuje, w jaki sposób utworzono zgłoszenie serwisowe, na przykład przez portal samoobsługowy, e-mail, telefon lub API. Poszczególne kanały mogą wiązać się z innym przebiegiem procesu i innymi oczekiwaniami użytkowników.

Analiza procesu według kanału zgłoszenia może dostarczyć przydatnych informacji. Zgłoszenia przesłane przez portal samoobsługowy mogą być lepiej ustrukturyzowane i szybciej rozwiązywane niż te przesłane e-mailem, które mogą wymagać ręcznego wprowadzania danych. Taka analiza pomaga promować sprawniejsze kanały lub usprawniać obsługę w mniej efektywnych kanałach.

Pozwala sprawdzić, czy sposób przesłania zgłoszenia wpływa na sprawność procesu, czas rozwiązania lub odsetek spraw rozwiązanych przy pierwszym kontakcie.

Zwykle jest to standardowe pole w rekordzie zgłoszenia serwisowego.

Kod rozwiązania pozwala w uporządkowany sposób sklasyfikować wynik obsługi zgłoszenia serwisowego. Przykłady: „Rozwiązane przez użytkownika”, „Wymieniono sprzęt”, „Wdrożono oprogramowanie” lub „Zduplikowane zgłoszenie”. Konsultant zwykle wprowadza tę informację podczas zamykania zgłoszenia.

Kody te pomagają analizować przyczyny źródłowe. Analiza częstotliwości poszczególnych kodów pozwala wykrywać powtarzające się problemy, typowe rozwiązania i możliwości przygotowania artykułów w bazie wiedzy lub automatycznego rozwiązywania zgłoszeń. Na przykład duża liczba zgłoszeń z kodem „Reset hasła” może uzasadniać wdrożenie narzędzia do samodzielnego resetowania haseł.

Pozwala analizować przyczyny źródłowe przez klasyfikację sposobów rozwiązywania zgłoszeń, co pomaga wykrywać trendy i obszary wymagające proaktywnego zarządzania problemami.

Pole zwykle wypełniane ręcznie przez konsultanta podczas rozwiązywania lub zamykania zgłoszenia serwisowego.

Liczba zmian przypisania określa, ile razy zgłoszenie serwisowe przekazano innemu konsultantowi lub zespołowi. Duża liczba zmian może wskazywać na problemy, takie jak błędne początkowe przypisanie, brak wiedzy konsultanta lub niejasny podział odpowiedzialności za proces.

To wskaźnik nieefektywności procesu. W process mining pozwala określić, ile razy zgłoszenie było przekazywane między osobami lub zespołami. Analiza spraw z dużą liczbą zmian przypisania może wskazać możliwości usprawnienia wstępnej kwalifikacji, szkoleń konsultantów lub podziału obowiązków między zespołami, tak aby zgłoszenia od razu trafiały we właściwe miejsce.

Wskaźnik nieefektywności procesu. Częste zmiany przypisania zwykle wiążą się z dłuższym czasem rozwiązania i niższym zadowoleniem użytkowników.

To miara obliczana przez zliczenie zmian pól „AssignedAgent” lub „AssignedTeam” dla danego „CaseId”.