Ihr Change Management Daten-Template

Der Activity Name beschreibt einen spezifischen Schritt oder Meilenstein im Lifecycle der Änderungsanfrage, wie „Risikobewertung abgeschlossen“ oder „Änderung genehmigt“. Jede Activity repräsentiert einen Zeitpunkt, an dem eine Aktion durchgeführt, eine Entscheidung getroffen oder der Prozess in eine neue Phase überging.\n\nDieses Attribut ist grundlegend für den Aufbau der Prozesslandkarte. Es definiert die Nodes im Prozessgraphen und ermöglicht es Analysten, die Abfolge der Events zu visualisieren, gängige Pfade zu identifizieren und Abweichungen vom Standardverfahren zu erkennen. Die Analyse von Aktivitäten hilft, Bottlenecks, Nacharbeits-Loops und ineffiziente Handoffs zwischen verschiedenen Phasen des Änderungsprozesses aufzudecken.

Es definiert die Schritte im Prozess und ermöglicht die Visualisierung des Process Flows sowie die Analyse von Bottlenecks, Nacharbeiten und Abweichungen.

Üblicherweise in einem Aktivitätsprotokoll, der Event-Historie oder einer Audit-Trail-Tabelle, die mit der Änderungsanfrage verknüpft ist, zu finden.

Die Änderungsanfrage-ID ist ein eindeutiger alphanumerischer Code, der jeder Änderungsanfrage bei ihrer Erstellung zugewiesen wird. Sie fungiert als Primärschlüssel für einen einzelnen Change Case und verknüpft alle zugehörigen Aufgaben, Genehmigungen und Protokolle von der Initiierung bis zum Abschluss.

Im Process Mining ist dieses Attribut unerlässlich, um den End-to-End-Verlauf jeder Änderung zu rekonstruieren. Durch die Gruppierung aller Events unter einer gemeinsamen Änderungsanfrage-ID können Analysten Prozessabläufe visualisieren, Case-Dauern berechnen und Variationen zwischen verschiedenen Change-Lebenszyklen analysieren. Es ist die Grundlage, auf der jede Case-Level-Analyse aufbaut, und ermöglicht einen klaren Überblick darüber, wie sich einzelne Änderungen durch das System entwickeln.

Diese ID ist entscheidend für die Verfolgung und Korrelation aller Events, die mit einer einzelnen Änderung zusammenhängen, und bildet somit den Grundstein für Process Discovery und Conformance Checking.

Typischerweise im Header oder primären Datensatz einer Änderungsanfrage-Transaktion zu finden.

Die Event Start Time markiert den Beginn einer Aktivität innerhalb des Lebenszyklus der Änderungsanfrage. Dieser Timestamp ist entscheidend für die chronologische Abfolge von Events und für die Berechnung der Dauer von Aktivitäten und des gesamten Case.

In der Prozessanalyse wird dieses Attribut verwendet, um die Aktivitäten korrekt anzuordnen und bildet die Grundlage des Event Log. Es ist unerlässlich für die Berechnung aller zeitbezogenen Metriken wie Durchlaufzeiten zwischen Aktivitäten, Wartezeiten und der gesamten Case-Dauer. Durch die Analyse dieser Timestamps können Organisationen identifizieren, welche Schritte am meisten Zeit in Anspruch nehmen, und Möglichkeiten zur Prozessbeschleunigung aufzeigen.

Dieser Timestamp ist unerlässlich für die Anordnung von Events, die Entdeckung des Prozessflusses und die Berechnung aller Performance-Metriken wie Durchlaufzeiten und Wartezeiten.

Im Event Log oder Audit Trail der Änderungsanfrage gefunden. Es kann „Erstellungsdatum“, „Startdatum“ oder einfach „Timestamp“ genannt werden.

Der Last Data Update Timestamp gibt an, wann ein bestimmter Datensatz zuletzt aus dem Quellsystem gezogen wurde. Dies ist ein Metadaten-Attribut, das für die Verwaltung der Datenpipeline und die Sicherstellung der Aktualität der Analyse unerlässlich ist.

Dieses Attribut hilft Datenarchitekten und Analysten, die Aktualität der von ihnen verwendeten Daten zu verstehen. Es wird verwendet, um den Zustand des Datenextraktionsprozesses zu überwachen und zu bestätigen, dass die Process Mining Analyse auf aktuellen und relevanten Informationen basiert. Es wird im Allgemeinen nicht für die Prozessanalyse selbst verwendet, ist aber entscheidend für Daten-Governance und Zuverlässigkeit.

