> Ciągłe doskonalenie procesów > Zarządzanie zgłoszeniami serwisowymi > Ivanti Service Manager > Szablon danych

Szablon danych do zarządzania zgłoszeniami serwisowymi

Ivanti Service Manager

← Wróć do przewodnika ulepszania procesów

Atrybuty zarządzania zgłoszeniami serwisowymi(21) Działania w procesie zarządzania zgłoszeniami serwisowymi(14) Instrukcje wyodrębniania danych(2)

Szablon danych do zarządzania zgłoszeniami serwisowymi

Ten szablon zawiera wskazówki dotyczące zbierania danych potrzebnych do skutecznego process mining w obszarze zarządzania zgłoszeniami serwisowymi. Opisuje najważniejsze atrybuty do uwzględnienia i działania do śledzenia, a także podpowiada, jak wyodrębnić te informacje z systemu. Skorzystaj z niego, aby przygotować dziennik zdarzeń do analizy.

Zalecane atrybuty do szczegółowej analizy
Najważniejsze działania do śledzenia podczas odkrywania procesu
Wskazówki dotyczące wyodrębniania danych z systemu źródłowego

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty zarządzania zgłoszeniami serwisowymi

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby kompleksowo przeanalizować proces zarządzania zgłoszeniami serwisowymi.

5 Wymagane 9 Zalecane 7 Opcjonalne

	Nazwa	Opis
	Czas zdarzenia EventTime	Znacznik czasu wskazujący, kiedy wystąpiło określone działanie lub zdarzenie.
Opis Czas zdarzenia, nazywany również czasem rozpoczęcia, to dokładna data i godzina zarejestrowania działania w systemie. Ten znacznik czasu pozwala prawidłowo ustalić kolejność zdarzeń i stanowi podstawę analiz process mining opartych na czasie, takich jak obliczanie czasu realizacji, czasu oczekiwania i czasu trwania działań. Dlaczego to ważne Ten znacznik czasu jest niezbędny do chronologicznego uporządkowania zdarzeń i obliczania wszystkich wskaźników opartych na czasie, które są ważne przy analizie efektywności. Skąd pobrać Dane można znaleźć w dziennikach audytu, wpisach w dzienniku, na przykład Journal.CreatedDateTime, lub rekordach zmian statusu powiązanych ze zgłoszeniem Service Request. Przykłady 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Nazwa działania ActivityName	Nazwa zdarzenia lub zadania, które wystąpiło w określonym momencie cyklu życia zgłoszenia serwisowego.
Opis Ten atrybut opisuje konkretny krok lub zmianę statusu w procesie obsługi zgłoszenia serwisowego, na przykład „Przekazanie zgłoszenia do akceptacji” lub „Rozwiązanie zgłoszenia serwisowego”. Analiza kolejności i częstotliwości działań pomaga zrozumieć przebieg procesu, wykrywać wąskie gardła i znajdować odstępstwa od standardowej procedury. Dlaczego to ważne Atrybut określa kroki na mapie procesu, dzięki czemu można wizualizować i analizować jego przebieg oraz wykrywać poprawki, wąskie gardła i odstępstwa. Skąd pobrać Zwykle na podstawie zmian statusu, wpisów w dzienniku lub opisów zdarzeń w dzienniku audytu Ivanti Service Manager. Przykłady Utworzenie zgłoszenia serwisowegoAkceptacja zgłoszeniaRozwiązanie zgłoszenia serwisowegoZamknięcie zgłoszenia serwisowego
	Service Request ID ServiceRequestID	Unikalny identyfikator każdego zgłoszenia serwisowego.
Opis Service Request ID 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, dzięki czemu można przeanalizować przebieg każdego zgłoszenia od początku do końca. Dlaczego to ważne To podstawowy identyfikator sprawy, który łączy wszystkie powiązane działania w jedną instancję procesu i umożliwia analizę procesu od początku do końca. Skąd pobrać To klucz główny obiektu biznesowego Service Request, często zapisany jako ServiceReqNumber w tabeli ServiceReq. Przykłady SR-0012345SR-0012346SR-0012347
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu ostatniego odświeżenia danych z systemu źródłowego.
Opis Ten atrybut wskazuje datę i godzinę ostatniego wyodrębnienia danych z Ivanti Service Manager. Informuje, jak aktualne są analizowane dane, jaki okres obejmuje analiza i kiedy można spodziewać się kolejnej aktualizacji. Dlaczego to ważne Informuje o aktualności danych, co ma znaczenie przy podejmowaniu decyzji na podstawie najnowszych dostępnych informacji o efektywności procesu. Skąd pobrać Wartość jest generowana i zapisywana w zbiorze danych podczas ich wyodrębniania. Przykłady 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	System źródłowy SourceSystem	System, z którego wyodrębniono dane.
Opis Ten atrybut wskazuje źródło danych o procesie. W tym widoku jego wartość będzie stała i będzie oznaczać, że wszystkie dane pochodzą z Ivanti Service Manager. Jest to ważne w środowiskach, w których łączy się dane z wielu systemów, ponieważ pozwala zachować jasną informację o ich pochodzeniu i kontekście. Dlaczego to ważne Atrybut dostarcza informacji o pochodzeniu danych i pozwala prawidłowo przypisać wyniki analizy do konkretnego systemu źródłowego, zwłaszcza w środowiskach korzystających z wielu systemów. Skąd pobrać Zwykle jest to stała wartość dodawana podczas wyodrębniania danych, aby oznaczyć źródło zbioru. Przykłady Ivanti Service Manager
	Czas zakończenia zdarzenia EventEndTime	Znacznik czasu wskazujący, kiedy zakończono działanie.
Opis Czas zakończenia zdarzenia oznacza moment zakończenia działania. Czas między czasem zdarzenia (rozpoczęciem) a jego zakończeniem to czas realizacji danego działania. Pozwala ustalić, które etapy procesu trwają najdłużej, a tym samym wskazać nieefektywne działania i obszary wymagające usprawnień. Dlaczego to ważne Umożliwia obliczenie czasu trwania poszczególnych działań, co pomaga wykrywać wąskie gardła procesu i zadania trwające zbyt długo. Skąd pobrać To pole może nie występować osobno. Często jego wartość odpowiada godzinie rozpoczęcia kolejnego działania w sekwencji dla tego samego case. Przykłady 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Priorytet Priority	Poziom priorytetu przypisany do zgłoszenia serwisowego.
Opis Priorytet określa pilność zgłoszenia serwisowego. Zwykle stosuje się poziomy takie jak „Niski”, „Średni”, „Wysoki” i „Krytyczny”. Analiza pozwala ocenić, czy zgłoszenia o wysokim priorytecie są obsługiwane szybciej. W tym celu porównuje się czas realizacji i zgodność z SLA dla poszczególnych poziomów priorytetu, aby sprawdzić, czy zasady priorytetyzacji działają zgodnie z założeniami. Dlaczego to ważne Pozwala ocenić skuteczność zasad priorytetyzacji i sprawdzić, czy zgłoszenia o wysokim priorytecie są rozwiązywane szybciej niż te o niskim priorytecie. Skąd pobrać Standardowe pole obiektu Service Request, zwykle nazwane „Priority”. Przykłady 1 - Krytyczny2 - Wysoki3 - Średni4 - Niski
	Przypisany agent AssignedAgent	Użytkownik lub agent przypisany do obsługi zgłoszenia serwisowego.
