Ihr Daten-Template für das Änderungsmanagement

Dieses Attribut erfasst den Namen der Aktivität, die zu einem bestimmten Zeitpunkt im Rahmen eines Änderungsantrags stattgefunden hat. Die Aktivitäten werden aus Statuswechseln, Workflow-Schritten oder bestimmten Protokolleinträgen in Jira abgeleitet, zum Beispiel „Änderung zur Prüfung eingereicht“ oder „Implementierung gestartet“.

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 entdecken, Engpässe zwischen Schritten zu erkennen und Prozessvarianten mit der Standardvorgehensweise zu vergleichen.

Das Attribut legt die Prozessschritte fest. Es ist entscheidend, um Prozessmodelle zu entdecken, Varianten zu analysieren und Engpässe zu erkennen.

Wird in der Regel aus dem Jira-Vorgangsverlauf abgeleitet, insbesondere aus Statuswechseln oder Aktualisierungen benutzerdefinierter Felder, die wichtige Prozessmeilensteine abbilden.

Die ID des Änderungsantrags ist der Primärschlüssel, der jede Änderungsinitiative in Jira Service Management eindeutig kennzeichnet. Als Case-ID für Process Mining verknüpft sie alle Events, Statuswechsel und Aktualisierungen zu einer zusammenhängenden End-to-End-Ansicht des Prozesses.

Bei der Analyse ermöglicht diese ID, den vollständigen Lebenszyklus jeder Änderung zu rekonstruieren. Sie ist entscheidend, um einzelne Änderungen durch verschiedene Phasen wie Risikobewertung, Freigabe, Implementierung und Review zu verfolgen. Alle Kennzahlen, KPIs und Dashboards verwenden dieses Attribut, um Event-Daten für eine bestimmte Änderung korrekt zusammenzufassen und miteinander zu verknüpfen.

Diese grundlegende Case-ID ermöglicht es, den gesamten Ablauf eines Änderungsantrags nachzuverfolgen und seine Leistung zu analysieren.

Dies ist der standardmäßige Jira-Vorgangsschlüssel im Feld key für Vorgänge des Typs „Änderungsantrag“.

Die Startzeit, also der Event-Timestamp, gibt das genaue Datum und die Uhrzeit an, zu denen eine Aktivität für einen Änderungsantrag erfasst 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 dient zur Berechnung von Zykluszeiten, Zeitspannen zwischen Aktivitäten und Wartezeiten sowie zur Bestimmung der Ereignisreihenfolge. Es bildet die Grundlage für die Leistungsüberwachung, die Berechnung der SLA-Einhaltung und das Erkennen von Engpässen.

Dieser Timestamp bildet die Grundlage für alle Leistungs- und Zeitraumanalysen. Er ermöglicht die Berechnung von Zykluszeiten und das Erkennen von Verzögerungen.

Der Timestamp jedes Eintrags im Jira-Vorgangsverlauf. Beim Event zur Erstellung entspricht er dem Feld created.

Dieses Attribut erfasst Datum und Uhrzeit, zu denen die Daten zuletzt aus dem Quellsystem abgerufen wurden. Es gibt an, wie aktuell die Daten im Process-Mining-Tool sind.

Anhand dieses Attributs können Benutzer beurteilen, wie aktuell die Prozessdaten sind. Das ist wichtig für operative Dashboards und die Überwachung in Echtzeit. Die Angabe liefert Kontext für die Analyse und hilft sicherzustellen, dass Entscheidungen nicht auf veralteten Daten beruhen.

Zeigt an, wie aktuell die Daten sind. So können Sie sicherstellen, dass Analysen relevant sind und auf aktuellen Informationen beruhen.

Dieses Metadatenfeld wird vom Datenextraktionstool beim Abruf der Daten ausgefüllt.

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

In einem größeren Unternehmenskontext, in dem Daten aus mehreren Systemen zusammengeführt werden, ist dieses Feld wichtig für die Datenherkunft, die Fehlerbehebung und das Verständnis systemspezifischer Prozessvarianten. Es macht deutlich, woher die analysierten Daten stammen.

Macht die Herkunft der Daten nachvollziehbar. Das ist wichtig, wenn Daten aus mehreren Systemen zusammengeführt oder Prüfungen durchgeführt werden.

Dies ist ein statischer Wert, der bei der Datenextraktion hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Dieses Attribut gibt den Status des Änderungsantrags an, zum Beispiel „Wartet auf Genehmigung“, „In Bearbeitung“ oder „Geschlossen“. Das Statusfeld in Jira ist ein zentraler Bestandteil der Workflow-Engine. Änderungen an diesem Feld bestimmen maßgeblich den Prozessablauf.