Gewährleistet die Data-Aktualität und hilft beim Monitoring der Data Pipeline, was für die Zuverlässigkeit der Process Analysis entscheidend ist.

Dieser Timestamp wird typischerweise während des Extraktions-, Transformations- und Ladeprozesses (ETL) generiert und hinzugefügt.

Das Attribut Source System identifiziert den Ursprung der Event-Daten. In Umgebungen mit mehreren ITSM-Tools oder integrierten Systemen hilft dieses Feld, Daten aus verschiedenen Quellen zu unterscheiden und so die Datenintegrität und den richtigen Kontext sicherzustellen.

Obwohl nicht immer in der primären Prozessflussanalyse verwendet, ist es für die Datenvalidierung und Governance von unschätzbarem Wert. Es hilft bei der Fehlerbehebung bei Datenimportproblemen und kann verwendet werden, um die Prozessperformance über verschiedene Systeme oder Geschäftsbereiche hinweg zu vergleichen, wenn diese separate Plattformen nutzen. Beispielsweise könnte ein Unternehmen ein System für Infrastrukturänderungen und ein anderes für Anwendungsänderungen verwenden.

Identifiziert den Datenursprung, was entscheidend für die Datenvalidierung, Fehlerbehebung und Analyse von Prozessen ist, die mehrere Systeme umfassen.

Diese Informationen können als Feld in den Quelldaten gespeichert oder während des Datenextraktions- und Transformationsprozesses (ETL) hinzugefügt werden.

Der Änderungstyp ist eine entscheidende Kategorisierung, die den erforderlichen Workflow, die Genehmigungsschritte und die Dringlichkeit einer Änderungsanfrage bestimmt. Standardänderungen sind typischerweise vorab genehmigt und risikoarm, normale Änderungen durchlaufen den vollständigen Bewertungs- und Genehmigungsprozess, und Notfalländerungen erfordern aufgrund eines dringenden geschäftlichen Bedarfs eine beschleunigte Bearbeitung.

Die Analyse des Prozesses nach Änderungstyp ist eine Kernaktivität in der Change Management Analyse. Sie ermöglicht den Vergleich der Leistung und Compliance verschiedener Änderungs-Workflows. Zum Beispiel können Analysten überprüfen, ob Notfalländerungen tatsächlich einen schnelleren Weg nehmen oder ob Standardänderungen ihrem vereinfachten, vorab genehmigten Ablauf folgen. Diese Segmentierung ist entscheidend, um Prozessvariationen zu verstehen und sicherzustellen, dass das richtige Maß an Governance angewendet wird.

Dieses Attribut ist essenziell für die Segmentierung der Analyse, da verschiedene Änderungstypen unterschiedliche, vordefinierte Prozessabläufe, Genehmigungsanforderungen und Performance-Erwartungen haben.

Im Hauptdatensatz oder in den Header-Daten der Änderungsanfrage zu finden.

Der Änderungsstatus gibt die Phase einer Änderungsanfrage zu einem bestimmten Zeitpunkt oder ihr Endergebnis an. Statusse entsprechen typischerweise wichtigen Meilensteinen im Prozess und bieten einen Überblick über den Fortschritt.

Dieses Attribut kann auf zwei Arten verwendet werden. Als Snapshot-Attribut zeigt es den aktuellen Zustand aller offenen Änderungen, was nützlich für operationale Dashboards zur Überwachung des Durchsatzes und der Rückstände ist. Als Event-Attribut kann eine Statusänderung selbst als Aktivität betrachtet werden, was hilft, den Event Log anzureichern, wenn detaillierte Aktivitätsdaten spärlich sind. Die Analyse von Statusübergängen hilft, den Lebenszyklus zu verstehen und festzustellen, wo Änderungen stecken bleiben.

Es bietet einen Snapshot des Änderungsfortschritts und ermöglicht die Analyse von Bottlenecks, Durchsatz und dem aktuellen Stand des Änderungs-Backlogs.

Im Header-Datensatz der Änderungsanfrage gefunden. Historische Statusänderungen können in einem Audit Log gefunden werden.

