Ihr Daten-Template für das Änderungsmanagement

BMC Helix ITSM
Ihr Daten-Template für das Änderungsmanagement

Ihr Daten-Template für das Änderungsmanagement

Dieses Template bietet eine strukturierte Anleitung zur Erfassung der wesentlichen Daten für die Analyse Ihres Änderungsmanagementprozesses. Sie finden darin empfohlene Attribute, wichtige zu verfolgende Aktivitäten sowie praktische Hinweise zur direkten Extraktion dieser Informationen aus Ihren Systemen. Verwenden Sie diese Ressource, um eine umfassende und wirksame Process-Mining-Initiative sicherzustellen.
  • Empfohlene Attribute für eine gründliche Analyse
  • Wichtige Aktivitäten und Meilensteine, die Sie in Ihrem Prozess verfolgen sollten
  • Konkrete Hinweise zur Extraktion aus relevanten Quellsystemen
Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Attribute des Change Managements

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse des Change Managements in Ihr Event Log aufnehmen sollten. Sie ermöglichen tiefgehende Erkenntnisse über Ihren Prozess.
5 Erforderlich 6 Empfohlen 11 Optional
Name Beschreibung
Aktivität
ActivityName
Der Name des konkreten Ereignisses oder Tasks, der innerhalb des Änderungsmanagementprozesses ausgeführt wird.
Beschreibung

Dieses Attribut steht für einen einzelnen Schritt oder eine Statusänderung im Lebenszyklus eines Änderungsantrags, beispielsweise „Change Request Submitted“ oder „Change Request Approved“. Diese Aktivitäten bilden die Bausteine der Prozesslandkarte.

Die Analyse der Reihenfolge und Dauer dieser Aktivitäten hilft, den Prozessfluss zu erkennen, Abweichungen vom Standardverfahren aufzudecken und Engpässe zu lokalisieren. Die Aktivitätsnamen werden typischerweise aus Statusübergängen abgeleitet, die in den Audit Logs des Systems aufgezeichnet sind.

Warum das wichtig ist

Es definiert die Prozessschritte und ermöglicht die Visualisierung und Analyse des Prozessflusses, der den Kern von Process Mining bildet.

Bezugsquelle

Abgeleitet aus Statusübergängen im Formular „CHG:ChangeRequest_AuditLog“ oder durch die Nachverfolgung von Änderungen am Feld „Status“ im Formular „CHG:Infrastructure Change“.

Beispiele
Change Request eingereichtRisikobewertung durchgeführtChange Request genehmigtÄnderung implementiert
Änderungsanfrage-ID
ChangeRequestID
Die eindeutige, vom System generierte Kennung eines Änderungsantrags, die als primäre Case-Kennung dient.
Beschreibung

Die Change Request ID ist der eindeutige Schlüssel, der jede Änderungsinitiative über ihren gesamten Lebenszyklus hinweg identifiziert. Sie bündelt alle zugehörigen Aktivitäten, Genehmigungen und Tasks und bildet die Grundlage für einen einzelnen Case im Process Mining.

Die Analyse von Prozessen anhand dieser ID ermöglicht eine End-to-End-Sicht darauf, wie Änderungen verwaltet werden, vom ersten Antrag bis zum endgültigen Abschluss. Das ist entscheidend, um Durchlaufzeiten zu verfolgen, Engpässe zu erkennen und Prozessvarianten einzelner Änderungen zu verstehen.

Warum das wichtig ist

Dies ist das grundlegende Attribut, das alle zugehörigen Ereignisse zu einer einzelnen Prozessinstanz verbindet und dadurch die End-to-End-Analyse des Änderungsmanagementprozesses ermöglicht.

Bezugsquelle

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 das genaue Datum und die genaue Uhrzeit, zu der eine Aktivität stattgefunden hat. Beispielsweise wird damit erfasst, wann eine Änderung eingereicht, genehmigt oder geschlossen wurde.

Dieser Timestamp ist für die Analyse des Prozessverlaufs entscheidend. Er dient dazu, Durchlaufzeiten zwischen Aktivitäten zu berechnen, Wartezeiten zu messen, Leistungstrends im Zeitverlauf zu erkennen und die Reihenfolge der Ereignisse zu bestimmen. Präzise Timestamps bilden die Grundlage jeder zeitbezogenen Prozessanalyse.

Warum das wichtig ist

Es liefert die zeitliche Dimension, die zum Berechnen von Dauern, Analysieren der Leistung und Verstehen der Ereignisreihenfolge im Prozess erforderlich ist.

Bezugsquelle

Quelle ist das Feld „Audit Date“ im Formular „CHG:ChangeRequest_AuditLog“ oder das mit bestimmten Statusänderungen verknüpfte Feld „Last Modified Date“.

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 an, zu denen die Daten zuletzt aus BMC Helix ITSM extrahiert wurden. Es bezeichnet nicht den Zeitpunkt des Ereignisses selbst, sondern den Zeitpunkt des Datenabrufs. Diese Information ist wichtig, um die Aktualität der analysierten Daten zu beurteilen und Aktualisierungszyklen zu verwalten.

