> Kontinuierliche Prozessoptimierung > Problem Management > Zendesk Support > Datenvorlage

Ihre Problem Management Datenvorlage

Zendesk Support

Problem Management Attribute (20) Problem Management Aktivitäten (12) Extraktionsleitfäden (3)

Ihre Problem Management Datenvorlage

Diese Vorlage bietet ein umfassendes Framework zur Abbildung Ihres Problem Management Lebenszyklus innerhalb von Zendesk Support. Sie skizziert die wesentlichen Attribute, Prozess-Meilensteine und die Extraktionslogik, die erforderlich sind, um Bottlenecks in der Root Cause Analyse zu identifizieren. Durch die Befolgung dieser Struktur können Sie ein hochwertiges Event Log für tiefere Prozesseinblicke erstellen.

Empfohlene Attribute für die Detailanalyse
Wichtige Prozessaktivitäten und Statusübergänge
Extraktionsanleitung für Zendesk Support-Daten

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Problem Management Attribute

Diese empfohlenen Datenfelder liefern den notwendigen Kontext, um Ticket-Kategorien, Prioritätsstufen und Verantwortlichkeiten über den gesamten Lebenszyklus der Problemlösung hinweg zu analysieren.

5 Erforderlich 8 Empfohlen 7 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name des Ereignisses oder der Aktion, die am Problemdatensatz durchgeführt wurde.
Beschreibung Dieses Attribut erfasst den spezifischen Schritt oder die Aktion, die während des Lebenszyklus des Problemdatensatzes vorgenommen wurde. Beispiele hierfür sind Statusänderungen wie „Offen“ zu „Ausstehend“, Zuweisungsänderungen oder spezifische Workflow-Schritte wie „Workaround Published“. In der Analyse bildet dies die Knotenpunkte der Process Map. Die Reihenfolge dieser Aktivitäten ermöglicht es Analysten, den Arbeitsfluss zu visualisieren, Bottlenecks zu identifizieren und die Zeit zwischen spezifischen Prozessschritten zu messen. Bedeutung Es definiert das "Was" des Prozesses und ermöglicht die Visualisierung des Prozessflusses und die Variantenanalyse. Datenquelle Abgeleitet aus Zendesk Ticket Audits oder Ticket Metriken Beispiele Problemdatensatz erfasstUntersuchung eingeleitetWorkaround veröffentlicht
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der anzeigt, wann der Problemdatensatz zuletzt geändert wurde.
Beschreibung Dieses Attribut spiegelt den letzten Zeitpunkt wider, zu dem die Problemdatensatzdaten im Quellsystem aktualisiert wurden. Es unterscheidet sich vom Event-Timestamp, da es sich auf die Datensatzebene und nicht auf die Aktivitätsebene bezieht. In der Analyse hilft dies, die Aktualität der Daten zu bestimmen. Es wird verwendet, um zu identifizieren, ob der Datensatz aktuell ist oder ob Synchronisationsverzögerungen zwischen dem Quellsystem und der Process Mining Umgebung bestehen. Bedeutung Es verfolgt die Datenaktualität und unterstützt inkrementelle Datenladestrategien. Datenquelle Zendesk Ticket Objekt, Feld „updated_at“ Beispiele 2023-11-01T14:20:00Z
	Problemdatensatz ProblemRecordId	Die eindeutige numerische Kennung, die dem Problemticket in Zendesk zugewiesen ist.
Beschreibung Dieses Attribut stellt den eindeutigen Schlüssel für den Problemdatensatz innerhalb des Zendesk Support Systems dar. Es dient als zentrale Case ID für Process Mining, wodurch alle nachfolgenden Events, Updates und Interaktionen zu einer einzigen Prozessinstanz gruppiert werden können. In der Analyse wird diese ID verwendet, um jede Problemuntersuchungsreise von der Erstellung bis zum Abschluss eindeutig zu identifizieren. Sie ermöglicht die Korrelation verwandter Incidents und die Verfolgung des Problem-Lebenszyklus durch verschiedene Support-Stufen. Bedeutung Es ist der grundlegende obligatorische Schlüssel, der erforderlich ist, um Ereignisse für jede Process Mining-Analyse zu Fällen zu gruppieren. Datenquelle Zendesk Ticket Objekt, Feld „id“, wo Typ „problem“ ist Beispiele 1045293849921
	Quellsystem SourceSystem	Der Name des Systems, aus dem die `data` stammen.
Beschreibung Dieses Attribut identifiziert die Softwareplattform, aus der die Prozessdaten extrahiert wurden. In diesem Kontext wird es konsistent mit „Zendesk Support“ gefüllt. In der Analyse, insbesondere bei der Kombination von Daten aus mehreren Systemen (z. B. Zendesk und Jira), ermöglicht dieses Feld Analysten das Filtern oder Gruppieren von Daten nach ihrem Ursprung. Es gewährleistet Datenherkunft und Nachvollziehbarkeit in Multi-System-Prozessansichten. Bedeutung Es sichert die Datenherkunft und unterstützt multisystemische Process Mining-Konfigurationen. Datenquelle Während der Extraktion fest codiert Beispiele Zendesk Support
	Startzeit EventTimestamp	Das spezifische Datum und die Uhrzeit, wann eine Aktivität stattfand.
