Szablon danych do analizy obsługi zgłoszeń serwisowych

ServiceNow
Szablon danych do analizy obsługi zgłoszeń serwisowych

Szablon danych do analizy obsługi zgłoszeń serwisowych

Ten szablon danych ułatwia rozpoczęcie process mining w obszarze obsługi zgłoszeń serwisowych. Zawiera wskazówki dotyczące najważniejszych atrybutów do zebrania, działań do śledzenia oraz sposobu eksportu danych z ServiceNow. Dzięki niemu można zgromadzić dane potrzebne do rzetelnej analizy i skutecznego usprawniania procesu.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia podczas odkrywania procesu
  • Instrukcja eksportu danych krok po kroku
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu zarządzania zgłoszeniami serwisowymi

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować proces zarządzania zgłoszeniami serwisowymi.
5 Wymagane 6 Zalecane 10 Opcjonalne
Nazwa Opis
Czas rozpoczęcia
EventTime
Znacznik czasu określający moment rozpoczęcia działania lub zdarzenia.
Opis

Ten atrybut zapisuje dokładną datę i godzinę każdego działania w procesie obsługi zgłoszenia serwisowego. Określa kolejność zdarzeń potrzebną do utworzenia mapy procesu i przeprowadzenia analiz czasowych.

Dokładne znaczniki czasu są niezbędne do obliczania czasu realizacji, oczekiwania i przetwarzania. Pozwalają wykrywać wąskie gardła i naruszenia SLA oraz analizować zmiany wyników w czasie.

Dlaczego to ważne

To wymagany znacznik czasu, który pozwala prawidłowo uporządkować zdarzenia. Stanowi podstawę analiz wyników i czasu, w tym obliczania czasu realizacji i wykrywania wąskich gardeł.

Skąd pobrać

Zwykle znajduje się w polach „sys_updated_on” lub „sys_created_on” odpowiednich tabel ServiceNow, na przykład sc_request i sc_task, albo w śladzie audytowym (sys_audit).

Przykłady
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
Działanie
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło podczas obsługi zgłoszenia serwisowego.
Opis

Atrybut „Działanie” zapisuje nazwę każdego kroku lub zmiany statusu w procesie obsługi zgłoszenia serwisowego. Mogą to być zdarzenia takie jak „Utworzenie zgłoszenia”, „Akceptacja zgłoszenia”, „Przypisanie do konsultanta” lub „Zamknięcie zgłoszenia”.

Analiza tych działań pozwala przedstawić przebieg procesu, wskazać typowe ścieżki i wykryć odstępstwa od standardowej procedury. To podstawa do zrozumienia, jak faktycznie przebiega realizacja zgłoszeń.

Dlaczego to ważne

To wymagany atrybut określający kroki na mapie procesu. Jest podstawą każdej analizy procesu, w tym wykrywania wąskich gardeł, pętli poprawek i problemów ze zgodnością.

Skąd pobrać

Dane pochodzą ze zmian pól „State” lub „Stage” w tabelach takich jak „sc_request” lub „sc_req_item” albo ze śladu audytowego (sys_audit).

Przykłady
Utworzenie zgłoszenia serwisowegoPrzypisanie zgłoszenia do grupyRozwiązanie zgłoszenia serwisowegoProśba o informacje od użytkownika
Service Request ID
ServiceRequestID
Unikalny identyfikator każdego rekordu zgłoszenia serwisowego.
Opis

Service Request ID to klucz główny, który jednoznacznie identyfikuje każde zgłoszenie serwisowe przesłane przez użytkownika lub system. Łączy wszystkie kolejne zdarzenia, od początkowej rejestracji po ostateczne zamknięcie. W process mining ten identyfikator jest niezbędny do odtworzenia pełnego przebiegu obsługi każdego zgłoszenia i analizy jego cyklu życia.

Dlaczego to ważne

To wymagany identyfikator Case ID. Łączy powiązane działania w jedną instancję procesu, co umożliwia analizę przebiegu procesu, jego wariantów i czasu realizacji.

Skąd pobrać

Tabela ServiceNow Request [sc_request], pole „number”.

Przykłady
REQ0010001REQ0010025REQ0010112
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu ostatniego odświeżenia lub pobrania danych.
Opis

Ten atrybut wskazuje datę i godzinę ostatniego pobrania danych z systemu źródłowego i załadowania ich do narzędzia process mining. Informuje, jak aktualne są analizowane dane.

Analitycy mogą sprawdzić, czy pracują na najnowszych danych. Ma to znaczenie przy monitorowaniu operacji i podejmowaniu bieżących decyzji. Informacja ta pozwala ocenić, jak dawno zebrano dane użyte do analizy.

Dlaczego to ważne

