> Ciągłe doskonalenie procesów > Zarządzanie zgłoszeniami serwisowymi > BMC Helix ITSM > Szablon danych

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

BMC Helix ITSM

← Wróć do przewodnika ulepszania procesów

Atrybuty obsługi zgłoszeń serwisowych(20) Czynności w procesie obsługi zgłoszeń serwisowych(14) Instrukcje wyodrębniania danych(3)

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

Szablon przedstawia najważniejsze atrybuty danych do zebrania oraz czynności do śledzenia w procesie obsługi zgłoszeń serwisowych. Zawiera też praktyczne wskazówki, jak sprawnie wyodrębnić te dane z BMC Helix ITSM. Ułatwia przygotowanie danych i rozpoczęcie inicjatyw process mining.

Zalecane atrybuty do zebrania
Najważniejsze czynności do śledzenia
Wskazówki dotyczące wyodrębniania danych z BMC Helix ITSM

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

Pobierz szablon

Atrybuty obsługi zgłoszeń serwisowych

Te pola danych są potrzebne do utworzenia dziennika zdarzeń, który umożliwi szczegółową analizę procesu obsługi zgłoszeń serwisowych.

5 Wymagane 6 Zalecane 9 Opcjonalne

	Nazwa	Opis
	Czas rozpoczęcia EventStartTime	Znacznik czasu wskazujący, kiedy rozpoczęła się dana czynność lub zdarzenie.
Opis Ten atrybut zapisuje dokładną datę i godzinę rozpoczęcia czynności. Każde zdarzenie w dzienniku, od wysłania zgłoszenia po jego ostateczne zamknięcie, musi mieć czas rozpoczęcia, aby można było ustalić chronologię procesu. Ten znacznik czasu jest niezbędny w analizach process mining opartych na czasie. Służy do obliczania czasu realizacji, czasu trwania czynności i oczekiwania między krokami, a także do sprawdzania zgodności z SLA. Ułatwia wykrywanie wąskich gardeł i analizę wyników procesu w czasie. Dlaczego to ważne Czas rozpoczęcia określa kolejność zdarzeń. Jest niezbędny do obliczania czasu trwania procesu, wykrywania opóźnień i analizy jego przebiegu w czasie. Skąd pobrać Odpowiada polom znaczników czasu w dziennikach audytowych lub tabelach historii statusów powiązanych z formularzem „SRM:Request”, na przykład polu „Submit Date” dla zdarzenia początkowego. Przykłady 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Czynność ActivityName	Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w danym momencie obsługi zgłoszenia serwisowego.
Opis Ten atrybut opisuje konkretny krok lub zmianę statusu w procesie obsługi zgłoszenia serwisowego, na przykład „Zgłoszenie w trakcie weryfikacji”, „Realizacja w toku” lub „Zgłoszenie serwisowe rozwiązane”. Każda czynność odpowiada pojedynczemu zdarzeniu w całym przebiegu obsługi zgłoszenia. Analiza kolejności i częstotliwości czynności stanowi podstawę process mining. Pozwala odkrywać mapy procesów, wskazywać wąskie gardła i analizować warianty procesu. Ważne jest, jakie czynności występują, w jakiej kolejności i jak często, aby można było usprawnić proces. Dlaczego to ważne Czynności składają się na mapę procesu. Ich śledzenie pozwala wizualizować i analizować przebieg procesu oraz sprawdzić, jak faktycznie wykonywana jest praca. Skąd pobrać Wartość jest zwykle ustalana na podstawie zmian pól „Status” i „Status Reason” w formularzu „SRM:Request” lub dzienników powiązanych aplikacji realizacyjnych, na przykład Incident lub Work Order. Przykłady Zgłoszenie oczekuje na zatwierdzenieRealizacja w tokuZgłoszenie serwisowe rozwiązaneZgłoszenie serwisowe zamknięte
	Service Request ID ServiceRequestId	Unikatowy identyfikator każdego zgłoszenia serwisowego, używany jako główny klucz do śledzenia całego cyklu obsługi.
Opis Service Request ID jednoznacznie identyfikuje każde zgłoszenie serwisowe wysłane przez użytkownika lub system. Łączy wszystkie kolejne zdarzenia, od początkowej rejestracji po ostateczne zamknięcie, dzięki czemu można przeanalizować cały przebieg obsługi zgłoszenia. W process mining ten identyfikator jest niezbędny do odtworzenia sekwencji czynności dla każdej sprawy. Umożliwia grupowanie powiązanych zdarzeń, takich jak „Zgłoszenie serwisowe wysłane”, „Zgłoszenie przypisane” i „Zgłoszenie serwisowe zamknięte”, w jedną instancję procesu. Na tej podstawie przeprowadza się analizę procesu. Dlaczego to ważne To podstawowy identyfikator sprawy. Bez niego nie można prześledzić całej obsługi zgłoszenia serwisowego ani odkrywać i analizować procesu. Skąd pobrać Zwykle jest to pole „InstanceId” lub „Request Number” w formularzu „SRM:Request” w BMC Helix ITSM. Przykłady SR000010572931SR000010572932SR000010572933
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu ostatniego odświeżenia danych procesu z systemu źródłowego.
Opis Ten atrybut wskazuje datę i godzinę ostatniej ekstrakcji danych z BMC Helix ITSM. Informuje użytkowników, jak aktualne są analizowane dane i jaki okres obejmuje analiza. To ważny atrybut metadanych w każdym dashboardzie lub analizie process mining. Pozwala ustalić, czy wnioski opierają się na danych zbliżonych do bieżących, czy na migawce historycznej. Ma to wpływ na ich trafność i aktualność. Dlaczego to ważne Informuje użytkowników o aktualności danych. Jest to niezbędne przy podejmowaniu decyzji na podstawie najnowszych dostępnych informacji o wynikach procesu. Skąd pobrać Ten znacznik czasu jest generowany i dodawany podczas ekstrakcji oraz wczytywania danych. Przykłady 2024-05-21T08:00:00Z
	System źródłowy SourceSystem	Wskazuje system, z którego wyodrębniono dane.
Opis Ten atrybut określa źródło danych o procesie. W tym widoku jego wartość byłaby ustawiona na stałe na „BMC Helix ITSM”, aby wskazać, że wszystkie zdarzenia związane ze zgłoszeniami serwisowymi pochodzą z tego systemu. W środowiskach z wieloma zintegrowanymi systemami pole to pomaga ustalić pochodzenie danych i podzielić je według źródła. Zapewnia przejrzystość i możliwość śledzenia danych, szczególnie gdy łączone są informacje z różnych platform. Dlaczego to ważne Informacja o źródle danych jest przydatna przy zarządzaniu danymi, śledzeniu ich pochodzenia i rozwiązywaniu problemów w środowiskach korzystających z wielu systemów. Skąd pobrać To stała wartość dodawana podczas ekstrakcji i przekształcania danych, a nie pole w samym BMC Helix ITSM. Przykłady BMC Helix ITSM
	Czas zakończenia EventEndTime	Znacznik czasu wskazujący, kiedy zakończyła się dana czynność lub zdarzenie.
