Szablon danych dotyczących zarządzania zmianami

ServiceNow
Szablon danych dotyczących zarządzania zmianami

Szablon danych dotyczących zarządzania zmianami

Szablon przedstawia uporządkowany sposób gromadzenia danych potrzebnych do skutecznego process mining w workflow zarządzania zmianami. Zawiera zalecane atrybuty i działania do śledzenia oraz praktyczne wskazówki dotyczące ekstrakcji danych. Dzięki niemu można przygotować dane do szczegółowej analizy i usprawnienia procesu.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia, aby poprawnie odkryć przebieg procesu
  • Wskazówki dotyczące ekstrakcji danych z ServiceNow
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zarządzania zmianami

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby szczegółowo analizować proces zarządzania zmianami.
3 Wymagane 7 Zalecane 9 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładny znacznik czasu wystąpienia konkretnego działania lub zdarzenia.
Opis

Czas zdarzenia określa dokładną datę i godzinę wykonania działania lub zarejestrowania zmiany statusu. Znacznik czasu pozwala uporządkować zdarzenia chronologicznie i jest niezbędny do analizy czasu trwania.

W process mining ten atrybut umożliwia obliczanie czasu realizacji, czasu przetwarzania i czasu oczekiwania między działaniami. Jest niezbędny w dashboardach analizujących wyniki, takich jak „Change Approval Cycle Time” i „End-to-End Change Process Flow”. Dokładne znaczniki czasu stanowią podstawę wykrywania opóźnień i pomiaru efektywności procesu względem SLA.

Dlaczego to ważne

Ten znacznik czasu pozwala prawidłowo uporządkować zdarzenia i obliczać wszystkie miary czasowe, w tym czas realizacji, czas trwania i zgodność z SLA.

Skąd pobrać

Tabela ServiceNow: sys_audit, pole: sys_created_on. Zawiera znacznik czasu każdej zarejestrowanej zmiany.

Przykłady
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
Identyfikator wniosku o zmianę
ChangeRequestNumber
Unikalny identyfikator wniosku o zmianę, używany jako główny identyfikator sprawy do grupowania powiązanych zdarzeń.
Opis

Identyfikator wniosku o zmianę jest podstawą analizy procesu zarządzania zmianami. Każdy wniosek otrzymuje unikalny numer, na przykład „CHG0030001”, który łączy wszystkie powiązane działania, zatwierdzenia i zadania.

W process mining ten atrybut służy do odtworzenia pełnego przebiegu każdej zmiany. Analitycy mogą prześledzić jej cykl życia od utworzenia do zamknięcia i sprawdzić, jak przebiegała w systemie. Grupowanie procesów według tego identyfikatora jest niezbędne do obliczania czasu realizacji, wykrywania pętli poprawek i analizy wariantów procesu.

Dlaczego to ważne

Ten identyfikator pozwala śledzić cały cykl życia zmiany i analizować przebieg procesu, jego czas trwania oraz zgodność dla każdego wniosku.

Skąd pobrać

Tabela ServiceNow: change_request, pole: number

Przykłady
CHG0030001CHG0030045CHG0030112
Nazwa działania
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w procesie zarządzania zmianami.
Opis

Nazwa działania opisuje pojedynczy krok lub zmianę statusu w cyklu życia wniosku o zmianę. Przykłady to „Wniosek o zmianę oczekuje na ocenę”, „Wysłano prośbę o zatwierdzenie” i „Wdrożono zmianę”. Działania te tworzą węzły na mapie procesu.

Analiza działań pozwala szczegółowo zbadać przebieg procesu. Śledząc ich kolejność i częstotliwość, organizacje mogą wykrywać typowe ścieżki, odstępstwa od standardowego procesu oraz wąskie gardła, w których zmiany często się zatrzymują. To podstawa wizualizacji procesu i obliczania takich miar jak czas przejścia między krokami.

Dlaczego to ważne

Atrybut ten stanowi podstawę mapy procesu. Umożliwia przedstawienie przebiegu procesu, wykrywanie wąskich gardeł i analizę odstępstw.

Skąd pobrać

Wartość jest wyznaczana na podstawie zmian pola „state” lub innych istotnych pól statusu w tabeli „change_request”, często rejestrowanych w tabeli „sys_audit”.