Der „Affected Business Service“ (Betroffener Geschäftsdienst) identifiziert die Kern-Business Capability, wie „Email Service“ oder „Online Banking“, die die Änderung modifizieren wird. Dies könnte auch ein spezifisches technisches Configuration Item (CI), wie ein Server oder eine Anwendung, sein, das einen Business Service unterstützt.\n\nDieses Attribut liefert kritischen Business Context für den Change Management Prozess. Es ermöglicht, die Analyse im Hinblick auf den Business Impact statt nur auf IT-Activity zu rahmen. Zum Beispiel können Analysten identifizieren, welche Services am häufigsten geändert werden, was auf Instabilität oder eine hohe Innovationsrate hindeuten könnte. Es hilft auch bei der Priorisierung von Änderungen und der Risikobewertung, indem technische Änderungen mit den unterstützten Business-Funktionen verknüpft werden.

Verknüpft IT-Änderungen mit dem Business Context, wodurch analysiert werden kann, welche Business Services am stärksten von Änderungsaktivitäten und damit verbundenen Risiken betroffen sind.

Im Hauptdatensatz der Änderungsanfrage gefunden, oft verknüpft aus einer Configuration Management Database (CMDB).

Die Event End Time markiert den Abschluss einer Aktivität. Zusammen mit der Event Start Time ermöglicht sie die präzise Berechnung der Bearbeitungszeit für jeden Schritt im Change-Lebenszyklus.

Dieses Attribut ist grundlegend für die Performance-Analyse. Die Differenz zwischen Start- und Endzeit zeigt die 'Bearbeitungszeit' einer Aktivität, während die Zeit zwischen dem Ende einer Aktivität und dem Beginn der nächsten die 'Wartezeit' offenbart. Diese Unterscheidung ist entscheidend, um festzustellen, ob Verzögerungen durch lange Aufgaben oder durch Leerlaufzeiten zwischen Aufgaben verursacht werden, und leitet gezielte Verbesserungsmaßnahmen an.

Es ermöglicht die Berechnung präziser Activity-Dauern und hilft, zwischen wertschöpfender Bearbeitungszeit und nicht-wertschöpfender Wartezeit zu unterscheiden.

Oft in den Activity Logs oder Audit Trail Tabellen gefunden. Falls nicht verfügbar, kann er manchmal aus der Startzeit des nachfolgenden Events abgeleitet werden.

Die Änderungspriorität ist eine Klassifizierung, die zur Bestimmung der relativen Bedeutung einer Änderungsanfrage dient. Sie unterstützt Teams dabei, Ressourcen effektiv zu planen und zuzuweisen, um sicherzustellen, dass die kritischsten Änderungen zuerst bearbeitet werden. Die Priorität wird oft anhand der potenziellen Auswirkungen der Änderung auf das Geschäft und der Dringlichkeit ihrer Implementierung berechnet.

Im Process Mining ist die Priorität eine aussagekräftige Dimension für Filterung und Vergleich. Analysten können untersuchen, ob hochpriorisierte Änderungen tatsächlich schneller bearbeitet werden als niedrigpriorisierte. Abweichungen könnten auf Probleme bei der Ressourcenallokation, Genehmigungs-Bottlenecks bei kritischen Änderungen oder eine inkonsistente Einhaltung von Priorisierungsregeln hindeuten.

Ermöglicht die Analyse, ob Änderungen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität, wodurch die Wirksamkeit der Priorisierungsrichtlinien validiert wird.

Im Hauptdatensatz oder in den Header-Daten der Änderungsanfrage zu finden.

Das Risikolevel stellt die bewertete Wahrscheinlichkeit und den potenziellen negativen Einfluss eines Scheiterns einer Änderung dar. Diese Bewertung beeinflusst das erforderliche Maß an Tests, Prüfung und Genehmigung. Hochrisiko-Änderungen erfordern typischerweise einen strengeren Überprüfungsprozess im Vergleich zu risikoarmen Änderungen.

Dieses Attribut ermöglicht eine risikobasierte Prozessanalyse. Es kann verwendet werden, um zu überprüfen, ob Hochrisiko-Änderungen die angemessene Überprüfung erhalten, z. B. durch ein Change Advisory Board (CAB). Es ermöglicht auch die Korrelation des Risikolevels mit Ergebnissen, zum Beispiel um festzustellen, ob Hochrisiko-Änderungen eine höhere Fehlerrate aufweisen, was darauf hindeuten könnte, dass der Risikobewertungs- oder Minderungs-Prozess verbessert werden muss.

Ermöglicht die Analyse, ob Prozesskontrollen und Genehmigungs-Workflows korrekt auf das bewertete Risiko der Änderung abgestimmt sind.

In den Header-Daten oder Risikobewertungsdetails einer Änderungsanfrage gefunden.