In Dashboards und Berichten zeigt dieser Timestamp, wie aktuell die Analyse ist. Das ist besonders wichtig bei der Überwachung laufender Prozesse.

Warum das wichtig ist

Es zeigt die Aktualität der Daten an. Das ist entscheidend, damit Analysen und Dashboards den aktuellen Zustand des Prozesses abbilden.

Bezugsquelle

Dies ist ein Metadatenfeld, das typischerweise vom ETL-Tool oder der Datenpipeline zum Zeitpunkt der Datenextraktion erzeugt und befüllt wird.

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 identifiziert die Herkunft der Prozessdaten, in diesem Fall „BMC Helix ITSM“. Es unterstützt Data Governance und Nachvollziehbarkeit, insbesondere in Umgebungen, in denen Daten aus mehreren Systemen für eine umfassendere Analyse zusammengeführt werden.

Wenn Änderungsdaten beispielsweise später mit Daten aus einem Finanz- oder Projektmanagementsystem zusammengeführt werden, sorgt dieses Feld für eine klare Unterscheidung der Datenquellen.

Warum das wichtig ist

Es liefert wichtigen Kontext zur Datenherkunft und stellt die Nachvollziehbarkeit sowie die korrekte Interpretation der Daten sicher, insbesondere bei Analysen über mehrere Systeme hinweg.

Bezugsquelle

Dabei handelt es sich typischerweise um einen statischen Wert, der während des ETL-Prozesses zur Kennzeichnung der Herkunft des Datensatzes hinzugefügt wird.

Beispiele
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
Änderungstyp
ChangeType
Die Klassifizierung der Änderung, beispielsweise Standard, Normal oder Emergency.
Beschreibung

Dieses Attribut kategorisiert den Änderungsantrag anhand seiner Art und des dafür vorgesehenen Prozesses. Zu den gängigen Typen gehören Standard (vorab genehmigt, geringes Risiko), Normal (erfordert eine vollständige Bewertung und Genehmigung) und Emergency (erfordert aufgrund eines dringenden Problems eine beschleunigte Bearbeitung).

Die Analyse nach Change Type ist entscheidend, um Prozessvarianten zu verstehen. Das Dashboard „Emergency Change Volume & Impact“ verwendet dieses Feld beispielsweise, um dringende Änderungen und ihre Auswirkungen auf die Servicestabilität zu verfolgen. Außerdem lässt sich damit prüfen, ob die verschiedenen Änderungstypen ihre vorgesehenen Prozesspfade einhalten.

Warum das wichtig ist

Es ermöglicht die Segmentierung des Prozesses, um verschiedene Change Workflows zu analysieren und zu vergleichen. Das ist für Compliance- und Leistungsanalysen entscheidend.

Bezugsquelle

Zu finden im Feld „Change Type“ des Formulars „CHG:Infrastructure Change“.

Beispiele
StandardNormalNotfallKeine Auswirkungen
Genehmigergruppe
ApproverGroup
Das Team oder die Gruppe, die in einer bestimmten Phase für die Genehmigung eines Änderungsantrags verantwortlich ist.
Beschreibung

Dieses Attribut identifiziert die Gruppe, die mit der Prüfung und Genehmigung einer Änderung beauftragt ist. Da eine Änderung mehrere Genehmigungsphasen durchlaufen kann, können im Lebenszyklus unterschiedliche Gruppen zuständig sein, beispielsweise ein technisches Genehmigungsteam und ein Business-Gremium.

Dieses Attribut ist für das Dashboard „Change Approval Bottlenecks“ besonders wichtig, da sich Genehmigungszeiten nach der verantwortlichen Gruppe segmentieren lassen. So können bestimmte Teams erkannt werden, die überlastet oder ineffizient sind und dadurch Verzögerungen im Prozess verursachen.

Warum das wichtig ist

Es ermöglicht die Erkennung von Engpässen im Genehmigungsprozess, indem Genehmigungsdauern nach dem jeweils verantwortlichen Team analysiert werden.

Bezugsquelle

Quelle ist das Formular „AP:Signature“, in dem Genehmigungen verwaltet werden und das mit dem Änderungsantrag verknüpft ist. Die Gruppe des Genehmigenden ist Bestandteil dieses Datensatzes.

Beispiele
Change Advisory BoardIT-SicherheitNetzwerktechnikAnwendungsentwicklung
Implementierungsteam
ImplementationTeam
Das Team, das für die Durchführung der Implementierung der Änderung verantwortlich ist.
Beschreibung

Dieses Attribut identifiziert die technische oder operative Gruppe, die mit den für den Änderungsantrag erforderlichen Arbeiten beauftragt ist. Während der Implementierungsphasen des Änderungslebenszyklus handelt es sich dabei häufig um die „Assigned Group“.

Diese Information ist für das Dashboard „Resource Bottlenecks in Change Process“ entscheidend. Durch die Analyse von Aktivitätsdauern und Volumen je Implementation Team können Verantwortliche unausgewogene Auslastung, fehlende Kompetenzen oder andere ressourcenbezogene Einschränkungen erkennen, die die Bereitstellung von Änderungen verzögern.

Warum das wichtig ist