Opis Przypisany agent to konkretna osoba odpowiedzialna za obsługę zgłoszenia serwisowego. Analiza na poziomie poszczególnych osób pomaga oceniać wyniki pracy, równoważyć obciążenie i wskazywać potrzeby szkoleniowe. Śledzenie zmian przypisania między agentami pozwala obliczać KPI, takie jak „Średnia liczba zmian przypisania na zgłoszenie”, i wykrywać nieefektywności procesu. Dlaczego to ważne Umożliwia analizę obciążenia i wyników pracy poszczególnych osób oraz wzorców zmian przypisania. Może to pomóc wykryć problemy ze szkoleniem, kompetencjami lub początkowym kierowaniem zgłoszeń. Skąd pobrać Zwykle jest to pole takie jak „Owner” w obiekcie Service Request. Jego wartość może się zmieniać przy każdym ponownym przypisaniu, dlatego należy ją rejestrować w dzienniku zdarzeń. Przykłady Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Przypisany zespół AssignedTeam	Zespół lub grupa wsparcia aktualnie odpowiedzialna za obsługę zgłoszenia serwisowego.
Opis Ten atrybut wskazuje zespół odpowiedzialny za obsługę zgłoszenia serwisowego w danym momencie. Analiza przekazywania zgłoszeń między zespołami, czasu obsługi przez każdy zespół oraz liczby obsługiwanych zgłoszeń pomaga zrozumieć rozkład obciążenia, wykrywać wąskie gardła i oceniać wyniki pracy zespołów. Dane te są też przydatne w dashboardach dotyczących zgodności z SLA i obciążenia agentów. Dlaczego to ważne Pozwala śledzić odpowiedzialność za zgłoszenia i przekazywanie ich między zespołami. Dzięki temu można analizować opóźnienia między zespołami, równomierne rozłożenie obciążenia oraz wskazywać zespoły będące wąskim gardłem procesu. Skąd pobrać Informacja ta jest zwykle zapisana w polu takim jak „OwnerTeam” obiektu Service Request lub w powiązanych rekordach przypisań. Przykłady Dział wsparcia ITOperacje siecioweWsparcie HRZarządzanie obiektami
	Status SLA SLAStatus	Informuje, czy zgłoszenie serwisowe rozwiązano przed upływem terminu SLA.
Opis Ten atrybut pochodny oznacza każde zgłoszenie serwisowe jako „Dotrzymano” lub „Przekroczono”, zależnie od tego, czy rozwiązano je przed upływem terminu SLA. Stanowi podstawę dashboardu „Wyniki zgodności z SLA” i KPI „Poziom zgodności z umową o poziomie usług”. Wartość jest obliczana przez porównanie ResolutionDateTime z SLADeadline dla każdego case. Dlaczego to ważne Bezpośrednio mierzy realizację zobowiązań dotyczących usług. Pomaga oceniać ich jakość i utrzymywać zaufanie użytkowników. Skąd pobrać Oblicza się go przez porównanie „ResolutionDateTime” z „SLADeadline”. Jeśli ResolutionDateTime <= SLADeadline, status to „Dotrzymano”. W przeciwnym razie status to „Przekroczono”. Przykłady DotrzymanoPrzekroczono
	Status zgłoszenia serwisowego ServiceRequestStatus	Status zgłoszenia serwisowego w chwili wystąpienia zdarzenia.
Opis Ten atrybut określa stan zgłoszenia serwisowego, na przykład „Zarejestrowane”, „W trakcie”, „Oczekujące”, „Rozwiązane” lub „Zamknięte”. Zmiany statusu często wyznaczają działania w dzienniku procesu. Analiza czasu spędzonego w każdym statusie może ujawnić wąskie gardła, na przykład zgłoszenia zbyt długo oczekujące. Dlaczego to ważne Pokazuje stan zgłoszenia w danym momencie. Pozwala obliczyć czas spędzony w poszczególnych stanach i wykryć przestoje w procesie. Skąd pobrać Standardowe pole obiektu Service Request, zwykle nazwane „Status”. Przykłady ZarejestrowaneAktywneOczekiwanie na klientaZrealizowaneZamknięte
	Termin SLA SLADeadline	Znacznik czasu określający, do kiedy należy rozwiązać zgłoszenie serwisowe.
Opis Termin SLA to obliczona data i godzina, do której należy rozwiązać zgłoszenie serwisowe, aby dotrzymać warunków umowy o poziomie usług. Termin jest zwykle ustalany na podstawie takich czynników jak priorytet i typ zgłoszenia. Porównanie rzeczywistego czasu rozwiązania z tym terminem pozwala mierzyć zgodność z SLA. Dlaczego to ważne To punkt odniesienia do oceny rzeczywistych wyników. Pozwala obliczać poziom zgodności z SLA i wskazywać zgłoszenia zagrożone opóźnieniem. Skąd pobrać Często jest to pole obliczane w Ivanti i przechowywane w polach związanych z umową o poziomie usług lub ofertą, na przykład „ResolutionTargetDateTime”. Przykłady 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Typ zgłoszenia serwisowego ServiceRequestType	Klasyfikacja lub kategoria zgłoszenia serwisowego.
Opis Ten atrybut określa kategorię zgłoszenia serwisowego, na przykład „Zamówienie sprzętu”, „Instalacja oprogramowania” lub „Reset hasła”. Umożliwia porównywanie wyników procesu, czasu realizacji i zgodności z SLA dla różnych typów usług. Analiza tych różnic pomaga dostosować usprawnienia procesów i lepiej przydzielać zasoby. Dlaczego to ważne Podział procesu według typu zgłoszenia pozwala skupić analizę na konkretnych obszarach i sprawdzić, czy niektóre zgłoszenia częściej się opóźniają, wymagają ponownej pracy lub nie spełniają wymagań SLA. Skąd pobrać Prawdopodobnie jest to pole obiektu biznesowego Service Request, często nazwane „Service” lub „Category”. Nazwy konkretnych pól, takich jak „SvcReqTmplLink_Category”, można sprawdzić w dokumentacji Ivanti Service Manager. Przykłady Zamówienie nowego sprzętuDostęp do oprogramowaniaZmiana kontaZapytanie informacyjne
	Znacznik czasu rozwiązania ResolutionDateTime	Data i godzina oficjalnego rozwiązania zgłoszenia serwisowego.
