> Kontinuierliche Prozessverbesserung > Änderungsmanagement > Freshservice > Daten Template

Ihr Daten-Template für Change Management

Freshservice

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Change Management(21) Aktivitäten im Change Management(15) Anleitungen zur Datenextraktion(2)

Ihr Daten-Template für Change Management

Mit diesem Template erfassen Sie die passenden Daten für die Analyse Ihres Change-Management-Prozesses. Es enthält die wichtigsten Attribute, die Sie sammeln sollten, und Aktivitäten, die Sie verfolgen sollten. Außerdem erfahren Sie, wie Sie diese Informationen aus Ihrem System extrahieren. So stellen Sie sicher, dass Ihre Daten für die Prozesserkennung und -optimierung bereitstehen.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten zum Verfolgen
Anleitung zur Datenextraktion aus Freshservice

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für Change Management

Diese Datenfelder sind erforderlich, um ein vollständiges Event Log zu erstellen und Ihren Change-Management-Prozess detailliert zu analysieren.

5 Erforderlich 8 Empfohlen 8 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name eines bestimmten Ereignisses oder einer Aufgabe im Change-Management-Prozess.
Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt oder Meilenstein im Lebenszyklus einer Änderung, etwa „Change Request erstellt“, „Genehmigung angefordert“ oder „Umsetzung abgeschlossen“. Die Abfolge dieser Aktivitäten für eine bestimmte Change-Request-ID bildet die Grundlage der Prozesslandkarte. Ihre Analyse hilft, den Prozessfluss zu erkennen, Abweichungen aufzudecken und die Dauer der einzelnen Phasen zu messen. Warum das wichtig ist Das Attribut legt die Schritte im Prozessfluss fest. Dadurch lässt sich der Lebenszyklus einer Änderung visualisieren und Prozessvarianten sowie Engpässe können analysiert werden. Woher beziehen Erstellt anhand der Audit-Protokolle, des Aktivitätsverlaufs oder der Statusänderungshistorie eines Change-Datensatzes in Freshservice. Beispiele Änderung genehmigtRisikobewertung abgeschlossenUmsetzung gestartetÄnderung geschlossen
	Change-Request-ID ChangeRequestId	Die eindeutige Kennung jedes Change Requests, der in Freshservice eingereicht wird.
Beschreibung Die Change-Request-ID dient als primäre Kennung für einen einzelnen Change Case, vom Beginn bis zum Abschluss. Sie verknüpft alle zugehörigen Aktivitäten, Genehmigungen und Protokolle zu einer zusammenhängenden Zeitleiste. So lässt sich der Prozess von Anfang bis Ende analysieren. Beim Process Mining ist diese ID entscheidend, um den Lebenszyklus jeder Änderung zu rekonstruieren und ihren Verlauf, ihre Dauer und ihre Ergebnisse zu verstehen. Warum das wichtig ist Dies ist die zentrale Case-ID, über die alle zugehörigen Ereignisse gruppiert werden. So lässt sich der gesamte Verlauf eines einzelnen Change Requests nachvollziehen und analysieren. Woher beziehen Dies ist ein zentrales Feld des Change-Objekts in Freshservice. Beispiele CHG-10234CHG-10235CHG-10236
	Ereigniszeit EventTime	Das genaue Datum und die Uhrzeit, zu denen eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Zu jeder Aktivität im Prozess gehört ein Timestamp, der ihren Zeitpunkt festhält. Diese Zeitangaben sind entscheidend, um die Dauer zwischen Aktivitäten zu berechnen, Wartezeiten zu erkennen und die Gesamtdurchlaufzeit des Prozesses zu analysieren. Sie ermöglichen Leistungsanalysen, die Ermittlung von Engpässen und die Überwachung der SLA-Einhaltung. Warum das wichtig ist Dieser Timestamp ist die Grundlage aller zeitbezogenen Analysen, darunter die Berechnung von Durchlaufzeiten, Dauern und Wartezeiten zwischen Prozessschritten. Woher beziehen Timestamp des jeweiligen Eintrags in den Audit-Protokollen oder im Aktivitätsverlauf eines Change-Datensatzes in Freshservice. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenexports oder der letzten Aktualisierung für jedes Ereignis. Es zeigt, wie aktuell die analysierten Daten sind, und hilft sicherzustellen, dass die Analysen auf aktuellen Informationen beruhen. So bleibt die Datenintegrität gewahrt und die Aktualität der Erkenntnisse lässt sich einordnen. Warum das wichtig ist Zeigt Benutzern, wie aktuell die Daten sind, und hilft, die Aktualität der Process-Mining-Analyse zu überprüfen. Woher beziehen Dieser Timestamp wird in der Regel beim Datenimport oder während des ETL-Prozesses erzeugt und hinzugefügt. Beispiele 2024-05-20T08:00:00Z2024-05-21T08:00:00Z
	Quellsystem SourceSystem	Gibt an, aus welchem System die Daten exportiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Prozessdaten an. In dieser Ansicht lautet der Wert immer „Freshservice“. Das Attribut gehört zu den bewährten Vorgehensweisen, insbesondere wenn Daten aus mehreren Systemen zusammengeführt werden. Es liefert wichtigen Kontext und unterstützt die Daten-Governance sowie die Fehlerbehebung. Warum das wichtig ist Macht die Herkunft der Daten nachvollziehbar. Das ist besonders wichtig, wenn Daten aus mehreren Unternehmenssystemen analysiert werden. Woher beziehen Dies ist ein statischer Wert, der beim Datenexport festgelegt wird, um die Herkunft der Daten zu kennzeichnen. Beispiele Freshservice
	Änderungsstatus ChangeStatus	Der aktuelle oder endgültige Status des Change Requests.
Beschreibung Dieses Attribut gibt den Status eines Change Requests zu einem bestimmten Zeitpunkt oder sein endgültiges Ergebnis an, etwa „Geschlossen“, „Abgebrochen“ oder „Abgelehnt“. Es ist wichtig für die Ergebnisanalyse, denn damit lassen sich erfolgreich abgeschlossene Änderungen von fehlgeschlagenen oder abgebrochenen unterscheiden. Durch eine Filterung nach Status können Sie bestimmte Gruppen von Änderungen gezielt analysieren. Warum das wichtig ist Das Attribut ermöglicht die Analyse der Ergebnisse von Änderungen und hilft, Erfolgs-, Fehler- und Abbruchquoten zu ermitteln. Woher beziehen Dies ist das Feld „Status“ des Change-Objekts in Freshservice. Beispiele GeschlossenAbgebrochenAbgelehntOffen
	Änderungstyp ChangeType	Die Klassifizierung der Änderung, zum Beispiel als Standardänderung, normale Änderung oder Notfalländerung.
Beschreibung Der Änderungstyp kategorisiert Change Requests nach Art, Risiko und Genehmigungsanforderungen. Standardänderungen sind vorab genehmigt, normale Änderungen durchlaufen den Standardprozess und Notfalländerungen müssen beschleunigt bearbeitet werden. Die Analyse nach Änderungstyp ist entscheidend, um festzustellen, ob die verschiedenen Typen unterschiedlichen Prozesspfaden folgen und sich bei Kennzahlen wie Durchlaufzeit oder Erfolgsquote unterscheiden. Warum das wichtig ist Wenn Sie den Prozess nach Änderungstyp aufschlüsseln, werden Unterschiede im Ablauf und in der Leistung von Standardänderungen, normalen Änderungen und Notfalländerungen sichtbar. Woher beziehen Dies ist das Feld „Änderungstyp“ des Change-Objekts in Freshservice. Beispiele StandardNormalNotfallGrößerer Change
	Change-Priorität ChangePriority	Die dem Change Request zugewiesene Prioritätsstufe, die seine geschäftliche Bedeutung angibt.
