Szablon danych do zarządzania zmianami
Szablon danych do zarządzania zmianami
- Zalecane atrybuty do zebrania na potrzeby szczegółowej analizy
- Najważniejsze działania i etapy procesu do śledzenia
- Szczegółowe wskazówki dotyczące pobierania danych z odpowiednich systemów źródłowych
Atrybuty zarządzania zmianami
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas rozpoczęcia
EventStartTime
|
Znacznik czasu wskazujący, kiedy rozpoczęła się dana czynność lub zdarzenie. | ||
|
Opis
Ten atrybut zapisuje dokładną datę i godzinę wykonania czynności. Może na przykład wskazywać, kiedy zmiana została zgłoszona, zatwierdzona lub zamknięta. Znacznik czasu jest niezbędny do analizy przebiegu procesu. Służy do obliczania czasu cyklu między czynnościami, pomiaru czasu oczekiwania, wykrywania zmian w wynikach w czasie i ustalania kolejności zdarzeń. Dokładne znaczniki czasu są podstawą każdej analizy procesu uwzględniającej czas.
Dlaczego to ważne
Zapewnia wymiar czasowy niezbędny do obliczania czasu trwania, analizy wyników i ustalania kolejności zdarzeń w procesie.
Skąd pobrać
Pochodzi z pola „Audit Date” w formularzu „CHG:ChangeRequest_AuditLog” lub z pola „Last Modified Date” powiązanego z konkretnymi zmianami statusu.
Przykłady
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Czynność
ActivityName
|
Nazwa konkretnego zdarzenia lub zadania wykonanego w ramach procesu zarządzania zmianami. | ||
|
Opis
Ten atrybut oznacza pojedynczy krok lub zmianę statusu w cyklu życia zgłoszenia zmiany, na przykład „Zgłoszenie zmiany przesłane” lub „Zgłoszenie zmiany zatwierdzone”. Czynności te składają się na mapę procesu. Analiza ich kolejności i czasu trwania pomaga ustalić przebieg procesu, wykryć odstępstwa od standardowej procedury i wskazać wąskie gardła. Nazwy czynności zwykle pochodzą ze zmian statusu zapisanych w dziennikach audytu systemu.
Dlaczego to ważne
Określa kroki procesu i umożliwia ich wizualizację oraz analizę przepływu procesu, co stanowi podstawę process mining.
Skąd pobrać
Pochodzi ze zmian statusu w formularzu „CHG:ChangeRequest_AuditLog” lub ze śledzenia zmian pola „Status” w formularzu „CHG:Infrastructure Change”.
Przykłady
Zgłoszenie zmiany przesłaneOcena ryzyka przeprowadzonaZgłoszenie zmiany zatwierdzoneZmiana wdrożona
|
|||
|
Identyfikator zgłoszenia zmiany
ChangeRequestID
|
Unikatowy identyfikator zgłoszenia zmiany wygenerowany przez system, używany jako główny identyfikator sprawy. | ||
|
Opis
Identyfikator zgłoszenia zmiany to unikatowy klucz, który pozwala śledzić każdą zmianę przez cały cykl jej realizacji. Łączy wszystkie powiązane czynności, zatwierdzenia i zadania, tworząc podstawę pojedynczej sprawy w process mining. Analiza procesów według tego identyfikatora pokazuje cały przebieg zarządzania zmianą, od pierwszego zgłoszenia po ostateczne zamknięcie. Ułatwia pomiar czasu cyklu, wykrywanie wąskich gardeł i analizę różnic w przebiegu poszczególnych zmian.
Dlaczego to ważne
Ten podstawowy atrybut łączy wszystkie powiązane zdarzenia w jedną instancję procesu, umożliwiając analizę zarządzania zmianami od początku do końca.
Skąd pobrać
Znajduje się w polu „Infrastructure Change ID” (Field ID 1000000182) formularza „CHG:Infrastructure Change”.
Przykłady
CRQ0000001234567CRQ0000001234568CRQ0000001234569
|
|||
|
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 pokazuje datę i godzinę ostatniego pobrania danych z BMC Helix ITSM. Nie wskazuje czasu wystąpienia zdarzenia, lecz moment pobrania danych. Informacja ta pomaga ocenić aktualność analizowanych danych i zarządzać cyklami ich odświeżania. W dashboardach i raportach znacznik czasu informuje użytkowników, jak aktualna jest analiza. Ma to szczególne znaczenie przy monitorowaniu trwających procesów.
Dlaczego to ważne
Informuje o aktualności danych, co pozwala sprawdzić, czy analizy i dashboardy odzwierciedlają bieżący stan procesu.
Skąd pobrać
To pole metadanych, które zwykle jest generowane i uzupełniane przez narzędzie ETL lub potok danych podczas ich pobierania.
Przykłady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
System źródłowy
SourceSystem
|
Nazwa systemu, z którego pobrano dane. | ||
|
Opis
Ten atrybut wskazuje źródło danych o procesie, którym w tym przypadku jest „BMC Helix ITSM”. Ułatwia zarządzanie danymi i śledzenie ich pochodzenia, zwłaszcza gdy szersza analiza obejmuje dane z wielu systemów. Jeśli na przykład dane o zmianach zostaną połączone z danymi z systemu finansowego lub do zarządzania projektami, to pole pozwoli jednoznacznie rozróżnić źródła danych.
Dlaczego to ważne
Dostarcza ważnych informacji o pochodzeniu danych, ułatwiając ich śledzenie i prawidłową interpretację, zwłaszcza podczas analizy danych z wielu systemów.
Skąd pobrać
Zwykle jest to stała wartość dodawana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL), aby oznaczyć źródło zbioru danych.
Przykłady
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
|
|||
|
Grupa zatwierdzająca
ApproverGroup
|
Zespół lub grupa odpowiedzialna za zatwierdzenie wniosku o zmianę na określonym etapie. | ||
|
Opis
Ten atrybut wskazuje grupę wyznaczoną do weryfikacji i zatwierdzenia zmiany. Ponieważ zmiana może przechodzić przez kilka etapów zatwierdzania, na poszczególnych etapach mogą odpowiadać za nią różne grupy, na przykład zespół zatwierdzający kwestie techniczne i rada zatwierdzająca kwestie biznesowe. Atrybut ten jest niezbędny w dashboardzie „Wąskie gardła w zatwierdzaniu zmian”, ponieważ pozwala porównywać czas zatwierdzania przez poszczególne grupy. Dzięki temu można wskazać zespoły przeciążone lub działające nieefektywnie, które opóźniają proces.
Dlaczego to ważne
Pozwala wykrywać wąskie gardła w procesie zatwierdzania, umożliwiając analizę czasu zatwierdzania przez poszczególne zespoły.
Skąd pobrać
Dane pochodzą z formularza „AP:Signature”, który obsługuje zatwierdzanie i jest powiązany z wnioskiem o zmianę. Grupa osoby zatwierdzającej jest częścią tego rekordu.
Przykłady
Komitet doradczy ds. zmianBezpieczeństwo ITInżynieria sieciowaTworzenie aplikacji
|
|||
|
Poziom ryzyka
RiskLevel
|
Ocena potencjalnego ryzyka związanego z wdrożeniem zmiany. | ||
|
Opis
Poziom ryzyka to jakościowa lub ilościowa ocena potencjalnych negatywnych skutków wdrożenia zmiany. Jest ważnym kryterium w procesie zatwierdzania, ponieważ zmiany o wyższym ryzyku podlegają dokładniejszej weryfikacji. Ten atrybut ma zasadnicze znaczenie dla dashboardu „Change Risk Profile Analysis”, który pomaga interesariuszom ocenić łączne ryzyko związane z portfelem zmian. Służy też do wykrywania pętli ponownej pracy, gdy niewystarczająca wstępna ocena ryzyka prowadzi do ponownej analizy na późniejszym etapie.
Dlaczego to ważne
Umożliwia analizę zgodności i efektywności procesu oraz pomaga zadbać o odpowiednią weryfikację zmian o wyższym ryzyku.
Skąd pobrać
Znajduje się w polu „Risk Level” formularza „CHG:Infrastructure Change”.
Przykłady
1 - Krytyczny2 - Wysoki3 - Średni4 - Niski5 - Planowanie
|
|||
|
Priorytet
Priority
|
Poziom priorytetu przypisany do zgłoszenia zmiany, wskazujący jego znaczenie dla firmy. | ||
|
Opis
Priorytet zwykle ustala się na podstawie wpływu i pilności. Określa on kolejność i tempo obsługi zgłoszenia zmiany. Zmiana o wyższym priorytecie zazwyczaj wymaga szybszej realizacji i może podlegać bardziej rygorystycznym umowom SLA. Ten atrybut służy do segmentowania i analizowania wyników według poziomu priorytetu w dashboardzie „Change SLA Performance”. Pomaga odpowiedzieć na pytania, takie jak „Czy dotrzymujemy SLA dla zmian o wysokim priorytecie?”, i wspiera decyzje dotyczące przydziału zasobów.
Dlaczego to ważne
Umożliwia analizę wyników według znaczenia zmiany dla firmy, dzięki czemu najważniejsze zmiany mogą być sprawnie obsługiwane i realizowane w wyznaczonym terminie.
Skąd pobrać
Znajduje się w polu „Priority” formularza „CHG:Infrastructure Change”.
Przykłady
KrytycznyWysokiŚredniNiski
|
|||
|
Status
Status
|
Bieżący stan lub etap zgłoszenia zmiany w jej cyklu życia. | ||
|
Opis
Pole Status wskazuje dokładny etap zgłoszenia zmiany w danym momencie, na przykład „Draft”, „Request For Authorization” lub „Completed”. Czynności są ustalane na podstawie przejść między statusami, ale sam status pomaga analizować bieżące obciążenie pracą. Ten atrybut jest niezbędny w dashboardzie „Change Throughput & Current Status”, który pokazuje liczbę zmian na poszczególnych etapach procesu. Pomaga kierownikom zrozumieć, ile pracy jest w toku i jak przydzielane są zasoby.
Dlaczego to ważne
Pokazuje bieżący stan procesu obsługi zmian, umożliwiając analizę pracy w toku i statusu wszystkich zgłoszeń zmian.
Skąd pobrać
Znajduje się w polu „Status” formularza „CHG:Infrastructure Change”.
Przykłady
Wersja roboczaOczekuje na zatwierdzenieZaplanowanaWdrożenie w tokuZakończona
|
|||
|
Typ zmiany
ChangeType
|
Klasyfikacja zmiany, na przykład standardowa, zwykła lub awaryjna. | ||
|
Opis
Ten atrybut klasyfikuje zgłoszenie zmiany według jej charakteru i wymaganej ścieżki procesu. Typowe kategorie to Standard (zmiana wstępnie zatwierdzona, o niskim ryzyku), Normal (wymaga pełnej oceny i zatwierdzenia) oraz Emergency (wymaga przyspieszonej obsługi ze względu na pilny problem). Analiza według typu zmiany pomaga zrozumieć różnice w przebiegu procesu. Na przykład dashboard „Emergency Change Volume & Impact” korzysta z tego pola, aby śledzić pilne zmiany i ich wpływ na stabilność usług. Pozwala też sprawdzić, czy poszczególne typy zmian przebiegają zgodnie z wymaganymi ścieżkami.
Dlaczego to ważne
Umożliwia podział procesu na segmenty, aby analizować i porównywać różne workflow zmian. Jest to ważne przy analizie zgodności i wyników.
Skąd pobrać
Znajduje się w polu „Change Type” formularza „CHG:Infrastructure Change”.
Przykłady
StandardowaZwykłaAwaryjnaBrak wpływu
|
|||
|
Zespół wdrożeniowy
ImplementationTeam
|
Zespół odpowiedzialny za wdrożenie zmiany. | ||
|
Opis
Ten atrybut wskazuje zespół techniczny lub operacyjny wyznaczony do wykonania prac wymaganych w ramach wniosku o zmianę. Na etapach wdrażania zmiany jest to często grupa wskazana w polu „Assigned Group”. Informacje te są niezbędne w dashboardzie „Wąskie gardła związane z zasobami w procesie zarządzania zmianami”. Analiza czasu trwania i liczby działań realizowanych przez poszczególne zespoły wdrożeniowe pozwala kierownikom wykrywać nierównomierne obciążenie, braki kompetencyjne i inne ograniczenia zasobów opóźniające wdrożenie zmiany.
Dlaczego to ważne
Pomaga wykrywać wąskie gardła związane z zasobami na etapie wdrożenia, umożliwiając analizę wyników pracy poszczególnych zespołów.
Skąd pobrać
Dane znajdują się w polu „ASGRP” (Assigned Group) formularza „CHG:Infrastructure Change”.
Przykłady
Operacje serweroweAdministratorzy baz danychZespół SAP BasisInfrastruktura chmurowa
|
|||
|
Czas zakończenia
EventEndTime
|
Znacznik czasu wskazujący, kiedy zakończyła się dana czynność lub zdarzenie. | ||
|
Opis
Czas zakończenia oznacza moment ukończenia czynności. W process mining często oblicza się go jako czas rozpoczęcia kolejnej czynności w danej sprawie, co pozwala określić czas trwania poprzedniego kroku. W przypadku ostatniej czynności w sprawie może być równy jej czasowi rozpoczęcia lub odpowiadać konkretnemu znacznikowi czasu zamknięcia. Ten atrybut jest niezbędny do obliczania wartości
Dlaczego to ważne
Umożliwia dokładne obliczanie czasu trwania czynności, co jest niezbędne do wykrywania wąskich gardeł i pomiaru wyników procesu.
Skąd pobrać
To atrybut obliczany zwykle podczas transformacji danych na podstawie czasu rozpoczęcia kolejnego zdarzenia w sekwencji dla danej sprawy.
Przykłady
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
|
|||
|
Czy ponowne wykonanie
IsRework
|
Flaga wskazująca, czy działanie oznacza powrót do wcześniejszego etapu lub ponowne wykonanie części procesu. | ||
|
Opis
Ten atrybut logiczny przyjmuje wartość true, gdy wniosek o zmianę wraca do wcześniejszego etapu cyklu życia, na przykład z „Zaplanowano” do „Oceny ryzyka”. Takie cofnięcia oznaczają konieczność ponownego wykonania pracy i często obniżają sprawność procesu. Flaga służy do obliczania KPI „Odsetek zmian wymagających ponownego wykonania” i wspiera dashboard „Ponowne wykonanie zmian i sprawność oceny”. Pozwala określić, jak często trzeba powtarzać pracę, oraz wskazać etapy, na których zdarza się to najczęściej. Dzięki temu można znaleźć obszary wymagające poprawy w planowaniu i ocenie zmian.
Dlaczego to ważne
Wskazuje działania należące do pętli ponownego wykonania, pomagając wykrywać nieefektywności procesu i kierować działania usprawniające we właściwe miejsca.
Skąd pobrać
Atrybut jest obliczany na podstawie kolejności działań w danym case. Podczas transformacji danych stosuje się reguły wykrywające cofnięcia w przebiegu procesu.
Przykłady
truefalse
|
|||
|
Czy zmiana awaryjna
IsEmergencyChange
|
Flaga logiczna przyjmująca wartość true, jeśli zmiana ma typ „Awaryjna”. | ||
|
Opis
Ta flaga pochodna ułatwia analizę, ponieważ jednoznacznie wskazuje zmiany awaryjne. Jej wartość zależy od atrybutu „ChangeType”. Atrybut wspiera przede wszystkim dashboard „Liczba i wpływ zmian awaryjnych” oraz KPI „Odsetek zmian awaryjnych”. Ułatwia filtrowanie i agregowanie danych o zmianach awaryjnych, dzięki czemu można śledzić ich częstotliwość i zmiany w czasie bez tworzenia złożonych filtrów w narzędziu analitycznym.
Dlaczego to ważne
Ułatwia analizę zmian awaryjnych, filtrowanie danych i obliczanie powiązanych KPI.
Skąd pobrać
Atrybut pochodny tworzony podczas transformacji danych. Reguła: IF 'ChangeType' = 'Emergency' THEN true ELSE false.
Przykłady
truefalse
|
|||
|
Identyfikator powiązanego incydentu
RelatedIncidentID
|
Identyfikator incydentu, który został spowodowany przez tę zmianę. | ||
|
Opis
Ten atrybut łączy wniosek o zmianę z późniejszymi incydentami, które mogły być jej skutkiem. Ta relacja pozwala ocenić dalszy wpływ zmian na stabilność usług. Jest to podstawowy atrybut potrzebny do obliczenia KPI „Odsetek incydentów spowodowanych zmianami”. Śledzenie tych powiązań pozwala ocenić jakość procesu zarządzania zmianami i wskazać typy zmian, zespoły lub usługi, z którymi wiąże się więcej problemów po wdrożeniu.
Dlaczego to ważne
Bezpośrednio mierzy negatywny wpływ zmian i dostarcza KPI do oceny ich jakości oraz skuteczności zarządzania ryzykiem.
Skąd pobrać
Powiązanie jest zwykle tworzone w formularzu incydentu („HPD:Help Desk”), gdzie incydent można połączyć z wnioskiem o zmianę, która go spowodowała.
Przykłady
INC000000987654INC000000987655INC000000987656
|
|||
|
Kod zamknięcia
CloseCode
|
Kod określający końcowy wynik zmiany w chwili jej zamknięcia. | ||
|
Opis
Kod zamknięcia określa ustandaryzowany powód zamknięcia wniosku o zmianę, na przykład „Zrealizowano pomyślnie”, „Zrealizowano pomyślnie z problemami”, „Wycofano” lub „Anulowano”. Atrybut ten opisuje wynik zmiany dokładniej niż sam jej końcowy status. Analiza kodów zamknięcia pomaga ocenić jakość i skuteczność wdrożonych zmian. Na przykład duża liczba zmian oznaczonych jako „Wycofano” może wskazywać na problemy z planowaniem lub testowaniem. To przydatna miara przy doskonaleniu procesu.
Dlaczego to ważne
Jasno i w ustrukturyzowany sposób określa wynik każdej zmiany, umożliwiając analizę skuteczności oraz przyczyn niepowodzeń i anulowania.
Skąd pobrać
Dane znajdują się w polu „Status Reason” lub podobnym polu kodu zamknięcia formularza „CHG:Infrastructure Change”. Pole jest aktywne na końcowych etapach procesu.
Przykłady
Zrealizowano pomyślnieZrealizowano pomyślnie z problemamiWycofanoAnulowano
|
|||
|
Osoba zgłaszająca zmianę
ChangeSubmitter
|
Osoba, która utworzyła i przesłała wniosek o zmianę. | ||
|
Opis
Ten atrybut wskazuje osobę, która zainicjowała wniosek o zmianę. W systemie jest ona zwykle zapisana jako użytkownik w polu „Submitter” lub „Reported By”. Choć nie zawsze jest to podstawowy wymiar analizy, atrybut może pomóc ustalić, skąd pochodzą wnioski o zmianę. Można na przykład sprawdzić, czy większość zmian zgłaszają określone działy lub osoby pełniące konkretne role. Wyniki takiej analizy dostarczają informacji o potrzebach biznesowych i sposobie planowania.
Dlaczego to ważne
Pomaga wskazać osoby zgłaszające zmiany, co pozwala analizować wzorce zapotrzebowania i zachowania użytkowników w procesie.
Skąd pobrać
Dane znajdują się w polu „Submitter” formularza „CHG:Infrastructure Change”.
Przykłady
Allen AllbrookMary MannBob Baxter
|
|||
|
Pilność
Urgency
|
Pilność zmiany, określająca, jak szybko należy ją wdrożyć. | ||
|
Opis
Pilność wskazuje, jak szybko należy wdrożyć zmianę. Wraz z wpływem służy do ustalenia ogólnego priorytetu zgłoszenia zmiany. Pilność jest ważnym atrybutem w dashboardzie „Change Risk Profile Analysis”, ponieważ pokazuje presję czasową w procesie zarządzania zmianami. Analiza trendów może pomóc wykryć przyczyny dużej liczby zgłoszeń wymagających szybkiej realizacji.
Dlaczego to ważne
Odzwierciedla presję czasu związaną ze zmianami i pomaga ocenić, czy proces skutecznie obsługuje zgłoszenia o różnym stopniu pilności.
Skąd pobrać
Znajduje się w polu „Urgency” formularza „CHG:Infrastructure Change”.
Przykłady
1 - Krytyczna2 - Wysoka3-średni4-niski
|
|||
|
Stan SLA
SLAState
|
Obliczany status wniosku o zmianę względem terminu SLA. | ||
|
Opis
Ten atrybut wskazuje, czy wniosek o zmianę został zrealizowany zgodnie z SLA, czy groziło mu przekroczenie terminu, czy też termin został przekroczony. Wartość jest obliczana przez porównanie rzeczywistego znacznika czasu zakończenia z „SLATargetDate”. To podstawowa miara w dashboardzie „Realizacja SLA dla zmian”. Pokazuje, jak realizacja przebiega względem uzgodnionych poziomów usług. Dane można analizować według priorytetu, typu zmiany lub zespołu, aby wskazać obszary, w których SLA jest często niedotrzymywane.
Dlaczego to ważne
Bezpośrednio mierzy realizację uzgodnionych zobowiązań, dlatego pozwala ocenić sprawność procesu i jakość usług.
Skąd pobrać
Atrybut jest obliczany podczas transformacji danych przez porównanie znacznika czasu ostatniego działania z „SLATargetDate”.
Przykłady
W terminieZagrożone przekroczeniem terminuPrzekroczono termin
|
|||
|
Termin SLA
SLATargetDate
|
Data i godzina, do których należy zakończyć realizację wniosku o zmianę. | ||
|
Opis
Termin SLA to ostateczna data realizacji wniosku o zmianę, ustalana na podstawie jego priorytetu i typu. Stanowi punkt odniesienia przy ocenie rzeczywistego czasu realizacji. Atrybut ten jest podstawą dashboardu „Realizacja SLA dla zmian”. Porównanie rzeczywistego czasu zamknięcia z terminem pozwala ustalić, czy zmiana została zrealizowana zgodnie z SLA. Analiza wyników SLA pomaga ocenić ogólną sprawność procesu i dotrzymywanie uzgodnionych poziomów usług.
Dlaczego to ważne
Stanowi punkt odniesienia do pomiaru wyników, pozwala obliczać odsetek zmian zgodnych z SLA i wskazywać te, którym grozi niedotrzymanie terminu.
Skąd pobrać
Informacje te są zwykle przechowywane w powiązanych formularzach do zarządzania SLA i łączone z wnioskiem o zmianę. Często są widoczne bezpośrednio w formularzu zmiany.
Przykłady
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
|
|||
|
Usługa, której dotyczy zmiana
AffectedService
|
Usługa biznesowa lub techniczna, na którą wpływa zmiana. | ||
|
Opis
Ten atrybut łączy wniosek o zmianę z konkretną usługą zdefiniowaną w bazie danych zarządzania konfiguracją (CMDB). Może to być usługa biznesowa dostępna dla użytkowników, na przykład „Poczta elektroniczna”, albo usługa techniczna działająca w tle, taka jak „Usługa uwierzytelniania”. Atrybut jest wykorzystywany w dashboardzie „Liczba i wpływ zmian awaryjnych” do powiązania zmian z usługami, których dotyczą. Pozwala ocenić stabilność poszczególnych usług i wskazać te, które wymagają częstych interwencji awaryjnych.
Dlaczego to ważne
Zapewnia kontekst biznesowy, łącząc zmiany techniczne z ich wpływem na usługi biznesowe i umożliwiając analizę procesu z perspektywy usług.
Skąd pobrać
Dane pochodzą z pola „ServiceCI” lub powiązań z elementami konfiguracji (CI) w formularzu „CHG:Infrastructure Change”.
Przykłady
Poczta firmowaSAP ERPZarządzanie relacjami z klientamiBankowość internetowa
|
|||
|
Wpływ
Impact
|
Oceniany wpływ zmiany na usługi biznesowe i infrastrukturę IT. | ||
|
Opis
Wpływ określa potencjalne skutki zmiany dla operacji biznesowych, usług i użytkowników. Wraz z pilnością jest ważnym czynnikiem przy ustalaniu priorytetu zgłoszenia zmiany. W analizie wpływ jest wykorzystywany w dashboardzie „Change Risk Profile Analysis”, który pokazuje potencjalne skutki biznesowe zmian w portfelu. Wiedza o udziale zmian o dużym wpływie może pomóc w opracowaniu strategii zarządzania ryzykiem i planowaniu zasobów.
Dlaczego to ważne
Pomaga określić potencjalne skutki zmian dla firmy, umożliwiając analizę ryzyka i ustalanie priorytetów na podstawie możliwego wpływu na usługi.
Skąd pobrać
Znajduje się w polu „Impact” formularza „CHG:Infrastructure Change”.
Przykłady
1 - Rozległy/powszechny2 - Znaczący/duży3 - Umiarkowany/ograniczony4 - Niewielki/lokalny
|
|||
Działania w procesie zarządzania zmianami
| Działanie | Opis | ||
|---|---|---|---|
|
Ocena ryzyka przeprowadzona
|
Ta czynność oznacza zakończenie oceny ryzyka proponowanej zmiany. Zwykle rejestruje się ją po aktualizacji statusu zgłoszenia zmiany lub zamknięciu konkretnego zadania oceny ryzyka. | ||
|
Dlaczego to ważne
Śledzenie tej czynności pomaga zapewnić zgodność z zasadami zarządzania zmianami. Ułatwia wykrywanie opóźnień na etapie oceny oraz analizę KPI wskaźnika ponownej pracy nad zmianą, jeśli proces wraca do tego kroku.
Skąd pobrać
Zdarzenie można ustalić na podstawie zmiany statusu w formularzu CHG:Change (np. przejścia do „Request For Change”) lub zakończenia powiązanego zadania w formularzu CHG:Task.
Rejestrowanie
Ustal znacznik czasu, kiedy powiązane zadanie „Risk Assessment” w CHG:Task otrzymuje status „Closed” lub „Completed”.
Typ zdarzenia
inferred
|
|||
|
Testy przeprowadzone
|
Oznacza zakończenie testów lub weryfikacji po wdrożeniu. Zdarzenie często rejestruje się po zamknięciu dedykowanego zadania testowego powiązanego ze zgłoszeniem zmiany. | ||
|
Dlaczego to ważne
Śledzenie tej czynności pozwala mierzyć KPI średniego czasu cyklu testów i kontrolować jakość. Pomaga też wykrywać wąskie gardła w procesie weryfikacji przed końcowym sprawdzeniem.
Skąd pobrać
Zdarzenie można ustalić na podstawie zakończenia rekordu zadania testowego w formularzu CHG:Task, powiązanego z nadrzędnym zgłoszeniem zmiany.
Rejestrowanie
Ustal znacznik czasu, kiedy powiązane zadanie „Testing” lub „Validation” w CHG:Task otrzymuje status „Closed” lub „Completed”.
Typ zdarzenia
inferred
|
|||
|
Utworzenie zgłoszenia zmiany
|
Ta czynność oznacza utworzenie w systemie rekordu zgłoszenia zmiany. Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia wpisu zgłoszenia zmiany w formularzu CHG:Change. | ||
|
Dlaczego to ważne
To punkt początkowy każdego zgłoszenia zmiany. Jest niezbędny do pomiaru całkowitego czasu trwania cyklu oraz analizy liczby napływających zmian.
Skąd pobrać
Zdarzenie jest rejestrowane na podstawie pola „Submit Date” lub znacznika czasu utworzenia rekordu w dzienniku audytu formularza CHG:Change (np. HPD:Help Desk Audit Log).
Rejestrowanie
Użyj znacznika czasu utworzenia rekordu z formularza CHG:Change.
Typ zdarzenia
explicit
|
|||
|
Zgłoszenie zmiany zatwierdzone
|
To ważny etap, w którym zgłoszenie zmiany otrzymuje formalną zgodę na realizację. Zdarzenie można ustalić na podstawie zmiany statusu, zwykle na „Scheduled” lub „Planning In Progress”, po uzyskaniu ostatecznej zgody. | ||
|
Dlaczego to ważne
Ten etap kończy fazę zatwierdzania. Jest istotny przy pomiarze opóźnień w zatwierdzaniu oraz KPI średniego czasu zatwierdzania zmian. To ważny punkt decyzyjny w procesie.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii zmian statusu w formularzu CHG:Change, a konkretnie momentu, w którym zgłoszenie opuszcza status zatwierdzania, taki jak „Request For Authorization”.
Rejestrowanie
Ustal znacznik czasu przejścia pola „Status” w CHG:Change poza końcową fazę zatwierdzania, np. na „Scheduled”.
Typ zdarzenia
inferred
|
|||
|
Zmiana wdrożona
|
Ta czynność oznacza pomyślne zakończenie prac związanych z wdrożeniem zmiany. Zwykle rejestruje się ją po zmianie statusu na „Completed” z powodem wskazującym na pomyślne zakończenie. | ||
|
Dlaczego to ważne
To ważny etap, który kończy fazę wdrożenia. Jest niezbędny do obliczenia czasu cyklu wdrożenia zmiany i analizy incydentów spowodowanych zmianami.
Skąd pobrać
Zdarzenie można ustalić na podstawie formularza CHG:Change, gdy pole „Status” ma wartość „Completed”, a pole „Status Reason” wartość „Successful”.
Rejestrowanie
Ustal znacznik czasu zmiany pola „Status” w CHG:Change na „Completed”.
Typ zdarzenia
inferred
|
|||
|
Zmiana zamknięta
|
To ostatnia czynność, która oznacza formalne zamknięcie zgłoszenia zmiany w systemie. Zdarzenie rejestruje się, gdy status zgłoszenia zmienia się na „Closed”. | ||
|
Dlaczego to ważne
Ta czynność oznacza pomyślne zakończenie cyklu zmiany. Jest niezbędna do pomiaru czasu trwania całego procesu i jego ogólnej przepustowości.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii zmian statusu w formularzu CHG:Change, gdy status zmienia się na „Closed”.
Rejestrowanie
Ustal znacznik czasu zmiany pola „Status” w CHG:Change na „Closed”.
Typ zdarzenia
inferred
|
|||
|
Zmiana zaplanowana
|
Ta czynność oznacza oficjalne zaplanowanie zatwierdzonej zmiany do wdrożenia. Zdarzenie rejestruje się po zmianie statusu w systemie na „Scheduled”. | ||
|
Dlaczego to ważne
To ważny etap, który oznacza gotowość do wdrożenia. Od tego momentu można mierzyć KPI czasu cyklu wdrożenia zmiany i średniego czasu oczekiwania na wdrożenie.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii zmian statusu w formularzu CHG:Change, gdy status zmienia się na „Scheduled”.
Rejestrowanie
Ustal znacznik czasu zmiany pola „Status” w CHG:Change na „Scheduled”.
Typ zdarzenia
inferred
|
|||
|
Analiza wpływu przeprowadzona
|
Oznacza zakończenie analizy potencjalnych skutków zmiany. Zwykle można je ustalić na podstawie aktualizacji statusu lub zamknięcia powiązanego zadania. | ||
|
Dlaczego to ważne
Ta czynność pomaga ocenić efektywność planowania i jego wpływ na ponowną pracę. Analiza czasu trwania i częstotliwości pozwala usprawnić wstępną ocenę.
Skąd pobrać
Zdarzenie można ustalić na podstawie znacznika czasu zakończenia zadania „Impact Analysis” w formularzu CHG:Task lub konkretnej zmiany statusu w formularzu CHG:Change.
Rejestrowanie
Ustal znacznik czasu, kiedy powiązane zadanie „Impact Analysis” w CHG:Task otrzymuje status „Closed” lub „Completed”.
Typ zdarzenia
inferred
|
|||
|
Plan wdrożenia opracowany
|
Oznacza utworzenie i udokumentowanie szczegółowego planu wdrożenia zmiany. Zwykle rejestruje się to po zakończeniu zadania planistycznego powiązanego ze zmianą. | ||
|
Dlaczego to ważne
Zakończenie tej czynności jest warunkiem zaplanowania i wdrożenia zmiany. Analiza czasu jej trwania pomaga wykrywać opóźnienia na etapie planowania, zanim zmiana zostanie wdrożona.
Skąd pobrać
Zdarzenie można ustalić na podstawie zakończenia konkretnego rekordu zadania planistycznego w formularzu CHG:Task, powiązanego z nadrzędnym zgłoszeniem zmiany.
Rejestrowanie
Ustal znacznik czasu, kiedy powiązane zadanie „Implementation Planning” w CHG:Task otrzymuje status „Closed” lub „Completed”.
Typ zdarzenia
inferred
|
|||
|
Przegląd po wdrożeniu
|
Oznacza zakończenie formalnego przeglądu po wdrożeniu zmiany. Zwykle rejestruje się tę czynność po zamknięciu zadania przeglądu po wdrożeniu (PIR). | ||
|
Dlaczego to ważne
Ta czynność wspiera uczenie się organizacji i ulepszanie procesów. Pomiar KPI wskaźnika przeglądów po wdrożeniu pomaga zadbać o wyciąganie wniosków ze zmian.
Skąd pobrać
Zdarzenie można ustalić na podstawie zakończenia zadania „Post-Implementation Review” w formularzu CHG:Task, powiązanego z nadrzędnym zgłoszeniem zmiany.
Rejestrowanie
Ustal znacznik czasu, kiedy powiązane zadanie „PIR” w CHG:Task otrzymuje status „Closed” lub „Completed”.
Typ zdarzenia
inferred
|
|||
|
Zgłoszenie zmiany odrzucone
|
Ta czynność oznacza formalne odrzucenie zgłoszenia zmiany przez osobę zatwierdzającą. Rejestruje się ją jako zmianę statusu na „Rejected”. Jest to stan końcowy. | ||
|
Dlaczego to ważne
Śledzenie odrzuconych zgłoszeń pomaga ustalić przyczyny, takie jak niekompletne informacje lub wysokie ryzyko. Analiza tych przyczyn może poprawić jakość przyszłych zgłoszeń zmian.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii zmian statusu w formularzu CHG:Change, a konkretnie przejścia do statusu „Rejected”.
Rejestrowanie
Ustal znacznik czasu zmiany pola „Status” w CHG:Change na „Rejected”.
Typ zdarzenia
inferred
|
|||
|
Zgłoszenie zmiany przesłane
|
Oznacza formalne przekazanie zgłoszenia zmiany do weryfikacji i zatwierdzenia. Zwykle można je rozpoznać po zmianie statusu zgłoszenia z „Draft” na „Request For Authorization”. | ||
|
Dlaczego to ważne
Ta czynność rozpoczyna proces zatwierdzania. Jej śledzenie jest niezbędne do pomiaru czasu oczekiwania zgłoszeń na wstępną weryfikację oraz analizy KPI czasu zatwierdzania zmian.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii zmian statusu zgłoszenia w formularzu CHG:Change, a konkretnie przejścia do statusu „Request For Authorization”.
Rejestrowanie
Ustal znacznik czasu zmiany pola „Status” w CHG:Change z „Draft” na „Request For Authorization”.
Typ zdarzenia
inferred
|
|||
|
Zmiana anulowana
|
Oznacza anulowanie zgłoszenia zmiany przed jej wdrożeniem lub zakończeniem. Zdarzenie rejestruje się po zmianie statusu zgłoszenia na „Cancelled”. | ||
|
Dlaczego to ważne
Śledzenie anulowanych zgłoszeń pozwala ustalić, dlaczego zmiany są wycofywane. Może ujawnić problemy, takie jak niewystarczające planowanie, zmiana priorytetów lub ograniczone zasoby.
Skąd pobrać
Zdarzenie można ustalić na podstawie historii zmian statusu w formularzu CHG:Change, gdy status zmienia się na „Cancelled”.
Rejestrowanie
Ustal znacznik czasu zmiany pola „Status” w CHG:Change na „Cancelled”.
Typ zdarzenia
inferred
|
|||
|
Zmiana zweryfikowana
|
Ta czynność oznacza formalne potwierdzenie przez interesariuszy, że zmiana zakończyła się powodzeniem po wdrożeniu i testach. Często rejestruje się ją jako zmianę statusu przed ostatecznym zamknięciem. | ||
|
Dlaczego to ważne
Weryfikacja to ostatnia kontrola jakości przed zamknięciem zmiany. Potwierdza, że zmiana spełniła założenia i nie wywołała niezamierzonych negatywnych skutków.
Skąd pobrać
Zdarzenie można ustalić na podstawie zmiany statusu w formularzu CHG:Change, np. przejścia z „Completed” do statusu „Verification” lub „Closed”.
Rejestrowanie
Ustal znacznik czasu przejścia pola „Status” w CHG:Change na „Closed” po zakończeniu prac wdrożeniowych.
Typ zdarzenia
inferred
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Już dziś można zacząć usprawniać proces zarządzania zmianami. Wystarczy przygotować dane za pomocą tego szablonu, aby uzyskać przydatne informacje i zwiększyć efektywność operacji.
Usprawnij zarządzanie zmianami i zapobiegaj zakłóceniom
Zwiększ odsetek udanych zmian do 95% i unikaj kosztownych przerw w świadczeniu usług.
Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.