Informuje użytkowników o aktualności danych, co pomaga ocenić wiarygodność analizy i podejmować decyzje na podstawie danych we właściwym czasie.

Skąd pobrać

To pole metadanych dodawane podczas wczytywania danych. Zawiera znacznik czasu zakończenia zadania ETL.

Przykłady
2023-10-27T04:00:00Z
System źródłowy
SourceSystem
System, z którego pochodzą dane.
Opis

Ten atrybut wskazuje system źródłowy danych, w tym przypadku ServiceNow. Przydaje się w środowiskach, w których łączy się dane z wielu systemów, aby uzyskać pełny obraz procesu.

W analizie danych z jednego źródła atrybut ten dostarcza ważnego kontekstu i wspiera zarządzanie danymi. Pozwala każdemu użytkownikowi ustalić, skąd pochodzą analizowane dane.

Dlaczego to ważne

Dostarcza metadanych potrzebnych do zarządzania danymi, śledzenia ich pochodzenia i zapewnienia kontekstu, zwłaszcza przy łączeniu danych z wielu systemów firmowych.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas pobierania i przekształcania danych.

Przykłady
ServiceNow
Grupa przypisania
AssignmentGroup
Zespół lub grupa odpowiedzialna za obsługę zgłoszenia serwisowego.
Opis

Grupa przypisania to zespół odpowiedzialny za zgłoszenie na danym etapie, na przykład „Service Desk”, „Network Operations” lub „Database Administration”. Atrybut ten pomaga analizować przepływ pracy między różnymi obszarami.

Śledzenie zmian grupy przypisania pozwala przedstawić przekazania między zespołami, mierzyć czas oczekiwania w kolejce każdego zespołu i wykrywać zależności lub opóźnienia między zespołami. Ma to znaczenie dla usprawniania współpracy między obszarami.

Dlaczego to ważne

Pokazuje rozkład pracy między zespołami, uwidacznia przekazania i pomaga wykrywać wąskie gardła oraz problemy z wynikami pracy poszczególnych zespołów.

Skąd pobrać

Tabele ServiceNow Request Item [sc_req_item] lub Catalog Task [sc_task], pole „assignment_group”.

Przykłady
Service DeskWsparcie IT, poziom 2Przygotowanie sprzętu
Kategoria
Category
Główna klasyfikacja zgłoszenia serwisowego, na przykład sprzęt lub oprogramowanie.
Opis

Kategoria określa ogólną klasyfikację zgłoszenia serwisowego. Zwykle służy do kierowania zgłoszeń do odpowiedniego zespołu oraz raportowania ich rodzajów.

W process mining kategoria pozwala filtrować dane i analizować je według wymiarów. Analitycy mogą porównywać przebieg procesu, czas realizacji i poziom automatyzacji dla różnych typów zgłoszeń. Dzięki temu widać różnice, które giną w danych zbiorczych. Na przykład obsługa zgłoszenia dotyczącego sprzętu może przebiegać zupełnie inaczej niż zgłoszenia dotyczącego oprogramowania.

Dlaczego to ważne

Umożliwia szczegółowy podział i porównywanie procesów dla różnych rodzajów usług, co pomaga wykrywać problemy i możliwości usprawnień charakterystyczne dla poszczególnych kategorii.

Skąd pobrać

Tabela ServiceNow Request Item [sc_req_item], zwykle za pośrednictwem kategorii powiązanej pozycji katalogowej [sc_cat_item].

Przykłady
SprzętOprogramowanieWniosek o dostępSieć
Priorytet
Priority
Poziom priorytetu zgłoszenia serwisowego, który wpływa na jego pilność.
Opis

Priorytet określa względną ważność i pilność zgłoszenia serwisowego. Często ustala się go na podstawie wpływu i pilności. Pomaga osobom obsługującym zdecydować, które zgłoszenia rozpatrzyć w pierwszej kolejności.

Analiza danych według priorytetu pozwala sprawdzić, czy zgłoszenia o wysokim priorytecie są obsługiwane szybciej niż te o niskim priorytecie. Można filtrować dashboardy, aby sprawdzić, czy dotrzymywane są SLA dla pilnych zgłoszeń, i ocenić skuteczność systemu priorytetów.

Dlaczego to ważne

Pozwala podzielić zgłoszenia na grupy i sprawdzić, czy te o wysokim priorytecie są obsługiwane szybciej. Jest potrzebny do analizy SLA i przydzielania zasobów.

Skąd pobrać

Tabele ServiceNow Request [sc_request] lub Request Item [sc_req_item], pole „priority”.

Przykłady
1 - Krytyczny2 - Wysoki3 - Umiarkowany4 - Niski
Przypisany użytkownik
AssignedTo
Osoba odpowiedzialna za obsługę zgłoszenia serwisowego w danym momencie.
Opis