Beschreibung Die Priorität ergibt sich in der Regel aus der Kombination von Auswirkung und Dringlichkeit. Sie dient als Grundlage für die Ressourcenplanung und Terminierung. Eine Analyse des Zusammenhangs zwischen Priorität und Prozesskennzahlen wie Zykluszeit und SLA-Einhaltung zeigt, ob Changes mit hoher Priorität schneller bearbeitet werden als solche mit niedriger Priorität. So lässt sich beurteilen, wie wirksam die Priorisierungsrichtlinien sind. Warum das wichtig ist Zeigt, ob der Prozess Changes mit hoher geschäftlicher Bedeutung wirksam priorisiert und die Ressourcen entsprechend zuweist. Woher beziehen Dies ist das Feld „Priority“ am Change-Objekt in Freshservice. Beispiele NiedrigMittelHochDringend
	Endzeit EndTime	Der Timestamp des letzten erfassten Ereignisses für den Change-Request-Case.
Beschreibung Die Endzeit markiert den Abschluss des Lebenszyklus eines Change Requests und entspricht in der Regel der Aktivität „Änderung geschlossen“ oder „Änderung abgebrochen“. Zusammen mit der Startzeit dient sie zur Berechnung der gesamten Durchlaufzeit von Anfang bis Ende für jeden Case. Die Analyse dieses Attributs zeigt die Gesamtdauer und den Durchsatz des Change-Management-Prozesses. Warum das wichtig ist Sie ist entscheidend für die Berechnung der Gesamtdurchlaufzeit eines Change Requests, einer wichtigen KPI für die Prozesseffizienz. Woher beziehen Dies ist der Timestamp der letzten Aktivität im Event Log für eine bestimmte Change-Request-ID. Beispiele 2023-11-05T18:00:00Z2023-11-06T09:45:00Z
	Geplantes Abschlussdatum TargetCompletionDate	Das geplante Datum oder SLA-Datum, bis zu dem der Change abgeschlossen sein soll.
Beschreibung Dieses Datum gibt die Frist für den Abschluss eines Change Requests an. Es ist der wichtigste Vergleichswert für die Messung der SLA-Einhaltung. Durch den Vergleich der tatsächlichen Endzeit mit dem geplanten Abschlussdatum lässt sich feststellen, ob ein Change fristgerecht, vorzeitig oder verspätet abgeschlossen wurde. Dieser Wert fließt in die KPI zur SLA-Einhaltungsquote bei Changes ein. Warum das wichtig ist Dient als Vergleichswert für die Messung fristgerechter Abschlüsse und der SLA-Einhaltung, zwei wichtigen Indikatoren für die Prozessleistung. Woher beziehen Dies könnte ein eigenes Datumsfeld „Due by“ oder „SLA Target“ am Change-Objekt in Freshservice sein. Beispiele 2023-11-10T17:00:00Z2023-11-15T17:00:00Z
	Name der anfragenden Person RequesterName	Der Name der Person, die den Change Request eingereicht hat.
Beschreibung Die anfragende Person hat den Change zur Prüfung eingereicht. Eine Auswertung nach anfragender Person kann Muster aufzeigen, etwa welche Personen oder Rollen häufig Changes beantragen oder ob bestimmte Anfragen öfter abgelehnt werden oder Nacharbeit erfordern. In Verbindung mit Abteilungsinformationen lässt sich das Attribut auch zur Analyse der Arbeitslast heranziehen. Warum das wichtig ist Zeigt, woher der Change-Bedarf kommt, und kann auf Schulungsbedarf oder Benutzergruppen mit besonders vielen Changes hinweisen. Woher beziehen Dies ist das Feld „Requested by“ am Change-Objekt in Freshservice, das mit einem Benutzerdatensatz verknüpft ist. Beispiele Alice JohnsonRobert SmithMaria Garcia
	Risikostufe RiskLevel	Die bewertete Risikostufe, die mit der Umsetzung des Changes verbunden ist.
Beschreibung Die Risikostufe beschreibt die möglichen negativen Folgen, falls ein Change scheitert. Übliche Stufen sind niedrig, mittel und hoch. Das Attribut ist wichtig für die Compliance-Analyse und zeigt, ob Changes mit höherem Risiko einen strengeren Prozess durchlaufen, etwa mit zusätzlichen Freigaben oder umfangreicheren Tests. So lässt sich prüfen, ob die Kontrollen des Risikomanagements korrekt angewendet werden. Warum das wichtig ist Dies ist für Compliance und Risikoanalyse entscheidend. So wird sichergestellt, dass Changes mit hohem Risiko angemessen geprüft werden und einen strengeren Prozess durchlaufen. Woher beziehen Dies entspricht dem Feld „Risk“ am Change-Objekt in Freshservice. Beispiele NiedrigMittelHochSehr hoch
	Zugewiesene Gruppe AssignedGroup	Das Team oder die Gruppe, die für die Umsetzung des Changes verantwortlich ist.
Beschreibung Dieses Attribut gibt an, welchem Team die Umsetzung des Changes zugewiesen ist, zum Beispiel dem „Network Team“ oder den „Database Administrators“. Eine Auswertung der Prozessleistung nach zugewiesener Gruppe ist wichtig, um Arbeitslast und Effizienz der Teams zu verstehen und Ressourcenengpässe zu erkennen. Sie zeigt, bei welchen Teams die Umsetzung länger dauert oder nach der Implementierung häufiger Probleme auftreten. Warum das wichtig ist Ermöglicht den Vergleich von Leistung und Arbeitslast verschiedener Umsetzungsteams, um Ressourcenengpässe und bewährte Vorgehensweisen zu erkennen. Woher beziehen Dies ist das Feld „Group“ oder „Assigned Group“ am Change-Objekt in Freshservice. Beispiele InfrastrukturteamAnwendungssupportSicherheitsbetrieb
	Abschlusscode CloseCode	Ein Code oder Grund, der angibt, warum der Change Request geschlossen wurde.
Beschreibung Der Abschlusscode enthält genauere Angaben zum Ergebnis eines abgeschlossenen Changes. Beispiele sind „Erfolgreich umgesetzt“, „Zurückgenommen“ oder „Abgelehnt“. Diese Information ergänzt den endgültigen Status und ermöglicht eine detailliertere Analyse der Erfolgs- und Fehlerursachen im Change-Management-Prozess. Warum das wichtig ist Liefert detaillierte Angaben zu den Ergebnissen von Changes und ermöglicht eine genauere Analyse, warum sie erfolgreich waren, scheiterten oder zurückgenommen wurden. Woher beziehen Prüfen Sie die Freshservice-Dokumentation oder das Change-Formular auf ein Feld wie „Closure Code“. Beispiele ErfolgreichErfolgreich mit ProblemenFehlgeschlagenZurückgenommen
	Abteilungsname DepartmentName	Die Abteilung der Person, die den Change beantragt hat.
Beschreibung Dieses Attribut ordnet den Change organisatorisch ein und gibt an, aus welcher Geschäftseinheit der Antrag stammt. Eine Auswertung nach Abteilung zeigt, welche Organisationseinheiten die meisten Changes anstoßen, die höchsten Ablehnungsquoten haben oder die längsten Zykluszeiten aufweisen. Diese Erkenntnisse helfen bei gezielten Prozessverbesserungen und der Ressourcenplanung. Warum das wichtig ist Ermöglicht die Auswertung von Prozessleistung und Nachfrage nach Geschäftseinheit und unterstützt so gezielte Verbesserungen. Woher beziehen Diese Information stammt in der Regel aus dem Benutzerprofil der anfragenden Person in Freshservice. Beispiele FinanzenPersonalwesenInformationstechnologieMarketing
	Anzahl verknüpfter Incidents AssociatedIncidentsCount	Die Anzahl der Incidents, die nach der Umsetzung mit diesem Change Request verknüpft wurden.
