Ihr Daten-Template für die Retouren- und Erstattungsabwicklung

Die Ereigniszeit beziehungsweise der Timestamp erfasst das genaue Datum und die Uhrzeit, zu denen eine Aktivität stattgefunden hat. Jede Aktivität im Event Log verfügt über einen zugehörigen Timestamp, der die chronologische Reihenfolge der Ereignisse festlegt.

Dieses Attribut ist für alle zeitbezogenen Process-Mining-Analysen entscheidend. Es dient zur Berechnung von Durchlaufzeiten zwischen Aktivitäten, zur Identifikation von Wartezeiten und Engpässen, zur Messung der gesamten Case-Dauer sowie zur Prüfung der Einhaltung von Service Level Agreements (SLAs). Die Genauigkeit der Timestamps wirkt sich unmittelbar auf die Zuverlässigkeit jeder Leistungsanalyse aus.

Dieser Timestamp ist für die Berechnung aller dauerbezogenen Kennzahlen wie Durchlauf- und Wartezeiten unerlässlich. Diese Kennzahlen bilden eine wichtige Grundlage der Leistungsanalyse.

Entspricht Datumsfeldern für die Erstellung oder Änderung in verschiedenen Tabellen, beispielsweise „SalesTable.createdDateTime“ für die Auftragserstellung oder „WMSJournalTrans.createdDateTime“ für Lagerjournale.

Die Retourenfall-ID dient als primäre Kennung für jede einzelne Instanz eines Retourenprozesses. Sie verknüpft alle Aktivitäten, die zu einer bestimmten Kundenretoure oder Erstattungsanfrage gehören, von der Erstellung des Retourenauftrags bis zu seinem endgültigen Abschluss.

In der Prozessanalyse ist diese ID grundlegend für die Rekonstruktion des End-to-End-Ablaufs jeder Retoure. Sie ermöglicht die Nachverfolgung des gesamten Lebenszyklus, die Messung der Gesamtdurchlaufzeiten und die Analyse von Unterschieden zwischen verschiedenen Cases. Alle Ereignisse, Daten und Kennzahlen werden anhand dieser Kennung aggregiert und miteinander korreliert.

Dies ist die zentrale Case-Kennung, die alle Prozessschritte verbindet und dadurch die Nachverfolgung und Analyse jeder Retoure vom Anfang bis zum Ende ermöglicht.

Dabei handelt es sich in der Regel um die Return Material Authorization (RMA)-Nummer oder die Sales-Order-Nummer des Typs „Returned Order“ im Modul „Sales and marketing“. Sie ist in Tabellen wie „SalesTable“ zu finden, wenn „SalesType“ den Wert „Returned Order“ hat.

Dieses Attribut beschreibt einen konkreten Schritt oder ein Ereignis im Lebenszyklus einer Retoure und Erstattung, beispielsweise „Return Order Created“, „Item Received“ oder „Credit Note Posted“. Jede Aktivität stellt einen eigenständigen Punkt im Prozess dar, der im System erfasst wird.

Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten bildet den Kern von Process Mining. Sie ermöglicht die Visualisierung von Prozessmodellen, die Identifikation von Engpässen zwischen Schritten sowie die Erkennung häufiger und seltener Prozessvarianten. Die Menge der Aktivitäten definiert den Umfang des analysierten Prozesses.

Es definiert die Prozessschritte und ermöglicht dadurch die Visualisierung des Prozessablaufs sowie die Identifikation von Engpässen, Nacharbeit und Abweichungen.

Dies ist ein konzeptionelles Attribut, das aus Systemereignissen abgeleitet wird. Es kann durch die Zuordnung von Statusänderungen in Tabellen wie „SalesTable“ und „WMSJournalTable“ oder von bestimmten Event Logs zu verständlichen Namen erzeugt werden.

Der Dispositionscode wird während der Qualitätsprüfung eines retournierten Artikels zugewiesen. Er legt den nächsten Prozessschritt fest, beispielsweise „Credit“, „Replace“, „Scrap“ oder „Return to Customer“.

Dieses Attribut ist ein entscheidender Entscheidungspunkt im Retourenprozess. Die Analyse nach Dispositionscode ermöglicht es Unternehmen, die Ergebnisse von Retouren zu verstehen, die finanziellen Auswirkungen der Verschrottung von Artikeln zu verfolgen und die Effizienz verschiedener Lösungswege wie Ersatzlieferung und Erstattung zu bewerten.