Przykłady
Zatwierdzono zmianęRozpoczęto wdrożenieZamknięto zmianęAnulowano zmianę
Czas zakończenia
EndTime
Znacznik czasu zakończenia działania. Często wyznacza się go na podstawie czasu rozpoczęcia kolejnego działania.
Opis

Czas zakończenia oznacza koniec działania. Systemy źródłowe często rejestrują początek zdarzenia, dlatego czas zakończenia trzeba zwykle wyznaczyć na podstawie danych. Najczęściej przyjmuje się znacznik czasu kolejnego działania w sekwencji dla tej samej sprawy.

Atrybut ten jest niezbędny do obliczania czasu trwania każdego działania, czyli czasu przetwarzania. Wiedza o tym, ile trwa każdy krok, pomaga wykrywać wąskie gardła i nieefektywności procesu. W przypadku ostatniego działania w sprawie czas zakończenia jest taki sam jak czas rozpoczęcia.

Dlaczego to ważne

Umożliwia obliczanie czasu przetwarzania działań, co pomaga wykrywać wąskie gardła i mierzyć czas trwania poszczególnych kroków procesu.

Skąd pobrać

Atrybut ten jest zwykle obliczany podczas przekształcania danych na podstawie StartTime kolejnego zdarzenia dla tego samego CaseId.

Przykłady
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Element konfiguracji
ConfigurationItem
Konkretny komponent IT, usługa lub system, którego dotyczy zmiana.
Opis

Element konfiguracji (CI) to zasób z bazy danych zarządzania konfiguracją (CMDB), którego dotyczy zmiana. Może to być serwer, aplikacja, urządzenie sieciowe lub usługa biznesowa.

Atrybut ten dostarcza kontekstu potrzebnego do analizy zmiany. W process mining pozwala podzielić analizę według rodzaju zmienianego zasobu. Na przykład dashboard „Change Testing Duration Analysis” wykorzystuje ten atrybut do porównywania czasu testów różnych aplikacji i systemów oraz wskazywania elementów CI, z którymi wiążą się dłuższe cykle testowe.

Dlaczego to ważne

Dostarcza kontekstu biznesowego i pozwala filtrować analizę według aplikacji, usługi lub systemu, którego dotyczy zmiana, aby wykrywać problemy związane z konkretnymi komponentami.

Skąd pobrać

Tabela ServiceNow: change_request, pole: cmdb_ci

Przykłady
SAP ERPOracle Database 19cUsługa poczty e-mailWebServer-01
Grupa przypisania
AssignmentGroup
Zespół lub grupa odpowiedzialna za wniosek o zmianę.
Opis

Grupa przypisania wskazuje zespół aktualnie odpowiedzialny za wniosek o zmianę, na przykład „CAB Approval”, „Network Engineering” lub „Database Administrators”. To ważny wymiar analizy wyników procesu w różnych obszarach funkcjonalnych.

Atrybut ten służy do pomiaru efektywności zespołów, wykrywania wąskich gardeł w poszczególnych grupach i analizy przekazywania pracy między zespołami. Dashboardy takie jak „Cross-Functional Handoff Efficiency” i „Change Implementation Throughput” wykorzystują te dane do wskazywania opóźnień wynikających ze współzależności między zespołami.

Dlaczego to ważne

Umożliwia analizę wyników zespołów, wskazuje wąskie gardła w poszczególnych grupach i pozwala mierzyć sprawność przekazywania pracy między obszarami funkcjonalnymi.

Skąd pobrać

Tabela ServiceNow: change_request, pole: assignment_group

Przykłady
Zatwierdzenie przez CABZespół sieciowyWsparcie serwerówAdministratorzy baz danych
Poziom ryzyka
RiskLevel
Oceniony poziom ryzyka zmiany, na przykład „High”, „Moderate” lub „Low”.
Opis

Poziom ryzyka to wynik oceny ryzyka wniosku o zmianę. Określa potencjalne negatywne skutki wdrożenia zmiany i pomaga ustalić wymagany zakres weryfikacji oraz zatwierdzeń.

Atrybut ten jest wykorzystywany w dashboardzie „Risk Assessment Standardization” do sprawdzania, czy podobne zmiany otrzymują spójne oceny ryzyka. Analiza przebiegu procesu według poziomu ryzyka pozwala też sprawdzić, czy zmiany wysokiego ryzyka przechodzą dokładniejszy proces zatwierdzania i testowania niż zmiany niskiego ryzyka. To ważny element kontroli zgodności.