Anhand des Status lässt sich der Fortschritt laufender Änderungen verfolgen und das Ergebnis abgeschlossener Änderungen nachvollziehen, etwa „Geschlossen – Erfolgreich“ oder „Geschlossen – Fehlgeschlagen“. Das Attribut ist wichtig, um Durchsatz-Dashboards zu erstellen und Nacharbeitsschleifen zu analysieren, bei denen ein Status auf einen vorherigen Zustand zurückgesetzt wird.

Das Attribut zeigt den Fortschritt und das endgültige Ergebnis eines Änderungsantrags übersichtlich an. Diese Informationen sind für die Durchsatz- und Nacharbeitsanalyse entscheidend.

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

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, die eine vollständige Genehmigung erfordern, und „Notfall“ für dringende Änderungen zur Behebung von Vorfällen.

Dieses Attribut ist für die Prozessanalyse wichtig, da verschiedene Änderungstypen häufig unterschiedlichen Prozesspfaden folgen und unterschiedlichen SLAs unterliegen. Es dient zur Berechnung der Kennzahl „Notfalländerungsrate“ und zum Filtern von Dashboards, um Leistung und Risiko der einzelnen Typen zu vergleichen.

Damit lässt sich der Prozess nach verschiedenen Workflows aufschlüsseln, etwa nach Standard- und Notfalländerungen, für die unterschiedliche Leistungserwartungen und Risiken gelten.

In Jira-Service-Management-Projekten ist dies üblicherweise ein benutzerdefiniertes Feld. Der Feldname kann variieren, lautet aber häufig „Änderungstyp“.

Dieses Attribut enthält das Datum, bis zu dem der Änderungsantrag abgeschlossen sein soll, damit das SLA eingehalten wird. Es dient als Maßstab für den Vergleich mit dem tatsächlichen Abschlusszeitpunkt.

Das Datum ist entscheidend, um die Leistung anhand eingegangener Verpflichtungen zu überwachen. Es bildet die Grundlage für das Dashboard „Überwachung der SLA-Leistung bei Änderungen“ und die Kennzahl „Einhaltungsquote des Änderungs-SLA“. Durch den Vergleich des tatsächlichen Lösungsdatums mit diesem Ziel können Unternehmen die Wirksamkeit ihrer Servicebereitstellung messen.

Dieser Datenpunkt ist die Grundlage für die Berechnung der SLA-Einhaltung und zeigt, bei welchen Änderungen die Gefahr besteht, dass die Frist überschritten wird.

Häufig handelt es sich um das Feld duedate in Jira oder um einen Wert aus einer konfigurierten SLA-Kennzahl in Jira Service Management.

Das Feld „Priorität“ hilft Teams dabei, die Reihenfolge für die Bearbeitung von Änderungsanträgen festzulegen. Es berücksichtigt Auswirkung und Dringlichkeit und unterstützt die Planung sowie die Ressourcenzuweisung.

Anhand der Priorität lässt sich die Leistung bei Änderungen mit hoher und niedriger Priorität vergleichen. So können Sie beispielsweise prüfen, ob Änderungen mit hoher Priorität tatsächlich kürzere Zykluszeiten haben oder an denselben Engpässen wie andere Änderungen hängen bleiben. Diese Erkenntnisse helfen, Ressourcen gezielt einzusetzen und geschäftliche Erwartungen zu erfüllen.

Damit lässt sich die Prozessleistung nach geschäftlicher Priorität analysieren und prüfen, ob kritische Änderungen wie erwartet bevorzugt bearbeitet werden.

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

In den meisten Änderungsmanagementprozessen ist die Risikostufe eine verpflichtende Bewertung. Sie kategorisiert die möglichen negativen Auswirkungen einer Änderung. Die Einstufung erfolgt während der Risikobewertung und beeinflusst häufig den erforderlichen Genehmigungs-Workflow.

Im Process Mining ist dieses Attribut für risikobasierte Analysen entscheidend. Es unterstützt das Dashboard „Genauigkeit und Ergebnis der Risikobewertung“, indem es das anfängliche Risiko mit dem tatsächlichen Ergebnis vergleicht. Außerdem dient es als zentrale Dimension für die Kennzahl „Änderungsfehlerrate nach Risikostufe“. So lässt sich bewerten, ob Änderungen mit hohem Risiko wirksam gesteuert werden.

Damit lässt sich prüfen, ob Prozesskontrollen und Genehmigungs-Workflows für unterschiedliche Risikoprofile wirksam sind. Außerdem können Sie das Risiko mit der Fehlerrate von Änderungen vergleichen.

