Ihr Daten-Template für das Change Management

Dieses Attribut erfasst den Namen der Aktivität, die zu einem bestimmten Zeitpunkt für einen Change Request stattgefunden hat. Die Aktivitäten werden aus Statusübergängen, Workflow-Schritten oder bestimmten Log-Einträgen in Jira abgeleitet, etwa „Change Submitted For Review“ oder „Implementation Started“.

Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten bildet den Kern von Process Mining. Sie ermöglicht es, die tatsächlichen Prozessabläufe zu ermitteln, Engpässe zwischen Schritten zu erkennen und Prozessvarianten mit der Standardarbeitsanweisung zu vergleichen.

Es definiert die Prozessschritte und ist damit entscheidend für die Ermittlung von Prozessmodellen, die Analyse von Varianten und die Identifikation von Engpässen.

Wird in der Regel aus der Jira-Vorgangshistorie abgeleitet, insbesondere aus Statusübergängen oder Aktualisierungen benutzerdefinierter Felder, die Prozessmeilensteine abbilden.

Die Change-Request-ID ist der Primärschlüssel, der jede Change-Initiative in Jira Service Management eindeutig identifiziert. Sie dient im Process Mining als Case-Kennung und verknüpft alle Events, Statusänderungen und Aktualisierungen zu einer zusammenhängenden End-to-End-Sicht auf den Prozess.

In der Analyse ermöglicht diese ID die Rekonstruktion des vollständigen Lebenszyklus jedes Changes. Sie ist entscheidend, um einzelne Changes durch Phasen wie Risikobewertung, Genehmigung, Implementierung und Prüfung zu verfolgen. Alle Kennzahlen, KPIs und Dashboards verwenden dieses Attribut, um Event-Daten eines bestimmten Changes korrekt zu aggregieren und miteinander zu verknüpfen.

Dies ist die grundlegende Case-Kennung. Sie ermöglicht es, den vollständigen Ablauf eines Change Requests nachzuverfolgen und seine Leistung zu analysieren.

Dies ist der standardmäßige Jira Issue Key im Feld key für Vorgänge des Typs Change Request.

Die Startzeit beziehungsweise der Event-Timestamp markiert das genaue Datum und die Uhrzeit, zu denen eine Aktivität für einen Change Request erfasst wurde. Jede Aktivität im Event Log, von der Erstellung bis zum Abschluss, verfügt über einen zugehörigen Timestamp.

Dieses Attribut ist für alle zeitbezogenen Analysen im Process Mining entscheidend. Es dient zur Berechnung von Durchlaufzeiten, Zeitspannen zwischen Aktivitäten und Wartezeiten sowie zur Bestimmung der Ereignisreihenfolge. Außerdem bildet es die Grundlage für Leistungsüberwachung, SLA-Berechnungen und die Identifikation von Engpässen.

Dieser Timestamp bildet die Grundlage für alle Analysen von Leistung und Dauer. Er ermöglicht die Berechnung von Durchlaufzeiten und die Identifizierung von Verzögerungen.

Der Timestamp jedes Eintrags im Jira-Issue-Historienprotokoll. Beim Erstellungsereignis handelt es sich um das Feld created.

Dieses Attribut erfasst Datum und Uhrzeit, zu denen die Daten zuletzt aus dem Quellsystem abgerufen wurden. Es beschreibt die Aktualität der Daten innerhalb des Process-Mining-Tools.

Die Analyse dieses Attributs zeigt, wie aktuell die Prozessdaten sind. Das ist für operative Dashboards und die Überwachung in Echtzeit wichtig. Außerdem liefert es Kontext für die Analyse und stellt sicher, dass Entscheidungen nicht auf veralteten Daten beruhen.

Gibt die Aktualität der Daten an und stellt sicher, dass Analysen relevant sind und auf aktuellen Informationen beruhen.

