Szablon danych do analizy obsługi zgłoszeń serwisowych
Szablon danych do analizy obsługi zgłoszeń serwisowych
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia podczas odkrywania procesu
- Instrukcja eksportu danych krok po kroku
Atrybuty procesu zarządzania zgłoszeniami serwisowymi
| 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
|
|||
Działania w procesie zarządzania zgłoszeniami serwisowymi
| 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
|
|||
Instrukcje pobierania danych
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.
Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.