Dlaczego to ważne

Niezbędny do analizy zgodności i sprawdzenia, czy zmiany wysokiego ryzyka są odpowiednio weryfikowane i przechodzą dokładniejszy proces.

Skąd pobrać

Tabela ServiceNow: change_request, pole: risk

Przykłady
WysokieUmiarkowaneNiskie
Priorytet
Priority
Priorytet wniosku o zmianę, określany na podstawie wpływu i pilności.
Opis

Priorytet określa znaczenie wniosku o zmianę i kolejność jego obsługi. Często wynika z wpływu i pilności zmiany. Przykładowe wartości to „Critical”, „High”, „Moderate” i „Low”.

Analiza według priorytetu pozwala sprawdzić, czy zmiany o wysokim priorytecie są obsługiwane szybciej niż te o niskim. Wspiera dashboard „Critical Change Performance”, który umożliwia osobne śledzenie czasu realizacji i wskaźnika niepowodzeń najważniejszych zmian. Jeśli zmiany o niskim priorytecie są realizowane szybciej niż te o wysokim, może to wskazywać na problemy z przydziałem zasobów lub przebiegiem procesu.

Dlaczego to ważne

Pomaga ocenić, czy zasoby są właściwie przydzielane do najważniejszych zmian, i monitorować ich wyniki osobno.

Skąd pobrać

Tabela ServiceNow: change_request, pole: priority

Przykłady
1 - Krytyczny2 - Wysoki3 - Umiarkowany4 - Niski
Stan zmiany
ChangeState
Bieżący lub historyczny stan wniosku o zmianę, na przykład „Assess”, „Authorize”, „Implement” lub „Closed”.
Opis

Atrybut Stan zmiany określa status wniosku o zmianę w danym momencie. W skrócie pokazuje, na jakim etapie cyklu życia znajduje się zmiana. W odróżnieniu od działania, które oznacza konkretne zdarzenie, stan opisuje sytuację po tym zdarzeniu.

W analizie stan zmiany służy do kategoryzowania spraw i badania ich wyników. Pozwala filtrować zmiany, na przykład analizować tylko te o stanie „Closed” lub sprawdzać, dlaczego wiele z nich utknęło w stanie „Authorize”. Jeśli występuje stan „Failed”, atrybut ten pomaga też obliczać KPI „Change Failure Rate”.

Dlaczego to ważne

Pokazuje stan wniosku o zmianę, umożliwiając analizę wyników, filtrowanie spraw i wykrywanie zmian, które utknęły w procesie.

Skąd pobrać

Tabela ServiceNow: change_request, pole: state

Przykłady
OcenaAutoryzacjaZaplanowanoWdrożeniePrzeglądZamkniętoAnulowano
Typ zmiany
ChangeType
Klasyfikacja zmiany, na przykład „Standard”, „Normal” lub „Emergency”.
Opis

Typ zmiany określa kategorię wniosku na podstawie charakteru zmiany, ryzyka i wymagań dotyczących zatwierdzenia. Zmiany standardowe są zatwierdzone z góry, zmiany normalne przechodzą pełny proces, a zmiany awaryjne są obsługiwane w trybie przyspieszonym.

To podstawowy wymiar analizy procesu, ponieważ poszczególne typy zmian mają różne, uzasadnione przebiegi. Porównanie zmian normalnych i awaryjnych może ujawnić, czy proces jest przestrzegany i jak sprawnie przebiega. Atrybut ten jest też wykorzystywany w dashboardach takich jak „Risk Assessment Standardization”, aby sprawdzić, czy podobne zmiany są obsługiwane w spójny sposób.

Dlaczego to ważne

Pozwala podzielić analizę na kategorie, ponieważ różne typy zmian przebiegają zgodnie z odmiennymi zatwierdzonymi ścieżkami i mają różne oczekiwane wyniki.

Skąd pobrać

Tabela ServiceNow: change_request, pole: type

Przykłady
StandardowaNormalnaAwaryjna
Czas realizacji
CycleTime
Łączny czas od utworzenia do zamknięcia zgłoszenia zmiany.
Opis

