Ihr Daten-Template für die Bearbeitung von Rückgaben und Erstattungen
Ihr Daten-Template für die Bearbeitung von Rückgaben und Erstattungen
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Prozessanalyse
- Schritt-für-Schritt-Anleitung zum Extrahieren von Daten aus Oracle Fusion SCM
Attribute für die Bearbeitung von Rückgaben und Erstattungen
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Der Name eines bestimmten Geschäftsschritts oder Ereignisses im Retouren- und Rückerstattungsprozess. | ||
|
Beschreibung
Dieses Attribut bezeichnet einen einzelnen Schritt oder Meilenstein im Retourenprozess, zum Beispiel „RMA erstellt“, „Artikel geprüft“ oder „Rückerstattung abgewickelt“. Jede Aktivität steht für einen bestimmten Prozesspunkt, der in den Event Logs des Systems erfasst wird. Die Analyse der Abfolge und Dauer dieser Aktivitäten bildet den Kern von Process Mining. Sie ermöglicht die Visualisierung von Prozesslandkarten, das Erkennen von Engpässen zwischen Schritten und die Berechnung der Durchlaufzeiten einzelner Aktivitäten. Diese Daten sind entscheidend, um den Prozessablauf, Nacharbeitsschleifen und die Einhaltung von Standardarbeitsanweisungen zu verstehen.
Warum das wichtig ist
Aktivitäten bilden das Grundgerüst der Prozesslandkarte. Sie ermöglichen es, den Prozessablauf und seine Varianten zu visualisieren und Engpässe zu analysieren.
Woher beziehen
Abgeleitet aus Event Logs, Statusänderungen oder bestimmten Transaktionsdatensätzen in Oracle-Fusion-SCM-Modulen wie Order Management und Inventory Management.
Beispiele
RMA erstelltArtikel eingegangenGutschrift erstelltRückerstattung abgewickelt
|
|||
|
Ereigniszeit
EventTime
|
Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Die Ereigniszeit, auch Startzeit genannt, bezeichnet das genaue Datum und die Uhrzeit, zu der eine Aktivität im Quellsystem erfasst wurde. Sie ordnet jeden Prozessschritt chronologisch ein. Dieser Timestamp ist für alle zeitbasierten Analysen unverzichtbar. Er dient dazu, Ereignisse korrekt zu ordnen, Durchlaufzeiten zwischen Aktivitäten zu berechnen, die Gesamtdauer eines Falls zu messen und die Leistung anhand von Service-Level-Agreements (SLAs) zu bewerten. Ohne genaue Timestamps lassen sich weder die Prozesseffizienz analysieren noch Verzögerungen erkennen oder Prozessdynamiken nachvollziehen.
Warum das wichtig ist
Dieses Attribut gibt die chronologische Abfolge der Ereignisse an. Sie ist grundlegend für die Berechnung aller zeitbasierten Kennzahlen und das Erkennen von Prozessengpässen.
Woher beziehen
Diese Information findet sich in Oracle Fusion SCM üblicherweise in einem Feld wie „Erstellungsdatum“, „Timestamp“ oder „Datum der letzten Aktualisierung“, das Transaktions- oder Statusdatensätzen zugeordnet ist.
Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Retourenfall-ID
ReturnCaseId
|
Der zentrale Bezeichner, der alle Aktivitäten zu einer bestimmten Kundenretoure oder einem Rückerstattungsantrag verknüpft. | ||
|
Beschreibung
Die Retourenfall-ID ist der eindeutige Bezeichner für den gesamten Retouren- und Rückerstattungsprozess. Sie verknüpft alle Ereignisse, von der Erstellung der Return Material Authorization (RMA) bis zur abschließenden Rückerstattung und zum Schließen des Falls. In der Process-Mining-Analyse ist dieses Attribut entscheidend, um den End-to-End-Ablauf jeder Retoure zu rekonstruieren. Analysten können damit den gesamten Prozessverlauf verfolgen, Durchlaufzeiten messen und nachvollziehen, wie sich die Bearbeitung verschiedener Retouren unterscheidet. Alle weiteren Ereignisdaten werden anhand dieser ID gruppiert, sodass sich der Prozess als zusammenhängender Ablauf analysieren lässt.
Warum das wichtig ist
Dieser Schlüssel ist unverzichtbar, um alle zusammengehörigen Ereignisse zu einer einzigen Prozessinstanz zusammenzuführen und eine End-to-End-Analyse zu ermöglichen.
Woher beziehen
Dieser Bezeichner wird üblicherweise in Oracle Order Management oder den Servicemodulen erzeugt, wenn ein Retourenantrag eingeleitet wird.
Beispiele
RMA-2023-00123RMA-2023-00456RMA-2023-00789
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, zu dem die Daten zuletzt aus dem Quellsystem aktualisiert oder extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt an, wann der Datensatz zuletzt aktualisiert wurde. Es zeigt an, wie aktuell der gesamte Datensatz ist, nicht einzelne Ereignisse. Der Zeitpunkt der letzten Datenaktualisierung hilft Benutzern, die Aktualität der Analyse einzuschätzen. So können sie Dashboards und Kennzahlen richtig einordnen und erkennen, ob sie Echtzeitinformationen oder Daten betrachten, die bereits Stunden oder Tage alt sind. Diese Metadaten sind für jedes Process-Mining-Projekt wichtig.
Warum das wichtig ist
Informiert Benutzer darüber, wie aktuell die Daten sind, und hilft ihnen, Kontext und Aktualität ihrer Analyse richtig einzuschätzen.
Woher beziehen
Dieser Timestamp wird während der Datenextraktion, -transformation und -ladung (ETL) erzeugt und hinzugefügt.
Beispiele
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut bezeichnet das Informationssystem, in dem die Ereignisdaten ursprünglich erfasst wurden. Für diesen Prozess ist das üblicherweise „Oracle Fusion SCM“. In Umgebungen mit mehreren integrierten Systemen ist dieses Feld für die Datenherkunft und die Fehlerbehebung entscheidend. Es bestätigt den Ursprung der Daten und ermöglicht es, Ereignisse aus bestimmten Systemen gezielt zu filtern. So bleiben Datenqualität und Kontext erhalten.
Warum das wichtig ist
Das Attribut liefert wichtige Informationen zur Datenherkunft. Diese sind für die Datenvalidierung und Analyse in Umgebungen mit mehreren Systemen unverzichtbar.
Woher beziehen
Dieser Wert wird häufig während der Datenextraktion, -transformation und -ladung (ETL) statisch hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen.
Beispiele
Oracle Fusion SCMOracle SCM Cloud
|
|||
|
Beantragter Erstattungsbetrag
RequestedRefundAmount
|
Der Geldbetrag, den der Kunde ursprünglich für die Rückgabe beantragt hat. | ||
|
Beschreibung
Dieses Attribut erfasst den Betrag, den der Kunde zu Beginn des Prozesses als Erstattung beantragt hat. Er dient als Ausgangswert für den Vergleich mit der endgültigen Erstattung. Dieser Datenpunkt ist für das Dashboard „Beantragte und tatsächliche Erstattungsbeträge“ und die KPI „Abweichungsquote bei Erstattungsbeträgen“ unverzichtbar. Der Vergleich der beantragten und tatsächlich ausgezahlten Beträge kann Probleme wie fehlerhafte Rücksendungen, Wiedereinlagerungsgebühren oder Anpassungen aufgrund von Richtlinien aufdecken. So gewinnen Sie Erkenntnisse zur finanziellen Genauigkeit und Kundenzufriedenheit.
Warum das wichtig ist
Dient als Ausgangswert für die Finanzanalyse, ermöglicht die Berechnung von Erstattungsabweichungen und macht mögliche Probleme sichtbar.
Woher beziehen
Dieser Wert sollte im RMA- oder Rücksendeantragskopf in Oracle Fusion SCM gespeichert sein, wahrscheinlich im Modul Order Management.
Beispiele
129.9945.501200.00
|
|||
|
Bearbeitende Person
ProcessingAgent
|
Der Benutzer oder die zuständige Person, die eine bestimmte Aktivität im Retourenprozess ausführt. | ||
|
Beschreibung
Dieses Attribut bezeichnet den Mitarbeitenden oder Systembenutzer, der eine bestimmte Aufgabe ausgeführt hat, zum Beispiel eine RMA freizugeben oder eine Rückerstattung abzuwickeln. Wenn keine Zuordnung zu einzelnen Personen erfasst wird, kann es sich auch um ein Team oder eine Abteilung handeln. Die Analyse der Leistung nach bearbeitender Person ist für die operative Steuerung wichtig. Mit diesem Attribut lässt sich das Dashboard „Leistung der Retourenbearbeitung“ erstellen. Es ermöglicht Vergleiche der Arbeitslast, Aktivitätsdauer und Nacharbeitsquoten verschiedener Personen. Die Erkenntnisse können auf Schulungsbedarf hinweisen, besonders leistungsstarke Mitarbeitende sichtbar machen und eine bessere Ressourcenverteilung unterstützen.
Warum das wichtig ist
Ermöglicht die Leistungsanalyse nach Benutzer oder Team. So lassen sich besonders leistungsstarke Mitarbeitende, Schulungsbedarf und eine ungleich verteilte Arbeitslast erkennen.
Woher beziehen
Diese Information findet sich in Oracle Fusion SCM üblicherweise in Feldern wie „USER_ID“, „PROCESSED_BY“ oder „AGENT_NAME“ in Transaktionsprotokollen.
Beispiele
j.doea.smithm.jones
|
|||
|
Endzeit
EndTime
|
Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde. | ||
|
Beschreibung
Die Endzeit markiert den Abschluss einer Aktivität. Während die Startzeit angibt, wann ein Ereignis begonnen hat, wird die Endzeit benötigt, um die tatsächliche Bearbeitungszeit dieses Ereignisses zu berechnen. Bei Ereignissen ohne Dauer können Start- und Endzeit identisch sein. Die Differenz zwischen End- und Startzeit ergibt in der Analyse die „Verarbeitungszeit“ einer Aktivität. So lässt sich erkennen, welche Schritte besonders zeitaufwendig sind, unabhängig von den Wartezeiten zwischen ihnen. Das ist wichtig für eine detaillierte Engpassanalyse und die Berechnung der Ressourceneffizienz.
Warum das wichtig ist
Dieses Attribut ist erforderlich, um die tatsächliche Bearbeitungszeit einzelner Aktivitäten zu berechnen und aktive Arbeitszeit von Wartezeit zu unterscheiden.
Woher beziehen
Dies kann ein separates Feld in den Protokollen des Quellsystems sein oder aus der Startzeit der nachfolgenden Aktivität abgeleitet werden.
Beispiele
2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
|
|||
|
Retourenstatus
ReturnStatus
|
Der aktuelle oder abschließende Status des Retourenfalls. | ||
|
Beschreibung
Dieses Attribut gibt den Gesamtstatus eines Retourenfalls zu einem bestimmten Zeitpunkt oder sein abschließendes Ergebnis an, zum Beispiel „Geschlossen – Rückerstattung“, „Geschlossen – Abgelehnt“ oder „In Bearbeitung“. Der Retourenstatus ist wichtig für die Ergebnisanalyse und Überwachung. Damit lassen sich Fälle nach ihrem Ergebnis filtern, die Abläufe freigegebener und abgelehnter Retouren vergleichen und das Dashboard „Aktueller Status des Retourenfalls“ erstellen. Die Verteilung der Ergebnisse zu verstehen, ist entscheidend, um die Wirksamkeit des Prozesses zu messen.
Warum das wichtig ist
Zeigt das Ergebnis eines Falls an. Das ist wichtig, um Fälle zu filtern, Ergebnisse zu vergleichen und die Erfolgsquote des Prozesses zu verstehen.
Woher beziehen
Der Status ist üblicherweise als Statusfeld im Datensatz des Hauptauftragskopfs für die Retoure oder RMA in Oracle Order Management verfügbar.
Beispiele
Warten auf WareneingangPrüfung abgeschlossenAbgeschlossen – erstattetAbgeschlossen – abgelehnt
|
|||
|
Rückgabegrund
ReturnReason
|
Der vom Kunden angegebene Grund für die Rückgabe des Artikels. | ||
|
Beschreibung
Dieses Attribut enthält den Rückgabegrund, den der Kunde in der Regel aus einer vorgegebenen Liste auswählt, zum Beispiel „Artikel defekt“, „Falsche Größe“ oder „Nicht mehr benötigt“. Die Analyse der Rückgabegründe liefert wichtige Erkenntnisse zur Produktqualität, zur Genauigkeit des Verkaufsprozesses und zum Kundenverhalten. Anhand dieser Daten lassen sich Produkte mit hohen Fehlerquoten ermitteln, Produktbeschreibungen verbessern und Fehlbestellungen reduzieren sowie die Ursachen von Rückgaben nachvollziehen. Daraus können gezielte Verbesserungen entstehen, die das Rückgabevolumen insgesamt senken.
Warum das wichtig ist
Zeigt, warum Rückgaben erfolgen, und liefert Ansatzpunkte für Verbesserungen an Produkten und Verkaufsprozessen.
Woher beziehen
Wird in Oracle Order Management üblicherweise als Code oder Textfeld auf der RMA-Position gespeichert.
Beispiele
DefektFalscher Artikel versandtZu spät eingetroffenGünstigerer Preis verfügbar
|
|||
|
Tatsächlicher Erstattungsbetrag
ActualRefundAmount
|
Der endgültige Geldbetrag, der tatsächlich verarbeitet und an den Kunden erstattet wurde. | ||
|
Beschreibung
Dieses Attribut gibt den endgültigen, bestätigten Betrag an, der dem Kunden nach allen Prüfungen, Anpassungen und Gebühren zurückgezahlt wurde. Der Wert bildet das tatsächliche finanzielle Ergebnis des Rückgabefalls ab. Dieser wichtige Finanzdatenpunkt wird im Dashboard „Beantragte und tatsächliche Erstattungsbeträge“ verwendet. Der Vergleich mit dem beantragten Betrag ist entscheidend für die Berechnung der KPI „Abweichungsquote bei Erstattungsbeträgen“ und für das Verständnis der finanziellen Auswirkungen von Rückgaberichtlinien, Artikelzuständen und Anpassungen während der Bearbeitung.
Warum das wichtig ist
Bildet das tatsächliche finanzielle Ergebnis der Rückgabe ab und ermöglicht Abweichungsanalysen sowie die Finanzberichterstattung.
Woher beziehen
Diese Informationen stammen wahrscheinlich aus der Gutschrift oder den Kreditorenbuchungen, die in Oracle Fusion Financials mit dem Rückgabefall verknüpft sind.
Beispiele
129.9940.000.00
|
|||
|
Zieldatum für die Erstattung gemäß SLA
RefundSlaTargetDate
|
Das Datum, bis zu dem die Erstattung gemäß Service Level Agreement abgeschlossen sein soll. | ||
|
Beschreibung
Dieses Attribut legt die Frist für den Abschluss der Erstattung in einem bestimmten Fall fest. Das SLA-Ziel richtet sich häufig nach den Unternehmensrichtlinien, dem Kundenstatus oder dem Rückgabegrund. Dieses Datum dient als Maßstab für Pünktlichkeit und Compliance. Es wird direkt im Dashboard „SLA-Einhaltung bei Rückgaberichtlinien“ verwendet und ist für die Berechnung der KPI „Erfüllungsquote des Erstattungs-SLA“ unverzichtbar. Durch den Vergleich des tatsächlichen Abschlussdatums mit dem Zieldatum lassen sich SLA-Verstöße erkennen und Fälle priorisieren, bei denen eine verspätete Bearbeitung droht.
Warum das wichtig ist
Dient als Maßstab für die termingerechte Bearbeitung und ist entscheidend für die Berechnung von SLA-Compliance-KPIs.
Woher beziehen
Dies kann ein eigenes Datumsfeld im Rückgabefall sein. Alternativ lässt sich das Datum berechnen, indem ein festgelegter Zeitraum, zum Beispiel 14 Tage, zum Datum der Rückgabeanmeldung addiert wird.
Beispiele
2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z
|
|||
|
Abweichung beim Erstattungsbetrag
RefundAmountDiscrepancy
|
Die berechnete Differenz zwischen dem beantragten und dem tatsächlichen Erstattungsbetrag. | ||
|
Beschreibung
Diese Kennzahl beziffert die Differenz zwischen dem vom Kunden beantragten und dem tatsächlich erhaltenen Betrag. Sie wird berechnet, indem „ActualRefundAmount“ von „RequestedRefundAmount“ abgezogen wird. Dieser berechnete Wert bildet die Grundlage für die KPI „Abweichungsquote bei Erstattungsbeträgen“. Ein Wert ungleich null zeigt an, dass der Betrag während der Bearbeitung angepasst wurde. Die Analyse der Gründe für solche Abweichungen, etwa Wiedereinlagerungsgebühren oder Abzüge für Beschädigungen, liefert Erkenntnisse zur Wirksamkeit von Richtlinien und zur Kundenkommunikation.
Warum das wichtig ist
Beziffert finanzielle Anpassungen im Erstattungsprozess und hilft, die Auswirkungen von Richtlinien und Prüfergebnissen zu analysieren.
Woher beziehen
Berechnetes Feld: „RequestedRefundAmount“ - „ActualRefundAmount“.
Beispiele
0.005.50-10.00
|
|||
|
Kunden-ID
CustomerId
|
Die eindeutige Kennung des Kunden, der die Rückgabe veranlasst hat. | ||
|
Beschreibung
Dieses Attribut ist die eindeutige ID des Kunden, der dem Rückgabefall zugeordnet ist. Es verknüpft den Rückgabeprozess mit der Kundendatenbank. Eine kundenbezogene Analyse von Rückgaben kann wichtige Muster aufzeigen. So lassen sich beispielsweise Kunden mit ungewöhnlich häufigen Rückgaben erkennen, was auf Zufriedenheitsprobleme oder möglichen Betrug hindeuten kann. Außerdem können Sie Rückgaben nach Kundensegmenten auswerten und feststellen, ob bestimmte Gruppen ein anderes Rückgabeverhalten zeigen.
Warum das wichtig ist
Ermöglicht eine kundenbezogene Analyse, mit der sich wiederholte Rückgaben, Verhaltensmuster in Kundensegmenten und möglicher Betrug erkennen lassen.
Woher beziehen
Zu finden als Kunden- oder Party-ID im Kopf des ursprünglichen Verkaufsauftrags oder des Rückgabeantrags in Oracle Order Management.
Beispiele
CUST-100589743ACC-54321
|
|||
|
Lager-ID
WarehouseId
|
Die Kennung des Lagers oder Standorts, an dem der zurückgesendete Artikel eingegangen ist. | ||
|
Beschreibung
Dieses Attribut bezeichnet den konkreten Standort, etwa ein Distributionszentrum oder Lager, an dem der zurückgesendete Artikel eingegangen ist und bearbeitet wurde. Die Auswertung nach Lagerstandort ist wichtig, um standortspezifische Leistungsprobleme zu erkennen. Sie ermöglicht den Vergleich von Prüfzeiten, Ergebnissen der Artikelverwendung und gesamten Durchlaufzeiten zwischen verschiedenen Standorten. So können operative Ineffizienzen, Personalengpässe oder Schulungsbedarf an einzelnen Standorten sichtbar werden.
Warum das wichtig ist
Ermöglicht die Auswertung der Leistung nach Standort und hilft, regionale oder standortspezifische Engpässe und Ineffizienzen zu erkennen.
Woher beziehen
Dieses Feld, häufig „ORGANIZATION_ID“ genannt, ist in Oracle Inventory Management der Wareneingangsbuchung zugeordnet.
Beispiele
WH-US-WESTWH-EU-CENTRALDC-01
|
|||
|
Nacharbeit
IsRework
|
Ein boolesches Kennzeichen, das angibt, ob eine Aktivität Teil einer Nacharbeitsschleife ist. | ||
|
Beschreibung
Dieses Kennzeichen markiert Aktivitäten, die Schritte aus demselben Case wiederholen und damit auf eine Prozessschleife oder Nacharbeit hindeuten. Fällt ein Artikel beispielsweise bei der Prüfung durch und muss erneut geprüft werden, wird das zweite Prüfereignis als Nacharbeit gekennzeichnet. Dieses Attribut ist grundlegend, um Prozessineffizienzen zu quantifizieren. Es wird im Dashboard „Nacharbeitsquoten bei der Rückgabebearbeitung“ verwendet und dient zur Berechnung der KPI „Häufigkeit von Nacharbeitsereignissen bei Rückgaben“. Nacharbeit und ihre Ursachen zu ermitteln, ist ein zentrales Ziel von Process Mining, denn sie weisen direkt auf unnötigen Aufwand, Verzögerungen und höhere Kosten hin.
Warum das wichtig ist
Kennzeichnet Prozessineffizienzen und Schleifen direkt und erleichtert so die Quantifizierung und Analyse der Nacharbeitsursachen.
Woher beziehen
Dieses berechnete Attribut wird von den Algorithmen der Process-Mining-Software ermittelt, die wiederholte Aktivitäten innerhalb eines einzelnen Case erkennen.
Beispiele
truefalse
|
|||
|
Produkt-ID
ProductId
|
Die eindeutige Kennung des zurückgegebenen Produkts. | ||
|
Beschreibung
Dieses Attribut ist die eindeutige Kennung, etwa eine SKU oder Artikelnummer, des Produkts, um das es bei der Rückgabe geht. Es verknüpft den Rückgabeprozess mit dem Produktkatalog. Die Analyse auf Produktebene ist entscheidend, um problematische Artikel zu erkennen. Wenn Unternehmen die Prozessanalyse nach Produkt-ID filtern oder auswerten, können sie Produkte mit hohen Rückgabequoten, langen Prüfzeiten oder bestimmten Fehlermustern ermitteln. Diese Informationen sind wichtig für die Qualitätskontrolle, das Lieferkettenmanagement und die Produktentwicklung.
Warum das wichtig ist
Verknüpft den Rückgabeprozess mit bestimmten Produkten und ermöglicht so die Analyse von Produktqualität und Rückgabemustern.
Woher beziehen
Dies wäre das Feld „INVENTORY_ITEM_ID“ oder ein ähnliches Feld auf der RMA-Position in den Modulen Oracle Order Management oder Inventory.
Beispiele
PROD-5540-ASKU-98765ITEM-001-B
|
|||
|
RMA-Nummer
RmaNumber
|
Die eindeutige Kennung des Vorgangs zur Genehmigung einer Warenrücksendung. | ||
|
Beschreibung
Die RMA-Nummer ist die formelle Genehmigung für einen Kunden, ein Produkt zurückzusenden. Häufig entspricht sie der Rückgabefall-ID. In manchen Systemen ist sie jedoch eine separate, vorgelagerte Kennung. Dieses Attribut dient als zentrale geschäftliche Referenznummer, die sowohl internen Benutzern als auch Kunden vertraut ist. Sie können damit Fälle suchen und filtern. Bei Mitteilungen zur Rückgabe ist sie häufig die wichtigste Referenznummer.
Warum das wichtig ist
Dient als zentrale geschäftliche Referenznummer für die operative Nachverfolgung und die Kommunikation mit Kunden.
Woher beziehen
Dies ist die primäre Kennung des Objekts „Return Merchandise Authorization“ in Oracle Order Management.
Beispiele
789001789002789003
|
|||
|
Rückgabeart
ReturnType
|
Ordnet die Rückgabe nach dem erwarteten Ergebnis ein, zum Beispiel Erstattung, Umtausch oder Reparatur. | ||
|
Beschreibung
Dieses Attribut klassifiziert die Art der bearbeiteten Rückgabe. Der Prozessablauf und die erforderlichen Schritte können sich deutlich unterscheiden, je nachdem, ob der Kunde eine Geldrückerstattung, ein Ersatzprodukt oder einen reparierten Artikel erhält. Die Auswertung nach Rückgabeart ist wichtig, um Prozessvarianten zu verstehen. Sie ermöglicht separate Prozessmodelle für Erstattungen und Umtauschvorgänge. So lassen sich spezifische Engpässe und Leistungsmerkmale der einzelnen Abläufe erkennen. Diese Segmentierung ist eine wichtige Grundlage für gezielte Prozessverbesserungen.
Warum das wichtig ist
Ermöglicht die getrennte Analyse unterschiedlicher Prozessabläufe, da Umtausch und Erstattung häufig verschiedene Schritte umfassen.
Woher beziehen
Dies ist in Oracle Order Management üblicherweise ein Kategorie- oder Typfeld im RMA-Kopf oder auf der RMA-Position.
Beispiele
ErstattungUmtauschReparatur
|
|||
|
SLA eingehalten
IsSlaCompliant
|
Ein boolesches Kennzeichen, das angibt, ob die Erstattung innerhalb der festgelegten SLA-Frist bearbeitet wurde. | ||
|
Beschreibung
Dieses berechnete Attribut gibt für jeden Rückgabefall einfach an, ob das SLA eingehalten wurde. Dazu wird der tatsächliche Timestamp des Erstattungsabschlusses mit „RefundSlaTargetDate“ verglichen. Das Kennzeichen ist wichtig, um Compliance-Quoten einfach zu messen und darzustellen. Es bildet die Grundlage für das Dashboard „SLA-Einhaltung bei Rückgaberichtlinien“ und vereinfacht die Berechnung der KPI „Erfüllungsquote des Erstattungs-SLA“. Durch schnelles Filtern und eine Ursachenanalyse lässt sich nachvollziehen, warum bestimmte Fälle ihre SLA-Frist verfehlen.
Warum das wichtig ist
Vereinfacht die Überwachung und Berichterstattung zum SLA, indem ein Datumsvergleich in eine einfache boolesche Kennzahl umgewandelt wird.
Woher beziehen
Berechnetes Feld. Der Wert ist „true“, wenn der Timestamp von „Refund Processed“ am oder vor „RefundSlaTargetDate“ liegt, andernfalls „false“.
Beispiele
truefalse
|
|||
|
Verwendungscode
DispositionCode
|
Ein Code, der angibt, wie der zurückgesendete physische Artikel letztlich behandelt wurde. | ||
|
Beschreibung
Der Verwendungscode gibt an, was nach der Prüfung mit dem zurückgesendeten Produkt geschehen ist, zum Beispiel, ob es wieder eingelagert, verschrottet, zur Aufarbeitung geschickt oder an den Lieferanten zurückgesandt wurde. Diese Informationen sind wertvoll, um die finanziellen und operativen Auswirkungen von Rückgaben zu analysieren. Anhand der Verwendungscodes kann ein Unternehmen die Kosten nicht wiederverkäuflicher Waren nachvollziehen und Möglichkeiten zur Verbesserung der Aufarbeitung ermitteln. So wird der Rückgabeprozess mit den Bestands- und Finanzergebnissen verknüpft.
Warum das wichtig ist
Verknüpft den Rückgabeprozess mit dem Verbleib des Artikels im Bestand und liefert Erkenntnisse zu Rückgewinnungsquoten und Kosten.
Woher beziehen
Diese Informationen werden nach Abschluss der Prüfung in den Modulen Oracle Inventory Management oder Warehouse Management erfasst.
Beispiele
RETURN_TO_STOCKSCRAPREFURBISHRETURN_TO_VENDOR
|
|||
Aktivitäten bei der Bearbeitung von Rückgaben und Erstattungen
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Artikel eingegangen
|
Diese Aktivität erfasst den physischen Eingang des retournierten Artikels im Lager oder Bearbeitungszentrum. In Oracle Fusion Inventory Management wird sie direkt erfasst, wenn die Ware gescannt und der RMA als eingegangen zugeordnet wird. | ||
|
Warum das wichtig ist
Der Wareneingang ist ein wichtiger Meilenstein, auf den Prüfung und weitere Bearbeitung folgen. Die Zeitspanne zwischen „RMA freigegeben“ und „Artikel eingegangen“ hilft, die Logistik- und Versandleistung zu analysieren.
Woher beziehen
Diese Transaktion wird direkt in Oracle Inventory Management erfasst. Das Ereignis entspricht dem Transaktionsdatum des RMA-Wareneingangs.
Erfassung
Verwenden Sie den Transaktions-Timestamp des RMA-Wareneingangs in Inventory.
Ereignistyp
explicit
|
|||
|
Artikel geprüft
|
Diese Aktivität kennzeichnet den Abschluss der Artikelprüfung, bei der eine Qualitätsbewertung erfasst wird. Sie wird üblicherweise als direkte Transaktion in Oracle Inventory Management oder Quality Management erfasst und aktualisiert den RMA-Status. | ||
|
Warum das wichtig ist
Das Prüfergebnis bestimmt die nächsten Schritte, etwa die Freigabe oder Ablehnung der Rückerstattung. Die Dauer der Prüfung selbst ist eine wichtige Kennzahl für die Effizienz des Lagers.
Woher beziehen
Erfasst wird der Transaktions-Timestamp, zu dem ein Prüfer die Prüfung des RMA-Wareneingangs in Oracle Inventory oder Quality Management abschließt.
Erfassung
Verwenden Sie den Abschluss-Timestamp der Prüftransaktion.
Ereignistyp
explicit
|
|||
|
Gutschrift erstellt
|
Bei dieser Finanzaktivität wird in Accounts Receivable eine Gutschrift erstellt, um die Rückerstattung an den Kunden zu veranlassen. Das Ereignis wird direkt durch den Retourenprozess in Order Management ausgelöst. | ||
|
Warum das wichtig ist
Die Erstellung einer Gutschrift ist ein eindeutiger Meilenstein: Das Unternehmen verpflichtet sich damit zur Rückerstattung an den Kunden. Sie leitet den finanziellen Abwicklungsteil des Prozesses ein.
Woher beziehen
Diese Transaktion wird direkt in Oracle Accounts Receivable erfasst. Über den Verkaufsauftragsverweis auf der Gutschrift lässt sich das Ereignis mit der ursprünglichen RMA verknüpfen.
Erfassung
Verwenden Sie das Erstellungsdatum der Gutschrifttransaktion in AR.
Ereignistyp
explicit
|
|||
|
Retourenfall geschlossen
|
Dies ist die letzte Aktivität. Sie zeigt an, dass alle Schritte zur RMA abgeschlossen sind, einschließlich Wareneingang, Entscheidung über die Retourenbehandlung und finanzieller Abwicklung. Sie wird aus dem abschließenden Status „Geschlossen“ der RMA abgeleitet. | ||
|
Warum das wichtig ist
Dieses Ereignis markiert das definitive Prozessende. Es ist wichtig, um die End-to-End-Durchlaufzeit zu berechnen und sicherzustellen, dass keine Fälle unbegrenzt offen bleiben.
Woher beziehen
Abgeleitet aus dem Timestamp, zu dem der RMA-Auftragskopf und alle zugehörigen Positionen in Oracle Order Management den abschließenden Status „Geschlossen“ erreichen.
Erfassung
Erfassen Sie den letzten Timestamp, zu dem sich der Status des RMA-Auftragskopfs oder einer Auftragsposition zu „Geschlossen“ ändert.
Ereignistyp
inferred
|
|||
|
RMA erstellt
|
Mit dieser Aktivität beginnt der Retourenprozess offiziell: In Oracle Fusion SCM wird eine Return Material Authorization (RMA) erstellt. Das Ereignis wird üblicherweise direkt erfasst, wenn ein Benutzer oder ein automatisierter Prozess einen neuen RMA-Verkaufsauftrag anlegt. | ||
|
Warum das wichtig ist
Dies ist das zentrale Start-Event des gesamten Retourenprozesses. Die Zeitspanne von dieser Aktivität bis zu den folgenden Aktivitäten zeigt die Gesamtdauer des Prozesses und hilft, frühe Verzögerungen zu erkennen.
Woher beziehen
Erfasst wird der Timestamp der Erstellung des Retourenauftragskopfs in Oracle Fusion Order Management. Das Ereignis entspricht dem ersten Speichern des RMA-Dokuments.
Erfassung
Erfassen Sie das Erstellungsdatum des Retourenauftragskopfs.
Ereignistyp
explicit
|
|||
|
RMA freigegeben
|
Dieser wichtige Meilenstein zeigt, dass der Retourenantrag gemäß den Geschäftsregeln geprüft und freigegeben wurde. Er wird üblicherweise anhand einer Statusänderung der RMA abgeleitet und ermöglicht nachfolgende Prozessschritte wie den Versand durch den Kunden. | ||
|
Warum das wichtig ist
Die Freigabe ist ein entscheidender Übergang im Prozess. Verzögerungen wirken sich direkt auf die gesamte Retourendurchlaufzeit und die Kundenzufriedenheit aus. Diese Aktivität ist daher wichtig, um Engpässe bei der Freigabe zu analysieren.
Woher beziehen
Abgeleitet aus dem Timestamp der Statusänderung des RMA-Auftragskopfs oder einer Auftragsposition zu „Genehmigt“ oder „Wareneingang ausstehend“.
Erfassung
Erfassen Sie den Timestamp, zu dem der RMA-Status auf freigegeben gesetzt wird.
Ereignistyp
inferred
|
|||
|
Rückerstattung abgewickelt
|
Diese Aktivität kennzeichnet den Abschluss der Rückerstattungszahlung an den Kunden. Sie wird direkt erfasst, wenn die Zahlungsausgleichstransaktion in Oracle Financials verbucht wird. | ||
|
Warum das wichtig ist
Dies ist ein entscheidender Endpunkt, um die gesamte Rückerstattungsdurchlaufzeit aus Kundensicht zu messen. Er bestätigt, dass das Unternehmen seiner Zahlungsverpflichtung gegenüber dem Kunden nachgekommen ist.
Woher beziehen
Das Ereignis wird anhand des Buchungs- oder Ausgleichsdatums der Zahlungstransaktion in Oracle Accounts Payable oder Treasury erfasst, mit der die Gutschrift ausgeglichen wird.
Erfassung
Verwenden Sie das Ausgleichsdatum der Zahlungstransaktion, mit der die Gutschrift beglichen wird.
Ereignistyp
explicit
|
|||
|
Artikel vom Kunden versandt
|
Diese Aktivität bezeichnet den Versand des Retourenartikels durch den Kunden an das Unternehmen. Das Ereignis wird in Oracle SCM häufig nicht direkt erfasst, lässt sich aber möglicherweise aus Daten einer Speditionsintegration oder einer manuellen Aktualisierung ableiten. | ||
|
Warum das wichtig ist
Diese Aktivität gibt Aufschluss über das Kundenverhalten und die Dauer des Transports. So lassen sich Verzögerungen in der internen Bearbeitung von Verzögerungen beim Versand unterscheiden.
Woher beziehen
Dieses Ereignis kann aus Speditionsdaten abgeleitet werden, die mit der RMA verknüpft sind, oder aus einer manuellen Statusaktualisierung in Oracle SCM. Ohne Integration ist das Ereignis möglicherweise nicht verfügbar.
Erfassung
Timestamp aus einer integrierten Speditions-API oder einem manuell ausgefüllten Datenfeld.
Ereignistyp
inferred
|
|||
|
Artikelprüfung begonnen
|
Diese Aktivität zeigt den Beginn der physischen Prüfung des retournierten Artikels an, bei der sein Zustand beurteilt wird. Sie lässt sich möglicherweise aus einer Änderung des Lagerorts oder Status im Lagerverwaltungssystem ableiten oder durch einen direkten Scan erfassen. | ||
|
Warum das wichtig ist
Die Zeitspanne zwischen Wareneingang und Prüfungsbeginn macht Wartezeiten an der Prüfstelle sichtbar, einem häufigen Engpass.
Woher beziehen
Das Ereignis kann durch eine Statusänderung der Wareneingangsposition oder eine Transaktion erfasst werden, bei der der Artikel in Oracle Inventory Management an einen Prüfplatz verlagert wird. Für eine direkte Erfassung ist möglicherweise eine benutzerdefinierte Konfiguration erforderlich.
Erfassung
Timestamp einer Statusänderung oder einer Umlagerung in einen Prüfbereich.
Ereignistyp
inferred
|
|||
|
Entscheidung über die Retourenbehandlung getroffen
|
Nach der Prüfung wird entschieden, was mit dem retournierten Artikel geschieht, zum Beispiel „Wiedereinlagerung“ oder „Verschrottung“. Erfasst wird dies durch eine direkte Bestandstransaktion, die den Artikel an seinen endgültigen Lagerort bewegt. | ||
|
Warum das wichtig ist
Dieser Schritt ist entscheidend für die Bestandsgenauigkeit und den finanziellen Abgleich. Die Analyse der Entscheidungen gibt Aufschluss über Retourengründe und Qualitätsprobleme bei Produkten.
Woher beziehen
Nach der Prüfung wird die Entscheidung als Transaktion in Oracle Inventory Management erfasst, zum Beispiel durch eine Umlagerung zwischen Lagerorten oder eine Aktualisierung des Artikelstatus.
Erfassung
Erfassen Sie den Timestamp der Bestandstransaktion, mit der die Retourenbehandlung umgesetzt wird.
Ereignistyp
explicit
|
|||
|
Kunde benachrichtigt
|
Diese Aktivität bezeichnet die Mitteilung an den Kunden, dass sein Retourenfall abgeschlossen ist, zum Beispiel weil die Rückerstattung abgewickelt oder ein Ersatzartikel versandt wurde. Sie wird häufig aus einem Mitteilungsprotokoll oder einer Statusaktualisierung des Falls abgeleitet. | ||
|
Warum das wichtig ist
Eine zeitnahe Mitteilung an den Kunden ist entscheidend für dessen Zufriedenheit. Die Analyse hilft sicherzustellen, dass die Service-Level-Agreements für die Kundenkommunikation eingehalten werden.
Woher beziehen
Hierfür ist eine Systemanalyse erforderlich. Die Mitteilung wird möglicherweise in einem integrierten CRM- oder Mitteilungssystem protokolliert. Alternativ kann der Status der RMA oder einer zugehörigen Serviceanfrage manuell aktualisiert werden.
Erfassung
Timestamp aus einem externen Mitteilungssystem oder einer manuellen Aktualisierung.
Ereignistyp
inferred
|
|||
|
RMA abgelehnt
|
Diese Aktivität bezeichnet die endgültige Ablehnung des Retourenantrags des Kunden. Sie wird üblicherweise aus einer Statusänderung der RMA zu „Abgelehnt“ oder „Storniert“ während der Freigabephase abgeleitet. | ||
|
Warum das wichtig ist
Dies ist ein wichtiger Ausnahmeweg. Die Analyse der Häufigkeit und Gründe für Ablehnungen kann Probleme mit Retourenrichtlinien, Kundenerwartungen oder Betrugsversuche aufdecken.
Woher beziehen
Abgeleitet aus dem Timestamp, zu dem sich der Status des RMA-Auftragskopfs oder einer Auftragsposition zu „Abgelehnt“ oder einem entsprechenden Endstatus ändert.
Erfassung
Ermitteln Sie den Timestamp der Statusänderung zu „Abgelehnt“ oder „Storniert“.
Ereignistyp
inferred
|
|||
|
RMA zur Freigabe eingereicht
|
Diese Aktivität bezeichnet den Zeitpunkt, zu dem die erstellte RMA zur internen Prüfung und Freigabe eingereicht wird. Sie wird häufig anhand einer Statusänderung der RMA abgeleitet, die den Wechsel vom Entwurfs- oder Erfassungsstatus in den Status „Freigabe ausstehend“ anzeigt. | ||
|
Warum das wichtig ist
Damit lässt sich die Dauer bis zur Freigabe messen. So können Sie die Zeit für die Dateneingabe von der tatsächlichen Wartezeit auf eine Entscheidung trennen.
Woher beziehen
Abgeleitet aus dem Timestamp, zu dem sich der Status des RMA-Auftragskopfs oder einer Auftragsposition im Freigabe-Workflow von Order Management in „Freigabe ausstehend“ oder einen entsprechenden Status ändert.
Erfassung
Ermitteln Sie den Timestamp der Statusänderung zu „Freigabe ausstehend“.
Ereignistyp
inferred
|
|||
|
Rückerstattung eingeleitet
|
Diese Aktivität zeigt an, dass die Zahlung der Rückerstattung eingeleitet wurde. Sie wird häufig aus einer Statusänderung der Gutschrift abgeleitet, wenn diese vom offenen Status in einen Status wechselt, der die Zahlungsbearbeitung anzeigt. | ||
|
Warum das wichtig ist
Diese Aktivität trennt die Freigabe und Erstellung der Gutschrift von der eigentlichen Zahlungsabwicklung. Diese kann von einem anderen Team oder System übernommen werden und eine Verzögerungsquelle sein.
Woher beziehen
Abgeleitet aus einer Statusänderung der Gutschrift in Accounts Receivable oder aus der Erstellung eines Zahlungsdatensatzes in Accounts Payable, der auf die Gutschrift verweist.
Erfassung
Ermitteln Sie den Timestamp, zu dem sich der Status der Gutschrift zu „Zahlung ausstehend“ oder einem ähnlichen Status ändert.
Ereignistyp
inferred
|
|||
|
Umtauschauftrag erstellt
|
Diese Aktivität tritt auf, wenn der Kunde einen Umtausch statt einer Rückerstattung beantragt hat. Sie wird direkt erfasst, wenn ein neuer Verkaufsauftrag erstellt wird, der häufig mit der ursprünglichen RMA verknüpft ist. | ||
|
Warum das wichtig ist
Diese Aktivität kennzeichnet eine wichtige Prozessvariante. Für eine genaue Durchlaufzeitanalyse der einzelnen Abläufe müssen Umtausch und Rückerstattung getrennt betrachtet werden.
Woher beziehen
Dieses Ereignis wird direkt erfasst, wenn in Order Management ein neues Verkaufsauftragsdokument erstellt wird. Es muss über ein Referenzfeld mit der RMA verknüpft werden.
Erfassung
Verwenden Sie das Erstellungsdatum des neuen, mit der RMA verknüpften Verkaufsauftrags.
Ereignistyp
explicit
|
|||
Anleitungen zum Extrahieren von Daten
Möchten Sie loslegen?
Verwenden Sie dieses Template, um die Datenerfassung zu vereinfachen und wichtige Erkenntnisse zur Bearbeitung Ihrer Rückgaben und Erstattungen zu gewinnen. Beginnen Sie noch heute damit, Ihren Prozess zu optimieren.
Engpässe beseitigen und Retouren- und Rückerstattungsprozesse jetzt optimieren
Ineffizienzen aufdecken und die Zykluszeit in Oracle Fusion SCM um 30 % senken.
Keine Kreditkarte erforderlich. In weniger als 5 Minuten eingerichtet.