Opis Czas zakończenia oznacza koniec czynności. W systemach ITSM wiele czynności to natychmiastowe zmiany statusu, ale niektóre trwają przez określony czas. Czas zakończenia pozwala dokładnie obliczyć czas trwania takich czynności. W analizie czas zakończenia zestawia się z czasem rozpoczęcia, aby obliczyć czas realizacji poszczególnych czynności. Dzięki temu można wskazać konkretne zadania, a nie tylko czas oczekiwania między nimi, które zajmują najwięcej czasu w procesie. Dlaczego to ważne Pozwala obliczyć czas realizacji czynności, co pomaga wykrywać nieefektywne kroki i sprawdzać, na co zespół poświęca czas. Skąd pobrać Wartość można wyliczyć. Czas zakończenia jednej czynności często odpowiada czasowi rozpoczęcia kolejnej czynności w tej samej sprawie. Dla ostatniej czynności będzie to znacznik czasu rozwiązania lub zamknięcia zgłoszenia. Przykłady 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	Priorytet Priority	Priorytet przypisany zgłoszeniu serwisowemu, określający jego wpływ na działalność i pilność.
Opis Priorytet określa kolejność i tempo obsługi zgłoszeń. Typowe wartości to „Krytyczny”, „Wysoki”, „Średni” i „Niski”. Zwykle ustala się go na podstawie wpływu zgłoszenia na działalność i jego pilności. Analiza według priorytetu pozwala sprawdzić, czy zgłoszenia o wysokim priorytecie są obsługiwane szybciej niż te o niskim priorytecie. To ważny wymiar dashboardów dotyczących czasu rozwiązania i zgodności z SLA. Pomaga właściwie przydzielać zasoby do najpilniejszych potrzeb biznesowych. Dlaczego to ważne Pomaga ocenić, czy proces właściwie ustala kolejność pracy i zapewnia oczekiwany poziom usług dla zgłoszeń o różnym wpływie na działalność. Skąd pobrać To pole „Priority” w formularzu „SRM:Request”. Przykłady KrytycznyWysokiŚredniNiski
	Przypisany pracownik AssignedAgent	Użytkownik aktualnie odpowiedzialny za obsługę zgłoszenia serwisowego.
Opis Ten atrybut wskazuje konkretnego pracownika IT lub członka zespołu wsparcia odpowiedzialnego za zgłoszenie w danym momencie. Zmiany wartości tego pola w trakcie obsługi pojedynczego zgłoszenia oznaczają przekazanie go innej osobie lub ponowne przypisanie. Atrybut ten jest ważny przy analizie wyników pracy i obciążenia pracowników. Pozwala sprawdzić, ile zgłoszeń obsługuje każda osoba, jaki jest średni czas ich rozwiązania i jak często zmienia się przypisanie. Dane te wspierają zarządzanie zasobami i pomagają wskazywać potrzeby szkoleniowe. Dlaczego to ważne Śledzenie przypisanego pracownika jest niezbędne do analizy przekazywania zgłoszeń, pomiaru indywidualnych wyników i oceny rozkładu obciążenia w zespole wsparcia. Skąd pobrać Odpowiada polu „Assignee” lub „Assigned To” w rekordzie realizacji, na przykład Work Order lub Incident, powiązanym ze zgłoszeniem serwisowym. Przykłady Bob SmithAlice JohnsonCharlie Brown
	Przypisany zespół AssignedTeam	Grupa wsparcia lub zespół aktualnie odpowiedzialny za zgłoszenie serwisowe.
Opis Ten atrybut wskazuje grupę funkcyjną odpowiedzialną za obsługę zgłoszenia, na przykład „Service Desk”, „Zespół sieci” lub „Administracja bazami danych”. Zmiana wartości oznacza przekazanie odpowiedzialności między zespołami. Analiza według przypisanego zespołu pomaga wykrywać wąskie gardła w pracy poszczególnych zespołów, analizować przekazania między nimi i oceniać efektywność grup wsparcia. Atrybut jest potrzebny w dashboardach „Poprawki i ponowne przypisania zgłoszeń” oraz „Efektywność wstępnej kwalifikacji”. Pokazuje, jak zgłoszenia są kierowane w organizacji. Dlaczego to ważne Pozwala analizować przepływ procesu między grupami funkcyjnymi, wykrywać nieefektywne kierowanie zgłoszeń i mierzyć wyniki poszczególnych zespołów. Skąd pobrać Odpowiada polu „Assigned Group” w rekordzie realizacji, na przykład Work Order lub Incident, powiązanym ze zgłoszeniem serwisowym. Przykłady Service DeskWsparcie infrastrukturyWsparcie aplikacji, poziom 2
	Rodzaj usługi ServiceType	Kategoria lub rodzaj usługi, o którą prosi użytkownik.
Opis Rodzaj usługi określa charakter zgłoszenia, na przykład „Zamówienie nowego oprogramowania”, „Reset hasła” lub „Wdrożenie nowego pracownika”. To podstawowy wymiar filtrowania i segmentowania danych o procesie. W analizie procesów atrybut ten służy do porównywania wyników obsługi różnych rodzajów zgłoszeń. Pomaga odpowiedzieć na pytania: „Które usługi najdłużej czekają na rozwiązanie?” lub „Przy których usługach najczęściej trzeba powtarzać pracę?”. Jest to ważne w dashboardach dotyczących czasu rozwiązania i zgodności z SLA. Dlaczego to ważne Pozwala podzielić zgłoszenia serwisowe na kategorie, porównać przebieg procesu, wykryć problemy dotyczące konkretnych rodzajów usług i odpowiednio zaplanować usprawnienia. Skąd pobrać Dane te często znajdują się w polu „Title” lub polu kategoryzacji formularza „SRM:Request”. Są ustalane na podstawie usługi wybranej z katalogu. Przykłady Zamówienie nowego sprzętuWniosek o dostęp do oprogramowaniaKonfiguracja dostępu VPN
	Status zgłoszenia RequestStatus	Status zgłoszenia serwisowego w chwili wystąpienia zdarzenia, na przykład „In Progress”, „Pending” lub „Closed”.