Czas realizacji to miara na poziomie sprawy, która określa łączny czas trwania zgłoszenia zmiany. Oblicza się go jako różnicę między znacznikiem czasu pierwszego i ostatniego zdarzenia dotyczącego danego zgłoszenia.

To ważny KPI służący do pomiaru ogólnego tempa procesu. Dashboard „Przebieg procesu zarządzania zmianą od początku do końca” przedstawia go jako ogólny wskaźnik wydajności procesu. Analiza trendów czasu realizacji i porównanie wyników według różnych wymiarów, takich jak typ zmiany lub priorytet, pomaga znaleźć możliwości usprawnienia procesu.

Dlaczego to ważne

Mierzy całkowity czas realizacji procesu zarządzania zmianą i wskazuje jego ogólne tempo oraz efektywność.

Skąd pobrać

Obliczany na poziomie sprawy podczas analizy danych przez odjęcie minimalnej wartości StartTime od maksymalnej wartości StartTime dla każdego CaseId.

Przykłady
60480012096002592000
Czy ponowne wykonanie
IsRework
Wartość logiczna ustawiona na true, jeśli działanie oznacza powtórzenie wcześniejszego kroku w tej samej sprawie.
Opis

Ten obliczany atrybut wskazuje działania będące ponownym wykonaniem pracy. Dochodzi do niego, gdy proces wraca do wcześniej ukończonego kroku, na przykład gdy zmiana zostaje odrzucona po zatwierdzeniu i skierowana do ponownej oceny.

Flaga ta pozwala określić skalę nieefektywności procesu. Zasila KPI „Wskaźnik ponownego wykonania zmian” oraz dashboard „Analiza nieudanych zmian i ponownego wykonania”. Filtrowanie działań, dla których „Czy ponowne wykonanie” ma wartość true, pozwala analitykom zbadać przyczyny, takie jak niepełna wstępna ocena lub zmieniające się wymagania, i ograniczyć straty.

Dlaczego to ważne

Wskazuje powtórnie wykonaną pracę, co pozwala określić skalę nieefektywności oraz znaleźć przyczyny zapętleń procesu i niepotrzebnego nakładu pracy.

Skąd pobrać

Obliczany podczas transformacji danych przez sprawdzenie, czy dla danego CaseId wystąpiło już to samo działanie lub wcześniejsze działanie ze standardowego przebiegu.

Przykłady
truefalse
Kod zamknięcia
CloseCode
Kod określający wynik po zamknięciu zgłoszenia zmiany, na przykład „Powodzenie” lub „Niepowodzenie”.
Opis

Kod zamknięcia określa końcowy wynik zrealizowanego zgłoszenia zmiany. Zapisuje, czy zmianę wdrożono pomyślnie, czy wystąpiły problemy, czy też ją wycofano.

Ten atrybut bezpośrednio zasila KPI „Wskaźnik nieudanych zmian”. Analiza rozkładu kodów zamknięcia pozwala określić skuteczność wdrażanych zmian. Filtrowanie mapy procesu według zmian z kodem zamknięcia „Niepowodzenie” pomaga znaleźć przyczyny problemów i ujawnia powtarzające się wzorce prowadzące do niepowodzeń.

Dlaczego to ważne

Bezpośrednio mierzy wynik zmiany i dostarcza podstawowych danych do obliczenia wskaźnika nieudanych zmian oraz analizy ich przyczyn.

Skąd pobrać

Tabela ServiceNow: change_request, pole: close_code

Przykłady
PowodzeniePowodzenie z problemamiNiepowodzenie / wycofano
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego.
Opis

Ten atrybut zawiera znacznik czasu ostatniego wyodrębnienia danych. To pole metadanych pozwala ocenić aktualność analizowanych danych.

Analitycy sprawdzają za jego pomocą, czy pracują na aktualnych informacjach i kiedy dane zostały zebrane. Ma to szczególne znaczenie w operacyjnych dashboardach monitorujących bieżące wyniki procesu, aby decyzje nie opierały się na nieaktualnych danych.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu analizy i dashboardy mogą opierać się na bieżących, istotnych informacjach.

Skąd pobrać

To pole metadanych generowane podczas wyodrębniania i przekształcania danych (ETL), które wskazuje czas pobrania danych.

