Ihr Change Management Daten-Template

Dieses Attribut zeichnet den Namen der Aktivität auf, die zu einem bestimmten Zeitpunkt für einen Änderungsantrag stattfand. Diese Aktivitäten werden aus Statusübergängen, Workflow-Schritten oder spezifischen Protokolleinträgen in Jira abgeleitet, wie z.B. 'Change Submitted For Review' oder 'Implementation Started'.

Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten ist der Kern des Process Mining. Sie ermöglicht die Entdeckung der tatsächlichen Prozessabläufe, die Identifizierung von Engpässen zwischen den Schritten und die Analyse von Prozessvarianten im Vergleich zur Standardarbeitsanweisung.

Es definiert die Schritte des Prozesses, was wesentlich ist, um Prozesslandkarten zu entdecken, Varianten zu analysieren und Engpässe zu identifizieren.

Typischerweise abgeleitet aus dem Jira Issue-Verlauf, speziell aus Statusübergängen oder Updates von benutzerdefinierten Feldern, die Prozessmeilensteine repräsentieren.

Die Change Request ID ist der Primärschlüssel, der jede Änderungsinitiative in Jira Service Management eindeutig identifiziert. Sie dient als Case-Identifikator für Process Mining, indem sie alle Events, Statusänderungen und Updates zu einer kohärenten End-to-End-Prozessansicht verknüpft.

In der Analyse ermöglicht diese ID die Rekonstruktion des gesamten Lebenszyklus jeder Änderung. Sie ist unerlässlich, um einzelne Änderungen durch verschiedene Phasen wie Risikobewertung, Genehmigung, Implementierung und Überprüfung zu verfolgen. Alle Metriken, KPIs und Dashboards stützen sich auf dieses Attribut, um Event-Daten für einen spezifischen Case korrekt zu aggregieren und zu korrelieren.

Dies ist der grundlegende Case-Identifikator, der es ermöglicht, den gesamten Verlauf eines Änderungsantrags zu verfolgen und dessen Performance zu analysieren.

Dies ist der Standard Jira Issue Key, zu finden im Feld key für Issues vom Typ Change Request.

Die Startzeit, oder Event-Timestamp, markiert das genaue Datum und die Uhrzeit, zu der eine Aktivität für einen Änderungsantrag aufgezeichnet wurde. Jede Aktivität im Event Log, von der Erstellung bis zum Abschluss, hat einen zugehörigen Timestamp.

Dieses Attribut ist entscheidend für alle zeitbasierten Analysen im Process Mining. Es wird verwendet, um Zykluszeiten, Dauern zwischen Aktivitäten, Wartezeiten und die Reihenfolge der Events zu berechnen. Es bildet die Grundlage für Performance-Monitoring, SLA-Einhaltungsberechnungen und Engpass-Identifikation.

Dieser Timestamp ist die Grundlage für alle Performance- und Dauernanalysen, die die Berechnung von Zykluszeiten und die Identifizierung von Verzögerungen ermöglichen.

Der Timestamp jedes Eintrags im Jira-Issue-Verlaufsprotokoll. Für das Erstellungs-Event ist dies das Feld created.

Dieses Attribut zeichnet das Datum und die Uhrzeit auf, zu der die Daten zuletzt aus dem Quellsystem abgerufen wurden. Es repräsentiert die Aktualität der Daten innerhalb des Process Mining Tools.

Die Analyse dieses Attributs hilft Benutzern zu verstehen, wie aktuell die Prozessdaten sind, was für operative Dashboards und Echtzeit-Monitoring wichtig ist. Es bietet Kontext für die Analyse und stellt sicher, dass Entscheidungen nicht auf veralteten Daten getroffen werden.

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

Dies ist ein Metadatenfeld, das vom Datenextraktionstool zum Zeitpunkt des Datenabrufs gefüllt wird.

Dieses Attribut gibt das Quellsystem an, aus dem die Prozessdaten stammen. In diesem Kontext ist der Wert konsistent 'Jira Service Management'.

