Szablon danych do zarządzania zmianami

Ivanti Cherwell
Szablon danych do zarządzania zmianami

Szablon danych do zarządzania zmianami

Szablon wskazuje, jakie dane zebrać do analizy procesu zarządzania zmianami. Zawiera listę zalecanych atrybutów i aktywności oraz instrukcje wyodrębniania tych informacji z systemu źródłowego. Można go wykorzystać do przygotowania dziennika zdarzeń na potrzeby process mining.
  • Zalecane atrybuty do zebrania
  • Najważniejsze aktywności do śledzenia
  • Instrukcja ekstrakcji danych z Ivanti Cherwell
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 analizować zarządzanie zmianami i odkrywać przebieg procesu.
5 Wymagane 6 Zalecane 8 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Znacznik czasu wskazujący, kiedy wystąpiła konkretna czynność lub zdarzenie dotyczące zgłoszenia zmiany.
Opis

Czas zdarzenia, nazywany też znacznikiem czasu, określa dokładną datę i godzinę wykonania czynności. Te dane czasowe pozwalają uporządkować zdarzenia chronologicznie i stanowią podstawę analiz process mining opartych na czasie.

Atrybut ten służy do obliczania czasu między czynnościami, mierzenia całkowitego czasu realizacji sprawy oraz wykrywania oczekiwania i opóźnień. Jest niezbędny do tworzenia dashboardów, które pokazują wyniki względem celów czasowych, takich jak „Change Approval Cycle Time”.

Dlaczego to ważne

Ten znacznik czasu stanowi podstawę analizy wyników i czasu trwania. Pozwala obliczać czas realizacji, wykrywać wąskie gardła i monitorować SLA.

Skąd pobrać

Zwykle znajduje się w dziennikach zmian statusu, ścieżkach audytu lub znacznikach czasu wpisów w dzienniku powiązanych z obiektem Change Request w Ivanti Cherwell.

Przykłady
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Identyfikator zgłoszenia zmiany
ChangeRequestId
Unikalny identyfikator pojedynczego zgłoszenia zmiany, który łączy wszystkie powiązane czynności od rozpoczęcia do zamknięcia.
Opis

Identyfikator zgłoszenia zmiany (Change Request ID) to klucz główny, który jednoznacznie identyfikuje każdą zmianę przez cały jej cykl życia. W process mining pełni funkcję identyfikatora sprawy. Łączy wszystkie zdarzenia, takie jak zgłoszenie, ocena, zatwierdzenie i wdrożenie, w jeden spójny przebieg procesu.

Analiza danych według identyfikatora zgłoszenia zmiany pozwala uzyskać pełny obraz procesu zarządzania zmianą od początku do końca. Umożliwia śledzenie poszczególnych zmian, obliczanie całkowitego czasu realizacji oraz wykrywanie odstępstw i wąskich gardeł dotyczących konkretnych zgłoszeń.

Dlaczego to ważne

To podstawowy identyfikator sprawy, który łączy powiązane zdarzenia. Dzięki niemu można prześledzić cały przebieg zgłoszenia zmiany i analizować jego realizację.

Skąd pobrać

Zwykle jest to główny identyfikator obiektu biznesowego Change Request w Ivanti Cherwell.

Przykłady
CR-105421CR-105422CR-105423
Nazwa czynności
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w danym momencie procesu zarządzania zmianą.
Opis

Nazwa czynności opisuje konkretny etap lub kamień milowy w cyklu życia zgłoszenia zmiany, na przykład „Change Submitted For Assessment” lub „Change Approved by CAB”. Czynności te tworzą węzły na odkrytej mapie procesu.

W analizie ten atrybut służy do wizualizacji przebiegu procesu, ustalania kolejności zdarzeń i wykrywania odstępstw od standardowej procedury. Pozwala obliczać czas przejścia między czynnościami i sprawdzać, gdzie występują opóźnienia.

Dlaczego to ważne

Ten atrybut pozwala odkryć i zwizualizować rzeczywisty przebieg procesu oraz wykryć wąskie gardła, pętle poprawek i ścieżki niezgodne z procedurą.

Skąd pobrać

Dane pochodzą ze zmian statusu, wpisów w dzienniku lub dzienników zdarzeń powiązanych z obiektem Change Request w Ivanti Cherwell.

Przykłady
Przekazano zmianę do ocenyZmiana oczekuje na zatwierdzenieZmiana wdrożona
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio pobrane z systemu źródłowego lub odświeżone.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z Ivanti Cherwell. Nie opisuje zdarzenia w samym procesie, lecz informuje o aktualności danych.