Beschreibung Dieses Attribut zeichnet den genauen Zeitpunkt auf, zu dem eine Aktivität innerhalb des Zendesk-Systems stattfand. Es liefert die zeitliche Dimension, die erforderlich ist, um Ereignisse korrekt zu sequenzieren und Dauern zwischen den Schritten zu berechnen. In der Analyse ist dies entscheidend für die Berechnung von Zykluszeiten, die Identifizierung von Verzögerungen, die Überprüfung der SLA-Compliance und die Visualisierung des Prozesses über die Zeit. Ohne genaue Timestamps ist es unmöglich, die Geschwindigkeit des Problemlösungsprozesses zu verstehen. Bedeutung Es ermöglicht die Sortierung von Aktivitäten und die Berechnung aller zeitbasierten KPIs. Datenquelle Zendesk Ticket Audits, Feld „created_at“ Beispiele 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	`SLA Due Date` SlaDueDate	Das Zieldatum und die Uhrzeit, bis zu der das Problem gelöst sein sollte.
Beschreibung Dieses Attribut stellt die Lösungsfrist basierend auf der Service Level Agreement Konfiguration dar. Es wird üblicherweise basierend auf der Priorität und der Erstellungszeit des Tickets berechnet. In der Analyse wird dies mit der tatsächlichen Lösungszeit verglichen, um die „Problem SLA Adherence Rate“ zu berechnen. Es speist das Dashboard „SLA Performance and Risk“, indem es Fälle hervorhebt, die ihre zugewiesene Zeit erreichen oder überschreiten. Bedeutung Es ist entscheidend für die Messung von Compliance und vertraglicher Leistung. Datenquelle Zendesk Ticket Metriken oder SLA-Richtlinien Endpunkt Beispiele 2023-12-01T17:00:00Z
	Anzahl verknüpfter Vorfälle RelatedIncidentCount	Die Anzahl der mit diesem Problemdatensatz verknüpften Vorfall-Tickets.
Beschreibung Dieses Attribut zählt, wie viele einzelne Incident-Tickets mit diesem Problemdatensatz verknüpft sind. In Zendesk wird dies über das Feld „problem_id“ in Incident-Tickets verwaltet, das auf diesen Datensatz zurückverweist. In der Analyse ist dies die primäre Metrik für „Incident Correlation and Impact“. Es hilft, Probleme zu priorisieren, die die größte Anzahl von Benutzern betreffen, und leitet strategische Entscheidungen darüber, welche Lösungen den höchsten ROI in Bezug auf die Reduzierung des Ticketvolumens erzielen werden. Bedeutung Es zeigt das Ausmaß und die Benutzerauswirkungen des Problems an. Datenquelle Zendesk Tickets API, Anzahl der Tickets, bei denen type='incident' und problem_id=ThisID Beispiele 015342
	Bearbeitername AssigneeName	Der spezifische Agent, der zur Bearbeitung des Problems zugewiesen wurde.
Beschreibung Dieses Attribut enthält den Namen des einzelnen Benutzers, der aktuell für den Problemdatensatz verantwortlich ist. Es bietet detaillierte Einblicke, wer spezifische Aktionen durchgeführt hat. In der Analyse hilft dies, die individuelle Arbeitslast und Leistung zu verstehen. Während eine Analyse auf Gruppenebene üblich ist, können Daten auf Zuweisungsebene den Schulungsbedarf oder Personen hervorheben, die besonders effektiv bei der Lösung komplexer Root Causes sind. Bedeutung Es ermöglicht die Ressourcenanalyse auf individueller Ebene. Datenquelle Zendesk Ticket Objekt, Feld „assignee_id“ (zu Namen aufgelöst) Beispiele John DoeJane SmithSystem
	Priorität Priority	Der Dringlichkeitsgrad, der dem Problemdatensatz zugewiesen ist.
Beschreibung Dieses Attribut gibt die relative Bedeutung des Problems an, typischerweise kategorisiert als Niedrig, Normal, Hoch oder Dringend. Es steuert die erwarteten Service Level Agreements (SLAs) und die Ressourcenzuweisung. In der Analyse wird dies verwendet, um den Prozess zu segmentieren und die Leistung über verschiedene Dringlichkeitsstufen hinweg zu vergleichen. Zum Beispiel hilft es zu überprüfen, ob „Dringende“ Probleme tatsächlich schneller gelöst werden als solche mit „Niedriger“ Priorität, wie es das Dashboard „Root Cause Investigation Velocity“ erfordert. Bedeutung Es ist unerlässlich für die Segmentierung von Fällen zur Analyse der SLA-Einhaltung und Ressourcenpriorisierung. Datenquelle Zendesk Ticket Objekt, Feld „priority“ Beispiele DringendHochNormalNiedrig
	Problemkategorie ProblemCategory	Die Klassifizierung des Problems (z. B. Software, Hardware, Netzwerk).
Beschreibung Dieses Attribut kategorisiert das Problem basierend auf dem betroffenen Service oder Technologie-Stack. Es ist typischerweise ein benutzerdefiniertes Dropdown-Feld in Zendesk Formularen. In der Analyse wird dies für das Dashboard „Problem Categorization Accuracy“ verwendet. Der Vergleich dieser anfänglichen Kategorie mit der endgültigen Root Cause hilft zu identifizieren, ob die initiale Triage Probleme korrekt den richtigen Teams zuweist. Bedeutung Es ermöglicht die Segmentierung nach Technologie oder Geschäftsservice. Datenquelle Zendesk Ticket Benutzerdefinierte Felder Beispiele DatenbankUI/UXNetzwerkinfrastruktur
	Problemstatus ProblemStatus	Der aktuelle Status des Problemdatensatzes in seinem Lebenszyklus.
Beschreibung Dieses Attribut zeigt den aktuellen Status des Problems an, z. B. Neu, Offen, Ausstehend, Gelöst oder Geschlossen. Es spiegelt den Fortschritt der Untersuchung wider. In der Analyse wird dies verwendet, um zwischen offenen und geschlossenen Fällen zu filtern. Es ist entscheidend für das Dashboard „Stale Problem Record Monitoring“, um zu identifizieren, welche aktiven Fälle nicht den erwarteten Status-Lebenszyklus durchlaufen. Bedeutung Es ermöglicht das Filtern von Fällen nach ihrem Abschlussstatus. Datenquelle Zendesk Ticket Objekt, Feld „status“ Beispiele neuopenpendingsolvedgeschlossen
	Support-Gruppe SupportGroup	Das Team oder die Abteilung, die aktuell dem Problemdatensatz zugewiesen ist.