Es hilft, ressourcenbezogene Engpässe in der Implementierungsphase zu erkennen, indem die Leistung je verantwortlichem Team analysiert wird.

Bezugsquelle

Zu finden im Feld „ASGRP“ (Assigned Group) des Formulars „CHG:Infrastructure Change“.

Beispiele
ServerbetriebDatenbankadministratorenSAP-Basis-TeamCloud-Infrastruktur
Priorität
Priority
Die dem Änderungsantrag zugewiesene Prioritätsstufe, die seine geschäftliche Bedeutung angibt.
Beschreibung

Die Priority wird typischerweise aus Impact und Urgency abgeleitet und bestimmt Reihenfolge und Geschwindigkeit der Bearbeitung eines Änderungsantrags. Eine Änderung mit höherer Priorität erfordert in der Regel eine schnellere Bearbeitung und kann strengeren Service Level Agreements (SLAs) unterliegen.

Dieses Attribut wird im Dashboard „Change SLA Performance“ verwendet, um die Leistung nach verschiedenen Prioritätsstufen zu segmentieren und zu analysieren. Es hilft bei Fragen wie: „Erfüllen wir unsere SLAs für Änderungen mit hoher Priorität?“ Außerdem unterstützt es Entscheidungen zur Ressourcenverteilung.

Warum das wichtig ist

Es ermöglicht die Leistungsanalyse nach geschäftlicher Bedeutung. Dadurch lassen sich besonders kritische Änderungen effizient bearbeiten und ihre Zielvorgaben einhalten.

Bezugsquelle

Zu finden im Feld „Priority“ des Formulars „CHG:Infrastructure Change“.

Beispiele
KritischHochMittelNiedrig
Risikostufe
RiskLevel
Eine Bewertung des potenziellen Risikos, das mit der Implementierung der Änderung verbunden ist.
Beschreibung

Risk Level ist eine qualitative oder quantitative Bewertung der möglichen negativen Folgen einer Implementierung. Das Attribut ist ein wichtiger Input für den Genehmigungsprozess, in dem Änderungen mit höherem Risiko einer eingehenderen Prüfung unterzogen werden.

Dieses Attribut ist zentral für das Dashboard „Change Risk Profile Analysis“. Es unterstützt Stakeholder dabei, die Gesamtrisikoexposition des Änderungsportfolios zu verstehen. Außerdem lässt es sich verwenden, um Schleifen mit Nacharbeit zu erkennen, bei denen unzureichende anfängliche Risikobewertungen später eine erneute Bewertung erforderlich machen.

Warum das wichtig ist

Es liefert eine wichtige Dimension für die Analyse von Prozesskonformität und Effizienz und trägt dazu bei, dass Änderungen mit höherem Risiko angemessen geprüft werden.

Bezugsquelle

Zu finden im Feld „Risk Level“ des Formulars „CHG:Infrastructure Change“.

Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig5 - Planung
Status
Status
Der aktuelle Zustand oder die aktuelle Phase des Änderungsantrags in seinem Lebenszyklus.
Beschreibung

Das Feld Status zeigt zu einem bestimmten Zeitpunkt die genaue Phase eines Änderungsantrags an, beispielsweise „Draft“, „Request For Authorization“ oder „Completed“. Während Aktivitäten aus Übergängen zwischen diesen Statuswerten abgeleitet werden, eignet sich der Status selbst zur Analyse der aktuellen Arbeitslast.

Dieses Attribut ist für das Dashboard „Change Throughput & Current Status“ entscheidend. Es liefert eine Momentaufnahme der Anzahl von Änderungen in den einzelnen Phasen der Pipeline. So können Verantwortliche laufende Arbeiten und die Ressourcenverteilung besser beurteilen.

Warum das wichtig ist

Es bietet eine aktuelle Sicht auf die Change Pipeline und ermöglicht die Analyse laufender Arbeiten sowie des aktuellen Zustands aller Änderungsanträge.

Bezugsquelle

Zu finden im Feld „Status“ des Formulars „CHG:Infrastructure Change“.

Beispiele
EntwurfAutorisierung angefordertEingeplantImplementierung läuftAbgeschlossen
Abschlusscode
CloseCode
Ein Code, der das endgültige Ergebnis der Änderung zum Zeitpunkt ihres Abschlusses angibt.
Beschreibung

Der Close Code liefert einen standardisierten Grund für den Abschluss eines Änderungsantrags, beispielsweise „Successful“, „Successful with Issues“, „Backed Out“ oder „Cancelled“. Dieses Attribut bietet eine detailliertere Sicht auf das Ergebnis einer Änderung als der abschließende Status allein.

Die Analyse von Close Codes kann helfen, Qualität und Erfolgsquote implementierter Änderungen zu bewerten. Eine hohe Zahl von Änderungen mit dem Status „Backed Out“ kann beispielsweise auf Probleme bei Planung oder Tests hinweisen und eine wichtige Kennzahl für die Prozessverbesserung liefern.

Warum das wichtig ist

Es liefert ein klares, strukturiertes Ergebnis für jede Änderung und ermöglicht die Analyse von Erfolgsquoten sowie von Gründen für Fehler oder Stornierungen.

