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 die Grundlage für 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 Prozessablaufn zu entdecken, Varianten zu analysierenn 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-ID für Process Mining, indem sie alle Ereignisse, 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-ID, der es ermöglicht, den gesamten Verlauf eines Änderungsantrags zu verfolgen und dessen Leistungsfähigkeit zu analysierenn.

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

Die Startzeit, oder Event-Zeitstempel, 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 Zeitstempel.

Dieses Attribut ist maßgeblich für alle zeitbasierten Analysen im Process Mining. Es wird verwendet, um Durchlaufzeiten, Zeitspannen zwischen Aktivitäten, Wartezeiten und die Reihenfolge der Ereignisse zu berechnen. Es bildet die Grundlage für Leistungsfähigkeit-Monitoring, SLA-Einhaltungsberechnungen und Engpass-Identifikation.

Dieser Zeitstempel ist die Grundlage für alle Leistungsfähigkeit- und Dauernanalysen, die die Berechnung von Durchlaufzeiten und die Identifizierung von Verzögerungen ermöglichen.

Der Zeitstempel 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 den Antrag bearbeitet.ie 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 wichtig 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 Typn sind 'Standard' für vorab genehmigte, risikoarme Änderungen, 'Standard' 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 Leistungsfähigkeit und das Risiko jedes Typs zu vergleichen.

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

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

Dieses Attribut gibt den Status des Änderungsantrags an, z.B. 'Genehmigung ausstehende Zahlungen identifizieren.end', 'In Bearbeitung' oder 'Geschlossen'. Das Statusfeld in Jira ist wesentlich 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 Resultate abgeschlossener Änderungen zu verstehen, zum Beispiel 'Geschlossen: Erfolgreich' versus 'Geschlossen: Fehlgeschlagen'. Sie ist wesentlich für den Aufbau von Durchsatz-Dashboards und die Analyse von Nacharbeitsschleifen, 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 wichtig 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 den Antrag bearbeitet.ie 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 analysierenn, 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-Leistungsfähigkeit und Arbeitslastverteilung, um individuelle oder Team-Engpässe zu identifizieren.

Dies ist das Standardfeld assignee eines Jira-Issues.

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 Leistungsfähigkeit-Vergleiche zwischen Änderungen mit hoher und niedriger Priorität. Man kann beispielsweise prüfen, ob Änderungen mit hoher Priorität tatsächlich kürzere Durchlaufzeiten 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 wichtig 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 in der Regel 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 Leistungsfähigkeit-Indikator für das 'Change SLA Leistungsfähigkeit Monitor' Dashboard. Es vereinfacht die Erstellung von KPIs wie 'Change SLA-Einhaltung 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 Dienste am häufigsten mit SLA-Verstöße verbunden sind.

Bietet ein klares, binäres Ergebnis für die SLA-Leistungsfähigkeit jedes Fälle, 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 Referenzwert, an dem die tatsächliche Abschlusszeit gemessen wird.

Dieses Datum ist wesentlich für die Überwachung der Leistungsfähigkeit im Vergleich zu den Verpflichtungen. Es bildet die Grundlage für das Dashboard 'Change SLA Leistungsfähigkeit 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 wichtigen 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 Funktion-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 Leistungsfähigkeit und ihrem Ergebnis korreliert wird.

Dies ist in der Regel 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 Datenbase (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 Dienste die meisten Änderungen erfahren, welche am stärksten gefährdet sind und wo sich änderungsbezogene Vorfälle konzentrieren. Dies ist maßgeblich 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, Nein war oder den Antrag bearbeitet.ie 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-Fälle 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 'Duplizieren' andere Gründe für den Abschluss angeben. Dies bietet mehr Kontext als der Status 'Closed' allein.

Dieses Attribut ist wichtig 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 wichtig ist.

Dies ist das Standardfeld resolution in Jira, das in der Regel 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 den Antrag bearbeitet.ie Ä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 in der Regel 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 'Datenbase Administrators'.

Dies ist maßgeblich für das 'Change Team Activity Workload'-Dashboard. Es ermöglicht die Analyse von Leistungsfähigkeit 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.