Beschreibung Dieses Attribut identifiziert die spezifische Agentengruppe, die zu einem bestimmten Zeitpunkt für das Problem verantwortlich ist. Es ändert sich, wenn das Ticket von einem Team an ein anderes übergeben wird. In der Analyse ist dies entscheidend für das Dashboard „Support Group Handover Analysis“. Es ermöglicht die Messung der Teamleistung, die Identifizierung von Bottlenecks bei Übergaben und die Analyse der Ressourcen-Arbeitslastverteilung. Bedeutung Es ermöglicht die Organisationsanalyse und die Identifizierung von Engpässen zwischen Abteilungen. Datenquelle Zendesk Ticket Objekt, Feld „group_id“ (zu Namen aufgelöst) Beispiele L2 SupportDatenbank-TeamNetzwerkbetrieb
	Ursachenkategorie RootCauseCategory	Die identifizierte zugrunde liegende Ursache des Problems (z. B. Codefehler, Konfigurationsfehler).
Beschreibung Dieses Attribut erfasst die finale Diagnose, was das Problem verursacht hat. Es wird üblicherweise während der Aktivität „Root Cause Identified“ ausgefüllt. In der Analyse wird es zur Generierung des Berichts „Problem Categorization Accuracy“ und zur Analyse von Trends bei Systemausfällen verwendet. Es hilft dem Management zu verstehen, ob sie sich auf Codequalität, Infrastrukturstabilität oder Lieferantenmanagement konzentrieren sollten. Bedeutung Es ermöglicht die Analyse von Fehlerursachen und lenkt langfristige Verbesserungsbemühungen. Datenquelle Zendesk Ticket Benutzerdefinierte Felder Beispiele Software-BugKonfigurationsfehlerAnwenderfehler
	Change Request ID ChangeRequestId	Der Identifikator des Change Requests, der zur Implementierung der Lösung verknüpft ist.
Beschreibung Dieses Attribut verknüpft den Problemdatensatz mit einem Change Management Datensatz (potenziell in einem anderen System oder einem anderen Ticket-Typ). Es signalisiert, dass ein formaler Änderungsprozess initiiert wurde. In der Analyse unterstützt dies das Dashboard „Change Request Initiation Rate“. Es hilft, den Übergang von der Diagnose zur Implementierung zu verfolgen und sicherzustellen, dass identifizierte Root Causes zu formalen Änderungsaktionen führen. Bedeutung Es verknüpft den Problemprozess mit dem Change Management-Prozess. Datenquelle Zendesk Ticket Benutzerdefinierte Felder oder verknüpfte Tickets Beispiele CR-1002CHG00394
	Hat PIR HasPostImplementationReview	Kennzeichnet, ob eine Überprüfung nach der Implementierung durchgeführt wurde.
Beschreibung Dieses Attribut gibt an, ob der Problemlösungsprozess eine Überprüfungsphase enthielt. Es wird abgeleitet, indem geprüft wird, ob die Aktivität „Post-Implementation Review Conducted“ in der Fallhistorie vorhanden ist. In der Analyse unterstützt dies das Dashboard „Post Implementation Review Coverage“. Es ist eine Compliance-Metrik, die sicherstellt, dass die Organisation aus ihren Hauptproblemen lernt. Bedeutung Es validiert die Einhaltung kontinuierlicher Verbesserungsprozesse. Datenquelle Abgeleitet aus dem Vorhandensein der Aktivität 'Überprüfung nach der Implementierung durchgeführt' Beispiele truefalsch
	Ist veraltet IsStale	Kennzeichnet, wenn das Problem seit über 14 Tagen keine Aktivität hatte.
Beschreibung Dieses berechnete Attribut identifiziert Datensätze, die seit Kurzem nicht aktualisiert wurden. Es vergleicht das aktuelle Datum (oder Analyse-Datum) mit dem Timestamp der letzten Aktivität. In der Analyse speist dies das Dashboard „Stale Problem Record Monitoring“. Es hilft Managern, vernachlässigte Fälle, die den Backlog überladen und möglicherweise eine administrative Schließung oder Neuvergabe erfordern, schnell zu isolieren. Bedeutung Es hilft, Prozessverschwendung und vernachlässigte Arbeitselemente zu identifizieren. Datenquelle Im Process Mining Tool berechnet: (Jetzt - LetzteDatenaktualisierung) > 14 Tage Beispiele truefalsch
	Problembetreff ProblemSubject	Die kurze Zusammenfassung oder der Titel des Problemdatensatzes.
Beschreibung Dieses Attribut enthält die Textzusammenfassung, die beim Erstellen des Problems eingegeben wurde. Es beschreibt normalerweise das Symptom oder das untersuchte Problem. In der Analyse bietet dies dem Analysten Kontext beim Drilldown in spezifische Fälle. Text-Mining-Techniken können hier auch angewendet werden, um ähnliche Probleme zu gruppieren oder wiederkehrende Themen zu identifizieren, die nicht durch strukturierte Kategoriefelder erfasst werden. Bedeutung Es liefert menschenlesbaren Kontext für einzelne Fälle. Datenquelle Zendesk Ticket Objekt, Feld „subject“ Beispiele Zahlungen in der Region EU können nicht verarbeitet werdenLatenzspitzen auf dem Login-ServerDatenexport schlägt für Admin-Benutzer fehl
	Untersuchungsdauer InvestigationDuration	Die Zeit von Beginn der Untersuchung bis zur Identifizierung der Root Cause.