Bezugsquelle

Zu finden im Feld „Status Reason“ oder in einem vergleichbaren Feld für den Abschlusscode des Formulars „CHG:Infrastructure Change“, das in den letzten Phasen aktiv wird.

Beispiele
ErfolgreichErfolgreich mit ProblemenZurückgesetztAbgebrochen
Auswirkung
Impact
Die bewerteten Auswirkungen der Änderung auf Geschäftsservices und die IT-Infrastruktur.
Beschreibung

Impact misst die möglichen Auswirkungen einer Änderung auf Geschäftsabläufe, Services und Benutzer. Zusammen mit Urgency ist Impact ein entscheidender Faktor für die Bestimmung der Priority des Änderungsantrags.

In der Analyse wird Impact im Dashboard „Change Risk Profile Analysis“ verwendet, um die möglichen geschäftlichen Folgen des Änderungsportfolios umfassend darzustellen. Die Verteilung von Änderungen mit hoher Auswirkung kann die Entwicklung von Risikomanagementstrategien und die Ressourcenplanung unterstützen.

Warum das wichtig ist

Es hilft, die möglichen geschäftlichen Folgen von Änderungen zu quantifizieren. Dadurch werden Risikoanalyse und Priorisierung danach möglich, wie stark Services beeinträchtigt werden könnten.

Bezugsquelle

Zu finden im Feld „Impact“ des Formulars „CHG:Infrastructure Change“.

Beispiele
1-Umfassend/weitreichend2-Erheblich/groß3-Mittel/begrenzt4-Gering/lokal begrenzt
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 in der Configuration Management Database (CMDB). Dabei kann es sich um einen benutzerorientierten Business Service wie „Email Services“ oder um einen technischen Backend-Service wie „Authentication Service“ handeln.

Im Dashboard „Emergency Change Volume & Impact“ wird es verwendet, um Änderungen mit den betroffenen Services in Beziehung zu setzen. So lässt sich die Stabilität verschiedener Services verstehen und erkennen, bei welchen Services häufige Emergency-Eingriffe erforderlich sind.

Warum das wichtig ist

Es liefert wichtigen geschäftlichen Kontext, verknüpft technische Änderungen mit ihren Auswirkungen auf Business Services und ermöglicht eine serviceorientierte Prozessanalyse.

Bezugsquelle

Quelle ist das Feld „ServiceCI“ oder eine zugehörige Configuration-Item-(CI)-Beziehung im Formular „CHG:Infrastructure Change“.

Beispiele
Unternehmens-E-MailSAP ERPCustomer Relationship ManagementOnline-Banking-Portal
Dringlichkeit
Urgency
Die Dringlichkeit der Änderung, die ihre zeitliche Sensitivität bei der Implementierung widerspiegelt.
Beschreibung

Urgency gibt an, wie schnell eine Änderung implementiert werden muss. Zusammen mit Impact ist sie ein wesentlicher Bestandteil für die Berechnung der Gesamt-Priority des Änderungsantrags.

Urgency ist ein wichtiges Attribut für das Dashboard „Change Risk Profile Analysis“. Es zeigt den Zeitdruck im Änderungsmanagementprozess. Die Analyse von Dringlichkeitstrends kann dabei helfen, zugrunde liegende Probleme zu erkennen, die eine hohe Zahl zeitkritischer Anträge verursachen.

Warum das wichtig ist

Es spiegelt den zeitkritischen Charakter von Änderungen wider und hilft zu analysieren, ob der Prozess Anträge mit unterschiedlicher zeitlicher Sensitivität wirksam bearbeitet.

Bezugsquelle

Zu finden im Feld „Urgency“ des Formulars „CHG:Infrastructure Change“.

Beispiele
1-Kritisch2-Hoch3-Mittel4-Niedrig
Einreicher der Änderung
ChangeSubmitter
Die Person, die den Änderungsantrag erstellt und eingereicht hat.
Beschreibung

Dieses Attribut identifiziert die Person, die den Änderungsantrag initiiert hat. Im System wird sie typischerweise als „Submitter“ oder „Reported By“ erfasst.

Auch wenn es nicht immer eine primäre Analysedimension ist, kann das Attribut beim Verständnis der Quellen von Änderungsanträgen helfen. So kann beispielsweise die Analyse zeigen, ob die meisten Änderungen aus bestimmten Abteilungen oder von bestimmten Rollen stammen und dadurch Erkenntnisse über geschäftliche Anforderungen und Planungsprozesse liefern.

Warum das wichtig ist

Es hilft, die Urheber von Änderungsanträgen zu identifizieren. Diese Information kann zur Analyse von Nachfragemustern und Benutzerverhalten im Prozess verwendet werden.

Bezugsquelle

Zu finden im Feld „Submitter“ des Formulars „CHG:Infrastructure Change“.

Beispiele
Allen AllbrookMary MannBob Baxter
Endzeit
EventEndTime
Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung

End Time markiert den Abschluss einer Aktivität. Im Process Mining wird dieser Wert häufig als Startzeit der nachfolgenden Aktivität im Case berechnet und liefert dadurch eine eindeutige Dauer für den vorherigen Schritt. Bei der letzten Aktivität eines Cases kann End Time der Startzeit entsprechen oder durch einen bestimmten Abschluss-Timestamp festgelegt werden.