Beschreibung Diese Kennzahl erfasst die nachgelagerten Folgen eines Changes, indem sie die Anzahl der Incidents zählt, die durch dessen Umsetzung entstanden sind. Ein hoher Wert kann auf Schwächen bei Planung, Tests oder Umsetzungsqualität hindeuten. Die Kennzahl fließt direkt in die KPI zur Incident-Quote nach der Implementierung ein und ist entscheidend für die Bewertung von Stabilität und Erfolg der Changes. Warum das wichtig ist Misst direkt die Qualität und Stabilität umgesetzter Changes und hilft dabei, Changes zu erkennen, die Dienstunterbrechungen verursachen. Woher beziehen Ermittelt durch Zählen der Incident-Tickets, die in Freshservice mit einem Change-Ticket verknüpft sind. Beispiele 015
	Auswirkungsstufe ImpactLevel	Die bewerteten geschäftlichen Folgen, falls der Change scheitert oder eine Dienstunterbrechung verursacht.
Beschreibung Die Auswirkungsstufe gibt an, welche Folgen ein Change für den Geschäftsbetrieb haben könnte. Sie reicht von gering (betroffen ist eine einzelne Person) bis hoch (betroffen ist die gesamte Organisation). Zusammen mit der Dringlichkeit bestimmt sie häufig die Gesamtpriorität. Eine Auswertung nach Auswirkung zeigt, ob der Prozess Changes angemessen behandelt, die die Geschäftskontinuität erheblich gefährden. Warum das wichtig ist Unterstützt die Risikoanalyse und zeigt, ob Changes mit potenziell schwerwiegenden geschäftlichen Folgen besonders sorgfältig behandelt werden. Woher beziehen Dies entspricht dem Feld „Impact“ am Change-Objekt in Freshservice. Beispiele NiedrigMittelHoch
	Dringlichkeit Urgency	Gibt an, wie schnell der Change aus geschäftlicher Sicht umgesetzt werden muss.
Beschreibung Die Dringlichkeit beschreibt, wie zeitkritisch ein Change ist. Ein Sicherheitspatch kann beispielsweise eine hohe Dringlichkeit haben. Zusammen mit der Auswirkung bestimmt dieses Attribut häufig die Priorität. Es hilft zu beurteilen, ob der Prozess zeitkritische geschäftliche Anforderungen angemessen berücksichtigt. So wird sichtbar, ob dringende Changes den Prozess tatsächlich schneller durchlaufen. Warum das wichtig ist Ordnet ein, wie zeitkritisch ein Change ist. In Verbindung mit der Zykluszeit lässt sich damit die Reaktionsfähigkeit des Prozesses beurteilen. Woher beziehen Dies ist das Feld „Urgency“ am Change-Objekt in Freshservice. Beispiele NiedrigMittelHoch
	Freigabedauer ApprovalDuration	Die Zeit, die ein Change Request in der Freigabephase verbracht hat.
Beschreibung Diese berechnete Dauer misst die Zeitspanne zwischen der Anfrage einer Freigabe und ihrer Erteilung oder Ablehnung. Sie ist eine wichtige Kennzahl für das Dashboard „Dauer der Change-Freigabephase“ und hilft, Engpässe im Freigabe-Workflow zu erkennen. Die Auswertung kann auf langsame Freigebende, ineffiziente Übergaben zwischen Gruppen oder systembedingte Verzögerungen bei Entscheidungen hinweisen. Warum das wichtig ist Misst direkt die Effizienz der Freigabephase und hilft, Engpässe zu erkennen und zu beseitigen, die Changes verzögern. Woher beziehen Berechnet als Zeitspanne zwischen der Aktivität „Freigabe angefordert“ und der Aktivität „Change freigegeben“ oder „Change abgelehnt“. Beispiele 1 Tag 2 Stunden5 Stunden 30 Minuten3 Tage
	SLA-Verletzung IsSlaBreached	Ein boolesches Kennzeichen dafür, ob der Change Request nach dem geplanten Datum abgeschlossen wurde.
Beschreibung Dieses Attribut zeigt binär an, ob die SLA eingehalten wurde: Es ist „true“, wenn die Endzeit des Changes nach dem geplanten Abschlussdatum liegt, andernfalls „false“. Das vereinfacht die Erstellung von Dashboards und KPIs zur SLA-Einhaltung und ermöglicht eine schnelle Filterung und Aggregation verspäteter Changes. Das Attribut unterstützt direkt die KPI zur SLA-Einhaltungsquote bei Changes. Warum das wichtig ist Liefert ein eindeutiges binäres Ergebnis zur SLA-Leistung und vereinfacht die Filterung und Berichterstellung für fristgerecht und verspätet abgeschlossene Changes. Woher beziehen Wird durch den Vergleich von EndTime und TargetCompletionDate berechnet. Wenn EndTime > TargetCompletionDate, ist der Wert true. Beispiele truefalse
	Umsetzungsdauer ImplementationDuration	Die Dauer der Umsetzungsphase des Changes.
Beschreibung Diese Kennzahl berechnet die Dauer der eigentlichen Umsetzungsarbeiten, üblicherweise vom Zeitpunkt der Aktivität „Umsetzung gestartet“ bis zur Aktivität „Umsetzung abgeschlossen“. Sie dient zur Analyse der Effizienz der technischen Umsetzung und unterstützt das Dashboard „Effizienz der Change-Umsetzungsphase“. Lange Umsetzungszeiten können auf technische Komplexität, fehlende Ressourcen oder unerwartete Herausforderungen hindeuten. Warum das wichtig ist Misst die Effizienz der praktischen technischen Arbeit und grenzt sie von Verzögerungen bei Planung und Freigabe ab. Woher beziehen Berechnet als Zeitspanne zwischen den Aktivitäten „Umsetzung gestartet“ und „Umsetzung abgeschlossen“. Beispiele 4 Stunden1 Stunde 30 Minuten8 Stunden

Erforderlich Empfohlen Optional

Aktivitäten im Change Management

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log genau erfassen, um den Change-Management-Prozess umfassend zu analysieren.

5 Empfohlen 10 Optional

	Aktivität	Beschreibung
	Änderung eingeplant	Bei dieser Aktivität werden eine konkrete Start- und Endzeit für die Umsetzung der genehmigten Änderung festgelegt. Das Ereignis lässt sich in der Regel daran erkennen, dass die Felder „Geplante Startzeit“ und „Geplante Endzeit“ ausgefüllt werden.
Warum das wichtig ist Dieser wichtige Meilenstein löst den Beginn der Umsetzungsphase aus. Er ist entscheidend für die Berechnung der „durchschnittlichen Umsetzungszeit“ und die Analyse der Planungseffizienz. Woher beziehen Abgeleitet aus dem Timestamp, zu dem die terminbezogenen Datumsfelder ausgefüllt werden und der Status zu „Geplant“ oder einem ähnlichen Status wechselt. Erfassung Abgeleitet aus dem Ausfüllen des Felds „Geplantes Startdatum“ und einer entsprechenden Statusänderung. Ereignistyp inferred
	Änderung genehmigt	Ein wichtiger Meilenstein: Eine zuständige Stelle, etwa das Change Advisory Board (CAB), genehmigt den Change Request offiziell zur Umsetzung. Diese Aktion wird in der Regel ausdrücklich im System protokolliert.