In Jira Service Management ist dies üblicherweise ein benutzerdefiniertes Feld. Gängige Bezeichnungen sind „Risikostufe“ oder „Auswirkung“.

Dieses berechnete Attribut vergleicht das tatsächliche Lösungsdatum eines Änderungsantrags mit seinem „Geplanten Abschlussdatum“. Das Ergebnis ist ein einfacher Status, zum Beispiel „Eingehalten“ oder „Überschritten“.

Im Dashboard „Überwachung der SLA-Leistung bei Änderungen“ zeigt dieser Status die Leistung auf einen Blick. Er vereinfacht die Erstellung von Kennzahlen wie der „Einhaltungsquote des Änderungs-SLA“, da der Status für jeden Case bereits berechnet wird. So können Sie einfach filtern und aggregieren, um zu sehen, bei welchen Änderungstypen, Teams oder Services SLA-Fristen am häufigsten überschritten werden.

Das Attribut zeigt für jeden Case eindeutig an, ob das SLA eingehalten wurde. Dadurch werden Berichte und Analysen zur SLA-Einhaltung einfacher.

Die Berechnung vergleicht den Timestamp der abschließenden Aktivität „Änderung geschlossen“ mit dem Attribut TargetCompletionDate.

Das Feld „Zugewiesen an“ bezeichnet den Benutzer, der für den aktuellen Schritt oder die aktuelle Aktivität im Änderungsmanagement-Workflow verantwortlich ist. Während des Lebenszyklus eines Änderungsantrags kann die Zuweisung mehrfach wechseln, wenn der Antrag zwischen verschiedenen Personen und Teams weitergegeben wird.

Dieses Attribut dient dazu, die Arbeitslastverteilung zu analysieren, benutzerspezifische Engpässe zu erkennen und die Ressourcenzuweisung nachzuvollziehen. Das Dashboard „Arbeitslast der Aktivitäten des Änderungsteams“ verwendet diese Daten, um zu zeigen, welche Personen oder Gruppen die meisten Aktivitäten bearbeiten.

Damit lassen sich Ressourcenleistung und Arbeitslastverteilung analysieren sowie Engpässe bei einzelnen Personen oder Teams erkennen.

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

Dieses Attribut erfasst den Grund für die Änderung, zum Beispiel „Sicherheitsupdate“, „Softwarefehler beheben“ oder „Infrastruktur aktualisieren“. Es liefert wichtigen Kontext, der über die Zusammenfassung oder Beschreibung hinausgeht.

In der Analyse lässt sich der Änderungsgrund mit anderen Kennzahlen wie Zykluszeit, Fehlerrate und Risikostufe vergleichen. So können Sie Fragen beantworten wie: „Werden Änderungen zur Fehlerbehebung schneller genehmigt als die Einführung neuer Funktionen?“ oder „Treten bei Infrastrukturaktualisierungen häufiger Fehler auf?“

Das Attribut liefert geschäftlichen Kontext und ermöglicht eine vertiefte Analyse, indem der Zweck einer Änderung mit ihrer Leistung und ihrem Ergebnis verglichen wird.

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

Dieses Attribut verknüpft den Änderungsantrag mit einem bestimmten Geschäftsservice aus der Configuration Management Database (CMDB), zum Beispiel dem E-Mail-Service oder dem Kunden-CRM. Das ist wichtig, um die geschäftlichen Auswirkungen einer Änderung zu verstehen.

Die Analyse von Änderungen nach Geschäftsservice hilft dabei, Maßnahmen zu priorisieren und Beteiligte über die Auswirkungen zu informieren. Sie zeigt, bei welchen Services die meisten Änderungen anstehen, welche besonders gefährdet sind und wo sich Vorfälle im Zusammenhang mit Änderungen häufen. Das ist entscheidend, um technische Änderungen aus geschäftlicher Sicht zu steuern.

Das Attribut stellt den Zusammenhang zwischen technischen Änderungen und ihren geschäftlichen Auswirkungen her. So lassen sich Maßnahmen priorisieren und Risiken anhand der Kritikalität des betroffenen Services bewerten.

In JSM handelt es sich häufig um ein benutzerdefiniertes Feld, das oft mit Jira Assets (früher Insight) oder einer anderen CMDB verknüpft ist.

Wird ein Änderungsantrag geschlossen, enthält das Feld „Lösung“ genauere Angaben zum Ergebnis. „Erledigt“ steht beispielsweise für einen erfolgreichen Abschluss. „Wird nicht umgesetzt“ oder „Duplikat“ geben andere Gründe für den Abschluss an. Das liefert mehr Kontext als der Status „Geschlossen“ allein.