Beschreibung Dieses berechnete Attribut misst die Dauer der Kern-Diagnosephase. Es berechnet die Zeitdifferenz zwischen der Aktivität „Investigation Commenced“ und der Aktivität „Root Cause Identified“. In der Analyse ist dies die primäre Metrik für die „Average Root Cause Analysis Duration“. Es ermöglicht das Benchmarking der Diagnosegeschwindigkeit über verschiedene Support-Gruppen und Problemkategorien hinweg. Bedeutung Es misst die Effizienz des Diagnoseprozesses. Datenquelle Im Process Mining Tool berechnet: Zeitstempel(Stammursache) - Zeitstempel(Untersuchungsbeginn) Beispiele 48 Stunden5 Tage
	Wissensartikel-ID KnowledgeArticleId	Die ID des Wissensdatenbankartikels, der erstellt oder mit dem Problem verknüpft wurde.
Beschreibung Dieses Attribut speichert die Referenz zu einem Zendesk Guide Artikel oder einem externen Wissenselement. Es zeigt an, dass das aus dem Problem gewonnene Wissen erfasst wurde. In der Analyse wird das Vorhandensein dieses Feldes verwendet, um die „Knowledge Base Integration Rate“ zu berechnen. Es überprüft, ob die Organisation den Lernkreislauf schließt, indem sie Lösungen für zukünftige Referenzen dokumentiert. Bedeutung Es misst die Effektivität von Wissensmanagementprozessen. Datenquelle Zendesk Ticket Benutzerdefinierte Felder oder verknüpfte Inhalte Beispiele 360045889KB-2991
	Workaround aktiv WorkaroundActive	Ein Flag, das anzeigt, ob ein Workaround bereitgestellt/veröffentlicht wurde.
Beschreibung Dieses Boolesche Attribut gibt an, ob eine temporäre Lösung für das Problem dokumentiert wurde. Es wird oft aus dem Vorhandensein einer Aktivität „Workaround Published“ oder einem spezifischen Kontrollkästchen im Formular abgeleitet. In der Analyse wird dies für das Dashboard „Workaround Publication Compliance“ verwendet. Es misst, wie oft das Support-Team den Benutzern sofortige Entlastung bietet, während die langfristige Untersuchung fortgesetzt wird. Bedeutung Es ist entscheidend für die Messung der Minderung der Benutzerauswirkungen während der Untersuchungen. Datenquelle Abgeleitet aus dem Vorhandensein der Aktivität 'Workaround veröffentlicht' oder eines benutzerdefinierten Feldes Beispiele truefalsch

Erforderlich Empfohlen Optional

Problem Management Aktivitäten

Erfassen Sie diese wesentlichen Prozessschritte und Statusänderungen, um den End-to-End-Fluss von der anfänglichen Problemidentifikation bis zur Implementierung der dauerhaften Lösung zu visualisieren.

8 Empfohlen 4 Optional

	Aktivität	Beschreibung
	`Root Cause` identifiziert	Der Punkt, an dem die zugrunde liegende Ursache des Problems bestimmt wird. Dies wird typischerweise erfasst, wenn ein benutzerdefiniertes Textfeld „Root Cause“ oder eine Dropdown-Kategorie vom Agenten ausgefüllt wird.
Bedeutung Ein entscheidender Meilenstein für das Dashboard "Geschwindigkeit der Stammursachenanalyse" und zur Messung der Diagnoseeffizienz. Datenquelle Überwachen Sie Änderungen an benutzerdefinierten Feldern wie „Root Cause“, „RCA“ oder „Problem Source“ auf Nicht-Null-Werte. Erfassen Werte benutzerdefinierter Felder zur Füllung vergleichen Ereignistyp inferred
	Lösung verifiziert	Die formale Kennzeichnung des Problems als „Gelöst“. In Zendesk tritt dies auf, wenn der Standard-Systemstatus auf „Gelöst“ gesetzt wird, was anzeigt, dass die Behebung verifiziert und der Fall abgeschlossen ist.
Bedeutung Der primäre Endpunkt für SLA Performance- und Risiko-Berechnungen sowie die Problem SLA Adherence Rate. Datenquelle Abgeleitet aus der Statusänderung des Tickets zu 'Gelöst'. Erfassen Protokolliert, wenn der Status zu 'Gelöst' wechselt Ereignistyp explicit
	Permanente Lösung angewendet	Zeigt an, dass die technische Lösung in der Umgebung bereitgestellt wurde. Dies wird üblicherweise über einen benutzerdefinierten Statusübergang oder einen spezifischen Tag verfolgt, bevor das Ticket vollständig gelöst ist.
Bedeutung Unerlässlich für das Dashboard "Effizienz der Fix-Implementierung", um die Zeit von der Diagnose bis zur Bereitstellung zu messen. Datenquelle Abgeleitet von einem spezifischen Tag (z. B. 'fix_deployed') oder einem benutzerdefinierten Statusfeld, falls vorhanden. Erfassen Tags oder benutzerdefinierte Status-Dropdowns überwachen Ereignistyp inferred
	Problemdatensatz erfasst	Die initiale Erstellung des Problemtickets innerhalb von Zendesk Support. Dieses Event erfasst den Timestamp, wann das Problem erstmals im System erfasst wurde und in der Regel die Prozessinstanz auslöst.
Bedeutung Legt die Startzeit für den End-to-End-Lösungszyklus fest und dient als Basis für alle nachfolgenden Vorlaufzeitmetriken. Datenquelle Abgeleitet vom 'created_at'-Zeitstempel im Ticket-Objekt oder dem ersten Eintrag im Ticket-Audit-Log. Erfassen Protokolliert, wenn die Transaktion 'Ticket erstellt' ausgeführt wurde Ereignistyp explicit
	Problemdatensatz geschlossen	Das letzte Lebenszyklus-Event, bei dem das Ticket gesperrt wird und keine weiteren Änderungen vorgenommen werden können. In Zendesk geschieht dies in der Regel automatisch 4 Tage nach dem „Gelöst“-Status.