Opis Ten atrybut zapisuje stan zgłoszenia serwisowego na różnych etapach jego obsługi. Status dostarcza kontekstu dla każdej czynności i często stanowi źródło wartości samego atrybutu „Czynność”. Analiza według statusu pozwala sprawdzić, ile czasu zgłoszenia spędzają w określonych stanach, takich jak „Pending Customer” lub „Waiting for Approval”. Pomaga to wykrywać wąskie gardła i opóźnienia wynikające z zależności zewnętrznych lub kolejek wewnętrznych. Wspiera bezpośrednio dashboard „Identyfikacja wąskich gardeł”. Dlaczego to ważne Pokazuje stan zgłoszenia i pozwala porównać czas spędzony w oczekiwaniu z czasem aktywnej obsługi. Jest to ważne przy wykrywaniu wąskich gardeł. Skąd pobrać To pole „Status” w formularzu „SRM:Request”. Wartości historyczne można znaleźć w dzienniku audytowym. Przykłady PlanowanieW tokuOczekujeRozwiązaneZamknięte
	Czy eskalowano IsEscalated	Wartość logiczna wskazująca, czy zgłoszenie serwisowe zostało eskalowane.
Opis Wartość tego atrybutu jest ustawiana na true, jeśli zgłoszenie serwisowe podlegało eskalacji funkcjonalnej lub hierarchicznej. Eskalacja następuje zwykle wtedy, gdy zgłoszenie nie jest obsługiwane zgodnie z oczekiwaniami, zbliża się termin SLA albo do zatwierdzenia lub podjęcia działania potrzebne są uprawnienia wyższego szczebla. Atrybut jest wykorzystywany w dashboardzie „Analiza efektywności eskalacji zgłoszeń”. Pozwala filtrować i analizować ścieżki obsługi eskalowanych zgłoszeń, ustalać przyczyny eskalacji, mierzyć czas rozwiązania po eskalacji i oceniać skuteczność tego procesu. Dlaczego to ważne Pozwala wyodrębnić i analizować zgłoszenia wymagające eskalacji. Dzięki temu można wykrywać słabe punkty standardowego procesu i ustalać, co prowadzi do eskalacji złożonych problemów. Skąd pobrać Zwykle nie jest to pojedyncze pole. Wartość ustala się na podstawie konkretnych czynności związanych z eskalacją w dzienniku audytowym albo zmian priorytetu lub przypisania zgodnych z procedurą eskalacji. Przykłady truefalse
	Czy przekroczono SLA IsSlaBreached	Wartość logiczna wskazująca, czy zgłoszenie serwisowe rozwiązano po terminie SLA.
Opis Wartość tego obliczanego atrybutu jest ustawiana na true, jeśli znacznik czasu rozwiązania zgłoszenia jest późniejszy niż jego „SLA Target Date”. Atrybut pokazuje w prosty, binarny sposób, czy dla danego zgłoszenia dotrzymano SLA. Jest wykorzystywany w dashboardzie „Przegląd zgodności z SLA” oraz we wskaźniku KPI „Odsetek zgłoszeń obsłużonych zgodnie z SLA”. Ułatwia obliczanie ogólnego poziomu zgodności i filtrowanie zgłoszeń, dla których przekroczono termin. Porównanie ich przebiegu z przebiegiem zgłoszeń obsłużonych zgodnie z SLA pomaga ustalić przyczyny opóźnień. Dlaczego to ważne Ułatwia analizę realizacji SLA, ponieważ porównanie znaczników czasu sprowadza do prostej wartości logicznej. Dzięki temu można łatwo mierzyć i prezentować poziom zgodności. Skąd pobrać To pole obliczane według reguły: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Przykłady truefalse
	Czy wystąpiła poprawka IsRework	Wartość logiczna wskazująca, czy zgłoszenie serwisowe wymagało ponownej pracy, na przykład powrotu do wcześniejszego etapu.
Opis Atrybut wskazuje zgłoszenia serwisowe, w których przebiegu wystąpiła pętla lub konieczne było ponowne wykonanie pracy. Przykładem może być powrót zgłoszenia z etapu „Realizacja w toku” do etapu „Weryfikacja zgłoszenia”. Dokładna definicja zależy od logiki procesu biznesowego. Atrybut wspiera dashboard „Analiza poprawek i ponownych przypisań zgłoszeń” oraz wskaźnik KPI „Odsetek zgłoszeń wymagających poprawek”. Pozwala mierzyć częstotliwość poprawek i analizować ich typowe przyczyny, takie jak błędna wstępna ocena lub niekompletne informacje. Takie problemy obniżają efektywność procesu. Dlaczego to ważne Pokazuje nieefektywność procesu, wskazując zgłoszenia, których przebieg odbiega od standardowej ścieżki. Pomaga ustalić przyczyny powrotów do wcześniejszych etapów i powtarzania pracy. Skąd pobrać To atrybut obliczany na podstawie kolejności czynności w dzienniku zdarzeń. Do wykrywania cofnięć w przebiegu procesu potrzebna jest odpowiednia logika. Przykłady truefalse
	Dział osoby zgłaszającej RequestorDepartment	Dział lub jednostka biznesowa użytkownika, który zgłosił potrzebę obsługi serwisowej.
Opis Ten atrybut wskazuje dział organizacji, w którym pracuje osoba zgłaszająca potrzebę obsługi serwisowej, na przykład finanse, kadry lub IT. Informacje te pochodzą zwykle z profilu użytkownika w systemie. Podział analizy procesu według działów pozwala określić ich potrzeby, wzorce zgłoszeń i obszary, w których warto przeprowadzić szkolenia lub usprawnić obsługę. Można na przykład sprawdzić, czy zgłoszenia z działu finansów są obsługiwane dłużej. Dlaczego to ważne Umożliwia analizę wykorzystania usług i wyników procesu w poszczególnych jednostkach biznesowych, co pomaga wykrywać problemy i trendy dotyczące konkretnych działów. Skąd pobrać Informacje te są zwykle pobierane z profilu użytkownika wskazanego w polu „Requested For” formularza „SRM:Request”. Przykłady FinanseSprzedażKadryTechnologie informatyczne
	Kanał zgłoszenia SubmissionChannel	Sposób lub kanał, za pośrednictwem którego zgłoszono potrzebę obsługi serwisowej.