Dieses Attribut ist entscheidend für die Berechnung der ProcessingTime jeder Aktivität, einer zentralen Kennzahl für die Leistungsanalyse und die Erkennung von Engpässen. Es ermöglicht eine detaillierte Analyse der Dauer einzelner Schritte.

Warum das wichtig ist

Es ermöglicht die präzise Berechnung von Aktivitätsdauern. Das ist eine wesentliche Grundlage für die Erkennung von Engpässen und die Messung der Prozessleistung.

Bezugsquelle

Dies ist ein berechnetes Attribut, das typischerweise während der Datentransformation aus der Startzeit des nächsten Ereignisses in der Sequenz für einen bestimmten Case abgeleitet wird.

Beispiele
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
Ist Nacharbeit
IsRework
Ein Kennzeichen dafür, dass eine Aktivität eine Schleife mit Nacharbeit 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, beispielsweise von „Scheduled“ zu „Risk Assessment“. Solche Rückschritte stellen Nacharbeit dar und sind häufig eine Ursache für Ineffizienz.

Dieses Kennzeichen wird zur Berechnung der KPI „Change Rework Rate“ verwendet und unterstützt das Dashboard „Change Rework & Assessment Efficiency“. Es hilft, die Häufigkeit von Nacharbeit zu quantifizieren und die Prozessschritte zu erkennen, an denen sie besonders oft auftritt. Dadurch werden Ansatzpunkte für Verbesserungen bei der ursprünglichen Planung und Bewertung sichtbar.

Warum das wichtig ist

Es identifiziert Prozessineffizienzen direkt, indem es Aktivitäten in einer Nacharbeitsschleife kennzeichnet und dadurch gezielte Verbesserungsmaßnahmen ermöglicht.

Bezugsquelle

Dies ist ein berechnetes Attribut, das aus der Analyse der Aktivitätssequenz eines Cases abgeleitet wird. Während der Datentransformation wird Logik angewendet, um Rückschritte im Prozessfluss zu erkennen.

Beispiele
truefalse
Ist Notfalländerung
IsEmergencyChange
Ein boolesches Kennzeichen, das true ist, wenn die Änderung vom Typ „Emergency“ ist.
Beschreibung

Dieses abgeleitete Kennzeichen vereinfacht die Analyse, indem es einen eindeutigen binären Indikator für Emergency Changes bereitstellt. Es basiert auf dem Wert des Attributs „ChangeType“.

Das Attribut unterstützt vor allem das Dashboard „Emergency Change Volume & Impact“ und die KPI „Emergency Change Percentage“. Es ermöglicht das einfache Filtern und Aggregieren von Daten zu Emergency Changes. Dadurch lassen sich Häufigkeit und Trends im Zeitverlauf ohne komplexe Filterlogik im Analysetool verfolgen.

Warum das wichtig ist

Es vereinfacht die Analyse von Emergency Changes und erleichtert das Filtern, die Darstellung in Dashboards sowie die Berechnung zugehöriger KPIs für diesen kritischen Änderungstyp.

Bezugsquelle

Dies ist ein während der Datentransformation erzeugtes abgeleitetes Attribut. Die Logik lautet: IF „ChangeType“ = „Emergency“ THEN true ELSE false.

Beispiele
truefalse
SLA-Status
SLAState
Der berechnete Status des Änderungsantrags im Verhältnis zu seinem SLA-Ziel.
Beschreibung

Dieses Attribut zeigt an, ob ein abgeschlossener Änderungsantrag sein Service Level Agreement (SLA) eingehalten hat, von einer Verletzung bedroht war oder das SLA verletzt hat. Es wird durch den Vergleich des tatsächlichen Abschluss-Timestamps mit „SLATargetDate“ berechnet.

Dies ist die zentrale Kennzahl für das Dashboard „Change SLA Performance“. Sie liefert ein klares, kompaktes Maß für die Leistung im Verhältnis zu Serviceverpflichtungen und ermöglicht die Analyse nach Priority, Change Type oder Team, um Bereiche mit geringer SLA-Einhaltung zu erkennen.

Warum das wichtig ist

Es misst die Leistung im Verhältnis zu eingegangenen Verpflichtungen direkt und ist damit ein wichtiger Indikator für Prozesseffizienz und Servicequalität.

Bezugsquelle

Dies ist ein berechnetes Attribut, das während der Datentransformation durch den Vergleich des Timestamps der letzten Aktivität mit „SLATargetDate“ abgeleitet wird.

Beispiele
TermingerechtGefährdetFrist überschritten
SLA-Zieldatum
SLATargetDate
Das Zieldatum und die Zielzeit, bis zu denen der Änderungsantrag abgeschlossen sein sollte.
Beschreibung

Die Service-Level-Agreement-(SLA)-Zieldatum ist die Frist für den Abschluss des Änderungsantrags, die anhand seiner Priorität und seines Typs bestimmt wird. Dieser Wert dient als Vergleichsmaßstab für die tatsächliche Abschlusszeit.

