Ihr Daten-Template für Change Management

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

Dieses Attribut ist grundlegend für den Aufbau der Prozessübersicht. Es definiert die Knoten im Prozessgraphen und ermöglicht Analysten, die Ereignisfolge zu visualisieren, häufige Abläufe zu erkennen und Abweichungen vom Standardverfahren festzustellen. Die Analyse von Aktivitäten hilft, Engpässe, Überarbeitungsschleifen und ineffiziente Übergaben zwischen den verschiedenen Phasen des Änderungsprozesses aufzudecken.

Es definiert die Prozessschritte und ermöglicht die Visualisierung des Prozessablaufs sowie die Analyse von Engpässen, Überarbeitungen und Abweichungen.

Befindet sich üblicherweise in einem Aktivitätsprotokoll, einer Ereignishistorie oder einer Audit-Trail-Tabelle, die dem Änderungsantrag zugeordnet ist.

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

Im Process Mining ist dieses Attribut entscheidend für die Rekonstruktion des durchgängigen Ablaufs jeder Änderung. Durch die Gruppierung aller Ereignisse unter einer gemeinsamen ID des Änderungsantrags können Analysten Prozessabläufe visualisieren, Case-Dauern berechnen und Abweichungen zwischen verschiedenen Änderungszyklen analysieren. Sie bildet die Grundlage für jede Analyse auf Case-Ebene und ermöglicht einen klaren Überblick darüber, wie einzelne Änderungen das System durchlaufen.

Diese ID ist entscheidend, um alle Ereignisse eines einzelnen Änderungsantrags nachzuverfolgen und miteinander zu verknüpfen. Damit bildet sie das Fundament für Process Discovery und Konformitätsprüfung.

Sie befindet sich typischerweise im Kopfbereich oder im primären Datensatz einer Transaktion für einen Änderungsantrag.

Die Startzeit des Ereignisses markiert den Beginn einer Aktivität im Lebenszyklus des Änderungsantrags. Dieser Timestamp ist entscheidend für die chronologische Reihenfolge der Ereignisse sowie für die Berechnung der Dauer einzelner Aktivitäten und des gesamten Cases.

In der Prozessanalyse wird dieses Attribut verwendet, um Aktivitäten korrekt zu ordnen und damit die Grundlage des Event Logs zu bilden. Es ist für die Berechnung aller zeitbezogenen Kennzahlen erforderlich, etwa der Durchlaufzeiten zwischen Aktivitäten, Wartezeiten und der gesamten Case-Dauer. Durch die Analyse dieser Timestamps können Unternehmen erkennen, welche Schritte am meisten Zeit beanspruchen, und Ansatzpunkte für eine Beschleunigung des Prozesses identifizieren.

Dieser Timestamp ist entscheidend für die Sortierung von Ereignissen, die Ermittlung des Prozessablaufs und die Berechnung aller Leistungskennzahlen wie Durchlauf- und Wartezeiten.

Befindet sich im Event Log oder Audit Trail des Änderungsantrags. Das Feld kann „Erstellungsdatum“, „Startdatum“ oder einfach „Timestamp“ heißen.

Der Timestamp der letzten Datenaktualisierung gibt an, wann ein bestimmter Datensatz zuletzt aus dem Quellsystem abgerufen wurde. Dieses Metadatenattribut ist für die Verwaltung der Datenpipeline und die Aktualität der Analyse entscheidend.

Es hilft Dateningenieuren und Analysten, die Aktualität der verwendeten Daten einzuschätzen. Außerdem wird es verwendet, um den Zustand des Datenextraktionsprozesses 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, ist aber für Data Governance und Zuverlässigkeit von großer Bedeutung.

Es stellt die Aktualität der Daten sicher und unterstützt die Überwachung des Zustands der Datenpipeline, was für die Zuverlässigkeit der Prozessanalyse entscheidend ist.

Dieser Timestamp wird typischerweise während des Datenextraktions-, Transformations- und Ladeprozesses (ETL) erzeugt und ergänzt.

Das Attribut „Quellsystem“ identifiziert die Herkunft der Ereignisdaten. In Umgebungen mit mehreren ITSM-Tools oder integrierten Systemen hilft dieses Feld, Daten aus unterschiedlichen Quellen zu unterscheiden und so Datenintegrität und Kontext sicherzustellen.

Auch wenn es nicht immer für die primäre Analyse des Prozessablaufs verwendet wird, ist es für Datenvalidierung und Governance sehr wertvoll. Es unterstützt bei der Fehlerbehebung in der Datenaufnahme und ermöglicht den Vergleich der Prozessleistung zwischen verschiedenen Systemen oder Geschäftsbereichen, wenn diese separate Plattformen verwenden. Ein Unternehmen kann beispielsweise ein System für Infrastrukturänderungen und ein anderes für Anwendungsänderungen einsetzen.