Opis To atrybut na poziomie case, który wskazuje końcowy moment dostarczenia usługi lub usunięcia problemu, przed formalnym zamknięciem zgłoszenia. Ten znacznik czasu jest podstawą do obliczenia całkowitego czasu realizacji zgłoszenia serwisowego. Pomaga mierzyć ogólną efektywność procesu i zgodność z SLA. Dlaczego to ważne Wyznacza koniec okresu używanego do obliczenia czasu realizacji całego procesu. Jest to ważny wskaźnik efektywności świadczenia usług. Skąd pobrać Osobne pole ze znacznikiem czasu w obiekcie Service Request, często nazwane „ResolvedDateTime” lub podobnie. Przykłady 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Czy wymagało ponownej pracy IsRework	Wartość logiczna wskazująca, czy obsługa zgłoszenia serwisowego wymagała ponownej pracy.
Opis Ta obliczana flaga przyjmuje wartość true, jeśli zgłoszenie serwisowe nosi ślady ponownej pracy, na przykład zostało ponownie otwarte po rozwiązaniu lub niektóre działania powtarzały się w pętli. Ułatwia obliczanie KPI „Odsetek zgłoszeń serwisowych wymagających ponownej pracy” i filtrowanie nieefektywnych przypadków w dashboardach, takich jak „Przepływy ponownej pracy i zmiany przypisania”. Dlaczego to ważne Ułatwia wskazanie i policzenie zgłoszeń wymagających dodatkowej, nieplanowanej pracy, co pozwala wykrywać problemy z jakością i efektywnością. Skąd pobrać Wartość wyliczana na podstawie danych. Można ją ustalić na podstawie atrybutu „ReopenCount” większego od zera lub wykrywania określonych sekwencji działań, takich jak wielokrotne zdarzenia „Assigned to Agent”. Przykłady truefalse
	Dział zgłaszającego RequestorDepartment	Dział, w którym pracuje użytkownik, który przesłał zgłoszenie serwisowe.
Opis Ten atrybut wskazuje dział pracownika lub systemu, który zainicjował zgłoszenie serwisowe, na przykład „Sprzedaż”, „Finanse” lub „Zasoby ludzkie”. Umożliwia analizę jakości usług i zapotrzebowania w różnych częściach organizacji. Można na przykład sprawdzić, czy zgłoszenia z niektórych działów są rozwiązywane dłużej lub czy działy te przesyłają ich więcej. Dlaczego to ważne Pozwala analizować wykorzystanie usług i ich jakość w poszczególnych jednostkach organizacyjnych oraz wykrywać problemy i trendy dotyczące konkretnych działów. Skąd pobrać Informacja ta jest zwykle pobierana z profilu użytkownika zgłaszającego, powiązanego ze zgłoszeniem serwisowym. Może znajdować się w polu „Department” obiektu Profile.Employee. Przykłady FinanseSprzedażMarketingTechnologia informacyjna
	Kanał Channel	Metoda lub kanał, za pośrednictwem którego przesłano zgłoszenie serwisowe.
Opis Kanał wskazuje, w jaki sposób utworzono zgłoszenie serwisowe, na przykład przez portal samoobsługowy, e-mail, telefon lub automatycznie przez inny system. Analiza liczby zgłoszeń i czasu ich rozwiązania według kanału pokazuje, które kanały są najefektywniejsze, a które mogą wymagać usprawnienia procesu lub przeszkolenia użytkowników. Dlaczego to ważne Pomaga zrozumieć zachowania użytkowników i efektywność poszczególnych kanałów. Wnioski mogą wspierać decyzje dotyczące sposobu świadczenia usług i możliwości automatyzacji. Skąd pobrać Informacja ta jest często zapisana w polu takim jak „Source” lub „CreatedBy” obiektu Service Request. Przykłady SamoobsługaE-mailTelefonWprowadzenie bezpośrednie
	Kategoria rozwiązania ResolutionCategory	Klasyfikacja sposobu rozwiązania zgłoszenia serwisowego.
Opis Kategoria rozwiązania pozwala w uporządkowany sposób sklasyfikować, jak ostatecznie rozwiązano zgłoszenie serwisowe. Często ma strukturę hierarchiczną, na przykład kategoria i podkategoria, co ułatwia analizę przyczyn źródłowych i raportowanie trendów. Może na przykład wskazać powtarzające się problemy lub typowe działania naprawcze, które można wykorzystać do ulepszania usług albo tworzenia artykułów w bazie wiedzy. Dlaczego to ważne Pokazuje, jak rozwiązywane są zgłoszenia, i pomaga wykrywać częste problemy, możliwości ulepszania usług oraz działania nadające się do automatyzacji. Skąd pobrać Często jest zapisana w polach klasyfikacyjnych uzupełnianych po rozwiązaniu zgłoszenia, takich jak „ResolutionCategory” lub własne pole kodu zamknięcia. Przykłady Wymagane szkolenie użytkownikaWdrożono oprogramowanieNaprawiono sprzętPrzyznano dostęp
	Liczba ponownych otwarć ReopenCount	Liczba ponownych otwarć rozwiązanego zgłoszenia serwisowego.
Opis Ten licznik zwiększa się za każdym razem, gdy zgłoszenie serwisowe zmienia status z „Rozwiązane” lub „Zamknięte” na „Aktywne”. Duża liczba ponownych otwarć może wskazywać na niską skuteczność rozwiązania za pierwszym razem, niekompletne rozwiązanie lub powracające problemy. Atrybut ten służy do obliczania KPI „Odsetek zgłoszeń serwisowych wymagających ponownej pracy”. Dlaczego to ważne Bezpośrednio mierzy ponowną pracę i wskazuje jakość rozwiązania. Wysoka wartość sugeruje, że pierwsza próba naprawy była nieskuteczna. Skąd pobrać Zwykle jest to pole licznika w obiekcie Service Request, zwiększane przez regułę biznesową po odpowiedniej zmianie statusu. Może być nazwane „ReopenCounter”. Przykłady 0123
	Liczba przypisań AssignmentCount	Łączna liczba przypisań i ponownych przypisań zgłoszenia serwisowego.
Opis Ta obliczana miara zlicza działania związane z przypisaniem, na przykład „Assigned to Team” i „Assigned to Agent”, dla każdego zgłoszenia serwisowego. Duża liczba ponownych przypisań, określana czasem jako „ping-pong zgłoszeń”, wskazuje na problemy z kierowaniem zgłoszeń, brak rozwiązania przy pierwszym kontakcie lub niejasny podział odpowiedzialności między zespołami. Atrybut ten jest potrzebny do obliczania KPI „Średnia liczba zmian przypisania na zgłoszenie”. Dlaczego to ważne Pozwala zmierzyć nieefektywne przekazywanie zgłoszeń i problemy z ich kierowaniem. Wysoka wartość często wiąże się z dłuższym czasem rozwiązania i frustracją użytkowników. Skąd pobrać Oblicza się ją podczas przygotowania danych, zliczając wystąpienia działań związanych z przypisaniem dla każdego unikalnego ServiceRequestID. Przykłady 12345
	Nazwa dostawcy VendorName	Nazwa zewnętrznego dostawcy zaangażowanego w rozwiązanie zgłoszenia.