Bedeutung Markiert das absolute Ende des Lebenszyklus des Datensatzes und wird für die Datenaufbewahrung und historische Berichterstattung verwendet. Datenquelle Abgeleitet aus der Statusänderung des Tickets zu 'Geschlossen'. Erfassen Protokolliert, wenn sich der Status zu „Geschlossen“ ändert Ereignistyp explicit
	Supportgruppe zugewiesen	Die Weiterleitung des Problemdatensatzes an ein spezifisches technisches Team oder eine Abteilung. Dies wird verfolgt, wenn das Feld „Group ID“ im Ticket aktualisiert wird.
Bedeutung Entscheidend für das Dashboard "Support Group Handover Analysis", um Wartezeiten zwischen Abteilungen zu messen. Datenquelle Überwachen Sie das Feld „group_id“ im Ticket-Audit-Log auf Änderungen. Erfassen Protokolliert, wenn die Transaktion 'Gruppenzuordnung ändern' ausgeführt wurde Ereignistyp explicit
	Untersuchung eingeleitet	Markiert den Übergang von einem passiven „Neu“-Status zu einem aktiven Arbeitsstatus. Dies zeigt an, dass ein Agent das Problem zur Kenntnis genommen und mit der Diagnose begonnen hat.
Bedeutung Wird zur Berechnung von Kennzahlen für veraltete Problemdatensätze verwendet und ist der Ausgangspunkt für den KPI „Durchschnittliche Dauer der Root Cause Analyse“. Datenquelle Abgeleitet, wenn der Ticket-Status von 'Neu' zu 'Offen' oder 'Ausstehend' wechselt. Erfassen Statusfeld vor/nachher vergleichen Ereignistyp inferred
	Workaround veröffentlicht	Die Handlung, eine temporäre Lösung für das Problem zu dokumentieren und zu teilen. In Zendesk wird dies oft über einen spezifischen Tag oder ein benutzerdefiniertes Kontrollkästchen erfasst, das anzeigt, dass ein Workaround verfügbar ist.
Bedeutung Unterstützt das Dashboard zur Compliance bei der Veröffentlichung von Workarounds, um sicherzustellen, dass Benutzern während langer Untersuchungen eine vorübergehende Entlastung geboten wird. Datenquelle Überwachen Sie das Hinzufügen eines „workaround_published“-Tags oder eine Änderung eines benutzerdefinierten Booleschen Feldes namens „Workaround“. Erfassen Benutzerdefinierte Feld- oder Tag-Werte vergleichen Ereignistyp inferred
	Change Request initiiert	Zeigt an, dass ein formaler Change Management-Prozess zur Behebung des Problems ausgelöst wurde. Dies wird oft abgeleitet, wenn ein benutzerdefiniertes Feld 'Change Request ID' ausgefüllt oder ein Ticket vom Typ 'Change' verknüpft wird.
Bedeutung Verfolgt die Rate der Change Request Initiierung und verknüpft Problem Management mit Change Management Workflows. Datenquelle Überwachen Sie Aktualisierungen eines benutzerdefinierten Feldes wie „change_reference“ oder die Erstellung eines „problem_change“-Verknüpfungstyps. Erfassen Benutzerdefiniertes Feld auf Eingabe externer ID überwachen Ereignistyp inferred
	Post-Implementierungs-Überprüfung durchgeführt	Bestätigung, dass eine retrospektive Überprüfung nach der Fehlerbehebung abgeschlossen wurde. Dies ist typischerweise ein Kontrollkästchen oder Datumsfeld, das vom Prozesskoordinator aktualisiert wird.
Bedeutung Erforderlich für den KPI zur Häufigkeit der Post-Implementation Reviews, um die Einhaltung der Qualitätsstandards zu gewährleisten. Datenquelle Überwachen Sie Aktualisierungen eines benutzerdefinierten Kontrollkästchens „PIR Completed“ oder des Datumsfeldes „PIR Date“. Erfassen Benutzerdefiniertes Feld auf Vervollständigung überwachen Ereignistyp inferred
	Problemuntersuchung wiedereröffnet	Tritt auf, wenn ein zuvor als „Gelöst“ markierter Problemdatensatz in einen offenen oder aktiven Status zurückkehrt. Dies deutet auf eine fehlgeschlagene Behebung oder eine abgelehnte Lösung hin.
Bedeutung Unterstützt den KPI „Wiedereröffnungsrate von Problemen“ und hilft, Qualitätsprobleme im Lösungsprozess zu identifizieren. Datenquelle Abgeleitet, wenn der Status von 'Gelöst' zurück zu 'Offen', 'Neu' oder 'Ausstehend' wechselt. Erfassen Statusfeld vor/nachher vergleichen Ereignistyp inferred
	Vorgeschlagene Lösung entworfen	Die Erstellung eines Wissensdatenbankartikels basierend auf der Problemuntersuchung. Dies wird aus der Nutzung der Zendesk Knowledge Capture App oder der Verknüpfung eines neuen Artikels abgeleitet.
Bedeutung Unterstützt den KPI „Wissensdatenbank-Integrationsrate“ und gewährleistet organisationales Lernen. Datenquelle Überwachen Sie Ereignisse im Zusammenhang mit der „Knowledge Capture“-Integration oder Tags wie „kcs_draft“. Erfassen Ableitung aus spezifischen System-Tags oder Link-Ereignissen Ereignistyp inferred

Extraktionsleitfäden

So erhalten Sie Ihre Daten von Zendesk Support

Schritte

