Ihr Daten-Template für das Änderungsmanagement

Der Aktivitätsname bezeichnet einen bestimmten Schritt oder Meilenstein im Lebenszyklus eines Änderungsantrags, zum Beispiel „Risikobewertung abgeschlossen“ oder „Änderung genehmigt“. Jede Aktivität steht für einen Zeitpunkt, an dem eine Aktion ausgeführt, eine Entscheidung getroffen oder der Prozess in eine neue Phase überführt wurde.

Dieses Attribut ist grundlegend für die Erstellung der Prozesslandkarte. Es definiert die Knoten im Prozessgraphen und ermöglicht es Analysten, die Ereignisabfolge zu visualisieren, häufige Abläufe zu erkennen und Abweichungen von der Standardvorgehensweise aufzudecken. Die Analyse der Aktivitäten macht Engpässe, Schleifen durch Nacharbeit und ineffiziente Übergaben zwischen den Prozessphasen sichtbar.

Das Attribut definiert die Prozessschritte und ermöglicht es, den Prozessablauf zu visualisieren sowie Engpässe, Nacharbeit und Abweichungen zu analysieren.

Üblicherweise in einem Aktivitätsprotokoll, einer Ereignishistorie oder einer Audit-Tabelle zum Änderungsantrag zu finden.

Die Änderungsantrags-ID ist ein eindeutiger alphanumerischer Code, der jedem Änderungsantrag bei seiner Erstellung zugewiesen wird. Als Primärschlüssel für einen einzelnen Änderungs-Case verknüpft sie alle zugehörigen Aufgaben, Genehmigungen und Protokolle vom Beginn bis zum Abschluss.

Im Process Mining ist dieses Attribut unverzichtbar, um den gesamten Verlauf jeder Änderung zu rekonstruieren. Werden alle Ereignisse unter einer gemeinsamen Änderungsantrags-ID gruppiert, können Analysten Prozessabläufe visualisieren, Case-Dauern berechnen und Abweichungen zwischen verschiedenen Änderungszyklen untersuchen. Sie bildet die Grundlage für alle Analysen auf Case-Ebene und zeigt übersichtlich, wie einzelne Änderungen das System durchlaufen.

Diese ID ist entscheidend, um alle Ereignisse zu einer einzelnen Änderung nachzuverfolgen und miteinander zu verknüpfen. Sie bildet damit die Grundlage für die Prozesserkennung und Konformitätsprüfung.

In der Regel im Kopfbereich oder im Hauptdatensatz eines Änderungsvorgangs zu finden.

Die Startzeit des Ereignisses markiert den Beginn einer Aktivität im Lebenszyklus des Änderungsantrags. Dieser Timestamp ist entscheidend, um Ereignisse chronologisch zu ordnen und die Dauer einzelner Aktivitäten sowie des gesamten Cases zu berechnen.

Bei der Prozessanalyse dient dieses Attribut dazu, Aktivitäten korrekt zu ordnen und so die Grundlage für das Event Log zu schaffen. Es ist unverzichtbar für die Berechnung aller zeitbezogenen Kennzahlen, etwa der Zykluszeiten zwischen Aktivitäten, der Wartezeiten und der gesamten Case-Dauer. Anhand dieser Timestamps können Unternehmen erkennen, welche Schritte am meisten Zeit beanspruchen und wo sich Prozesse beschleunigen lassen.

Dieser Timestamp ist entscheidend, um Ereignisse zu ordnen, den Prozessablauf zu erkennen und Leistungskennzahlen wie Zyklus- und Wartezeiten zu berechnen.

Im Event Log oder Audit-Trail zum Änderungsantrag zu finden. Die Bezeichnung kann „Erstellungsdatum“, „Startdatum“ oder einfach „Timestamp“ lauten.

Der Timestamp der letzten Datenaktualisierung gibt an, wann ein bestimmter Datensatz zuletzt aus dem Quellsystem abgerufen wurde. Dieses Metadatenattribut ist wichtig, um die Datenpipeline zu verwalten und sicherzustellen, dass die Analyse auf aktuellen Daten beruht.

Das Attribut hilft Data Engineers und Analysten, die Aktualität der verwendeten Daten einzuschätzen. Es dient dazu, den Zustand der Datenextraktion zu überwachen und zu bestätigen, dass die Process-Mining-Analyse auf aktuellen und relevanten Informationen basiert. Für die Prozessanalyse selbst wird es in der Regel nicht verwendet, für Daten-Governance und Zuverlässigkeit ist es jedoch entscheidend.