Opis Ten atrybut określa, w jaki sposób zainicjowano zgłoszenie serwisowe, na przykład przez portal samoobsługowy, e-mail, telefon do Service Desk lub automatyczny alert systemowy. Różne kanały mogą wiązać się z innymi wariantami procesu i czasem rozwiązania. Analiza procesu według kanału zgłoszenia może ujawnić nieefektywne działania lub dobre praktyki związane z poszczególnymi sposobami przyjmowania zgłoszeń. Zgłoszenia z portalu samoobsługowego mogą być na przykład rozwiązywane szybciej dzięki lepszej jakości danych na początku procesu. Zgłoszenia e-mailowe mogą natomiast wymagać więcej ręcznej wstępnej kwalifikacji. Dlaczego to ważne Pozwala sprawdzić, jak sposób przyjęcia zgłoszenia wpływa na efektywność procesu, jakość danych i całkowity czas obsługi. Dzięki temu można wprowadzać ukierunkowane usprawnienia w poszczególnych kanałach. Skąd pobrać Wartość można często ustalić na podstawie pól takich jak „Client Type” lub „Reported Source” w formularzu „SRM:Request” albo w powiązanych zgłoszeniach realizacyjnych. Przykłady Portal samoobsługowyE-mailTelefonWygenerowane przez system
	Kategoria rozwiązania ResolutionCategory	Klasyfikacja sposobu rozwiązania zgłoszenia.
Opis Ten atrybut pozwala uporządkować informacje o sposobie rozwiązania zgłoszenia, na przykład „Poprawka oprogramowania”, „Szkolenie użytkownika” lub „Korekta danych”. Opisuje charakter rozwiązania dokładniej niż sam kod zamknięcia. Atrybut jest potrzebny w dashboardzie „Trafność kategorii rozwiązania”, gdzie można porównać kategorię z początkowym typem usługi i sprawdzić ich zgodność. Analiza kategorii rozwiązań pomaga wykrywać powtarzające się problemy i planować działania zapobiegawcze. Jeśli wiele zgłoszeń rozwiązuje się przez szkolenie użytkowników, może to wskazywać na potrzebę szerszego wsparcia w tym obszarze. Dlaczego to ważne Pokazuje, na czym polegały zastosowane rozwiązania. Pomaga wykrywać powtarzające się problemy i wskazywać możliwości zapobiegania im lub szkolenia użytkowników. Skąd pobrać Informacje te są częścią pól klasyfikacji operacyjnej i produktowej zgłoszenia realizacyjnego. Pole jest często oznaczone jako „Resolution Category”. Przykłady Administracja kontamiAwaria sprzętuAktualizacja oprogramowaniaInformacje przekazane
	Kod zamknięcia CloseCode	Kod określający wynik lub przyczynę zamknięcia zgłoszenia serwisowego.
Opis Kod zamknięcia pozwala w ujednolicony sposób klasyfikować rozwiązania zgłoszeń serwisowych. Przykładowe wartości to „Rozwiązane przez Service Desk”, „Anulowane przez użytkownika” i „Zduplikowane zgłoszenie”. Analiza kodów zamknięcia pomaga ustalić, jakie są najczęstsze wyniki obsługi zgłoszeń. Może ujawnić na przykład dużą liczbę zgłoszeń anulowanych przez użytkowników, co może wskazywać na zbyt długi proces, albo wiele duplikatów, które mogą wynikać z problemów systemowych lub komunikacyjnych. Atrybut ten jest wykorzystywany w dashboardzie „Trafność kategorii rozwiązania”. Dlaczego to ważne Dostarcza uporządkowanych danych o wynikach obsługi zgłoszeń, dzięki czemu można analizować skuteczność rozwiązań oraz przyczyny nieukończenia lub anulowania zgłoszeń. Skąd pobrać Informacje te znajdują się zwykle w polu „Resolution” lub „Closure Code” zgłoszenia realizacyjnego powiązanego ze zgłoszeniem serwisowym. Przykłady RozwiązaneAnulowane przez użytkownikaNie jest już potrzebneRozwiązane automatycznie
	Liczba przekazań HandoffCount	Łączna liczba zmian przypisania zgłoszenia serwisowego między agentami lub zespołami.
Opis Ta miara obliczana zlicza zmiany wartości „AssignedAgent” lub „AssignedTeam” dla pojedynczego zgłoszenia serwisowego. Duża liczba przekazań może wskazywać na rozdrobnienie procesu, brak rozwiązania sprawy przy pierwszym kontakcie lub nieefektywne kierowanie zgłoszeń. Atrybut stanowi podstawę wskaźnika KPI „Średnia liczba przekazań między agentami na zgłoszenie” i jest wykorzystywany w dashboardzie „Poprawki i ponowne przypisania zgłoszeń”. Analiza zgłoszeń z dużą liczbą przekazań może wskazać możliwości usprawnienia wstępnej kwalifikacji, poprawy szkoleń lub uproszczenia procesu rozwiązywania zgłoszeń. Może to skrócić opóźnienia i poprawić zadowolenie klientów. Dlaczego to ważne Mierzy rozdrobnienie procesu i nakład pracy związany z komunikacją. Duża liczba przekazań często wiąże się z dłuższym czasem rozwiązania i niższą efektywnością procesu. Skąd pobrać To miara obliczana przez zliczenie różnych wartości atrybutu „AssignedAgent” lub „AssignedTeam” dla każdego unikalnego identyfikatora zgłoszenia serwisowego. Przykłady 0135
	Termin realizacji SLA SlaTargetDate	Data i godzina, do których zgodnie z umową SLA należy rozwiązać zgłoszenie serwisowe.
Opis Termin realizacji SLA to obliczony znacznik czasu określający ostateczny termin obsługi zgłoszenia serwisowego. Wyznaczają go zasady umowy serwisowej, które często uwzględniają takie czynniki jak priorytet i typ zgłoszenia. Atrybut ten stanowi podstawę dashboardu „Przegląd zgodności z SLA”. Jest punktem odniesienia przy pomiarze rzeczywistego czasu rozwiązania zgłoszenia. Porównanie „EventEndTime” ostatniej czynności rozwiązującej zgłoszenie z terminem SLA pozwala ustalić, czy dotrzymano zobowiązania serwisowego. Dlaczego to ważne To podstawowy punkt odniesienia przy ocenie realizacji zobowiązań serwisowych, niezbędny do monitorowania i raportowania zgodności z SLA. Skąd pobrać Datę oblicza i zapisuje moduł Service Level Management (SLM). Można ją znaleźć w powiązanych formularzach SLM. Przykłady 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z

Wymagane Zalecane Opcjonalne

Czynności w procesie obsługi zgłoszeń serwisowych

Aby prawidłowo odkryć i zwizualizować proces, należy rejestrować w dzienniku zdarzeń te kroki i kamienie milowe.