Melden Sie sich bei Ihrer Zendesk-Instanz an und navigieren Sie über das Produktfach zur Explore-Berichtsoberfläche.
Klicken Sie auf den Ordner 'Abfragen' (oder 'Berichte' in neueren Versionen) und wählen Sie 'Neue Abfrage'.
Wenn Sie aufgefordert werden, einen Datensatz auszuwählen, wählen Sie 'Support', gefolgt von 'Update-Verlauf' und dann 'Support: Update-Verlauf [Standard]'. Dieser Datensatz enthält die für das Process Mining erforderlichen Event Logs und nicht nur Daten zum aktuellen Zustand.
Fügen Sie im Bereich 'Metriken' 'Anzahl (Tickets)' oder 'Anzahl (Updates)' hinzu, um sicherzustellen, dass Daten abgerufen werden.
Fügen Sie im Bereich 'Filter' einen Filter für 'Ticket > Tickettyp' hinzu und wählen Sie 'Problem', um den Datensatz auf den Problem Management-Prozess zu beschränken.
Fügen Sie im Bereich 'Zeilen' die folgenden Attribute in dieser spezifischen Reihenfolge hinzu, um die Event Log-Struktur zu definieren: Ticket > Ticket-ID, Zeit - Zeitstempel > Update - Zeitstempel, Aktualisierer > Name des Aktualisierers und Änderungen > Änderungen - Feldname.
Um die Spalte 'Aktivitätsname' zu erstellen, müssen Sie ein 'Standard Calculated Attribute' erstellen. Klicken Sie auf das Berechnungs-Symbol in der rechten Seitenleiste, wählen Sie 'Standard calculated attribute', nennen Sie es 'Activity Mapper' und fügen Sie den im Abschnitt 'Abfrage' unten bereitgestellten Code ein.
Fügen Sie dieses neue 'Activity Mapper'-Attribut zum Bereich 'Zeilen' hinzu. Filtern Sie dieses Attribut, um NULL-Werte auszuschließen und irrelevanten Systemrauschen zu entfernen.
Fügen Sie zusätzliche Attribute zum Bereich 'Zeilen' für den Kontext hinzu: Ticket > Priorität, Ticket > Gruppe, Ticket > Status und alle benutzerdefinierten Felder, die für die Stammursachen- oder Kategorienanalyse erforderlich sind (z. B. Ticket > Ticket-Tags oder spezifische benutzerdefinierte Felder).
Legen Sie den Zeitbereich im Bereich 'Filter' mit 'Zeit - Zeitstempel > Update - Datum' fest, um Ihr gewünschtes Analysefenster abzudecken (z. B. Letzte 6 Monate).
Klicken Sie auf das Symbol 'Visualisierungstyp' und wählen Sie 'Tabelle'. Stellen Sie sicher, dass die Tabelle entpivotisiert oder flach ist, falls diese Option verfügbar ist, oder stellen Sie einfach sicher, dass alle Attribute im Bereich 'Zeilen' sind.
Exportieren Sie das Ergebnis, indem Sie auf 'Exportieren > CSV' klicken. Stellen Sie sicher, dass das Kontrollkästchen 'Attributformatierung beibehalten' aktiviert ist, um Zeitstempelformate für ProcessMind zu erhalten.

Konfiguration

Datensatz: Support: Update-Verlauf (Wichtig: Verwenden Sie nicht den Standard-Tickets-Datensatz, da dieser nur den aktuellen Zustand anzeigt).
Zeitfilter: Update - Datum (Empfohlen: Letzte 90 bis 180 Tage, je nach Datenvolumen).
Ticket-Typ: Streng nach 'Problem' filtern, um Vorfälle und Serviceanfragen nicht zu vermischen.
Zeilenlimit: Zendesk Explore-Exporte sind oft auf 50.000 Zeilen begrenzt. Falls Ihr Datensatz diese Grenze überschreitet, nutzen Sie den Filter 'Update - Datum', um die Daten in kleineren monatlichen Blöcken zu exportieren und extern zusammenzuführen.
Benutzerdefinierte Felder: Identifizieren Sie die spezifischen Feld-IDs für Stammursache, Change Request und Workaround in Ihrer Zendesk-Instanz, da dies keine Standard-Systemfelder sind.
Systemberechtigungen: Erfordert eine Explore Viewer- oder Explore Professional-Lizenz.

a Beispielabfrage config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Schritte