Ten atrybut wskazuje konkretnego konsultanta lub technika przypisanego do zgłoszenia serwisowego. Zmienia się, gdy zgłoszenie jest przekazywane między osobami.

Analiza pola „Assigned To” pomaga zrozumieć rozkład obciążenia, wyniki pracy poszczególnych osób i wpływ przekazań na czas rozwiązania zgłoszenia. Pozwala ocenić wykorzystanie zasobów i wskazać możliwości szkolenia lub doprecyzowania procesu, aby ograniczyć ponowne przypisania.

Dlaczego to ważne

Umożliwia analizę obciążenia i wyników pracy konsultantów oraz przekazań między nimi. Jest niezbędny do zarządzania zasobami i wykrywania wąskich gardeł związanych z konkretnymi osobami.

Skąd pobrać

Tabele ServiceNow Request Item [sc_req_item] lub Catalog Task [sc_task], pole „assigned_to”.

Przykłady
Beth AnglinDavid LooHoward Johnson
Stan
State
Bieżący status operacyjny zgłoszenia serwisowego.
Opis

Atrybut „Stan” wskazuje bieżący etap obsługi zgłoszenia serwisowego, na przykład „Open”, „Work in Progress”, „Pending” lub „Closed”. Zmiany tego pola często służą do odtworzenia działań na mapie procesu.

Analiza stanu pozwala sprawdzić, ile czasu zgłoszenia spędzają w poszczególnych statusach, zwłaszcza oczekując na dalsze działania. Pomaga wykrywać kolejki i opóźnienia, na przykład czas oczekiwania na informacje od użytkownika, który często wydłuża czas realizacji.

Dlaczego to ważne

Pokazuje status zgłoszenia w dowolnym momencie i umożliwia analizę czasu oczekiwania, kolejek oraz czasu trwania poszczególnych etapów procesu.

Skąd pobrać

Tabele ServiceNow Request [sc_request] lub Request Item [sc_req_item], pole „state” lub „stage”.

Przykłady
OtwarteW trakcie realizacjiOczekiwanie na informacje od użytkownikaZamknięte, zrealizowane
Zgodność z SLA
MadeSLA
Wartość logiczna wskazująca, czy zgłoszenie serwisowe zostało rozwiązane w terminie określonym w umowie SLA.
Opis

Ten atrybut wskazuje, czy zgłoszenie serwisowe zostało rozwiązane w czasie określonym w umowie SLA. To ważny miernik wyniku, który bezpośrednio pokazuje, czy usługa spełnia przyjęte zobowiązania.

Analiza tego pola pozwala obliczyć KPI dotyczący zgodności z SLA. Można też porównać przebieg procesu w zgłoszeniach zgodnych z SLA i tych, w których doszło do przekroczenia terminu. Ujawnia to powtarzające się wzorce i działania prowadzące do naruszeń SLA. Takie informacje pomagają monitorować ryzyko i stale ulepszać usługi.

Dlaczego to ważne

Bezpośrednio mierzy realizację zobowiązań dotyczących usług i pozwala analizować przyczyny naruszeń SLA przez porównanie zgłoszeń zgodnych i niezgodnych z umową.

Skąd pobrać

Tabela ServiceNow Task SLA [task_sla], pole 'has_breached'. Wartość należy odwrócić, np. MadeSLA = NOT has_breached.

Przykłady
truefalse
Czas realizacji zgłoszenia
CaseCycleTime
Łączny czas od utworzenia zgłoszenia serwisowego do jego ostatecznego zamknięcia.
Opis

Czas realizacji zgłoszenia to obliczany miernik całkowitego czasu obsługi, od znacznika czasu pierwszego zdarzenia do znacznika czasu ostatniego zdarzenia. Pokazuje pełny czas realizacji procesu z perspektywy klienta.

To podstawowy KPI sprawności całego procesu. Na dashboardach wysokiego poziomu służy do monitorowania wyników względem celów i analizy zmian w czasie. Można go analizować według kategorii, priorytetu i innych wymiarów, aby ustalić, które zgłoszenia trwają najdłużej.

Dlaczego to ważne

To ważny KPI mierzący skuteczność procesu od początku do końca. Służy do monitorowania wyników na wysokim poziomie, porównywania ich z innymi okresami lub jednostkami oraz wskazywania obszarów do usprawnienia.

Skąd pobrać

Obliczany dla każdego unikalnego 'ServiceRequestID' przez odjęcie minimalnej wartości 'StartTime' od maksymalnej wartości 'EndTime'.

Przykłady
2 10:30:000 04:15:2210 00:05:00
Czas zakończenia
EndTime
Znacznik czasu określający moment zakończenia działania lub zdarzenia.
Opis