Dzięki niemu osoby korzystające z dashboardu wiedzą, jak aktualna jest analiza. Ułatwia planowanie odświeżania danych i pozwala podejmować decyzje na podstawie danych o znanym wieku.

Dlaczego to ważne

Informuje o aktualności danych. Dzięki temu użytkownicy mogą ocenić wiarygodność analizy i jej przydatność do oceny bieżącego stanu operacji.

Skąd pobrać

Ten znacznik czasu jest generowany i zapisywany w każdym rekordzie podczas procesu pobierania, przekształcania i ładowania danych (ETL).

Przykłady
2024-05-21T02:00:00Z
System źródłowy
SourceSystem
System, z którego pobrano dane. W tym widoku jest to „Ivanti Cherwell”.
Opis

Ten atrybut wskazuje system źródłowy danych o zdarzeniach. W środowiskach korzystających z wielu systemów pomaga rozróżnić dane z poszczególnych źródeł. W tym modelu danych ma stałą wartość wskazującą, że dane pochodzą z Ivanti Cherwell.

W modelu z jednym źródłem może wydawać się niezmienny, ale ma znaczenie dla nadzoru nad danymi, ich identyfikowalności i przyszłych integracji z innymi systemami. Pozwala ustalić pochodzenie danych i wspiera zarządzanie ich jakością.

Dlaczego to ważne

Dostarcza informacji o pochodzeniu danych, co ma znaczenie dla nadzoru nad danymi, rozwiązywania problemów i zapewnienia ich identyfikowalności.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas pobierania i przekształcania danych, aby oznaczyć ich źródło.

Przykłady
Ivanti Cherwell
Osoba odpowiedzialna za zmianę
ChangeOwner
Użytkownik lub osoba aktualnie odpowiedzialna za zgłoszenie zmiany.
Opis

Osoba odpowiedzialna za zmianę (Change Owner) to osoba przypisana do zgłoszenia i odpowiadająca za nie na danym etapie. W miarę przechodzenia zgłoszenia przez kolejne etapy odpowiedzialność może przechodzić na inne osoby.

Analiza tego atrybutu pomaga ocenić obciążenie pracą i wykrywać wąskie gardła związane z konkretnymi osobami. Ułatwia też analizę przekazywania odpowiedzialności, które może powodować znaczne opóźnienia. Atrybut ten wspiera analizę „Change Handoff & Resource Utilization” w dashboardzie.

Dlaczego to ważne

Pozwala śledzić odpowiedzialność poszczególnych osób oraz analizować rozkład obciążenia, częstotliwość przekazywania spraw i wąskie gardła związane z konkretnymi zasobami.

Skąd pobrać

Zwykle odpowiada polu „Owned By” lub „Assigned To” w obiekcie biznesowym Change Request.

Przykłady
Alice JohnsonBob WilliamsCharlie Brown
Planowana data zakończenia
TargetCompletionDate
Planowany lub uzgodniony termin zakończenia wdrożenia zmiany.
Opis

Planowana data zakończenia to termin, do którego zmiana powinna zostać w pełni wdrożona i zweryfikowana. Często jest określona w umowie o gwarantowanym poziomie świadczenia usług (SLA) i stanowi podstawę oceny wyników.

Atrybut ten służy do monitorowania terminowości i dotrzymywania terminów. Porównuje się go z faktyczną datą zakończenia, aby obliczyć KPI „On-Time Change Completion Rate” i „Change SLA Adherence Rate”. Pozwala też wcześniej wykryć zmiany zagrożone opóźnieniem.

Dlaczego to ważne

Stanowi punkt odniesienia przy pomiarze terminowości i zgodności z SLA, czyli ważnych wskaźników sprawności i niezawodności procesu.

Skąd pobrać

Zwykle jest to pole daty w obiekcie Change Request, oznaczone na przykład „Target Date”, „Due Date” lub „SLA Target”.

Przykłady
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
Poziom ryzyka zmiany
ChangeRiskLevel
Oszacowany poziom ryzyka związanego ze zmianą, na przykład „Low”, „Medium” lub „High”.
Opis

Poziom ryzyka zmiany to klasyfikacja przypisywana podczas oceny, która określa potencjalne negatywne skutki zmiany. Wynik oceny często wpływa na proces zatwierdzania i wymagany zakres kontroli.

