Szablon danych dotyczących zarządzania zmianami
Szablon danych dotyczących zarządzania zmianami
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia, aby poprawnie odkryć przebieg procesu
- Wskazówki dotyczące ekstrakcji danych z ServiceNow
Atrybuty zarządzania zmianami
| 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
|
|||
Działania w procesie zarządzania zmianami
| 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
|
|||
Instrukcje ekstrakcji danych
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.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.