Dies ist ein Metadatenfeld, das beim Abruf der Daten durch das Datenextraktionswerkzeug befüllt wird.

Dieses Attribut gibt das Quellsystem an, aus dem die Prozessdaten stammen. In diesem Kontext lautet der Wert immer „Jira Service Management“.

In einem übergreifenden Unternehmenskontext, in dem Daten aus mehreren Systemen zusammengeführt werden, ist dieses Feld für die Datenherkunft, die Fehlerbehebung und das Verständnis systemspezifischer Prozessvarianten entscheidend. Es schafft Klarheit über den Ursprung der analysierten Daten.

Stellt eine klare Datenherkunft bereit. Das ist besonders wichtig, wenn Daten aus mehreren Systemen zusammengeführt oder Prüfungen durchgeführt werden.

Dies ist ein statischer Wert, der während der Datenextraktion ergänzt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Dieses Attribut gibt den Status des Änderungsantrags an, etwa „Awaiting Approval“, „In Progress“ oder „Closed“. Das Statusfeld in Jira ist ein zentraler Bestandteil der Workflow-Engine. Änderungen an diesem Feld steuern den Prozessablauf maßgeblich.

Die Statusanalyse ermöglicht es, den Fortschritt aktiver Änderungen zu verfolgen und die Ergebnisse abgeschlossener Änderungen zu verstehen, beispielsweise „Closed - Successful“ im Vergleich zu „Closed - Failed“. Das Attribut ist entscheidend für Throughput-Dashboards und die Analyse von Nacharbeitschleifen, bei denen ein Status in einen vorherigen Zustand zurückkehrt.

Es bietet einen klaren Überblick über den Fortschritt und das Endergebnis eines Änderungsantrags. Das ist für die Analyse von Durchsatz und Nacharbeit entscheidend.

Dies ist das standardmäßige status-Feld eines Jira-Issues. Die verfügbaren Status werden in der Workflow-Konfiguration des Projekts definiert.

Der Änderungstyp kategorisiert den Änderungsantrag nach Art, Dringlichkeit und Auswirkung. Zu den gängigen Typen gehören „Standard“ für vorab genehmigte Änderungen mit geringem Risiko, „Normal“ für routinemäßige Änderungen mit vollständiger Genehmigung und „Emergency“ für dringende Änderungen zur Behebung von Incidents.

Dieses Attribut ist für die Prozessanalyse entscheidend, da unterschiedliche Änderungstypen häufig verschiedenen Prozesspfaden folgen und unterschiedliche SLAs haben. Es wird zur Berechnung des KPI „Emergency Change Rate“ verwendet und ermöglicht es, Dashboards zu filtern, um Leistung und Risiko der einzelnen Typen zu vergleichen.

Es ermöglicht die Segmentierung des Prozesses, um unterschiedliche Workflows zu analysieren, etwa Standard- und Emergency-Änderungen mit jeweils eigenen Leistungserwartungen und Risiken.

Dies ist in der Regel ein benutzerdefiniertes Feld in Jira-Service-Management-Projekten. Der Feldname kann abweichen, lautet aber häufig „Change Type“.

Der Bearbeiter ist der Benutzer, der für den aktuellen Schritt oder die aktuelle Aktivität im Change-Management-Workflow verantwortlich ist. Im Lebenszyklus eines Änderungsantrags kann sich der Bearbeiter mehrfach ändern, wenn die Aufgabe zwischen verschiedenen Personen und Teams weitergegeben wird.

Dieses Attribut dient zur Analyse der Arbeitslastverteilung, zur Identifizierung benutzerspezifischer Engpässe und zum Verständnis der Ressourcenverteilung. Das Dashboard „Change Team Activity Workload“ verwendet diese Daten, um zu zeigen, welche Personen oder Gruppen die meisten Aktivitäten bearbeiten.

Dies unterstützt die Analyse von Ressourcenleistung und Arbeitslastverteilung und macht Engpässe bei einzelnen Personen oder Teams sichtbar.