W process mining atrybut ten służy do analizy spójności ocen ryzyka i zależności między ryzykiem a przebiegiem procesu. Można na przykład sprawdzić, czy zmiany wysokiego ryzyka przechodzą dokładniejszą ścieżkę zatwierdzania lub wymagają dłuższego wdrożenia. Atrybut ten wspiera dashboard „Change Risk Assessment Consistency”.

Dlaczego to ważne

Pozwala analizować wpływ ryzyka na przebieg procesu, cykle zatwierdzania i odsetek pomyślnie zakończonych zmian. Pomaga też sprawdzić, czy zmiany wysokiego ryzyka są odpowiednio kontrolowane.

Skąd pobrać

Wartość ta jest zapisywana w polu „Risk Level” lub podobnym polu obiektu Change Request, zwykle podczas oceny ryzyka.

Przykłady
NiskieŚrednieWysokieKrytyczne
Status zmiany
ChangeStatus
Bieżący lub końcowy status zgłoszenia zmiany, na przykład „Closed”, „Rejected” lub „In Progress”.
Opis

Status zmiany określa stan zgłoszenia w danym momencie lub jego końcowy wynik. To ważny atrybut, który pomaga zrozumieć sposób zakończenia sprawy i wykrywać wyjątki.

W analizie procesu atrybut ten służy do filtrowania wyników, na przykład do analizy wyłącznie zmian odrzuconych lub anulowanych. Jest wykorzystywany w KPI, takich jak „Change Request Rejection Rate”, i pomaga ocenić ogólną kondycję oraz sprawność procesu zarządzania zmianą.

Dlaczego to ważne

Określa wynik zgłoszenia zmiany i umożliwia analizę odsetka odrzuceń, odsetka zakończonych spraw oraz udziału spraw otwartych i zamkniętych.

Skąd pobrać

Odpowiada polu „Status” obiektu biznesowego Change Request w Ivanti Cherwell.

Przykłady
ZatwierdzonoOdrzuconoZamkniętoAnulowanoOczekiwanie na zatwierdzenie
Typ zmiany
ChangeType
Klasyfikacja zmiany, na przykład „Standard”, „Normal” lub „Emergency”.
Opis

Typ zmiany określa kategorię zgłoszenia na podstawie charakteru, pilności i wpływu zmiany. Typowe kategorie to Standard (wstępnie zatwierdzona zmiana o niskim ryzyku), Normal (wymaga pełnej oceny i zatwierdzenia) oraz Emergency (wymaga natychmiastowego wdrożenia).

Ten atrybut pozwala porównywać wyniki procesu w poszczególnych kategoriach. Można na przykład sprawdzić, czy zmiany awaryjne przebiegają inną, szybszą ścieżką albo czy zmiany standardowe rzeczywiście są realizowane bez zbędnych utrudnień. Atrybut ten jest wykorzystywany w dashboardzie „Problematic Change Type Performance”.

Dlaczego to ważne

Podział procesu według typu zmiany pozwala porównywać wyniki i sprawdzać, czy konkretne kategorie, na przykład „Emergency”, powodują wąskie gardła lub odstępstwa.

Skąd pobrać

Odpowiada polu klasyfikacji, prawdopodobnie „Change Type” lub „Category”, w obiekcie biznesowym Change Request.

Przykłady
StandardowaZwykłaAwaryjna
Zespół odpowiedzialny za zmianę
ChangeTeam
Zespół lub grupa aktualnie odpowiedzialna za zgłoszenie zmiany.
Opis

Zespół odpowiedzialny za zmianę (Change Team) to grupa lub dział przypisany do zgłoszenia. Podobnie jak w przypadku osoby odpowiedzialnej, zespół może się zmieniać w trakcie procesu. Oznacza to przekazanie odpowiedzialności między zespołami, na przykład z service desku do zespołu inżynierii sieciowej.

Ten atrybut pomaga analizować przekazywanie spraw między zespołami i wykrywać opóźnienia systemowe powodowane przez konkretne grupy. Ułatwia ustalenie, które zespoły są przeciążone i gdzie dochodzi do problemów z komunikacją. Wspiera analizę „Change Handoff & Resource Utilization”.

Dlaczego to ważne

Wskazuje odpowiedzialność zespołów, co pozwala analizować wąskie gardła procesu, mierzyć wyniki zespołów i ustalać przyczyny opóźnień przy przekazywaniu spraw między grupami.

Skąd pobrać

Informacje te są zwykle zapisane w polu „Owned By Team” lub podobnym polu przypisania grupy w obiekcie Change Request.