In einem breiteren Unternehmenskontext, wo Daten aus mehreren Systemen zusammengeführt werden könnten, ist dieses Feld entscheidend für die Datenherkunft, Fehlerbehebung und das Verständnis systemspezifischer Prozessvariationen. Es sorgt für Klarheit über den Ursprung der analysierten Daten.

Bietet eine klare Datenherkunft, die wesentlich ist, wenn Daten aus mehreren Systemen kombiniert werden oder für Auditzwecke.

Dies ist ein statischer Wert, der während der Datenextraktion hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen.

Der Änderungstyp kategorisiert den Änderungsantrag basierend auf seiner Art, Dringlichkeit und Auswirkung. Gängige Typen sind 'Standard' für vorab genehmigte, risikoarme Änderungen, 'Normal' für Routineänderungen, die eine vollständige Genehmigung erfordern, und 'Emergency' für dringende Änderungen zur Behebung von Vorfällen.

Dieses Attribut ist für die Prozessanalyse unerlässlich, da verschiedene Änderungstypen oft unterschiedliche Prozesspfade und SLAs aufweisen. Es wird verwendet, um den KPI 'Notfall-Änderungsrate' zu berechnen und Dashboards zu filtern, um die Performance und das Risiko jedes Typs zu vergleichen.

Es ermöglicht die Segmentierung des Prozesses, um verschiedene Workflows zu analysieren, wie z.B. Standard- vs. Notfalländerungen, die einzigartige Leistungserwartungen und Risiken aufweisen.

Dies ist typischerweise ein benutzerdefiniertes Feld in Jira Service Management-Projekten. Der Feldname kann variieren, wird aber oft 'Change Type' genannt.

Dieses Attribut gibt den Status des Änderungsantrags an, z.B. 'Genehmigung ausstehend', 'In Bearbeitung' oder 'Geschlossen'. Das Statusfeld in Jira ist fundamental für dessen Workflow-Engine, und Änderungen an diesem Feld sind die primären Treiber des Prozessflusses.

Die Analyse des Status ermöglicht es, den Fortschritt aktiver Änderungen zu verfolgen und die Ergebnisse abgeschlossener Änderungen zu verstehen, zum Beispiel 'Geschlossen – Erfolgreich' versus 'Geschlossen – Fehlgeschlagen'. Sie ist entscheidend für den Aufbau von Durchsatz-Dashboards und die Analyse von Nacharbeits-Schleifen, bei denen ein Status in einen vorherigen Zustand zurückkehrt.

Es bietet eine klare Sicht auf den Fortschritt und das Endergebnis einer Änderungsanfrage, was für die Durchsatz- und Nacharbeitsanalyse entscheidend ist.

Dies ist das Standardfeld status eines Jira-Issues. Die verfügbaren Status sind in der Workflow-Konfiguration des Projekts definiert.

Der Bearbeiter ist der einzelne Benutzer, der für den aktuellen Schritt oder die Aktivität im Change Management-Workflow verantwortlich ist. Der Bearbeiter kann sich im Laufe des Lebenszyklus eines Änderungsantrags mehrfach ändern, wenn dieser zwischen verschiedenen Personen und Teams wechselt.

Dieses Attribut wird verwendet, um die Arbeitslastverteilung zu analysieren, benutzerspezifische Engpässe zu identifizieren und die Ressourcenzuweisung zu verstehen. Das 'Change Team Activity Workload'-Dashboard stützt sich auf diese Daten, um zu zeigen, welche Einzelpersonen oder Gruppen die meisten Aktivitäten bearbeiten.

Dies hilft bei der Analyse der Ressourcen-Performance und Arbeitslastverteilung, um individuelle oder Team-Engpässe zu identifizieren.

Dies ist das Standardfeld assignee eines Jira-Issues.

Dies ist eine berechnete Metrik, die die verstrichene Zeit zwischen der Aktivität 'Change Submitted For Review' und der Aktivität 'Change Request Approved' misst. Sie isoliert die Genehmigungsphase des Änderungslebenszyklus für eine fokussierte Analyse.