6 Zalecane 8 Opcjonalne

	Działanie	Opis
	Realizacja w toku	Przypisany pracownik lub zespół rozpoczął realizację zgłoszenia serwisowego. Zgłoszenie opuściło kolejkę i jest aktywnie obsługiwane.
Dlaczego to ważne To początek pracy związanej z realizacją zgłoszenia. Analiza czasu trwania tego etapu pomaga ocenić produktywność zespołu i złożoność realizacji. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu w formularzu SRM:Request na „In Progress”. Rejestrowanie Znacznik czasu aktualizacji, podczas której pole „Status” w SRM:Request zmienia wartość na „In Progress”. Typ zdarzenia inferred
	Zgłoszenie przypisane	Zgłoszenie serwisowe przypisano konkretnemu pracownikowi lub zespołowi odpowiedzialnemu za jego realizację. Oznacza to koniec etapu klasyfikacji.
Dlaczego to ważne Ten etap jest ważny przy pomiarze czasu klasyfikacji i analizie obciążenia pracowników. Częste zmiany przypisania mogą wskazywać na problemy z kierowaniem zgłoszeń lub braki kompetencyjne. Skąd pobrać Zdarzenie można odczytać bezpośrednio z dziennika audytowego pól „Assigned Group” lub „Assignee” w formularzu SRM:Request albo w powiązanych formularzach realizacji, na przykład WOI:WorkOrder. Rejestrowanie Znacznik czasu z dziennika audytowego wskazujący, kiedy po raz pierwszy ustawiono niepustą wartość pola „Assignee”. Typ zdarzenia explicit
	Zgłoszenie serwisowe anulowane	Osoba, która złożyła zgłoszenie, lub zespół service desk wycofał je przed zakończeniem realizacji. Jest to stan końcowy zgłoszenia.
Dlaczego to ważne Analiza anulowanych zgłoszeń pomaga wykrywać powtarzające się przyczyny, na przykład błędnie składane zgłoszenia lub usługi, które nie są już potrzebne. Wnioski można wykorzystać do ulepszenia katalogu usług. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu w formularzu SRM:Request na „Canceled”. Rejestrowanie Znacznik czasu aktualizacji, podczas której pole „Status” w SRM:Request zmienia wartość na „Canceled”. Typ zdarzenia inferred
	Zgłoszenie serwisowe rozwiązane	Realizacja zgłoszenia serwisowego została zakończona, a informację o rozwiązaniu przekazano osobie, która je złożyła. Zgłoszenie oczekuje na ostateczne potwierdzenie lub zostanie automatycznie zamknięte po upływie określonego czasu.
Dlaczego to ważne To ważny etap oznaczający koniec cyklu świadczenia usługi. Stanowi główny punkt końcowy przy pomiarze czasu rozwiązania zgłoszenia i realizacji SLA. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu w formularzu SRM:Request na „Resolved” lub „Completed”. Rejestrowanie Znacznik czasu aktualizacji, podczas której pole „Status” w SRM:Request zmienia wartość na „Resolved” lub „Completed”. Typ zdarzenia inferred
	Zgłoszenie serwisowe wysłane	To zdarzenie oznacza utworzenie i wysłanie nowego zgłoszenia serwisowego przez użytkownika. Jest rejestrowane, gdy w formularzu SRM:Request powstaje nowy wpis ze statusem początkowym, zwykle „Submitted”.
Dlaczego to ważne To początek obsługi każdego zgłoszenia serwisowego. Zdarzenie jest niezbędne do pomiaru całkowitego czasu obsługi i analizy liczby przyjmowanych zgłoszeń. Skąd pobrać Zdarzenie jest ustalane na podstawie znacznika czasu utworzenia rekordu i jego początkowego statusu, na przykład „Submitted”, w formularzu SRM:Request. Rejestrowanie Ustal znacznik czasu utworzenia nowego Service Request ID w formularzu SRM:Request, gdy status ma wartość „Submitted”. Typ zdarzenia inferred
	Zgłoszenie serwisowe zamknięte	Zgłoszenie serwisowe zostało formalnie zamknięte i przeniesione do zarchiwizowanego stanu tylko do odczytu. Następuje to po rozwiązaniu zgłoszenia i upływie okresu na potwierdzenie.
Dlaczego to ważne Ta czynność oznacza ostateczny koniec procesu. Czas między statusami „Resolved” i „Closed” może wskazać nieefektywności w procedurze zamykania zgłoszeń. Skąd pobrać Zdarzenie jest ustalane na podstawie końcowej zmiany statusu w formularzu SRM:Request na „Closed”. Rejestrowanie Znacznik czasu aktualizacji, podczas której pole „Status” w SRM:Request zmienia wartość na „Closed”. Typ zdarzenia inferred
	Prośba o informacje od użytkownika	Pracownik realizujący zgłoszenie potrzebuje dodatkowych informacji od osoby, która je złożyła. Zgłoszenie zwykle otrzymuje wtedy status „Pending”.
Dlaczego to ważne Ta czynność pozwala obliczyć „Czas oczekiwania na informacje z zewnątrz” i ustalić, jak często zgłoszenia są wstrzymywane z powodu brakujących informacji. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu w formularzu SRM:Request na „Pending” oraz przyczyny statusu, takiej jak „Customer Hold” lub „Awaiting Information”. Rejestrowanie Znacznik czasu zmiany statusu na „Pending” wraz z określoną przyczyną statusu. Typ zdarzenia inferred
	Rozwiązanie wdrożone	Pracownik zakończył prace techniczne wymagane do realizacji zgłoszenia serwisowego. Zgłoszenie jest gotowe do potwierdzenia przez użytkownika przed formalnym rozwiązaniem.
Dlaczego to ważne Ta czynność oddziela zakończenie prac technicznych od formalnego rozwiązania zgłoszenia. Dzięki temu można wykryć opóźnienia między zakończeniem pracy a potwierdzeniem przez użytkownika. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany statusu zgłoszenia realizacyjnego w systemie zaplecza, na przykład zmiany statusu Work Order na „Completed”, zanim nadrzędny SRM:Request otrzyma status „Resolved”. Rejestrowanie Znacznik czasu oznaczający zakończenie zgłoszenia w systemie zaplecza, takiego jak Work Order lub Incident, powiązanego z SRM:Request. Typ zdarzenia inferred
	Użytkownik potwierdził rozwiązanie	Osoba, która złożyła zgłoszenie, potwierdziła, że usługa została zrealizowana zgodnie z oczekiwaniami i zgłoszenie jest rozwiązane. Często powoduje to jego ostateczne zamknięcie.