Przykłady
Operacje siecioweAdministracja bazami danychWsparcie aplikacji
Czas realizacji wdrożenia zmiany
ImplementationCycleTime
Obliczany czas od rozpoczęcia wdrożenia zmiany do jego zakończenia.
Opis

Ta miara określa czas trwania etapu wdrożenia zmiany. Jest obliczana jako czas między aktywnościami „Rozpoczęto wdrożenie zmiany” i „Wdrożono zmianę”.

Atrybut służy do obliczania KPI „Średni czas wdrożenia zmiany” i zasila dashboard „Przebieg wdrożenia zmiany i opóźnienia”. Pozwala odróżnić opóźnienia w planowaniu od opóźnień w realizacji, dzięki czemu zespoły mogą skupić działania usprawniające na samym wdrożeniu technicznym.

Dlaczego to ważne

Pozwala ocenić sam etap wdrożenia i oddzielić problemy techniczne lub braki zasobów od opóźnień w zatwierdzaniu.

Skąd pobrać

Obliczany w narzędziu process mining lub podczas transformacji danych przez wyznaczenie różnicy między znacznikami czasu rozpoczęcia i zakończenia wdrożenia.

Przykłady
4 godziny 15 minut1 dzień 2 godziny30 minut
Czy zakończono na czas
IsOnTimeCompletion
Obliczana flaga przyjmuje wartość true, jeśli zmianę zakończono w terminie lub przed datą docelową.
Opis

To atrybut logiczny wyliczany przez porównanie wartości „ActualCompletionDate” z „TargetCompletionDate”. Ułatwia analizę, ponieważ jasno wskazuje, czy każde zgłoszenie zmiany zrealizowano w terminie.

Flaga służy do obliczania KPI „Odsetek zmian zakończonych w terminie”. Można jej użyć jako filtra w dashboardach, aby wyodrębnić i przeanalizować opóźnione zmiany oraz znaleźć ich częste przyczyny.

Dlaczego to ważne

Ułatwia analizę wyników, jasno pokazując, czy dotrzymano terminu. Na tej podstawie obliczane są KPI dotyczące terminowego zakończenia.

Skąd pobrać

Tego atrybutu nie ma w systemie źródłowym. Jest obliczany podczas transformacji danych przez porównanie „ActualCompletionDate” <= „TargetCompletionDate”.

Przykłady
truefalse
Faktyczna data zakończenia
ActualCompletionDate
Znacznik czasu wskazujący, kiedy zmiana została faktycznie wdrożona i zweryfikowana jako zakończona.
Opis

Faktyczna data zakończenia wskazuje moment zakończenia prac wdrożeniowych dotyczących zgłoszenia zmiany. To ważny kamień milowy, który porównuje się z planowanym terminem, aby ocenić wyniki.

Atrybut ten jest używany razem z planowaną datą zakończenia do ustalenia, czy zmianę wdrożono na czas. Stanowi podstawę do obliczania KPI, takich jak „On-Time Change Completion Rate”, oraz analizy przyczyn opóźnień na etapie wdrożenia.

Dlaczego to ważne

Zapisuje faktyczny czas zakończenia, potrzebny do obliczenia odsetka zmian wdrożonych na czas i analizy skali opóźnień.

Skąd pobrać

Datę tę często zapisuje się, gdy status zgłoszenia zmienia się na „Implemented” lub „Completed”. Może być przechowywana w osobnym polu albo ustalana na podstawie znacznika czasu zmiany statusu.

Przykłady
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
Jednostka biznesowa
BusinessUnit
Jednostka biznesowa lub dział, który zgłosił zmianę albo odniesie z niej korzyści.
Opis

Ten atrybut łączy zgłoszenie zmiany z konkretną częścią organizacji, na przykład działem finansów, marketingu lub operacji. Dzięki temu techniczny proces zyskuje kontekst biznesowy.

Analiza według jednostki biznesowej pokazuje, skąd pochodzi zapotrzebowanie na zmiany. Może wspierać modele rozliczeń wewnętrznych, ocenę wpływu zmian IT na różne obszary działalności oraz wykrywanie jednostek, w których zmiany są bardziej złożone lub częściej się opóźniają.

Dlaczego to ważne

Zapewnia kontekst biznesowy i pozwala analizować zapotrzebowanie na zmiany, ich wpływ oraz wyniki z perspektywy organizacji.

Skąd pobrać

Informacja ta może znajdować się w obiekcie Change Request lub pochodzić z profilu użytkownika zgłaszającego.