Dies ist das standardmäßige assignee-Feld eines Jira-Issues.

Das Feld „Priority“ unterstützt Teams dabei, die Reihenfolge für die Bearbeitung von Änderungsanträgen festzulegen. Es bildet eine Kombination aus Auswirkung und Dringlichkeit ab und steuert Planung sowie Ressourcenverteilung.

Die Analyse der Priorität ermöglicht Leistungsvergleiche zwischen Änderungen mit hoher und niedriger Priorität. So lässt sich beispielsweise prüfen, ob Änderungen mit hoher Priorität tatsächlich kürzere Durchlaufzeiten haben oder an denselben Engpässen wie andere Änderungen festhängen. Das ist wertvoll, um den Ressourceneinsatz zu optimieren und geschäftliche Erwartungen zu erfüllen.

Ermöglicht die Analyse der Prozessleistung anhand der geschäftlichen Priorität und stellt sicher, dass kritische Änderungen wie erwartet beschleunigt werden.

Dies ist das standardmäßige priority-Feld eines Jira-Issues.

Die Risikostufe ist in den meisten Change-Management-Prozessen eine verpflichtende Bewertung. Sie klassifiziert die potenziellen negativen Auswirkungen einer Änderung. Die Einstufung erfolgt häufig während der Risikobewertung und beeinflusst den erforderlichen Genehmigungsworkflow.

Im Process Mining ist dieses Attribut für eine risikobasierte Analyse entscheidend. Es unterstützt das Dashboard „Risk Assessment Accuracy & Outcome“, indem es das ursprüngliche Risiko mit dem tatsächlichen Ergebnis verknüpft. Außerdem bildet es die zentrale Dimension für den KPI „Change Failure Rate by Risk Level“ und hilft zu bewerten, ob Änderungen mit hohem Risiko wirksam gesteuert werden.

Ermöglicht die Analyse, ob Prozesskontrollen und Genehmigungsworkflows für unterschiedliche Risikoprofile wirksam sind, und unterstützt die Verknüpfung von Risiko und Ausfallrate von Änderungen.

Dies ist in Jira Service Management in der Regel ein benutzerdefiniertes Feld. Übliche Bezeichnungen sind „Risk Level“ oder „Impact“.

Dieses berechnete Attribut vergleicht das tatsächliche Auflösungsdatum eines Änderungsantrags mit seinem „Target Completion Date“. Das Ergebnis ist ein einfacher Status wie „Met“ oder „Breached“.

Es liefert für das Dashboard „Change SLA Performance Monitor“ einen klaren Überblick über die Leistung. KPIs wie „Change SLA Adherence Rate“ lassen sich einfacher erstellen, da der Status für jeden Case vorab berechnet wird. Dadurch können Sie leicht filtern und aggregieren, welche Änderungstypen, Teams oder Services besonders häufig SLA-Verstöße aufweisen.

Liefert für jeden Case ein klares binäres Ergebnis zur SLA-Leistung und vereinfacht dadurch die Berichterstattung und Analyse der SLA-Einhaltung.

Wird durch den Vergleich des Timestamps der abschließenden Aktivität „Change Closed“ mit dem Attribut „TargetCompletionDate“ berechnet.

Dieses Attribut speichert das Datum, bis zu dem der Änderungsantrag zur Einhaltung seines SLA abgeschlossen sein soll. Es dient als Referenz für die Messung der tatsächlichen Abschlusszeit.

Der Zieltermin ist für die Überwachung der Leistung im Verhältnis zu eingegangenen Verpflichtungen grundlegend. Er bildet die Basis für das Dashboard „Change SLA Performance Monitor“ und den KPI „Change SLA Adherence Rate“. Durch den Vergleich des tatsächlichen Abschlussdatums mit diesem Ziel können Unternehmen die Wirksamkeit ihrer Servicebereitstellung messen.