Dieser Code bestimmt den Weg, den ein Retourenfall nach der Prüfung nimmt. Damit ist er für die Analyse von Prozessvarianten und deren Geschäftsergebnissen entscheidend.

Dies ist ein wichtiges Feld im Qualitätsmanagementmodul. Es ist mit der Verarbeitung von Quality Order oder Inspection Order verknüpft.

Die Produkt-ID, häufig die Stock Keeping Unit (SKU), identifiziert den konkreten Artikel, den der Kunde zurücksendet. Jede Retourenauftragszeile ist mit einer Produkt-ID verknüpft.

Die Analyse von Retouren nach Produkt ist entscheidend, um Artikel mit hohen Retourenquoten zu identifizieren. Dies kann auf Probleme bei der Qualitätskontrolle, ungenaue Produktbeschreibungen oder Herstellungsfehler hinweisen. Die Analyse hilft dabei, produktbezogene Untersuchungen und Verbesserungen zu priorisieren.

Sie ermöglicht die Analyse von Retouren auf Produktebene und hilft, Artikel mit Qualitätsproblemen oder hohen Retourenvolumina zu identifizieren.

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

Der Retourengrundcode erfasst den vom Kunden genannten Rücksendegrund, beispielsweise „Defective Item“, „Wrong Size“, „Not as Described“ oder „No Longer Needed“. Diese Information wird in der Regel bei der Einleitung der Retoure erfasst.

Die Analyse von Retourengründen ist für die Ursachenanalyse von großer Bedeutung. Sie hilft Unternehmen, Probleme mit der Produktqualität, fehlerhafte Produktbeschreibungen oder logistische Fehler zu erkennen. Die daraus gewonnenen Erkenntnisse können Verbesserungen bei Produktdesign, Marketing und Lieferkettenprozessen anstoßen und so künftige Retouren reduzieren.

Es liefert wichtige Erkenntnisse darüber, warum Retouren entstehen, und ermöglicht eine Ursachenanalyse zur Senkung der Retourenquote und Verbesserung der Kundenzufriedenheit.

Dieser Wert wird typischerweise auf Ebene der Retourenauftragszeile gespeichert. Suchen Sie in der Tabelle „SalesLine“ für Retourenaufträge nach Feldern für den Retourengrundcode.

Dieses Attribut gibt den vom Kunden verwendeten Kanal zum Start des Retourenprozesses an, beispielsweise „Online Portal“, „In-Store“, „Customer Service Call“ oder „Mail“.

Die Segmentierung der Prozessanalyse nach Retourenkanal hilft bei der Bewertung der Leistung und Effizienz jedes Kanals. Ein Unternehmen kann Durchlaufzeiten, Kosten und Kundenzufriedenheit kanalübergreifend vergleichen, um bewährte Vorgehensweisen sowie Investitions- und Verbesserungsmöglichkeiten zu erkennen. Dies ist für das Dashboard „Return Channel Utilization Performance“ entscheidend.

Es 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 aus dem Benutzer abgeleitet werden, der den Auftrag erstellt hat. Möglicherweise sind dafür eine individuelle Logik oder ein eigenes Feld erforderlich.

Dieses Attribut identifiziert die Person, die für die Ausführung eines Prozessschritts verantwortlich ist. Dabei kann es sich um den Lagermitarbeiter handeln, der den Artikel entgegengenommen hat, um den Qualitätsprüfer oder um den Finanzsachbearbeiter, der die Gutschrift gebucht hat.

Die Analyse nach Benutzern hilft, die Arbeitslastverteilung zu verstehen, besonders leistungsstarke Mitarbeiter zu identifizieren und möglichen Schulungsbedarf zu erkennen. Sie kann außerdem zur Untersuchung von Cases dienen, die von bestimmten Personen oder Teams bearbeitet wurden, sowie zur Sicherstellung einer angemessenen Funktionstrennung.

Es ermöglicht die Analyse der Arbeitslastverteilung und der Leistung einzelner Mitarbeiter oder Teams sowie die Identifikation von Möglichkeiten für Schulungen oder eine bessere Ressourcenverteilung.

Zu finden in Feldern wie „created by“ oder „modified by“ in Transaktionsdatensätzen, beispielsweise „SalesTable.createdBy“, oder in verknüpften Benutzer-IDs in Journaltabellen.

