Ihr Daten-Template für die Bearbeitung von Retouren und Erstattungen

Die Ereigniszeit beziehungsweise der Timestamp erfasst das genaue Datum und die Uhrzeit einer Aktivität. Jede Aktivität im Event Log hat einen zugehörigen Timestamp, der die chronologische Reihenfolge der Ereignisse festlegt.

Dieses Attribut ist für alle zeitbasierten Process-Mining-Analysen entscheidend. Es dient dazu, Zykluszeiten zwischen Aktivitäten zu berechnen, Wartezeiten und Engpässe zu erkennen, die gesamte Falldauer zu messen und die Einhaltung von Service Level Agreements (SLAs) zu prüfen. Die Genauigkeit der Timestamps wirkt sich direkt auf die Zuverlässigkeit jeder Leistungsanalyse aus.

Dieser Timestamp ist erforderlich, um alle zeitbasierten Kennzahlen wie Zyklus- und Wartezeiten zu berechnen. Sie bilden eine wichtige Grundlage für die Leistungsanalyse.

Entspricht Datumsfeldern für Erstellung oder Änderung in verschiedenen Tabellen, zum Beispiel 'SalesTable.createdDateTime' für die Auftragserstellung oder 'WMSJournalTrans.createdDateTime' für Lagerjournale.

Die Retourenfall-ID ist die zentrale Kennung für jeden einzelnen Retourenprozess. Sie verknüpft alle Aktivitäten zu einer bestimmten Retoure oder Erstattungsanfrage eines Kunden, von der Erstellung des Retourenauftrags bis zum endgültigen Abschluss.

Für die Prozessanalyse ist diese ID entscheidend, um den gesamten Ablauf jeder Retoure zu rekonstruieren. Sie ermöglicht es, den vollständigen Prozessverlauf nachzuverfolgen, die gesamte Durchlaufzeit zu messen und Unterschiede zwischen einzelnen Fällen zu analysieren. Alle Ereignisse, Daten und Kennzahlen werden anhand dieser Kennung zusammengeführt und miteinander verknüpft.

Diese zentrale Fallkennung verknüpft alle Prozessschritte. So lässt sich jede Retoure vom Anfang bis zum Abschluss nachverfolgen und analysieren.

Dies ist üblicherweise die Nummer der Return Material Authorization (RMA) oder die Nummer eines Verkaufsauftrags vom Typ 'Returned Order' im Modul 'Sales and marketing'. Sie ist in Tabellen wie 'SalesTable' zu finden, in denen 'SalesType' den Wert 'Returned Order' hat.

Dieses Attribut bezeichnet einen bestimmten Schritt oder ein Ereignis im Retouren- und Erstattungsprozess, zum Beispiel 'Retourenauftrag erstellt', 'Ware eingegangen' oder 'Gutschrift gebucht'. Jede Aktivität steht für einen eigenen Prozessschritt, der im System erfasst wird.

Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten bildet die Grundlage von Process Mining. Sie ermöglicht die Visualisierung von Prozessabläufen, das Erkennen von Engpässen zwischen Schritten und das Aufdecken häufiger wie seltener Prozessvarianten. Die Aktivitäten legen fest, welcher Prozess analysiert wird.

Das Attribut bildet die Prozessschritte ab und ermöglicht es, den Prozessablauf zu visualisieren sowie Engpässe, Nacharbeit und Abweichungen zu erkennen.

Dieses konzeptionelle Attribut wird aus Systemereignissen abgeleitet. Es lässt sich erstellen, indem Statusänderungen in Tabellen wie 'SalesTable' und 'WMSJournalTable' oder bestimmte Ereignisprotokolle verständlichen Namen zugeordnet werden.

Der Dispositionscode wird bei der Qualitätsprüfung einer retournierten Ware zugewiesen. Er legt den nächsten Prozessschritt fest, zum Beispiel 'Credit', 'Replace', 'Scrap' oder 'Return to Customer'.

Dieses Attribut ist ein wichtiger Entscheidungspunkt im Retourenprozess. Eine Analyse nach Dispositionscode zeigt, wie Retouren abgeschlossen werden, welche finanziellen Auswirkungen die Verschrottung von Waren hat und wie effizient verschiedene Lösungswege sind, etwa Ersatzlieferung oder Erstattung.

Dieser Code legt fest, welchen Weg ein Retourenfall nach der Prüfung nimmt. Er ist daher entscheidend für die Analyse von Prozessvarianten und deren geschäftlichen Auswirkungen.