Przykłady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Pilność
Urgency
Szybkość, z jaką należy rozwiązać zmianę, określana na przykład jako wysoka, średnia lub niska.
Opis

Pilność określa, jak szybko należy wdrożyć zmianę. Odzwierciedla znaczenie czasu z perspektywy biznesowej. Wraz z wpływem służy do obliczenia ogólnego priorytetu.

Priorytet jest podstawowym polem analizy, a pilność dostarcza dodatkowego kontekstu. Można ją wykorzystać, aby sprawdzić, dlaczego niektóre zmiany oznaczono jako pilne i czy proces obsługuje je skutecznie, nie obniżając stabilności. Pomaga też ocenić, czy organizacja zbyt często działa reaktywnie i pod presją czasu.

Dlaczego to ważne

Pokazuje, jak ważny jest czas realizacji zmiany, i ułatwia ocenę, czy proces skutecznie obsługuje pilne zgłoszenia.

Skąd pobrać

Tabela ServiceNow: change_request, pole: urgency

Przykłady
1 - Wysoki2 - Średni3 - Niski
Przypisany użytkownik
AssignedToUser
Użytkownik odpowiedzialny za wniosek o zmianę w danym momencie.
Opis

Ten atrybut wskazuje osobę przypisaną do pracy nad wnioskiem o zmianę. W trakcie cyklu życia wniosku przypisanie może się zmieniać, gdy przechodzi on między etapami i zespołami.

Analiza według użytkownika pomaga zrozumieć rozkład obciążenia pracą, wyniki poszczególnych osób i potrzeby szkoleniowe. Ułatwia też analizę przekazywania pracy, zwłaszcza w połączeniu z grupą przypisania, dzięki czemu można sprawdzić, jak sprawnie zadania przechodzą między osobami.

Dlaczego to ważne

Pomaga śledzić obciążenie pracą i wyniki poszczególnych użytkowników oraz analizować opóźnienia przy przekazywaniu pracy między zasobami.

Skąd pobrać

Tabela ServiceNow: change_request, pole: assigned_to

Przykłady
Beth AnglinDavid LooAbel Tuter
Stan SLA
SlaState
Status zgłoszenia zmiany w odniesieniu do umowy SLA, na przykład „Zgodnie z planem”, „Zagrożone” lub „Przekroczone”.
Opis

Stan SLA pokazuje, czy zgłoszenie zmiany jest realizowane w terminach określonych w umowie SLA. Status można śledzić na każdym etapie procesu.

Atrybut ten służy do monitorowania zgodności z zobowiązaniami dotyczącymi poziomu usług. Jest głównym źródłem danych dla dashboardu „Przegląd realizacji SLA dla zmian” oraz KPI „Wskaźnik dotrzymania SLA dla zmian”. Analiza miejsc i przyczyn przekroczeń SLA pozwala ograniczyć opóźnienia systemowe i zwiększyć przewidywalność świadczenia usług.

Dlaczego to ważne

Bezpośrednio pokazuje realizację terminów i umożliwia proaktywne monitorowanie oraz analizę przekroczeń SLA, aby usprawnić świadczenie usług.

Skąd pobrać

Dane można pobrać z tabeli „task_sla” w ServiceNow, która zawiera informacje o SLA powiązanych z zadaniami, takimi jak zgłoszenia zmian. Stan SLA można też obliczyć na podstawie pól z terminami.

Przykłady
Zgodnie z planemZagrożonePrzekroczone
System źródłowy
SourceSystem
System, z którego wyodrębniono dane, zwykle „ServiceNow”.
Opis

Ten atrybut wskazuje źródło danych o procesie. W tym przypadku oczekiwaną wartością jest ServiceNow, ale pole to ma znaczenie dla zarządzania danymi oraz łączenia danych z wielu systemów.

W analizie pozwala ustalić pochodzenie danych i zweryfikować ich źródło. Organizacje korzystające z kilku narzędzi ITSM lub zintegrowanych systemów mogą filtrować i porównywać procesy z różnych platform.

Dlaczego to ważne

Pozwala jednoznacznie ustalić i udokumentować pochodzenie danych o procesie, co ma znaczenie dla zarządzania danymi i analizy obejmującej wiele systemów.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas wyodrębniania i przekształcania danych (ETL).