Dieses Attribut stellt den ursprünglichen Erstattungsbetrag dar, der zu Beginn des Retourenprozesses angefordert oder erwartet wird. Er basiert in der Regel auf dem ursprünglichen Kaufpreis der retournierten Artikel.

Dieser Wert dient als Referenz für die „Refund Amount Discrepancy Analysis“. Durch den Vergleich des angeforderten Betrags mit dem tatsächlich erstatteten Betrag kann das Unternehmen Abweichungen erkennen, die beispielsweise durch Wiedereinlagerungsgebühren, Teilerstattungen für beschädigte Waren oder andere Anpassungen entstehen. Dies unterstützt die Überwachung der finanziellen Genauigkeit und der Einhaltung von Richtlinien.

Er dient als Referenzwert zur Messung der finanziellen Genauigkeit, indem er mit dem tatsächlich verarbeiteten Erstattungsbetrag verglichen wird.

Dabei handelt es sich typischerweise um den Zeilenbetrag oder Gesamtbetrag der ursprünglichen Auftragszeile, die retourniert wird. Der Wert ist in „SalesLine.LineAmount“ zu finden.

Die Endzeit bezeichnet den Abschluss-Timestamp einer Aktivität. Während StartTime den Beginn markiert, kennzeichnet EndTime das Ende. Dadurch lässt sich die Bearbeitungszeit der jeweiligen Aufgabe berechnen.

Dieses Attribut ist für eine detaillierte Leistungsanalyse entscheidend, insbesondere bei Aufgaben mit messbarer Dauer wie „Item Inspection“. Durch den Vergleich von StartTime und EndTime können Analysten die aktive Bearbeitungszeit von Aufgaben präzise messen und von der Wartezeit zwischen Aufgaben unterscheiden. So lassen sich Ineffizienzen innerhalb einzelner Aktivitäten und nicht nur zwischen ihnen erkennen.

Es ermöglicht die Berechnung der aktiven Bearbeitungszeit einzelner Aktivitäten und hilft dabei, Wartezeit von tatsächlicher Arbeitszeit zu unterscheiden.

Dieser Wert muss häufig abgeleitet werden. Er kann beispielsweise dem „modifiedDateTime“ einer Statusänderung entsprechen, die eine Aktivität abschließt, oder der StartTime der nachfolgenden Aktivität.

Bei der Verarbeitung einer Erstattung wird ein Finanzdokument erstellt, das als Gutschrift oder Credit Memo bezeichnet wird. Dieses Attribut speichert die eindeutige ID dieses Dokuments.

Die ID stellt eine direkte Verbindung zwischen dem operativen Retourenprozess und den Finanzdaten im Buchhaltungssystem her. Sie ist für Prüfzwecke und die detaillierte Untersuchung finanzieller Abweichungen nützlich, da Analysten einen Retourenfall bis zur konkreten Finanztransaktion zurückverfolgen können, durch die er ausgeglichen wurde.

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

Die Gutschriftsnummer befindet sich typischerweise im Feld „InvoiceId“ der Tabelle „CustInvoiceJour“, wenn der Transaktionstyp „Credit note“ lautet. Sie kann mit dem Retourenauftrag verknüpft werden.

Die Kunden-ID ist die eindeutige Kennung des mit der Retoure verbundenen Kundenkontos. Sie verknüpft die Retourentransaktion mit einem bestimmten Kunden im CRM oder in der Kundendatenbank.

Die Analyse von Retouren nach Kunde ermöglicht es, Kunden mit ungewöhnlich vielen Retouren zu identifizieren. Dies kann auf betrügerisches Verhalten oder anhaltende Unzufriedenheit hindeuten. Außerdem lässt sich die Kundensegmentierung unterstützen, beispielsweise um besonders wertvollen Kunden Premium-Retourenservices anzubieten.

Sie verknüpft den Retourenprozess mit einem bestimmten Kunden und ermöglicht dadurch die Analyse auf Kundenebene sowie die Identifikation von Retourenmustern oder möglichem Betrug.

Dies ist das Feld „CustAccount“ in „SalesTable“ für den Retourenauftrag.

Dieses Attribut identifiziert das konkrete physische Lager oder Retourenzentrum, in dem der retournierte Artikel verarbeitet wird. Verschiedene Standorte können unterschiedliche Prozesse, Ressourcen oder Leistungsniveaus aufweisen.