Der Verantwortliche Benutzer ist die spezifische Person, die einer Änderungsanfrage oder Aktivität zugewiesen ist. Dieses Attribut bietet eine granularere Sicht auf Arbeitslast und Verantwortung als die Teamebene.

Die Analyse von Daten auf Benutzerebene kann beim Performance Management und bei der Identifizierung von Schulungsmöglichkeiten helfen. Sie kann Personen hervorheben, die Prozessexperten sind, oder solche, die mit bestimmten Aufgaben Schwierigkeiten haben könnten. Es wird auch zur Analyse von Nacharbeiten verwendet, um beispielsweise festzustellen, ob von bestimmten Personen bearbeitete Änderungen eher abgelehnt werden oder eine Nachbesserung erfordern. Es ist jedoch darauf zu achten, diese Informationen konstruktiv und nicht für strafende Maßnahmen zu verwenden.

Bietet eine granulare Ansicht zur Analyse der individuellen Arbeitslast und Leistung, wodurch Experten und potenzielle Schulungsbedarfe innerhalb von Teams identifiziert werden können.

Typischerweise im Änderungsanfrage-Datensatz oder in den Aufgaben-Details zu finden, oft als „Zugewiesener“ oder „Zuständig für“ bezeichnet.

Das Verantwortliche Team identifiziert die Gruppe von Personen, die in einer bestimmten Phase an der Änderung arbeiten. Dies könnte ein Bewertungsteam, ein Genehmigungsgremium wie das CAB oder das technische Team sein, das die Implementierung durchführt.

Dieses Attribut ist unerlässlich für die Analyse der Ressourcenallokation, der Arbeitslastverteilung und der Übergaben zwischen Teams. Eine Social Network Analysis kann Kommunikationsmuster und Bottlenecks zwischen verschiedenen Gruppen aufzeigen. Durch die Messung der mit jedem Team verbrachten Zeit können Organisationen identifizieren, welche Gruppen überlastet sind oder wo Verzögerungen bei der Verantwortungsübergabe häufig auftreten.

Dies ist entscheidend für die Analyse von Übergaben zwischen Teams, die Identifizierung von Ressourcenengpässen und das Verständnis der Arbeitslastverteilung in der gesamten Organisation.

Im Änderungsanfrage-Datensatz oder in den Activity-Level-Details gefunden. Es kann „Assignment Group“ oder „Team“ genannt werden.

Der Änderungsanlass ist eine textuelle Beschreibung, die den geschäftlichen Beweggrund für die Änderungsanfrage darlegt. Sie beantwortet die Frage „Warum tun wir das?“, indem sie Kontext liefert, wie z. B. „Sicherheitspatch für kritische Schwachstelle“ oder „Neue Funktion zur Verbesserung der Kundenerfahrung“.

Obwohl oft ein Freitextfeld, kann dieses Attribut wertvolle qualitative Einblicke liefern, wenn es kategorisiert oder mit Text-Mining-Techniken analysiert wird. Es hilft, die Nachfrage nach Änderungen aus verschiedenen Geschäftsbereichen zu verstehen. Eine Analyse könnte beispielsweise ergeben, dass ein großer Prozentsatz der Änderungen durch Fehlerbehebungen bedingt ist, was auf potenzielle Probleme mit der Softwarequalität hindeutet, während in einem anderen Zeitraum eine hohe Anzahl von Änderungen im Zusammenhang mit strategischen Projekten stehen könnte.

Bietet Business Context, warum Änderungen initiiert werden, und hilft, die Haupttreiber von Änderungen innerhalb der Organisation zu analysieren.

Typischerweise im anfänglichen Einreichungsformular oder in den Header-Details der Änderungsanfrage zu finden.

Der Change Impact bewertet die potenziellen Auswirkungen einer Änderung auf den Geschäftsbetrieb, Services oder die Infrastruktur. Gemeinsam mit der Dringlichkeit bildet er die wesentliche Grundlage, um die Gesamtpriorität einer Änderung festzulegen. Ein Beispiel: Änderungen an kritischen Services mit direktem Kundenkontakt haben grundsätzlich einen hohen Impact.

Die Analyse nach Impact stellt sicher, dass geschäftskritische Änderungen mit der notwendigen Sorgfalt behandelt werden. Im Conformance Checking lässt sich so verifizieren, ob High-Impact-Änderungen stets die vorgesehenen Genehmigungs- und Testschritte durchlaufen. Zudem lassen sich Performance-Vergleiche anstellen – beispielsweise um zu prüfen, ob solche Änderungen aufgrund umfassenderer Reviews und Tests eine längere Durchlaufzeit aufweisen.