Przykłady
FinanseZasoby ludzkieSprzedaż i marketingOperacje
Osoba zgłaszająca zmianę
ChangeSubmitter
Użytkownik, który utworzył lub przesłał zgłoszenie zmiany.
Opis

Ten atrybut wskazuje osobę, która rozpoczęła proces zgłaszając zmianę. Może to być inna osoba niż odpowiedzialna za zmianę, która przejmuje odpowiedzialność za jej wdrożenie na późniejszym etapie.

Analiza osoby zgłaszającej zmianę pomaga wykrywać wzorce związane z jakością zgłoszeń. Może na przykład pokazać, że konkretne osoby lub zespoły często przesyłają niekompletne zgłoszenia, które są odrzucane lub wymagają poprawek. Takie informacje można wykorzystać do zaplanowania szkoleń i poprawy jakości zgłoszeń.

Dlaczego to ważne

Pozwala ustalić, skąd pochodzą zgłoszenia zmian, analizować ich jakość według osoby lub zespołu oraz wskazywać obszary wymagające szkoleń.

Skąd pobrać

Zwykle odpowiada polu „Created By” lub „Requested By” w obiekcie Change Request.

Przykłady
Susan MillerDavid ChenMaria Garcia
Priorytet zmiany
ChangePriority
Poziom priorytetu zgłoszenia zmiany, określający jego pilność i wpływ na działalność firmy.
Opis

Priorytet zmiany określa się na podstawie jej pilności i wpływu. Pomaga zespołom ustalać kolejność prac i efektywnie przydzielać zasoby, tak aby najpierw realizować zmiany o największym znaczeniu.

Analiza priorytetu pozwala sprawdzić, czy zmiany o wysokim priorytecie są realizowane szybciej niż te o niskim priorytecie. Odstępstwa od tego założenia mogą wskazywać na nieefektywność lub wąskie gardła w ustalaniu priorytetów albo realizacji.

Dlaczego to ważne

Pomaga sprawdzić, czy proces nadaje odpowiedni priorytet zmianom o dużym wpływie i czy są one rzeczywiście realizowane szybciej, zgodnie z założeniami.

Skąd pobrać

Zwykle jest to pole „Priority” w obiekcie Change Request. Wartość może być ustawiana ręcznie lub wyliczana na podstawie pól wpływu i pilności.

Przykłady
1 - Krytyczny2 - Wysoki3 - Średni4 - Niski
Przyczyna odrzucenia
ChangeRejectionReason
Opis tekstowy lub kategoria wyjaśniająca, dlaczego zgłoszenie zmiany zostało odrzucone.
Opis

Gdy zgłoszenie zmiany zostaje odrzucone, ten atrybut zapisuje przyczynę podaną przez osobę zatwierdzającą. Może to być pozycja z wcześniej zdefiniowanej listy lub opis wpisany odręcznie.

Informacja ta jest niezbędna w dashboardzie „Rejected Change Request Analysis”. Klasyfikacja i analiza przyczyn odrzuceń pozwala wykryć częste problemy ze zgłoszeniami, takie jak brak wymaganych informacji, niewystarczająca ocena ryzyka lub konflikt z potrzebami biznesowymi. Wnioski z analizy można wykorzystać do poprawy jakości kolejnych zgłoszeń.

Dlaczego to ważne

Pokazuje bezpośrednio, dlaczego zmiany są odrzucane. Pozwala ukierunkować usprawnienia procesu zgłaszania i oceny, aby zmniejszyć ogólny odsetek odrzuceń.

Skąd pobrać

Dane te są często zapisywane w osobnym polu „Rejection Reason” lub w polu notatek, które jest uzupełniane po zmianie statusu na „Rejected”.

Przykłady
Niewystarczające szczegóły w planie wdrożeniaNiepełna ocena ryzykaKonflikt z innymi zaplanowanymi zmianami
Usługa objęta zmianą
ServiceAffected
Główna usługa biznesowa lub element konfiguracji (CI), którego dotyczy zmiana.
Opis

Ten atrybut wskazuje główną usługę IT, aplikację lub element infrastruktury, którego dotyczy zgłoszenie zmiany. Łączy proces zarządzania zmianą z szerszym środowiskiem zarządzania usługami IT.

Analiza według usługi objętej zmianą jest ważna dla KPI „Top Problematic Change Types”. Pomaga ustalić, które usługi są najczęściej zmieniane i które wiążą się z wysokim odsetkiem odrzuceń lub opóźnieniami. Dzięki temu właściciele usług mogą poprawiać ich stabilność i zarządzać długiem technologicznym.