Warum das wichtig ist Dieses Ereignis markiert das Ende der Genehmigungsphase und den Beginn der Umsetzungsplanung. Es ist wichtig für die Berechnung der „durchschnittlichen Genehmigungszeit für Änderungen“ und der „Genehmigungsquote beim ersten Durchlauf“. Woher beziehen Freshservice protokolliert dieses Ereignis ausdrücklich, wenn eine genehmigende Person auf die Schaltfläche „Genehmigen“ klickt. Der Vorgang wird mit Timestamp im Aktivitätsprotokoll des Tickets erfasst. Erfassung Der Timestamp der Aktion „Genehmigt“ im Genehmigungs-Tab oder im Aktivitätsprotokoll. Ereignistyp explicit
	Änderung geschlossen	Dieses Ereignis markiert den offiziellen erfolgreichen Abschluss des Change-Management-Prozesses. Es wird erfasst, wenn der Status des Change-Tickets auf den endgültigen Status „Geschlossen“ gesetzt wird.
Warum das wichtig ist Dies ist das primäre End-Event des Prozesses. Es bildet den letzten Datenpunkt für die Berechnung der „durchschnittlichen Durchlaufzeit von Änderungen“ und der „SLA-Einhaltungsquote bei Änderungen“. Woher beziehen Dieses Ereignis wird anhand des Timestamps erfasst, der mit der abschließenden Statusänderung zu „Geschlossen“ im Verlauf des Change-Tickets verknüpft ist. Erfassung Der Timestamp der abschließenden Statusänderung zu „Geschlossen“. Ereignistyp explicit
	Change Request erstellt	Dieses Ereignis kennzeichnet den offiziellen Beginn des Change-Management-Prozesses: Ein neuer Change Request wird in Freshservice erfasst. Das Ereignis wird ausdrücklich protokolliert, wenn ein Benutzer ein neues Change-Ticket speichert. Dabei werden eine eindeutige Change-Request-ID und ein Erstellungs-Timestamp angelegt.
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Die Zeitspanne von dieser Aktivität bis zu „Änderung geschlossen“ ergibt die Durchlaufzeit von Anfang bis Ende und ist eine wichtige KPI für die Prozesseffizienz. Woher beziehen Dieses Ereignis wird ausdrücklich im Audit-Verlauf des Change-Datensatzes erfasst. Es entspricht dem Erstellungs-Timestamp des Change-Tickets. Erfassung Der Erstellungs-Timestamp des Change-Request-Datensatzes. Ereignistyp explicit
	Umsetzung abgeschlossen	Dieses Ereignis zeigt an, dass die technische Umsetzung der Änderung abgeschlossen ist. Es wird in der Regel aus einer Statusänderung zu einem Status nach der Umsetzung abgeleitet, etwa „Prüfung ausstehend“.
Warum das wichtig ist Dieser Meilenstein markiert das Ende der eigentlichen Umsetzungsarbeiten. Er dient als Endpunkt für die Berechnung der „durchschnittlichen Umsetzungszeit“ und kennzeichnet den Beginn von Tests oder Prüfungen. Woher beziehen Abgeleitet aus einer Statusänderung zu einem Status wie „Prüfung ausstehend“, „Test ausstehend“ oder „Abgeschlossen“. Erfassung Abgeleitet aus einer Statusänderung zu „Prüfung ausstehend“ oder einem ähnlichen Status. Ereignistyp inferred
	Änderung abgebrochen	Dieses Ereignis kennzeichnet die Beendigung eines Change Requests vor seinem Abschluss. Es handelt sich um einen alternativen Endstatus, der erfasst wird, wenn der Ticketstatus auf „Abgebrochen“ oder „Zurückgezogen“ gesetzt wird.
Warum das wichtig ist Die Analyse abgebrochener Änderungen kann Probleme in der anfänglichen Planung oder Genehmigungsphase aufdecken. Dazu gehören etwa Requests, die nicht mehr benötigt werden oder keine tragfähige geschäftliche Begründung haben. Woher beziehen Erfasst anhand des Timestamps der Statusänderung zu „Abgebrochen“ oder einem gleichbedeutenden Endstatus, der nicht „Geschlossen“ lautet. Erfassung Der Timestamp der Statusänderung zu „Abgebrochen“. Ereignistyp explicit
	Änderung abgelehnt	Dieses Ereignis zeigt an, dass eine genehmigende Person den Change Request offiziell abgelehnt hat und er nicht weiterbearbeitet wird. Die Aktion wird ausdrücklich protokolliert und führt häufig zu einer Nacharbeitungsschleife.
Warum das wichtig ist Diese Aktivität ist wichtig, um Nacharbeit zu analysieren und Ursachen für das Scheitern des Prozesses zu ermitteln. Häufige Ablehnungen weisen auf Probleme mit der Qualität des Requests oder der Risikobewertung hin. Woher beziehen Freshservice protokolliert dieses Ereignis ausdrücklich, wenn eine genehmigende Person auf die Schaltfläche „Ablehnen“ klickt. Der Vorgang wird im Aktivitätsprotokoll des Tickets erfasst. Erfassung Der Timestamp der Aktion „Abgelehnt“ im Genehmigungs-Tab oder im Aktivitätsprotokoll. Ereignistyp explicit
	Änderung wieder geöffnet	Dieses Ereignis tritt ein, wenn eine zuvor geschlossene oder erledigte Änderung wieder geöffnet wird, in der Regel aufgrund von Problemen, die nach der Umsetzung entdeckt wurden. Es lässt sich an einer Statusänderung von einem geschlossenen zu einem offenen Status erkennen.
Warum das wichtig ist Diese Aktivität ist ein deutlicher Hinweis auf Nacharbeit oder fehlgeschlagene Änderungen. Ihre Häufigkeit zu erfassen, ist entscheidend, um die Qualität von Änderungen und die Wirksamkeit der Tests zu beurteilen. Woher beziehen Abgeleitet aus einem Statuswechsel von „Geschlossen“ oder „Gelöst“ zurück zu „Offen“ oder „In Bearbeitung“ im Aktivitätsprotokoll des Tickets. Erfassung Ermitteln Sie eine Statusänderung von einem Endstatus, zum Beispiel „Geschlossen“, zu einem nicht endgültigen Status, zum Beispiel „Offen“. Ereignistyp inferred
	Genehmigung angefordert	Dieses Ereignis kennzeichnet den Zeitpunkt, an dem der Change Request offiziell zur Prüfung und Freigabe eingereicht wird. Es lässt sich in der Regel daran erkennen, dass der Status des Change Requests zu „Genehmigung ausstehend“ wechselt oder der Request einer genehmigenden Person zugewiesen wird.
Warum das wichtig ist Diese Aktivität markiert den Beginn der Genehmigungsphase. Die Dauer von diesem Zeitpunkt bis zu „Änderung genehmigt“ ist entscheidend, um Engpässe im Genehmigungszyklus zu erkennen. Woher beziehen Das Ereignis wird aus dem Aktivitätsprotokoll abgeleitet oder anhand von Statusänderungen zu „Genehmigung ausstehend“ ermittelt. Als Ereigniszeit gilt der Timestamp dieser Statusänderung. Erfassung Abgeleitet aus einer Statusänderung zu „Genehmigung ausstehend“. Ereignistyp inferred
	Notiz zur Änderung hinzugefügt	Dieses Ereignis erfasst einen Kommentar oder eine Notiz zum Change Request und weist damit auf Kommunikation oder Dokumentation hin. Freshservice protokolliert solche Ereignisse ausdrücklich im Aktivitätsverlauf jedes Tickets.