Sichert die Aktualität der Daten und unterstützt die Überwachung der Datenpipeline. Beides ist entscheidend für zuverlässige Prozessanalysen.

Dieser Timestamp wird üblicherweise während der Datenextraktion, -transformation und -ladung (ETL) erzeugt und hinzugefügt.

Das Attribut „Quellsystem“ gibt an, woher die Ereignisdaten stammen. In Umgebungen mit mehreren ITSM-Tools oder integrierten Systemen hilft dieses Feld, Daten aus verschiedenen Quellen zu unterscheiden und so Datenintegrität und Kontext sicherzustellen.

Für die Analyse des primären Prozessablaufs wird das Attribut nicht immer verwendet, für die Datenvalidierung und Governance ist es jedoch sehr wertvoll. Es unterstützt bei der Fehlersuche in der Datenübernahme und ermöglicht Vergleiche der Prozessleistung zwischen verschiedenen Systemen oder Geschäftseinheiten, wenn diese getrennte Plattformen verwenden. Ein Unternehmen kann beispielsweise ein System für Infrastrukturänderungen und ein anderes für Anwendungsänderungen einsetzen.

Gibt die Herkunft der Daten an. Das ist wichtig für die Datenvalidierung, die Fehlersuche und die Analyse von Prozessen, die mehrere Systeme umfassen.

Diese Information kann als Feld in den Quelldaten gespeichert oder während der Datenextraktion und -transformation (ETL) hinzugefügt werden.

Der Änderungsstatus zeigt die Phase eines Änderungsantrags zu einem bestimmten Zeitpunkt oder sein endgültiges Ergebnis an. Die Statuswerte entsprechen in der Regel wichtigen Meilensteinen im Prozess und geben einen Überblick über den Fortschritt.

Dieses Attribut lässt sich auf zwei Arten verwenden. Als Momentaufnahme zeigt es den aktuellen Status aller offenen Änderungen und eignet sich damit für operative Dashboards zur Überwachung von Durchsatz und Rückständen. Als Ereignisattribut kann eine Statusänderung selbst als Aktivität gelten und das Event Log ergänzen, wenn nur wenige detaillierte Aktivitätsdaten vorliegen. Die Analyse von Statusübergängen zeigt, wie der Lebenszyklus verläuft und an welchen Stellen Änderungen ins Stocken geraten.

Das Attribut zeigt den Fortschritt einer Änderung und ermöglicht die Analyse von Engpässen, Durchsatz und dem aktuellen Stand des Änderungsrückstands.

Im Kopfdatensatz des Änderungsantrags zu finden. Frühere Statusänderungen können in einem Audit-Protokoll stehen.

Der Änderungstyp ist eine wichtige Klassifizierung, die den erforderlichen Workflow, die Genehmigungsschritte und die Dringlichkeit eines Änderungsantrags bestimmt. Standardänderungen sind in der Regel vorab genehmigt und risikoarm. Normale Änderungen durchlaufen den vollständigen Bewertungs- und Genehmigungsprozess. Notfalländerungen werden aufgrund eines dringenden geschäftlichen Bedarfs beschleunigt bearbeitet.

Die Analyse nach Änderungstyp gehört zu den zentralen Aufgaben im Änderungsmanagement. Sie ermöglicht den Vergleich der Leistung und Compliance verschiedener Änderungs-Workflows. Analysten können beispielsweise prüfen, ob Notfalländerungen tatsächlich schneller bearbeitet werden oder ob Standardänderungen dem vereinfachten, vorab genehmigten Ablauf folgen. Diese Aufschlüsselung macht Prozessabweichungen sichtbar und zeigt, ob die Governance angemessen ist.

Dieses Attribut ist für die Aufschlüsselung der Analyse unverzichtbar, da für verschiedene Änderungstypen jeweils eigene Prozessabläufe, Genehmigungsanforderungen und Leistungserwartungen gelten.

Im Hauptdatensatz oder in den Kopfdaten des Änderungsantrags zu finden.

Der betroffene Geschäftsservice bezeichnet die zentrale Geschäftsfunktion, zum Beispiel „E-Mail-Service“ oder „Onlinebanking“, die durch die Änderung angepasst wird. Betroffen sein kann auch ein bestimmtes technisches Configuration Item (CI), etwa ein Server oder eine Anwendung, die einen Geschäftsservice unterstützt.