Dlaczego to ważne

Łączy zmiany z konkretnymi usługami biznesowymi. Dzięki temu można ustalić, które usługi są najmniej stabilne lub wiążą się z największą liczbą problematycznych zmian.

Skąd pobrać

Informacja ta pochodzi zwykle z bazy danych zarządzania konfiguracją (CMDB) i jest zapisana w polu „Primary CI” lub „Service” obiektu Change Request.

Przykłady
Usługa poczty e-mail (Exchange)System ERP (SAP)Główny przełącznik sieciowy (CISCO-4500X)
Wymagane Zalecane Opcjonalne

Aktywności w zarządzaniu zmianami

To najważniejsze kroki procesu i kamienie milowe, które warto zapisać w dzienniku zdarzeń, aby prawidłowo odtworzyć przebieg procesu i mierzyć jego wyniki.
7 Zalecane 7 Opcjonalne
Działanie Opis
CAB zatwierdził zmianę
To ważny etap, w którym Change Advisory Board (CAB) lub wyznaczony organ zatwierdza realizację zmiany. Zdarzenie jest wnioskowane na podstawie zmiany statusu zgłoszenia na „Zatwierdzono”.
Dlaczego to ważne

To działanie wyznacza koniec cyklu zatwierdzania. Umożliwia rozpoczęcie planowania i wdrożenia, a także służy do obliczania KPI dotyczącego czasu zatwierdzania zmian.

Skąd pobrać

Wnioskowane na podstawie historii audytowej obiektu Change Request, a dokładniej znacznika czasu zmiany pola „Status” na „Zatwierdzono”.

Rejestrowanie

Wnioskowane na podstawie zmiany statusu na „Zatwierdzono”.

Typ zdarzenia inferred
Oceniono wpływ i ryzyko
To działanie oznacza zakończenie analizy ryzyka i wpływu zgłoszonej zmiany. Zwykle jest wnioskowane na podstawie zmiany statusu zgłoszenia na stan oznaczający gotowość do zatwierdzenia, na przykład „Oczekuje na zatwierdzenie”.
Dlaczego to ważne

Śledzenie tego działania pozwala zmierzyć czas trwania etapu oceny i sprawdzić, czy analiza ryzyka jest konsekwentnie przeprowadzana przed zatwierdzeniem. Wspiera też KPI dotyczący przestrzegania zasad oceny ryzyka.

Skąd pobrać

Wnioskowane na podstawie historii obiektu Change Request. Zdarzenie jest rejestrowane w chwili zmiany pola „Status” z „W trakcie oceny” na status taki jak „Oczekuje na zatwierdzenie przez CAB”.

Rejestrowanie

Wnioskowane na podstawie zmiany statusu na „Oczekuje na zatwierdzenie przez CAB”.

Typ zdarzenia inferred
Przeprowadzenie przeglądu po wdrożeniu
Ta czynność oznacza przeprowadzenie formalnego przeglądu zakończonej zmiany, aby ocenić jej powodzenie i zapisać wnioski. Często można ją ustalić na podstawie zmiany statusu na „Post Implementation Review”.
Dlaczego to ważne

Śledzenie tej czynności pozwala sprawdzić, czy zebrano informacje zwrotne dotyczące zmian. Jest to niezbędne do ciągłego doskonalenia i bezpośrednio wspiera KPI „Post-Implementation Review Rate”.

Skąd pobrać

Ustalane na podstawie historii audytu obiektu Change Request. Rejestrowany jest znacznik czasu zmiany pola „Status” na wartość taką jak „Post Implementation Review”.

Rejestrowanie

Ustalane na podstawie zmiany statusu na „Post Implementation Review”.

Typ zdarzenia inferred
Utworzono zgłoszenie zmiany
To działanie oznacza rozpoczęcie nowego zgłoszenia zmiany w systemie. Zwykle jest rejestrowane w chwili utworzenia nowego rekordu w obiekcie biznesowym Change Request i wyznacza początek całego procesu.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Analiza czasu od tego działania do kolejnych etapów pokazuje całkowity czas realizacji i pomaga wykryć opóźnienia na początku procesu.

Skąd pobrać

Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia rekordu Change Request. W Ivanti Cherwell jest on zwykle zapisany w polu „CreatedDateTime” obiektu biznesowego Change Request.

Rejestrowanie