Warum das wichtig ist Notizen sind zwar kein zentraler Prozessschritt, können aber Verzögerungen erklären, insbesondere während der Genehmigungs- oder Planungsphase. Häufige Notizen können auf unklare Anforderungen oder Kommunikationsprobleme hindeuten. Woher beziehen Das Ereignis wird im Bereich „Aktivität“ oder „Audit“ des Change-Request-Tickets ausdrücklich mit Timestamp und dem Benutzer protokolliert, der die Notiz hinzugefügt hat. Erfassung Als Ereignis „Notiz hinzugefügt“ im Aktivitätsprotokoll des Tickets erfasst. Ereignistyp explicit
	Planung abgeschlossen	Dieses Ereignis zeigt an, dass die erforderliche Planung der Änderung abgeschlossen ist. Dazu gehören die Ausarbeitung der Umsetzungs- und Rückfallpläne. In der Regel wird es aus einer Statusänderung nach der Genehmigung abgeleitet.
Warum das wichtig ist Dieses Ereignis markiert den Übergang von der Planung zur Umsetzung. Die Analyse der Dauer der Planungsphase hilft, Möglichkeiten zur Optimierung der Vorbereitungen zu erkennen. Woher beziehen Abgeleitet aus einer Statusänderung von einem planungsbezogenen Status wie „Freigabe ausstehend“ zu einem Umsetzungsstatus wie „Geplant“. Erfassung Abgeleitet aus einer Statusänderung weg von „Planung läuft“ oder einem ähnlichen Status. Ereignistyp inferred
	Prüfung nach der Umsetzung abgeschlossen	Dieses Ereignis zeigt an, dass die Prüfung nach der Umsetzung (Post-Implementation Review, PIR) abgeschlossen ist. Dabei werden der Erfolg der Änderung bewertet und Erkenntnisse dokumentiert. Es lässt sich häufig daran erkennen, dass nach der Umsetzung Prüfnotizen hinzugefügt oder ein Status aktualisiert wird.
Warum das wichtig ist Dieses Ereignis stellt sicher, dass eine formale Prüfung stattfindet. Die Analyse dieser Aktivität hilft, die Wirksamkeit von Änderungen zu beurteilen und die kontinuierliche Prozessverbesserung zu unterstützen. Woher beziehen Abgeleitet aus dem Ausfüllen von PIR-bezogenen Feldern im Change-Formular nach dem Umsetzungsdatum oder aus einer Statusänderung zu einem Status wie „Prüfung abgeschlossen“. Erfassung Abgeleitet aus dem Ausfüllen der Felder für PIR-Notizen oder einer bestimmten Statusänderung. Ereignistyp inferred
	Risikobewertung abgeschlossen	Dieses Ereignis zeigt an, dass die formale Bewertung der mit der Änderung verbundenen Risiken abgeschlossen ist. Es lässt sich häufig daran erkennen, dass das Feld für die Risikostufe ausgefüllt oder aktualisiert wurde oder eine zugehörige Aufgabe abgeschlossen ist.
Warum das wichtig ist Die Erfassung dieser Aktivität hilft sicherzustellen, dass die Vorgaben für Änderungen eine Risikobewertung vorsehen. Sie ermöglicht die Analyse der „Abdeckung durch Risikobewertungen“ und der für diesen wichtigen Schritt benötigten Zeit. Woher beziehen Das Ereignis wird wahrscheinlich aus einer mit Timestamp versehenen Aktualisierung des Felds „Risiko“ im Change-Formular oder aus dem Abschluss einer bestimmten Aufgabe zur Risikoanalyse abgeleitet. Erfassung Abgeleitet aus dem Timestamp, zu dem das Feld „Risiko“ ausgefüllt oder ein zugehöriger Punkt auf der Checkliste als abgeschlossen markiert wird. Ereignistyp inferred
	Tests abgeschlossen	Dieses Ereignis erfasst den Abschluss aller erforderlichen Tests und Validierungen. Damit wird geprüft, ob die Änderung erfolgreich war und keine negativen Auswirkungen verursacht hat. Es lässt sich aus dem Abschluss einer Aufgabe oder einer Statusänderung ableiten.
Warum das wichtig ist Die Erfassung dieser Aktivität hilft bei der Messung der KPI „Abschlussquote der Tests“ und stellt sicher, dass Änderungen vor dem endgültigen Abschluss ordnungsgemäß geprüft werden. So lassen sich Probleme nach der Umsetzung verringern. Woher beziehen Dieses Ereignis lässt sich möglicherweise nur schwer erfassen. Es muss gegebenenfalls aus dem Abschluss einer verknüpften Aufgabe „Test“ oder einer Statusänderung zu „Test abgeschlossen“ abgeleitet werden. Erfassung Abgeleitet aus dem Abschluss einer mit der Änderung verknüpften Testaufgabe. Ereignistyp inferred
	Umsetzung gestartet	Dieses Ereignis markiert den Beginn der tatsächlichen Bereitstellung oder Umsetzung der Änderung. Es wird abgeleitet, wenn der Status des Change Requests zu „In Bearbeitung“ oder einem ähnlichen aktiven Status wechselt.
Warum das wichtig ist Dieses Ereignis liefert einen klaren Ausgangspunkt, um die Dauer der aktiven Umsetzung zu erfassen. So lässt sich die Wartezeit von der tatsächlich geleisteten Arbeit unterscheiden. Woher beziehen Abgeleitet aus einer Statusänderung zu „In Bearbeitung“ oder „Umsetzung läuft“ zum geplanten Startzeitpunkt. Erfassung Abgeleitet aus einer Statusänderung zu „In Bearbeitung“. Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Freshservice

Schritte

Freshservice Analytics öffnen: Melden Sie sich bei Ihrer Freshservice-Instanz mit einem Konto an, das im Analytics-Modul Berichte erstellen und anzeigen darf.
Neuen Bericht erstellen: Öffnen Sie den Bereich Analytics. Erstellen Sie einen Bericht und geben Sie ihm einen aussagekräftigen Namen, zum Beispiel "Process Mining - Change Management Event Log".
Erstes Widget hinzufügen (Change Request Created): Fügen Sie dem Bericht ein Widget hinzu. Wählen Sie als Modul „Changes“ aus. Verwenden Sie als Kennzahl „Count of Changes“. Fügen Sie im Bereich „Group by“ die Felder „Change ID“ und „Created at“ hinzu. Dieses Widget dient als Quelle für die Aktivität „Change Request Created“.
Berichtsfilter konfigurieren: Wenden Sie auf den gesamten Bericht einen Filter für das Datum „Created at“ an, um den Analysezeitraum festzulegen, zum Beispiel die letzten 6 Monate. Stellen Sie sicher, dass dieser Filter auch für alle folgenden Widgets gilt, damit die Daten konsistent sind.
Widgets für alle Aktivitäten erstellen: Wiederholen Sie den Vorgang für jede der 15 erforderlichen Aktivitäten. Verwenden Sie unterschiedliche Felder, Statuswerte und Module, um die einzelnen Ereignisse herauszufiltern. Für „Change Approved“ können Sie beispielsweise nach dem Datum „Approved on“ gruppieren. Bei statusbasierten Ereignissen wie „Implementation Started“ benötigen Sie eine Kennzahl mit dem Filter Status is In Progress und müssen für die betreffenden Changes nach dem Timestamp Last Updated at gruppieren. Einzelheiten zu den einzelnen Widgets finden Sie in der Konfiguration im Abschnitt „query“.
Zugrunde liegende Daten exportieren: Sobald alle 15 Widgets konfiguriert sind und der Bericht geladen wurde, öffnen Sie jedes Widget einzeln. Klicken Sie auf das Optionssymbol mit den drei Punkten und wählen Sie „Export“ und anschließend „Export underlying data“. Wählen Sie das CSV-Format.
Exportierte Dateien zusammenführen: Sie erhalten 15 separate CSV-Dateien. Öffnen Sie jede Datei und fügen Sie eine neue Spalte mit dem Namen ActivityName hinzu. Tragen Sie in dieser Spalte den Namen der jeweiligen Aktivität ein, zum Beispiel „Change Request Created“ für die erste Datei und „Change Approved“ für die zweite.
Ein einzelnes Event Log erstellen: Führen Sie die Daten aus allen 15 bearbeiteten CSV-Dateien in einer gemeinsamen CSV-Datei zusammen. Achten Sie darauf, dass die Spaltenüberschriften in allen Dateien übereinstimmen.
Spaltennamen vereinheitlichen: Benennen Sie die Spalten in der zusammengeführten Datei so um, dass sie dem erforderlichen Schema entsprechen. Benennen Sie zum Beispiel „Change ID“ in ChangeRequestId und die jeweiligen Datumsspalten der einzelnen Dateien, etwa „Created at“ und „Approved on“, in EventTime um.
Statische und empfohlene Attribute ergänzen: Fügen Sie Ihrer abschließenden Tabelle die Spalten SourceSystem (für alle Zeilen mit „Freshservice“ befüllen) und LastDataUpdate (mit Datum und Uhrzeit des aktuellen Exports befüllen) hinzu. Ergänzen Sie außerdem Spalten für empfohlene Attribute wie ChangeStatus und ChangeType. Diese Werte können Sie aus einem separaten „enrichment“-Bericht in Freshservice abrufen, der die Details zu jeder Change ID enthält. Verknüpfen Sie die Daten anschließend mit einer Tabellenfunktion wie SVERWEIS.
Abschließende Formatierung: Prüfen Sie die fertige CSV-Datei auf einheitliche Timestamp-Formate, leere Zeilen und Spaltenüberschriften, die exakt dem für den Upload in ProcessMind erforderlichen Schema entsprechen.