Dieses Feld ist ein zentrales Element des Qualitätsmanagementmoduls. Es wird bei der Verarbeitung von Qualitäts- oder Prüfaufträgen verwendet.

Die Produkt-ID, häufig die Artikelnummer (SKU), kennzeichnet den konkreten Artikel, den der Kunde zurücksendet. Jede Position eines Retourenauftrags ist einer Produkt-ID zugeordnet.

Die Analyse der Retouren nach Produkt ist wichtig, um Artikel mit hohen Retourenquoten zu erkennen. Das kann auf Qualitätsprobleme, ungenaue Produktbeschreibungen oder Herstellungsfehler hindeuten. Die Analyse hilft dabei, Untersuchungen und Verbesserungen für bestimmte Produkte zu priorisieren.

Ermöglicht die Analyse von Retouren nach Produkt und hilft dabei, Artikel mit Qualitätsproblemen oder besonders vielen Rücksendungen zu erkennen.

Dies entspricht dem Feld 'ItemId' in der Tabelle 'SalesLine' des Retourenauftrags.

Der Retourengrundcode erfasst den vom Kunden angegebenen Rücksendegrund, zum Beispiel „Defekter Artikel“, „Falsche Größe“, „Entspricht nicht der Beschreibung“ oder „Wird nicht mehr benötigt“. Diese Information wird in der Regel bei der Einleitung der Retoure erfasst.

Die Analyse der Retourengründe ist wichtig, um Ursachen zu ermitteln. Sie hilft Unternehmen, Qualitätsmängel, unzutreffende Produktbeschreibungen oder Fehler in der Logistik zu erkennen. Die daraus gewonnenen Erkenntnisse können Verbesserungen am Produktdesign, im Marketing und in der Lieferkette anstoßen und so künftige Retouren verringern.

Zeigt, warum Retouren erfolgen, und ermöglicht so eine Ursachenanalyse, mit der sich die Retourenquote senken und die Kundenzufriedenheit verbessern lässt.

Diese Information ist üblicherweise auf Positionsebene des Retourenauftrags gespeichert. Suchen Sie bei Retourenaufträgen in der Tabelle 'SalesLine' nach Feldern für den Retourengrundcode.

Dieses Attribut gibt an, über welchen Kanal der Kunde die Retoure eingeleitet hat, zum Beispiel über das „Online-Portal“, im „Geschäft“, per „Anruf beim Kundenservice“ oder per „Post“.

Wenn Sie die Prozessanalyse nach Retourenkanal aufschlüsseln, können Sie die Leistung und Effizienz der einzelnen Kanäle bewerten. Unternehmen können Durchlaufzeiten, Kosten und Kundenzufriedenheit kanalübergreifend vergleichen und so bewährte Vorgehensweisen sowie Bereiche mit Investitions- oder Verbesserungsbedarf erkennen. Diese Auswertung ist wichtig für das Dashboard „Leistung der Retourenkanäle“.

Ermöglicht den Leistungsvergleich verschiedener Retourenkanäle und hilft dabei, die effizientesten und kostengünstigsten Kanäle zu optimieren.

Diese Information kann im Kopf des Retourenauftrags ('SalesTable') gespeichert oder anhand des Benutzers abgeleitet werden, der den Auftrag erstellt hat. Möglicherweise sind dafür eine benutzerdefinierte Logik oder ein eigenes Feld erforderlich.

Dieses Attribut gibt an, welcher Benutzer für die Ausführung eines Prozessschritts verantwortlich ist. Das kann der Lagerarbeiter sein, der die Ware entgegennimmt, der Qualitätsprüfer oder der Finanzsachbearbeiter, der die Gutschrift bucht.

Eine Analyse nach Benutzern zeigt, wie sich die Arbeitslast verteilt, wer besonders gute Ergebnisse erzielt und wo Schulungsbedarf bestehen könnte. Außerdem können Sie Fälle untersuchen, die von bestimmten Personen oder Teams bearbeitet wurden, und die Funktionstrennung sicherstellen.

Damit lassen sich die Arbeitslastverteilung und die Leistung einzelner Personen oder Teams analysieren. Außerdem können Sie Schulungsbedarf und Möglichkeiten zur Ressourcenverteilung erkennen.

Zu finden in den Feldern 'created by' oder 'modified by' von Transaktionsdatensätzen, zum Beispiel in 'SalesTable.createdBy' oder als verknüpfte Benutzer-IDs in Journaltabellen.

