Szablon danych do zarządzania problemami
Szablon danych do zarządzania problemami
- Zalecane atrybuty do szczegółowej analizy
- Najważniejsze czynności procesu i zmiany statusu
- Wskazówki dotyczące ekstrakcji danych z Zendesk Support
Atrybuty zarządzania problemami
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas rozpoczęcia
EventTimestamp
|
Dokładna data i godzina wystąpienia działania. | ||
|
Opis
Ten atrybut zapisuje dokładny moment wykonania działania w systemie Zendesk. Dostarcza informacji o czasie, które są potrzebne do prawidłowego uporządkowania zdarzeń i obliczenia czasu między etapami. W analizie jest niezbędny do obliczania czasu cyklu, wykrywania opóźnień, sprawdzania zgodności z SLA i przedstawiania przebiegu procesu w czasie. Bez dokładnych znaczników czasu nie można ocenić tempa rozwiązywania problemów.
Dlaczego to ważne
Umożliwia sortowanie działań i obliczanie wszystkich KPI opartych na czasie.
Skąd pobrać
Zendesk Ticket Audits, pole „created_at”
Przykłady
2023-10-12T08:30:00Z2023-10-12T09:15:22Z
|
|||
|
Działanie
ActivityName
|
Nazwa zdarzenia lub działania wykonanego w ramach rekordu problemu. | ||
|
Opis
Ten atrybut opisuje konkretny etap lub działanie w cyklu życia rekordu problemu. Przykłady obejmują zmianę statusu, na przykład z „Open” na „Pending”, zmianę przypisania lub określony etap workflow, taki jak „Workaround Published”. Na mapie procesu atrybut ten odpowiada węzłom. Kolejność działań pozwala analitykom zobaczyć przepływ pracy, wykrywać wąskie gardła i mierzyć czas między poszczególnymi etapami procesu.
Dlaczego to ważne
Określa, co dzieje się w procesie, i umożliwia wizualizację jego przebiegu oraz analizę wariantów.
Skąd pobrać
Dane pochodzą z Zendesk Ticket Audits lub Ticket Metrics
Przykłady
Zarejestrowanie rekordu problemuRozpoczęcie dochodzeniaOpublikowanie obejścia
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu ostatniej modyfikacji rekordu problemu. | ||
|
Opis
Ten atrybut wskazuje, kiedy dane rekordu problemu zostały ostatnio zaktualizowane w systemie źródłowym. Różni się od znacznika czasu zdarzenia, ponieważ dotyczy całego rekordu, a nie pojedynczego działania. W analizie pomaga ocenić aktualność danych. Pozwala sprawdzić, czy zbiór danych jest bieżący i czy między systemem źródłowym a środowiskiem process mining występują opóźnienia synchronizacji.
Dlaczego to ważne
Pozwala kontrolować aktualność danych i wspiera strategie ich przyrostowego ładowania.
Skąd pobrać
Obiekt Zendesk Ticket, pole „updated_at”
Przykłady
2023-11-01T14:20:00Z
|
|||
|
Rekord problemu
ProblemRecordId
|
Unikatowy identyfikator numeryczny przypisany zgłoszeniu problemu w Zendesk. | ||
|
Opis
Ten atrybut jest unikatowym kluczem rekordu problemu w systemie Zendesk Support. Stanowi centralny identyfikator case w process mining, dzięki któremu wszystkie późniejsze zdarzenia, aktualizacje i interakcje można przypisać do jednej instancji procesu. W analizie identyfikator służy do odróżniania poszczególnych przebiegów dochodzenia, od utworzenia rekordu po jego zamknięcie. Umożliwia powiązanie powiązanych incydentów i śledzenie cyklu życia problemu na kolejnych poziomach wsparcia.
Dlaczego to ważne
To podstawowy, wymagany klucz do grupowania zdarzeń w case’y na potrzeby każdej analizy process mining.
Skąd pobrać
Obiekt Zendesk Ticket, pole „id” dla typu „problem”
Przykłady
1045293849921
|
|||
|
System źródłowy
SourceSystem
|
Nazwa systemu, z którego pochodzą dane. | ||
|
Opis
Ten atrybut wskazuje platformę, z której pobrano dane o procesie. W tym przypadku jego wartością będzie zawsze „Zendesk Support”. Podczas analizy danych z wielu systemów, na przykład Zendesk i Jira, pole to pozwala filtrować lub grupować dane według źródła. Ułatwia też śledzenie pochodzenia danych w widokach procesów obejmujących wiele systemów.
Dlaczego to ważne
Pozwala śledzić pochodzenie danych i obsługuje konfiguracje process mining obejmujące wiele systemów.
Skąd pobrać
Wartość ustawiana na stałe podczas ekstrakcji danych
Przykłady
Zendesk Support
|
|||
|
Grupa wsparcia
SupportGroup
|
Zespół lub dział, do którego obecnie przypisano rekord problemu. | ||
|
Opis
Ten atrybut wskazuje konkretną grupę agentów odpowiedzialną za problem w danym momencie. Zmienia się, gdy zgłoszenie jest przekazywane między zespołami. W analizie jest niezbędny dla dashboardu Support Group Handover Analysis. Umożliwia pomiar wyników poszczególnych zespołów, wykrywanie wąskich gardeł przy przekazywaniu spraw i analizę rozkładu obciążenia zasobów.
Dlaczego to ważne
Umożliwia analizę organizacyjną i wykrywanie wąskich gardeł między działami.
Skąd pobrać
Obiekt Zendesk Ticket, pole „group_id” (zamienione na nazwę)
Przykłady
Wsparcie L2Zespół baz danychOperacje sieciowe
|
|||
|
Imię i nazwisko przypisanego agenta
AssigneeName
|
Agent przypisany do obsługi problemu. | ||
|
Opis
Ten atrybut zawiera imię i nazwisko użytkownika odpowiedzialnego obecnie za rekord problemu. Pozwala ustalić, kto wykonał poszczególne działania. W analizie pomaga zrozumieć obciążenie pracą i wyniki poszczególnych osób. Analiza na poziomie grupy jest częstsza, ale dane o przypisanych agentach mogą wskazać potrzeby szkoleniowe lub osoby szczególnie skuteczne w rozwiązywaniu złożonych problemów.
Dlaczego to ważne
Umożliwia analizę zasobów na poziomie poszczególnych osób.
Skąd pobrać
Obiekt Zendesk Ticket, pole „assignee_id” (zamienione na imię i nazwisko)
Przykłady
Jan KowalskiAnna NowakSystem
|
|||
|
Kategoria problemu
ProblemCategory
|
Klasyfikacja problemu, np. oprogramowanie, sprzęt lub sieć. | ||
|
Opis
Ten atrybut określa kategorię problemu na podstawie usługi lub stosu technologicznego, którego dotyczy. Zazwyczaj jest to niestandardowe pole wyboru w formularzach Zendesk. W analizie służy do tworzenia dashboardu „Dokładność kategoryzacji problemów”. Porównanie kategorii przypisanej na początku z ostateczną przyczyną źródłową pozwala sprawdzić, czy wstępna selekcja kieruje problemy do właściwych zespołów.
Dlaczego to ważne
Umożliwia podział danych według technologii lub usługi biznesowej.
Skąd pobrać
Niestandardowe pola zgłoszenia Zendesk
Przykłady
Baza danychInterfejs użytkownika i UXInfrastruktura sieciowa
|
|||
|
Kategoria przyczyny źródłowej
RootCauseCategory
|
Ustalona przyczyna problemu, np. błąd w kodzie lub błąd konfiguracji. | ||
|
Opis
Ten atrybut zapisuje ostateczną diagnozę przyczyny problemu. Zazwyczaj jest uzupełniany podczas czynności „Ustalono przyczynę źródłową”. W analizie służy do tworzenia raportu „Dokładność kategoryzacji problemów” oraz badania trendów awarii systemów. Pomaga kierownictwu zdecydować, czy należy skupić się na jakości kodu, stabilności infrastruktury czy zarządzaniu dostawcami.
Dlaczego to ważne
Umożliwia analizę wzorców awarii i pomaga ukierunkować długoterminowe działania usprawniające.
Skąd pobrać
Niestandardowe pola zgłoszenia Zendesk
Przykłady
Błąd oprogramowaniaBłąd konfiguracjiBłąd użytkownika
|
|||
|
Liczba powiązanych incydentów
RelatedIncidentCount
|
Liczba zgłoszeń incydentów powiązanych z tym rekordem problemu. | ||
|
Opis
Ten atrybut zlicza zgłoszenia incydentów powiązane z danym rekordem problemu. W Zendesk powiązanie jest realizowane za pomocą pola „problem_id” w zgłoszeniach incydentów. W analizie jest to główny miernik dla obszaru „Incident Correlation and Impact”. Pomaga ustalać priorytety problemów dotykających największej liczby użytkowników i podejmować decyzje o tym, które poprawki najbardziej ograniczą liczbę zgłoszeń.
Dlaczego to ważne
Wskazuje skalę problemu i jego wpływ na użytkowników.
Skąd pobrać
Zendesk Tickets API, liczba zgłoszeń, w których type='incident' i problem_id=ThisID
Przykłady
015342
|
|||
|
Priorytet
Priority
|
Poziom pilności przypisany do rekordu problemu. | ||
|
Opis
Ten atrybut określa względną ważność problemu. Zwykle przyjmuje wartość Low, Normal, High lub Urgent. Wpływa na oczekiwany poziom usług (SLA) i przydział zasobów. W analizie służy do podziału procesu na segmenty i porównywania wyników dla różnych poziomów pilności. Można na przykład sprawdzić, czy problemy o priorytecie „Urgent” są rozwiązywane szybciej niż te o priorytecie „Low”, zgodnie z wymaganiami dashboardu Root Cause Investigation Velocity.
Dlaczego to ważne
Umożliwia podział case’ów na segmenty, aby analizować zgodność z SLA i priorytetyzację zasobów.
Skąd pobrać
Obiekt Zendesk Ticket, pole „priority”
Przykłady
PilnyWysokiNormalnyNiski
|
|||
|
Status problemu
ProblemStatus
|
Bieżący stan rekordu problemu w jego cyklu życia. | ||
|
Opis
Ten atrybut pokazuje bieżący status problemu, na przykład New, Open, Pending, Solved lub Closed. Odzwierciedla postęp dochodzenia. W analizie służy do filtrowania spraw otwartych i zamkniętych. Jest niezbędny dla dashboardu Stale Problem Record Monitoring, który pomaga wykrywać aktywne sprawy, w których status nie zmienia się zgodnie z oczekiwanym przebiegiem.
Dlaczego to ważne
Umożliwia filtrowanie case’ów według stanu realizacji.
Skąd pobrać
Obiekt Zendesk Ticket, pole „status”
Przykłady
noweotwarteoczekującerozwiązanezamknięte
|
|||
|
Termin realizacji SLA
SlaDueDate
|
Docelowa data i godzina rozwiązania problemu. | ||
|
Opis
Ten atrybut określa termin rozwiązania problemu na podstawie konfiguracji umowy o poziomie usług. Zwykle jest obliczany na podstawie priorytetu i czasu utworzenia zgłoszenia. W analizie termin ten porównuje się z rzeczywistym czasem rozwiązania, aby obliczyć wskaźnik Problem SLA Adherence Rate. Dashboard SLA Performance and Risk wskazuje sprawy, których termin realizacji się zbliża lub został przekroczony.
Dlaczego to ważne
Niezbędny do pomiaru zgodności i realizacji zobowiązań umownych.
Skąd pobrać
Punkt końcowy Zendesk Ticket Metrics lub SLA Policies
Przykłady
2023-12-01T17:00:00Z
|
|||
|
Identyfikator artykułu w bazie wiedzy
KnowledgeArticleId
|
Identyfikator artykułu w bazie wiedzy utworzonego w związku z problemem lub powiązanego z nim. | ||
|
Opis
Ten atrybut przechowuje odnośnik do artykułu w Zendesk Guide lub zewnętrznego materiału z bazy wiedzy. Wskazuje, że wnioski z rozwiązania problemu zostały udokumentowane. W analizie obecność tego pola służy do obliczania wskaźnika „Poziom integracji z bazą wiedzy”. Pozwala sprawdzić, czy organizacja dokumentuje rozwiązania, aby można było z nich skorzystać w przyszłości.
Dlaczego to ważne
Pozwala ocenić skuteczność procesów zarządzania wiedzą.
Skąd pobrać
Niestandardowe pola zgłoszenia Zendesk lub powiązane treści
Przykłady
360045889KB-2991
|
|||
|
Identyfikator wniosku o zmianę
ChangeRequestId
|
Identyfikator wniosku o zmianę powiązanego z wdrożeniem poprawki. | ||
|
Opis
Ten atrybut łączy rekord problemu z rekordem zarządzania zmianą, który może znajdować się w innym systemie lub dotyczyć innego typu zgłoszenia. Oznacza to, że rozpoczęto formalny proces zmiany. W analizie wspiera dashboard „Odsetek problemów zainicjowanych wnioskami o zmianę”. Ułatwia śledzenie przejścia od diagnozy do wdrożenia i sprawdzenie, czy ustalenie przyczyny źródłowej prowadzi do formalnych działań związanych ze zmianą.
Dlaczego to ważne
Łączy proces obsługi problemów z procesem zarządzania zmianą.
Skąd pobrać
Niestandardowe pola zgłoszenia Zendesk lub powiązane zgłoszenia
Przykłady
CR-1002CHG00394
|
|||
|
Nieaktualny
IsStale
|
Flaga wskazująca, że problem nie był aktualizowany od ponad 14 dni. | ||
|
Opis
Ten obliczany atrybut wskazuje rekordy, które nie były ostatnio aktualizowane. Porównuje bieżącą datę lub datę analizy z czasem ostatniej aktywności. W analizie zasila dashboard „Monitorowanie nieaktualnych rekordów problemów”. Pomaga kierownikom szybko znaleźć zaniedbane sprawy zalegające w kolejce, które mogą wymagać zamknięcia administracyjnego lub ponownego przypisania.
Dlaczego to ważne
Pomaga wykrywać straty w procesie i zaniedbane zadania.
Skąd pobrać
Obliczane w narzędziu process mining: (Now - LastDataUpdate) > 14 dni
Przykłady
truefalse
|
|||
|
Obejście problemu aktywne
WorkaroundActive
|
Flaga wskazująca, czy udostępniono lub opublikowano obejście problemu. | ||
|
Opis
Ten atrybut logiczny wskazuje, czy udokumentowano tymczasowe rozwiązanie problemu. Jego wartość często ustala się na podstawie obecności czynności „Opublikowano obejście problemu” lub zaznaczenia odpowiedniego pola w formularzu. W analizie służy do tworzenia dashboardu „Zgodność z publikowaniem obejść problemów”. Pokazuje, jak często zespół wsparcia zapewnia użytkownikom doraźną pomoc, gdy trwa poszukiwanie rozwiązania długoterminowego.
Dlaczego to ważne
Pomaga mierzyć, w jakim stopniu podczas analizy ograniczany jest wpływ problemu na użytkowników.
Skąd pobrać
Ustalane na podstawie obecności czynności „Opublikowano obejście problemu” lub niestandardowego pola
Przykłady
truefalse
|
|||
|
Przeprowadzono PIR
HasPostImplementationReview
|
Flaga wskazująca, czy przeprowadzono przegląd po wdrożeniu. | ||
|
Opis
Ten atrybut wskazuje, czy proces rozwiązywania problemu obejmował etap przeglądu. Jego wartość ustala się na podstawie obecności czynności „Przeprowadzono przegląd po wdrożeniu” w historii sprawy. W analizie wspiera dashboard „Zakres przeglądów po wdrożeniu”. Jest to wskaźnik zgodności, który pozwala sprawdzić, czy organizacja wyciąga wnioski z poważnych problemów.
Dlaczego to ważne
Pozwala sprawdzić zgodność z procesami ciągłego doskonalenia.
Skąd pobrać
Ustalane na podstawie obecności czynności „Przeprowadzono przegląd po wdrożeniu”
Przykłady
truefalse
|
|||
|
Temat problemu
ProblemSubject
|
Krótki opis lub tytuł rekordu problemu. | ||
|
Opis
Ten atrybut zawiera opis wpisany podczas tworzenia problemu. Zwykle przedstawia objaw lub badaną usterkę. Podczas analizy zapewnia kontekst przy przeglądaniu poszczególnych case’ów. Można też zastosować analizę tekstu, aby grupować podobne problemy lub wykrywać powtarzające się tematy, których nie obejmują pola kategorii.
Dlaczego to ważne
Zapewnia czytelny dla użytkownika kontekst poszczególnych case’ów.
Skąd pobrać
Obiekt Zendesk Ticket, pole „subject”
Przykłady
Nie można przetwarzać płatności w regionie UESkoki opóźnień na serwerze logowaniaEksport danych nie działa dla użytkowników administracyjnych
|
|||
Działania w procesie zarządzania problemami
| Działanie | Opis | ||
|---|---|---|---|
|
Opublikowanie obejścia
|
Udokumentowanie i udostępnienie tymczasowego rozwiązania problemu. W Zendesk jest ono często rejestrowane za pomocą określonego tagu lub niestandardowego pola wyboru informującego o dostępności obejścia. | ||
|
Dlaczego to ważne
Wspiera dashboard Workaround Publication Compliance i pomaga zapewnić użytkownikom tymczasowe rozwiązanie podczas długotrwałego dochodzenia.
Skąd pobrać
Monitoruj dodanie tagu „workaround_published” lub zmianę niestandardowego pola logicznego o nazwie „Workaround”.
Rejestrowanie
Porównaj wartości pola niestandardowego lub tagu
Typ zdarzenia
inferred
|
|||
|
Potwierdzenie rozwiązania
|
Formalne oznaczenie problemu jako rozwiązany. W Zendesk następuje po ustawieniu standardowego statusu systemowego „Solved”, co oznacza, że poprawka została zweryfikowana, a sprawa zakończona. | ||
|
Dlaczego to ważne
Główny punkt końcowy do obliczania wyników i ryzyka SLA oraz wskaźnika Problem SLA Adherence Rate.
Skąd pobrać
Dane pochodzą ze zmiany statusu zgłoszenia na „Solved”.
Rejestrowanie
Rejestrowane po zmianie statusu na Solved
Typ zdarzenia
explicit
|
|||
|
Przypisanie do grupy wsparcia
|
Przekazanie rekordu problemu do konkretnego zespołu technicznego lub działu. Zdarzenie jest rejestrowane po aktualizacji pola Group ID w zgłoszeniu. | ||
|
Dlaczego to ważne
Niezbędne do pomiaru czasu oczekiwania między działami w dashboardzie Support Group Handover Analysis.
Skąd pobrać
Monitoruj zmiany pola „group_id” w dzienniku audytu zgłoszenia.
Rejestrowanie
Rejestrowane po wykonaniu transakcji Group Assignment Change
Typ zdarzenia
explicit
|
|||
|
Rozpoczęcie dochodzenia
|
Oznacza przejście ze stanu „New” do aktywnej pracy nad problemem. Wskazuje, że agent przyjął zgłoszenie i rozpoczął diagnozę. | ||
|
Dlaczego to ważne
Służy do obliczania wskaźników dotyczących nieaktualnych rekordów problemów i wyznacza początek pomiaru KPI Average Root Cause Analysis Duration.
Skąd pobrać
Wnioskowane na podstawie zmiany statusu zgłoszenia z „New” na „Open” lub „Pending”.
Rejestrowanie
Porównaj pole statusu przed zmianą i po niej
Typ zdarzenia
inferred
|
|||
|
Ustalenie przyczyny źródłowej
|
Moment ustalenia podstawowej przyczyny problemu. Zwykle jest rejestrowany, gdy agent wypełni niestandardowe pole tekstowe „Root Cause” lub wybierze kategorię z listy. | ||
|
Dlaczego to ważne
Ważny etap dla dashboardu Root Cause Investigation Velocity i pomiaru sprawności diagnozy.
Skąd pobrać
Monitoruj zmiany pól niestandardowych „Root Cause”, „RCA” lub „Problem Source” i sprawdzaj, czy zawierają wartość.
Rejestrowanie
Sprawdź, czy pola niestandardowe zostały wypełnione
Typ zdarzenia
inferred
|
|||
|
Wdrożenie trwałej poprawki
|
Oznacza wdrożenie rozwiązania technicznego w środowisku. Zwykle jest rejestrowane jako zmiana statusu niestandardowego lub określony tag przed pełnym rozwiązaniem zgłoszenia. | ||
|
Dlaczego to ważne
Niezbędne do pomiaru czasu od diagnozy do wdrożenia w dashboardzie Fix Implementation Efficiency.
Skąd pobrać
Zdarzenie można wywnioskować z określonego tagu, na przykład „fix_deployed”, lub z niestandardowego pola statusu, jeśli jest dostępne.
Rejestrowanie
Monitoruj tagi lub niestandardowe listy statusów
Typ zdarzenia
inferred
|
|||
|
Zamknięcie rekordu problemu
|
Końcowe zdarzenie cyklu życia, po którym zgłoszenie zostaje zablokowane i nie można go już zmienić. W Zendesk następuje to zwykle automatycznie 4 dni po ustawieniu statusu „Solved”. | ||
|
Dlaczego to ważne
Oznacza definitywny koniec cyklu życia rekordu i służy do zarządzania przechowywaniem danych oraz raportowania historycznego.
Skąd pobrać
Dane pochodzą ze zmiany statusu zgłoszenia na „Closed”.
Rejestrowanie
Rejestrowane po zmianie statusu na Closed
Typ zdarzenia
explicit
|
|||
|
Zarejestrowanie rekordu problemu
|
Utworzenie zgłoszenia problemu w Zendesk Support. To zdarzenie zapisuje znacznik czasu pierwszej rejestracji problemu w systemie i zwykle rozpoczyna instancję procesu. | ||
|
Dlaczego to ważne
Wyznacza początek cyklu rozwiązania problemu od początku do końca i stanowi punkt odniesienia dla wszystkich późniejszych pomiarów czasu realizacji.
Skąd pobrać
Dane pochodzą ze znacznika czasu „created_at” w obiekcie zgłoszenia lub z pierwszego wpisu w dzienniku audytu zgłoszenia.
Rejestrowanie
Rejestrowane po wykonaniu transakcji Ticket Created
Typ zdarzenia
explicit
|
|||
|
Ponowne otwarcie dochodzenia dotyczącego problemu
|
Zdarzenie występuje, gdy rekord problemu oznaczony wcześniej jako „Solved” wraca do statusu „Open” lub innego aktywnego stanu. Może to oznaczać, że poprawka nie zadziałała lub rozwiązanie zostało odrzucone. | ||
|
Dlaczego to ważne
Wspiera KPI Problem Re-opening Rate i pomaga wykrywać problemy z jakością procesu rozwiązywania.
Skąd pobrać
Wnioskowane na podstawie zmiany statusu z „Solved” na „Open”, „New” lub „Pending”.
Rejestrowanie
Porównaj pole statusu przed zmianą i po niej
Typ zdarzenia
inferred
|
|||
|
Przeprowadzenie przeglądu po wdrożeniu
|
Potwierdzenie, że po wdrożeniu poprawki przeprowadzono przegląd retrospektywny. Zwykle jest rejestrowane przez koordynatora procesu w polu wyboru lub polu daty. | ||
|
Dlaczego to ważne
Wymagane do obliczania KPI Post-Implementation Review Frequency i monitorowania zgodności ze standardami jakości.
Skąd pobrać
Monitoruj aktualizacje niestandardowego pola wyboru „PIR Completed” lub pola daty „PIR Date”.
Rejestrowanie
Monitoruj niestandardowe pole pod kątem zakończenia przeglądu
Typ zdarzenia
inferred
|
|||
|
Przygotowanie projektu proponowanego rozwiązania
|
Utworzenie artykułu w bazie wiedzy na podstawie dochodzenia dotyczącego problemu. Zdarzenie można wywnioskować z użycia aplikacji Zendesk Knowledge Capture lub powiązania nowego artykułu. | ||
|
Dlaczego to ważne
Wspiera KPI Knowledge Base Integration Rate i pomaga utrwalać wiedzę w organizacji.
Skąd pobrać
Monitoruj zdarzenia związane z integracją „Knowledge Capture” lub tagi takie jak „kcs_draft”.
Rejestrowanie
Wnioskuj na podstawie określonych tagów systemowych lub zdarzeń powiązania
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie obsługi wniosku o zmianę
|
Oznacza uruchomienie formalnego procesu zarządzania zmianą w celu rozwiązania problemu. Zdarzenie można zwykle wywnioskować z wypełnienia niestandardowego pola „Change Request ID” lub powiązania zgłoszenia typu „Change”. | ||
|
Dlaczego to ważne
Pozwala śledzić wskaźnik rozpoczęcia obsługi wniosków o zmianę i łączy workflow zarządzania problemami z workflow zarządzania zmianą.
Skąd pobrać
Monitoruj aktualizacje niestandardowego pola, takiego jak „change_reference”, lub utworzenie powiązania typu „problem_change”.
Rejestrowanie
Monitoruj niestandardowe pole pod kątem wpisania zewnętrznego identyfikatora
Typ zdarzenia
inferred
|
|||
Instrukcje ekstrakcji danych
Gotowi do rozpoczęcia?
Zastosuj ten szablon w środowisku Zendesk, aby poprawić stabilność usług IT. Nasz zespół może pomóc dopracować ekstrakcję danych i rozpocząć analizę process mining.
Usprawnij zarządzanie problemami, aby szybciej usuwać awarie IT
Skróć cykle rozwiązywania problemów o 30% i usuń wąskie gardła w IT.
Nie trzeba podawać danych karty. Konfiguracja zajmuje kilka minut.