Dies ist der zentrale Datenpunkt zur Berechnung der SLA-Einhaltung und zur Identifizierung von Änderungen, bei denen ein Fristverstoß droht.

Dies ist in Jira häufig das Feld duedate oder ein Wert aus einer konfigurierten SLA-Metrik in Jira Service Management.

Dieses Attribut erfasst den zugrunde liegenden Grund für die Änderung, beispielsweise „New Feature Implementation“, „Bug Fix“ oder „Infrastructure Upgrade“. Es liefert wichtigen Kontext über die Zusammenfassung oder Beschreibung hinaus.

In der Analyse kann der Änderungsgrund mit anderen Kennzahlen wie Durchlaufzeit, Ausfallrate und Risikostufe verknüpft werden. So lässt sich beispielsweise beantworten, ob Änderungen zur Fehlerbehebung schneller genehmigt werden als die Implementierung neuer Funktionen oder ob Infrastruktur-Upgrades eine höhere Ausfallrate haben.

Liefert geschäftlichen Kontext für eine vertiefte Analyse, indem der Zweck einer Änderung mit ihrer Leistung und ihrem Ergebnis verknüpft wird.

Dies ist in Jira Service Management üblicherweise ein benutzerdefiniertes Feld, häufig eine Auswahlliste oder ein Textfeld.

Nach dem Abschluss eines Änderungsantrags liefert das Feld „Resolution“ konkrete Informationen zum Ergebnis. „Done“ steht beispielsweise für einen erfolgreichen Abschluss, während „Won't Do“ oder „Duplicate“ andere Abschlussgründe angeben. Dadurch entsteht ein genaueres Bild als durch den Status „Closed“ allein.

Dieses Attribut ist für die Analyse von Erfolgs- und Ausfallraten von Änderungen entscheidend. Der KPI „Post-Implementation Issue Rate“ lässt sich beispielsweise besser verstehen, wenn nach Änderungen mit der Auflösung „Failed“ oder „Rolled Back“ gefiltert wird. So können erfolgreich implementierte Änderungen von solchen unterschieden werden, die nach der Genehmigung abgebrochen oder abgelehnt wurden.

Liefert detaillierten Kontext zum Endergebnis einer Änderung und ist damit für die genaue Berechnung von Erfolgs- und Ausfallraten entscheidend.

Dies ist das standardmäßige resolution-Feld in Jira. Es wird üblicherweise gesetzt, wenn ein Issue in eine Statuskategorie „Done“ wechselt.

Dieses Attribut verknüpft den Änderungsantrag mit einem bestimmten Geschäftsservice aus der Configuration Management Database (CMDB), beispielsweise „Email Service“ oder „Customer CRM“. Das ist ein zentraler Aspekt, um die geschäftlichen Auswirkungen einer Änderung zu verstehen.

Die Analyse von Änderungen nach Geschäftsservice hilft dabei, Maßnahmen zu priorisieren und Stakeholder über Auswirkungen zu informieren. Sie zeigt, bei welchen Services die meisten Änderungen stattfinden, welche Services besonders gefährdet sind und wo sich durch Änderungen verursachte Incidents konzentrieren. Das ist für die Steuerung technischer Änderungen aus geschäftlicher Sicht entscheidend.

Verknüpft technische Änderungen mit geschäftlichen Auswirkungen und ermöglicht Priorisierung sowie Risikoanalyse anhand der Kritikalität des betroffenen Services.

Dies ist in JSM häufig ein benutzerdefiniertes Feld, das oft mit Jira Assets, früher Insight, oder einer anderen CMDB verknüpft ist.

Dieses berechnete Attribut identifiziert Änderungsanträge, die zur Überarbeitung an eine frühere Prozessstufe zurückgesendet wurden, beispielsweise von „Awaiting Approval“ zurück zu „Planning“. Es weist darauf hin, dass die ursprüngliche Einreichung unvollständig oder fehlerhaft war oder die erforderlichen Kriterien nicht erfüllte.