Opis Ten atrybut wskazuje zewnętrznego dostawcę zaangażowanego w obsługę lub realizację zgłoszenia serwisowego. Jest potrzebny w dashboardzie „Czas obsługi przez zewnętrznych dostawców”, który pozwala mierzyć i porównywać wyniki pracy różnych dostawców. Śledzenie tych danych pomaga zarządzać relacjami z dostawcami i wykrywać wąskie gardła wynikające z zależności zewnętrznych. Dlaczego to ważne Umożliwia analizę wyników pracy zewnętrznych dostawców i ich wpływu na całkowity czas rozwiązywania zgłoszeń serwisowych, wspierając zarządzanie dostawcami. Skąd pobrać Może to być pole obiektu zadania powiązanego ze zgłoszeniem serwisowym albo osobne pole samego obiektu Service Request, jeśli przypisano dostawcę. Przykłady Dell SupportOracle ConsultingMicrosoft Premiernull

Wymagane Zalecane Opcjonalne

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

To najważniejsze kroki i punkty kontrolne procesu, które należy uwzględnić w dzienniku zdarzeń, aby dokładnie odkryć i przeanalizować proces.

5 Zalecane 9 Opcjonalne

	Działanie	Opis
	Przypisanie zgłoszenia do konsultanta	Konkretna osoba przejmuje obsługę zgłoszenia serwisowego. Zdarzenie można zwykle wywnioskować z pierwszego wypełnienia lub aktualizacji pola „Owner”, które wskazuje konsultanta odpowiedzialnego za zgłoszenie.
Dlaczego to ważne To koniec początkowego oczekiwania w kolejce. Pomiar czasu do tego momentu pomaga wykrywać problemy z przydziałem zasobów i zasila dashboard obciążenia konsultantów. Skąd pobrać Zdarzenie można wywnioskować z wypełnienia lub zmiany pola „Owner” w rekordzie Service Request, widocznej w historii audytu. Rejestrowanie Pierwszy znacznik czasu, w którym po utworzeniu zgłoszenia lub przypisaniu go do zespołu pole „Owner” zawiera nazwisko konsultanta. Typ zdarzenia inferred
	Przypisanie zgłoszenia do zespołu	Zgłoszenie serwisowe zostaje przypisane do konkretnego zespołu wsparcia. Zdarzenie można wykryć, sprawdzając, czy pole „OwnerTeam” w rekordzie Service Request zostało wypełnione lub zmienione.
Dlaczego to ważne To zdarzenie pomaga analizować efektywność zespołów, rozkład obciążenia i czas przekazywania spraw między zespołami. Ułatwia też wskazanie zespołów, które tworzą wąskie gardła w procesie. Skąd pobrać Zmiany pola „OwnerTeam” można śledzić w historii audytu lub dzienniku rekordu Service Request. Rejestrowanie Zdarzenie aktualizacji pola „OwnerTeam”, zwykle zapisywane w historii audytu. Typ zdarzenia explicit
	Rozwiązanie zgłoszenia serwisowego	Zgłoszenie serwisowe uznaje się za rozwiązane, a użytkownik otrzymuje rozwiązanie. To ważny etap rejestrowany po zmianie statusu na „Resolved”, która często zatrzymuje licznik SLA.
Dlaczego to ważne To istotny punkt końcowy przy pomiarze czasu rozwiązania zgłoszenia i realizacji SLA. Czas od utworzenia zgłoszenia do tego etapu jest podstawowym KPI efektywności procesu. Skąd pobrać Zdarzenie można wywnioskować ze zmiany pola „Status” rekordu Service Request na „Resolved” wraz z odpowiadającym jej znacznikiem czasu. Rejestrowanie Wykrycie aktualizacji pola „Status” na „Resolved” w historii audytu. Typ zdarzenia inferred
	Utworzenie zgłoszenia serwisowego	To działanie rozpoczyna cykl życia zgłoszenia serwisowego. Nowe zgłoszenie zostaje formalnie przesłane i zarejestrowane w Ivanti. Zdarzenie jest rejestrowane po utworzeniu nowego rekordu obiektu biznesowego Service Request, któremu system nadaje unikalny Service Request ID.
Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Analiza czasu od tego momentu do rozwiązania zgłoszenia jest podstawą pomiaru całkowitego czasu realizacji i efektywności procesu. Skąd pobrać Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia rekordu Service Request, na przykład pola CreatedDateTime w obiekcie biznesowym ServiceReq. Rejestrowanie Utworzenie rekordu w tabeli ServiceReq, rozpoznawane na podstawie znacznika czasu utworzenia. Typ zdarzenia explicit
	Zamknięcie zgłoszenia serwisowego	Zgłoszenie serwisowe zostaje oficjalnie zamknięte i nie można już podjąć dalszych działań. Często następuje to automatycznie po upływie określonego czasu w statusie „Resolved” i oznacza koniec cyklu życia zgłoszenia.
Dlaczego to ważne To ostateczny koniec procesu. Czas między statusami „Resolved” i „Closed” może ujawnić opóźnienia w potwierdzeniu rozwiązania lub działaniu automatycznych procesów systemowych. Skąd pobrać Zdarzenie można wywnioskować ze zmiany pola „Status” rekordu Service Request na „Closed” wraz z odpowiadającym jej znacznikiem czasu. Rejestrowanie Wykrycie aktualizacji pola „Status” na „Closed” w historii audytu. Typ zdarzenia inferred
	Akceptacja zgłoszenia	Zgłoszenie serwisowe uzyskało wszystkie wymagane akceptacje i może przejść do realizacji. Zdarzenie jest rejestrowane po pomyślnym zakończeniu workflow akceptacji, gdy zmienia się status zgłoszenia.
Dlaczego to ważne To ważny etap, który oznacza koniec akceptacji i początek realizacji. Pozwala zmierzyć efektywność samego procesu akceptacji. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu z „Waiting for Approval” na „Approved” lub „Fulfilled”. Może być też jawnie rejestrowane w obiekcie biznesowym FRS_Approval. Rejestrowanie Zmiana pola „Status” rekordu Service Request ze statusu oczekiwania na akceptację na status aktywny. Typ zdarzenia inferred
	Anulowanie zgłoszenia serwisowego	Użytkownik lub konsultant anuluje zgłoszenie serwisowe przed jego rozwiązaniem. To alternatywny stan końcowy, rejestrowany po zmianie statusu na „Cancelled” lub „Withdrawn”.