Es identifiziert die Herkunft der Daten und ist damit entscheidend für Datenvalidierung, Fehlerbehebung und die Analyse von Prozessen, die sich über mehrere Systeme erstrecken.

Diese Information kann als Feld in den Quelldaten gespeichert oder während des Datenextraktions- und Transformationsprozesses (ETL) ergänzt werden.

Der Änderungsstatus gibt die Phase eines Änderungsantrags zu einem bestimmten Zeitpunkt oder dessen finales Ergebnis an. Statuswerte 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 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 betrachtet werden und das Event Log ergänzen, wenn detaillierte Aktivitätsdaten nur begrenzt verfügbar sind. Die Analyse von Statusübergängen hilft, den Lebenszyklus zu verstehen und festzustellen, an welchen Stellen Änderungen stecken bleiben.

Es liefert eine Momentaufnahme des Fortschritts der Änderung und ermöglicht die Analyse von Engpässen, Durchsatz und dem aktuellen Stand des Änderungsrückstands.

Befindet sich im Kopfsatz des Änderungsantrags. Historische Statusänderungen können in einem Audit Log gespeichert sein.

Der Änderungstyp ist eine entscheidende Kategorisierung, 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 erfordern aufgrund eines dringenden geschäftlichen Bedarfs eine beschleunigte Bearbeitung.

Die Analyse nach Änderungstyp gehört zu den Kernaufgaben der Change-Management-Analyse. Sie ermöglicht den Vergleich von Leistung und Compliance verschiedener Änderungs-Workflows. Analysten können beispielsweise prüfen, ob Notfalländerungen tatsächlich einen schnelleren Ablauf durchlaufen oder ob Standardänderungen ihrem vereinfachten, vorab genehmigten Ablauf folgen. Diese Segmentierung ist entscheidend, um Prozessvarianten zu verstehen und das angemessene Governance-Niveau sicherzustellen.

Dieses Attribut ist für die Segmentierung der Analyse unverzichtbar, da verschiedene Änderungstypen eigene vordefinierte Prozessabläufe, Genehmigungsanforderungen und Leistungserwartungen haben.

Befindet sich in den Haupt- oder Kopfdaten des Änderungsantrags.

Der betroffene Geschäftsservice bezeichnet die zentrale Geschäftsfunktion, etwa „E-Mail-Service“ oder „Online-Banking“, die durch die Änderung angepasst wird. Dabei kann es sich auch um ein bestimmtes technisches Configuration Item (CI) handeln, beispielsweise einen Server oder eine Anwendung, der bzw. die einen Geschäftsservice unterstützt.

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

Es verknüpft IT-Änderungen mit dem geschäftlichen Kontext und ermöglicht die Analyse, welche Geschäftsservices am stärksten von Änderungsaktivitäten und den damit verbundenen Risiken betroffen sind.

Befindet sich im Hauptdatensatz des Änderungsantrags und ist häufig über eine Configuration Management Database (CMDB) verknüpft.

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

Dieses Attribut ist grundlegend für die Leistungsanalyse. 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“ darstellt. Diese Unterscheidung ist entscheidend, um festzustellen, ob Verzögerungen durch lang dauernde Aufgaben oder durch Leerlauf zwischen Aufgaben entstehen, und gezielte Verbesserungen abzuleiten.

Es ermöglicht die präzise Berechnung von Aktivitätsdauern und hilft, wertschöpfende Bearbeitungszeit von nicht wertschöpfender Wartezeit zu unterscheiden.

Befindet sich häufig in Aktivitätsprotokollen oder Audit-Trail-Tabellen. Falls sie nicht verfügbar ist, kann sie manchmal aus der Startzeit des folgenden Ereignisses abgeleitet werden.

Die Änderungspriorität ist eine Klassifizierung zur Bestimmung der relativen Bedeutung eines Änderungsantrags. Sie hilft Teams, Termine und Ressourcen wirksam zu planen und sicherzustellen, dass die kritischsten Änderungen zuerst bearbeitet werden. Die Priorität wird häufig anhand der möglichen Auswirkungen der Änderung auf das Geschäft und der Dringlichkeit ihrer Umsetzung berechnet.

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

Sie ermöglicht die Analyse, ob Änderungen mit hoher Priorität schneller bearbeitet werden als Änderungen mit niedriger Priorität, und damit die Überprüfung der Wirksamkeit von Priorisierungsrichtlinien.

Befindet sich in den Haupt- oder Kopfdaten des Änderungsantrags.