Przykłady
ServiceNowServiceNow_PRODSNOW_ITSM
Wpływ
Impact
Potencjalny wpływ zmiany na operacje biznesowe, oceniany na przykład jako wysoki, średni lub niski.
Opis

Wpływ określa potencjalne skutki dla firmy, jeśli wniosek o zmianę nie zostanie prawidłowo obsłużony. Wraz z pilnością jest jednym z czynników określających priorytet zmiany.

Analiza według wpływu pomaga zadbać o właściwą obsługę zmian dotyczących usług krytycznych. Dashboard „Critical Change Performance” wykorzystuje ten atrybut do wyodrębniania i monitorowania zmian o dużym wpływie na działalność. Służy on również do sprawdzania spójności oceny ryzyka, na przykład czy zmianom o dużym wpływie nie przypisano bez uzasadnienia niskiego poziomu ryzyka.

Dlaczego to ważne

Pomaga ustalać priorytety zmian na podstawie ich potencjalnego wpływu na działalność i sprawdzać, czy zmiany o dużym wpływie są obsługiwane z należytą starannością.

Skąd pobrać

Tabela ServiceNow: change_request, pole: impact

Przykłady
1 - Wysoki2 - Średni3 - Niski
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania zmianami

To najważniejsze kroki i etapy procesu, które warto zapisać w dzienniku zdarzeń, aby poprawnie odkryć przebieg zarządzania zmianami.
7 Zalecane 6 Opcjonalne
Działanie Opis
Anulowano zmianę
Wniosek o zmianę został wycofany lub anulowany przed zakończeniem wdrożenia. To alternatywny stan końcowy, rejestrowany, gdy pole state przyjmuje wartość „Canceled”.
Dlaczego to ważne

Analiza anulowanych zmian może ujawnić nieefektywności procesu, na przykład niepotrzebnie składane wnioski lub wnioski zbyt długo oczekujące na zatwierdzenie, które zdążyły się zdezaktualizować.

Skąd pobrać

Zdarzenie jest rozpoznawane, gdy pole „state” w tabeli change_request przyjmuje wartość „Canceled”. Znacznik czasu pochodzi z dziennika audytu tej zmiany stanu.

Rejestrowanie

Zapisz znacznik czasu, gdy pole „state” zmienia się na „Canceled”.

Typ zdarzenia inferred
Oceniono ryzyko i wpływ
Oznacza zakończenie analizy ryzyka i wpływu wniosku o zmianę. To ważny etap przed uzyskaniem zgody. Zdarzenie często rozpoznaje się, gdy stan zmienia się z „Assess” na „Authorize” lub „Awaiting Approval”.
Dlaczego to ważne

Pomiar czasu trwania oceny jest niezbędny do obliczenia KPI „Avg. Risk Assessment Cycle Time”. Pozwala ujednolicić proces oceny i wskazać, które analizy trwają zbyt długo.

Skąd pobrać

Zdarzenie jest rozpoznawane po zmianie pola „state” w tabeli change_request z „Assess” na „Authorize”. Znacznik czasu pochodzi z dziennika audytu tej zmiany stanu.

Rejestrowanie

Wykryj zmianę pola „state” z „Assess” na kolejny stan, na przykład „Authorize”.

Typ zdarzenia inferred
Utworzono wniosek o zmianę
To zdarzenie oznacza utworzenie w systemie nowego rekordu wniosku o zmianę. Rozpoczyna ono oficjalnie proces zarządzania zmianami i jest rejestrowane po dodaniu wpisu do tabeli change_request.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Analiza czasu od tego zdarzenia do kolejnych pozwala ustalić całkowity czas realizacji i wykryć opóźnienia na samym początku procesu.

Skąd pobrać

Zdarzenie odpowiada znacznikowi czasu utworzenia rekordu (sys_created_on) w tabeli ServiceNow change_request.

Rejestrowanie

Użyj znacznika czasu sys_created_on z tabeli change_request.

Typ zdarzenia explicit
Wdrożono zmianę
Prace wdrożeniowe zostały zakończone. Zmiana jest gotowa do przeglądu, weryfikacji lub testów. Zdarzenie rozpoznaje się, gdy stan wniosku zmienia się z „Implement” na „Review”.
Dlaczego to ważne

To ważny etap kończący wdrożenie. Jest potrzebny do obliczenia KPI „Change Failure Rate” i „Change Rework Rate”.