Bestätigung der Voraussetzungen: Stellen Sie sicher, dass das Zendesk Data Sharing Add-on in Ihrer Organisation aktiviert ist. Bestätigen Sie, dass Sie schreibgeschützte Zugangsdaten für die replizierte Zendesk-Datenbank haben, die typischerweise auf Snowflake oder Amazon Redshift gehostet wird.
Verbindung zur Datenbank herstellen: Verwenden Sie Ihren bevorzugten SQL-Client (wie DBeaver, DataGrip oder die native Snowflake/Redshift Weboberfläche), um eine Verbindung zu Ihrem Zendesk Data Warehouse mithilfe der bereitgestellten Zugangsdaten herzustellen.
Benutzerdefinierte Felder identifizieren: Bevor Sie die Abfrage ausführen, müssen Sie die eindeutigen IDs für die benutzerdefinierten Felder identifizieren, die in Ihrem Problem Management-Prozess verwendet werden. Navigieren Sie im Zendesk Admin Center zu Objekte und Regeln > Tickets > Felder. Finden Sie die Felder für 'Stammursache', 'Change Request ID', 'Workaround veröffentlicht', 'Dauerhafte Lösung angewendet' und 'Überprüfung nach der Implementierung', um deren spezifische Feld-IDs zu erhalten. Diese werden verwendet, um die Platzhalter in der Abfrage zu ersetzen.
SQL-Abfrage überprüfen: Die bereitgestellte Abfrage verwendet eine Common Table Expression (CTE) namens ProblemTickets, um zuerst alle Problemdatensätze auszuwählen und zu filtern. Dies verbessert die Performance und Lesbarkeit. Der Hauptteil der Abfrage verwendet dann UNION ALL, um die Ergebnisse von 12 separaten SELECT-Anweisungen zu kombinieren, eine für jede erforderliche Aktivität.
Abfrage anpassen: Öffnen Sie einen neuen Abfrage-Editor und fügen Sie das komplette SQL-Skript ein. Ändern Sie die Platzhalter im Skript:
- Legen Sie im ProblemTickets CTE den gewünschten Datumsbereich fest, indem Sie '[YYYY-MM-DD]' ersetzen.
- Ersetzen Sie für jede Aktivität, die auf einem benutzerdefinierten Feld basiert, die Platzhalter-IDs (z. B. [Ihre 'Stammursachenkategorie' Feld_ID], [Ihre 'Change Request ID' Feld_ID]) durch die tatsächlichen IDs, die Sie in Schritt 3 identifiziert haben.
Abfrage ausführen: Führen Sie das geänderte SQL-Skript gegen die Datenbank aus. Die Ausführungszeit variiert je nach Datumsbereich und Volumen der Ticketdaten.
Logik für 'Vorgeschlagene Lösung entworfen' untersuchen: Die Abfrage geht davon aus, dass das Entwerfen einer Lösung durch das Ausfüllen eines benutzerdefinierten Feldes namens [Ihre 'KB Artikel-ID' Feld_ID] erfasst wird. Wenn Ihr Prozess abweicht, zum Beispiel durch die Verwendung eines spezifischen Tags oder Kommentars, müssen Sie diesen Teil der Abfrage entsprechend anpassen.
Datenvalidierung: Nach Abschluss der Abfrage führen Sie eine kurze Überprüfung der Ergebnisse durch. Überprüfen Sie eine angemessene Anzahl von Zeilen, stellen Sie sicher, dass alle Spalten vorhanden sind, und suchen Sie nach unerwarteten NULL-Werten in kritischen Spalten wie ProblemRecordId und EventTimestamp.
Event Log exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-Codierung verwendet und dass die Spaltenüberschriften mit den Attributnamen übereinstimmen, die von Ihrem Process Mining Tool benötigt werden.
Für den Upload vorbereiten: Vor dem Hochladen überprüfen Sie die CSV-Datei auf Formatierungsprobleme. Stellen Sie sicher, dass Datums- und Zeitwerte in der Spalte EventTimestamp in einem konsistenten Format vorliegen, z. B. JJJJ-MM-TT HH24:MI:SS.

Konfiguration

Voraussetzungen: Diese Extraktion erfordert das Zendesk Data Sharing Add-on und direkten SQL-Zugriff auf die replizierten Daten in einer Snowflake- oder Amazon Redshift-Instanz.
Ticket-Typ-Filter: Die Abfrage ist vorkonfiguriert, um nur Tickets zu analysieren, deren type 'Problem' ist. Dies ist entscheidend, um den Problemmanagement-Prozess von Vorfällen und anderen Ticket-Typen zu isolieren.
Datumsbereich-Filterung: Es wird dringend empfohlen, die Daten für einen bestimmten Zeitraum zu filtern, um die Performance zu steuern. Die Abfrage enthält einen Platzhalter created_at >= '[YYYY-MM-DD]' im initialen CTE. Für eine erste Analyse ist ein Zeitraum von 3 bis 6 Monaten typisch.
Konfiguration benutzerdefinierter Felder: Diese Extraktion ist stark abhängig von Ihrer spezifischen Zendesk-Konfiguration. Sie müssen die korrekte field_id für benutzerdefinierte Felder identifizieren und einfügen, die Aktivitäten wie 'Stammursache identifiziert', 'Change Request initiiert' und 'Workaround veröffentlicht' verfolgen. Die Abfrage schlägt fehl oder liefert keine Daten für diese Aktivitäten, wenn die Platzhalter-IDs nicht ersetzt werden.
Datenlatenz: Die Daten in der replizierten Datenbank sind nicht in Echtzeit verfügbar. Es gibt in der Regel eine Verzögerung von einigen Stunden zwischen einem Ereignis in Zendesk und dessen Erscheinen im Data Warehouse. Beachten Sie dies bei der Analyse sehr aktueller Aktivitäten.