Die Risikostufe beschreibt die bewertete Wahrscheinlichkeit und mögliche negative Auswirkung eines Fehlschlags der Änderung. Diese Bewertung beeinflusst den erforderlichen Umfang von Tests, Prüfung und Genehmigung. Änderungen mit hohem Risiko erfordern typischerweise einen strengeren Prüfprozess als Änderungen mit niedrigem Risiko.

Dieses Attribut ermöglicht eine risikobasierte Prozessanalyse. Es kann verwendet werden, um zu prüfen, ob Änderungen mit hohem Risiko die angemessene Prüfung erhalten, etwa durch ein Change Advisory Board (CAB). Außerdem lässt sich die Risikostufe mit Ergebnissen verknüpfen, beispielsweise um festzustellen, ob Änderungen mit hohem Risiko eine höhere Fehlerquote aufweisen. Dies kann darauf hindeuten, dass die Risikobewertung oder der Prozess zur Risikominderung verbessert werden muss.

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

Befindet sich in den Kopfdaten oder den Details der Risikobewertung eines Änderungsantrags.

Der verantwortliche Benutzer ist die konkrete Person, die einem Änderungsantrag oder einer Aktivität zugewiesen wurde. Dieses Attribut bietet eine detailliertere Sicht auf Arbeitslast und Verantwortung als die Zuweisung auf Teamebene.

Die Analyse auf Benutzerebene kann das Leistungsmanagement unterstützen und Schulungsbedarf aufzeigen. Sie kann Personen sichtbar machen, die über besondere Prozesserfahrung verfügen, oder solche, die bei bestimmten Aufgaben Schwierigkeiten haben. Außerdem lässt sich Überarbeitungsaufwand analysieren, etwa indem geprüft wird, ob von bestimmten Personen bearbeitete Änderungen häufiger abgelehnt werden oder Nachbesserungen erfordern. Die Informationen sollten jedoch konstruktiv und nicht für Sanktionen verwendet werden.

Er bietet eine detaillierte Sicht auf individuelle Arbeitslast und Leistung und hilft, Experten sowie möglichen Schulungsbedarf in Teams zu identifizieren.

Befindet sich typischerweise im Datensatz des Änderungsantrags oder in Aufgabendetails und ist häufig mit „Bearbeiter“ oder „Zugewiesen an“ bezeichnet.

Das verantwortliche Team identifiziert die Personengruppe, die in einer bestimmten Phase mit der Änderung betraut ist. Dies kann ein Bewertungsteam, ein Genehmigungsgremium wie das CAB oder das technische Team sein, das die Umsetzung durchführt.

Dieses Attribut ist für die Analyse der Ressourcenverteilung, der Arbeitslast und der Übergaben zwischen Teams entscheidend. Eine soziale Netzwerkanalyse kann Kommunikationsmuster und Engpässe zwischen verschiedenen Gruppen sichtbar machen. Durch die Messung der Zeit, die eine Änderung bei jedem Team verbringt, können Unternehmen überlastete Gruppen und häufige Verzögerungen bei der Übergabe von Verantwortlichkeiten erkennen.

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

Befindet sich im Datensatz des Änderungsantrags oder in den Details auf Aktivitätsebene. Das Feld kann „Zuständigkeitsgruppe“ oder „Team“ heißen.

Der Änderungsgrund ist eine textuelle Beschreibung des geschäftlichen Anlasses hinter dem Änderungsantrag. Er beantwortet die Frage „Warum führen wir diese Änderung durch?“ und liefert Kontext, etwa „Sicherheitspatch für eine kritische Schwachstelle“ oder „Neue Funktion zur Verbesserung der Customer Experience“.

Dieses Attribut wird häufig als Freitext erfasst. Wenn Sie es jedoch kategorisieren oder mit Text-Mining-Verfahren analysieren, kann es wertvolle qualitative Erkenntnisse liefern. So lässt sich besser verstehen, aus welchen Unternehmensbereichen der Bedarf für Änderungen entsteht. Eine Analyse kann beispielsweise zeigen, dass ein großer Anteil der Änderungen auf Fehlerbehebungen zurückgeht. Das kann auf mögliche Probleme mit der Softwarequalität hinweisen. In einem anderen Zeitraum kann dagegen ein hoher Anteil an Änderungen im Zusammenhang mit strategischen Projekten stehen.

Liefert den geschäftlichen Kontext dafür, warum Änderungen initiiert werden, und unterstützt die Analyse der wichtigsten Änderungstreiber innerhalb der Organisation.

Typischerweise im initialen Einreichungsformular oder in den Kopfdaten des Änderungsantrags zu finden.

Die Auswirkung der Änderung misst den möglichen Effekt einer Änderung auf Geschäftsabläufe, Services oder die Infrastruktur. Zusammen mit der Dringlichkeit ist sie ein wichtiger Faktor für die Bestimmung der Gesamtpriorität. Eine Änderung an einem kritischen, kundenorientierten Service hat beispielsweise eine hohe Auswirkung.