Hilft zu überprüfen, ob Änderungen mit hohem Business Impact strengere Überprüfungs- und Testpfade durchlaufen, um eine ordnungsgemäße Governance zu gewährleisten.

Im Hauptdatensatz oder in den Header-Daten der Änderungsanfrage zu finden.

Die Änderungsdringlichkeit gibt an, wie schnell eine Änderung implementiert werden muss, um Geschäftsanforderungen zu erfüllen. Sie spiegelt die Zeitkritikalität der Änderung wider, unabhängig von ihren potenziellen Auswirkungen. Eine Änderung könnte geringe Auswirkungen, aber eine hohe Dringlichkeit haben, wie die Behebung eines kleinen Problems vor dem Start einer Marketingkampagne.

Die Dringlichkeit ist eine Schlüsselkomponente bei der Berechnung der Priorität und wird verwendet, um die Aktualität des Change Management Prozesses zu analysieren. Analysten können untersuchen, ob Änderungen mit hoher Dringlichkeit tatsächlich schneller verarbeitet werden. Der Vergleich von Durchlaufzeiten über verschiedene Dringlichkeitsstufen kann aufzeigen, ob der Prozess auf geschäftliche Anforderungen reagiert oder ob alle Änderungen mit der gleichen Geschwindigkeit behandelt werden, unabhängig von ihrer Zeitkritikalität.

Ermöglicht die Analyse der Prozessreaktionsfähigkeit auf zeitkritische Geschäftsanforderungen durch den Vergleich von Cycle Times über verschiedene Dringlichkeitsstufen hinweg.

Im Hauptdatensatz oder in den Header-Daten der Änderungsanfrage zu finden.

Der Grund für das Änderungsergebnis liefert den Kontext, warum eine Änderungsanfrage so abgeschlossen wurde, wie sie es wurde. Bei erfolgreichen Änderungen könnte dies „Erfolgreich“ sein. Bei fehlgeschlagenen Änderungen könnte es „Nicht erfolgreich – Rollback initiiert“ lauten. Bei abgelehnten oder stornierten Änderungen wird die Begründung angegeben, z. B. „Unzureichende Begründung“ oder „Vom Anfragenden storniert“.

Dieses Attribut ist entscheidend für die Ursachenanalyse fehlgeschlagener oder abgelehnter Änderungen. Durch die Kategorisierung und Analyse dieser Gründe können Organisationen häufige Fehlermuster identifizieren. Wenn beispielsweise viele Änderungen aufgrund von „Unvollständigen Informationen“ abgelehnt werden, signalisiert dies die Notwendigkeit, den Änderungsantragsprozess zu verbessern. Diese Daten helfen bei der Berechnung und dem Verständnis von KPIs wie der Änderungsfehlerrate und der Erstgenehmigungsrate.

Liefert kritische Daten für die Ursachenanalyse fehlgeschlagener, abgelehnter oder stornierter Änderungen und hilft, die Qualität zukünftiger Änderungsanfragen zu verbessern.

In den Abschlussdetails eines Änderungsanfrage-Datensatzes gefunden. Es kann „Schließungscode“, „Auflösung“ oder „Ablehnungsgrund“ genannt werden.

Das geplante Abschlussdatum ist der für die Änderung festgelegte Termin, der oft durch Geschäftsanforderungen oder Service Level Agreements (SLAs) bestimmt wird. Es dient als Benchmark zur Messung der Aktualität und Performance des Change Management Prozesses.

Dieses Attribut ist unerlässlich für die SLA Performance Analyse. Durch den Vergleich des tatsächlichen Abschlussdatums mit dem geplanten Datum können Organisationen die On-Time Completion Rate, einen wichtigen Key Performance Indicator, berechnen. Die Analyse von Änderungen, die ihre geplanten Termine nicht einhalten, kann helfen, die Ursachen für Verzögerungen zu identifizieren, sei es in Zusammenhang mit Genehmigungs-Bottlenecks, Ressourcenengpässen oder unrealistischer Planung.

Dies ist ein Schlüsselattribut zur Messung der SLA-Compliance und pünktlichen Lieferung, das hilft, die Grundursachen für Verzögerungen im Prozess zu identifizieren.

Typischerweise in den Header-Daten der Änderungsanfrage zu finden.