Pobierane bezpośrednio ze znacznika czasu utworzenia rekordu.

Typ zdarzenia explicit
Zamknięcie zmiany
To końcowy etap procesu zarządzania zmianą, oznaczający jego pomyślne zakończenie. Jest rejestrowany, gdy status zgłoszenia zmienia się na „Closed”, co oznacza, że wszystkie prace zostały zakończone.
Dlaczego to ważne

Jako główny punkt końcowy procesu ta czynność jest niezbędna do obliczenia całkowitego czasu realizacji pomyślnie zakończonych zmian. Potwierdza zakończenie wszystkich etapów procesu.

Skąd pobrać

Ustalane na podstawie znacznika czasu ostatniej zmiany statusu na „Closed” w historii audytu obiektu Change Request.

Rejestrowanie

Ustalane na podstawie ostatniej zmiany statusu na „Closed”.

Typ zdarzenia inferred
Zaplanowano zmianę
To działanie oznacza formalne potwierdzenie i zapisanie daty oraz godziny wdrożenia zmiany. Jest rejestrowane, gdy status zmienia się na „Zaplanowano”.
Dlaczego to ważne

To ważny moment, w którym zapada decyzja o realizacji zmiany. Zatwierdzona koncepcja przechodzi wtedy w zaplanowane działanie. To warunek rozpoczęcia wdrożenia.

Skąd pobrać

Ustalane na podstawie historii obiektu Change Request. Rejestrowany jest znacznik czasu zmiany pola „Status” na „Scheduled”.

Rejestrowanie

Ustalane na podstawie zmiany statusu na „Scheduled”.

Typ zdarzenia inferred
Zmiana wdrożona
Ten kamień milowy oznacza zakończenie prac technicznych nad zmianą. Jest rejestrowany, gdy status zgłoszenia zmienia się na „Implemented” lub podobną wartość oznaczającą oczekiwanie na weryfikację.
Dlaczego to ważne

To ważny wskaźnik powodzenia oraz dane wejściowe do KPI „On-Time Change Completion Rate” i „Average Change Implementation Time”. Oznacza koniec etapu realizacji.

Skąd pobrać

Ustalane na podstawie dziennika audytu obiektu Change Request, z wykorzystaniem znacznika czasu zmiany statusu na „Implemented” lub „Pending Verification”.

Rejestrowanie

Ustalane na podstawie zmiany statusu na „Implemented”.

Typ zdarzenia inferred
Anulowanie zmiany
Oznacza stan końcowy, w którym zatwierdzone lub będące w toku zgłoszenie zmiany zostaje wycofane przed zakończeniem. Zdarzenie jest rejestrowane, gdy status zmienia się na „Cancelled”.
Dlaczego to ważne

To alternatywny punkt końcowy procesu. Analiza przyczyn i momentów anulowania zmian może ujawnić problemy z planowaniem, przydziałem zasobów lub zmieniającymi się priorytetami biznesowymi.

Skąd pobrać

Ustalane na podstawie historii audytu. Rejestrowany jest znacznik czasu zmiany pola „Status” obiektu Change Request na „Cancelled”.

Rejestrowanie

Ustalane na podstawie zmiany statusu na „Cancelled”.

Typ zdarzenia inferred
Odrzucono zmianę
To końcowa decyzja o odrzuceniu zgłoszenia zmiany na etapie zatwierdzania. Zdarzenie jest rejestrowane, gdy status zgłoszenia zmienia się na „Odrzucono”.
Dlaczego to ważne

To krytyczny punkt końcowy procesu. Analiza odrzuconych zmian i przyczyn odrzucenia pomaga poprawić jakość zgłoszeń oraz mierzyć KPI dotyczący odsetka odrzuconych zgłoszeń zmian.

Skąd pobrać

Wnioskowane na podstawie znacznika czasu zmiany pola „Status” w obiekcie Change Request na „Odrzucono”, zapisanego w historii audytowej.

Rejestrowanie

Wnioskowane na podstawie zmiany statusu na „Odrzucono”.

Typ zdarzenia inferred
Opracowano plan wdrożenia
Oznacza zakończenie szczegółowego planowania zmiany, w tym określenie zadań, zasobów i planu wycofania. Zdarzenie jest często wnioskowane na podstawie zmiany statusu z „Zatwierdzono” na „Zaplanowano”.
Dlaczego to ważne

Czas trwania tego działania pokazuje sprawność etapu planowania zmiany. Opóźnienia mogą wydłużyć cały proces, nawet po uzyskaniu zatwierdzenia.