Dieses Attribut liefert wichtigen geschäftlichen Kontext für das Änderungsmanagement. Es ermöglicht Analysen aus Sicht der geschäftlichen Auswirkungen statt allein anhand der IT-Aktivitäten. Analysten können beispielsweise ermitteln, welche Services am häufigsten geändert werden. Das kann auf Instabilität oder eine hohe Innovationsrate hindeuten. Außerdem unterstützt das Attribut die Priorisierung von Änderungen und die Risikobewertung, indem es technische Änderungen mit den unterstützten Geschäftsfunktionen verknüpft.

Das Attribut stellt den Bezug zwischen IT-Änderungen und dem geschäftlichen Kontext her. So lässt sich analysieren, welche Geschäftsservices am stärksten von Änderungen und den damit verbundenen Risiken betroffen sind.

Im Hauptdatensatz des Änderungsantrags zu finden, häufig mit Verknüpfung zu einer Configuration Management Database (CMDB).

Die Endzeit des Ereignisses markiert den Abschluss einer Aktivität. Zusammen mit der Startzeit des Ereignisses ermöglicht sie die genaue Berechnung der Verarbeitungszeit jedes Schritts im Lebenszyklus einer Änderung.

Dieses Attribut ist grundlegend für die Leistungsanalyse. Die Differenz zwischen Start- und Endzeit zeigt die Verarbeitungszeit einer Aktivität. Die Zeit zwischen dem Ende einer Aktivität und dem Beginn der nächsten entspricht der Wartezeit. Diese Unterscheidung zeigt, ob Verzögerungen durch langwierige Aufgaben oder durch Leerlauf zwischen Aufgaben entstehen, und hilft, Verbesserungsmaßnahmen gezielt auszurichten.

Damit lassen sich Aktivitätsdauern genau berechnen und wertschöpfende Verarbeitungszeit von nicht wertschöpfender Wartezeit unterscheiden.

Häufig im Aktivitätsprotokoll oder in Audit-Tabellen zu finden. Falls der Wert fehlt, lässt er sich manchmal aus der Startzeit des nachfolgenden Ereignisses ableiten.

Die Änderungspriorität gibt an, wie wichtig ein Änderungsantrag im Verhältnis zu anderen ist. Sie hilft Teams, Termine und Ressourcen sinnvoll zu planen, damit besonders kritische Änderungen zuerst bearbeitet werden. Die Priorität wird häufig anhand der möglichen Auswirkungen der Änderung auf das Unternehmen und der Dringlichkeit ihrer Umsetzung bestimmt.

Im Process Mining ist die Priorität eine wichtige Dimension für Filter und Vergleiche. Analysten können untersuchen, ob Änderungen mit hoher Priorität tatsächlich schneller bearbeitet werden als solche mit niedriger Priorität. Abweichungen können auf Probleme bei der Ressourcenverteilung, Genehmigungsengpässe bei kritischen Änderungen oder eine uneinheitliche Anwendung der Priorisierungsregeln hindeuten.

Damit lässt sich prüfen, ob Änderungen mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität. So können Unternehmen die Wirksamkeit ihrer Priorisierungsregeln bewerten.

Im Hauptdatensatz oder in den Kopfdaten des Änderungsantrags zu finden.

Die Risikostufe gibt die geschätzte Wahrscheinlichkeit und die möglichen negativen Auswirkungen an, falls eine Änderung scheitert. Diese Einschätzung beeinflusst den erforderlichen Umfang von Tests, Prüfungen und Genehmigungen. Änderungen mit hohem Risiko werden in der Regel gründlicher geprüft als Änderungen mit niedrigem Risiko.

Dieses Attribut ermöglicht eine risikobasierte Prozessanalyse. Damit lässt sich prüfen, ob Änderungen mit hohem Risiko angemessen geprüft werden, zum Beispiel durch ein Change Advisory Board (CAB). Außerdem können Risikostufen mit Ergebnissen verglichen werden. So lässt sich feststellen, ob Änderungen mit hohem Risiko häufiger scheitern, was auf Verbesserungsbedarf bei der Risikobewertung oder den Maßnahmen zur Risikominderung hindeuten kann.

Damit lässt sich analysieren, ob Prozesskontrollen und Genehmigungs-Workflows auf das bewertete Risiko der Änderung abgestimmt sind.