Die Analyse nach Auswirkungen hilft sicherzustellen, dass Änderungen an kritischen Services mit der erforderlichen Sorgfalt verwaltet werden. Bei der Konformitätsprüfung kann sie eingesetzt werden, um zu verifizieren, dass Änderungen mit hoher Auswirkung bestimmte Genehmigungs- oder Testphasen durchlaufen. Außerdem ermöglicht sie Leistungsvergleiche, etwa die Prüfung, ob Änderungen mit hoher Auswirkung aufgrund umfangreicherer Prüfungen und Tests länger bis zur Umsetzung benötigen.

Sie hilft zu überprüfen, ob Änderungen mit hoher geschäftlicher Auswirkung strengere Prüfungs- und Testabläufe durchlaufen und damit angemessene Governance gewährleistet ist.

Befindet sich in den Haupt- oder Kopfdaten des Änderungsantrags.

Die Dringlichkeit der Änderung gibt an, wie schnell eine Änderung 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 beispielsweise geringe Auswirkungen, aber hohe Dringlichkeit haben, etwa wenn ein kleiner Fehler vor dem Start einer Marketingkampagne behoben werden muss.

Die Dringlichkeit ist ein wichtiger Bestandteil der Prioritätsberechnung und dient zur Analyse der Termintreue im Change-Management-Prozess. Analysten können untersuchen, ob Änderungen mit hoher Dringlichkeit tatsächlich schneller bearbeitet werden. Der Vergleich von Durchlaufzeiten über verschiedene Dringlichkeitsstufen hinweg zeigt, ob der Prozess auf geschäftliche Anforderungen reagiert oder alle Änderungen unabhängig von ihrer zeitlichen Sensibilität gleich schnell behandelt.

Sie ermöglicht die Analyse der Reaktionsfähigkeit des Prozesses auf zeitkritische geschäftliche Anforderungen durch den Vergleich von Durchlaufzeiten über verschiedene Dringlichkeitsstufen hinweg.

Befindet sich in den Haupt- oder Kopfdaten des Änderungsantrags.

Das geplante Abschlussdatum ist die für die Änderung gesetzte Frist, die häufig durch geschäftliche Anforderungen oder Service Level Agreements (SLAs) bestimmt wird. Es dient als Referenz für die Messung der Termintreue und Leistung des Change-Management-Prozesses.

Dieses Attribut ist für die SLA-Leistungsanalyse entscheidend. Durch den Vergleich des tatsächlichen Abschlussdatums mit dem geplanten Datum können Unternehmen die Abschlussquote zum geplanten Termin berechnen, eine wichtige Leistungskennzahl. Die Analyse von Änderungen, deren geplante Termine verfehlt wurden, hilft, die Ursachen der Verzögerungen zu identifizieren, etwa Genehmigungsengpässe, begrenzte Ressourcen oder unrealistische Planung.

Dies ist ein wichtiges Attribut zur Messung der SLA-Konformität und termingerechten Lieferung. Es hilft, die Ursachen von Verzögerungen im Prozess zu identifizieren.

Befindet sich typischerweise in den Kopfdaten des Änderungsantrags.

Der Grund des Änderungsergebnisses liefert Kontext dazu, warum ein Änderungsantrag auf diese Weise beendet wurde. Bei erfolgreichen Änderungen kann der Wert „Erfolgreich“ lauten. Bei fehlgeschlagenen Änderungen beispielsweise „Nicht erfolgreich, Rollback eingeleitet“. Bei abgelehnten oder abgebrochenen Änderungen enthält er die Begründung, etwa „Unzureichende Begründung“ oder „Vom Antragsteller abgebrochen“.

Dieses Attribut ist für die Ursachenanalyse fehlgeschlagener oder abgelehnter Änderungen entscheidend. Durch die Kategorisierung und Analyse dieser Gründe können Unternehmen häufige Fehlermuster erkennen. Werden beispielsweise viele Änderungen wegen „Unvollständiger Informationen“ abgelehnt, weist dies auf Verbesserungsbedarf beim Einreichungsprozess hin. Die Daten unterstützen die Berechnung und Interpretation von KPIs wie Änderungsfehlerquote und Genehmigungsrate im ersten Durchlauf.

Es liefert wichtige Daten für die Ursachenanalyse fehlgeschlagener, abgelehnter oder abgebrochener Änderungen und hilft, die Qualität künftiger Änderungsanträge zu verbessern.

Befindet sich in den Abschlussdetails eines Änderungsantrags. Das Feld kann „Abschlusscode“, „Lösung“ oder „Ablehnungsgrund“ heißen.