Czas zakończenia oznacza koniec działania. Jest równy znacznikowi czasu kolejnego działania w sekwencji, który wyznacza koniec trwania bieżącego działania. Atrybut ten jest niezbędny do obliczenia czasu potrzebnego na każdy krok procesu.

Porównując czas rozpoczęcia i zakończenia działania, analitycy mogą obliczyć czas przetwarzania i oczekiwania. To podstawa wykrywania wąskich gardeł, oceny wykorzystania zasobów i monitorowania wyników względem celów czasowych.

Dlaczego to ważne

Ten atrybut jest potrzebny do obliczania czasu trwania każdego działania. To ważny element analizy wyników, wykrywania wąskich gardeł i badania wykorzystania zasobów.

Skąd pobrać

To atrybut pochodny, obliczany na podstawie pola „StartTime” kolejnego zdarzenia w danym case.

Przykłady
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
Kanał
ContactType
Sposób, w jaki zgłaszający przesłał zgłoszenie serwisowe.
Opis

Typ kontaktu, czyli kanał, określa sposób zgłoszenia sprawy. Typowe kanały to portal usług, e-mail, telefon lub automatyczne powiadomienie.

Znajomość kanału pomaga analizować różnice w przebiegu procesu wynikające ze sposobu zgłoszenia. Zgłoszenia przesłane przez portal mogą na przykład zawierać bardziej uporządkowane informacje i być obsługiwane automatycznie, dzięki czemu ich realizacja trwa krócej niż w przypadku zgłoszeń e-mailowych. Analiza pozwala promować sprawniejsze kanały.

Dlaczego to ważne

Pomaga ustalić, jak kanał zgłoszenia wpływa na sprawność procesu, poziom automatyzacji i całkowity czas realizacji. Ułatwia też usprawnianie kontaktu z użytkownikami.

Skąd pobrać

Tabele ServiceNow Request [sc_request] lub Interaction [interaction]. Pole często nosi nazwę 'contact_type'.

Przykłady
PortalE-mailTelefonSamoobsługa
Kod rozwiązania
ResolutionCode
Kod określający sposób ostatecznego rozwiązania zgłoszenia serwisowego.
Opis

Kod rozwiązania to uporządkowana klasyfikacja sposobu, w jaki ostatecznie rozwiązano zgłoszenie serwisowe. Przykłady: „Zrealizowano automatycznie”, „Błąd użytkownika” lub „Nie jest już wymagane”.

Ten atrybut jest ważny przy analizie przyczyn opóźnień na dashboardzie. Powiązanie kodów rozwiązania z długim czasem realizacji lub częstą ponowną pracą pomaga wykrywać problemy systemowe. Jeśli na przykład zgłoszenia oznaczone jako „Niepełne informacje” są regularnie obsługiwane długo, może to wskazywać na problem z gromadzeniem danych na początku procesu.

Dlaczego to ważne

Dostarcza uporządkowanych danych o wynikach rozwiązywania zgłoszeń, co ułatwia analizę przyczyn opóźnień, ponownej pracy i innych nieefektywności.

Skąd pobrać

Tabela ServiceNow Request Item [sc_req_item] lub powiązana tabela zadań. Pole często nosi nazwę 'close_code' lub 'resolution_code'.

Przykłady
Rozwiązano (trwale)Nie rozwiązano (nie można odtworzyć problemu)Zrealizowano wniosekAnulowano przez użytkownika
Liczba ponownych otwarć
ReopenCount
Liczba ponownych otwarć zgłoszenia serwisowego po jego rozwiązaniu.
Opis

Ten atrybut zlicza, ile razy zgłoszenie serwisowe zmieniło status z rozwiązane lub zamknięte na otwarte albo w trakcie realizacji. Wynik większy od zera oznacza, że pierwsza próba rozwiązania nie była skuteczna.

Miernik bezpośrednio pokazuje konieczność ponownej pracy i jest jednym ze składników KPI dotyczącego skuteczności rozwiązania przy pierwszym podejściu. Duża liczba ponownych otwarć może świadczyć o niskiej jakości rozwiązania, niepełnej realizacji lub niezrozumieniu potrzeb użytkownika. Wszystkie te problemy obniżają sprawność procesu i satysfakcję użytkowników.

Dlaczego to ważne

Pozwala zmierzyć ponowną pracę i jakość rozwiązań. Duża liczba ponownych otwarć wskazuje na nieefektywność, niski odsetek skutecznych rozwiązań za pierwszym razem i spadek satysfakcji klientów.

Skąd pobrać

Tabele ServiceNow Request [sc_request] lub Request Item [sc_req_item], pole 'reopen_count'.

