Ihr Daten-Template für Change Management
Ihr Daten-Template für Change Management
- Empfohlene Attribute für eine umfassende Analyse
- Zentrale Aktivitäten und Meilensteine, die Sie in Ihrem Prozess verfolgen sollten
- Konkrete Hinweise zur Extraktion aus relevanten Quellsystemen
Attribute des Change Managements
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Die Bezeichnung des konkreten Ereignisses oder der Aufgabe im Änderungsmanagementprozess. | ||
|
Beschreibung
Dieses Attribut steht für einen einzelnen Schritt oder eine Statusänderung im Lebenszyklus eines Änderungsantrags, etwa 'Change Request Submitted' oder 'Change Request Approved'. Diese Aktivitäten bilden die einzelnen Schritte der Prozesslandkarte. Die Analyse ihrer Reihenfolge und Dauer zeigt den Prozessfluss, macht Abweichungen von der Standardvorgehensweise sichtbar und hilft, Engpässe zu lokalisieren. Die Aktivitätsnamen werden üblicherweise aus Statuswechseln abgeleitet, die in den Audit Logs des Systems erfasst sind.
Warum das wichtig ist
Das Attribut definiert die Prozessschritte und ermöglicht es, den Prozessfluss darzustellen und zu analysieren. Das ist die Grundlage des Process Mining.
Woher beziehen
Abgeleitet aus Statuswechseln im Formular 'CHG:ChangeRequest_AuditLog' oder aus der Nachverfolgung von Änderungen am Feld 'Status' im Formular 'CHG:Infrastructure Change'.
Beispiele
Änderungsantrag eingereichtRisikobewertung durchgeführtÄnderungsantrag freigegebenÄnderung umgesetzt
|
|||
|
Änderungsantrags-ID
ChangeRequestID
|
Die eindeutige, vom System generierte Kennung eines Änderungsantrags. Sie dient als primäre Case-ID. | ||
|
Beschreibung
Die Change Request ID ist der eindeutige Schlüssel für jede Änderungsinitiative während ihres gesamten Lebenszyklus. Sie fasst alle zugehörigen Aktivitäten, Freigaben und Aufgaben zusammen und bildet die Grundlage für einen einzelnen Case im Process Mining. Die Analyse anhand dieser ID zeigt den gesamten Änderungsprozess von der ersten Anfrage bis zum endgültigen Abschluss. So lassen sich Zykluszeiten verfolgen, Engpässe erkennen und Unterschiede im Ablauf einzelner Änderungen nachvollziehen.
Warum das wichtig ist
Dieses grundlegende Attribut führt alle zugehörigen Ereignisse zu einer Prozessinstanz zusammen und ermöglicht so die durchgängige Analyse des Änderungsmanagements.
Woher beziehen
Zu finden im Feld 'Infrastructure Change ID' (Field ID 1000000182) des Formulars 'CHG:Infrastructure Change'.
Beispiele
CRQ0000001234567CRQ0000001234568CRQ0000001234569
|
|||
|
Startzeit
EventStartTime
|
Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis begonnen hat. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit einer Aktivität genau. Es zeigt zum Beispiel, wann eine Änderung eingereicht, freigegeben oder abgeschlossen wurde. Der Timestamp ist entscheidend für die Analyse des Prozessverlaufs. Er dient dazu, Zykluszeiten zwischen Aktivitäten zu berechnen, Wartezeiten zu messen, Leistungstrends im Zeitverlauf zu erkennen und die Reihenfolge der Ereignisse zu bestimmen. Genaue Timestamps sind die Grundlage jeder zeitbezogenen Prozessanalyse.
Warum das wichtig ist
Das Attribut liefert die zeitliche Grundlage, um Dauern zu berechnen, die Leistung zu analysieren und die Reihenfolge der Ereignisse im Prozess nachzuvollziehen.
Woher beziehen
Stammt aus dem Feld 'Audit Date' im Formular 'CHG:ChangeRequest_AuditLog' oder aus dem Feld 'Last Modified Date' zu bestimmten Statusänderungen.
Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut zeigt Datum und Uhrzeit der letzten Datenextraktion aus BMC Helix ITSM. Es bezeichnet nicht den Zeitpunkt des Ereignisses selbst, sondern den Zeitpunkt des Datenabrufs. Diese Information ist wichtig, um die Aktualität der analysierten Daten einzuschätzen und Aktualisierungszyklen zu verwalten. In Dashboards und Berichten zeigt dieser Timestamp, wie aktuell die Analyse ist. Das ist besonders wichtig, wenn laufende Prozesse überwacht werden.
Warum das wichtig ist
Das Attribut gibt an, wie aktuell die Daten sind. So lässt sich sicherstellen, dass Analysen und Dashboards den neuesten Prozessstand abbilden.
Woher beziehen
Dieses Metadatenfeld wird in der Regel vom ETL-Tool oder der Datenpipeline zum Zeitpunkt der Datenextraktion erzeugt und befüllt.
Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Der Name des Systems, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt die Herkunft der Prozessdaten an, in diesem Fall 'BMC Helix ITSM'. Es unterstützt die Datenverwaltung und Rückverfolgbarkeit, insbesondere wenn Daten aus mehreren Systemen für eine umfassendere Analyse zusammengeführt werden. Werden Änderungsdaten beispielsweise später mit Daten aus einem Finanz- oder Projektmanagementsystem zusammengeführt, lassen sich die Quellen anhand dieses Felds eindeutig unterscheiden.
Warum das wichtig ist
Das Attribut gibt wichtige Auskunft über die Datenherkunft und ermöglicht Rückverfolgbarkeit sowie eine korrekte Interpretation, insbesondere bei Analysen über mehrere Systeme hinweg.
Woher beziehen
In der Regel handelt es sich um einen statischen Wert, der während des ETL-Prozesses (Extraktion, Transformation und Laden) hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.
Beispiele
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
|
|||
|
Änderungstyp
ChangeType
|
Die Klassifizierung der Änderung, zum Beispiel als Standard, Normal oder Notfall. | ||
|
Beschreibung
Dieses Attribut kategorisiert den Änderungsantrag nach seiner Art und dem dafür vorgesehenen Prozess. Gängige Typen sind Standard (vorab freigegeben, geringes Risiko), Normal (erfordert eine vollständige Bewertung und Freigabe) und Notfall (muss aufgrund eines dringenden Problems beschleunigt bearbeitet werden). Die Analyse nach Änderungstyp ist wichtig, um Prozessvarianten zu verstehen. So verwendet das Dashboard 'Emergency Change Volume & Impact' dieses Feld, um dringende Änderungen und ihre Auswirkungen auf die Service-Stabilität zu verfolgen. Außerdem lässt sich damit prüfen, ob die verschiedenen Änderungstypen den jeweils vorgesehenen Ablauf einhalten.
Warum das wichtig ist
Damit lässt sich der Prozess nach Änderungstypen aufteilen und vergleichen. Das ist wichtig für die Analyse von Compliance und Prozessleistung.
Woher beziehen
Zu finden im Feld 'Change Type' des Formulars 'CHG:Infrastructure Change'.
Beispiele
StandardNormalNotfallKeine Auswirkungen
|
|||
|
Genehmigergruppe
ApproverGroup
|
Das Team oder die Gruppe, die dafür zuständig ist, einen Änderungsantrag in einer bestimmten Phase freizugeben. | ||
|
Beschreibung
Dieses Attribut gibt die Gruppe an, die mit der Prüfung und Freigabe einer Änderung beauftragt ist. Da eine Änderung mehrere Freigabephasen durchlaufen kann, können im Verlauf unterschiedliche Gruppen zuständig sein, etwa ein technisches Freigabeteam und ein fachlicher Freigabeausschuss. Dieses Attribut ist für das Dashboard „Engpässe bei der Änderungsfreigabe“ wichtig, da sich damit Freigabezeiten nach der jeweils zuständigen Gruppe aufschlüsseln lassen. So können Teams ermittelt werden, die überlastet oder wenig effizient sind und dadurch den Prozess verzögern.
Warum das wichtig ist
Damit lassen sich Engpässe im Freigabeprozess erkennen, indem die Freigabedauer für jedes zuständige Team analysiert wird.
Woher beziehen
Die Daten stammen aus dem Formular „AP:Signature“, das Freigaben verwaltet und mit dem Änderungsantrag verknüpft ist. Die Gruppe des Genehmigers ist Teil dieses Datensatzes.
Beispiele
Change Advisory BoardIT-SicherheitNetzwerktechnikAnwendungsentwicklung
|
|||
|
Implementierungsteam
ImplementationTeam
|
Das Team, das für die Umsetzung der Änderung zuständig ist. | ||
|
Beschreibung
Dieses Attribut gibt die technische oder operative Gruppe an, die mit den für den Änderungsantrag erforderlichen Arbeiten beauftragt ist. Während der Implementierungsphasen des Änderungslebenszyklus ist dies häufig die „Assigned Group“. Diese Information ist entscheidend für das Dashboard „Ressourcenengpässe im Änderungsprozess“. Durch die Analyse von Aktivitätsdauer und -volumen je Implementierungsteam können Verantwortliche unausgewogene Arbeitslasten, fehlende Kompetenzen und andere ressourcenbedingte Einschränkungen erkennen, die die Bereitstellung von Änderungen verzögern.
Warum das wichtig ist
Damit lassen sich ressourcenbedingte Engpässe in der Implementierungsphase erkennen, indem die Leistung der jeweils zuständigen Teams analysiert wird.
Woher beziehen
Zu finden im Feld „ASGRP“ (Assigned Group) des Formulars „CHG:Infrastructure Change“.
Beispiele
ServerbetriebDatenbankadministrationSAP-Basis-TeamCloud-Infrastruktur
|
|||
|
Priorität
Priority
|
Die einem Änderungsantrag zugewiesene Priorität, die seine geschäftliche Bedeutung angibt. | ||
|
Beschreibung
Die Priorität ergibt sich in der Regel aus den Auswirkungen und der Dringlichkeit. Sie bestimmt, in welcher Reihenfolge und wie schnell ein Änderungsantrag bearbeitet wird. Änderungen mit höherer Priorität müssen meist schneller bearbeitet werden und unterliegen möglicherweise strengeren Service Level Agreements (SLAs). Dieses Attribut wird im Dashboard 'Change SLA Performance' verwendet, um die Leistung nach Prioritätsstufen aufzuschlüsseln und zu analysieren. Es hilft bei Fragen wie: 'Halten wir unsere SLAs für Änderungen mit hoher Priorität ein?' Außerdem unterstützt es Entscheidungen zur Ressourcenzuteilung.
Warum das wichtig ist
Damit lässt sich die Prozessleistung nach geschäftlicher Bedeutung auswerten. So können besonders kritische Änderungen effizient bearbeitet und ihre Zielvorgaben eingehalten werden.
Woher beziehen
Zu finden im Feld 'Priority' des Formulars 'CHG:Infrastructure Change'.
Beispiele
KritischHochMittelNiedrig
|
|||
|
Risikostufe
RiskLevel
|
Eine Bewertung des möglichen Risikos, das mit der Umsetzung der Änderung verbunden ist. | ||
|
Beschreibung
Die Risikostufe ist eine qualitative oder quantitative Einschätzung möglicher negativer Folgen der Änderung. Sie ist eine wichtige Grundlage für die Freigabe: Änderungen mit höherem Risiko werden genauer geprüft. Dieses Attribut ist zentral für das Dashboard 'Change Risk Profile Analysis'. Es hilft Beteiligten, das Gesamtrisiko des Änderungsportfolios einzuschätzen. Außerdem lassen sich damit Schleifen erkennen, in denen unzureichende erste Risikobewertungen später eine erneute Prüfung erforderlich machen.
Warum das wichtig ist
Das Attribut ist eine wichtige Dimension für die Analyse von Prozesseinhaltung und Effizienz. Es hilft sicherzustellen, dass Änderungen mit höherem Risiko angemessen geprüft werden.
Woher beziehen
Zu finden im Feld 'Risk Level' des Formulars 'CHG:Infrastructure Change'.
Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig5 - Planung
|
|||
|
Status
Status
|
Der aktuelle Status oder die aktuelle Phase des Änderungsantrags in seinem Lebenszyklus. | ||
|
Beschreibung
Das Feld 'Status' zeigt den genauen Stand eines Änderungsantrags zu einem bestimmten Zeitpunkt an, zum Beispiel 'Draft', 'Request For Authorization' oder 'Completed'. Aktivitäten werden aus den Wechseln zwischen diesen Statuswerten abgeleitet. Der Status selbst eignet sich jedoch auch zur Analyse der aktuellen Arbeitslast. Dieses Attribut ist wichtig für das Dashboard 'Change Throughput & Current Status'. Es zeigt, wie viele Änderungen sich in den einzelnen Phasen des Prozesses befinden. So können Verantwortliche laufende Arbeiten und die Ressourcenzuteilung besser einschätzen.
Warum das wichtig ist
Das Attribut zeigt den aktuellen Stand des Änderungsprozesses und ermöglicht die Analyse laufender Arbeiten sowie aller offenen Änderungsanträge.
Woher beziehen
Zu finden im Feld 'Status' des Formulars 'CHG:Infrastructure Change'.
Beispiele
EntwurfAutorisierung angefordertTerminiertUmsetzung läuftAbgeschlossen
|
|||
|
Abschlusscode
CloseCode
|
Ein Code, der das Ergebnis der Änderung zum Zeitpunkt ihres Abschlusses angibt. | ||
|
Beschreibung
Der Abschlusscode gibt den Grund für den Abschluss eines Änderungsantrags in standardisierter Form an, zum Beispiel „Erfolgreich“, „Erfolgreich mit Problemen“, „Zurückgenommen“ oder „Abgebrochen“. Dieses Attribut beschreibt das Ergebnis der Änderung genauer als der abschließende Status allein. Die Analyse der Abschlusscodes kann Aufschluss über die Qualität und Erfolgsquote umgesetzter Änderungen geben. Eine hohe Zahl zurückgenommener Änderungen kann beispielsweise auf Probleme bei der Planung oder beim Testen hindeuten. Damit liefert das Attribut eine wertvolle Kennzahl für die Prozessverbesserung.
Warum das wichtig ist
Das Attribut liefert für jede Änderung ein klares, strukturiertes Ergebnis. So lassen sich Erfolgsquoten sowie Gründe für Fehlschläge oder Abbrüche analysieren.
Woher beziehen
Zu finden im Feld „Status Reason“ oder einem ähnlichen Feld für den Abschlusscode des Formulars „CHG:Infrastructure Change“. Das Feld wird in den letzten Phasen aktiv.
Beispiele
ErfolgreichErfolgreich mit ProblemenZurückgenommenAbgebrochen
|
|||
|
Antragsteller der Änderung
ChangeSubmitter
|
Die Person, die den Änderungsantrag erstellt und eingereicht hat. | ||
|
Beschreibung
Dieses Attribut gibt an, wer den Änderungsantrag eingeleitet hat. Im System wird diese Person üblicherweise als „Submitter“ oder „Reported By“ erfasst. Auch wenn dieses Attribut nicht immer eine zentrale Analysedimension ist, kann es Aufschluss darüber geben, woher Änderungsanträge kommen. Eine Analyse, ob die meisten Änderungen aus bestimmten Abteilungen oder von bestimmten Rollen ausgehen, kann beispielsweise Erkenntnisse über den Geschäftsbedarf und die Planungsprozesse liefern.
Warum das wichtig ist
Damit lässt sich feststellen, wer Änderungsanträge eingereicht hat. Diese Information kann zur Analyse von Nachfragemustern und des Benutzerverhaltens im Prozess dienen.
Woher beziehen
Zu finden im Feld „Submitter“ des Formulars „CHG:Infrastructure Change“.
Beispiele
Allen AllbrookMary MannBob Baxter
|
|||
|
Auswirkungen
Impact
|
Die bewerteten Auswirkungen der Änderung auf Geschäftsservices und die IT-Infrastruktur. | ||
|
Beschreibung
Die Auswirkungen geben an, welche Folgen eine Änderung für den Geschäftsbetrieb, Services und Benutzer haben kann. Zusammen mit der Dringlichkeit sind sie ein wichtiger Faktor für die Priorität des Änderungsantrags. In der Analyse dient dieses Attribut im Dashboard 'Change Risk Profile Analysis' dazu, die möglichen geschäftlichen Folgen des Änderungsportfolios umfassend darzustellen. Die Verteilung von Änderungen mit großen Auswirkungen kann in die Risikostrategie und Ressourcenplanung einfließen.
Warum das wichtig ist
Das Attribut hilft, die möglichen geschäftlichen Folgen von Änderungen einzuschätzen. So lassen sich Risiken analysieren und Prioritäten danach setzen, wie stark Services beeinträchtigt werden könnten.
Woher beziehen
Zu finden im Feld 'Impact' des Formulars 'CHG:Infrastructure Change'.
Beispiele
1 - Umfassend/Weitreichend2 - Erheblich/Groß3 - Mäßig/Begrenzt4 - Gering/Lokal
|
|||
|
Betroffener Service
AffectedService
|
Der geschäftliche oder technische Service, der von der Änderung betroffen ist. | ||
|
Beschreibung
Dieses Attribut verknüpft den Änderungsantrag mit einem bestimmten Service aus der Configuration Management Database (CMDB). Dabei kann es sich um einen nutzerorientierten Geschäftsservice wie „E-Mail-Dienste“ oder einen technischen Backend-Service wie „Authentifizierungsdienst“ handeln. Im Dashboard „Umfang und Auswirkungen von Notfalländerungen“ werden Änderungen den betroffenen Services zugeordnet. So lässt sich die Stabilität verschiedener Services beurteilen und feststellen, bei welchen häufig Notfalleingriffe erforderlich sind.
Warum das wichtig ist
Das Attribut liefert wichtigen geschäftlichen Kontext: Es verknüpft technische Änderungen mit ihren Auswirkungen auf Geschäftsservices und ermöglicht eine servicebezogene Prozessanalyse.
Woher beziehen
Die Daten stammen aus dem Feld „ServiceCI“ oder aus verknüpften Configuration Items (CIs) im Formular „CHG:Infrastructure Change“.
Beispiele
Unternehmens-E-MailSAP ERPKundenbeziehungsmanagementOnline-Banking-Portal
|
|||
|
Dringlichkeit
Urgency
|
Die Dringlichkeit der Änderung, die angibt, wie zeitkritisch ihre Umsetzung ist. | ||
|
Beschreibung
Die Dringlichkeit gibt an, wie schnell eine Änderung umgesetzt werden muss. Zusammen mit den Auswirkungen ist sie ein wichtiger Faktor für die Gesamtpriorität des Änderungsantrags. Dieses Attribut ist wichtig für das Dashboard 'Change Risk Profile Analysis', da es den Zeitdruck im Änderungsmanagement sichtbar macht. Die Analyse von Dringlichkeitstrends kann helfen, grundlegende Ursachen für eine hohe Zahl zeitkritischer Anträge zu erkennen.
Warum das wichtig ist
Das Attribut zeigt, wie zeitkritisch Änderungen sind. So lässt sich analysieren, ob der Prozess Anträge mit unterschiedlicher Dringlichkeit angemessen bearbeitet.
Woher beziehen
Zu finden im Feld 'Urgency' des Formulars 'CHG:Infrastructure Change'.
Beispiele
1 - Kritisch2 - Hoch3-Mittel4-Niedrig
|
|||
|
Endzeit
EventEndTime
|
Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis abgeschlossen wurde. | ||
|
Beschreibung
Die Endzeit kennzeichnet den Abschluss einer Aktivität. Im Process Mining wird sie häufig als Startzeit der nächsten Aktivität im Case berechnet. So lässt sich die Dauer des vorherigen Schritts bestimmen. Bei der letzten Aktivität eines Case kann sie der Startzeit entsprechen oder einem bestimmten Abschluss-Timestamp. Dieses Attribut ist wichtig, um die
Warum das wichtig ist
Damit lassen sich Aktivitätsdauern genau berechnen. Das ist entscheidend, um Engpässe zu erkennen und die Prozessleistung zu messen.
Woher beziehen
Dieses berechnete Attribut wird in der Regel bei der Datentransformation ermittelt, indem für einen Case die Startzeit des nächsten Ereignisses in der Abfolge herangezogen wird.
Beispiele
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
|
|||
|
Ist Nacharbeit
IsRework
|
Eine Kennzeichnung dafür, ob eine Aktivität eine Nacharbeitsschleife oder einen Rückschritt im Prozess darstellt. | ||
|
Beschreibung
Dieses boolesche Attribut wird auf „true“ gesetzt, wenn ein Änderungsantrag in eine frühere Phase seines Lebenszyklus zurückkehrt, zum Beispiel von „Geplant“ zur „Risikobewertung“. Solche Rückschritte bedeuten Nacharbeit und sind häufig eine Ursache für Ineffizienz. Die Kennzeichnung dient zur Berechnung der KPI „Nacharbeitsquote bei Änderungen“ und unterstützt das Dashboard „Nacharbeit bei Änderungen und Effizienz der Bewertung“. Sie hilft, die Häufigkeit von Nacharbeit zu messen und die Prozessschritte zu ermitteln, in denen sie besonders oft auftritt. So werden Bereiche sichtbar, in denen sich die anfängliche Planung und Bewertung verbessern lassen.
Warum das wichtig ist
Die Kennzeichnung macht Prozessineffizienzen direkt sichtbar, indem sie Aktivitäten in Nacharbeitsschleifen markiert. So können Verbesserungsmaßnahmen gezielt ansetzen.
Woher beziehen
Dieses Attribut wird berechnet, indem die Aktivitätsfolge eines Cases analysiert wird. Bei der Datentransformation erkennt eine Logik Rückschritte im Prozessablauf.
Beispiele
truefalse
|
|||
|
Ist Notfalländerung
IsEmergencyChange
|
Ein boolesches Kennzeichen, das den Wert „true“ hat, wenn die Änderung vom Typ „Notfall“ ist. | ||
|
Beschreibung
Dieses abgeleitete Kennzeichen vereinfacht die Analyse, indem es Notfalländerungen eindeutig markiert. Es basiert auf dem Wert des Attributs „ChangeType“. Das Attribut unterstützt vor allem das Dashboard „Umfang und Auswirkungen von Notfalländerungen“ sowie die KPI „Anteil der Notfalländerungen“. Damit lassen sich Daten zu Notfalländerungen einfach filtern und aggregieren. So können Häufigkeit und zeitliche Entwicklung ohne komplexe Filterlogik im Analysetool verfolgt werden.
Warum das wichtig ist
Das Attribut vereinfacht die Analyse von Notfalländerungen. Es erleichtert das Filtern, die Darstellung in Dashboards und die Berechnung von KPIs zu diesem wichtigen Änderungstyp.
Woher beziehen
Dieses abgeleitete Attribut wird bei der Datentransformation erstellt. Die Logik lautet: IF 'ChangeType' = 'Emergency' THEN true ELSE false.
Beispiele
truefalse
|
|||
|
SLA-Status
SLAState
|
Der berechnete Status des Änderungsantrags im Verhältnis zum SLA-Ziel. | ||
|
Beschreibung
Dieses Attribut gibt an, ob ein abgeschlossener Änderungsantrag die Vorgaben seines Service Level Agreement (SLA) erfüllt hat, gefährdet war, sie zu verfehlen, oder sie verfehlt hat. Der Status wird berechnet, indem der tatsächliche Abschlusszeitpunkt mit dem „SLATargetDate“ verglichen wird. Das Attribut ist die zentrale Kennzahl für das Dashboard „SLA-Leistung bei Änderungen“. Es zeigt übersichtlich, ob die vereinbarten Service-Level eingehalten wurden. Die Daten lassen sich nach Priorität, Änderungstyp oder Team aufschlüsseln, um Bereiche mit geringer SLA-Einhaltung zu ermitteln.
Warum das wichtig ist
Das Attribut misst direkt, ob vereinbarte Ziele erreicht wurden. Damit ist es ein wichtiger Indikator für Prozesseffizienz und Servicequalität.
Woher beziehen
Dieses Attribut wird bei der Datentransformation berechnet, indem der Timestamp der letzten Aktivität mit dem „SLATargetDate“ verglichen wird.
Beispiele
FristgerechtGefährdetVerfehlt
|
|||
|
SLA-Zieldatum
SLATargetDate
|
Das Datum und die Uhrzeit, bis zu denen der Änderungsantrag abgeschlossen sein soll. | ||
|
Beschreibung
Das SLA-Zieldatum (Service Level Agreement) ist die Frist für den Abschluss des Änderungsantrags. Sie richtet sich nach dessen Priorität und Typ. Anhand dieser Frist wird die tatsächliche Abschlusszeit gemessen. Dieses Attribut ist eine zentrale Grundlage für das Dashboard „SLA-Leistung bei Änderungen“. Durch den Vergleich der tatsächlichen Abschlusszeit mit dem Ziel lässt sich feststellen, ob die Änderung die SLA-Vorgaben erfüllt hat. Die Analyse der SLA-Leistung zeigt, wie effizient der Prozess insgesamt ist und ob die vereinbarten Service-Level eingehalten werden.
Warum das wichtig ist
Das Attribut dient als Vergleichsmaßstab für die Leistung. Damit lassen sich die SLA-Einhaltungsquote berechnen und gefährdete Änderungen erkennen.
Woher beziehen
Diese Information wird üblicherweise in zugehörigen SLA-Verwaltungsformularen gespeichert und mit dem Änderungsantrag verknüpft. Häufig ist sie direkt im Änderungsformular sichtbar.
Beispiele
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
|
|||
|
Zugehörige Incident-ID
RelatedIncidentID
|
Die Kennung eines Incidents, der durch diese Änderung verursacht wurde. | ||
|
Beschreibung
Dieses Attribut verknüpft einen Änderungsantrag mit nachfolgenden Incidents, die möglicherweise durch die Änderung verursacht wurden. Dieser Zusammenhang ist wichtig, um die Auswirkungen von Änderungen auf die Stabilität von Services zu verstehen. Das Attribut ist die wichtigste Grundlage für die Berechnung der KPI „Durch Änderungen verursachte Incident-Rate“. Anhand dieser Verknüpfungen kann ein Unternehmen die Qualität seines Änderungsprozesses messen und Änderungen, Teams oder Services ermitteln, bei denen nach der Implementierung häufiger Probleme auftreten.
Warum das wichtig ist
Das Attribut misst direkt die negativen Auswirkungen von Änderungen. Damit ist es eine wichtige KPI zur Bewertung der Änderungsqualität und der Wirksamkeit des Risikomanagements.
Woher beziehen
Diese Verknüpfung wird üblicherweise im Incident-Formular („HPD:Help Desk“) hergestellt. Dort kann ein Incident mit dem Änderungsantrag verknüpft werden, der ihn verursacht hat.
Beispiele
INC000000987654INC000000987655INC000000987656
|
|||
Aktivitäten im Change Management
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Änderung abgeschlossen
|
Dies ist die letzte Aktivität und kennzeichnet den formellen Abschluss des Änderungsantrags im System. Das Ereignis wird erfasst, wenn der Status des Antrags auf 'Closed' gesetzt wird. | ||
|
Warum das wichtig ist
Diese Aktivität markiert das erfolgreiche Ende des Änderungsprozesses. Sie ist wichtig, um die Gesamtdauer des Prozesses und den Gesamtdurchsatz zu messen.
Woher beziehen
Abgeleitet aus dem Statusänderungsverlauf im Formular CHG:Change, wenn der Status zu 'Closed' wechselt.
Erfassung
Ermitteln Sie den Timestamp, zu dem das Feld 'Status' in CHG:Change auf 'Closed' gesetzt wird.
Ereignistyp
inferred
|
|||
|
Änderung terminiert
|
Diese Aktivität kennzeichnet den Zeitpunkt, zu dem die freigegebene Änderung offiziell zur Umsetzung eingeplant wird. Das Ereignis wird anhand der Statusänderung zu 'Scheduled' im System erfasst. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein zeigt an, dass die Änderung zur Umsetzung bereit ist. Ab hier lassen sich die Umsetzungszykluszeit und die durchschnittliche Wartezeit bis zur Umsetzung messen.
Woher beziehen
Abgeleitet aus dem Statusänderungsverlauf im Formular CHG:Change, wenn der Status zu 'Scheduled' wechselt.
Erfassung
Ermitteln Sie den Timestamp, zu dem das Feld 'Status' in CHG:Change auf 'Scheduled' gesetzt wird.
Ereignistyp
inferred
|
|||
|
Änderung umgesetzt
|
Diese Aktivität kennzeichnet den erfolgreichen Abschluss der Umsetzungsarbeiten. Sie wird in der Regel erfasst, wenn der Status auf 'Completed' gesetzt und als Grund ein erfolgreicher Abschluss angegeben wird. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein markiert das Ende der Bereitstellungsphase. Er ist entscheidend, um die Umsetzungszykluszeit zu berechnen und Vorfälle infolge von Änderungen zu analysieren.
Woher beziehen
Abgeleitet aus dem Formular CHG:Change, wenn 'Status' auf 'Completed' und 'Status Reason' auf 'Successful' gesetzt ist.
Erfassung
Ermitteln Sie den Timestamp, zu dem das Feld 'Status' in CHG:Change auf 'Completed' gesetzt wird.
Ereignistyp
inferred
|
|||
|
Änderungsantrag erstellt
|
Diese Aktivität kennzeichnet die erstmalige Erstellung eines Änderungsantrags im System. Das Ereignis wird anhand des Erstellungs-Timestamps des Eintrags im Formular CHG:Change erfasst. | ||
|
Warum das wichtig ist
Hier beginnt jeder Änderungsantrag. Dieser Zeitpunkt ist entscheidend, um die Gesamtdauer des Prozesses zu messen und das Volumen eingehender Änderungen zu analysieren.
Woher beziehen
Dieses Ereignis wird anhand des Felds 'Submit Date' oder des Erstellungs-Timestamps im Audit Log des Formulars CHG:Change erfasst, zum Beispiel im HPD:Help Desk Audit Log.
Erfassung
Verwenden Sie den Erstellungs-Timestamp aus dem Formular CHG:Change.
Ereignistyp
explicit
|
|||
|
Änderungsantrag freigegeben
|
Ein wichtiger Meilenstein: Der Änderungsantrag erhält die formelle Freigabe zur Umsetzung. Das Ereignis wird aus einer Statusänderung abgeleitet, in der Regel zu 'Scheduled' oder 'Planning In Progress' nach der abschließenden Autorisierung. | ||
|
Warum das wichtig ist
Damit endet die Freigabephase. Dieser Schritt ist entscheidend, um Engpässe bei der Freigabe und die durchschnittliche Freigabedauer von Änderungen zu messen. Zugleich ist er ein wichtiger Entscheidungspunkt im Prozess.
Woher beziehen
Abgeleitet aus dem Statusänderungsverlauf im Formular CHG:Change, insbesondere wenn der Antrag einen Freigabestatus wie 'Request For Authorization' verlässt.
Erfassung
Ermitteln Sie den Timestamp, zu dem das Feld 'Status' in CHG:Change die abschließende Freigabephase verlässt, zum Beispiel mit dem Wechsel zu 'Scheduled'.
Ereignistyp
inferred
|
|||
|
Risikobewertung durchgeführt
|
Diese Aktivität kennzeichnet den Abschluss der Risikobewertung für die geplante Änderung. Sie wird häufig erfasst, wenn der Status des Änderungsantrags aktualisiert oder eine bestimmte Aufgabe zur Risikobewertung abgeschlossen wird. | ||
|
Warum das wichtig ist
Die Erfassung dieser Aktivität ist wichtig, um die Einhaltung der Richtlinien für das Änderungsmanagement sicherzustellen. Sie hilft, Verzögerungen in der Bewertungsphase zu erkennen und die Nacharbeitsquote bei Änderungen zu analysieren, wenn der Prozess zu diesem Schritt zurückkehrt.
Woher beziehen
Abgeleitet aus einer Statusänderung im Formular CHG:Change, zum Beispiel dem Wechsel zu 'Request For Change', oder aus dem Abschluss einer zugehörigen Aufgabe im Formular CHG:Task.
Erfassung
Ermitteln Sie den Timestamp, zu dem eine verknüpfte Aufgabe 'Risk Assessment' in CHG:Task als 'Closed' oder 'Completed' markiert wird.
Ereignistyp
inferred
|
|||
|
Tests durchgeführt
|
Kennzeichnet den Abschluss der Tests oder Validierung nach der Umsetzung. Dieser Schritt wird häufig durch den Abschluss einer eigens dafür vorgesehenen Aufgabe erfasst, die mit dem Änderungsantrag verknüpft ist. | ||
|
Warum das wichtig ist
Die Erfassung dieser Aktivität ist wichtig, um die durchschnittliche Testzykluszeit zu messen und die Qualität sicherzustellen. Sie hilft, Engpässe im Validierungsprozess vor der abschließenden Überprüfung zu erkennen.
Woher beziehen
Abgeleitet aus dem Abschluss eines Testaufgabeneintrags im Formular CHG:Task, der mit dem übergeordneten Änderungsantrag verknüpft ist.
Erfassung
Ermitteln Sie den Timestamp, zu dem eine verknüpfte Aufgabe 'Testing' oder 'Validation' in CHG:Task als 'Closed' oder 'Completed' markiert wird.
Ereignistyp
inferred
|
|||
|
Änderung abgebrochen
|
Kennzeichnet den Abbruch eines Änderungsantrags vor seiner Umsetzung oder seinem Abschluss. Er wird erfasst, wenn der Status des Antrags auf 'Cancelled' gesetzt wird. | ||
|
Warum das wichtig ist
Die Erfassung von Abbrüchen zeigt, warum Änderungen zurückgezogen werden. So lassen sich etwa eine unzureichende Erstplanung, geänderte Prioritäten oder fehlende Ressourcen erkennen.
Woher beziehen
Abgeleitet aus dem Statusänderungsverlauf im Formular CHG:Change, wenn der Status zu 'Cancelled' wechselt.
Erfassung
Ermitteln Sie den Timestamp, zu dem das Feld 'Status' in CHG:Change auf 'Cancelled' gesetzt wird.
Ereignistyp
inferred
|
|||
|
Änderung überprüft
|
Diese Aktivität zeigt an, dass Beteiligte nach der Umsetzung und den Tests formell bestätigt haben, dass die Änderung erfolgreich war. Sie wird häufig durch eine Statusänderung vor dem endgültigen Abschluss erfasst. | ||
|
Warum das wichtig ist
Die Überprüfung ist die letzte Qualitätskontrolle vor dem Abschluss einer Änderung. Sie bestätigt, dass die Änderung ihre Ziele erreicht und keine unbeabsichtigten negativen Auswirkungen verursacht hat.
Woher beziehen
Abgeleitet aus einer Statusänderung im Formular CHG:Change, zum Beispiel dem Wechsel von 'Completed' zu 'Verification' oder 'Closed'.
Erfassung
Ermitteln Sie den Timestamp, zu dem das Feld 'Status' in CHG:Change nach den Umsetzungsaktivitäten zu 'Closed' wechselt.
Ereignistyp
inferred
|
|||
|
Änderungsantrag abgelehnt
|
Diese Aktivität kennzeichnet die formelle Ablehnung des Änderungsantrags durch eine freigabeberechtigte Person. Sie wird durch eine Statusänderung zu 'Rejected' erfasst und stellt einen Endzustand dar. | ||
|
Warum das wichtig ist
Die Erfassung von Ablehnungen hilft, Gründe wie unvollständige Angaben oder ein hohes Risiko zu erkennen. Diese Analyse kann die Qualität künftiger Änderungsanträge verbessern.
Woher beziehen
Abgeleitet aus dem Statusänderungsverlauf im Formular CHG:Change, insbesondere aus dem Wechsel zum Status 'Rejected'.
Erfassung
Ermitteln Sie den Timestamp, zu dem das Feld 'Status' in CHG:Change auf 'Rejected' gesetzt wird.
Ereignistyp
inferred
|
|||
|
Änderungsantrag eingereicht
|
Kennzeichnet die formelle Einreichung eines Änderungsantrags zur Prüfung und Freigabe. In der Regel lässt sich dieser Schritt daran erkennen, dass sich der Status des Antrags von 'Draft' zu 'Request For Authorization' ändert. | ||
|
Warum das wichtig ist
Mit dieser Aktivität beginnt der Freigabeprozess. Ihre Erfassung ist wichtig, um die Wartezeit bis zur ersten Prüfung zu messen und die Kennzahl zur Freigabedauer von Änderungen auszuwerten.
Woher beziehen
Abgeleitet aus dem Statusänderungsverlauf des Änderungsantrags im Formular CHG:Change, insbesondere aus dem Wechsel zu 'Request For Authorization'.
Erfassung
Ermitteln Sie den Timestamp, zu dem sich das Feld 'Status' in CHG:Change von 'Draft' zu 'Request For Authorization' ändert.
Ereignistyp
inferred
|
|||
|
Auswirkungsanalyse durchgeführt
|
Kennzeichnet den Abschluss der Auswirkungsanalyse, mit der die möglichen Folgen einer Änderung ermittelt werden. Dieser Schritt lässt sich in der Regel aus einer Statusaktualisierung oder dem Abschluss einer zugehörigen Aufgabe ableiten. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig, um die Effizienz der Planung und ihre Auswirkungen auf Nacharbeiten zu verstehen. Die Analyse ihrer Dauer und Häufigkeit hilft, die erste Bewertungsphase zu verbessern.
Woher beziehen
Abgeleitet aus dem Abschluss-Timestamp einer Aufgabe 'Impact Analysis' im Formular CHG:Task oder aus einem bestimmten Statuswechsel im Formular CHG:Change.
Erfassung
Ermitteln Sie den Timestamp, zu dem eine verknüpfte Aufgabe 'Impact Analysis' in CHG:Task als 'Closed' oder 'Completed' markiert wird.
Ereignistyp
inferred
|
|||
|
Überprüfung nach der Umsetzung
|
Kennzeichnet den Abschluss einer formellen Überprüfung nach der Umsetzung der Änderung. Diese Aktivität wird in der Regel anhand des Abschlusses einer Aufgabe zur Überprüfung nach der Umsetzung (PIR) erfasst. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig, damit die Organisation aus Erfahrungen lernt und Prozesse verbessert. Die Kennzahl zur Überprüfungsquote nach der Umsetzung zeigt, ob Erkenntnisse aus Änderungen gewonnen werden.
Woher beziehen
Abgeleitet aus dem Abschluss einer Aufgabe 'Post-Implementation Review' im Formular CHG:Task, die mit dem übergeordneten Änderungsantrag verknüpft ist.
Erfassung
Ermitteln Sie den Timestamp, zu dem eine verknüpfte Aufgabe 'PIR' in CHG:Task als 'Closed' oder 'Completed' markiert wird.
Ereignistyp
inferred
|
|||
|
Umsetzungsplan erstellt
|
Kennzeichnet, dass der detaillierte Plan zur Umsetzung der Änderung erstellt und dokumentiert wurde. Dieser Schritt wird in der Regel erfasst, wenn eine zugehörige Planungsaufgabe abgeschlossen ist. | ||
|
Warum das wichtig ist
Der Abschluss dieser Aktivität ist Voraussetzung für die Terminplanung und Umsetzung. Ihre Dauer zeigt, ob es vor der Umsetzung zu Verzögerungen in der Planungsphase kommt.
Woher beziehen
Abgeleitet aus dem Abschluss eines bestimmten Planungseintrags im Formular CHG:Task, der mit dem übergeordneten Änderungsantrag verknüpft ist.
Erfassung
Ermitteln Sie den Timestamp, zu dem eine verknüpfte Aufgabe 'Implementation Planning' in CHG:Task als 'Closed' oder 'Completed' markiert wird.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Bereiten Sie Ihre Daten noch heute mit diesem Template vor und beginnen Sie, Ihren Change-Management-Prozess zu optimieren. Gewinnen Sie wertvolle Erkenntnisse und steigern Sie die Effizienz Ihrer Abläufe.
Optimieren Sie jetzt Ihr Change Management und vermeiden Sie Störungen
Steigern Sie Ihre Erfolgsquote bei Changes auf 95 % und vermeiden Sie kostspielige Serviceunterbrechungen.
Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.