Diese Metrik unterstützt direkt das 'Change Approval Cycle Time' Dashboard und den entsprechenden KPI. Sie wird verwendet, um Engpässe im Genehmigungsprozess zu identifizieren, sei es bei spezifischen Genehmigungsgruppen, Änderungstypen oder Risikostufen. Die Reduzierung dieser Zeit kann den gesamten Änderungsbereitstellungsprozess erheblich beschleunigen.

Misst direkt die Effizienz der Genehmigungsphase und hilft, Verzögerungen bei der Autorisierung von Änderungen genau zu identifizieren und zu beheben.

Berechnet durch Subtraktion des TimeStamps von 'Change Submitted For Review' vom TimeStamp von 'Change Request Approved' für eine gegebene Change Request ID.

Das Prioritätsfeld hilft Teams, die Reihenfolge zu bestimmen, in der Änderungsanträge bearbeitet werden. Es spiegelt eine Kombination aus Auswirkung und Dringlichkeit wider und leitet die Terminplanung sowie die Ressourcenzuweisung.

Die Analyse der Priorität ermöglicht Performance-Vergleiche zwischen Änderungen mit hoher und niedriger Priorität. Man kann beispielsweise prüfen, ob Änderungen mit hoher Priorität tatsächlich kürzere Zykluszeiten haben oder ob sie in denselben Engpässen stecken bleiben wie andere Änderungen. Dies ist wertvoll für die Optimierung der Ressourcenausrichtung und die Erfüllung geschäftlicher Erwartungen.

Ermöglicht die Analyse der Prozessleistung basierend auf der Geschäftspriorität und stellt sicher, dass kritische Änderungen wie erwartet beschleunigt werden.

Dies ist das Standardfeld priority eines Jira-Issues.

Die Risikostufe ist eine obligatorische Bewertung in den meisten Change Management-Prozessen, die die potenziellen negativen Auswirkungen einer Änderung kategorisiert. Die Stufe wird während der Risikobewertungsphase bestimmt und beeinflusst oft den erforderlichen Genehmigungs-Workflow.

Im Process Mining ist dieses Attribut entscheidend für die risikobasierte Analyse. Es unterstützt das Dashboard 'Risikobewertungsgenauigkeit & -ergebnis', indem es das anfängliche Risiko mit dem tatsächlichen Ergebnis korreliert. Es ist auch die primäre Dimension für den KPI 'Änderungsfehlerrate nach Risikostufe' und hilft zu beurteilen, ob risikoreiche Änderungen effektiv gemanagt werden.

Ermöglicht die Analyse, ob Prozesskontrollen und Genehmigungs-Workflows für verschiedene Risikoprofile effektiv sind, und hilft, das Risiko mit Änderungsfehlerraten zu korrelieren.

Dies ist typischerweise ein benutzerdefiniertes Feld in Jira Service Management. Gängige Namen sind 'Risk Level' oder 'Impact'.

Dies ist ein berechnetes Attribut, das das tatsächliche Lösungsdatum eines Änderungsantrags mit dessen 'Target Completion Date' vergleicht. Das Ergebnis ist ein einfacher Status, wie 'Erfüllt' oder 'Verletzt'.

Dies bietet einen klaren, auf einen Blick erkennbaren Performance-Indikator für das 'Change SLA Performance Monitor' Dashboard. Es vereinfacht die Erstellung von KPIs wie 'Change SLA Adherence Rate', indem der Status für jeden Case vorab berechnet wird. Dies ermöglicht ein einfaches Filtern und Aggregieren, um zu sehen, welche Arten von Änderungen, Teams oder Services am häufigsten mit SLA-Verletzungen verbunden sind.

Bietet ein klares, binäres Ergebnis für die SLA-Performance jedes Cases, was die Berichterstellung und Analyse der SLA-Einhaltung vereinfacht.