Przykłady
012
Ocena satysfakcji
SatisfactionScore
Ocena satysfakcji klienta przekazana przez zgłaszającego po zamknięciu sprawy.
Opis

Ten atrybut przechowuje ocenę satysfakcji, często w skali od 1 do 5, którą użytkownik końcowy wystawia po rozwiązaniu zgłoszenia serwisowego. To bezpośredni miernik postrzeganej jakości usługi.

Dane te są niezbędne do analizy wpływu procesu na satysfakcję klienta na dashboardzie. Pozwalają bezpośrednio powiązać mierniki procesu, takie jak czas realizacji, ponowna praca i przekazania między zespołami, z doświadczeniem klienta. Dzięki temu można uzasadnić biznesowe korzyści z usprawnień, łącząc sprawność operacyjną z wynikami odczuwanymi przez klientów.

Dlaczego to ważne

Łączy mierniki skuteczności procesu z wynikami odczuwanymi przez klientów i pomaga określić, jak nieefektywność procesu wpływa na doświadczenia użytkowników.

Skąd pobrać

Zwykle znajduje się w powiązanej tabeli Survey [asmt_assessment_instance], połączonej z pierwotnym zgłoszeniem.

Przykłady
5431
Ponowna praca
IsRework
Obliczany wskaźnik określający, czy działanie jest powtórzeniem wcześniejszego działania w tej samej sprawie.
Opis

Ten wskaźnik logiczny służy do wykrywania pętli ponownej pracy w obsłudze zgłoszenia serwisowego. Przyjmuje wartość 'true', jeśli to samo działanie wystąpiło już wcześniej w tej samej sprawie. Może tak być na przykład wtedy, gdy zgłoszenie zostanie dwukrotnie przypisane do tego samego zespołu albo gdy użytkownik kilkakrotnie otrzyma prośbę o podanie informacji.

Ten atrybut jest niezbędny na dashboardzie przekazań między pracownikami i przypadków ponownej pracy oraz przy obliczaniu KPI dotyczącego ponownej pracy nad zgłoszeniami. Pozwala bezpośrednio pokazać i zmierzyć nieefektywne pętle procesu, które często giną w danych zbiorczych.

Dlaczego to ważne

Bezpośrednio wskazuje i mierzy ponowną pracę w procesie, dzięki czemu można analizować przyczyny i skutki nieefektywnych pętli, które zwiększają koszty i wydłużają czas realizacji.

Skąd pobrać

Obliczany podczas przekształcania danych przez sprawdzenie, czy w tej samej sprawie wcześniej wystąpiła aktywność o tej samej nazwie.

Przykłady
falsetrue
Rozwiązanie przy pierwszym podejściu
IsFirstPassResolution
Wskaźnik określający, czy zgłoszenie rozwiązano za pierwszym razem i nie otwierano go ponownie.
Opis

Ten obliczany atrybut logiczny przyjmuje wartość 'true' tylko wtedy, gdy zgłoszenie serwisowe zostało rozwiązane i zamknięte bez ponownego otwarcia. Wskazuje jakość i skuteczność rozwiązania zapewnionego przez service desk.

Miernik ten bezpośrednio wspiera KPI dotyczący odsetka rozwiązań przy pierwszym podejściu. Wysoki wynik jest pożądany, ponieważ oznacza sprawną obsługę i wysoką jakość usług, co przekłada się na większą satysfakcję klientów. Analiza zgłoszeń, których nie udało się rozwiązać przy pierwszym podejściu, może ujawnić przyczyny, takie jak niewystarczające szkolenia, nieaktualna dokumentacja lub błędna wstępna diagnoza.

Dlaczego to ważne

Mierzy jakość i sprawność procesu rozwiązywania zgłoszeń. Niski odsetek rozwiązań przy pierwszym podejściu wskazuje na problemy prowadzące do ponownej pracy i frustracji klientów.

Skąd pobrać

Obliczany na poziomie sprawy. Sprawę uznaje się za rozwiązaną przy pierwszym podejściu, jeśli jej 'ReopenCount' wynosi zero.

Przykłady
truefalse
Wykonane automatycznie
IsAutomated
Wskaźnik określający, czy działanie wykonał system lub mechanizm automatyzacji.
Opis

Ten atrybut logiczny rozróżnia działania wykonane ręcznie przez pracownika od działań realizowanych przez system automatyczny, na przykład workflow lub integrację. Przykładowo wysłanie prośby o zatwierdzenie może być automatyczne, a przypisanie zgłoszenia do pracownika może wymagać działania ręcznego.

Analiza tego atrybutu pozwala mierzyć i zwiększać poziom automatyzacji procesu obsługi zgłoszeń serwisowych. Pomaga wskazać zadania ręczne, które zajmują najwięcej czasu i mogą zostać zautomatyzowane w przyszłości. Zwiększa to sprawność i obniża koszty.