Skąd pobrać

Zdarzenie można wywnioskować ze znacznika czasu zmiany statusu z „Zatwierdzono” na „Zaplanowano”. Można je też powiązać z uzupełnieniem określonych pól planowania.

Rejestrowanie

Wnioskowane na podstawie zmiany statusu z „Zatwierdzono” na „Zaplanowano”.

Typ zdarzenia inferred
Przekazano zmianę do oceny
Oznacza formalne przekazanie nowo utworzonego zgłoszenia zmiany do wstępnej oceny. Zdarzenie jest zwykle wnioskowane na podstawie zmiany statusu zgłoszenia z „Nowe” lub „Wersja robocza” na „W trakcie oceny”.
Dlaczego to ważne

To działanie rozpoczyna formalny proces zarządzania zmianą po wprowadzeniu początkowych danych. Czas między utworzeniem zgłoszenia a jego przekazaniem do oceny może wskazywać na potrzebę szkolenia użytkowników lub utrudnienia w procesie.

Skąd pobrać

Wnioskowane na podstawie dziennika audytowego lub historii obiektu Change Request. Wykorzystywany jest znacznik czasu zmiany pola „Status” na wartość taką jak „W trakcie oceny” lub „Przekazano do oceny”.

Rejestrowanie

Wnioskowane na podstawie zmiany statusu z „Nowe” na „W trakcie oceny”.

Typ zdarzenia inferred
Przeprowadzenie weryfikacji zmiany
Oznacza etap testowania i weryfikacji, który ma potwierdzić, że zmiana zakończyła się powodzeniem i nie wywołała niepożądanych skutków. Można go ustalić na podstawie zmiany statusu na „Verification” lub „Testing”.
Dlaczego to ważne

Analiza częstotliwości i czasu trwania tej czynności pozwala sprawdzić, czy nie pomija się kontroli jakości. To ważny etap zapobiegania incydentom spowodowanym zmianami.

Skąd pobrać

Rejestrowane na podstawie znacznika czasu zmiany statusu obiektu Change Request, na przykład zmiany na „Verification” lub „User Acceptance Testing”.

Rejestrowanie

Ustalane na podstawie zmiany statusu na „Verification”.

Typ zdarzenia inferred
Rozpoczęcie wdrażania zmiany
Oznacza rozpoczęcie technicznej realizacji zmiany. Zwykle można je ustalić na podstawie zmiany statusu zgłoszenia na „In Progress” lub „Implementing”.
Dlaczego to ważne

Ta czynność wyznacza początek wdrożenia. Czas od tego momentu do „Change Implemented” to rzeczywisty czas wdrożenia, który składa się na całkowity czas realizacji procesu.

Skąd pobrać

Ustalane na podstawie historii audytu obiektu Change Request. Jest to znacznik czasu zmiany pola „Status” na wartość taką jak „In Progress” lub „Implementing”.

Rejestrowanie

Ustalane na podstawie zmiany statusu na „In Progress”.

Typ zdarzenia inferred
Zmiana oczekuje na zatwierdzenie
To działanie oznacza okres, w którym zgłoszenie zmiany formalnie oczekuje na decyzję Change Advisory Board (CAB) lub innego organu zatwierdzającego. Jest wnioskowane na podstawie statusu takiego jak „Oczekuje na zatwierdzenie” lub „Oczekuje na CAB”.
Dlaczego to ważne

To działanie wiąże się z czasem oczekiwania. Analiza jego długości pomaga wykryć wąskie gardła w workflow zatwierdzania, które często powodują opóźnienia w zarządzaniu zmianą.

Skąd pobrać

Rejestrowane na podstawie znacznika czasu aktualizacji pola „Status” w obiekcie biznesowym Change Request na „Oczekuje na zatwierdzenie” lub równoważną wartość.

Rejestrowanie

Rozpoznawane na podstawie przejścia do statusu „Oczekuje na zatwierdzenie”.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Ivanti Cherwell

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby rozpocząć analizę procesu zarządzania zmianami i znaleźć możliwości jego usprawnienia. Już dziś zacznij optymalizować wdrażanie zmian.

Zwiększ odsetek udanych zmian do 95%: zoptymalizuj Ivanti Cherwell

Usuń wąskie gardła, ogranicz ryzyko i zwiększ odsetek udanych zmian do 95%.

Rozpocznij okres próbny

Nie trzeba podawać danych karty kredytowej. Można zacząć od razu.