Dlaczego to ważne To niestandardowe zakończenie procesu. Analiza przyczyn anulowania zgłoszeń może ujawnić problemy z samym procesem lub zmieniające się potrzeby użytkowników. Skąd pobrać Zdarzenie można wywnioskować ze zmiany pola „Status” rekordu Service Request na „Cancelled”. Rejestrowanie Wykrycie aktualizacji pola „Status” na „Cancelled” w historii audytu. Typ zdarzenia inferred
	Ponowne otwarcie zgłoszenia serwisowego	Wcześniej rozwiązane zgłoszenie serwisowe zostało ponownie aktywowane, ponieważ problem nadal występuje lub użytkownik nie zaakceptował rozwiązania. Zdarzenie jest rejestrowane, gdy status zmienia się z „Resolved” na aktywny, na przykład „Active” lub „Assigned”.
Dlaczego to ważne To bezpośredni wskaźnik konieczności ponownej pracy i niskiej jakości rozwiązania za pierwszym razem. Analiza ponownie otwartych zgłoszeń pomaga wykrywać słabe punkty procesu i poprawiać KPI dotyczący odsetka poprawek przy zgłoszeniach serwisowych. Skąd pobrać Zdarzenie można wywnioskować z historii audytu, gdy pole „Status” zmienia się z „Resolved” lub „Closed” na status aktywny. Rejestrowanie Zmiana statusu końcowego („Resolved”, „Closed”) na status otwarty („Active”, „Assigned”). Typ zdarzenia inferred
	Prośba o informacje do użytkownika	Przypisany konsultant potrzebuje dodatkowych informacji od zgłaszającego, aby kontynuować realizację. Zdarzenie jest rejestrowane, gdy status zgłoszenia zmienia się na przykład na „Waiting for Customer”.
Dlaczego to ważne To działanie wskazuje opóźnienia spowodowane niekompletnymi informacjami w zgłoszeniu. Śledzenie jego częstotliwości i czasu trwania pomaga analizować wpływ próśb o informacje i wskazywać możliwości usprawnienia procesu. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu rekordu Service Request na przykład na „Waiting for Customer” lub „Pending”. Rejestrowanie Wykrycie zmiany pola „Status” na określony status oczekiwania na odpowiedź użytkownika. Typ zdarzenia inferred
	Przekazanie informacji przez użytkownika	Zgłaszający przekazał potrzebne informacje, dzięki czemu konsultant może wznowić pracę. Zdarzenie jest rejestrowane, gdy zgłoszenie przechodzi ze statusu „Waiting for Customer” do statusu aktywnego.
Dlaczego to ważne To zdarzenie zamyka etap oczekiwania na informacje. Czas między wysłaniem prośby a otrzymaniem odpowiedzi jest istotnym źródłem opóźnień i poprawek w procesie. Skąd pobrać Zdarzenie można wywnioskować, gdy pole „Status” rekordu Service Request zmienia się ze statusu „Waiting for Customer” na aktywny, na przykład „Active” lub „In Progress”. Rejestrowanie Wykrycie zmiany statusu z oczekiwania na odpowiedź użytkownika na status aktywny. Typ zdarzenia inferred
	Przekazanie zgłoszenia do akceptacji	Zgłoszenie serwisowe przekazano do wymaganej akceptacji przed jego realizacją. Zdarzenie można zwykle rozpoznać po zmianie statusu zgłoszenia na „Submitted” lub „Pending Approval”, która często uruchamia workflow akceptacji.
Dlaczego to ważne Śledzenie tego działania pomaga wykrywać opóźnienia na etapie akceptacji. Długi czas oczekiwania może być istotnym wąskim gardłem, które wydłuża czas rozwiązania zgłoszenia i obniża satysfakcję użytkowników. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu rekordu Service Request, na przykład na „Submitted” lub „Waiting for Approval”. Dane mogą też pochodzić z obiektów biznesowych FRS_Approval lub FRS_ApprovalVoteTracking. Rejestrowanie Zmiana pola „Status” rekordu Service Request na status oczekiwania na akceptację. Typ zdarzenia inferred
	Realizacja zgłoszenia serwisowego	Konsultant lub system wykonał wszystkie czynności wymagane do realizacji zgłoszenia serwisowego. Zdarzenie jest rejestrowane po zmianie statusu na „Fulfilled”, która często poprzedza końcowy status „Resolved”.
Dlaczego to ważne Ten etap oznacza zakończenie prac technicznych lub proceduralnych. Pozwala zmierzyć czas aktywnej obsługi przed ostatecznym potwierdzeniem i zamknięciem zgłoszenia. Skąd pobrać Zdarzenie można wywnioskować ze zmiany pola „Status” rekordu Service Request na „Fulfilled”. Rejestrowanie Zmiana pola „Status” na „Fulfilled”, wykryta w historii rekordu. Typ zdarzenia inferred
	Zaangażowanie zewnętrznego dostawcy	Realizację zgłoszenia serwisowego przekazano zewnętrznemu dostawcy lub innej firmie. Zdarzenie jest zwykle rejestrowane po zmianie statusu na „Waiting for 3rd Party” lub podobny.
Dlaczego to ważne To działanie jest niezbędne do pomiaru efektywności dostawcy i jego wpływu na całkowity czas realizacji. Pozwala analizować opóźnienia po stronie dostawców i zasila dashboard czasu trwania działań zewnętrznych dostawców. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu rekordu Service Request na przykład na „Waiting for 3rd Party” lub „Pending Vendor”. Rejestrowanie Wykrycie zmiany pola „Status” na określony status oczekiwania na dostawcę. Typ zdarzenia inferred
	Zmiana priorytetu	Priorytet zgłoszenia serwisowego zmienił się po jego utworzeniu. Zdarzenie można odczytać z dziennika audytu lub historii zmian poszczególnych pól.
Dlaczego to ważne Śledzenie zmian priorytetu jest niezbędne do oceny skuteczności ustalania priorytetów. Pomaga sprawdzić, czy eskalacje są obsługiwane prawidłowo i czy początkowy priorytet został trafnie określony. Skąd pobrać To jawne zdarzenie z historii audytu rekordu Service Request, w której zapisywane są zmiany pola „Priority”. Rejestrowanie Zdarzenie aktualizacji pola „Priority” zapisane w historii audytu systemu. Typ zdarzenia explicit

Zalecane Opcjonalne

Instrukcje wyodrębniania danych

Jak pobrać dane z Ivanti Service Manager

Kroki