Dieses Kennzeichen bildet die Grundlage für den KPI „Change Rework Rate“ und das Dashboard „Change Rework and Rejection Analysis“. Durch die Kennzeichnung von Nacharbeitsfällen können Analysten gezielt danach filtern und Ursachen wie unzureichende Erstplanung, unklare Anforderungen oder eine unvollständige Risikobewertung untersuchen.

Macht ineffiziente Prozesse sichtbar, indem Fälle mit zusätzlicher, ungeplanter Arbeit ausdrücklich gekennzeichnet werden. Dadurch lassen sich die Ursachen der Nacharbeit analysieren.

Wird durch die Analyse der Aktivitätsfolge im Event Log berechnet. Nacharbeit liegt vor, wenn auf eine Aktivität einer späteren Prozessstufe eine Aktivität einer früheren Stufe folgt.

Der Meldende ist die Person, die das Änderungsantrags-Issue in Jira erstellt hat. Dabei handelt es sich häufig um den Change Owner oder um eine Person, die die Änderung im Namen eines Teams initiiert.

Die Analyse des Meldenden kann zeigen, welche Abteilungen, Teams oder Personen die meisten Änderungen initiieren. Außerdem lassen sich Trends bei den Quellen von Änderungen erkennen und gezielt Rückmeldungen oder Schulungen für Gruppen anbieten, die häufig unvollständige oder qualitativ unzureichende Änderungsanträge einreichen.

Hilft dabei, die Quellen von Änderungsanträgen zu identifizieren und die Qualität der ursprünglichen Einreichungen gezielt zu verbessern.

Dies ist das standardmäßige reporter-Feld eines Jira-Issues.

Dieses Attribut gibt an, ob die Änderung zu einem negativen Ergebnis geführt hat, beispielsweise zu einem Incident in der Produktionsumgebung. Dazu wird der Änderungsantrag häufig mit einem oder mehreren Incident-Issues in Jira verknüpft.

Diese Daten sind für die Berechnung der KPIs „Post-Implementation Issue Rate“ und „Change Failure Rate“ entscheidend. Sie liefern ein direktes Maß für die Qualität einer Änderung sowie für die Wirksamkeit von Planung, Tests und Risikobewertung. Die Analyse der Änderungen, die zu Problemen führen, hilft dabei, Kontrollen zu verbessern und künftige Ausfälle zu vermeiden.

Misst direkt die Qualität und den Erfolg einer Änderung, indem erfasst wird, ob sie nachfolgende betriebliche Probleme verursacht hat.

Wird üblicherweise durch die Prüfung verknüpfter Issues in Jira abgeleitet, insbesondere wenn ein Change-Issue über „is caused by“-Verknüpfungen mit Incident-Issues verbunden ist.

Dieses Attribut gibt das Team an, das mit der Bearbeitung der Änderung beauftragt ist. Während Jira mit dem Feld „Assignee“ einzelne Personen zuweist, wird ein Feld „Team“ häufig verwendet, um Aufgaben einer funktionalen Gruppe wie „Network Operations“ oder „Database Administrators“ zuzuordnen.

Das ist für das Dashboard „Change Team Activity Workload“ entscheidend. Es ermöglicht die Analyse von Leistung und Engpässen auf Teamebene statt nur auf Ebene einzelner Personen. Für die Ressourcenplanung und das Management ist diese Sicht häufig aussagekräftiger.

Unterstützt die Analyse von Arbeitslast und Leistung auf Team- oder Abteilungsebene und macht systemische Engpässe sichtbar.

Dies ist in Jira üblicherweise ein benutzerdefiniertes Feld, da kein standardmäßiges Feld „Team“ vorhanden ist. Es kann vom Typ „Group Picker“ oder eine einfache Auswahlliste sein.