Dieses Attribut enthält den ursprünglichen Erstattungsbetrag, der zu Beginn des Retourenprozesses angefordert oder erwartet wurde. Grundlage ist in der Regel der ursprüngliche Kaufpreis der zurückgesendeten Artikel.

Dieser Wert dient als Ausgangspunkt für die „Analyse von Abweichungen beim Erstattungsbetrag“. Durch den Vergleich des angeforderten mit dem tatsächlich erstatteten Betrag können Unternehmen Abweichungen erkennen, die etwa durch Wiedereinlagerungsgebühren, Teilerstattungen für beschädigte Waren oder andere Anpassungen entstehen. So lassen sich die finanzielle Genauigkeit und die Einhaltung von Richtlinien überwachen.

Dient als Ausgangswert für die Prüfung der finanziellen Genauigkeit, indem er mit dem tatsächlich verarbeiteten Erstattungsbetrag verglichen wird.

Dies ist üblicherweise der Positions- oder Gesamtbetrag der ursprünglichen Verkaufsauftragsposition, die zurückgesendet wird. Sie finden ihn in 'SalesLine.LineAmount'.

Der Endzeitpunkt gibt den Abschluss-Timestamp einer Aktivität an. Während StartTime den Beginn markiert, bezeichnet EndTime das Ende. Damit lässt sich die Bearbeitungszeit der jeweiligen Aufgabe berechnen.

Dieses Attribut ist für detaillierte Leistungsanalysen wichtig, insbesondere bei Aufgaben mit messbarer Dauer wie der 'Warenprüfung'. Durch den Vergleich von StartTime und EndTime können Analysten die aktive Bearbeitungszeit genau messen und von der Wartezeit zwischen Aufgaben unterscheiden. So lassen sich Ineffizienzen innerhalb einzelner Aktivitäten erkennen, nicht nur zwischen ihnen.

Damit lässt sich die aktive Bearbeitungszeit einzelner Aktivitäten berechnen und von der Wartezeit unterscheiden.

Dieser Wert muss häufig abgeleitet werden. Er kann beispielsweise dem 'modifiedDateTime' einer Statusänderung entsprechen, mit der eine Aktivität abgeschlossen wird, oder der StartTime der nachfolgenden Aktivität.

Bei der Verarbeitung einer Erstattung wird ein Finanzdokument erstellt, das als Gutschrift oder Gutschriftsanzeige bezeichnet wird. Dieses Attribut enthält die eindeutige ID des Dokuments.

Über diese ID lässt sich der operative Retourenprozess direkt mit den Finanzdaten im Buchhaltungssystem verknüpfen. Sie ist für Prüfungen und detaillierte Analysen finanzieller Abweichungen hilfreich. So kann ein Analyst einen Retourenfall bis zur konkreten Finanztransaktion zurückverfolgen, mit der er abgeschlossen wurde.

Verknüpft den operativen Retourenprozess mit der zugehörigen Finanztransaktion und ist damit wichtig für Prüfungen und den finanziellen Abgleich.

Die Gutschriftnummer steht üblicherweise im Feld 'InvoiceId' der Tabelle 'CustInvoiceJour', wenn der Transaktionstyp 'Credit note' lautet. Sie lässt sich mit dem Retourenauftrag verknüpfen.

Die Kunden-ID ist die eindeutige Kennung des Kundenkontos, das der Retoure zugeordnet ist. Sie verknüpft den Retourenvorgang mit einem bestimmten Kunden im CRM- oder Kundendatenbanksystem.

Die Analyse der Retouren nach Kunde hilft dabei, Kunden mit ungewöhnlich vielen Rücksendungen zu erkennen. Dies kann auf betrügerisches Verhalten oder anhaltende Unzufriedenheit hindeuten. Außerdem lassen sich Kunden segmentieren, um beispielsweise besonders wertvollen Kunden einen Premium-Retourenservice anzubieten.

Verknüpft den Retourenprozess mit einem bestimmten Kunden und ermöglicht so Analysen auf Kundenebene sowie die Erkennung von Retourenmustern und möglichem Betrug.

Dies ist das Feld 'CustAccount' in der Tabelle 'SalesTable' des Retourenauftrags.

Dieses Attribut kennzeichnet das konkrete Lager oder Retourenzentrum, in dem der zurückgesendete Artikel bearbeitet wird. Je nach Standort können sich Prozesse, Ressourcen und Leistungsniveau unterscheiden.