In den Kopfdaten oder den Details zur Risikobewertung eines Änderungsantrags zu finden.

Der verantwortliche Benutzer ist die Person, der ein Änderungsantrag oder eine Aktivität zugewiesen wurde. Dieses Attribut zeigt die Arbeitslast und Zuständigkeit detaillierter als eine Zuweisung auf Teamebene.

Die Analyse auf Benutzerebene kann das Leistungsmanagement unterstützen und Schulungsbedarf aufzeigen. Sie kann Personen mit besonderer Prozesserfahrung sichtbar machen oder zeigen, wer bei bestimmten Aufgaben Unterstützung benötigt. Auch Nacharbeit lässt sich untersuchen, etwa indem geprüft wird, ob Änderungen bestimmter Personen häufiger abgelehnt werden oder Nachbesserungen erfordern. Die Informationen sollten jedoch konstruktiv und nicht für Sanktionen verwendet werden.

Das Attribut ermöglicht eine detaillierte Analyse der individuellen Arbeitslast und Leistung. So lassen sich Fachleute und möglicher Schulungsbedarf in den Teams erkennen.

Üblicherweise im Datensatz des Änderungsantrags oder in den Aufgabendetails zu finden. Die Bezeichnung lautet häufig „Zugewiesen an“ oder „Zuständig“.

Das verantwortliche Team bezeichnet die Gruppe, die in einer bestimmten Phase mit der Änderung betraut ist. Dazu können ein Bewertungsteam, ein Genehmigungsgremium wie das CAB oder das technische Team gehören, das die Änderung umsetzt.

Dieses Attribut ist wichtig für die Analyse der Ressourcenzuweisung, der Arbeitslastverteilung und der Übergaben zwischen Teams. Eine soziale Netzwerkanalyse kann Kommunikationsmuster und Engpässe zwischen verschiedenen Gruppen sichtbar machen. Wenn Unternehmen messen, wie viel Zeit eine Änderung bei den einzelnen Teams verbringt, können sie überlastete Gruppen und häufige Verzögerungen bei Verantwortungsübergaben erkennen.

Das Attribut ist entscheidend, um Übergaben zwischen Teams zu analysieren, Ressourcenengpässe zu erkennen und die Arbeitslastverteilung im Unternehmen zu verstehen.

Im Datensatz des Änderungsantrags oder in den Aktivitätsdetails zu finden. Die Bezeichnung kann „Zuweisungsgruppe“ oder „Team“ lauten.

Der Änderungsgrund beschreibt den geschäftlichen Anlass für einen Änderungsantrag. Er beantwortet die Frage „Warum führen wir diese Änderung durch?“ und liefert Kontext, zum Beispiel „Sicherheitsupdate für eine kritische Schwachstelle“ oder „Neue Funktion zur Verbesserung der Customer Experience“.

Auch wenn dieses Attribut häufig ein Freitextfeld ist, kann es bei einer Kategorisierung oder Textanalyse wertvolle qualitative Erkenntnisse liefern. Es hilft zu verstehen, aus welchen Unternehmensbereichen Änderungsbedarf entsteht. Eine Analyse kann beispielsweise zeigen, dass ein großer Anteil der Änderungen auf Fehlerbehebungen zurückgeht, was auf Probleme mit der Softwarequalität hindeuten kann. In einem anderen Zeitraum könnten dagegen viele Änderungen mit strategischen Projekten zusammenhängen.

Das Attribut liefert den geschäftlichen Kontext für Änderungen und hilft, die wichtigsten Auslöser für Veränderungen im Unternehmen zu analysieren.

Üblicherweise im ursprünglichen Einreichungsformular oder in den Kopfdaten des Änderungsantrags zu finden.

Die Auswirkungen einer Änderung geben an, welche Folgen sie für den Geschäftsbetrieb, Services oder die Infrastruktur haben kann. Zusammen mit der Dringlichkeit sind sie ein wichtiger Faktor für die Gesamtpriorität der Änderung. Eine Änderung, die einen geschäftskritischen, kundenorientierten Service betrifft, hat beispielsweise hohe Auswirkungen.