Konfiguration

Voraussetzungen: Sie benötigen Zugriff auf das Freshservice-Analytics-Modul. Dieses ist üblicherweise in den Tarifen Pro und Enterprise verfügbar. Benutzer benötigen eine Rolle, die das Erstellen von Berichten und das Anzeigen von Change-Management-Daten erlaubt.
Datumsbereichsfilter: Wenden Sie auf den gesamten Bericht einen einheitlichen Datumsbereichsfilter an, zum Beispiel „Created at is in the last 180 days“. So greifen alle Widgets auf denselben Satz von Change Requests zu.
Widget-Konfiguration: Konfigurieren Sie jedes Widget so, dass es eine einzelne Geschäftsaktivität abbildet. Dazu filtern Sie beispielsweise nach einem bestimmten Status, verwenden ein eigenes Datumsfeld wie „Approved on“ oder kombinieren das Feld „Last Updated at“ mit einem Statusfilter.
Export der zugrunde liegenden Daten: Verwenden Sie immer die Option „Export underlying data“ und nicht „Export“, womit das Widget-Bild oder zusammengefasste Daten exportiert werden. Nur der Export der zugrunde liegenden Daten liefert die Rohdaten auf Zeilenebene, die für ein Event Log erforderlich sind.
Leistungshinweise: Berichte mit mehr als einem Dutzend Widgets und einem großen Datumsbereich von über einem Jahr können langsam laden. Führen Sie den Bericht aus und exportieren Sie die Daten möglichst außerhalb der Hauptgeschäftszeiten, um die Leistung möglichst wenig zu beeinträchtigen.

Beispielabfrage sql

/* This is a configuration guide for creating widgets in Freshservice Analytics. 
Create one widget for each of the following 15 configurations. */

// Widget 1: Change Request Created
Widget.Module = "Changes"
Widget.Metric = "Count of Changes"
Widget.GroupBy = ["Change ID", "Created at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Created at": "EventTime"}

// Widget 2: Approval Requested
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status history contains 'Awaiting Approval')"
Widget.GroupBy = ["Change ID", "First moved to awaiting approval at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "First moved to awaiting approval at": "EventTime"}

// Widget 3: Risk Assessment Completed
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Risk is not empty)"
Widget.GroupBy = ["Change ID", "[Timestamp of first Risk update]"] // Note: This may require using 'Last Updated at' with a specific condition or a custom field.
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "[Timestamp of first Risk update]": "EventTime"}

// Widget 4: Note Added to Change
Widget.Module = "Ticket Activities"
Widget.Metric = "Count of Activities (Filtered: Activity Type is 'Note added' AND Parent Type is 'Change')"
Widget.GroupBy = ["Parent ID", "Performed at"]
Widget.ColumnsToExport = {"Parent ID": "ChangeRequestId", "Performed at": "EventTime"}

// Widget 5: Change Approved
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status is 'Approved')"
Widget.GroupBy = ["Change ID", "Approved on"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Approved on": "EventTime"}

// Widget 6: Change Rejected
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status is 'Rejected')"
Widget.GroupBy = ["Change ID", "Last Updated at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Last Updated at": "EventTime"}

// Widget 7: Planning Completed
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status history contains 'Pending Release')"
Widget.GroupBy = ["Change ID", "Last Updated at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Last Updated at": "EventTime"}

// Widget 8: Change Scheduled
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Scheduled Start Time is not empty)"
Widget.GroupBy = ["Change ID", "[Timestamp of first Schedule update]"] // Note: This often corresponds to the 'Last Updated at' when the schedule fields were populated.
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "[Timestamp of first Schedule update]": "EventTime"}

// Widget 9: Implementation Started
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status is 'In Progress')"
Widget.GroupBy = ["Change ID", "Last Updated at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Last Updated at": "EventTime"}

// Widget 10: Implementation Completed
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status history contains 'Pending Review')"
Widget.GroupBy = ["Change ID", "Last Updated at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Last Updated at": "EventTime"}

// Widget 11: Testing Completed
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status history contains 'Pending Review' OR custom testing status)"
Widget.GroupBy = ["Change ID", "[Timestamp for status change to review]"] // Use 'Last Updated at' corresponding to the status change.
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "[Timestamp for status change to review]": "EventTime"}

// Widget 12: Post-Implementation Review Done
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status is 'Closed' AND [PIR field is populated])"
Widget.GroupBy = ["Change ID", "Last Updated at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Last Updated at": "EventTime"}

// Widget 13: Change Re-Opened
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status history contains 'Re-opened')"
Widget.GroupBy = ["Change ID", "Last Updated at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Last Updated at": "EventTime"}

// Widget 14: Change Closed
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status is 'Closed')"
Widget.GroupBy = ["Change ID", "Closed at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Closed at": "EventTime"}