Die Analyse nach Lager ermöglicht Leistungsvergleiche zwischen Standorten. Sie zeigt, welche Einrichtungen Retouren besonders effizient bearbeiten, macht regionale Engpässe sichtbar und unterstützt Entscheidungen zur Ressourcenverteilung und Standardisierung von Prozessen im Logistiknetzwerk.

Ermöglicht den Leistungsvergleich verschiedener Lager und Retourenzentren und hilft dabei, regionale Engpässe sowie bewährte Vorgehensweisen zu erkennen.

Diese Information ist im Feld 'InventLocationId' von bestandsbezogenen Transaktionen gespeichert, etwa im Wareneingangsjournal ('WMSJournalTable') oder in der Tabelle 'SalesLine'.

Dieses Attribut erfasst Datum und Uhrzeit, zu denen die Daten zuletzt aus dem Quellsystem exportiert und im Process-Mining-Tool aktualisiert wurden. Es zeigt, wie aktuell die analysierten Daten sind.

Der Zeitpunkt der letzten Datenaktualisierung ist wichtig, um die Aktualität der Analyse einzuschätzen. So können Benutzer Dashboards und KPIs richtig einordnen und erkennen, ob sie Echtzeitdaten oder einen Datenstand von einem bestimmten Zeitpunkt betrachten. Das ist für die operative Überwachung entscheidend.

Das Attribut zeigt, wie aktuell die Daten sind, damit Analysten den zeitlichen Bezug ihrer Prozesserkenntnisse einschätzen können.

Dieses Metadatenattribut wird während der Datenübernahme erzeugt und gespeichert. Es entspricht üblicherweise dem Timestamp, zu dem der ETL-Auftrag abgeschlossen wurde.

Dieses Attribut gibt an, aus welchem Informationssystem die Daten stammen. In diesem Fall ist das in erster Linie 'Microsoft Dynamics 365'.

In größeren Unternehmen kann sich ein Prozess über mehrere Systeme erstrecken. Das Quellsystem für jedes Ereignis anzugeben, ist wichtig für die Data Governance, die Fehlersuche beim Datenexport und das Verständnis der Systemlandschaft des Prozesses. So lässt sich die Herkunft der analysierten Daten nachvollziehen.

Das Attribut liefert wichtigen Kontext zur Datenherkunft. Dieser ist für Data Governance, Validierung und das Verständnis der Systemlandschaft des Prozesses erforderlich.

Dabei handelt es sich üblicherweise um einen statischen Wert, der beim Prozess für Datenextraktion, Transformation und Laden (ETL) hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Dieses Attribut klassifiziert den Retourenfall nach der Lösung, die der Kunde wünscht oder das Unternehmen anbietet. Übliche Typen sind eine Geldrückerstattung, ein Austausch gegen einen Ersatzartikel oder eine Reparatur.

Diese Einteilung erleichtert die Analyse unterschiedlicher Prozessabläufe. Die Bearbeitung einer Erstattung unterscheidet sich deutlich vom Versand eines Ersatzartikels. Durch die Aufschlüsselung nach Retourentyp lassen sich Durchlaufzeiten und Engpässe für die einzelnen Lösungswege genauer analysieren.

Ermöglicht die Analyse nach dem angestrebten Ergebnis, da Erstattungen und Ersatzlieferungen unterschiedliche Schritte und Durchlaufzeiten haben.

Dies kann ein benutzerdefiniertes Feld im Kopf des Retourenauftrags sein oder anhand des Dispositionscodes beziehungsweise nachfolgender Transaktionen abgeleitet werden, etwa der Erstellung eines Ersatzverkaufsauftrags.

Dieses berechnete boolesche Attribut gibt an, ob eine Retoure alle Kriterien der Unternehmensrichtlinie erfüllt. Dabei können Faktoren wie die Rückgabefrist, der Zustand des Artikels oder der Retourengrund berücksichtigt werden.

Das Attribut unterstützt direkt das Dashboard „Übersicht zur Compliance bei Retourengenehmigungen“ und die KPI „Anteil richtlinienkonformer Retourengenehmigungen“. Unternehmen können damit die Einhaltung der Richtlinien quantifizieren, als Ausnahme genehmigte Cases erkennen und Gründe sowie Häufigkeit solcher Ausnahmen analysieren. Das ist wichtig für Governance und Kostenkontrolle.

Misst direkt die Einhaltung der Geschäftsregeln und hilft dabei, nicht richtlinienkonforme Retourengenehmigungen zu erkennen und zu verringern, die zu Umsatzeinbußen führen können.