Berechnet durch den Vergleich des TimeStamps der finalen Aktivität 'Change Closed' mit dem Attribut 'TargetCompletionDate'.

Dieses Attribut speichert das Datum, bis zu dem der Änderungsantrag voraussichtlich abgeschlossen sein muss, um seine SLA zu erfüllen. Es ist der Maßstab, an dem die tatsächliche Abschlusszeit gemessen wird.

Dieses Datum ist fundamental für die Überwachung der Performance im Vergleich zu den Verpflichtungen. Es bildet die Grundlage für das Dashboard 'Change SLA Performance Monitor' und den KPI 'Change SLA Einhaltungsrate'. Durch den Vergleich des tatsächlichen Lösungsdatums mit diesem Ziel können Organisationen die Effektivität ihrer Servicebereitstellung messen.

Dies ist der primäre Datenpunkt zur Berechnung der SLA-Einhaltung und zur Identifizierung, welche Änderungen Gefahr laufen, ihre Fristen zu überschreiten.

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

Dieses Attribut erfasst den zugrunde liegenden Grund für die Änderung, wie z.B. 'Implementierung neuer Funktionen', 'Bugfix' oder 'Infrastruktur-Upgrade'. Es liefert entscheidenden Kontext über die Zusammenfassung oder Beschreibung hinaus.

In der Analyse kann der Grund für eine Änderung mit anderen Metriken wie Zykluszeit, Fehlerrate und Risikostufe korreliert werden. Dies hilft, Fragen zu beantworten wie: 'Werden Änderungen im Zusammenhang mit Bugfixes schneller genehmigt als neue Feature-Implementierungen?' oder 'Haben Infrastruktur-Upgrades eine höhere Fehlerrate?'.

Liefert Geschäftskontext, der eine tiefere Analyse ermöglicht, indem der Zweck einer Änderung mit ihrer Performance und ihrem Ergebnis korreliert wird.

Dies ist typischerweise ein benutzerdefiniertes Feld in Jira Service Management, oft eine Auswahlliste oder ein Textfeld.

Dieses Attribut verknüpft den Änderungsantrag mit einem spezifischen Geschäftsservice, der in der Configuration Management Database (CMDB) definiert ist, z.B. 'E-Mail-Service' oder 'Kunden-CRM'. Dies ist ein Schlüsselkonzept, um die geschäftlichen Auswirkungen einer Änderung zu verstehen.

Die Analyse von Änderungen nach Geschäftsservice hilft bei der Priorisierung von Bemühungen und der Kommunikation von Auswirkungen an Stakeholder. Sie ermöglicht eine Sicht darauf, welche Services die meisten Änderungen erfahren, welche am stärksten gefährdet sind und wo sich änderungsbezogene Vorfälle konzentrieren. Dies ist entscheidend für das Management technischer Änderungen aus einer geschäftsorientierten Perspektive.

Verknüpft technische Änderungen mit geschäftlichen Auswirkungen, was eine Priorisierung und Risikoanalyse basierend auf der Kritikalität des betroffenen Dienstes ermöglicht.

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

Dieses berechnete Attribut identifiziert Änderungsanträge, die zur Modifikation in eine frühere Phase zurückgesendet wurden, zum Beispiel von 'Awaiting Approval' zurück zu 'Planning'. Es signalisiert, dass die ursprüngliche Einreichung unvollständig, falsch war oder die notwendigen Kriterien nicht erfüllte.

Dieses Kennzeichen ist die Grundlage für den KPI 'Change Rework Rate' und das Dashboard 'Change Rework and Rejection Analysis'. Durch das Kennzeichnen von Nacharbeits-Cases können Analysten diese leicht filtern und die Ursachen untersuchen, wie z.B. schlechte anfängliche Planung, unklare Anforderungen oder unzureichende Risikobewertung.

Hebt Prozessineffizienzen hervor, indem Fälle explizit gekennzeichnet werden, die zusätzliche, ungeplante Arbeit erforderten, was eine Analyse der Grundursachen für Nacharbeiten ermöglicht.