Die Analyse nach Auswirkungen hilft sicherzustellen, dass Änderungen an kritischen Services angemessen behandelt werden. Bei der Konformitätsprüfung lässt sich kontrollieren, ob Änderungen mit hohen Auswirkungen stets bestimmte Genehmigungs- oder Testphasen durchlaufen. Auch Leistungsvergleiche sind möglich, etwa um zu prüfen, ob Änderungen mit hohen Auswirkungen wegen umfangreicherer Prüfungen und Tests länger dauern.

Damit lässt sich prüfen, ob Änderungen mit erheblichen geschäftlichen Auswirkungen gründlicher geprüft und getestet werden. So wird eine angemessene Governance sichergestellt.

Im Hauptdatensatz oder in den Kopfdaten des Änderungsantrags zu finden.

Die Dringlichkeit einer Änderung gibt an, wie schnell sie umgesetzt werden muss, um geschäftliche Anforderungen zu erfüllen. Sie beschreibt die zeitliche Kritikalität unabhängig von den möglichen Auswirkungen. Eine Änderung kann geringe Auswirkungen haben, aber dennoch dringend sein, etwa wenn ein kleiner Fehler vor dem Start einer Marketingkampagne behoben werden muss.

Die Dringlichkeit ist ein wichtiger Faktor bei der Berechnung der Priorität und dient dazu, die Reaktionsfähigkeit des Änderungsmanagementprozesses zu analysieren. Analysten können prüfen, ob dringende Änderungen tatsächlich schneller bearbeitet werden. Der Vergleich der Zykluszeiten nach Dringlichkeitsstufe zeigt, ob der Prozess auf geschäftliche Anforderungen reagiert oder alle Änderungen unabhängig von ihrer zeitlichen Kritikalität gleich schnell behandelt.

Der Vergleich der Zykluszeiten nach Dringlichkeitsstufe zeigt, wie gut der Prozess auf zeitkritische geschäftliche Anforderungen reagiert.

Im Hauptdatensatz oder in den Kopfdaten des Änderungsantrags zu finden.

Das geplante Abschlussdatum ist die Frist für die Änderung. Sie wird häufig durch geschäftliche Anforderungen oder Service Level Agreements (SLAs) festgelegt und dient als Maßstab für die Termintreue und Leistung des Änderungsmanagementprozesses.

Dieses Attribut ist für die Analyse der SLA-Leistung unverzichtbar. Durch den Vergleich des tatsächlichen mit dem geplanten Abschlussdatum können Unternehmen die Abschlussquote zum geplanten Termin berechnen, eine wichtige Leistungskennzahl. Die Analyse von Änderungen, deren geplante Termine nicht eingehalten wurden, hilft, die Ursachen für Verzögerungen zu erkennen. Dazu zählen etwa Genehmigungsengpässe, begrenzte Ressourcen oder unrealistische Planungen.

Dieses Attribut ist wichtig, um die SLA-Konformität und die termingerechte Umsetzung zu messen und die Ursachen für Prozessverzögerungen zu erkennen.

Üblicherweise in den Kopfdaten des Änderungsantrags zu finden.

Der Grund für das Änderungsergebnis erläutert, warum ein Änderungsantrag auf diese Weise abgeschlossen wurde. Bei erfolgreichen Änderungen kann der Wert „Erfolgreich“ lauten. Bei gescheiterten Änderungen etwa „Nicht erfolgreich, Rollback eingeleitet“. Bei abgelehnten oder stornierten Änderungen nennt er die Begründung, zum Beispiel „Unzureichende Begründung“ oder „Vom Antragsteller storniert“.

Dieses Attribut ist entscheidend für die Ursachenanalyse bei gescheiterten oder abgelehnten Änderungen. Durch die Kategorisierung und Analyse der Gründe können Unternehmen wiederkehrende Fehlermuster erkennen. Werden beispielsweise viele Änderungen wegen „Unvollständiger Angaben“ abgelehnt, deutet das auf Verbesserungsbedarf beim Einreichungsprozess hin. Die Daten helfen außerdem, Kennzahlen wie die Änderungsfehlerrate und die Genehmigungsquote beim ersten Durchlauf zu berechnen und zu verstehen.

Das Attribut liefert wichtige Daten für die Ursachenanalyse gescheiterter, abgelehnter oder stornierter Änderungen und hilft, die Qualität künftiger Änderungsanträge zu verbessern.

In den Abschlussdetails des Änderungsantrags zu finden. Die Bezeichnung kann „Abschlusscode“, „Lösung“ oder „Ablehnungsgrund“ lauten.