Dlaczego to ważne

Pozwala mierzyć poziom automatyzacji i wskazywać zadania ręczne, które można zautomatyzować, aby zwiększyć sprawność i obniżyć koszty operacyjne.

Skąd pobrać

Ustalane na podstawie tego, czy użytkownik wykonujący działanie, np. 'sys_updated_by', jest wskazanym użytkownikiem systemowym lub integracyjnym.

Przykłady
truefalse
Zgłaszający
OpenedBy
Osoba, która jako pierwsza przesłała zgłoszenie serwisowe.
Opis

Ten atrybut wskazuje użytkownika, który utworzył zgłoszenie serwisowe. Często jest to osoba, której dotyczy zgłoszenie, ale może nim być także kierownik, pełnomocnik lub system automatyczny.

Analiza zgłoszeń według użytkownika, który je otworzył, lub jego działu pomaga wykrywać wzorce. Może na przykład ujawnić grupę użytkowników, która często przesyła złożone lub problematyczne zgłoszenia. Takie informacje mogą pomóc zaplanować szkolenia lub wskazać potrzebę uzupełnienia bazy wiedzy, aby zachęcić do samoobsługi.

Dlaczego to ważne

Ułatwia analizę zgłoszeń według użytkownika, działu lub roli. Wyniki mogą pomóc w planowaniu szkoleń i ukierunkowanych usprawnień procesu.

Skąd pobrać

Tabela ServiceNow Request [sc_request], pole 'opened_by'.

Przykłady
Abel TuterFred LuddyDon Goodliffe
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania zgłoszeniami serwisowymi

Poniżej przedstawiono najważniejsze kroki i kamienie milowe, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkrywać przebieg procesu i identyfikować wąskie gardła.
6 Zalecane 8 Opcjonalne
Działanie Opis
Akceptacja zgłoszenia
To działanie oznacza formalne zatwierdzenie zgłoszenia, które może przejść do realizacji. Jest rejestrowane, gdy osoba zatwierdzająca oznaczy powiązany rekord akceptacji jako „approved”.
Dlaczego to ważne

Ten ważny etap oznacza przejście od akceptacji do realizacji. Analiza czasu potrzebnego na jego osiągnięcie pomaga zrozumieć opóźnienia przed rozpoczęciem realizacji.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu powiązanego rekordu sysapproval_approver na „approved”, która następnie powoduje zmianę stanu w sc_req_item.

Rejestrowanie

Należy ustalić znacznik czasu zmiany sysapproval_approver.state na „approved”.

Typ zdarzenia inferred
Prośba o informacje od użytkownika
Zdarzenie występuje, gdy osoba realizująca zgłoszenie potrzebuje dodatkowych informacji od pierwotnego zgłaszającego. Jest zwykle wnioskowane na podstawie zmiany stanu zgłoszenia na wartość taką jak „Awaiting User Info”.
Dlaczego to ważne

To działanie ma znaczenie dla dashboardu „Analiza opóźnień spowodowanych oczekiwaniem na informacje od zgłaszającego”. Pozwala określić czas stracony na oczekiwanie na odpowiedź użytkownika.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu w sc_req_item na określony status oczekiwania na informacje. Zmiana jest rejestrowana w tabeli sys_audit.

Rejestrowanie

Należy ustalić znacznik czasu zmiany sc_req_item.state na „Awaiting User Info”.

Typ zdarzenia inferred
Przypisanie zgłoszenia do konsultanta
To działanie występuje, gdy konkretna osoba zostaje przypisana do obsługi zgłoszenia serwisowego. Jest rejestrowane przez monitorowanie zmian pola „Assigned to” w zgłoszeniu lub powiązanych zadaniach realizacyjnych.
Dlaczego to ważne

Dane te są niezbędne do mierzenia przekazań między osobami, obliczania obciążenia poszczególnych konsultantów i analizy czasu oczekiwania przed rozpoczęciem pracy nad zgłoszeniem.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola assigned_to w tabeli sc_req_item lub sc_task. Historia zmian jest zapisywana w tabeli sys_audit.

Rejestrowanie

Należy śledzić zmiany pola assigned_to w sys_audit.

Typ zdarzenia inferred
Rozwiązanie zgłoszenia serwisowego
To działanie oznacza zakończenie pracy przez osobę realizującą zgłoszenie i przekazanie rozwiązania. Jest rejestrowane, gdy stan zgłoszenia zmienia się na „Resolved” lub podobny status.
Dlaczego to ważne