Dieses Attribut ist eine zentrale Grundlage für das Dashboard „Change SLA Performance“. Durch den Vergleich der tatsächlichen Abschlusszeit mit diesem Ziel lässt sich feststellen, ob die Änderung ihr SLA eingehalten hat. Die Analyse der SLA-Leistung hilft, die Effizienz des Gesamtprozesses und die Einhaltung von Serviceverpflichtungen zu bewerten.

Warum das wichtig ist

Es liefert den Vergleichsmaßstab für die Leistungsmessung und ermöglicht die Berechnung von SLA-Konformitätsraten sowie die Erkennung gefährdeter Änderungen.

Bezugsquelle

Diese Information wird typischerweise in zugehörigen SLA-Managementformularen 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 er möglicherweise verursacht hat. Diese Beziehung ist entscheidend, um die nachgelagerten Auswirkungen von Änderungen auf die Servicestabilität zu verstehen.

Dies ist das wichtigste Attribut für die Berechnung der KPI „Change-Induced Incident Rate“. Durch die Nachverfolgung dieser Verknüpfungen kann eine Organisation die Qualität ihres Änderungsprozesses messen und Änderungstypen, Teams oder Services erkennen, die mit einer höheren Rate von Problemen nach der Implementierung verbunden sind.

Warum das wichtig ist

Es misst direkt die negativen Auswirkungen von Änderungen und liefert eine wichtige KPI zur Bewertung der Änderungsqualität und der Wirksamkeit des Risikomanagements.

Bezugsquelle

Diese Beziehung wird typischerweise im Incident-Formular („HPD:Help Desk“) hergestellt, in dem ein Incident als durch einen Änderungsantrag verursacht verknüpft werden kann.

Beispiele
INC000000987654INC000000987655INC000000987656
Erforderlich Empfohlen Optional

Aktivitäten des Change Managements

Dies sind die wesentlichen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um den Prozess präzise zu erkennen und Engpässe wirksam zu identifizieren.
7 Empfohlen 7 Optional
Aktivität Beschreibung
Änderung eingeplant
Diese Aktivität markiert den Zeitpunkt, an dem die genehmigte Änderung offiziell zur Implementierung eingeplant wird. Das Ereignis wird anhand der Statusänderung zu „Scheduled“ im System erfasst.
Warum das wichtig ist

Dies ist ein wichtiger Meilenstein, der die Bereitschaft zur Implementierung signalisiert. Er bildet den Ausgangspunkt für die Messung der KPIs Change Implementation Cycle Time und Average Implementation Wait Time.

Bezugsquelle

Abgeleitet aus dem Verlauf der Statusänderungen im Formular CHG:Change, wenn der Status zu „Scheduled“ wechselt.

Erfassen

Ermitteln Sie den Timestamp, zu dem das Feld „Status“ in CHG:Change auf „Scheduled“ aktualisiert wird.

Ereignistyp inferred
Änderung geschlossen
Dies ist die letzte Aktivität und markiert den formellen Abschluss des Änderungsantrags im System. Das Ereignis wird erfasst, wenn der Status des Änderungsantrags auf „Closed“ gesetzt wird.
Warum das wichtig ist

Diese Aktivität markiert das erfolgreiche Ende des Änderungslebenszyklus. Sie ist erforderlich, um die End-to-End-Prozessdauer und den Gesamtdurchsatz zu messen.

Bezugsquelle

Abgeleitet aus dem Verlauf der Statusänderungen im Formular CHG:Change, wenn der Status zu „Closed“ wechselt.

Erfassen

Ermitteln Sie den Timestamp, zu dem das Feld „Status“ in CHG:Change auf „Closed“ aktualisiert wird.

Ereignistyp inferred
Änderung implementiert
Diese Aktivität steht für den erfolgreichen Abschluss der Implementierungsarbeiten an der Änderung. Sie wird in der Regel erfasst, wenn der Status auf „Completed“ aktualisiert wird und ein Erfolgsgrund angegeben ist.
Warum das wichtig ist

Dies ist ein wesentlicher Meilenstein am Ende der Bereitstellungsphase. Er ist erforderlich, um die Change Implementation Cycle Time zu berechnen und durch Änderungen verursachte Incidents zu analysieren.

Bezugsquelle

Abgeleitet aus dem Formular CHG:Change, wenn „Status“ auf „Completed“ und „Status Reason“ auf „Successful“ gesetzt ist.

Erfassen

Ermitteln Sie den Timestamp, zu dem das Feld „Status“ in CHG:Change auf „Completed“ aktualisiert wird.

Ereignistyp inferred
Change Request erstellt
Diese Aktivität kennzeichnet die erstmalige Erstellung eines Datensatzes für einen Change Request im System. Das Ereignis wird anhand des Erstellungs-Timestamps des Change-Request-Eintrags im Formular CHG:Change erfasst.
Warum das wichtig ist

Dies ist der Ausgangspunkt jedes Change Requests. Die Aktivität ist entscheidend, um die Gesamtdauer des Lebenszyklus zu messen und das Volumen eingehender Änderungen zu analysieren.

Bezugsquelle