Dlaczego to ważne To wyraźny sygnał zadowolenia klienta i formalne zakończenie obsługi. Pozwala odróżnić rozwiązanie zgłoszenia od akceptacji przez klienta. Skąd pobrać Zdarzenie może być zapisane w dzienniku pracy SRM:Request lub notatkach o aktywności, gdy użytkownik potwierdzi rozwiązanie przez portal lub e-mail. Nie zawsze odpowiada mu osobny status. Rejestrowanie Przeszukaj dzienniki pracy (SRM:WorkInfo) w poszukiwaniu wpisów potwierdzających akceptację użytkownika lub wypełnienie ankiety. Typ zdarzenia explicit
	Wznowienie obsługi zgłoszenia	Zgłoszenie serwisowe przestaje oczekiwać, zwykle po otrzymaniu wymaganych informacji od użytkownika. Pracownik wznawia jego realizację.
Dlaczego to ważne To zdarzenie kończy okres oczekiwania. Pozwala dokładnie mierzyć czas oczekiwania na informacje z zewnątrz i ocenić jego wpływ na zgodność z SLA. Skąd pobrać Zdarzenie jest ustalane, gdy status SRM:Request zmienia się z „Pending” z powrotem na „In Progress”. Rejestrowanie Znacznik czasu aktualizacji, podczas której pole „Status” w SRM:Request zmienia wartość z „Pending” na „In Progress”. Typ zdarzenia inferred
	Zgłoszenie oczekuje na zatwierdzenie	Zgłoszenie serwisowe przekazano wyznaczonej osobie lub grupie zatwierdzającej. Oczekuje ono na decyzję, zanim rozpocznie się realizacja. Ten etap często dotyczy zgłoszeń związanych z kosztami lub uprawnieniami dostępu.
Dlaczego to ważne Ta czynność pozwala wyodrębnić opóźnienia związane z zatwierdzaniem, analizować czas trwania tego etapu i wskazywać wąskie gardła w ścieżce akceptacji. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu w formularzu SRM:Request na wartość taką jak „Waiting Approval”. Rejestrowanie Znacznik czasu aktualizacji, podczas której pole „Status” w SRM:Request zmienia wartość na „Waiting Approval”. Typ zdarzenia inferred
	Zgłoszenie odrzucone	Zgłoszenie serwisowe odrzucono na etapie zatwierdzania. Jest to stan końcowy, który zatrzymuje proces przed rozpoczęciem realizacji.
Dlaczego to ważne Analiza odrzuconych zgłoszeń może ujawnić problemy z uzasadnieniem wniosków, kryteriami kwalifikacji lub zasadami zatwierdzania. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu w formularzu SRM:Request na „Rejected”. Rejestrowanie Znacznik czasu aktualizacji, podczas której pole „Status” w SRM:Request zmienia wartość na „Rejected”. Typ zdarzenia inferred
	Zgłoszenie w trakcie weryfikacji	Zespół service desk wstępnie weryfikuje i klasyfikuje zgłoszenie, aby ustalić jego charakter, priorytet oraz właściwy zespół realizujący. Zwykle odpowiada temu zmiana statusu rekordu zgłoszenia.
Dlaczego to ważne Śledzenie tej czynności pozwala mierzyć sprawność klasyfikacji i wykrywać opóźnienia między wysłaniem zgłoszenia a jego przypisaniem. Jest to ważne przy obliczaniu KPI „Średni czas klasyfikacji”. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu w formularzu SRM:Request na wartość taką jak „In Review” lub „Planning”. Rejestrowanie Znacznik czasu aktualizacji, podczas której pole „Status” w SRM:Request zmienia wartość na „In Review”. Typ zdarzenia inferred
	Zgłoszenie zatwierdzone	Wymagana osoba lub grupa formalnie zatwierdziła zgłoszenie serwisowe, więc można rozpocząć jego realizację. Zdarzenie to zwykle następuje po statusie „Waiting for Approval”.
Dlaczego to ważne To zdarzenie kończy podproces zatwierdzania. Pozwala mierzyć czas oczekiwania na akceptację i ocenić jej wpływ na całkowity czas rozwiązania zgłoszenia. Skąd pobrać Zdarzenie jest ustalane na podstawie zmiany statusu w formularzu SRM:Request z „Waiting Approval” na kolejny status, na przykład „Planning” lub „In Progress”. Sama decyzja o zatwierdzeniu jest rejestrowana w powiązanych formularzach akceptacji. Rejestrowanie Znacznik czasu zmiany statusu z „Waiting Approval” po pozytywnej decyzji o zatwierdzeniu. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje wyodrębniania danych

Jak pobrać dane z BMC Helix ITSM

Kroki

Otwórz Smart Reporting: Zaloguj się do środowiska BMC Helix ITSM. Przejdź do sekcji raportowania i uruchom Smart Reporting. W zależności od wersji opcja może nazywać się „Reports” lub „Smart Reporting”.
Utwórz nowy raport: W interfejsie Smart Reporting wybierz opcję utworzenia nowego raportu. Jako typ wybierz „Report”.
Wybierz źródło danych i widok: Wskaż główne źródło danych AR System. Następnie wyszukaj i wybierz widok Service Request, który zwykle opiera się na formularzu SRM:Request.
Dodaj powiązane formularze (złączenia): Aby uwzględnić cały przebieg procesu, połącz główny formularz SRM:Request z powiązanymi formularzami. Na karcie „Data” dodaj następujące złączenia:
- SRM:WorkInfo (według SR ID+ = Request Number), aby pobrać szczegóły działań związanych z realizacją i wpisy w dzienniku pracy.
- AP:Signature (według Request = SRInstanceID), aby pobrać zdarzenia związane z zatwierdzaniem, takie jak akceptacje i odrzucenia. Może być konieczne skonfigurowanie niestandardowego złączenia.
Określ kolumny raportu: Przeciągnij wymagane pola z połączonych formularzy do obszaru „Columns”. Uwzględnij między innymi pola Request Number, Submit Date, Status, Description, Priority, Assigned To i Assigned Group z formularza SRM:Request oraz powiązane pola z pozostałych formularzy.
Utwórz pola obliczeniowe dla działań: W tej metodzie należy utworzyć serię pól obliczeniowych, które będą zawierać znaczniki czasu poszczególnych działań. Na karcie „Data” utwórz osobne pole dla każdego działania. Na przykład:
- Znacznik czasu przesłania: Użyj bezpośrednio pola Submit Date.
- Znacznik czasu zatwierdzenia: Użyj pola Signature Date z formularza AP:Signature.
- Znacznik czasu rozpoczęcia pracy: Użyj wartości MIN(Submit Date) z formularza SRM:WorkInfo, pogrupowanej według numeru zgłoszenia.
Przygotuj raport do połączenia wyników: Smart Reporting nie ma prostego przycisku „UNION ALL”, takiego jak SQL. Aby uzyskać podobny wynik, utwórz jeden raport i użyj zaawansowanych funkcji lub podzapytań do przekształcenia danych. Często stosuje się kilka kolumn obliczeniowych, po jednej dla znacznika czasu każdego działania. Następnie trzeba przekształcić dane z eksportu tak, aby każde działanie znalazło się w osobnym wierszu.
Zastosuj filtry: Ogranicz zakres danych i skróć czas generowania raportu, dodając filtry. Co najmniej filtruj według pola Submit Date z formularza SRM:Request, aby wybrać konkretny zakres dat. W środowisku wielofirmowym dodaj również filtr „Company”.
Uruchom raport i sprawdź dane: Uruchom raport i upewnij się, że dane są pobierane prawidłowo. Sprawdź złączenia, wypełnienie kolumn oraz to, czy pola obliczeniowe zwracają oczekiwane znaczniki czasu.
Wyeksportuj raport: Po sprawdzeniu raportu wyeksportuj dane do CSV lub Microsoft Excel. Te formaty można łatwo przygotować do zaimportowania do narzędzi process mining.
Przekształć dane po eksporcie: Zmień szeroki układ danych (jeden wiersz na zgłoszenie i wiele kolumn ze znacznikami czasu) na układ długi (jeden wiersz na działanie). Użyj skryptu, na przykład w Pythonie lub PowerShell, albo narzędzia takiego jak Excel Power Query, aby przekształcić kolumny ze znacznikami czasu w dwie kolumny: ActivityName i EventStartTime. Ten krok jest niezbędny do utworzenia wymaganego dziennika zdarzeń.