Berechnet durch Analyse der Abfolge von Aktivitäten im Event Log. Eine Nacharbeit wird erkannt, wenn eine spätere Aktivität von einer früher stattfindenden Aktivität gefolgt wird.

Wenn ein Änderungsantrag geschlossen wird, liefert das Feld 'Resolution' spezifische Informationen über das Ergebnis. Zum Beispiel deutet 'Done' auf Erfolg hin, während 'Won't Do' oder 'Duplicate' andere Gründe für den Abschluss angeben. Dies bietet mehr Kontext als der Status 'Closed' allein.

Dieses Attribut ist essenziell für die Analyse von Änderungs-Erfolgs- und Fehlerraten. So kann beispielsweise der KPI 'Post-Implementation Issue Rate' besser verstanden werden, indem nach Änderungen mit einer 'Failed' oder 'Rolled Back' Resolution gefiltert wird. Es hilft, erfolgreich implementierte Änderungen von denen zu unterscheiden, die nach der Genehmigung abgebrochen oder abgelehnt wurden.

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

Dies ist das Standardfeld resolution in Jira, das typischerweise gesetzt wird, wenn ein Issue in eine 'Done'-Statuskategorie wechselt.

Der Melder ist die Person, die das Änderungsantrag-Issue in Jira erstellt hat. Dies ist oft der Änderungsverantwortliche oder jemand, der die Änderung im Namen eines Teams initiiert.

Die Analyse des Melders kann dabei helfen, zu identifizieren, welche Abteilungen, Teams oder Einzelpersonen die meisten Änderungen initiieren. Sie kann verwendet werden, um Trends bei den Änderungsquellen zu erkennen und Feedback oder Schulungen für Gruppen bereitzustellen, die häufig unvollständige oder qualitativ minderwertige Änderungsanträge einreichen.

Hilft, die Quellen von Änderungsanfragen zu identifizieren, die analysiert werden können, um die Qualität der ersten Einreichungen zu verbessern.

Dies ist das Standardfeld reporter eines Jira-Issues.

Dieses Attribut gibt an, ob die Änderung zu einem negativen Ergebnis geführt hat, wie z.B. einem Produktionsvorfall. Dies beinhaltet oft die Verknüpfung des Änderungsantrags-Issues mit einem oder mehreren Incident-Issues in Jira.

Diese Daten sind essenziell für die Berechnung der KPIs 'Rate von Problemen nach Implementierung' und 'Änderungsfehlerrate'. Sie liefern ein direktes Maß für die Änderungsqualität und die Effektivität der Planungs-, Test- und Risikobewertungsprozesse. Die Analyse, welche Änderungen zu Problemen führen, hilft bei der Verfeinerung von Kontrollen und der Vermeidung zukünftiger Fehler.

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

Dies wird typischerweise durch die Überprüfung verknüpfter Issues in Jira abgeleitet, insbesondere wenn ein Change Issue 'is caused by'-Links von Incident Issues aufweist.

Dieses Attribut identifiziert das Team, das mit der Änderung arbeiten soll. Während Jira ein 'Assignee'-Feld für Einzelpersonen hat, wird ein 'Team'-Feld oft verwendet, um Arbeit einer funktionalen Gruppe zuzuweisen, wie 'Network Operations' oder 'Database Administrators'.

Dies ist entscheidend für das 'Change Team Activity Workload'-Dashboard. Es ermöglicht die Analyse von Performance und Engpässen auf Teamebene und nicht nur auf individueller Ebene, was oft nützlicher für die Ressourcenplanung und das Management ist.

Erleichtert die Arbeitslast- und Leistungsanalyse auf Team- oder Abteilungsebene und hebt systemische Engpässe hervor.

Dies ist normalerweise ein benutzerdefiniertes Feld in Jira, da es kein Standardfeld 'Team' gibt. Es könnte vom Typ 'Group Picker' oder eine einfache Auswahlliste sein.