To ważny etap, który zwykle zatrzymuje naliczanie czasu SLA. Oznacza koniec aktywnej realizacji i jest uwzględniany przy obliczaniu całkowitego czasu rozwiązania zgłoszenia.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu w sc_req_item na „Resolved” lub podobny stan końcowy przed ostatecznym zamknięciem. Zmiana jest rejestrowana w tabeli sys_audit.

Rejestrowanie

Należy ustalić znacznik czasu zmiany sc_req_item.state na „Resolved”.

Typ zdarzenia inferred
Utworzenie zgłoszenia serwisowego
To działanie rozpoczyna obsługę zgłoszenia serwisowego. Jest rejestrowane, gdy użytkownik składa zgłoszenie za pośrednictwem katalogu usług. System zapisuje je jako zdarzenie utworzenia nowego rekordu w tabeli sc_req_item (Requested Item).
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Jest niezbędne do obliczania całkowitego czasu obsługi oraz analizy liczby i wzorców składania zgłoszeń.

Skąd pobrać

To jawne zdarzenie odczytywane ze znacznika czasu utworzenia rekordu (pole sys_created_on) w tabeli sc_req_item.

Rejestrowanie

Należy użyć znacznika czasu sys_created_on z rekordu sc_req_item.

Typ zdarzenia explicit
Zamknięcie zgłoszenia serwisowego
Oznacza ostateczny koniec obsługi zgłoszenia serwisowego. Zwykle następuje automatycznie po upływie określonego czasu w stanie „Resolved”. W tym czasie użytkownik może ponownie otworzyć zgłoszenie.
Dlaczego to ważne

To główne zdarzenie oznaczające pomyślne zakończenie procesu. Analiza czasu między stanami „Resolved” i „Closed” pozwala również ocenić zasady automatycznego zamykania zgłoszeń.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu w sc_req_item na końcowy stan zamknięcia, taki jak „Closed Complete”. Zmiana jest rejestrowana w tabeli sys_audit.

Rejestrowanie

Należy ustalić znacznik czasu zmiany sc_req_item.state na „Closed Complete”.

Typ zdarzenia inferred
Anulowanie zgłoszenia
To końcowy stan zgłoszenia anulowanego przed realizacją, przez użytkownika lub osobę obsługującą. Zdarzenie jest rejestrowane, gdy stan zgłoszenia zmienia się na „Cancelled” lub „Closed Cancelled”.
Dlaczego to ważne

To ważne zdarzenie oznaczające niepomyślne zakończenie procesu. Analiza przyczyn anulowania zgłoszeń może dostarczyć informacji o potrzebach użytkowników, nieefektywności procesu lub zmieniających się priorytetach biznesowych.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu w sc_req_item na końcowy stan anulowania, taki jak „Closed Cancelled”. Zmiana jest rejestrowana w tabeli sys_audit.

Rejestrowanie

Należy ustalić znacznik czasu zmiany sc_req_item.state na „Cancelled”.

Typ zdarzenia inferred
Odrzucenie zgłoszenia
To działanie oznacza formalne odrzucenie zgłoszenia na etapie akceptacji. Jest to alternatywna ścieżka zakończenia procesu. Zdarzenie jest rejestrowane, gdy osoba zatwierdzająca oznaczy zgłoszenie jako „rejected”.
Dlaczego to ważne

Śledzenie odrzuceń pomaga wykrywać nieprawidłowe lub błędnie skierowane zgłoszenia oraz problemy z ich składaniem. Odrzucenie stanowi też ważną ścieżkę wyjątkową do analizy.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu powiązanego rekordu sysapproval_approver na „rejected”. Zwykle powoduje to zmianę stanu nadrzędnego rekordu sc_req_item na zamknięty, niekompletny.

Rejestrowanie

Należy ustalić znacznik czasu zmiany sysapproval_approver.state na „rejected”.

Typ zdarzenia inferred
Ponowne otwarcie zgłoszenia
To działanie rejestruje przypadki, w których zgłoszenie oznaczone wcześniej jako rozwiązane wraca do stanu otwartego. Jest wnioskowane na podstawie zmiany stanu z „Resolved” na „Work in Progress” lub podobny.
Dlaczego to ważne

To bezpośrednia miara poprawek, niezbędna do obliczania KPI „Odsetek zgłoszeń rozwiązanych za pierwszym razem”. Wysoka wartość może wskazywać na niską jakość rozwiązania lub niepełną realizację.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu w sc_req_item ze stanu rozwiązania lub zamknięcia na stan otwarty albo w trakcie realizacji. Zmiana jest rejestrowana w sys_audit.

Rejestrowanie

Należy wykryć w sys_audit zmianę stanu z „Resolved” na „Work in Progress”.

