Ihr Daten-Template für Change Management

BMC Helix ITSM
Ihr Daten-Template für Change Management

Ihr Daten-Template für Change Management

Dieses Template bietet eine strukturierte Anleitung, mit der Sie die wichtigsten Daten für die Analyse Ihres Change-Management-Prozesses erfassen. Es enthält empfohlene Attribute, zentrale Aktivitäten für die Nachverfolgung und praktische Hinweise dazu, wie Sie diese Informationen direkt aus Ihren Systemen extrahieren. So schaffen Sie eine fundierte Grundlage für Ihr Process-Mining-Vorhaben.
  • 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
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute des Change Managements

Diese empfohlenen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihr Change Management umfassend zu analysieren und detaillierte Erkenntnisse über den Prozess zu gewinnen.
5 Erforderlich 6 Empfohlen 11 Optional
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 ProcessingTime jeder Aktivität zu berechnen. Diese Kennzahl bildet eine Grundlage für die Leistungsanalyse und das Erkennen von Engpässen. Sie ermöglicht eine detaillierte Auswertung der Dauer einzelner Schritte.

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
Erforderlich Empfohlen Optional

Aktivitäten im Change Management

Diese zentralen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess präzise zu entdecken und Engpässe gezielt zu identifizieren.
7 Empfohlen 7 Optional
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
Empfohlen Optional

Anleitungen zur Datenextraktion

So extrahieren Sie Ihre Daten aus BMC Helix ITSM

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.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.