Zaloguj się do Ivanti Service Manager na konto z uprawnieniami do odczytu zgłoszeń serwisowych i ich historii audytu.
W głównym panelu nawigacyjnym przejdź do obszaru roboczego Service Request.
W tym procesie należy wyeksportować dane z dwóch źródeł, a następnie połączyć je poza systemem. Pierwszy eksport obejmuje utworzenie zgłoszenia i jego podstawowe atrybuty, a drugi szczegółową historię zmian.
Pierwszy eksport (zdarzenia utworzenia): Utwórz nowe zapisane wyszukiwanie dla obiektu biznesowego ServiceReq. Ustaw filtr CreatedDateTime, aby wybrać zgłoszenia utworzone w wybranym okresie analizy, na przykład w ciągu ostatnich sześciu miesięcy.
Wybierz kolumny wyszukiwania utworzenia: RecId, ServiceReqNumber (dla ServiceRequestID), CreatedDateTime (dla EventTime), SvcReqTmplLink_Category (dla ServiceRequestType), OwnerTeam, Owner, Priority, Status, ResolutionDateTime i TargetDateTime (dla SLADeadline).
Uruchom wyszukiwanie i użyj funkcji eksportu tabeli, zwykle oznaczonej ikoną dyskietki lub strzałki, aby zapisać dane w pliku CSV. Nazwij go ServiceRequests.csv.
Drugi eksport (zdarzenia z historii audytu): Utwórz nowe zapisane wyszukiwanie dla obiektu biznesowego FRS_data_audit_history, w którym rejestrowane są zmiany pól.
Ogranicz wyniki wyszukiwania do zmian dotyczących zgłoszeń serwisowych. Dodaj filtr, w którym ParentObjectType ma wartość 'ServiceReq'. Dodaj też filtr AuditDate obejmujący ten sam okres analizy co poprzednio.
Wybierz kolumny wyszukiwania audytu: ParentLink_RecID (do powiązania ze zgłoszeniem), FieldName, OldValue, NewValue i AuditDate (dla EventTime). Wyeksportuj dane do drugiego pliku CSV o nazwie AuditHistory.csv.
Przekształcanie i łączenie danych: Połącz wyeksportowane pliki CSV i przekształć je w jeden dziennik zdarzeń. Użyj narzędzia do przygotowywania danych, takiego jak Power Query w Excelu, Python lub narzędzie bazodanowe, i wykonaj następujące kroki:
- Wczytaj pliki ServiceRequests.csv i AuditHistory.csv.
- Na podstawie pliku ServiceRequests.csv utwórz zdarzenie 'Service Request Created' dla każdego zgłoszenia.
- Na podstawie pliku AuditHistory.csv utwórz pozostałe zdarzenia. Przypisz wartości z kolumn FieldName i NewValue do wymaganych nazw działań. Na przykład, jeśli FieldName ma wartość 'Status', a NewValue ma wartość 'Resolved', ustaw ActivityName na 'Service Request Resolved'.
- Połącz przekształcone zdarzenia audytu z danymi zgłoszeń, używając ParentLink_RecID z pliku audytu i RecId z pliku zgłoszeń. Dzięki temu do każdego zdarzenia zostaną dodane atrybuty zgłoszenia.
- Połącz zdarzenia 'Created' i zdarzenia pochodzące z audytu w jednej tabeli.
Sformatuj końcową tabelę i ustaw wymagane nagłówki kolumn: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate oraz inne zalecane atrybuty. Upewnij się, że wszystkie znaczniki czasu mają spójny format.
Zapisz końcowy dziennik zdarzeń w jednym pliku CSV, gotowym do przesłania.

Konfiguracja

Obiekty biznesowe: Ta metoda wymaga eksportu danych z dwóch obiektów biznesowych: ServiceReq z danymi głównymi zgłoszeń oraz FRS_data_audit_history ze zdarzeniami.
Filtr zakresu dat: Aby kontrolować ilość danych, należy zastosować filtr zakresu dat do obu eksportów. Użyj pola CreatedDateTime w obiekcie ServiceReq i pola AuditDate w obiekcie FRS_data_audit_history. Do wstępnej analizy zaleca się okres 3–6 miesięcy.
Filtry historii audytu:
- Ustaw filtr ParentObjectType na 'ServiceReq', aby wyodrębnić wyłącznie zmiany dotyczące zgłoszeń serwisowych.
- Opcjonalnie można ograniczyć pole FieldName do pól istotnych dla procesu, takich jak 'Status', 'Owner', 'OwnerTeam' i 'Priority'. Pozwoli to znacznie zmniejszyć rozmiar eksportu.
Wymagania wstępne: Potrzebne jest konto użytkownika w Ivanti Service Manager z uprawnieniami do tworzenia zapisanych wyszukiwań i eksportowania danych z obiektów biznesowych ServiceReq oraz FRS_data_audit_history.
Wydajność: Tabela FRS_data_audit_history może być bardzo duża. Eksport bez odpowiednio zawężonego filtra dat może obciążyć Ivanti i spowodować przekroczenie limitu czasu. W razie potrzeby warto eksportować dane w mniejszych partiach miesięcznych lub kwartalnych.

Przykładowe zapytanie sql

-- This script represents the transformation logic to be applied in a data preparation tool (e.g., Power Query, Python, SQL) after exporting the two CSV files from Ivanti.

-- Step 1: Define the 'Service Request Created' events from the ServiceRequests.csv export.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    'Service Request Created' AS ActivityName,
    sr.CreatedDateTime AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    sr.Status AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    DATEDIFF(hour, sr.CreatedDateTime, sr.ResolutionDateTime) AS CycleTime,
    CASE WHEN sr.ResolutionDateTime IS NOT NULL AND sr.ResolutionDateTime <= sr.TargetDateTime THEN 'Met' ELSE 'Breached' END AS SLAStatus,
    sr.RecId -- Internal key for joining
FROM
    ServiceRequests_Export sr -- Represents the ServiceRequests.csv file

UNION ALL

-- Step 2: Transform records from AuditHistory.csv into specific activities and join with service request attributes.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 'Request Submitted for Approval'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 'Request Approved'
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Team'
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Agent'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 'Information Requested from User'
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 'Information Provided by User'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 'External Vendor Engaged'
        WHEN audit.FieldName = 'Priority' THEN 'Priority Changed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 'Service Request Fulfilled'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 'Service Request Resolved'
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 'Service Request Reopened'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 'Service Request Closed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 'Service Request Cancelled'
    END AS ActivityName,
    audit.AuditDate AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    audit.NewValue AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    NULL AS CycleTime,
    NULL AS SLAStatus,
    sr.RecId
FROM
    AuditHistory_Export audit -- Represents the AuditHistory.csv file
JOIN
    ServiceRequests_Export sr ON audit.ParentLink_RecID = sr.RecId
WHERE
    -- This filter ensures that only rows corresponding to a defined activity are included.
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 1
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 1
        WHEN audit.FieldName = 'Priority' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 1
        ELSE 0
    END = 1;

Kroki