Typ zdarzenia inferred
Przekazanie informacji przez użytkownika
To działanie oznacza moment przekazania potrzebnych informacji przez zgłaszającego. Jest wnioskowane, gdy zgłoszenie przechodzi ze stanu „Awaiting User Info” do aktywnego stanu, takiego jak „Work in Progress”.
Dlaczego to ważne

W połączeniu z działaniem „Prośba o informacje od użytkownika” pozwala dokładnie mierzyć opóźnienia spowodowane oczekiwaniem na użytkownika i oceniać sprawność komunikacji.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu w sc_req_item ze statusu oczekiwania na informacje na status aktywny. Często wywołuje je dodanie komentarza przez użytkownika lub odpowiedź na e-mail.

Rejestrowanie

Należy ustalić znacznik czasu zmiany stanu z „Awaiting User Info” na „Work in Progress”.

Typ zdarzenia inferred
Przypisanie zgłoszenia do grupy
Oznacza przypisanie zgłoszenia serwisowego do konkretnego zespołu lub grupy realizującej. Zdarzenie jest wnioskowane na podstawie zmiany pola grupy przypisania w zgłoszeniu lub powiązanych z nim zadaniach.
Dlaczego to ważne

Śledzenie przypisań do grup pozwala analizować rozkład obciążenia między zespołami i wykrywać opóźnienia, zanim zgłoszenie trafi do właściwych osób realizujących.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola assignment_group w tabeli sc_req_item lub sc_task. Historia zmian jest zapisywana w tabeli sys_audit.

Rejestrowanie

Należy śledzić zmiany pola assignment_group w sys_audit.

Typ zdarzenia inferred
Utworzenie zadania realizacyjnego
Oznacza utworzenie konkretnego zadania lub elementu pracy potrzebnego do realizacji zgłoszenia serwisowego. To jawne zdarzenie rejestrowane przy utworzeniu nowego rekordu w tabeli Catalog Task.
Dlaczego to ważne

W przypadku złożonych zgłoszeń analiza utworzenia i zakończenia poszczególnych zadań pozwala dokładniej prześledzić realizację i wskazać miejsca, w których pojawiają się opóźnienia.

Skąd pobrać

To jawne zdarzenie odczytywane ze znacznika czasu utworzenia rekordu (pole sys_created_on) w tabeli sc_task, powiązanego z sc_req_item.

Rejestrowanie

Należy użyć znacznika czasu sys_created_on z rekordów sc_task.

Typ zdarzenia explicit
Wysłanie prośby o akceptację
Oznacza moment przekazania zgłoszenia do akceptacji przez kierownika lub inną wyznaczoną osobę. Zdarzenie jest zwykle wnioskowane na podstawie zmiany stanu zgłoszenia na „Pending Approval” lub podobny status.
Dlaczego to ważne

Śledzenie akceptacji pomaga wykrywać wąskie gardła w procesie zatwierdzania i mierzyć czas oczekiwania na zgodę przed rozpoczęciem realizacji zgłoszenia.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie zmiany pola stanu w sc_req_item na wartość oznaczającą oczekiwanie na akceptację albo utworzenia powiązanego rekordu w tabeli sysapproval_approver. Zmiany są rejestrowane w tabeli sys_audit.

Rejestrowanie

Należy ustalić znacznik czasu zmiany sc_req_item.state na „Pending Approval”.

Typ zdarzenia inferred
Zaangażowanie zewnętrznego dostawcy
Oznacza przekazanie zgłoszenia serwisowego lub jednego z jego zadań zewnętrznemu dostawcy do realizacji. Zdarzenie można wywnioskować z przypisania do grupy dostawcy lub odpowiedniego pola w zgłoszeniu.
Dlaczego to ważne

To działanie pozwala analizować wyniki pracy dostawcy i jego wpływ na cały przebieg obsługi zgłoszenia. Jest potrzebne do dashboardu „Cykl współpracy z zewnętrznym dostawcą”.

Skąd pobrać

Zdarzenie jest zwykle wnioskowane. Może wynikać z przypisania do grupy dostawcy w polu assignment_group lub ustawienia odpowiedniego pola w rekordzie sc_req_item albo sc_task.

Rejestrowanie

Należy wykryć zmianę assignment_group na znaną grupę dostawcy.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z ServiceNow

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby rozpocząć analizę procesu zarządzania zgłoszeniami serwisowymi i znaleźć możliwości zwiększenia efektywności. Zacznij usprawniać workflow już dziś, aby szybciej rozwiązywać zgłoszenia i poprawić zadowolenie klientów.

Usprawnij zarządzanie zgłoszeniami serwisowymi już teraz

Osiągnij 70% automatyzacji i szybciej rozwiązuj zgłoszenia serwisowe.

Rozpocznij bezpłatny okres próbny

Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.