a Beispielabfrage sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3.6+ auf Ihrem System installiert ist. Installieren Sie die erforderlichen Bibliotheken requests und pandas, indem Sie pip install requests pandas in Ihrem Terminal oder Ihrer Eingabeaufforderung ausführen.
Zendesk API-Token generieren: Melden Sie sich als Administrator bei Zendesk Support an. Navigieren Sie zu Admin Center > Apps und Integrationen > APIs > Zendesk API. Klicken Sie im Abschnitt 'Token-Zugriff' auf 'API-Token hinzufügen', um ein neues Token zu erstellen. Kopieren Sie dieses Token sofort und speichern Sie es sicher, da es danach nicht mehr angezeigt wird.
Python-Skript konfigurieren: Erstellen Sie eine neue Python-Datei (z. B. extract_zendesk_problems.py) und kopieren Sie das vollständige Skript aus dem Abschnitt 'Abfrage' in diese Datei. Aktualisieren Sie die Platzhalter-Variablen am Anfang des Skripts: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN und START_TIME. Für den ersten Lauf setzen Sie START_TIME auf den Unix-Timestamp des gewünschten Startdatums für Ihre Extraktion.
Benutzerdefinierte Feld-IDs zuordnen: Identifizieren Sie die numerischen IDs für die benutzerdefinierten Felder, die in Ihrem Problem Management-Prozess verwendet werden. Sie finden diese, indem Sie zu Admin Center > Objekte und Regeln > Tickets > Felder navigieren und die URL oder Feldeigenschaften überprüfen. Aktualisieren Sie das CUSTOM_FIELD_MAPPING Dictionary im Skript mit Ihren spezifischen IDs.
Skript ausführen: Führen Sie das Skript von Ihrem Terminal aus mit dem Befehl python extract_zendesk_problems.py aus. Das Skript beginnt mit dem Abrufen von Daten über die Zendesk Incremental Export API.
Ausführung überwachen: Das Skript zeigt seinen Fortschritt an, einschließlich der Anzahl der verarbeiteten Tickets und des aktuellen Zeitstempels, der abgerufen wird. Es wird API-Ratenbegrenzungen automatisch behandeln, indem es bei Bedarf pausiert.
Datenabruf und Transformation: Das Skript ruft zuerst alle Problemtickets ab, die seit dem START_TIME erstellt oder aktualisiert wurden. Für jedes Problemticket ruft es dann den vollständigen Audit-Trail ab, der alle historischen Änderungen enthält.
Event Log-Generierung: Das Skript verarbeitet jedes Audit-Ereignis und ordnet Feldänderungen (wie Status, Gruppe oder Aktualisierungen benutzerdefinierter Felder) den definierten Geschäftsaktivitäten zu. Es ruft auch Benutzer- und Gruppennamen ab und speichert sie zwischen, um die Daten anzureichern.
Handhabung inkrementeller Ladevorgänge: Nach dem anfänglichen vollständigen Laden aktualisieren Sie für nachfolgende Läufe die Variable START_TIME auf die end_time, die am Ende des vorherigen erfolgreichen Laufs ausgegeben wurde. Dies stellt sicher, dass Sie nur neue und aktualisierte Daten ohne Duplizierung abrufen.
Ausgabe überprüfen: Nach Abschluss des Skripts wird eine Datei namens zendesk_problem_event_log.csv im selben Verzeichnis generiert. Diese CSV-Datei enthält den strukturierten Event Log, der zur Analyse bereit ist.
Für den Upload vorbereiten: Öffnen Sie die CSV-Datei in einem Tabellenkalkulationstool, um deren Inhalt zu überprüfen. Stellen Sie sicher, dass alle erforderlichen Spalten (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) vorhanden und korrekt gefüllt sind, bevor Sie sie zu ProcessMind hochladen.

Konfiguration

Zendesk API-Zugangsdaten: Das Skript benötigt Ihre Zendesk-Subdomain, die E-Mail-Adresse des dem API-Token zugeordneten Benutzers und das API-Token selbst zur Authentifizierung.
Startzeitpunkt: Die Variable START_TIME ist ein Unix-Epoch-Timestamp, der den Startpunkt für die Datenextraktion definiert. Für den ersten Lauf setzen Sie diesen auf ein Datum in der Vergangenheit (z. B. vor 6 Monaten), um historische Daten zu erhalten. Für nachfolgende Läufe verwenden Sie die Endzeit des vorherigen Laufs, um Daten inkrementell abzurufen.
Mapping benutzerdefinierter Felder: Das Dictionary CUSTOM_FIELD_MAPPING ist entscheidend. Sie müssen die Platzhalter-IDs mit den tatsächlichen IDs der benutzerdefinierten Felder aus Ihrer Zendesk-Instanz aktualisieren, um Aktivitäten wie 'Workaround veröffentlicht' und 'Stammursache identifiziert' korrekt zu erfassen.
Ticket-Typ-Filter: Das Skript ist fest programmiert, nur Tickets zu verarbeiten, deren type 'Problem' ist. Dies stellt sicher, dass Vorfälle, Aufgaben und Fragen aus dem Event Log des Problemmanagements ausgeschlossen werden.
API-Ratenbegrenzung: Das Skript enthält eine grundlegende time.sleep(60) Funktion zur Handhabung von 429 'Too Many Requests'-Fehlern. Diese Dauer der Pause muss möglicherweise je nach Ihrem Zendesk-Plan und dem Volumen der extrahierten Daten angepasst werden.
Voraussetzungen: Eine Python 3 Umgebung mit den Bibliotheken requests und pandas ist erforderlich, um das Skript auszuführen. Das API-Token muss einem Konto zugeordnet sein, das über die Berechtigung zum Lesen von Ticketdaten verfügt.

a Beispielabfrage python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

class=class="hl-string">"hl-comment"># Caching for user and group lookups to reduce API calls
user_cache = {}
group_cache = {}

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

def get_user_name(user_id):
    if not user_id: return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return str(user_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def get_group_name(group_id):
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return str(group_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'zendesk_problem_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

Ihre Problem Management Datenvorlage

Ihre Problem Management Datenvorlage

Problem Management Attribute

Problem Management Aktivitäten

Extraktionsleitfäden

Zendesk Explore Updates History Export

Schritte

Konfiguration

a Beispielabfrage config

SQL-Abfrage über Zendesk Data Sharing

Schritte

Konfiguration

a Beispielabfrage sql

Python-Extraktion mit inkrementeller Export-API

Schritte

Konfiguration

a Beispielabfrage python

Bereit, um loszulegen?

Ihr Problem Management für schnellere IT-Lösungen optimieren

Ihre Problem Management Datenvorlage

Ihre Problem Management Datenvorlage

Problem Management Attribute

Problem Management Aktivitäten

Extraktionsleitfäden

Zendesk Explore Updates History Export

Schritte

Konfiguration

a Beispielabfrage config

SQL-Abfrage über Zendesk Data Sharing

Schritte

Konfiguration

a Beispielabfrage sql

Python-Extraktion mit inkrementeller Export-API

Schritte

Konfiguration

a Beispielabfrage python

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Ihr Problem Management für schnellere IT-Lösungen optimieren