Die Analyse nach Lager ermöglicht einen Leistungsvergleich zwischen Standorten. Sie kann zeigen, welche Einrichtungen Retouren besonders effizient verarbeiten, regionale Engpässe sichtbar machen und Entscheidungen zur Ressourcenverteilung sowie zur Standardisierung von Prozessen im Logistiknetzwerk unterstützen.

Es ermöglicht den Leistungsvergleich verschiedener Lager oder Retourenzentren und hilft, regionale Engpässe oder bewährte Vorgehensweisen zu identifizieren.

Diese Information wird im Feld „InventLocationId“ von bestandsbezogenen Transaktionen gespeichert, beispielsweise im Wareneingangsjournal („WMSJournalTable“) oder in „SalesLine“.

Dieses Attribut erfasst Datum und Uhrzeit der letzten Extraktion aus dem Quellsystem und der Aktualisierung im Process-Mining-Tool. Es dient als Bezugspunkt für die Aktualität der analysierten Daten.

Die Kenntnis des Zeitpunkts der letzten Datenaktualisierung ist wichtig, um die Aktualität der Analyse einzuschätzen. Sie hilft Ihnen, Dashboards und KPIs korrekt zu interpretieren und zu erkennen, ob Sie Echtzeitdaten oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten. Dies ist für das operative Monitoring entscheidend.

Es zeigt die Aktualität der Daten an und stellt sicher, dass Analysten den zeitlichen Stand ihrer Prozesserkenntnisse kennen.

Dies ist ein Metadatenattribut, das während der Datenaufnahme erzeugt und gespeichert wird. Es entspricht in der Regel dem Timestamp des Abschlusses des ETL-Jobs.

Dieses Attribut identifiziert das Quellsystem, aus dem die Daten stammen. In diesem Kontext handelt es sich hauptsächlich um „Microsoft Dynamics 365“.

In größeren Organisationen erstreckt sich ein Prozess möglicherweise über mehrere Systeme. Die Angabe des Quellsystems für jedes Ereignis ist entscheidend für die Data Governance, die Behebung von Problemen bei der Datenextraktion und das Verständnis der technologischen Prozesslandschaft. Sie bestätigt die Herkunft der analysierten Daten.

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

Dabei handelt es sich in der Regel um einen statischen Wert, der während des ETL-Prozesses zur Kennzeichnung der Herkunft des Datensatzes ergänzt wird.

Dieses Attribut klassifiziert den Retourenfall anhand der vom Kunden gewünschten oder vom Unternehmen angebotenen Lösungsart. Häufige Typen sind eine finanzielle „Refund“, der Austausch gegen einen „Replacement“-Artikel oder eine „Repair“.

Diese Kategorisierung eignet sich zur Analyse verschiedener Prozesspfade. Die Ausstellung einer Erstattung unterscheidet sich deutlich vom Versand eines Ersatzartikels. Die Segmentierung nach Retourentyp ermöglicht eine präzisere Analyse der Durchlaufzeiten und Engpässe, die für den jeweiligen Lösungsweg spezifisch sind.

Sie ermöglicht die Segmentierung der Analyse nach dem angestrebten Ergebnis, da Erstattungs- und Ersatzprozesse unterschiedliche Schritte und Durchlaufzeiten aufweisen.

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

Dies ist ein berechnetes boolesches Attribut, das angibt, ob eine Retoure alle in der Retourenrichtlinie des Unternehmens definierten Kriterien erfüllt. Grundlage können beispielsweise die Rückgabefrist, der Zustand des Artikels oder der Retourengrund sein.

Dieses Attribut unterstützt direkt das Dashboard „Return Approval Compliance Overview“ und die KPI „Compliant Return Approval Rate“. Es ermöglicht dem Unternehmen, die Richtlinieneinhaltung zu quantifizieren, als Ausnahmen genehmigte Cases zu identifizieren und Gründe sowie Häufigkeit solcher Ausnahmen zu analysieren. Dies ist für Governance und Kostenkontrolle von großer Bedeutung.

Es misst die Einhaltung von Geschäftsregeln direkt und hilft, nicht konforme Retourengenehmigungen zu erkennen und zu reduzieren, die zu Umsatzeinbußen führen können.