Dieses Ereignis wird anhand des Felds „Submit Date“ oder des Erstellungs-Timestamps im Audit Log des Formulars CHG:Change erfasst, beispielsweise im HPD:Help Desk Audit Log.

Erfassen

Verwenden Sie den Erstellungs-Timestamp aus dem Formular CHG:Change.

Ereignistyp explicit
Change Request genehmigt
Dies ist ein wichtiger Meilenstein: Der Change Request erhält die formale Genehmigung zur Umsetzung. Das Ereignis wird aus einer Statusänderung abgeleitet, typischerweise zu „Scheduled“ oder „Planning In Progress“ nach der abschließenden Genehmigung.
Warum das wichtig ist

Damit endet die Genehmigungsphase. Die Aktivität ist entscheidend, um Genehmigungsengpässe und den KPI für die durchschnittliche Genehmigungszeit von Änderungen zu messen. Sie markiert einen zentralen Entscheidungspunkt im Prozess.

Bezugsquelle

Abgeleitet aus der Statusänderungshistorie im Formular CHG:Change, insbesondere wenn der Antrag einen Genehmigungsstatus wie „Request For Authorization“ verlässt.

Erfassen

Identifizieren Sie den Timestamp, an dem das Feld „Status“ in CHG:Change die abschließende Genehmigungsphase verlässt, beispielsweise 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 Change Requests aktualisiert oder eine bestimmte Aufgabe zur Risikobewertung geschlossen wird.
Warum das wichtig ist

Die Erfassung dieser Aktivität ist entscheidend, um die Einhaltung von Change-Management-Richtlinien 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.

Bezugsquelle

Abgeleitet aus einer Statusänderung im Formular CHG:Change, beispielsweise dem Wechsel zu „Request For Change“, oder aus dem Abschluss einer zugehörigen Aufgabe im Formular CHG:Task.

Erfassen

Identifizieren Sie den Timestamp, an dem eine verknüpfte Aufgabe „Risk Assessment“ in CHG:Task als „Closed“ oder „Completed“ markiert wird.

Ereignistyp inferred
Tests durchgeführt
Zeigt an, dass Tests oder Validierungen nach der Implementierung abgeschlossen wurden. Dies wird häufig durch den Abschluss eines dedizierten Test-Tasks erfasst, der mit dem Änderungsantrag verknüpft ist.
Warum das wichtig ist

Die Nachverfolgung dieser Aktivität ist entscheidend, um die Average Testing Cycle Time zu messen und die Qualität sicherzustellen. Sie hilft, Engpässe im Validierungsprozess vor der abschließenden Prüfung zu erkennen.

Bezugsquelle

Abgeleitet aus dem Abschluss eines Test-Task-Datensatzes im Formular CHG:Task, der mit dem übergeordneten Änderungsantrag verknüpft ist.

Erfassen

Ermitteln Sie den Timestamp, zu dem ein verknüpfter Task „Testing“ oder „Validation“ in CHG:Task als „Closed“ oder „Completed“ markiert wird.

Ereignistyp inferred
Änderung abgebrochen
Steht für die Stornierung eines Änderungsantrags vor seiner Implementierung oder seinem Abschluss. Dies wird erfasst, wenn der Status des Änderungsantrags auf „Cancelled“ aktualisiert wird.
Warum das wichtig ist

Die Nachverfolgung von Stornierungen liefert Erkenntnisse darüber, warum Änderungen zurückgezogen werden. Sie kann auf Probleme wie unzureichende ursprüngliche Planung, veränderte Prioritäten oder Ressourcenengpässe hinweisen.

Bezugsquelle

Abgeleitet aus dem Verlauf der Statusänderungen im Formular CHG:Change, wenn der Status zu „Cancelled“ wechselt.

Erfassen

Ermitteln Sie den Timestamp, zu dem das Feld „Status“ in CHG:Change auf „Cancelled“ aktualisiert wird.

Ereignistyp inferred
Änderung verifiziert
Diese Aktivität zeigt an, dass Stakeholder den Erfolg der Änderung nach Implementierung und Tests formell bestätigt haben. Häufig wird sie durch eine Statusänderung vor dem endgültigen Abschluss dargestellt.
Warum das wichtig ist

Die Verifizierung ist das letzte Qualitätstor vor dem Abschluss einer Änderung. Sie bestätigt, dass die Änderung ihre Ziele erreicht und keine unbeabsichtigten negativen Auswirkungen verursacht hat.

Bezugsquelle

Abgeleitet aus einer Statusänderung im Formular CHG:Change, beispielsweise vom Status „Completed“ zu „Verification“ oder „Closed“.

Erfassen

Ermitteln Sie den Timestamp, zu dem das Feld „Status“ in CHG:Change nach Abschluss der Implementierungsaktivitäten zu „Closed“ wechselt.

Ereignistyp inferred
Auswirkungsanalyse durchgeführt
Diese Aktivität steht für den Abschluss der Auswirkungsanalyse, mit der die möglichen Folgen einer Änderung ermittelt werden. Sie wird in der Regel aus einer Statusaktualisierung oder dem Abschluss einer zugehörigen Aufgabe abgeleitet.
Warum das wichtig ist