// Widget 15: Change Cancelled
Widget.Module = "Changes"
Widget.Metric = "Count of Changes (Filtered: Status is 'Cancelled' OR Status is 'Withdrawn')"
Widget.GroupBy = ["Change ID", "Last Updated at"]
Widget.ColumnsToExport = {"Change ID": "ChangeRequestId", "Last Updated at": "EventTime"}

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3 auf Ihrem System installiert ist. Installieren Sie die erforderlichen Bibliotheken requests für API-Aufrufe und pandas für die Datenverarbeitung mit folgendem Befehl im Terminal: pip install requests pandas.
API-Schlüssel abrufen: Melden Sie sich als Administrator bei Ihrer Freshservice-Instanz an. Öffnen Sie Ihre Profileinstellungen, suchen Sie den API-Bereich und erstellen Sie einen neuen API-Schlüssel. Kopieren Sie den Schlüssel sicher, da Sie ihn für das Skript benötigen.
Skript konfigurieren: Erstellen Sie eine Python-Datei, zum Beispiel extract_freshservice_changes.py. Kopieren Sie das vollständige Python-Skript aus dem Abschnitt query in diese Datei. Aktualisieren Sie die Platzhaltervariablen am Anfang des Skripts: FRESHSERVICE_DOMAIN (zum Beispiel your-company.freshservice.com) und API_KEY mit Ihren Zugangsdaten.
Extraktionszeitraum festlegen: Ändern Sie die Variable UPDATED_SINCE_FILTER im Skript, um das Startdatum für die Datenextraktion festzulegen. Verwenden Sie das ISO-8601-Format, zum Beispiel YYYY-MM-DDTHH:MM:SSZ. Für den Anfang empfiehlt sich ein aktueller Zeitraum von 3 bis 6 Monaten.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python extract_freshservice_changes.py. Das Skript ruft Change- und Aktivitätsdaten über die Freshservice-API ab und zeigt den Fortschritt für jede verarbeitete Ergebnisseite an.
API-Daten abrufen: Das Skript durchläuft alle Change Requests, die innerhalb des festgelegten Zeitraums aktualisiert wurden. Für jeden Change ruft es den vollständigen Aktivitätsverlauf ab. Bei großen Datenmengen kann dies aufgrund von API-Ratenbegrenzungen längere Zeit dauern.
Daten in ein Event Log umwandeln: Das Skript verarbeitet die JSON-Rohdaten. Anhand von Aktivitätstypen und Statusänderungen erkennt es bestimmte Ereignisse, etwa „Change Request Created“, „Status changed to Closed“ oder „Note added“. Anschließend überträgt es diese Informationen in die erforderliche Event-Log-Struktur und erstellt für jede erkannte Aktivität eine Zeile.
Zusätzliche Attribute berechnen: Nach der Erstellung des ersten Event Logs führt das Skript eine Nachbearbeitung durch. Es ergänzt statische Spalten wie SourceSystem und LastDataUpdate. Außerdem berechnet es für jeden Case den EndTime, indem es den neuesten EventTime für jede eindeutige ChangeRequestId ermittelt.
Als CSV exportieren: Nach Abschluss speichert das Skript das fertige Event Log als freshservice_change_management_event_log.csv im selben Verzeichnis, aus dem das Skript ausgeführt wurde. Die Datei ist für den direkten Upload in ein Process-Mining-Tool formatiert.

Konfiguration

API-Schlüssel: Sie benötigen einen Freshservice-API-Schlüssel. Er muss zu einem Administrator oder einem Benutzerprofil mit umfassendem Lesezugriff auf das Change-Management-Modul gehören.
Freshservice-Domain: Geben Sie die spezifische Freshservice-Domain Ihrer Organisation an, zum Beispiel your-company.freshservice.com.
Datumsbereich (UPDATED_SINCE_FILTER): Diese Einstellung filtert Changes nach ihrem letzten Aktualisierungszeitpunkt. Um den vollständigen Verlauf zu extrahieren, müssen Sie das Skript möglicherweise mit einem sehr frühen Datum ausführen. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um die Leistung zu berücksichtigen. Ein vollständiger historischer Datenabruf kann viel Zeit in Anspruch nehmen und an API-Ratenbegrenzungen stoßen.
Statuszuordnungen: Das Skript leitet viele Aktivitäten aus Statusänderungen ab, zum Beispiel „Implementation Started“ aus dem Status „In Progress“. Diese Statusnamen sind im Skript fest hinterlegt. Möglicherweise müssen Sie die Zeichenfolgen an die benutzerdefinierten Statuswerte Ihrer Freshservice-Instanz anpassen.
Leistung: Das Skript ruft die Aktivitäten für jeden Change Request einzeln ab. Bei einer Instanz mit Zehntausenden Changes kann die Extraktion aufgrund der Anzahl der API-Aufrufe und möglicher Ratenbegrenzungen mehrere Stunden dauern.

Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime, timezone
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain (e.g., class="hl-string">'your-company.freshservice.com')
FRESHSERVICE_DOMAIN = class="hl-string">"[YOUR_DOMAIN]"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[YOUR_API_KEY]"

class=class="hl-string">"hl-comment"># Filter for changes updated since a specific date (ISO 8601 format)
class=class="hl-string">"hl-comment"># Example: class="hl-string">'2023-01-01T00:00:00Z'
UPDATED_SINCE_FILTER = class="hl-string">"2023-01-01T00:00:00Z"

class=class="hl-string">"hl-comment"># --- Script --- 
BASE_URL = fclass="hl-string">"https://{FRESHSERVICE_DOMAIN}/api/v2"

def get_all_changes(updated_since):
    changes = []
    url = fclass="hl-string">"{BASE_URL}/changes?updated_since={updated_since}"
    page = 1
    while url:
        print(fclass="hl-string">"Fetching changes page {page}...")
        try:
            response = requests.get(url, auth=(API_KEY, class="hl-string">'X'))
            response.raise_for_status()  class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            changes.extend(data[class="hl-string">'changes'])
            class=class="hl-string">"hl-comment"># Freshservice uses the class="hl-string">'Link' header for pagination
            if class="hl-string">'Link' in response.headers:
                url = response.headers[class="hl-string">'Link'].split(class="hl-string">';')[0].strip(class="hl-string">'<>')
            else:
                url = None
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching changes: {e}")
            if response.status_code == 429: class=class="hl-string">"hl-comment"># Rate limit exceeded
                print(class="hl-string">"Rate limit exceeded. Waiting for 60 seconds...")
                time.sleep(60)
                continue class=class="hl-string">"hl-comment"># Retry the same URL
            else:
                url = None class=class="hl-string">"hl-comment"># Stop on other errors
    return changes

def get_change_activities(change_id):
    activities = []
    url = fclass="hl-string">"{BASE_URL}/changes/{change_id}/activities"
    while url:
        try:
            response = requests.get(url, auth=(API_KEY, class="hl-string">'X'))
            response.raise_for_status()
            data = response.json()
            activities.extend(data[class="hl-string">'activities'])
            if class="hl-string">'Link' in response.headers:
                url = response.headers[class="hl-string">'Link'].split(class="hl-string">';')[0].strip(class="hl-string">'<>')
            else:
                url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching activities for change {change_id}: {e}")
            if response.status_code == 429: class=class="hl-string">"hl-comment"># Rate limit exceeded
                print(class="hl-string">"Rate limit exceeded. Waiting for 60 seconds...")
                time.sleep(60)
                continue class=class="hl-string">"hl-comment"># Retry the same URL
            else:
                url = None class=class="hl-string">"hl-comment"># Stop on other errors
    return activities