Skąd pobrać

Zdarzenie jest rozpoznawane po zmianie stanu z „Implement” na kolejny stan, na przykład „Review”. Znacznik czasu pochodzi z historii audytu pola „state” w tabeli change_request.

Rejestrowanie

Wykryj zmianę pola „state” z „Implement” na „Review”.

Typ zdarzenia inferred
Zamknięto zmianę
Wniosek o zmianę został pomyślnie zrealizowany i sprawdzony, a proces uznaje się za zakończony. To główny punkt końcowy procesu, rejestrowany po zmianie stanu na „Closed”.
Dlaczego to ważne

To zdarzenie oznacza pomyślne zakończenie cyklu życia zmiany. Jest punktem końcowym przy pomiarze całkowitego czasu realizacji procesu i zgodności z SLA.

Skąd pobrać

Zdarzenie jest rozpoznawane, gdy pole „state” w tabeli change_request przyjmuje wartość „Closed”. Znacznik czasu pochodzi z historii audytu tej końcowej zmiany stanu.

Rejestrowanie

Zapisz znacznik czasu, gdy pole „state” zmienia się na „Closed”.

Typ zdarzenia inferred
Zaplanowano zmianę
Zatwierdzona zmiana ma wyznaczone planowane daty rozpoczęcia i zakończenia, a jej wdrożenie zostało wpisane do kalendarza. Zdarzenie rozpoznaje się po zmianie stanu wniosku na „Scheduled”.
Dlaczego to ważne

To zdarzenie oddziela etapy planowania i zatwierdzania od aktywnego wdrożenia. Czas spędzony w tym stanie może wskazywać na opóźnienie między zatwierdzeniem a rozpoczęciem prac.

Skąd pobrać

Zdarzenie jest rozpoznawane po zmianie pola „state” w tabeli change_request na „Scheduled”. Znacznik czasu pochodzi z odpowiadającego jej wpisu w dzienniku audytu.

Rejestrowanie

Śledź w historii audytu tabeli change_request zmiany pola state na „Scheduled”.

Typ zdarzenia inferred
Zatwierdzono zmianę
Wniosek o zmianę uzyskał wszystkie wymagane zgody i może przejść do planowania oraz wdrożenia. To ważny etap, rejestrowany po udzieleniu ostatniej zgody i ustawieniu pola „approval” na „approved”.
Dlaczego to ważne

Ten etap kończy proces zatwierdzania. Jest niezbędny do pomiaru czasu zatwierdzania i wykrywania wąskich gardeł w podejmowaniu decyzji.

Skąd pobrać

Zdarzenie jest rozpoznawane po zmianie pola „approval” w tabeli change_request na „approved”. Znacznik czasu pochodzi z historii audytu tej zmiany.

Rejestrowanie

Zapisz znacznik czasu, gdy pole „approval” przyjmuje wartość „approved”.

Typ zdarzenia inferred
Odrzucono zmianę
Osoba zatwierdzająca lub CAB odrzuciła wniosek o zmianę. Jest to stan końcowy wniosku, chyba że zostanie on poprawiony i złożony ponownie. Zdarzenie jest rejestrowane, gdy pole „approval” przyjmuje wartość „rejected”.
Dlaczego to ważne

Śledzenie odrzuceń pomaga wykrywać ich częste przyczyny, takie jak niekompletne informacje lub wysokie ryzyko. Analiza może poprawić jakość kolejnych wniosków o zmianę.

Skąd pobrać

Zdarzenie jest rozpoznawane po zmianie pola „approval” w tabeli change_request na „rejected”. Znacznik czasu pochodzi z historii audytu.

Rejestrowanie

Zapisz znacznik czasu, gdy pole „approval” przyjmuje wartość „rejected”.

Typ zdarzenia inferred
Ponownie otwarto zmianę
Po przejściu do późniejszego etapu wniosek o zmianę wrócił do wcześniejszego stanu, na przykład „Implement” lub „Assess”. Zdarzenie rozpoznaje się po nieliniowej zmianie stanu i oznacza konieczność ponownego wykonania prac.
Dlaczego to ważne

To zdarzenie pomaga wykrywać pętle poprawek i obliczać KPI „Change Rework Rate”. Częste ponowne otwieranie wniosków może wskazywać na problemy z jakością wdrożenia, testami lub planowaniem.