Diese Aktivität ist entscheidend, um die Effizienz der Planung und deren Einfluss auf Nacharbeit zu verstehen. Die Analyse ihrer Dauer und Häufigkeit hilft, die Phase der Erstbewertung zu verbessern.

Bezugsquelle

Abgeleitet aus dem Abschluss-Timestamp einer Aufgabe „Impact Analysis“ im Formular CHG:Task oder aus einem bestimmten Statusübergang im Formular CHG:Change.

Erfassen

Identifizieren Sie den Timestamp, an dem eine verknüpfte Aufgabe „Impact Analysis“ in CHG:Task als „Closed“ oder „Completed“ markiert wird.

Ereignistyp inferred
Change Request abgelehnt
Diese Aktivität kennzeichnet die formale Ablehnung des Change Requests durch einen Genehmiger. Sie wird durch die Statusänderung zu „Rejected“ erfasst und stellt einen Endzustand dar.
Warum das wichtig ist

Die Erfassung von Ablehnungen hilft, Gründe wie unvollständige Informationen oder ein hohes Risiko zu erkennen. Diese Analyse kann die Qualität künftiger Change-Request-Einreichungen verbessern.

Bezugsquelle

Abgeleitet aus der Statusänderungshistorie im Formular CHG:Change, insbesondere aus dem Übergang zum Status „Rejected“.

Erfassen

Identifizieren Sie den Timestamp, an dem das Feld „Status“ in CHG:Change auf „Rejected“ aktualisiert wird.

Ereignistyp inferred
Change Request eingereicht
Diese Aktivität steht für die formale Einreichung eines Change Requests zur Prüfung und Genehmigung. Sie wird in der Regel daran erkannt, dass der Status des Change Requests von „Draft“ zu „Request For Authorization“ wechselt.
Warum das wichtig ist

Diese Aktivität startet den Genehmigungsprozess. Ihre Erfassung ist entscheidend, um die Wartezeit bis zur ersten Prüfung zu messen und den KPI für die Genehmigungszeit von Änderungen zu analysieren.

Bezugsquelle

Abgeleitet aus der Statusänderungshistorie des Change Requests im Formular CHG:Change, insbesondere aus dem Übergang zu „Request For Authorization“.

Erfassen

Identifizieren Sie den Timestamp, an dem sich das Feld „Status“ in CHG:Change von „Draft“ zu „Request For Authorization“ ändert.

Ereignistyp inferred
Überprüfung nach der Implementierung
Steht für den Abschluss einer formellen Prüfung nach der Implementierung der Änderung. Diese Aktivität wird in der Regel durch den Abschluss eines Tasks für einen Post-Implementation Review (PIR) erfasst.
Warum das wichtig ist

Diese Aktivität ist für das Lernen innerhalb der Organisation und die Verbesserung von Prozessen entscheidend. Die Messung der KPI Post-Implementation Review Rate trägt dazu bei, dass aus Änderungen Erkenntnisse gewonnen werden.

Bezugsquelle

Abgeleitet aus dem Abschluss eines Tasks „Post-Implementation Review“ im Formular CHG:Task, der mit dem übergeordneten Änderungsantrag verknüpft ist.

Erfassen

Ermitteln Sie den Timestamp, zu dem ein verknüpfter „PIR“-Task in CHG:Task als „Closed“ oder „Completed“ markiert wird.

Ereignistyp inferred
Umsetzungsplan erstellt
Diese Aktivität zeigt an, dass der detaillierte Plan zur Umsetzung der Änderung erstellt und dokumentiert wurde. Sie wird in der Regel erfasst, wenn eine mit der Änderung verknüpfte Planungsaufgabe abgeschlossen ist.
Warum das wichtig ist

Der Abschluss dieser Aktivität ist Voraussetzung für Terminierung und Umsetzung. Die Analyse ihrer Dauer hilft, Verzögerungen in der Planungsphase vor der Ausführung der Änderung zu erkennen.

Bezugsquelle

Abgeleitet aus dem Abschluss eines bestimmten Planungs-Task-Datensatzes im Formular CHG:Task, der mit dem übergeordneten Änderungsantrag verknüpft ist.

Erfassen

Ermitteln Sie den Timestamp, zu dem ein verknüpfter Task „Implementation Planning“ in CHG:Task als „Closed“ oder „Completed“ markiert wird.

Ereignistyp inferred
Empfohlen Optional

Anleitungen zur Datenextraktion

So erhalten Sie Ihre Daten aus BMC Helix ITSM

Bereit für den Start?

Beginnen Sie noch heute mit der Optimierung Ihres Änderungsmanagementprozesses, indem Sie Ihre Daten mit diesem Template vorbereiten. Gewinnen Sie wertvolle Erkenntnisse und steigern Sie die Effizienz Ihrer Abläufe.

Optimieren Sie jetzt Ihr Änderungsmanagement und vermeiden Sie Unterbrechungen

Steigern Sie Ihre Erfolgsquote bei Änderungen auf 95 % und vermeiden Sie kostspielige Serviceunterbrechungen.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Die Einrichtung dauert nur wenige Minuten.