Szablon danych do zarządzania zmianami
Szablon danych do zarządzania zmianami
- Zalecane atrybuty do zebrania
- Najważniejsze aktywności do śledzenia
- Instrukcja ekstrakcji danych z Ivanti Cherwell
Atrybuty zarządzania zmianami
| 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)
|
|||
Aktywności w zarządzaniu zmianami
| 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
|
|||
Instrukcje ekstrakcji danych
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%.
Nie trzeba podawać danych karty kredytowej. Można zacząć od razu.