Dies ist ein abgeleitetes Attribut. Für die Berechnung müssen Merkmale der Retoure, etwa das Retouren- und Kaufdatum oder der Retourengrund, mit vordefinierten Geschäftsregeln verglichen werden.

Dieses berechnete Attribut zeigt den SLA-Status in einfacher Form an, üblicherweise als „Fristgerecht“ oder „Verspätet“. Der Status ergibt sich aus dem Vergleich des Timestamps der letzten Aktivität, zum Beispiel „Retourenauftrag geschlossen“, mit dem Attribut 'RefundSlaTargetDate'.

Das Attribut vereinfacht die Leistungsberichte in Dashboards wie „SLA-Leistung bei Erstattungen“. Statt Datumsangaben selbst vergleichen zu müssen, sehen Benutzer einen direkten und leicht verständlichen Status. So können sie schnell filtern und Daten zusammenfassen, um die „Einhaltung des SLA für die Falllösung“ zu berechnen.

Zeigt auf einen Blick, ob das SLA eingehalten wurde. So lassen sich verspätete Cases einfach filtern und die Ursachen von Verzögerungen analysieren.

Dies ist ein abgeleitetes Attribut. Es wird berechnet, indem der Timestamp der letzten Aktivität zur Falllösung mit dem Attribut 'RefundSlaTargetDate' verglichen wird.

Dieses Attribut gibt den aktuellen Status des Retourenauftragskopfs an, zum Beispiel „Offen“, „Fakturiert“ oder „Storniert“. Es zeigt auf hoher Ebene, an welcher Stelle des Lebenszyklus sich der Case befindet.

Aktivitäten bilden einzelne Prozessschritte ab, während der Gesamtstatus zum Filtern und Segmentieren von Cases dient. Ein Analyst kann sich beispielsweise auf „Offene“ Cases konzentrieren, um die aktuelle Arbeitslast zu verstehen, oder den Prozessablauf von Cases analysieren, die schließlich „Storniert“ werden.

Fasst den Status des Cases auf hoher Ebene zusammen. Das erleichtert das Filtern und hilft, Ergebnisse wie Stornierungen nachzuvollziehen.

Diese Information steht im Feld 'SalesStatus' oder 'DocumentStatus' der Tabelle 'SalesTable'.

Dieses Attribut enthält den endgültigen, bestätigten Betrag, der dem Kunden erstattet wurde. Der Wert wird bei der Erstellung und Buchung der Gutschrift erfasst.

Das Attribut ist für Finanzanalysen entscheidend und wird direkt im Dashboard „Analyse von Abweichungen beim Erstattungsbetrag“ sowie für die KPI „Genauigkeit der Erstattungsbeträge“ verwendet. Die Analyse dieser Daten zeigt die finanziellen Auswirkungen von Retouren und die während des Prozesses vorgenommenen Anpassungen.

Zeigt die tatsächlichen finanziellen Auswirkungen der Retoure. Der Wert ist entscheidend, um die Genauigkeit der Erstattungen zu berechnen und finanzielle Ergebnisse nachzuvollziehen.

Diesen Wert finden Sie in den Details der gebuchten Gutschrifttransaktion. Er steht mit den Tabellen 'CustTrans' und 'CustInvoiceJour' zur Gutschrift in Verbindung.

Dieses Attribut legt die Frist des Service Level Agreement (SLA) für die Bearbeitung eines Retourenfalls fest. Bis zu diesem Datum soll der Kunde eine endgültige Lösung erhalten, etwa eine gebuchte Erstattung oder einen versendeten Ersatzartikel.

Das Zieldatum ist wichtig, um die Leistung anhand der vereinbarten Serviceziele zu überwachen. Es dient zur Berechnung der KPI „Einhaltung des SLA für die Falllösung“ und als Grundlage für das Dashboard „SLA-Leistung bei Erstattungen“. Durch den Vergleich mit dem tatsächlichen Abschlussdatum können Unternehmen SLA-Verstöße erkennen und überfällige Cases frühzeitig bearbeiten.

Dient als Maßstab für die Prozessleistung und ermöglicht es, die SLA-Einhaltung zu verfolgen und verspätete Cases zu erkennen.

Möglicherweise ist dies kein Standardfeld. Häufig wird der Wert anhand des Erstellungsdatums der Retoure und einer festgelegten SLA-Frist berechnet, zum Beispiel 14 Tage. Er kann in einem benutzerdefinierten Feld gespeichert sein.