Konfiguracja

Wymagania wstępne: Potrzebne jest konto użytkownika z uprawnieniami do raportowania w BMC Helix ITSM, w tym do tworzenia i uruchamiania raportów w Smart Reporting. Konto musi też mieć uprawnienia do odczytu danych z formularzy SRM:Request, SRM:WorkInfo i AP:Signature.
Najważniejsze formularze: Raport powstaje przez połączenie następujących formularzy:
- SRM:Request: Główny formularz ze szczegółami zgłoszenia serwisowego.
- SRM:WorkInfo: Zawiera wpisy w dzienniku pracy, na podstawie których można odtworzyć działania związane z realizacją zgłoszenia.
- AP:Signature: Zawiera rekordy zatwierdzeń potrzebne do śledzenia działań związanych z akceptacją.
Filtrowanie według zakresu dat: Zawsze filtruj według pola SRM:Request.Submit Date. Zalecany zakres to 3–6 miesięcy danych. Pozwala to uzyskać reprezentatywną próbkę bez nadmiernego obciążania raportu.
Ważne filtry: Oprócz zakresu dat filtruj według pola „Company”, aby wyodrębnić dane konkretnej jednostki biznesowej. Można też wykluczyć typy zgłoszeń lub statusy, które nie mają znaczenia dla analizy procesu, na przykład „Draft”.
Wydajność: Raporty łączące wiele formularzy i obejmujące długi zakres dat mogą generować się powoli. Przy dużych wolumenach danych warto zaplanować ich uruchamianie poza godzinami szczytu. Jeśli występują przekroczenia limitu czasu, należy podzielić eksport na mniejsze, miesięczne partie.

Przykładowe zapytanie sql

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

Kroki

Wymagania wstępne: Przygotuj klienta bazodanowego, na przykład DBeaver, SQL Server Management Studio lub Oracle SQL Developer, oraz dane logowania z uprawnieniami tylko do odczytu do bazy BMC Helix AR System.
Połącz się z bazą danych: Użyj klienta bazodanowego, aby nawiązać połączenie z serwerem bazy AR System.
Przygotuj zapytanie: Skopiuj całe zapytanie SQL z sekcji „Query” tego dokumentu do edytora zapytań w kliencie bazodanowym.
Ustaw parametry: Znajdź w zapytaniu wartości zastępcze. Zastąp :start_date i :end_date wybranym zakresem dat, na przykład '2023-01-01' i '2023-12-31'. Jeśli ma to zastosowanie, zastąp :company_name nazwą firmy, według której mają być filtrowane dane.
Uruchom zapytanie: Wykonaj zmodyfikowane zapytanie SQL. W zależności od zakresu dat i wielkości systemu może to potrwać kilka minut.
Sprawdź wyniki: Po zakończeniu zapytania zostanie wyświetlony zestaw wyników zawierający dziennik zdarzeń. Sprawdź, czy dane zostały poprawnie pobrane i zawierają oczekiwane kolumny oraz działania.
Sprawdź znaczniki czasu: Upewnij się, że wszystkie kolumny ze znacznikami czasu, w szczególności EventStartTime, EventEndTime i LastDataUpdate, mają spójny format, na przykład 'YYYY-MM-DD HH:MI:SS'. Jeśli baza zwraca inny format, odpowiednio zmień w zapytaniu funkcje TO_CHAR lub CONVERT.
Wyeksportuj dane: Użyj funkcji eksportu w kliencie bazodanowym, aby zapisać cały zestaw wyników w pliku CSV. Wybierz kodowanie UTF-8, aby zapewnić zgodność.
Przygotuj plik do przesłania: Nadaj plikowi odpowiednią nazwę, na przykład servicerequest_eventlog.csv. Plik jest gotowy do przesłania na platformę ProcessMind.

Konfiguracja

Dane logowania do bazy: Wymagane jest konto użytkownika z uprawnieniami tylko do odczytu bazy AR System. Zapobiega to przypadkowej modyfikacji danych i jest zgodne z dobrymi praktykami bezpieczeństwa.
Filtrowanie według zakresu dat: Zapytanie zawiera parametry :start_date i :end_date. Należy ustawić konkretny, rozsądny zakres, zwykle obejmujący 3–12 miesięcy danych, aby kontrolować wydajność zapytania i ilość pobieranych danych. Filtrowanie odbywa się według pola Submit_Date zgłoszenia serwisowego.
Filtr firmy: Parametr :company_name pozwala wybrać zgłoszenia konkretnej firmy operacyjnej. Aby pobrać dane wszystkich firm, można usunąć wiersz AND req.Company = :company_name lub ustawić w nim symbol wieloznaczny, jeśli jest obsługiwany.
Wartości statusów: Zapytanie korzysta ze standardowych wartości liczbowych statusów BMC Helix ITSM, na przykład Submitted = 0, In Review = 1. W danym systemie mogą być używane statusy niestandardowe lub inne przypisania liczbowe. Sprawdź wartości w formularzu SYS:Status lub w Developer Studio i w razie potrzeby zmień klauzule WHERE w zapytaniu.
Wydajność: Bezpośrednie zapytania do dużych tabel, takich jak SRM_Request, oraz dzienników audytu mogą obciążać zasoby. Aby ograniczyć wpływ na wydajność systemu, zaplanuj pobieranie danych poza godzinami szczytu.