Dies ist ein abgeleitetes Attribut. Die Logik muss durch den Vergleich von Retourenattributen, beispielsweise Retourendatum, Kaufdatum und Retourengrund, mit vordefinierten Geschäftsregeln erstellt werden.

Dieses berechnete Attribut liefert einen einfachen Status zur SLA-Einhaltung, typischerweise „On Time“ oder „Late“. Der Status wird durch den Vergleich des Timestamps der letzten Aktivität, beispielsweise „Return Order Closed“, mit „RefundSlaTargetDate“ ermittelt.

Das Attribut vereinfacht die Leistungsberichterstattung in Dashboards wie „Refund Resolution SLA Performance“. Anstatt Datumswerte selbst vergleichen zu müssen, erhalten Benutzer einen direkten und leicht verständlichen Status. Dadurch lassen sich verspätete Cases schnell filtern und die gesamte „Resolution SLA Adherence Rate“ berechnen.

Es bietet einen übersichtlichen Indikator für die SLA-Einhaltung und erleichtert das Filtern verspäteter Cases sowie die Analyse der Ursachen von Verzögerungen.

Dies ist ein abgeleitetes Attribut, das durch den Vergleich des Timestamps der abschließenden Lösungsaktivität mit dem Attribut „RefundSlaTargetDate“ berechnet wird.

Dieses Attribut gibt den aktuellen Status des Kopfes des Retourenauftrags an, beispielsweise „Open“, „Invoiced“ oder „Canceled“. Es bietet einen Überblick darüber, an welcher Stelle des Lebenszyklus sich der Case befindet.

Während Aktivitäten detaillierte Prozessschritte abbilden, eignet sich der Gesamtstatus zum Filtern und Segmentieren von Cases. Ein Analyst kann beispielsweise nur „Open“-Cases betrachten, um die aktuelle Arbeitslast zu verstehen, oder den Prozessablauf von Cases analysieren, die letztlich den Status „Canceled“ erreichen.

Es liefert eine übergeordnete Zusammenfassung des Case-Status und eignet sich zum Filtern von Cases sowie zum Verständnis von Ergebnissen wie Stornierungen.

Diese Information befindet sich im Feld „SalesStatus“ oder „DocumentStatus“ der Tabelle „SalesTable“.

Dieses Attribut enthält den endgültig bestätigten Betrag, der dem Kunden erstattet wurde. Der Wert wird erfasst, wenn die Gutschrift erstellt und gebucht wird.

Dieses Attribut ist für die Finanzanalyse entscheidend und wird direkt im Dashboard „Refund Amount Discrepancy Analysis“ sowie in der KPI „Refund Amount Accuracy Rate“ verwendet. Die Analyse dieser Daten hilft, die finanziellen Auswirkungen von Retouren und die während des Prozesses vorgenommenen Anpassungen zu verstehen.

Dieser Wert stellt die tatsächlichen finanziellen Auswirkungen der Retoure dar und ist entscheidend für die Berechnung der Erstattungsgenauigkeit sowie das Verständnis der finanziellen Ergebnisse.

Dieser Wert ist in den Transaktionsdetails der gebuchten Gutschrift zu finden. Er steht mit den Tabellen „CustTrans“ und „CustInvoiceJour“ für die Gutschrift in Verbindung.

Dieses Attribut definiert die Frist des Service Level Agreement (SLA) für die Lösung eines Retourenfalls. Bis zu diesem Datum soll der Kunde eine abschließende Lösung erhalten, beispielsweise eine gebuchte Erstattung oder einen versendeten Ersatzartikel.

Dieses Zieldatum ist für die Überwachung der Leistung anhand von Serviceverpflichtungen entscheidend. Es dient zur Berechnung der KPI „Resolution SLA Adherence Rate“ und speist das Dashboard „Refund Resolution SLA Performance“. Durch den Vergleich dieses Datums mit dem tatsächlichen Abschlussdatum des Prozesses kann das Unternehmen SLA-Verletzungen erkennen und alternde Cases proaktiv bearbeiten.

Es ist der Maßstab für die Messung der Prozessleistung und ermöglicht die Überwachung der SLA-Einhaltung sowie die Identifikation verspäteter Cases.

Dies ist möglicherweise kein Standardfeld. Häufig wird der Wert aus dem Erstellungsdatum der Retoure zuzüglich einer vordefinierten SLA-Frist berechnet, beispielsweise 14 Tage. Er kann in einem benutzerdefinierten Feld gespeichert werden.