Skąd pobrać

Zdarzenie jest rozpoznawane na podstawie sekwencji zmian stanu w historii audytu change_request. Przejście z późniejszego stanu, na przykład „Review”, do wcześniejszego, na przykład „Implement”, oznacza ponowne otwarcie.

Rejestrowanie

Wykryj nieliniową zmianę pola „state” polegającą na powrocie do wcześniejszego stanu.

Typ zdarzenia inferred
Rozpoczęto wdrożenie
Rozpoczęły się prace nad wdrożeniem zmiany. Zdarzenie jest rejestrowane, gdy stan wniosku o zmianę zmienia się na „Implement”, co oznacza przejście od planowania do realizacji.
Dlaczego to ważne

To początek prac wdrożeniowych. Od tego momentu mierzy się KPI „Average Implementation Duration” i analizuje efektywność zespołu.

Skąd pobrać

Zdarzenie jest rozpoznawane po zmianie pola „state” w tabeli change_request na „Implement”. Znacznik czasu pochodzi z dziennika audytu tej zmiany stanu.

Rejestrowanie

Zapisz znacznik czasu zmiany stanu na „Implement” z historii audytu change_request.

Typ zdarzenia inferred
Trwa przegląd
Trwa przegląd po wdrożeniu (PIR), który ma ustalić, czy zmiana zakończyła się powodzeniem i spełniła założone cele. Zdarzenie jest rejestrowane, gdy stan wniosku o zmianę przyjmuje wartość „Review”.
Dlaczego to ważne

Analiza czasu trwania przeglądu pomaga wykrywać opóźnienia w weryfikacji efektów zmiany. Ujawnia też przypadki niezgodne z procedurą, w których pominięto ten etap.

Skąd pobrać

Zdarzenie jest rozpoznawane po zmianie pola „state” w tabeli change_request na „Review”. Znacznik czasu pochodzi z dziennika audytu tej zmiany stanu.

Rejestrowanie

Zapisz znacznik czasu zmiany stanu na „Review” z historii audytu change_request.

Typ zdarzenia inferred
Wniosek o zmianę oczekuje na ocenę
Wniosek o zmianę został złożony i oczekuje na ocenę techniczną oraz biznesową. Zwykle zdarzenie to rozpoznaje się po zmianie stanu wniosku na „Assess” lub podobny, co oznacza, że wniosek nie jest już wersją roboczą.
Dlaczego to ważne

To zdarzenie pozwala zmierzyć czas przekazania wniosku od osoby zgłaszającej do zespołu oceniającego. Opóźnienia na tym etapie mogą wskazywać na problemy z jakością danych we wniosku lub dostępnością zasobów do jego oceny.

Skąd pobrać

Zdarzenie jest rozpoznawane na podstawie zmiany pola „state” w tabeli change_request, zwykle na wartość „Assess”. Znacznik czasu pochodzi z historii audytu (sys_audit) tej zmiany pola.

Rejestrowanie

Śledź w historii audytu tabeli change_request zmiany pola state na „Assess”.

Typ zdarzenia inferred
Wysłano prośbę o zatwierdzenie
To zdarzenie oznacza formalne przekazanie wniosku o zmianę do zatwierdzenia, zwykle przez kierownika lub Change Advisory Board (CAB). Jest rejestrowane, gdy status zatwierdzenia wniosku zmienia się na „requested”.
Dlaczego to ważne

To początek cyklu zatwierdzania. Pomiar czasu od tego zdarzenia do „Change Approved” pozwala bezpośrednio obliczyć KPI „Average Change Approval Time”.

Skąd pobrać

Zdarzenie jest rozpoznawane po zmianie pola „approval” w tabeli change_request na „requested”. Znacznik czasu tej zmiany pola pochodzi z tabeli sys_audit.

Rejestrowanie

Znacznik czasu chwili, w której pole „approval” w tabeli change_request przyjmuje wartość „requested”.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z ServiceNow

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby przygotować dane i uzyskać wgląd w proces zarządzania zmianami w ServiceNow. Zacznij usprawniać proces już dziś.

Ogranicz nieudane zmiany i popraw wyniki ServiceNow!

Z łatwością wskaż wąskie gardła i osiągnij 95% skuteczności zmian.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.