Przykładowe zapytanie sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

Kroki

Wymagania wstępne: Upewnij się, że w systemie jest zainstalowany Python 3.6 lub nowszy. Zainstaluj bibliotekę requests, potrzebną do wykonywania wywołań HTTP API, uruchamiając w terminalu lub wierszu polecenia pip install requests.
Uzyskaj dane dostępowe do API: Utwórz lub uzyskaj dane logowania dla dedykowanego konta serwisowego w BMC Helix ITSM. Konto musi mieć co najmniej uprawnienia tylko do odczytu formularza SRM:Request i powiązanego formularza dziennika audytu, który często nazywa się SRM:Request_AuditLog lub podobnie. Zapisz nazwę użytkownika, hasło i podstawowy URL instancji BMC Helix, na przykład https://[your-company].bmc.com.
Skonfiguruj skrypt Python: Zapisz udostępniony skrypt Python w pliku, na przykład extract_servicerequests.py. Otwórz go i uzupełnij zmienne zastępcze na początku: BASE_URL, USERNAME, PASSWORD i AUDIT_FORM_NAME. Dostosuj słownik STATUS_ACTIVITY_MAP do statusów używanych w workflow obsługi zgłoszeń serwisowych w Państwa organizacji.
Ustaw okres pobierania danych: Zmień zmienne START_DATE i END_DATE w skrypcie. Określają one przedział czasu pobierania danych na podstawie daty przesłania zgłoszenia serwisowego. Na początek warto przetestować skrypt na krótkim zakresie, na przykład obejmującym jeden dzień.
Uruchom skrypt: W terminalu wykonaj polecenie python extract_servicerequests.py. Skrypt najpierw uwierzytelni się za pomocą API, aby uzyskać token.
Pobierz dane podstawowe: Skrypt odpytuje formularz SRM:Request, aby pobrać listę wszystkich zgłoszeń serwisowych utworzonych w wybranym zakresie dat. Zbiera identyfikator case oraz powiązane atrybuty statyczne, takie jak priorytet i typ usługi.
Pobierz historię zdarzeń: Skrypt przetwarza kolejno identyfikatory zgłoszeń serwisowych uzyskane w poprzednim kroku. Dla każdego z nich wykonuje drugie wywołanie API do skonfigurowanego formularza dziennika audytu, aby pobrać szczegółową historię zmian statusu danego zgłoszenia.
Przekształć dane w dziennik zdarzeń: Dla każdego rekordu z dziennika audytu skrypt przypisuje zmianie statusu standardową nazwę działania na podstawie słownika STATUS_ACTIVITY_MAP. Tworzy wiersz dla każdego przypisanego działania, zawierający identyfikator zgłoszenia serwisowego, nazwę działania i znacznik czasu zmiany.
Dodaj zdarzenie przesłania zgłoszenia: Skrypt tworzy też początkowe działanie „Service Request Submitted” dla każdego zgłoszenia, korzystając z pola Submit Date w głównym formularzu SRM:Request.
Wyeksportuj dane do CSV: Po przetworzeniu wszystkich zgłoszeń serwisowych i ich historii skrypt łączy wygenerowane wiersze w jedną listę i zapisuje je w pliku CSV servicerequest_event_log.csv. Plik ma format gotowy do przesłania do narzędzia process mining.

Konfiguracja

Punkty końcowe API: Skrypt korzysta głównie z dwóch punktów końcowych API. Uwierzytelnianie odbywa się przez api/jwt/login. Dane są pobierane z arsys/v1/entry/SRM:Request (lista case) oraz arsys/v1/entry/[AUDIT_FORM_NAME] (historia zdarzeń).
Uprawnienia konta serwisowego: Wymagane jest dedykowane konto serwisowe z dostępem do odczytu formularza SRM:Request i systemowego formularza dziennika audytu. Korzystanie z takiego konta zwiększa bezpieczeństwo i ułatwia śledzenie działań.
Filtrowanie według zakresu dat: Skrypt filtruje zgłoszenia serwisowe według pola Submit Date. Zaleca się pobieranie danych w partiach, na przykład po 3–6 miesięcy, aby zapewnić niezawodne działanie.
Mapowanie statusów na działania: Słownik STATUS_ACTIVITY_MAP w skrypcie odpowiada za główną logikę przekształcania danych. Należy go skonfigurować tak, aby uwzględniał statusy niestandardowe używane w organizacji i przypisywał im odpowiednie nazwy działań. Statusy niewystępujące w słowniku zostaną pominięte.
Formularz dziennika audytu: Możliwość pobrania szczegółowych działań zależy od dostępności dziennika audytu, który można odpytywać. Należy ustalić nazwę właściwego formularza przechowującego historię zmian statusu zgłoszeń serwisowych i odpowiednio ustawić zmienną AUDIT_FORM_NAME.
Paginacja: Skrypt automatycznie obsługuje paginację API, aby pobrać wszystkie rekordy. Parametr limit w wywołaniu API ustawiono na 1000 rekordów na żądanie, co pozwala zachować równowagę między wydajnością a zużyciem pamięci.

Przykładowe zapytanie python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

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

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

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

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby usprawnić zbieranie danych i rozpocząć process mining. Już dziś zacznij optymalizować obsługę zgłoszeń serwisowych.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Sprawniejsza obsługa zgłoszeń serwisowych: usprawnij proces już dziś

Osiągnij 70% automatyzacji, wyeliminuj opóźnienia w realizacji zgłoszeń i popraw doświadczenia użytkowników.

Rozpocznij okres próbny

Bez podawania danych karty kredytowej. Rozpoczęcie zajmuje kilka minut.

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

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

Atrybuty obsługi zgłoszeń serwisowych

Czynności w procesie obsługi zgłoszeń serwisowych

Instrukcje wyodrębniania danych

Raportowanie Smart Reporting w BMC Helix ITSM dla zgłoszeń serwisowych

Kroki

Konfiguracja

Przykładowe zapytanie sql

Bezpośrednie zapytanie SQL do tabel bazy danych AR System

Kroki

Konfiguracja

Przykładowe zapytanie sql

Pobieranie danych skryptem Python przez BMC Helix REST API

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Sprawniejsza obsługa zgłoszeń serwisowych: usprawnij proces już dziś