Wymagania wstępne i konfiguracja: Upewnij się, że w systemie jest zainstalowany Python 3.6 lub nowszy. Zainstaluj biblioteki requests do wywołań API i pandas do przetwarzania danych, uruchamiając pip install requests pandas. Uzyskaj od administratora Ivanti Service Manager klucz API z co najmniej uprawnieniami do odczytu obiektów biznesowych ServiceReq i FRS_Audit_ServiceReq.
Skonfiguruj skrypt: Pobierz udostępniony skrypt Python. Otwórz go w edytorze tekstu lub środowisku IDE i zmień zmienne placeholder na początku pliku: TENANT_URL, API_KEY, START_DATE i END_DATE, tak aby odpowiadały środowisku Ivanti i wybranemu okresowi eksportu.
Uruchom skrypt: W wierszu poleceń uruchom python your_script_name.py. Skrypt wyświetli komunikat o nawiązywaniu połączenia i uwierzytelnianiu w Ivanti API.
Pobierz dane zgłoszeń serwisowych: Skrypt rozpocznie od pobrania z obiektu biznesowego ServiceReq wszystkich zgłoszeń utworzonych w wybranym zakresie dat. Automatycznie obsłuży stronicowanie API, aby pobrać pełną listę zgłoszeń, i będzie wyświetlać postęp po pobraniu każdej strony danych.
Pobierz historię audytu: Dla każdego pobranego zgłoszenia skrypt wykona dodatkowe zapytanie do obiektu biznesowego FRS_Audit_ServiceReq. Pobierze pełną historię zmian pól danego zgłoszenia, niezbędną do utworzenia szczegółowego dziennika zdarzeń.
Utwórz zdarzenie 'Created': Podczas przetwarzania każdego zgłoszenia skrypt najpierw utworzy zdarzenie 'Service Request Created'. Znacznik czasu tego zdarzenia zostanie pobrany bezpośrednio z pola CreatedDateTime rekordu zgłoszenia.
Utwórz zdarzenia na podstawie ścieżki audytu: Następnie skrypt przeanalizuje rekordy ścieżki audytu każdego zgłoszenia. Wykryje zmiany ważnych pól, takich jak Status, OwnerTeam, Owner i Priority.
Przypisz zmiany do działań: Zdefiniowana w skrypcie logika mapowania przekształci zmiany pól w nazwy odpowiednich działań. Na przykład zmiana pola Status z 'Active' na 'Resolved' zostanie zapisana jako działanie 'Service Request Resolved'.
Utwórz dziennik zdarzeń: Wszystkie wygenerowane zdarzenia, zarówno utworzenie zgłoszenia, jak i późniejsze zmiany zarejestrowane w ścieżce audytu, zostaną zebrane w uporządkowanej liście. Każde zdarzenie będzie zawierać identyfikator zgłoszenia serwisowego, nazwę działania, znacznik czasu i inne istotne atrybuty.
Przekształć i sformatuj dane: Zebrana lista zdarzeń zostanie przekształcona w obiekt Pandas DataFrame. Skrypt dopasuje kolumny do wymaganego schematu ProcessMind, w tym ServiceRequestID, ActivityName i EventTime.
Wyeksportuj dane do CSV: Po przetworzeniu wszystkich zgłoszeń serwisowych i ich historii skrypt zapisze końcowy DataFrame w pliku ivanti_servicereq_event_log.csv w tym samym katalogu, z którego uruchomiono skrypt. Plik będzie gotowy do przesłania.

Konfiguracja

Adres URL punktu końcowego API: Podstawowy adres URL REST API dzierżawy Ivanti Service Manager. Należy go wpisać w zmiennej TENANT_URL w skrypcie, na przykład https://your-tenant.ivanti.com.
Klucz API: Prawidłowy klucz REST API wygenerowany w konsoli administracyjnej Ivanti. Musi być przypisany do roli z uprawnieniami do odczytu obiektów biznesowych ServiceReq i FRS_Audit_ServiceReq.
Zakres dat: Skrypt wymaga podania START_DATE i END_DATE w formacie 'YYYY-MM-DD'. Do wstępnej analizy zaleca się zakres od 3 do 6 miesięcy. Pozwoli to zachować rozsądną ilość danych i uwzględnić wystarczającą liczbę wariantów procesu.
Rozmiar strony (TOP_COUNT): Ta zmienna określa liczbę rekordów pobieranych podczas jednego wywołania API. Domyślna wartość to 500, co zapewnia dobry kompromis między wydajnością a zużyciem pamięci. Wartość można dostosować do wydajności serwera API.
Wymagane pola (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): Skrypt określa pola pobierane z API, aby ograniczyć rozmiar przesyłanych danych. Upewnij się, że listy zawierają wszystkie pola potrzebne do uwzględnienia wymaganych i zalecanych atrybutów.

Przykładowe zapytanie python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Ivanti tenant URL and API Key
TENANT_URL = class="hl-string">"https://[your-tenant.ivanti.com]"
API_KEY = class="hl-string">"[Your Ivanti REST API Key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># API settings
TOP_COUNT = 500
API_BO_URL = fclass="hl-string">"{TENANT_URL}/api/odata/businessobject"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"rest_api_key={API_KEY}",
    class="hl-string">"Content-Type": class="hl-string">"application/json"
}

class=class="hl-string">"hl-comment"># Fields to select from the API to reduce payload size
SELECT_FIELDS_SR = class="hl-string">"RecId,ServiceReqNumber,CreatedDateTime,OwnerTeam,Owner,Priority,Status,Subject,Resolution,ResolvedDateTime,ResponseTarget,Service"
SELECT_FIELDS_AUDIT = class="hl-string">"FieldName,OldValue,NewValue,ModifiedDateTime,ParentLink_RecID"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def get_paginated_data(url, params):
    class="hl-string">"""Fetches all pages of data from a given Ivanti API endpoint."""
    all_records = []
    page_url = url
    while page_url:
        try:
            response = requests.get(page_url, headers=HEADERS, params=params)
            response.raise_for_status() 
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            page_url = data.get(class="hl-string">'@odata.nextLink')
            print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
            class=class="hl-string">"hl-comment"># Parameters are only needed for the first request
            params = {}
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break
    return all_records

