Ihr Change-Management Daten-Template

Der Aktivitätsname beschreibt einen spezifischen Schritt oder Meilenstein im Lebenszyklus der Änderungsanfrage, wie „Risikobewertung abgeschlossen“ oder „Änderung genehmigt“. Jede Activity repräsentiert einen Zeitpunkt, an dem eine Aktion durchgeführt, eine Entscheidung getroffen oder den Antrag bearbeitet.er Prozess in eine neue Phase überging.\n\nDieses Attribut ist die Basis für den Aufbau der Prozessablauf. Es definiert die Knoten im Prozessgraphen und ermöglicht es Analysten, die Abfolge der Ereignisse zu visualisieren, gängige Pfade zu identifizieren und Abweichungen vom Standardverfahren zu erkennen. Die Analyse von Aktivitäten hilft, Engpässe, Nacharbeitsschleifen und ineffiziente Übergaben zwischen verschiedenen Phasen des Änderungsprozesses aufzudecken.

Es definiert die Schritte im Prozess und ermöglicht die Visualisierung des Prozessflusss sowie die Analyse von Engpässe, 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 Ereignisse unter einer gemeinsamen Änderungsanfrage-ID können Analysten Prozessabläufe visualisieren, Case-Dauern berechnen und Variationen zwischen verschiedenen Change-Lebenszyklen analysierenn. 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 maßgeblich für die Verfolgung und Korrelation aller Ereignisse, die mit einer einzelnen Änderung zusammenhängen, und bildet somit den Grundstein für Prozessanalyse (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 Zeitstempel ist maßgeblich für die chronologische Abfolge von Ereignisse 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 Zeitstempels können Organisationen identifizieren, welche Schritte am meisten Zeit in Anspruch nehmen, und Möglichkeiten zur Prozessbeschleunigung aufzeigen.

Dieser Zeitstempel ist unerlässlich für die Anordnung von Ereignisse, die Entdeckung des Prozessflusses und die Berechnung aller Leistungsfähigkeit-Metriken wie Durchlaufzeiten und Wartezeiten.

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

Der Last Daten Update Zeitstempel 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 notwendig 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 wichtig für Daten-Governance und Zuverlässigkeit.

Gewährleistet die Daten-Aktualität und hilft beim Monitoring der Daten Pipeline, was für die Zuverlässigkeit der Prozessanalyse wichtig ist.

Dieser Zeitstempel wird in der Regel während des Extraktions-, Transformations- und Ladeprozesses (ETL) generiert und hinzugefügt.

Das Attribut Quellsystem 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 besonders wertvoll. Es hilft bei der Fehlerbehebung bei Datenimportproblemen und kann verwendet werden, um die Prozess-Performance über verschiedene Systeme oder Geschäftsbereiche hinweg zu vergleichen, wenn diese separate Plattformen einsetzen. Beispielsweise könnte ein Unternehmen ein System für Infrastrukturänderungen und ein anderes für Anwendungsänderungen verwenden.

Identifiziert den Datenursprung, was wesentlich 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 wichtige Kategorisierung, die den erforderlichen Workflow, die Genehmigungsschritte und die Dringlichkeit einer Änderungsanfrage bestimmt. Standardänderungen sind in der Regel 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 maßgeblich, um Prozessvariationen zu verstehen und sicherzustellen, dass das richtige Maß an Governance angewendet wird.

Dieses Attribut ist wichtig für die Segmentierung der Analyse, da verschiedene Änderungstypen unterschiedliche, vordefinierte Prozessabläufe, Genehmigungsanforderungen und Leistungsfähigkeit-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. Status entsprechen in der Regel wichtigen Meilensteinen im Prozess und bieten einen Überblick über den Fortschritt.

Dieses Attribut kann auf zwei Arten verwendet werden. Als Momentaufnahme-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 Momentaufnahme des Änderungsfortschritts und ermöglicht die Analyse von Engpässe, 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 „E-Mail 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 Dienste 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 Dienste am stärksten von Änderungsaktivitäten und damit verbundenen Risiken betroffen sind.

Im HauptDatensatz der Änderungsanfrage gefunden, oft verknüpft aus einer Configuration Management Datenbase (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 die Basis für die Leistungsfähigkeit-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 maßgeblich, um festzustellen, ob Verzögerungen durch lange Aufgaben oder den Antrag bearbeitet.urch Leerlaufzeiten zwischen Aufgaben verursacht werden, und leitet gezielte Verbesserungsmaßnahmen an.

Es ermöglicht die Berechnung präziser Aktivitätsdauern 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 Ereignisse 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-Engpässe 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 in der Regel 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 Resultaten, 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 detailliertere Sicht auf Arbeitslast und Verantwortung als die Teamebene.

Die Analyse von Daten auf Benutzerebene kann beim Leistungsfähigkeit 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 den Antrag bearbeitet.as 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 Engpässe 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 maßgeblich 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 zentrale Faktor von Änderungen innerhalb der Organisation zu analysierenn.

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, Dienste oder den Antrag bearbeitet.ie Infrastruktur. Gemeinsam mit der Dringlichkeit bildet er die wesentliche Grundlage, um die Gesamtpriorität einer Änderung festzulegen. Ein Beispiel: Änderungen an kritischen Dienste 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 Leistungsfähigkeit-Vergleiche anstellen: beispielsweise um zu prüfen, ob solche Änderungen aufgrund vollständigerer 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 sicherstellen.

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 analysierenn. 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 Durchlaufzeits ü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 maßgeblich 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 Leistungsfähigkeit des Change-Management Prozesses.

Dieses Attribut ist unerlässlich für die SLA Leistungsfähigkeit Analyse. Durch den Vergleich des tatsächlichen Abschlussdatums mit dem geplanten Datum können Organisationen die On-Time Completion Rate, einen wichtigen Key Leistungsfähigkeit 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-Engpässe, 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.