def main():
    print(class="hl-string">"Starting Freshservice data extraction...")
    all_changes = get_all_changes(UPDATED_SINCE_FILTER)
    event_log = []
    total_changes = len(all_changes)
    
    print(fclass="hl-string">"Found {total_changes} changes to process.")

    for index, change in enumerate(all_changes):
        print(fclass="hl-string">"Processing change {index + 1}/{total_changes}: ID {change['id']}")
        change_id = change[class="hl-string">'id']
        requester_name = change[class="hl-string">'requester'][class="hl-string">'first_name'] + class="hl-string">' ' + change[class="hl-string">'requester'][class="hl-string">'last_name'] if change.get(class="hl-string">'requester') else None
        assigned_group = change[class="hl-string">'group'][class="hl-string">'name'] if change.get(class="hl-string">'group') else None

        class=class="hl-string">"hl-comment"># Base attributes for all events of this case
        base_event = {
            class="hl-string">'ChangeRequestId': change_id,
            class="hl-string">'ChangeStatus': change.get(class="hl-string">'status_name'),
            class="hl-string">'ChangeType': change.get(class="hl-string">'change_type_name'),
            class="hl-string">'ChangePriority': change.get(class="hl-string">'priority_name'),
            class="hl-string">'RequesterName': requester_name,
            class="hl-string">'AssignedGroup': assigned_group,
            class="hl-string">'RiskLevel': change.get(class="hl-string">'risk_name'),
            class="hl-string">'TargetCompletionDate': change.get(class="hl-string">'planned_end_date'),
            class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
            class="hl-string">'LastDataUpdate': datetime.now(timezone.utc).isoformat()
        }

        class=class="hl-string">"hl-comment"># 1. Change Request Created
        event_log.append({
            **base_event,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': change[class="hl-string">'created_at']
        })

        class=class="hl-string">"hl-comment"># Fetch and process activities
        activities = get_change_activities(change_id)
        for activity in activities:
            activity_event_time = activity[class="hl-string">'performed_at']

            class=class="hl-string">"hl-comment"># 4. Note Added to Change
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note Added':
                event_log.append({
                    **base_event,
                    class="hl-string">'ActivityName': class="hl-string">'Note Added to Change',
                    class="hl-string">'EventTime': activity_event_time
                })
            
            class=class="hl-string">"hl-comment"># 5. Change Approved & 6. Change Rejected
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Approval' and class="hl-string">'status_name' in activity[class="hl-string">'activity_data']:
                if activity[class="hl-string">'activity_data'][class="hl-string">'status_name'] == class="hl-string">'Approved':
                    event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': class="hl-string">'Change Approved',
                        class="hl-string">'EventTime': activity_event_time
                    })
                elif activity[class="hl-string">'activity_data'][class="hl-string">'status_name'] == class="hl-string">'Rejected':
                    event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': class="hl-string">'Change Rejected',
                        class="hl-string">'EventTime': activity_event_time
                    })
            
            class=class="hl-string">"hl-comment"># Process status changes and field updates
            if class="hl-string">'changes' in activity[class="hl-string">'activity_data']:
                previous_status_id = activity[class="hl-string">'activity_data'][class="hl-string">'changes'].get(class="hl-string">'status', [None, None])[0]
                new_status_name = activity[class="hl-string">'activity_data'][class="hl-string">'changes'].get(class="hl-string">'status', [None, class="hl-string">''])[1]
                previous_status_name = change[class="hl-string">'status_name_label_mapping'].get(str(previous_status_id))

                class=class="hl-string">"hl-comment"># 2. Approval Requested
                if new_status_name == class="hl-string">'Awaiting Approval':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Approval Requested', class="hl-string">'EventTime': activity_event_time})
                
                class=class="hl-string">"hl-comment"># 3. Risk Assessment Completed
                if class="hl-string">'risk' in activity[class="hl-string">'activity_data'][class="hl-string">'changes']:
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Risk Assessment Completed', class="hl-string">'EventTime': activity_event_time})

                class=class="hl-string">"hl-comment"># 7. Planning Completed (Inferred)
                if new_status_name == class="hl-string">'Open' and previous_status_name == class="hl-string">'Awaiting Approval':
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Planning Completed', class="hl-string">'EventTime': activity_event_time})

                class=class="hl-string">"hl-comment"># 8. Change Scheduled (Inferred)
                if class="hl-string">'planned_start_date' in activity[class="hl-string">'activity_data'][class="hl-string">'changes'] or class="hl-string">'planned_end_date' in activity[class="hl-string">'activity_data'][class="hl-string">'changes']:
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Change Scheduled', class="hl-string">'EventTime': activity_event_time})

                class=class="hl-string">"hl-comment"># 9. Implementation Started (Inferred)
                if new_status_name == class="hl-string">'In Progress':
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Implementation Started', class="hl-string">'EventTime': activity_event_time})

                class=class="hl-string">"hl-comment"># 10. Implementation Completed (Inferred)
                if new_status_name == class="hl-string">'Pending Review':
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Implementation Completed', class="hl-string">'EventTime': activity_event_time})

                class=class="hl-string">"hl-comment"># 11. Testing Completed (Inferred)
                if new_status_name == class="hl-string">'Testing Complete': class=class="hl-string">"hl-comment"># This status name may need customization
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Testing Completed', class="hl-string">'EventTime': activity_event_time})
                
                class=class="hl-string">"hl-comment"># 12. Post-Implementation Review Done (Inferred)
                if new_status_name == class="hl-string">'Pending PIR' and previous_status_name != class="hl-string">'Closed': class=class="hl-string">"hl-comment"># Example status, might need adjustment
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Post-Implementation Review Done', class="hl-string">'EventTime': activity_event_time})
                
                class=class="hl-string">"hl-comment"># 13. Change Re-Opened
                is_reopened = (previous_status_name in [class="hl-string">'Closed', class="hl-string">'Cancelled']) and (new_status_name not in [class="hl-string">'Closed', class="hl-string">'Cancelled'])
                if is_reopened:
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Change Re-Opened', class="hl-string">'EventTime': activity_event_time})

                class=class="hl-string">"hl-comment"># 14. Change Closed
                if new_status_name == class="hl-string">'Closed':
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Change Closed', class="hl-string">'EventTime': activity_event_time})

                class=class="hl-string">"hl-comment"># 15. Change Cancelled
                if new_status_name == class="hl-string">'Cancelled':
                     event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Change Cancelled', class="hl-string">'EventTime': activity_event_time})

    if not event_log:
        print(class="hl-string">"No events were generated. Check your filters and API permissions.")
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Post-processing
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ChangeRequestId', class="hl-string">'EventTime']).drop_duplicates()

    class=class="hl-string">"hl-comment"># Calculate EndTime
    end_times = df.groupby(class="hl-string">'ChangeRequestId')[class="hl-string">'EventTime'].max().to_dict()
    df[class="hl-string">'EndTime'] = df[class="hl-string">'ChangeRequestId'].map(end_times)

    class=class="hl-string">"hl-comment"># Reorder columns
    column_order = [
        class="hl-string">'ChangeRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', class="hl-string">'EndTime',
        class="hl-string">'ChangeStatus', class="hl-string">'ChangeType', class="hl-string">'ChangePriority', class="hl-string">'RequesterName', class="hl-string">'AssignedGroup', class="hl-string">'RiskLevel',
        class="hl-string">'TargetCompletionDate'
    ]
    df = df[column_order]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'freshservice_change_management_event_log.csv'
    df.to_csv(output_file, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_file}")

if __name__ == class="hl-string">'__main__':
    main()

Möchten Sie loslegen?

Bereiten Sie Ihre Daten mit diesem umfassenden Template vor und starten Sie noch heute mit der Optimierung Ihres Change Managements. Entdecken Sie bisher verborgene Erkenntnisse und sorgen Sie für effizientere Bereitstellungen.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Fehlgeschlagene Changes vermeiden: Verbessern Sie jetzt Ihr Freshservice-Management

Erreichen Sie eine Erfolgsquote von 95 % bei Changes und vermeiden Sie Ausfälle und Verzögerungen in Freshservice.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten startklar.

Ihr Daten-Template für Change Management

Ihr Daten-Template für Change Management

Attribute für Change Management

Aktivitäten im Change Management

Anleitungen zur Datenextraktion

Export von Freshservice-Analytics-Rohdaten

Schritte

Konfiguration

Beispielabfrage sql

Datenextraktion mit Python über die Freshservice-REST-API

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Fehlgeschlagene Changes vermeiden: Verbessern Sie jetzt Ihr Freshservice-Management