Dieses Attribut ist wichtig, um Erfolgs- und Fehlerraten von Änderungen zu analysieren. So lässt sich die Kennzahl „Rate der Probleme nach der Implementierung“ besser einordnen, wenn Sie nach Änderungen mit der Lösung „Fehlgeschlagen“ oder „Zurückgesetzt“ filtern. Das Attribut hilft, erfolgreich umgesetzte Änderungen von solchen zu unterscheiden, die nach der Genehmigung abgebrochen oder abgelehnt wurden.

Das Attribut liefert genaue Informationen zum endgültigen Ergebnis einer Änderung. Das ist entscheidend, um Erfolgs- und Fehlerraten korrekt zu berechnen.

Dies ist das standardmäßige Feld resolution in Jira. Es wird üblicherweise gesetzt, wenn ein Vorgang in die Statuskategorie „Erledigt“ wechselt.

Die meldende Person ist der Benutzer, der den Änderungsantrag in Jira erstellt hat. Häufig handelt es sich dabei um den Änderungsverantwortlichen oder um jemanden, der die Änderung im Auftrag eines Teams anstößt.

Die Analyse der meldenden Personen zeigt, welche Abteilungen, Teams oder Einzelpersonen die meisten Änderungen anstoßen. So lassen sich Trends bei den Quellen von Änderungen erkennen und Gruppen, die häufig unvollständige oder qualitativ mangelhafte Änderungsanträge einreichen, gezielt beraten oder schulen.

Damit lassen sich die Quellen von Änderungsanträgen erkennen und analysieren, um die Qualität der Ersteinreichungen zu verbessern.

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

Dieses berechnete Attribut kennzeichnet Änderungsanträge, die zur Überarbeitung an eine frühere Prozessphase zurückgegeben wurden, zum Beispiel von „Wartet auf Genehmigung“ zu „Planung“. Es weist darauf hin, dass die Ersteinreichung unvollständig oder fehlerhaft war oder die erforderlichen Kriterien nicht erfüllte.

Das Kennzeichen bildet die Grundlage für die Kennzahl „Nacharbeitsquote bei Änderungen“ und das Dashboard „Analyse von Nacharbeit und Ablehnungen bei Änderungen“. Mit der Kennzeichnung von Nacharbeitsfällen können Analysten gezielt danach filtern und Ursachen wie mangelhafte Erstplanung, unklare Anforderungen oder eine unzureichende Risikobewertung untersuchen.

Das Attribut macht Prozessineffizienzen sichtbar, indem es Fälle kennzeichnet, die zusätzliche, ungeplante Arbeit erforderten. So lassen sich die Ursachen der Nacharbeit analysieren.

Die Berechnung basiert auf der Analyse der Aktivitätsreihenfolge im Event Log. Eine Nacharbeit liegt vor, wenn auf eine Aktivität aus einer späteren Prozessphase eine Aktivität aus einer früheren Phase folgt.

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

Diese Daten sind wichtig, um die Kennzahlen „Rate der Probleme nach der Implementierung“ und „Änderungsfehlerrate“ zu berechnen. Sie messen direkt die Qualität einer Änderung und die Wirksamkeit der Planung, Tests und Risikobewertung. Die Analyse von Änderungen, die zu Problemen führen, hilft dabei, Kontrollen zu verbessern und künftige Fehler zu vermeiden.

Das Attribut misst direkt die Qualität und den Erfolg einer Änderung, indem es erfasst, ob sie später zu betrieblichen Problemen geführt hat.

Das Attribut wird üblicherweise ermittelt, indem verknüpfte Vorgänge in Jira geprüft werden. Dabei wird insbesondere geprüft, ob Vorfälle über den Link „wird verursacht durch“ mit einem Änderungsvorgang verknüpft sind.

Dieses Attribut gibt das Team an, dem die Änderung zugewiesen wurde. Jira bietet zwar das Feld „Zugewiesen an“ für einzelne Personen, mit einem Feld „Team“ wird die Arbeit jedoch häufig einer Fachgruppe zugewiesen, etwa dem Netzwerkbetrieb oder der Datenbankadministration.

Das ist für das Dashboard „Arbeitslast der Aktivitäten des Änderungsteams“ entscheidend. Damit lassen sich Leistung und Engpässe auf Teamebene statt nur für einzelne Personen analysieren. Das ist für die Ressourcenplanung und -verwaltung oft aussagekräftiger.

Damit lassen sich Arbeitslast und Leistung auf Team- oder Abteilungsebene analysieren und systembedingte Engpässe erkennen.

Da Jira kein standardmäßiges Feld „Team“ enthält, handelt es sich meist um ein benutzerdefiniertes Feld. Es kann vom Typ „Gruppenauswahl“ oder eine einfache Auswahlliste sein.