def map_status_change_to_activity(old_status, new_status):
    class="hl-string">"""Maps status transitions to activity names."""
    class=class="hl-string">"hl-comment"># Normalize statuses by removing spaces and converting to lower case
    old = str(old_status).lower().replace(class="hl-string">" ", class="hl-string">"") if old_status else class="hl-string">""
    new = str(new_status).lower().replace(class="hl-string">" ", class="hl-string">"") if new_status else class="hl-string">""

    if new in [class="hl-string">'submitted', class="hl-string">'pendingapproval']:
        return class="hl-string">'Request Submitted for Approval'
    if new == class="hl-string">'approved':
        return class="hl-string">'Request Approved'
    if new == class="hl-string">'waitingforcustomer':
        return class="hl-string">'Information Requested from User'
    if old == class="hl-string">'waitingforcustomer' and new not in [class="hl-string">'resolved', class="hl-string">'closed', class="hl-string">'cancelled']:
        return class="hl-string">'Information Provided by User'
    if new == class="hl-string">'waitingfor3rdparty':
        return class="hl-string">'External Vendor Engaged'
    if new == class="hl-string">'fulfilled':
        return class="hl-string">'Service Request Fulfilled'
    if new == class="hl-string">'resolved':
        return class="hl-string">'Service Request Resolved'
    if old == class="hl-string">'resolved' and new not in [class="hl-string">'closed']:
        return class="hl-string">'Service Request Reopened'
    if new == class="hl-string">'closed':
        return class="hl-string">'Service Request Closed'
    if new == class="hl-string">'cancelled':
        return class="hl-string">'Service Request Cancelled'
    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting Ivanti Service Request extraction...")

    class=class="hl-string">"hl-comment"># 1. Fetch all Service Requests within the date range
    sr_url = fclass="hl-string">"{API_BO_URL}/ServiceReqs"
    sr_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z"
    sr_params = {
        class="hl-string">"$filter": sr_filter,
        class="hl-string">"$select": SELECT_FIELDS_SR,
        class="hl-string">"$top": TOP_COUNT
    }
    print(fclass="hl-string">"Fetching Service Requests from {START_DATE} to {END_DATE}...")
    service_requests = get_paginated_data(sr_url, sr_params)

    if not service_requests:
        print(class="hl-string">"No service requests found for the given date range.")
        return

    print(fclass="hl-string">"Found {len(service_requests)} service requests. Now fetching audit histories...")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 2. For each Service Request, fetch its audit history and build events
    for i, sr in enumerate(service_requests):
        print(fclass="hl-string">"Processing SR {i+1}/{len(service_requests)}: {sr.get('ServiceReqNumber')}")
        sr_id = sr.get(class="hl-string">'RecId')
        sr_number = sr.get(class="hl-string">'ServiceReqNumber')
        
        class=class="hl-string">"hl-comment"># Event: Service Request Created
        event_log.append({
            class="hl-string">'ServiceRequestID': sr_number,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': sr.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
            class="hl-string">'LastDataUpdate': current_time,
            class="hl-string">'EventEndTime': None,
            class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
            class="hl-string">'AssignedTeam': sr.get(class="hl-string">'OwnerTeam'),
            class="hl-string">'AssignedAgent': sr.get(class="hl-string">'Owner'),
            class="hl-string">'Priority': sr.get(class="hl-string">'Priority'),
            class="hl-string">'ServiceRequestStatus': sr.get(class="hl-string">'Status'),
            class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
            class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
            class="hl-string">'CycleTime': None, class=class="hl-string">"hl-comment"># To be calculated later if needed
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># To be calculated later if needed
        })

        class=class="hl-string">"hl-comment"># Fetch audit history for this SR
        audit_url = fclass="hl-string">"{API_BO_URL}/FRS_Audit_ServiceReqs"
        audit_params = {
            class="hl-string">"$filter": fclass="hl-string">"ParentLink_RecID eq '{sr_id}'",
            class="hl-string">"$select": SELECT_FIELDS_AUDIT,
            class="hl-string">"$orderby": class="hl-string">"ModifiedDateTime asc"
        }
        audit_history = get_paginated_data(audit_url, audit_params)

        if not audit_history:
            continue

        class=class="hl-string">"hl-comment"># Process audit history to create events
        for audit_entry in audit_history:
            field_name = audit_entry.get(class="hl-string">'FieldName')
            event_time = audit_entry.get(class="hl-string">'ModifiedDateTime')
            old_value = audit_entry.get(class="hl-string">'OldValue')
            new_value = audit_entry.get(class="hl-string">'NewValue')
            activity_name = None
            current_team = None
            current_agent = None
            current_priority = None
            current_status = None

            if field_name == class="hl-string">'Status':
                activity_name = map_status_change_to_activity(old_value, new_value)
                current_status = new_value
            elif field_name == class="hl-string">'OwnerTeam' and new_value:
                activity_name = class="hl-string">'Request Assigned to Team'
                current_team = new_value
            elif field_name == class="hl-string">'Owner' and new_value:
                activity_name = class="hl-string">'Request Assigned to Agent'
                current_agent = new_value
            elif field_name == class="hl-string">'Priority' and old_value is not None:
                activity_name = class="hl-string">'Priority Changed'
                current_priority = new_value

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestID': sr_number,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
                    class="hl-string">'LastDataUpdate': current_time,
                    class="hl-string">'EventEndTime': None,
                    class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
                    class="hl-string">'AssignedTeam': current_team or sr.get(class="hl-string">'OwnerTeam'), class=class="hl-string">"hl-comment"># Use current if changed, else original
                    class="hl-string">'AssignedAgent': current_agent or sr.get(class="hl-string">'Owner'),
                    class="hl-string">'Priority': current_priority or sr.get(class="hl-string">'Priority'),
                    class="hl-string">'ServiceRequestStatus': current_status or sr.get(class="hl-string">'Status'),
                    class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
                    class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
                    class="hl-string">'CycleTime': None,
                    class="hl-string">'SLAStatus': None
                })

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated.")
        return

    print(class="hl-string">"Extraction complete. Creating CSV file...")
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure chronological order
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], ascending=[True, True])
    
    class=class="hl-string">"hl-comment"># Forward fill key attributes to provide context for each event
    df[class="hl-string">'AssignedTeam'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedTeam'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssignedAgent'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedAgent'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'Priority'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'Priority'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ServiceRequestStatus'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'ServiceRequestStatus'].fillna(method=class="hl-string">'ffill')

    output_filename = class="hl-string">'ivanti_servicereq_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log saved successfully to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

Gotowi do rozpoczęcia?

Skorzystaj ze szczegółowego szablonu danych, aby lepiej wykorzystać możliwości analizy procesu zarządzania zgłoszeniami serwisowymi. Zacznij usprawniać operacje już dziś.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Zacznij usprawniać zarządzanie zgłoszeniami serwisowymi już dziś

Skróć czas realizacji zgłoszeń, ogranicz frustrację użytkowników i osiągnij 70% automatyzacji.

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.

Szablon danych do zarządzania zgłoszeniami serwisowymi

Szablon danych do zarządzania zgłoszeniami serwisowymi

Atrybuty zarządzania zgłoszeniami serwisowymi

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

Instrukcje wyodrębniania danych

Eksport danych z zapisanych wyszukiwań i tabeli Ivanti do CSV

Kroki

Konfiguracja

Przykładowe zapytanie sql

Skrypt Python korzystający z Ivanti REST API

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Zacznij usprawniać zarządzanie zgłoszeniami serwisowymi już dziś